ODC分析についてのよもやま話〜ソフトウェア不具合についてのあれやこれや・・・〜第9回（最終回／後編）「不具合の低減：では、どうすれば良いのか？」

前回、不具合が起こる要因の一つに「品質表現の変容」にあると捉え、次のように述べました。

「一件の要求品質であっても扱われる工程あるいは担当する人たちによって、それぞれが捉える品質表現は変化し、また品質メトリクスという形に変容していくことを指します。

人伝てに共有される要求品質は都度表現が変容することで、その解釈にギャップ（隙間、誤解、曲解など）が生じやすくなり、そのことが実装で不具合となって現れてしまうのではないかと考えています。」

図にすると図表1のイメージとなります。

この利用者と開発者のギャップを低減させる方策にシステムとソフトウェア両面から取り組んだのが、利用時の品質（ISO25000シリーズ）です。通称SQuaRE (Systems and software Quality Requirements and Evaluation、スクエア) と呼ばれています。

このISO25000シリーズ (SQuaRE) の統括エディタを務められた早稲田大学名誉教授の東 基衛先生によるSQuaREにおける「利用時の品質」の捉え方を図解したのが図表2に示す「品質のライフサイクル」*1 です。

ちなみに、東先生とはSQuaREについてSECジャーナルへの寄稿をお願いした際、お会いする機会がありました。その際、東先生は利用時品質でなく「利用時の品質」という言葉を使われていたので、本稿でも「利用時の品質」としています。

設計者の思いとお客様（ユーザー）の期待とにギャップがあると、顧客満足度の低下を招くことが分かっています。そのギャップを埋めるために登場したのが、利用時の品質を定義したISO25000シリーズ (SQuaRE) です。

そこで定義されたのが、図表3のSQuaRE品質モデル*2 である開発者視点の製品品質モデルと利用者視点の利用時の品質モデルです。

これまでなじみの製品品質モデル（品質特性）に加え、ユーザーの観点からの特性として利用時の品質モデルが加わったことで、設計やテストでは、これら二つの別々の見方を考慮する必要があるかのように見えます。

しかし、そうではないと私は考えます。

別々に見えるのは、対象（製品）を捉える立場の違い（開発者かユーザーか）で分かれていることを示しているのであって、実は同じ対象を見ています。

利用時の品質の「心」はODC分析のインパクト属性（図表4）*3 の「心」と通じるものがあり、同じ「心」の観点で対象を見ていると考えています。
インパクト属性の定義「心」は「CUSTOMER FIRST」を掲げる当時（‘90年）のIBM全社共通の品質指標として定義されたもので、顧客満足度向上を目指したものだからです。
加えて、製品開発の観点とお客様観点の両面から対象を見ることを求めているからです。

そのことから手繰っていくと次のようなつながりがあることが見えてきました（図表5）。

これらから、利用時の品質モデルと製品品質モデルとはODC分析のインパクト属性とつながっていると捉えられます。
ODC分析でのインパクト属性分析では、不具合の持つ製品品質の観点と同時に利用時の品質観点を認識しながら分析すると、より分かりやすく的確になります。また、改善策にも利用時の品質観点から策定することで、顧客満足度の向上につながります。

このように考えれば、品質に対する視野が広がるでしょう。

では、本題の不具合をなくすために今日明日何から手をつければ良いのでしょうか？

製品品質、利用時の品質を理解した上で、要求を分析して確実に設計につなげ、漏らさずレビューとテストで検証するには、確実な「要求と設計のひも付け」が確保できることにあると考えています。

前稿（前編）で言及した「不具合の芽は設計で芽生る」ということの理由は、この「ひも付け」の弱さであると考えているからです。

「要求のひも付け」とよく言われますが、実際にひもで結ぶことができれば、誰が見ても理解できるはずですが、そうはいかない現実に対してどういう解決策があるでしょうか。

私がこれまで、いかに品質を上げるか、不具合を低減させるかに取り組んできた中で、「要求と設計のひも付け」に効果が実感できた手法がUSDMです。
USDM (Universal Specification Describing Manner)*4は、派生開発推進協議会が提唱されているもので、公開されている資料*5 を参照しながら紹介します。

本連載のなかでUSDMを詳細に説明するのは本筋ではないので、その特徴と有効性、注意点、そしてあえてここで紹介する理由としてODC分析との親和性を説明します。

USDMの特徴と有効性：

要求と仕様を一対一で階層化する

USDMの最大の特徴は、要求と仕様を一対一で階層化して表現することで、要求の見落とし、仕様の抜け、漏れを早期発見するのに極めて有効な仕様書の表記方法であることです。

要求の中にある「動詞」を時系列に抽出する

要求の中に含まれる「動詞」に着目して、一つ一つの「動詞」を一つの仕様として捉え、それを時系列に階層化します（図表6）。

要求から仕様へ階層化する具体例を次に示します。

図表7は、自動車のクルーズコントロールの始動に対する要求（制御仕様調査書）をUSDM化して要求仕様書で表現した例です。

この事例では、自然言語で書かれた制御仕様書（要求）の中にある機能要求を抽出して、サブシステムへの要求としてUSDMの最上段（ピンク色部分）に置き、そこからブレークダウンしてソフトウェア要求をその下に置いていきます（黄色部分）。ここでは二つソフトウェア要求があります。それぞれのソフトウェア要求の直下に設計したソフトウェア仕様（水色部分）を置きます。
このように、要求と仕様を一対一で階層化することで、仕様がどの要求にひも付くかが明確になります。

