CMMIの要件管理 プロジェクト管理の仕組み (その2)

更新日

投稿日

 前回のその1に続いて、今回は、CMMIの要件管理です。CMMI では次のこと(特定プラクティスといいます)ができている必要があります。
 
 (1) 要件の理解を獲得する
 (2) 要件に対するコミットメントを獲得する
 (3) 要件変更を管理する
 (4) 要件に対する双方向の追跡可能性を維持する
 (5) プロジェクト作業と要件の間の不整合を特定する
 
 どの項目も「やっている」と答えることができる開発現場が多いと思います。しかし、上記の (4) (5) を満足するためには要求仕様に対して『適切な実現性検討』が実施できている必要があり、実際のところ、十分にできているところは多くはありません。
 
 『適切な実現性検討』ができているということは、要求仕様(外部機能仕様)が希望機能一覧表ではなく、実現妥当性の検証ができているということです。この連載で何度か触れている「できた成り型開発」や「ベストエフォート型開発」では駄目です。「できた成り型開発」というのは、リリース時にできていることが製品仕様になるような開発です。最大限の努力をしたのだから、結果的にできあがったものが製品仕様になる開発スタイルということもできます。このような開発スタイルは多くの開発現場で見ることができるのですが、実現性検討が不十分なまま製品開発を進めているということに他なりません。
 
 適切に実現性検討が行われている状態とは、要求仕様の一つひとつに対する製品内部の振る舞いが確認できるということです。製品内部の振る舞いによる裏付けがある要求仕様が、実現性検証ができている要求仕様なのです。
 
 ここで、要素技術開発における実現性検討と製品開発における実現性検討はそのアウトプットは大きく違うことに注意してください。ここで話題にしているのは、製品開発における実現性検討であり、要求仕様の一つひとつに対する製品内部の振る舞いが文書で確認(追跡)できることと、製品内部の機能ユニット/モジュール/ブロックの一つひとつが関係している要求仕様を文書で確認(追跡)できることが要求されます。これが「双方向の追跡可能性を維持」しているということです。
 
 「双方向の追跡可能性維持」を断片的に設計文書化しているところはありますが、適切に実施できているところは QFD(品質機能展開)関連の手法・技法を導入しているか、少なくとも図32のようなマトリクスが設計文書に含まれているはずです。これを製造業ではあまり見かけることはありません。
 
                   R&D
図32.要求仕様と内部構成の双方向追跡を可能とする設計文書
 
 ところで、『適切な実現性検討』ができていれば、仕様変更や設計変更に強い開発になります。図32のような設計文書があれば、仕様変...
 前回のその1に続いて、今回は、CMMIの要件管理です。CMMI では次のこと(特定プラクティスといいます)ができている必要があります。
 
 (1) 要件の理解を獲得する
 (2) 要件に対するコミットメントを獲得する
 (3) 要件変更を管理する
 (4) 要件に対する双方向の追跡可能性を維持する
 (5) プロジェクト作業と要件の間の不整合を特定する
 
 どの項目も「やっている」と答えることができる開発現場が多いと思います。しかし、上記の (4) (5) を満足するためには要求仕様に対して『適切な実現性検討』が実施できている必要があり、実際のところ、十分にできているところは多くはありません。
 
 『適切な実現性検討』ができているということは、要求仕様(外部機能仕様)が希望機能一覧表ではなく、実現妥当性の検証ができているということです。この連載で何度か触れている「できた成り型開発」や「ベストエフォート型開発」では駄目です。「できた成り型開発」というのは、リリース時にできていることが製品仕様になるような開発です。最大限の努力をしたのだから、結果的にできあがったものが製品仕様になる開発スタイルということもできます。このような開発スタイルは多くの開発現場で見ることができるのですが、実現性検討が不十分なまま製品開発を進めているということに他なりません。
 
 適切に実現性検討が行われている状態とは、要求仕様の一つひとつに対する製品内部の振る舞いが確認できるということです。製品内部の振る舞いによる裏付けがある要求仕様が、実現性検証ができている要求仕様なのです。
 
 ここで、要素技術開発における実現性検討と製品開発における実現性検討はそのアウトプットは大きく違うことに注意してください。ここで話題にしているのは、製品開発における実現性検討であり、要求仕様の一つひとつに対する製品内部の振る舞いが文書で確認(追跡)できることと、製品内部の機能ユニット/モジュール/ブロックの一つひとつが関係している要求仕様を文書で確認(追跡)できることが要求されます。これが「双方向の追跡可能性を維持」しているということです。
 
 「双方向の追跡可能性維持」を断片的に設計文書化しているところはありますが、適切に実施できているところは QFD(品質機能展開)関連の手法・技法を導入しているか、少なくとも図32のようなマトリクスが設計文書に含まれているはずです。これを製造業ではあまり見かけることはありません。
 
                   R&D
図32.要求仕様と内部構成の双方向追跡を可能とする設計文書
 
 ところで、『適切な実現性検討』ができていれば、仕様変更や設計変更に強い開発になります。図32のような設計文書があれば、仕様変更が生じたときに製品内部のどこの振る舞いを確認する必要があるのか、設計変更が生じたときに要求仕様のどこを確認する必要があるのかがわかるからです。要件管理の仕組み進化・深化は大きな効果につながることがわかります。
 
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
製品設計:ミス防止対策(その5)

【製品設計:ミス防止対策 連載目次】 1.  お客様目線で行う製品設計、「未然防止の品質管理」 2.  過去のトラブル、フィー...

【製品設計:ミス防止対策 連載目次】 1.  お客様目線で行う製品設計、「未然防止の品質管理」 2.  過去のトラブル、フィー...


ベンチャーのように考える 新規事業・新商品を生み出す技術戦略(その69)

◆ 社内ベンチャーを目指す 1、Withコロナ時代に求められるR&D  2020年6月現在、新型コロナウィルスにより世界中の経済が影響を受...

◆ 社内ベンチャーを目指す 1、Withコロナ時代に求められるR&D  2020年6月現在、新型コロナウィルスにより世界中の経済が影響を受...


自社の強みとは 『価値づくり』の研究開発マネジメント (その23)

   前回は、オープンイノベーションを成功させるためのビジネスモデルの必要性を解説しました。今回は、自社の強みの設定について議論したいと思...

   前回は、オープンイノベーションを成功させるためのビジネスモデルの必要性を解説しました。今回は、自社の強みの設定について議論したいと思...


「技術マネジメント総合」の活用事例

もっと見る
設計部門の仕組み構築(その3)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...


設計部門とリスク管理(その1)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...


進捗の見える化:第2回 プロジェクト管理の仕組み (その11)

 進捗の見える化ですが、前回のその10に続いて解説します。今回考えるべきポイントは、可視化・見える化の方法です。図40 に示しているように、進捗管理では予...

 進捗の見える化ですが、前回のその10に続いて解説します。今回考えるべきポイントは、可視化・見える化の方法です。図40 に示しているように、進捗管理では予...