品質確保に効果のあった派生開発プロセスの工夫（その５）
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。
- 論述対象となるプロジェクト、および開発プロセスの特徴
- ・組込み系の社会インフラを担うミッションクリティカル・システム。
- ・信頼性・成熟性について高い品質が求められている。
- ・稼働直前の総合テストからプロジェクトを引き継ぎ。
- ・母体システムのドキュメントが不足、母体品質も悪い。
- ・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。
エントリ内容の目次
内容はかなり長くなるため、順を追って述べる。
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒記事はこちら１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
⇒Ｐａｒｔ１
⇒Ｐａｒｔ２（３）ＸＤＤＰでの問題提起と解決策の概要
⇒記事はこちら（４）当方が遭遇した派生開発の問題と解決策の概要
⇒本記事が該当２部 レポートの詳細－－－－－－－－－－－－－－
（５）レポート内容
（４）当方が遭遇した派生開発の問題と解決策の概要
前回は、派生開発プロセスの１つであるＸＤＤＰの概要を見てきた。
今回は当方が遭遇した派生開発プロジェクトにおける問題点と対処策の概要を見ていく。
ここで述べる内容は、まだＸＤＤＰの存在を知らなかった時点で行ったものである。
１．当該派生開発プロジェクトの特徴
以下のスライドでは、対象となる派生開発プロジェクトの概要と、引き継いだ母体システムの品質が悪い状況を述べている。
母体システムはドキュメント密度、レビュー密度、テスト項目密度などの品質管理指標が軒並み低かった。
また市販の静的解析ツールでソースコードの複雑度を測定したところ「保守不能」レベルの複雑度であることが判明した。
２．派生開発プロジェクト開始時点の開発プロセス
当初我々が採用していた開発プロセスである。一般的なウォーターフォール型の開発プロセスであり、ＸＤＤＰでいうところの「新規開発崩し」である。
欠陥修正においては、欠陥が作りこまれた最上流の工程から順番に作業を行う。欠陥の内容によっては、方式設計での混入のケースもあれば、軽微な製造レベルでの欠陥のケースもある。なので、毎回開始する工程は異なってはいるが、最も上流の工程から開始する点は同じである。
上記の開発プロセスをさらに細分化したプロセスが以下である。
特に変わり映えのないウォーターフォール開発である。
３．派生開発で遭遇した問題・課題
・プロジェクト序盤に遭遇した問題
プロジェクト初期に遭遇した問題とその原因である。
特に影響が大きかったのは、ウォーターフォール開発であるため、上流工程では下流工程の成果物であるソースコードの調査を十分にしないまま開発を進めていたため、後工程で欠陥が多発してしまった点である。
後になってソースコードを読むほどにドキュメントでは把握できない「暗黙の制約」が出てくるため、これらの制約を理解し直してから設計にフィードバックするという手戻り作業が膨大に発生してしまった。
これを改善するためには、上流工程で下流工程の作業を先取り実施するフロントローディングが必要であると感じた。
あとは、母体ドキュメントの不備によって、工程間のドキュメントのトレーサビリティが確保されていなかったために、基本設計書で述べている機能や動作仕様が、詳細設計書ではどのように落とし込まれているのかを追跡することができなかった点である。
不備なドキュメントだけをインプットとして設計してしまったのでは、アウトプットされる内容も不備なままである（ガベージイン・ガベージアウト）。
これを改善するためには、ドキュメントが不足しているならば、その不足箇所をリバースエンジニアリングすることでドキュメントを書き起こし、トレーサビリティがしっかりと確保された状態で設計を行うことが必要であると感じた。
・プロジェクト中盤に遭遇した問題
更にプロジェクト中盤ころに遭遇した問題とその原因、気付きをまとめたものである。
欠陥修正案件を行っているため、どのように修正を行うかを示す資料は、基本的はフリーフォーマットであった。
その資料は、対処の結論だけが述べられており、その結論が妥当であるのかどうかを資料内容から確認することが困難であった。
そのため、レビューで設計者に「どこまで調査して結論をだしたのか？」「なぜこの結論が妥当なのか？」をヒアリングしなければならない。
しかし設計者は、その調査過程について資料化していなかったために、どこまで調査したかを忘れてしまっており、調査のやり直しの手戻りが発生したり、時にはリスクがあるとは知りつつも納期の関係上、詳細な調査を省いたまま対処内容を決定したりしていた。
フリーフォーマットに頼った成果物の作成方法だと、明らかに非効率やリスクを含んでいるため、ドキュメントの作成手順や手法を定め、ドキュメントに網羅性・妥当性・追跡性を与えることで、第三者でも結論の妥当性を検証できるように工夫した。この工夫を、ドキュメントのアカウンタビリティ（説明責任能力）の強化と呼んだ。
もう１つが、作業スコープに関する問題である。
欠陥修正案件は、どうしても個別具体的な欠陥事象への対応をするため、類似欠陥の存在や、対処の有効範囲の検証を行わずに、すぐに問題への対処を行ってしまいたい、という誘引が働く。
あわてて対処案を検討してしまったがために、テスト工程などで対処不十分であることが判明したり、対処によってグレードを誘発したりするなどの問題が発生した。よって、すぐに対処をするのではなく、上流工程の開始前（超上流）にて、対処スコープをしっかりと関係者と協議し合意した上で対処案の検討を行うようにした。
４．４つのプラクティスの概要
４つのプラクティスの概要をまとめたものである。
１．フロントローディング強化
フロントローディング強化で実現したい課題は、ドキュメントだけではソフトウェアの制約事項を把握できないことから、下流工程に進むにつれて調査工数が増大する手戻りのリスクを軽減することである。
２．ドキュメントのトレーサビリティ強化
ドキュメントのトレーサビリティ強化で実現したい課題は、１つは既存の工程別の成果物（ドキュメントなど）の間に、適切な追跡可能性を与え、工程間を通じた設計内容の妥当性を確認することである。
２つ目は、工程間で成果物の変更箇所に漏れ・誤りがないことを保証することである。
３．ドキュメントのアカウンタビリティ強化
ドキュメントのアカウンタビリティ強化で実現したい課題は、部分理解の制約の中でも、レビューアが設計内容の妥当性を検証することが可能になるようなドキュメントを作成することである。
４．超上流でのスコープ・マネジメント強化
超上流のスコープ・マネジメント強化で実現したい課題は、変更要求に対して具体的な対処を検討する前に、一旦、変更要求で求められている真の要求は何かを確認し、対処の漏れを事前に防止することである。
５．本施策で解決を目指す内容
本施策では次の問題の解決を目指す。
プラクティスの具体的な内容までは踏み込んで理解はできないと思うが、やりたいことは理解して頂けたかと思う。具体的な内容については、レポートの詳細にて述べるので、そちらを参照されたい。
６．本施策の限界
本施策の限界やデメリットなどについてまとめた。
以上が当方で行った開発プロセスの工夫の概要である。
この工夫を実際に行っていた時点ではＸＤＤＰの存在は知らなかったのだが、類似する施策がいくつか含まれている。
開発プロセスの工夫を簡単に言うと、
- 上流工程で下流工程までの成果物をインプットして、前倒しで調査（フロントローディング）することで、「暗黙の制約」を早期に把握する。
- 既存ドキュメントの不足部分はそのままにせず、リバースエンジニアリングを行って不足部分を補ってから設計し、ドキュメント間のトレーサビリティを確保する。
- 欠陥修正の対処内容の検討では、結論だけを述べずに調査過程もすべてドキュメント化することで、ドキュメントの説明能力を高め、レビューの効率化・調査漏れの早期発見を行う。
- そもそもの対処スコープを誤ると、その後の作業が全て無駄になってしまうため、すぐに対処案の検討を行うのではなく、この案件では欠陥の発生状況をどこまで救うのか、類似欠陥については同時に対処するのか、といった作業スコープを明確にする。
といった内容である。
レビューでの気付きの誘発という効果も期待できるが、それよりも、このプロセスや成果物の作成手法に準拠することで、設計者本人が設計している段階で調査漏れなどに気付きやすくなる効果を第一に想定している。
なぜなら当該プロジェクトは有識者が不在で、レビューアもシステムについては理解が十分ではなかったことが挙げられる。
ＸＤＤＰでは、有識者が不在であることは想定していないため、この点が開発プロセスの工夫の方向性の違いとして出ている。
レポートの詳細では、成果物の作成手法などの細かな内容まで記載しており、できるだけ誰でも同じ成果物を作成できるように工夫をしている。その辺りの詳細については、次回から述べるレポート内容をご参照いただきたい。
ＸＤＤＰとの類似点や異なっている点についても対比させて記載をしている。
今回紹介したスライドをまとめてダウンロードする場合はこちらから。
⇒process_overview_vsn.0.1.pdf(803KB)