ただし、USDM策定には注意すべきことがあります。

1）USDM：要求から動詞を全て出し切る

・・・と、いうけれど、機械的にやれば出し切れるというものではありません。文脈を読むことが大切です。要求に現れない隠れた動詞を見逃さないこと（図表8）。

よく見落とすのが、「〜をして、〜をする」という要求表現の中には、後半の「〜をする」ためには、「〜をして」の後に必要な処理が潜んでいたりします。

2）USDM：要求も必要に応じて階層化する　あるいは階層分割をする

要求項目が複雑多岐な場合、いきなり全部を表そうとしても収まりきらないことになりかねません。こういったことを避けるためには、最初に要求全体を把握できるように大項目、中項目、小項目に整理しておき、大項目の要求を分割して小さな範囲にしてそれぞれに階層化するのが良いでしょう。

私のコンサルでの経験から紹介します。対象は艦艇の艦内監視ネットワークシステムで、艦内区画に張り巡らされた各種センサー（発煙、火災、浸水、ガス発生など）情報を集約したセンサー情報の組み合わせから事象を特定し、対応として該当区画の防火扉の閉鎖、換気装置の開閉、消火班の配置などの指示を出すというシステムでした。このシステムに対して、いきなりUSDM化を始めたら、あまりに組み合わせと場合分けが多くなり、とても巨大な表になってしまった、という反省があります。

3）USDM：エラーケースを見落としがち

要求表現は、とかく正常系のみの場合が主体になりがちです。そこで、要求の「〜の場合、〜処理をする」という場合、常にエラーケース「〜でなかった場合」はどうするかを意識しながら階層化していく必要があります。

これらのことを注意しながらUSDMで仕様を表現する経験を積むと、要求-仕様をUSDM化することで、トレーサビリティーマトリックス化やテストカバレージマトリックス化への拡張が可能と気付きました。

特にUSDMはODC分析と親和性があることに気付いたのです。

「動詞」に着目するという点において、ODC分析との親和性が生まれます。

連載第3回でODC分析の属性の説明の中では割愛しましたが、タイプ属性分類のヒントとして次のように「動詞」に着目することで、タイプ属性選択肢が明確になってきます。

一件の不具合報告の記述中にある「動詞」に着目すると、「〜が」という「目的語」あるいは「主語」がひも付いています。この連なりが不具合の本質を示しているとすると、次のようなタイプ属性選択肢のヒントが得られます（図表9）。
（赤字が動詞、青字が主語または目的語）

このように「動詞」に着目すると、図表10のような展開が見えてきます。

以上のことから、私はUSDMとODC分析の融合（の可能性）を発案しました。

図表11は、USDMの応用適用の可能性を示したものです。

図表11は、USDMで表現した要求・仕様書にトレーサビィティーマトリックス、テストケースマトリックスあるいは不具合リストを付加することで、仕様一件一件のてんまつが一目で分かるであろうことが見て取れます。

実際、ある企業でのコンサル活動の中で、仕様書のUSDM化に取り組まれた社員の方からそのままテストケースに使えるのでは？と機能テストケースとして試されたことがあります。そこで私は不具合リストとODC分析のタイプ属性を追記することを提案した結果、そのままODC分析の属性集計に使えるようになりました。
多少の工夫は要りますが単体・機能テストケースには対応できると考えています。

ここまでの説明で、ODC分析とUSDMの組み合わせが、ソフトウェア不具合低減への有効なツールになりうることをご理解いただけるなら、ぜひ実践されることをお勧めします。

連載「ODC分析についてのよもやま話」の最終回として、これまでの不具合ありきの世界から「なぜソフトウェア不具合が起こるのか？」という原点に立ち戻って、多分に私の経験と知見から導き出した私見を述べました。

ODC分析は、不具合そのものを見るだけでなく、不具合の「出方」から開発プロセス実施の「やり方」を見直すための手掛かりになります。
今回の一連の記事が、何かしら皆さんのお役に立てば幸いです。

長くソフトウェア品質に携わってくると、まだまだみなさんにお話ししたい「よもやま話」から溢れた「こぼれ話」があり、今回のそれぞれの話題についてもかなりのエピソードが溢れました。
またいつか、それら溢れた「こぼれ話」を掬う機会があればと思います。連載の最後までお読みくださり、ありがとうございました。

参考文献：

*1) 「システム・ソフトウェア品質標準 SQuaREシリーズの歴史と概要」
(独)情報処理推進機構 (IPA) SEC Journal Vol.10 No.5
早稲田大学 理工学術院 名誉教授 SQuaREシリーズ プロジェクト統括エディタ　東 基衞

*2) ISO/IEC 25010:2011 Systems and Software Quality Requirements and Evaluation (SQuaRE)

*3) Orthogonal Defect Classification – A concept for In-process Measurement
Ram Chillarege, Inderpal S. Bhandari, Michael J. Halliday, etc., IBM Thomas J. Watson Research Center
IEEE Transactions on Software Engineering Vol .18, No. 11, Nov. 1992ⒸIEEE

*4) USDM入門
AFFORDD T2 研究会 ⒸCopyright 2016 派生開発推進協議会

｢ソフトウェア不具合改善⼿法ODC分析」 〜 ⼯程の「質」を可視化する 〜
⽇科技連ODC分析研究会編 杉崎眞弘・佐々⽊⽅規
株式会社⽇科技連出版社 (ISBN978-4-8171-9713-9)