品質確保に効果のあった派生開発プロセスの工夫（その７）

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

論述対象となるプロジェクト、および開発プロセスの特徴

・組込み系の社会インフラを担うミッションクリティカル・システム。

・信頼性・成熟性について高い品質が求められている。

・稼働直前の総合テストからプロジェクトを引き継ぎ。

・母体システムのドキュメントが不足、母体品質も悪い。

・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。

エントリ内容の目次

内容はかなり長くなるため、順を追って述べる。

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

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

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

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

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

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

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

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

（２）派生開発プロセスの内容
　序．品質確保に効果的な派生開発プロセス
　１．対処検討プロセス群
　２．開発プロセス群
　３．検証プロセス群

２部　（１）派生開発の課題とプロセス改善について

１．派生開発の課題（part2）

１．２　我々のプロジェクトで認識した派生開発の問題

我々の保守プロジェクトでも、前述した派生開発の特徴による問題を認識した。

まず、一般的な派生開発の特徴である、前述の１．～４．が当てはまった。この結果、部分理解の制約を抱えたまま、欠陥修正などの案件をこなすこととなった。

当該保守プロジェクトで採用している開発プロセスは、ウォーターフォール・モデルに従い、方式設計、基本設計、詳細設計、製造、単体テスト、結合テスト、総合テストを行い、各工程間では成果物のレビューを行うものである。前述した派生開発崩しの開発プロセスに該当する（図表1.2-1参照）。

・図表1.2-1　当初採用していた派生開発プロセス

よって、１人プロジェクトになったり、レビューをせずに対処を進めたりするようなことはなかった。

また、関連ドキュメントは変更差分を赤字で記載するルールとしていたため、変更前・変更後の動作差分を把握しやすく、新規開発崩しの問題点の２．に相当する問題は発生しなかった。

ただし、新規開発崩しの問題点の１．に相当する問題は発生した。ドキュメントの変更、例えばシーケンス図にメッセージを１つ追加することが、他の処理にどのように影響を与えるのかは、さらに下流工程に進み、詳細設計やソースコードの調査をしない限り把握することができなかった。

その結果、下流工程に進むにつれ上流工程で検討した内容の考慮漏れが見つかるなどし、手戻りが発生した。

これら当該プロジェクトで発生した問題について図表1.2-2にまとめる。

・図表1.2-2　当該プロジェクトに当てはまった派生開発の特徴や問題

派生開発の特徴 （図表1.1-1参照）	プロジェクトへの 該当有無	プロジェクトで 発生した問題
１．	該当する	部分理解の制約
２．	該当する
３．	該当する
４．	該当する
５．	該当しない	なし
６．	該当する	新規開発崩しの問題点

新規開発崩しの問題点 （図表1.1-2参照）	プロジェクトへの 該当有無	プロジェクトで 発生した問題
１．	該当する	手戻りの発生
２．	該当しない	なし

以上までに一般的に考えられる派生開発の問題について見てきたが、ここからは、当該プロジェクトで認識した問題のうち、特に品質確保への影響が大きく、解決が必要だと考えられた４つの問題について取り上げる。

この問題は、前述した派生開発の特徴や、新規開発崩しによる問題、当該プロジェクトの特徴が組み合わさって発生したものである。また、これらの問題の解決によって、品質確保や生産性の向上に一定の効果があると考えられる問題を選択している。

次の1.3節では本問題の内容と原因、問題から得られた教訓を述べる。ここから得られた教訓が、2章で述べる「派生開発の４つのプラクティス」や「派生開発のプロセス」へとつながる。

なお、ここで述べる４つの問題のうち２つは、当該プロジェクトの前半に認識した課題である。

残り２つはプロジェクトの後半で認識した問題である。プロジェクトの前半は、母体システムに関する理解がかなり不足していたことと、システムの特徴を把握できないまま開発を進めたこともあり、検討漏れによる欠陥やデグレードの発生が多かった。

プロジェクトの後半になると、母体システムの理解もおおよそ進み、単純な欠陥の混入や流出は発生しなかった。ただし、欠陥への対処の水平展開が漏れるなどの問題が発生していた。このため、ここで述べる４つの問題が、読者のプロジェクトで顕在化していないかを検討する際は、プロジェクトの進捗状況やチームメンバの成熟度も１つの参考になると考えている。

