前回エントリから１ヵ月以上空いてしまいました。
多忙と試験勉強が言い訳なのですが。。
このシリーズエントリは先が長すぎて、No.50とか平気でいきそうなので、きりのいいところでpdf化した内容を一括ダウンロードで終わりにしたいかな、、と考えているこの頃です。

ではプロセス改善のNo.14をどうぞ。

品質確保に効果のあった派生開発プロセスの工夫#14

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part3)

対処検討プロセスを順に解説していく。今回は「1.2.2 要求仕様の特定」の解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.2.2 要求仕様の特定

1.2.2.1 プロセスの目的・概要

要求仕様の特定プロセスの目的は、システムやソフトウェアの構成要素が特定できる形まで、要求コンセプトをブレイクダウンし、適切な作業スコープを設定することである。

要求コンセプトは、「トランザクションの同時受付数を５０００まで拡張する」とか「機器の障害発生時に、アクティブ系の機器が存在しない状態を３０秒以上継続させない」などといった、システムの構成要素や設計・プログラム構成要素を特定しにくい表現になっている。

この表現を、「Ａ機器管理処理ブロックにおいて、○○通知を受信した場合は、□□の動作を行う」といったシステムやソフトウェアの構成要素の振る舞いがわかる程度の詳細度にブレイクダウンしていく。このブレイクダウンされたものを要求仕様と呼ぶ。

要求仕様はある程度の抽象度を保ちながらも、ソフトウェアやシステムの振る舞いを限定する粒度として定める。

要求仕様は、この後のプロセスである「1.3対処案の特定」プロセスのインプット情報になる。「1.3対処案の特定」プロセスでは、要求仕様を満足する具体的な設計情報を含む対処案を複数（または１つ）検討する。

よって要求仕様に求められる詳細さは、要求コンセプトと対処設計案との間の橋渡しをする粒度ということになるが、場合によっては要求仕様を明確に定義しなくてもよい場合もあろう。例えば、欠陥是正の内容があまりに小さい規模でかつ限定的なものであった場合は、要求コンセプトも具体的になる。要求コンセプトから直接的に対処設計案を導き出せるようであれば、無理に要求仕様を定義する必要はない。

では、なぜ要求仕様という、要求コンセプトと対処設計案との中間の成果物を規定しているのか。

これは派生開発の特徴に対応した結果である。派生開発では、母体動作を隅々まで理解しておくことは困難である。また、母体システムに関するドキュメント類が不十分であり、詳細動作を理解するにはソースコードを読まなければならないことも多い。こうした前提に立ったとき、要求コンセプトから要求仕様にブレイクダウンするには、かなりの分量の母体動作調査をしなければならない。

この調査の過程で、既存のドキュメントだけでは知りえなかった動作仕様を「スペックアウト」としてアウトプットするなどの作業を行う。こうした調査の結果として要求仕様がアウトプットされるため、検討漏れや検討誤りが含まれている可能性が高い。このため、具体的な対処案の検討に入る前に、要求仕様という成果物を関係者間で検証し、合意を得ておくことで、早期の品質確保につながり、作業手戻りの削減にもつながる。

つまり、要求仕様を規定する意義の１つとしては、要求コンセプトを要求仕様に落とし込む過程で様々な検討や分析が必要な場合は、一足飛びに対処案を設計するよりも、要求仕様という中間ポイントでレビュー等の検証作業をはさんだほうが、品質の確保に効果的だということが挙げられる。

もう１つの要求仕様を規定する意義としては現実的な作業スコープのコントロールにある。

要求コンセプトは作業スコープが最大になっており、プロジェクトの納期や予算といった制約を踏まえた場合に、スコープが広すぎる場合がほとんどである。そのままのスコープで作業を継続してしまうと、膨大な量の調査や検討作業が発生し、納期や予算を守れなくなってしまう。

そこで、プロジェクトの納期や予算といった制約条件を満足する形で、作業スコープをコントロールする必要がある。本プロセスでは、スコープを詳細化しながら限定化していく手法を解説している。これらの手法を活用し、現実的な作業スコープになるようにコントロールした結果として、要求仕様をアウトプットすることができる。

結果的に要求仕様は、

要求コンセプトをシステマチックにブレイクダウンした結果と、プロジェクト制約を満足するために意図的に（戦略的に）縮小されたスコープの両方

