品質確保に効果のあった派生開発プロセスの工夫（その４）
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。
- 論述対象となるプロジェクト、および開発プロセスの特徴
- ・組込み系の社会インフラを担うミッションクリティカル・システム。
- ・信頼性・成熟性について高い品質が求められている。
- ・稼働直前の総合テストからプロジェクトを引き継ぎ。
- ・母体システムのドキュメントが不足、母体品質も悪い。
- ・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。
エントリ内容の目次
内容はかなり長くなるため、順を追って述べる。
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒記事はこちら１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
⇒Ｐａｒｔ１
⇒Ｐａｒｔ２（３）ＸＤＤＰでの問題提起と解決策の概要
⇒本記事が該当（４）当方が遭遇した派生開発の問題と解決策の概要
２部 レポートの詳細－－－－－－－－－－－－－－
（５）レポート内容
（３）ＸＤＤＰでの問題提起と解決策の概要
前回までに派生開発の技術面、プロジェクト面の特徴を見てきた。
その結果、開発期間が短い、品質が新規開発と比較して悪い、といったような状況が確認できた。
今回は、派生開発の１つであるＸＤＤＰでは、どのような問題点を認識し、どのような解決策を提案しているのかを概観する。なおＸＤＤＰの内容については当方の理解の範囲内で概説するため、詳細は異なっている部分もあると思う。この点は書籍等で確認をして頂きたいと考える。
※スライドをいくつか見ながら概説をする。スライドをまとめたものは、本エントリの末尾からダウンロード可能。
１．ＸＤＤＰの概要
清水氏が提唱しているＸＤＤＰの概要。派生開発推進協議会のサイトを参照してもらえると、より詳細な情報が得られる。
⇒派生開発推進協議会はこちらから
２．ＸＤＤＰで想定する問題点
ＸＤＤＰで想定する、現状の派生開発の問題・課題をリストアップする。
結果的に母体システムを十分に理解することができないため、母体への影響箇所の把握が漏れてしまう、ということが品質不良の根本原因だとしている。
次に、ＸＤＤＰで想定している現状の派生開発プロセスには何があるのかを見ていこう。
３．ＸＤＤＰで想定している現状の派生開発プロセス
ＸＤＤＰで想定している現状の派生開発を示す。「現状の」ということは、問題が含まれている開発プロセスであることを示す。
・開発プロセスがないパターン
ＸＤＤＰで想定している、現状の派生開発プロセスの１つがこれだ。
これは、変更要求（文書または口頭などでの変更依頼と考えてよい）が到来したら、ソースをいきなり読み始め、変更になりそうなソースを見つけ次第にどんどん修正してしまう、というプロセス（といえるのかどうか）である。
変更になりそうなソースが見当たらなくなるか、もしくは時間切れ？になると、そこで変更は終了というわけである。
あまりにもお粗末なプロセスであり、こんなプロセスで開発を行っている組織があるのか疑問を抱いてしまうが、清水氏がコンサルティングしてきた結果について述べているということは、おそらくこのようなプロセスの組織が多いのだろう。
このプロセスを採用することの問題点は以下である。
このようなプロセスで開発をしていたら、ソースの変更理由をレビューで第三者が把握することも難しくなり、有効な指摘も行いにくくなる。
そもそも変更内容の妥当性はどのプロセスで保証されるのであろうか。
当方が見る限りでは、これは本当に最悪パターンである。
このような組織に対してであれば、ＸＤＤＰを採用するまでもなく、もう少しまともな何かしらのプロセスを採用しただけでも品質は向上しそうだと思ってしまう。
・新規開発崩し
もう１つの現状の派生開発プロセスがこの「新規開発崩し」である。
当方の感覚では、このような新規開発（ウォーターフォール）の開発プロセスを採用している組織がほとんどなのではないかと考える。当方も、今回の派生開発プロジェクトを行うまでは、この「新規開発崩し」で行っていた。
このプロセスを採用することでの悪影響は以下である。悪影響については、２点ほど当方の考えを追記している。
ＸＤＤＰの書籍には明記されていないが、当方が新規開発崩しを採用することの最も悪い影響は、新規開発のように工程を上流から区切って開発を行うことだと考えている。
工程を区切って派生開発を行うと、上流工程では下流工程の成果物（例えば詳細設計書やソースコードなど）をインプットしないままに設計を行うことになる。
しかし派生開発は、母体がすでにソースコードまで存在しており、ソースコードの内容を理解しないままに勝手気ままに設計をすることは、不要な手戻りを発生させる。
もちろん、ドキュメントに全ての詳細事項が記載されていれば問題ないケースもあろうが、実際には母体システムの既存ドキュメントの内容は不十分である。その結果、設計書とソースコードの内容が一致していない、といったことが往々にして発生する。
こうした場合、誤ったドキュメントをベースに開発・設計したとしても、製造工程でソースコードを参照したときに、これまでの設計内容は妥当ではないことが判明してしまう。これは大変に大きな手戻りになってしまう。
４．ＸＤＤＰで提唱する派生開発プロセス
これがＸＤＤＰで提唱する開発プロセスである。
ＰＦＤという手法で記載されているが、○がプロセスでそれ以外が成果物である、というだけで特に難しい内容ではない。
プロセスにおいて特徴的なのは、新規開発では当然に存在する開発工程がないことだ。
ＸＤＤＰで想定しているプロセスは、まず変更要求が発生したら、変更要求をブレイクダウンし、変更仕様をまとめ変更要求仕様書として記載する。
次に、変更仕様に対応する変更箇所（ソースファイルと関数）を特定する。次に、変更が特定された関数の変更設計書（差分設計書に相当するもの）を記載し、最後にソースコードを修正する、というプロセスである。
上流工程の設計書類については、テストが完了してから更新を行う、ということを提唱している。このため、製造工程に相当するプロセスのみの定義となっている。
これは、前述した現状の派生開発のプロセス（開発プロセスがないケース）に似ている。しかし、いきなりソースコードを変更するのではなく、変更要求をしっかりと対応する仕様にブレイクダウンして要求分析をし、そのブレイクダウンされた変更仕様の１つ１つに対して、ソースコードのどこが変更になるのかを調査する。
この時には、ソースコードはもちろん既存ドキュメントも含めて参照するため、開発工程の上流から下流までの全ての成果物を一緒くたに参照することになる。
結果的には、開発工程で区切らないプロセスになっており、前述した当方が最も悪影響を及ぼすと考えている問題にも対応できている。
５．ＸＤＤＰで定める成果物
成果物は最低限のものだけを規定している。成果物をしっかりと作成することで、レビューでの指摘が行いやすくなり、品質を確保できることを狙っている。
６．ＸＤＤＰを適用することでの効果
これらのプロセスを採用した結果目指す効果の概要をまとめた。
この結果、現状の開発プロセス及び新規開発崩しを採用することで発生していた問題について解消することが可能になる。現状の派生開発プロセスを用いることでの問題点について、解決策をもたらしていることがわかる。
７．ＸＤＤＰに関する疑問点
最後にＸＤＤＰの成果物、プロセスなどについて疑問点をまとめてみた。
まずＸＤＤＰの成果物に関連した疑問点をリストアップし、自分で調査できる範囲で調査結果をまとめた。
同様にＸＤＤＰのプロセスに関連した疑問点をリストアップし、自分で調査した結果である。これらのうちのいくつかは、現時点では疑問が解消されているが、資料の作成当時の内容をベースに記載している。
今後も周辺領域の研究が進められることで、より適用範囲が広がっていくと思う。
以上がＸＤＤＰの概要である。
簡単に言うと、
- 変更要求に対して漏れのない要求分析を行う（変更要求から変更仕様へのブレイクダウン）。
- 変更仕様の１つ１つについて、どのソースのどこを変更するのかを、追跡可能な状態でドキュメント化する。
- ドキュメント化によってレビューでの指摘や気付きを誘発しやすくなり、品質確保が可能になる。
といったことを実現するためのプロセスであり、かつ作成する成果物のフォーマットなどにも細かな配慮や工夫が詰まっており、特にレビューによって設計誤りや漏れに気付きやすくする効果を狙っている。
次回は、当方の担当した派生開発プロジェクトで遭遇した問題と、解決策の概要について見ていく。
今回紹介したスライドをまとめてダウンロードする場合はこちらから。
⇒xddp_overview_vsn.0.1.pdf(724KB)
