顧客の要求を確実に仕様にできる要件定義マニュアル

顧客の要求を確実に仕様にできる要件定義マニュアル

要件定義ってやり方に型がありそうで、ないというのが正直な自分の感想です。MTGで決めること、課題管理、成果物などは、いわゆるプロジェクトごとに、粒度が違うことが多いと思います。いわゆる要件定義の出来、不出来で、プロジェクトの成熟度が求められるのだと思います。実は、これは成果物の完成度ではなくて、開発者、発注者との仕様の共有だと思います。

・理論編 要件定義とプロセスについての基本的説明
・モデリング編 事例を使ったモデル作成例の説明
・実践編 プロジェクトの特性に合わせた活用方法の説明
・リファレンス編 モデリングとプロセスの詳細説明

このような感じで、システムの要件定義をうまく行うためについて書かれています。ただ、前提としてUML表記についての素養がある人達限定です。顧客もいわゆる大手でシステム部門を持っているような案件での、やり方になるのかもしれません。手法やすすめ方の参考になると思います。
　
システム開発において、要件の共有をうまくやるにはどうすればいいんだろうか？と考えると、結局は、何回もイテレーションしていくしかないんじゃないかと思います。どうしてもスナップショット的に、仕様を決定していくと、時間が経つと陳腐化していたり、間違いにきがついて、戻り作業が発生しています。しかし気をつけたいのは、アジャイル開発などで、手戻り前提で考えればいいと思ってやると、そもそも毎回きっちり皆で、頭に汗をかかないといけないのに、手戻り前提で、手を抜いてしまい、結果最悪なことになるパターンも無きにしも非ずです。アジャイル手法と言っておいて、実は単に、何回も同じことを繰り返しているだけ。みたいな事もあったりするのではないでしょうか。
　
手法ややり方自体は問題ではなく、仕様などが決まらないことが悪であり、モデリングやプロセスも結局は、その仕事に携わる人達とのコンセンサスがないとうまくいかないのではないかと思います。
　
こんな手間のかかる開発スタイルは、これから一体どうなっていくのでしょうか？すぐにはなくなるとは思いませんが、誰もがシステムに対して素養が出てきたり、システムのインターフェース、仕様や使い方について、ある一定の水準になったときにでも、現在のような仕様に関する、合意形成の仕組みは必要になるのでしょうか。。ある一定のレベルに皆がなった時には、また違う段階の合意形成が必要になってくるのだとは思いますが。