１．３　特に解決が必要だと考えた４つの問題

４つの問題の概要は以下である。

・図表1.3-1　解決が必要だと考えた４つの問題

通番	問題の概要	対応する派生開発の特徴	対応する新規開発崩し問題	問題発生時点
１	母体ドキュメントの不足や不備によって、調査・検討不足が発生し、欠陥混入が発生した。	２	１	前半
２	ウォーターフォール・モデルに従って対処を検討した結果、下流工程に進むにつれて「暗黙の制約条件」が発見され、当初検討した対処が実現できず手戻りが発生した。	６	１
３	対処の結論だけが資料に記載されており、結論を導くまでの設計者の思考過程がわからないため、レビューで対処内容の妥当性の検証が困難で、欠陥の流出が発生した。	２、６	－	後半
４	設計段階では影響を想定していなかった処理について、テスト工程で範囲を広げてテストしたところ、関連する欠陥が多発した。	６	－

通番の１～２は、プロジェクトを開始してすぐに直面した問題である。通番３～４は、複雑な対処案件をこなせるようになってきた後半で直面した問題である。

表中「対応する派生開発の特徴」の欄であるが、プロジェクト全体では部分理解の制約を受けているが、その中でも特に関連すると思われる派生開発の特徴を挙げた。「対応する新規開発崩し問題」欄は、当該プロジェクトは図表1.1-2の１．のみ当てはまったので、その問題が影響を及ぼしていると思われるものに記載をした。

このようにしてみると、図表1.1-1派生開発の特徴に示す、“６．派生開発に適したプロセスが検討されていない（存在しない）”が最も多く関連していることがわかる。このことからも、派生開発に適した開発プロセスを検討することの重要性が伺える。

以降に問題の１つ１つを詳しく見ていく。

（１）母体ドキュメントの不足や不備によって、調査・検討不足が発生し、欠陥混入が発生した

●問題内容と原因

本問題の原因は、システムの動作仕様を理解するためには既存のドキュメントが不足していること、変更内容が工程を経るたびにどのように実現されているのかを追跡できないこと、の２つである。

プロジェクトを引き継いですぐに、引継ぎ前に積み残していた残案件の対処（欠陥是正）を行うこととなった。引継ぎ前の担当者が作成していた変更要求仕様書が存在しているため、その内容に従って変更を行えば比較的容易に対処できる、と誰もが理解をしていた。

作業はウォーターフォール・モデルに則り、最上流の設計書の修正から開始された。ハイレベルの基本設計においては、シーケンス図に新たなメッセージを追加するといった程度の対応であった。母体のドキュメントも、システム全体のシーケンス図が主な記述内容であり、それ以外に修正が必要になるドキュメントはなかった。このため、基本設計はほとんど工数をかけることなく完了した。

ただし詳細設計に突入した頃から、いろいろな混乱が発生してきた。その原因は、基本設計書と詳細設計書の間をつなぐ情報が不足していたからである。

基本設計書は、機能を主語にして、機能単位でシステムが動作すべき仕様が記載されており、プログラムの内部構造については一切触れられていない。これに対し、次工程での詳細設計書は、プログラム構造を主語として、構造単位で動作やフローチャートが列記されていた。プログラムを構成するタスクやメモリ、処理モジュールという単位でブレイクダウンされている。

本来ならば、基本設計書に記載されているシステムの外部動作仕様を、どういった内部処理やメモリ構成で実現するかの青写真として、ＤＦＤやＵＭＬなどの表記を使った内部構造で表現し、それを詳細設計工程で更に細分化する、という流れで設計を行う。

しかし外部動作仕様（外部）と、詳細なモジュール構造（内部）だけしかドキュメントがなく、その中間をつなぐ設計書（外部←→内部）が存在していない。

このため、基本設計書に記載されている機能や処理が、詳細設計書に記載されているどのモジュールやどのロジック、どのメモリ構成で実現されているのかを対応付けることが困難であった。

これらの情報はすべて前担当者の頭のなかにあり、ドキュメントとして表現されていなかった。対応をさせるためにソースコードを参照してボトムアップ的に調べるしかなかったが、派生開発特有の短納期という制約もあり、十分な調査ができず、結果的には影響範囲を見逃してしまい、欠陥を混入させることになった。

