品質確保に効果のあった派生開発プロセスの工夫（その１）
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
以下に要約を示しますので、ご興味があればどうぞ。
本シリーズ・エントリの要約
システム開発プロジェクトは、その約４割もが派生開発プロジェクトである(*1)。派生開発とは母体システムへの機能追加・変更、欠陥是正の対応を行う開発・保守プロジェクトのことである。
派生開発は新規開発とは異なる特徴がある。例えば、母体システムを全て理解する時間がないことや、度重なる改修でソースコードが保守しにくくなっていること、変更によるデグレードを考慮しなければならないこと、などがある。
こうした派生開発の特徴に応じた開発プロセスを採用しないと、品質確保を効率的に行うことが難しい。実際にソフトウェア開発企業では、ソフトウェア品質不具合に起因する品質問題の再発防止策については、「ソフトウェア開発プロセスの見直し」が重要であると認識している(*2)。
このように、派生開発が増加している一方、派生開発の特徴に対応した開発プロセスが浸透していないことが、品質確保の上で問題視されている。
我々は派生開発の実地経験を基に、開発プロセスの工夫を試みた。その結果、設計品質の確保に効果があったと考えられる４つのプラクティス（慣行）をプロセスとして汎化し整理した。
プラクティスは、
- ドキュメントのトレーサビリティ強化
- フロントローディング強化
- ドキュメントのアカウンタビリティ強化
- 超上流でのスコープ・マネジメント強化
の４つである。
この４つのプラクティスを適用することで、いくつかの派生開発特有の課題を解決できると考えている。ただし実地経験を基に作成したプロセスではあるが、まだ実証が充分ではない。この点は今後の課題とし、他プロジェクトへの適用を通じて検証を継続していきたい。
内容についてご批評を頂ければ幸甚である。
(*1)独立行政法人 情報処理推進機構, 2012年度「ソフトウェア産業の実態把握に関する調査」調査報告書(2013/04/26)のP53/P123 Q2-3 2011会計年度のソフトウェア開発プロジェクトの内訳 を参照。
(*2) 独立行政法人 情報処理推進機構, 2012年度「ソフトウェア産業の実態把握に関する調査」調査報告書(2013/04/26)のP79/P150 Q5-5 ソフトウェア不具合に起因する品質問題の再発防止策 を参照。
- 論述対象となるプロジェクト、および開発プロセスの特徴
- ・組込み系の社会インフラを担うミッションクリティカル・システム。
- ・信頼性・成熟性について高い品質が求められている。
- ・稼働直前の総合テストからプロジェクトを引き継ぎ。
- ・母体システムのドキュメントが不足、母体品質も悪い。
- ・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。
エントリ内容の目次
内容はかなり長くなるため、順を追って述べる。
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒本記事が該当１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
（３）ＸＤＤＰでの問題提起と解決策の概要
（４）当方が遭遇した派生開発の問題と解決策の概要２部 レポートの詳細－－－－－－－－－－－－－－
（５）レポート内容
（１）このレポートの概要と背景について
本レポートは、派生開発プロジェクトにおいて、上流工程での品質確保に効果のあったと考える開発プロセス上の工夫についてまとめたものである。派生開発の中でも、特に母体システムの欠陥修正（改修）案件における開発プロセスについて焦点を当てて述べている。
要約に示しているように、まだ効果を検証中の段階であり、工夫や施策の内容も日々変化し続けている。よって定量的な数値での効果を述べることは現段階では避けたいが、品質確保に効果があることを実感として持っている。
また派生開発プロセスの１つであるＸＤＤＰについても、今後ますます研究や活動が活発になってくると思われるため、システム開発の現場で同じような問題意識や課題をお持ちの方には、何かしら参考になる内容もあるのではないかと考えている。
当方が携わった派生開発プロジェクトの概要
対象となった派生開発プロジェクトの概要について述べる。
我々の受託したプロジェクトは、他の組織で開発された当該システムを、本番稼働直前に実施される総合テストから引き継ぎ、システムの改修・保守を行うものである。組込み系の社会インフラを担うミッションクリティカル・システムで、信頼性や成熟性（不具合のない状態）について高い品質を求められている点が特徴である。
プロジェクトでは、総合テストの実施、および積み残された機能追加案件の対応、残存欠陥の修正を行った。母体の開発ドキュメントの不備・不足によって母体動作理解が難しい、母体が不十分なレビューとテストで品質が悪い、ソースが複雑で理解しにくい、といった特徴があった。
プロジェクト運営の状況
引き継いだ母体システムには多量の欠陥が混入しており、母体欠陥の改修に多くの工数を要した。
欠陥の内容は、ドキュメント内容を正しく実装できていない、といった実装誤りのような比較的軽微なものから、設計漏れ、仕様誤りなどの影響の大きい欠陥も含まれていた。後に母体の混入欠陥数を分析すると、他の類似プロジェクトと比較して多くの母体欠陥が潜在していたことがわかった。
欠陥の修正のために対処案の妥当性を調査していると、そこで別の母体欠陥が摘出される、といった状況が続いた。このため、対処案の検討時点で影響範囲の調査漏れがあると、すぐにデグレードや考慮漏れによる設計誤りなどの結果として表れる。
こうした経験から、事前に影響を及ぼす範囲を含めて広く調査することや、水平展開をして類似する欠陥が潜在してないかを調査することが、デグレードや手戻りの発生を抑え、品質確保に効果があるということを学んだ。
システムはすでに本稼動を開始していたが、並行してこれらの欠陥修正を行い、段階的リリースを行った結果、本番稼働環境で大きな不具合の発生もなく、許容できる品質水準に到達することができたと考えている。
ＸＤＤＰとの出会い
欠陥対応がひと段落付いたころ、我々はＸＤＤＰの存在を知った。ＸＤＤＰとは、派生開発に特化した開発プロセスの１つである。
内容を紐解くと、ＸＤＤＰは多くのプロジェクトに導入され効果が確認されていることが分ったが、それよりも我々が工夫した内容と類似している点も多いことに気が付いた。
そこで、一旦我々が行ってきた工夫をプロセスという形にまとめることで、ＸＤＤＰと相互補完関係になる資料を作成すれば、今後の参考になるのではないかと考えた。
今後ＸＤＤＰを採用するプロジェクトも増えてくると思われるため、そういったプロジェクトにおいてもプロセス改善の着眼点として、何らかの示唆を与えられる資料になることを願っている。ＸＤＤＰの研究成果を一歩でも進めることができれば、また、プロジェクトに適用することで品質確保に少しでも貢献できれば幸いである。
今回は以上である。このレポートの背景や目的についてはご理解いただけたと考える。
次回からレポート内容のサマリーについて述べていく。