を含むことになる。

以上までに述べたように、要求仕様の特定プロセスは、要求コンセプトを確実に要求仕様へとブレイクダウンし、かつコントロール可能なスコープを設定することを保証するプロセスである。

1.2.2.2 プロセス実施による効果

要求仕様の特定プロセスを実行することで得られる効果は多岐にわたる。主要な効果のみを以下にリストアップする。

• 検討事項の漏れや不備が防止され、高い設計品質を確保できる。
• 検討結果のレビューを効率的・効果的に行うことができ、品質確保が容易になる。
• テスト項目の漏れや不備が防止され、欠陥やデグレードの流出が軽減できる。

1.2.2.3 プロセス実施上の留意点・考慮点

繰り返しになるが、要求仕様の粒度については派生開発プロセスで規定する範囲を超えているため、プロジェクトやシステム特性に応じて定義が必要である（要求、要件、仕様といった粒度の定義を行っている場合もあるため、それぞれの組織で用いている粒度を適宜当てはめればよい）。

要求仕様書や、基本設計書、詳細設計書、ソースコードといった成果物の定義は、要求コンセプトをどのくらい詳細化したかの度合いと、要求コンセプトという日本語表記の文章を、図形情報やプログラム言語などへと変換した度合いを示すだけであり、どの詳細度でどのように成果物を定義するのかは常に自由である。本派生開発プロセスは、これらの成果物の粒度や定義を制限する意図を含んでいない。

1.2.2.4 ツールと手法

以下に本プロセスのインプットをアウトプットに変換するためのツールと手法を示す。本プロセスは作業スコープを詳細化し、かつ適度に縮小することが狙いであるため、主にスコープ縮小・限定化の手法について示す。

（１）前提条件分析
前提条件分析とは、要求コンセプトを実現するうえで満足しなければならない、明示・暗示の前提条件を漏れなく抽出することである。

要求コンセプトに関する前提条件を明らかにしていくにつれ、スコープはより具体的・限定的になっていく。前提条件分析は、要求コンセプトのスコープを絞り込んでいく方法の１つである。

前提条件分析は、要求コンセプトを実現するために影響を受ける箇所を、前提条件である母体システムのドキュメントやソースコードから抽出して、検討が必要な範囲を絞り込んでいく。

前提条件を明らかにしていく具体的な手順としては、「要素分解」や「バリエーションの検証」の手法を組み合わせて行う（「要素分解」や「バリエーションの検証」の解説は後述するため、前提条件分析の理解のためにも、これらの手法の解説を先に読んでおいたほうが良い）。

例えば、「トランザクションの同時受付数を５０００まで拡張する」という要求コンセプトの場合に、このコンセプトを実現するための前提条件を検討していく。

要素分解の１つとして、トランザクション処理を行うシステム処理ブロックに着目した場合は、要素として“処理ブロック（モジュール）”を挙げる。処理ブロックのバリエーション（要素に含まれる類型）はＡ～Ｚまで存在しているとした場合、どの処理ブロックが影響を受けるのかについてバリエーションの検証を行い、関係の有無を検証する。

・図表1.2.2-1　前提条件分析

図表1.2.2-1に示すこれらの調査の結果、前提条件として「トランザクション同時受付数の変更に関連する処理ブロックは、ＡとＢである」ことを導く。

処理ブロックという要素について、全ての取り得るバリエーションを列挙し（最大スコープ）、その後にバリエーションの検証を行って絞り込み（スコープの縮小）をした結果、スコープ境界（対象となるものと、対象外となるもののリスト）が明らかになった。非常に単純な例を挙げたが、このようにして関連する要素１つ１つを絞り込んでいく。

もし、上記のバリエーション検証を行う際に（関係有無欄の○×をつける際に）、既存のドキュメントを参照しても情報が不足しており判断ができない場合は、ソースコードを参照して検証を行う。ソースコードの調査を行った結果については、スペックアウトとしてドキュメント化し、既存のドキュメントを補完できるようにしておく。

前提条件となる要素は多岐に渡る。例えば「改修対象のサブシステム」という要素では、欠陥に関連するサブシステムはＡ～Ｄまであるとしても、今回の改修対象はサブシステムＡだけ、という前提条件が付く場合もある。この場合は、サブシステムＡのみで欠陥の影響を吸収できる改修案を検討しなければならない。

