Club-Zコラム第12回

【第12回】必要なのは仕組みの進化&深化

株式会社RDPi　　代表取締役　石橋　良造

2008.07.24

まず要件管理です。CMMI では次のこと（特定プラクティスといいます）ができている必要があるとしています。

1. 要件の理解を獲得する
2. 要件に対するコミットメントを獲得する
3. 要件変更を管理する
4. 要件に対する双方向の追跡可能性を維持する
5. プロジェクト作業と要件の間の不整合を特定する

どの項目も「やっている」と答えることができる開発現場が多いと思います。しかし、上記の (4) (5) を満足するためには要求仕様に対して適切な実現性検討が実施できている必要があり、実際のところ、十分にできているところは多くはありません。

適切な実現性検討ができているということは、要求仕様（外部機能仕様）が希望機能一覧表ではなく、実現妥当性の検証ができているということです。この連載で何度か触れている「できた成り型開発」や「ベストエフォート型開発」では駄目です。「できた成り型開発」というのは、リリース時にできていることが製品仕様になるような開発です。最大限の努力をした（ベストエフォート）のだから、結果的にできあがったものが製品仕様になる開発スタイルということもできます。このような開発スタイルは多くの開発現場で見ることができるのですが、実現性検討が不十分なまま製品開発を進めているということに他なりません。

適切に実現性検討が行われている状態とは、要求仕様の一つひとつに対する製品内部の振る舞いが確認できるということです。製品内部の振る舞いによる裏付けがある要求仕様が、実現性検証ができている要求仕様なのです。

ここで、要素技術開発における実現性検討と製品開発における実現性検討はそのアウトプットは大きく違うことに注意してください。ここで話題にしているのは製品開発における実現性検討であり、要求仕様の一つひとつに対する製品内部の振る舞いが文書で確認（追跡）できることと、製品内部の機能ユニット／モジュール／ブロックの一つひとつが関係している要求仕様を文書で確認（追跡）できることが要求されます。これが「双方向の追跡可能性を維持」しているということです。

双方向の追跡可能性維持を断片的に設計文書化しているところはありますが、適切に実施できているところは QFD（品質機能展開）関連の手法・技法を導入しているか、少なくとも図32のようなマトリクスが設計文書に含まれているはずですが、製造業ではあまり見かけることはありません。




ところで、適切な実現性検討ができていれば、仕様変更や設計変更に強い開発になります。図32のような設計文書があれば、仕様変更が生じたときに製品内部のどこの振る舞いを確認する必要があるのか、設計変更が生じたときに要求仕様のどこを確認する必要があるのかがわかるからです。要件管理の仕組み進化・深化は大きな効果につながることがわかります。