もう１つの問題は、基本設計書の内容を、詳細設計書に落とし込んだ際に、本当にその変更点だけで基本設計書の内容を漏れなく反映できているのかをレビュー等で追跡できなかったことである。

前述したように、基本設計書と詳細設計書は、ドキュメント間のトレーサビリティが低いという特徴があった。そのことによる自明の結果として、変更箇所の妥当性をレビューする際においても、上流の成果物の内容が、漏れなく下流の成果物に落としこまれているのかをレビューアがチェックすることも困難となる。

無論レビューアもプロジェクトを引き継いだばかりであり、詳細な設計情報は把握していない。結果的には、レビューの効果が低いために欠陥の除去ができず、欠陥がテスト工程に流出することとなった。

本問題の内容をまとめて振り返ると、（１）ドキュメントの記載が不足しているために、ドキュメント間のトレーサビリティが確保できないこと、（２）レビューでドキュメントの変更箇所に漏れがないのかを工程間で追跡できないこと、の２つが挙げられる。

●得られた教訓

母体ドキュメントの記載不足や誤りが多く、ドキュメント品質が悪い場合は、そのドキュメントをベースに設計をすれば、設計された内容も悪い品質を継承することになる（ガベージイン・ガベージアウト）。

各工程のドキュメント間のトレーサビリティを確保するには、工程で区切らず、工程を横断して検討するための資料（対処検討資料）を作成する必要がある。そして工程間のトレーサビリティが低い箇所は、調査を行ってドキュメントを作成し、不足しているドキュメントを補わなければならない。

また、レビューにおいてドキュメントの変更箇所に漏れがないのかを追跡できるために、変更箇所を一覧できるドキュメントが必要である。つまりは、ドキュメントに適切なトレーサビリティ（追跡可能性）を与える必要があることがわかった。

得られた教訓から導いたプラクティスは以下である。

プラクティス１
・ドキュメントのトレーサビリティ強化

（２）ウォーターフォール・モデルに従って対処を検討した結果、下流工程に進むにつれて「暗黙の制約条件」が発見され、当初検討した対処が実現できず手戻りが発生した

●問題内容と原因

本問題の原因は、既存のドキュメントとソースコードには乖離があり、ドキュメントに記載されていない詳細な制約事項は、ソースコードを参照しなければ把握できないことである。

前述したように、当初はウォーターフォール・モデルに従って開発を行っていた。

ドキュメントは上流工程のものほど、概要レベルの記載でかつページ数も少ない。上流工程の開発作業は、存在する方式設計書や基本設計書の一部を変更するだけで済んでしまうため、とても少ない工数で作業が完了してしまう。

作業を行っていても、これほど少ない工数で終えてしまっていいのか不安があった。検討漏れが存在している可能性を否定できなかったが、既存のドキュメントを見る限りはそれ以外に修正が必要と感じる箇所はなかった。

ただし、その不安は的中することになる。詳細設計工程や製造工程へ進むと、上流ドキュメントだけでは理解することができなかったプログラム構造上の制約が次々に発見された。

このため、一旦上流工程に戻って設計し直すことも発生した。このような手戻り作業が増えるため、工程が進むにつれ作業工数が増大していった。当然、スケジュール上はそのような問題が多発することを盛り込んでいないため、連日の残業でカバーすることとなる。

このような作業プロセスは、手戻りのリスクを常に抱えたまま工程を進行させるようなものである。手戻りリスクによる予備の期間や工数を、どのくらい確保すればよいのかが分らないため、運任せのプロジェクト運営になってしまう。

事前にリスクを洗い出し対応を打つことで、計画的なプロジェクト運営を行う必要があった。

●得られた教訓

派生開発は、新規開発とは異なり既にソースコードまで存在している。そのため、上流工程で実施したいと考えた対処が実現できるかどうかは、下流工程の成果物を確認しなければ判断できない。

下流工程の成果物を調査せずに対処内容を決定すれば、手戻りのリスクを抱えたままでプロジェクト運営をすることになる。

このため、対処案が実現できるのかを、下流工程の作業を前倒し実施して、事前に検討することが必要である。
得られた教訓から導いたプラクティスは以下である。

プラクティス２
・フロントローディング強化

残り２つの問題については次回に見ていく。