あるいは「システムの既存の制約」という要素が前提条件になる場合もある。「トランザクションの同時受付数を５０００まで拡張する」のが今回の要求だとしても、他のシステム制約として「処理能力として○○bpsを確保する」があった場合、既に存在する制約（処理能力）を遵守できる形で同時受付数を拡張しなければならない。

こういった前提条件を見逃さないように、「システムの既存の制約」という要素について、可能な限りバリエーションを網羅して調査することが望まれる。もしくはシステムの方式設計書をインプット情報にして、そこから読み取れる「システムの既存の制約」に関連する文章を、バリエーションとしてピックアップする方法もある。

以上までに見たように、前提条件分析を行う際のインプット情報は、ドキュメントやソースコードを調査したり、ブレーンストーミングを行ったり、有識者へヒアリングを行うなどして入手する。プロジェクトやシステムの特性に応じたインプット情報を用いる。前提条件の要素を洗い出す際には、後述する「要素分解」を用いる。または以前のプロジェクトで用いた前提条件に関するリストを活用すれば、効率的な前提条件の洗い出しができる。

（２）要素分解
要素分解は、１つの対象を、それを構成する複数の要素に分解をすることである。

大きなスコープの要求を、複数の小さなスコープの要素に分解し、要素ごとに漏れなく検討をするための方法である。派生開発プロセスの全体を通じて何度も活用する手法である。要素分解と、後述するバリエーションの検証は、ほとんどの場合、同時に活用する手法となる。

要素分解を行うためのインプット情報は、要求コンセプトや前提条件などである。これらから関連する要素をピックアップする。例えば、何らかの機能が他の機能に影響する範囲を検討したいのであれば、他の機能を全てバリエーションとして列挙する。または、ある状態でのアクションの変化が、他の状態へ与える影響を検討したいのであれば、他の状態を全てバリエーションとして列挙する。

要素分解とバリエーションの検証を何度も繰り返すことで、要求コンセプトをブレイクダウンして要求仕様に落とし込むことができる。

具体例として、「サブシステムＡに内部障害が発生しても、システム全体のサービス断を避けたい」という要求コンセプトを要求仕様に落とし込んでいくプロセスを簡単に見ていく。本節では、要素分解のみを行い、次節(3)ではバリエーションの検証を行って要求仕様を導く。

まずは要求コンセプトに「サブシステムＡの内部障害によって、システム全体のサービス断を避けたい」とあるのだから、「サブシステムＡの内部障害を契機として、システム全体のサービス断になるケース」を要素にし、この要素に当てはまる全てのパターンをバリエーションとして洗い出す。

また「サブシステムＡの内部障害」を要素にし、内部障害に該当するパターンには何があるのかをバリエーションとして網羅していく。この結果の例を図表1.2.2-2に示す。

・図表1.2.2-2　要素分解

通番１の「サブシステムＡの内部障害」については、３つのバリエーションが列挙された。

次の手順ではこの１つ１つを「バリエーションの検証」で、今回の要求の対象になる内部障害か否かを検証していく。この内容については次節(3)を参照されたい。

通番２の「サブシステムＡの内部障害を契機に、システム全体のサービス断になるケース」についても、３つのバリエーションが列挙された。「バリエーションの検証」では、今回の要求の対象となるのか、実現可能なのか、などを１つ１つ検証する。この内容についても次節(3)で説明を行う。

以上のように、要求コンセプトを構成する要素と、要素に含まれる具体的なケース（バリエーション）を全て網羅することが「要素分解」である。要素分解を行うと、バリエーションはより具体的な内容になる。さらに詳細な内容を検討したい場合は、バリエーションの１つを要素に見立て、更なる要素分解を行う。

要素分解の手法は、プロジェクトマネジメントにおけるＷＢＳと同様に階層化を行うものである。このためＷＢＳ作成時の注意事項が、そのまま要素分解を行う際の注意事項にも当てはまる。最も重要な注意事項は、「細分化されたバリエーションは、細分化前の要素の１００％を表現していること」である。漏れのない細分化が確実に行われていることに留意する。

