米国国防総省がソフトウェア開発における品質、生産性の向上、工期短縮などのニーズを満たし、ソフトウェア開発の活動をより高度なレベルに高めるためために、カーネギーメロン大学にソフトウェアの下請業者を客観的に評価する基準として使えるモデルを作る研究を依頼し、能力成熟度モデル（CMM: Capability Maturity Model）が開発されました。（1989年）
CMMはその後も改訂・更新を経て、現在では改訂版である CMMI（能力成熟度モデル統合、Capability Maturity Model Integration）になっています。
「要件定義」のカテゴリーでなぜ「能力成熟度モデル」について書くのかと言うと、この能力成熟度モデルは、ソフトウェア業界のみならずすべての組織に当てはまるからです。
組織の成熟度とその特性（出典：株式会社コンピータジャパンのHPより）
|
成熟度レベル |
特性 |
|
|
レベル１ |
初期 |
ソフトウェアプロセスは場当たり的、時には混沌としたものと特徴付けられる。ほとんどのプロセスは定義されておらず、成功は個人の努力に依存する。（業務の属人化） |
|
レベル２ |
反復できる |
コスト、スケジュール、機能充足性を確認するために、基本的なプロジェクト管理プロセスが確立されている。同様のアプリケーションのプロジェクトに関しては、以前の成功経験を反復するためのプロセス規律がある。 |
|
レベル３ |
定義された |
管理およびエンジニアリングの活動に対するソフトウェアプロセスが、「組織の標準ソフトウェアプロセス」として文書化、標準化、そして統合化されている。ソフトウェアの開発と保守において、承認されテーラーリングされたバージョンの「組織の標準ソフトウェアプロセス」をすべてのプロジェクトが使用する。 |
|
レベル４ |
管理された |
ソフトウェアプロセスおよび成果物品質に関する詳細な計測結果が収集されている。ソフトウェアプロセスも成果物も、定量的に理解され制御される。 |
|
レベル５ |
最適化する |
革新的なアイディアや技術の試行、およびプロセスからの定量的フィードバックによって、継続的なプロセス改善が可能になっている。 |
CMMIに関心を持った方は、ぜひ各レベルの詳細な説明について調査してみてください。
上記の表にある「ソフトウェア」とか「アプリケーション」という言葉を、皆さんの会社の「業務（ビジネス）」に置き換えてみてください。
現代の、そしてこれからの企業活動はITCの支援なくして存続することは困難だと思われます。
「要件定義」を自社で行う力を獲得するためにも組織としての仕事の手順の成熟度を上げ、少なくともレベル３の「定義された」つまり、業務が可視化（文書化）され組織としてそれを常にアップデートしている体制構築が必要です。
多くの企業では、何かプロジェクト（JSox法対応やISO対応等）がある度に、異なるフォーマットで業務プロセスが描かれ、当該プロジェクトの担当部署に「死蔵」されている例が多くはないでしょうか？しかし、本来の業務プロセス（マスターモデル）は現場の標準として作成・保存・アップデートされるべきで、ある部署において問題が発生した時には、関係者はこの「業務プロセス」を共通言語として立ち返って問題解決の方策を議論すべきです。それが組織と業務プロセスの「最適化」に繋がります。「要件定義」を自社で行おうとするときには必ず最新の「業務プロセス」（業務フロー図等）が必要になります。
システム開発において、ＩＴベンダーに丸投げし「要件定義」までベンダーに依存していては、一過性のプロジェクトに終わり、自社内に永続的に利用可能な「業務プロセス」は蓄積されず、社員の能力向上にも繋がりません。経営層の方々には是非自社の成熟度がどのレベルなのか一度考えてみて戴き、自社の業務管理能力の向上に取り組んで戴きたいと思います。
