ＩＴ経営屋さんの学問のすすめ派生開発プロセスの工夫（その８）

派生開発プロセスの工夫（その８）

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

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

論述対象となるプロジェクト、および開発プロセスの特徴: ・組込み系の社会インフラを担うミッションクリティカル・システム。; ・信頼性・成熟性について高い品質が求められている。; ・稼働直前の総合テストからプロジェクトを引き継ぎ。; ・母体システムのドキュメントが不足、母体品質も悪い。; ・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。

エントリ内容の目次

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

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

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

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

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

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

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

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

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

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

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

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

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

前回は、当方が派生開発プロジェクトで遭遇した４つの問題のうち２つを述べた。今回は残りの２つを述べる。

（３）対処の結論だけが資料に記載されており、結論を導くまでの設計者の思考過程がわからないため、レビューで対処内容の妥当性の検証が困難で、欠陥の流出が発生した

●問題内容と原因

（１）と（２）の問題に対処することで、ある程度の設計品質を確保できるようになった上で、更に設計品質を高めるために解決が必要となった問題である。本問題の原因は、担当者が検討した結果のみを資料に記載していることである。

欠陥修正の対処方法を、母体ドキュメントやソースコードを調査して、対処検討資料としてまとめるが、その際に、検討した結果のみを記載する傾向が多かった。

もちろん、レビューアが母体システムについて熟知しているのであれば、その結論だけを見て、検討結果の妥当性を判断することもできよう。

しかし部分理解の制約があるため、どうしても検討結果だけを見ても、“なぜその結果が導かれたのか”、“なぜその結果が妥当といえるのか”を判断できないことが多い。

このためレビューアが、その結論を導いた理由や、問題がない理由、どこまで調査して判断したのか、といったことをヒアリングすることになる。

そこで明確な回答があればまだ判断できるが、実際には担当者も自分自身がどのような考えで、どのような手法で、どこまで調査したのかを、明確に覚えていないことが多い。特に複雑な案件だと、調査をして１つの事実を証明し、その事実に基づいて次の調査や検討を行う、といったように大量の調査が必要になるため、すべての調査内容を覚えておく事は不可能である。

レビューアとしては、資料上の結論が、妥当と思える内容を調査した結果導かれたものであることを確認しなければならない。そうなると、調査のやり直しを行うか、もしくは少ない情報のみでレビューアが意思決定をせざるを得ないといった状況が発生する。

このことが、手戻りの発生や、欠陥の流出を招く。少ない情報だけで意思決定を行う事は明らかにリスクである。このリスクを早期に軽減し、手戻りや欠陥流出を防止することが必要であった。

●得られた教訓

設計者の頭の中にある検討過程をきちんとドキュメントに展開しなければ、結論の正しさは検証できない。

ドキュメントは、結論よりも、むしろ検討過程の妥当性を検証できるべきである。また、単に検討過程を記述しただけでは、検討すべき事項に漏れがないのかをレビューアが確認することができない。

つまり、検討過程で漏れなく検討ができていることを保証できる資料作りが必要である。これは、ドキュメントが持つアカウンタビリティ（説明責任能力）を高めることと同義である。

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

プラクティス３
・ドキュメントのアカウンタビリティ強化

（４）設計段階では影響を想定していなかった処理について、テスト工程で範囲を広げてテストしたところ、関連する欠陥が多発した

●問題内容と原因

本問題は、欠陥対応に関する適切なスコープ・マネジメントが存在していなかったことが原因である。

本問題は、派生開発の中でも比較的対処規模の大きい案件や、対応が難しい案件で発生する傾向があると考えている。

当該プロジェクトでの具体的な事例で説明を行う。当該プロジェクトのシステムは、デュプレックスシステム（ホットスタンバイ方式）を採用しており、本番系に障害が発生した場合は、自動的に待機系に切り替えるフェイルオーバ動作を行う。

ただし、本番系システムのＯＳが異常停止した場合に、本番系がサービス停止状態であることを待機系が検出するまでに長時間がかかってしまい、結果的にシステム全体がサービス中断状態になることが問題とされた。

この問題への対処として、システムのＯＳが異常停止した時限定の処理として、待機系から本番系の運転状態を監視する処理と、待機系を強制的にアクティブ（本番系）に切り替える対処を盛り込んだ。

本案件の結合テストに差し掛かる段階で、ＯＳの異常停止時以外の場合でも、ホットスタンバイ動作が正常に動作するのかを検証することになり、様々な障害を発生させるテストケースを作成し、テストを行った。

この結果、ホットスタンバイ動作が正常に動作しないケースが、ＯＳの異常停止時以外にも複数あることが判明し、それぞれ緊急に対処を行うこととなった。このときは納期も延長できなかったため、残業によって対応を行い、プロジェクト運営はかなり混乱した。

なぜこのような混乱が生じたかというと、原因は当初の作業スコープが狭すぎたことによると考えている。

具体的な問題事象がＯＳの異常停止時だったため、設計時点ではその作業スコープに限定していた。これに対し結合テスト時点では、作業スコープをフェイルオーバ動作全体に拡大した。

これにより、実際に設計を行ったスコープと、テストで検証したスコープに差異が発生し、設計を行っていなかったスコープで類似欠陥が摘出された。

もし当初の設計時点において、ＯＳの異常停止時だけでなく、フェイルオーバ動作全体の正常性を保証するという広い作業スコープを設定していたのならば、検討や調査する内容が増加するため、当初から作業量やスケジュールも全く違ったものになっていた可能性が高い。そして、結合テストで摘出した欠陥を上流工程で早期に摘出できていた可能性も否定できない。

●得られた教訓

派生開発における欠陥是正は、問題となっているのが個別具体的なケースであるため、その問題対処をすぐに行いたくなる誘引が働く。

しかし、摘出した欠陥と類似する欠陥が母体システムに潜在している可能性は高いため、顕在化している欠陥のみを対処しても、システム全体としては対処が不足してしまうことがある。

そのため、一旦問題の水平展開をするなどして作業スコープを拡大し、調査することが必要だったと考える。最上流で決定する作業スコープが変われば、設計・実装のインパクトも大きく変わる。最上流の作業スコープをしっかり検討することが、計画的なプロジェクト運営と、品質の確保につながる。

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

プラクティス４
・超上流でのスコープ・マネジメント強化

以上までに、我々が認識した派生開発の特徴に起因する問題と、そこから得られた教訓について述べた。

次章からは、これらの教訓から導いたプラクティスと、プラクティスを実践するためのプロセスについて述べる。

我々のプラクティスとＸＤＤＰの研究成果において、いくつか一致する部分が見られる。
こうした一致は、我々のプラクティスの方向性が誤っていないことを裏付けるものと考えている。

できるだけＸＤＤＰとの類似点や相違点を明らかにしながら、これらのプラクティス、プロセスについて述べていく。そうすることで、今後ＸＤＤＰを導入する際に、併せて本プラクティスとプロセスを検討できるようになり、プロジェクト特性に応じたプロセスの選択の幅が広がると考えている。

次回は、設計品質の確保に効果のあった派生開発プロセスの工夫について述べていこう。

関連記事