品質確保に効果のあった派生開発プロセスの工夫（その６）
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。
- 論述対象となるプロジェクト、および開発プロセスの特徴
- ・組込み系の社会インフラを担うミッションクリティカル・システム。
- ・信頼性・成熟性について高い品質が求められている。
- ・稼働直前の総合テストからプロジェクトを引き継ぎ。
- ・母体システムのドキュメントが不足、母体品質も悪い。
- ・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。
エントリ内容の目次
内容はかなり長くなるため、順を追って述べる。
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒記事はこちら１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
⇒Ｐａｒｔ１
⇒Ｐａｒｔ２（３）ＸＤＤＰでの問題提起と解決策の概要
⇒記事はこちら（４）当方が遭遇した派生開発の問題と解決策の概要
⇒記事はこちら２部 レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
１．派生開発の課題
⇒今回の記事が該当
２．派生開発のプラクティス、プロセス（２）派生開発プロセスの内容
序．品質確保に効果的な派生開発プロセス
１．対処検討プロセス群
２．開発プロセス群
３．検証プロセス群
２部 （１）派生開発の課題とプロセス改善について
１．派生開発の課題（part1）
１．１ 一般的な派生開発の課題
派生開発とは、母体システムへの機能追加・変更、欠陥是正を行うシステム開発を指す。
母体システムが存在しているという点で、新規開発とは異なる特徴を持っている。派生開発プロセスの１つであるＸＤＤＰを提唱する清水吉男氏によると、一般的に考えられる派生開発の特徴には、次のようなものがある。
・図表1.1-1 派生開発の特徴
- 別の担当者が開発したソースコードを読む必要がある
- ドキュメントが不足していることが多くソースコードの理解が難しい
- これまでの改修によって、当初の設計思想が崩れている
- 案件ごとの変更量は新規開発に比べて少ないため、開発期間が短い
- 変更量が少ないと１人プロジェクトになることがある
- 派生開発に適したプロセスが検討されていない（存在しない）
図表1.1-1の上記１．～４．については、いずれも母体システムの理解が難しくなることの要因ととらえることができる。
他人のソースコードは、自分のソースコードよりも、記述内容の意図を把握しにくい傾向がある。また、ドキュメントが不足していれば母体システムの動作仕様の把握が難しくなる。
度重なる保守で、当初の設計思想が崩れていると、処理間でポリシーに矛盾が発生するため、設計意図を把握しにくくなる。
さらに派生開発の変更量は新規開発と比較して少なくなるため、どうしても開発期間は短く設定される傾向にある。開発期間が短ければ、それだけ母体システムの理解に当てる時間も短くなる。
こうした特徴の結果、母体システムの動作仕様を完全に理解してから開発を行うことは、ほとんど不可能である。清水吉男氏はこのことを部分理解の制約と呼んでいる。
新規開発であれば、上流工程で明らかにした概要設計を、工程を経るたびに詳細化していくため、全体理解⇒部分理解という順番で開発を進めることができる。
しかし派生開発は、変更が求められている局所的な処理がメインターゲットとなるため、システムの全体を理解してから変更対象となる処理部分を理解する、という手順をとることができない。部分的・局所的な変更内容を理解しつつ時間の許す範囲で全体動作を理解し、母体システムに影響を与えないことを調査することになる。
しかし変更量が少なく開発期間が短いという特徴により、全体動作を理解するまでの時間を確保することができない。その結果、部分理解の制約を抱えたまま開発を行うことになる。
部分理解の制約のまま開発を進めることで、次のような問題が発生する。
１つには、変更による母体への影響を把握できずに、デグレードや設計誤りといった欠陥を混入させることである。
２つ目は、レビューアも部分理解の制約を抱えていることから、開発メンバの設計内容の妥当性を検証する手段がなく、欠陥を摘出できずに流出してしまうことである。
３つ目は、影響範囲を適切にとらえられていない場合は、テストで検証する範囲にも漏れが発生し、テストでも欠陥を摘出できずに流出してしまうことである。
次に、図表1.1-1の５．と６．に着目する。
これらの特徴は、派生開発に適した開発プロセスが検討されていない状況を表している。
変更量が少なければ、アサインする担当者が１人になる場合もある。こうした際には第三者によるレビューが省かれてしまうため、開発プロセスを遵守することなく作業を進めてしまう。また、派生開発に適した開発プロセスが検討されていなければ、前述した派生開発の特徴に起因する欠陥を除去できないであろう。
・新規開発崩しの問題点
清水吉男氏は、新規開発用のウォーターフォール・モデルに従った開発プロセスを派生開発に適用することを、新規開発崩しと呼んでいる。
新規開発崩しは、新規開発と同じように方式設計、基本設計、詳細設計、製造と、工程順に成果物を更新し、工程間でレビューを行うプロセスである。清水吉男氏は１人プロジェクトのようにレビューも実行されていない状況よりはまだ効果があるものの、新規開発崩しにも次のような問題があると述べている。
・図表1.1-2 新規開発崩しの問題
- ドキュメントの文字を置き換える作業が中心になるが、文字情報の変更だけでは、変更によって他に影響を与える箇所を特定しにくい
- ドキュメントに変更後の動作だけを記載したのでは、変更仕様（○○という動作を、△△へ変更する）をドキュメントから再度読み取らなければならなくなる
図表1.1-2の１．は、文字情報の記載を変更したことで、どの処理が影響を受けるのかを特定する方法がないことを述べている。
新規開発時に、ある機能を変更する場合は、どの機能への影響を考慮すべき、といった情報をドキュメントとしてまとめていない限り、文字情報の変更が及ぼす影響を特定する手段はないであろう。
図表1.1-2の２．の意味するところは次の通りである。既存のドキュメントは、システムで実現する機能を、機能を主語にして記載していることがほとんどである。
例えば、“障害検出機能は、Ａ回線から障害データを受信し、システムＢへ通知を行う”といった形である。その機能に変更が必要となったため、ドキュメントを“障害検出機能は、Ｃ回線から障害データを受信し、システムＦへ通知を行う”と変更したとする。そのドキュメントを基に開発を行う担当者は、Ｃ回線の前は何回線であったのか、通知を行うシステムＦは、以前は何システムであったのかを、変更前と変更後のドキュメントを見て、差分を再確認しなければならないので手間がかかる、ということを述べている。
以上までに見る特徴の結果、派生開発は新規開発と比較すると、部分理解の制約によって、欠陥混入や流出の可能性が高いということがわかった。
また、新規開発プロセスをそのまま適用しても、派生開発の特徴に合ったプロセスではないため、品質確保の効果が限定的であることがわかった。そのため、派生開発の特徴に合わせた効果のある派生開発プロセスを検討することが、派生開発の課題と言えよう。
今回は以上である。派生開発プロジェクトの一般的な問題点を確認した。
次回は、我々が携わった派生開発プロジェクトで認識した問題点について述べる。