（３）バリエーションの検証
バリエーションの検証は、「要素分解」で細分化された、要素の取り得る状態のリスト（バリエーション）に対して、特定の質問事項や検証事項に当てはまるか否かを１つ１つ検証するものである。

検証をする観点は任意であり、かつ複数の検証観点を同時に用いてもよい。検証時の留意点としては、検証結果がなぜ導かれたのかの理由を明記することである。

明記することで検証過程を第三者が追跡確認することができるようになる。検証結果だけが記載されていると、検証者が何をどの程度考えて結論を導いたのかが判断できなくなってしまう。

具体例として、前節(2)の図表1.2.2-2で述べた「サブシステムＡに内部障害が発生しても、システム全体のサービス断を避けたい」という要求コンセプトを要求仕様に落とし込んでいくプロセスを簡単に見ていく。前節(2)では、要素分解するところまでを述べたので、本節ではその後のバリエーションの検証を述べる。図表1.2.2-3を参照されたい。

・図表1.2.2-3　要素分解とバリエーションの検証

図表1.2.2-3の通番１の「サブシステムＡの内部障害」については、３つのバリエーションが列挙されたが、この１つ１つを「バリエーションの検証」で、今回の要求の対象になる内部障害か否かを検証していく。

図表1.2.2-3の例では、検証の結果、内部障害のうちバリエーション1-3は対象外であることがわかった。このように１つ１つの対象を検証することで、対象／対象外が明確になり、スコープ境界が明らかになった。

また図表1.2.2-2の通番２の「サブシステムＡの内部障害を契機に、システム全体のサービス断になるケース」については、３つのバリエーションが列挙された。「バリエーションの検証」では、今回の要求の対象となるのかを検証する。

例えば、前提条件分析において「今回の改修対象となるのはサブシステムＡだけ」という前提条件があったとする。その場合は、３つのバリエーションのうち、サブシステムＡだけで対応可能なケースと、サブシステムＡだけでは対応が困難なケースがあることがわかった。

・図表1.2.2-4　要素分解とバリエーションの検証

通番2-2は、前提条件である「今回の改修対象となるのはサブシステムＡだけ」に反しているため、このままでは実現することが難しい。

こうした時に既存のプログラムを大幅に変えたり、前提条件を変更したりしても要求をなんとしても達成すべきなのか、前提条件に従ってスコープ外（対象外）とするのかは、よりハイレベルな関係者間の協議事項になる。

このように、対応しようとすると多大な工数がかかる、といった前提条件とのトレード・オフ課題をピックアップすることも可能である。結果的に図表1.2.2-4の例では、前提条件に反するために、このケースにおいては対象外（対処しない）にする意思決定をしたことになる。

これらの要素分解と検証結果から、要求仕様をまとめると以下のようになる。

サブシステムＡのソフトウェアエラーとハードウェアエラーが発生した際に、サブシステムＢのサービス停止処理と、サブシステムＣへの障害通知処理を行わないようにする。

上記の要求仕様は、要求コンセプトである「サブシステムＡに内部障害が発生しても、システム全体のサービス断を避けたい」の内容が、より具体化され、かつスコープ境界も明確になっている。

なお、要求仕様の記述の詳細度をどの程度に規定するのかは、プロジェクトやシステム特性に応じて別途規定する必要がある。

より詳細な記述を求める場合でも、「要素分解」「バリエーションの検証」を繰り返すことで、どこまでも詳細な落としこみが可能である。

例えば、図表1.2.2-4のバリエーション通番2-1において、サブシステムＡの内部障害によってサブシステムＢを停止させている処理が、具体的にどのくらい存在するのかを更に詳細に調査したい場合を考える。

関連するドキュメントを調査してもよいし、ソースコードを調査してもよい。例えば、サブシステムＡ内部障害が発生したことを示すソースコードをキーに、プログラム全体をｇｒｅｐすることで、更に詳細なバリエーションを展開することができる。この際の要素は「サブシステムＡ内部障害の発生箇所」となり、ソースをｇｒｅｐした結果がバリエーションになる。

「バリエーションの検証」では、「サブシステムＡ内部障害によってサブシステムＢを停止しているか否か」という観点で検証を行えば、変更が必要になるプログラムの箇所（スコープ）を具体的に絞り込んでいくことができる。絞り込んだ結果の例を図表1.2.2-5に示す。

