品質確保に効果のあった派生開発プロセスの工夫#15
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。
エントリ内容の目次
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒記事はこちら１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
⇒Ｐａｒｔ１
⇒Ｐａｒｔ２（３）ＸＤＤＰでの問題提起と解決策の概要
⇒記事はこちら（４）当方が遭遇した派生開発の問題と解決策の概要
⇒記事はこちら２部 レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
１．派生開発の課題
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３
２．派生開発のプラクティス、プロセス
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３（２）派生開発プロセスの内容
１．対処検討プロセス群
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３
⇒ｐａｒｔ４（本記事が該当）２．開発プロセス群
３．検証プロセス群
（２）派生開発プロセスの内容
１．対処検討プロセス群(part4)
対処検討プロセスを順に解説していく。今回は「1.3 対処案の特定」の解説を行う。
・1.1 原因特定
・1.2 スコープ定義
├─1.2.1 要求コンセプトの明確化
└─1.2.2 要求仕様の特定
・1.3 対処案の特定
・1.4 対処案の検証
・1.5 対処決定
※プロセスの全体像を参照したい場合はこちら。
1.3 対処案の特定
1.3.1 プロセスの目的・概要
対処案の特定プロセスの目的は、要求仕様を満足する対処案を複数検討し、対処案を実現するために明らかにしなければならない調査事項（調査アイテム）を洗い出すことである。
本プロセスでは、必要であれば要求仕様を更に要素分解して、設計書やソースコードの調査を行う。調査の過程で、要素分解、バリエーション検討、マトリクス表記の３手法を活用しながら、対処案を検討する。
対処案を検討する際には、母体ソフトウェアの理解が必要になる。
母体ソフトウェアの知識が乏しい場合は、既存のドキュメントやソースコードを参照して、母体ソフトウェアの知識を補充しながら検討を進める必要がある。
この際に、既存のドキュメントが不足しており、母体動作の理解が難しかった場合は、ソースコードを参照してリバースエンジニアリングを行い、不足している既存ドキュメントを補う形でドキュメントを作成する。
このドキュメントをスペックアウトと呼ぶ。スペックアウトは、後の開発工程において、既存ドキュメントに盛り込まれて、正式なドキュメントとして採用される。
調査量が多い場合は、前提・制約条件の設定手法を用いて、作業スコープを適度にコントロールする。また、調査が完了したアイテムと、未調査のアイテムが何であるのかを明確にする。
本プロセス実行の留意点としては、選択肢や可能性を広げるためにも、できるだけ複数の対処案を挙げることと、対処案を検証するために必要な調査アイテムを漏れなくリストアップすることである。
調査アイテムの量によっては、その時点でプロジェクト納期を満足しない対処案があるかもしれない。調査にかけられる時間も有限であるから、調査アイテムの量や難易度などによって、この時点でスクリーニングを行うことも検討する。
1.3.2 ツールと手法
以下に、本プロセスで用いるツールと手法について示す。
（１）仮説思考
要求仕様がおおよそ明確になった後は、要求仕様を満足する対処を検討し、その対処内容の妥当性を調査していくという流れになる。
対処内容を調査する際には、既存ドキュメントとソースコードを参照しながら、対処の妥当性、他の処理や機能への影響の有無、といった点を確認していく。
この際、関連しそうなドキュメントやソースコードを闇雲に調査することは効率的ではない。
特に派生開発では、既存のシステム仕様を全て把握するだけの期間が与えられる事はないため、関連する箇所を効率的に調査することが課題となる。
何の調査の指針がないままだと、調査は非効率的になるため、現時点で得られている情報を基に、対処案を仮説として検討することが有効である。仮説を設定することによって、調査の指針が明確になる。
仮説の妥当性を検証するという目的意識があれば、闇雲にソースコードやドキュメントを眺める、といった非効率的な作業は不要になる。
ここで重要なことは、現時点で得られる情報だけで仮説（対処案）を導くことである。
対処案の妥当性をもう少し確認してしたい、と考えてむやみに調査を重ねると、無駄に時間を浪費することにもなりかねない。
要求事項と要求仕様は明確になっているので、これらの情報だけで仮説を導くことが重要である。そして次の「1.4 対処案の検証」プロセスで、仮説を検証する。
対処案はあくまで仮説であるので、次の「1.4 対処案の検証」プロセスで調査をした結果、対処案が妥当ではないという結論にたどり着く場合もある。
その際は、対処案を修正して再度検証を繰り返していく。具体的な対処案を掲げて調査を繰り返したほうが、より早く妥当な結論を見つけることができる。
※仮説思考に関する過去のエントリに「知的体力」がある。
その中で仮説思考を具体的に進めていく方法を記載しているので、参考までに。
（２）対処案を検証するための調査アイテムのリストアップ
対処案を特定したら、対処案を検証するための調査アイテムを洗い出す。次節の「1.4 対処案の検証」プロセスでは、この調査アイテムのリストに従って検証を実行する。
調査すべき事項は、調査アイテムをリストアップする担当者の知識や経験の量に大きく依存する。
母体ソフトウェアについての理解がほとんどない担当者の場合は、有識者であればすぐに回答できるような単純な事項も調査アイテムとしてリストアップすることになる。
また母体ソフトウェアの理解が十分にある担当者の場合は、単純な項目はアイテムには挙がらず、より複雑な項目がアイテムとしてリストアップされる。
このように、調査アイテムの内容が担当者の理解度に応じて変動する事は当然であり、変動することを前提に本プロセスを実行するべきである。
理解度が不十分な担当者であるにも関わらず、単純な項目を挙げずに難易度の高い項目だけを挙げても、その後の検討が容易に進む事はない。
むしろ、本来調査しなければならない単純な項目の調査アイテムがリストアップされていないことにより、作業量の見積り精度が悪くなったり、調査作業の進捗がずっと停滞したままになったりする。
調査アイテムの内容が、有識者であればすぐに回答できるような内容である場合は、有識者とのミーティングを通じて、調査アイテムごとに調査結果を記載していく。
決して単純な項目だからといって調査アイテムから消してしまってはいけない。また、既存ドキュメントを読めば記載されていると思える項目でも、現時点でその担当者が把握していないことなのであれば、もらさずに調査アイテムに挙げる。
リストアップを漏らさず行うことで、作業量が把握でき、調査という成果や進捗が見えにくい作業をコントロールすることが可能になる。
次回は、「1.4 対処案の検証」を説明する。