・図表1.2.2-5　スコープの更なる絞込み結果

この図表1.2.2-5に示す詳細度で要求仕様としてまとめても構わない。要求の内容や、プロジェクト、システム特性に応じて規定すれば問題はない。

このように、階層的な要素分解を繰り返すことで、調べたい内容をロジカルにかつ漏れなく列挙することができる。また要素分解した結果が表として残るので、第三者が要素分解の過程に誤りがないのかを検証することが容易になり、レビュー効率も向上する。

また、これらの要素とバリエーションをマトリクス表記することで、システム挙動を漏れなく検討・表記することが可能になる。この点については次節(4)の「マトリクス表記」を参照されたい。

（４）マトリクス表記
マトリクス表記は、縦軸と横軸に任意の要素を設定し、要素の取り得るバリエーションの組み合わせを全て検証・検討するために用いる。

マトリクス表記は、網羅的な記述が行える点が特徴である。

網羅的な表記が特徴であるから、スコープ境界を明らかにするために適した表現手法である。例えば、バリエーションの組み合わせによっては、現実的に存在し得ないパターンもあるが、そのようなイリーガルケースの振舞いまでも検証・検討することができる。

具体例として、要素分解とバリエーションの検証の項で説明した「サブシステムＡに内部障害が発生しても、システム全体のサービス断を避けたい」という要求コンセプトを実現する際に、どのような検討ができるのかを示す。図表1.2.2-6に、要素分解とバリエーションの検証結果をマトリクス表記にしたものを示す。

・図表1.2.2-6　マトリクス表記

サブシステムＡの内部障害のうち、通番７～９の「受信メッセージのタイムアウト」は、今回の対象外とし、サービス断になるケースのうち、通番２と５の「サブシステムＢが自律的にサブシステムＡの障害を検出するケース」は対象外としている。

図表1.2.2-6では、これらの結果が漏れなく記載されており、日本語で記載された要求仕様である「サブシステムＡのソフトウェアエラーとハードウェアエラーが発生した際に、サブシステムＢのサービス停止と、サブシステムＣへの障害通知を停止する」のスコープ境界を明確に示すことができている。

要求仕様をマトリクス表記することのメリットは、１つには設計時点で全ての組み合わせについて漏れなく検討を行うことで、検討漏れを防止できる点がある。

想定外の組み合わせをなくすことで、イリーガルケースでもフェールセーフを考慮した設計を行うことができ、システムやソフトウェアの堅牢性を高めることができる。

メリットのもう１つは、システムやソフトウェアのテスト項目に流用することができ、工数削減および漏れのないテスト項目の洗い出しが可能な点である。

図表1.2.2-6であれば、通番の１～９の全てをテスト項目としてピックアップし、想定動作となることを検証することができる。日本語だけで記載された要求仕様だと、テスト項目を抽出することにも時間がかかるし、抽出したテスト項目に漏れがないことを保証するのが困難である。

要求仕様がマトリクス表記になっていれば、テストで検証すべき事項がすでに明記されているため、テスト項目を洗い出す工数が不要になる。またマトリクスで網羅性が保証されているため、テスト項目が不足することもない。

なお、マトリクス要素が多すぎてテスト項目が多くなってしまう場合は、直行表やオールペア法などの手法を用いて、テスト項目を削減することができる。マトリクス表記はこれらの組み合わせテストとの相性が良く、プロジェクトで目標とするテスト項目密度などの品質目標に応じたテスト項目の抽出が可能である。

また要求仕様だけでなく、他の工程で作成したマトリクスも同じようにテスト項目として採用できる。基本設計工程でのマトリクスであれば結合テスト、詳細設計工程でのマトリクスであれば単体テスト、といったように、開発工程とペアになるテスト工程で採用することが可能である。

マトリクス表記をテスト項目に活用すると、マトリクスを作成する設計段階でテスト工程を意識した開発が行える。これにより、“テストが容易に実施できるか”、“テスト結果の検証が容易にできるか”といった観点について、設計段階から検証することが可能になり、設計品質の向上と、テストの効率化の両方が達成できる。

このように、マトリクス表記をＶ字モデル・Ｗ字モデル開発へ適用することで、設計→検証工程のトレーサビリティが向上する。

次回は「1.3　対処案の特定」の説明を行う。