「要件定義ではなく、要件開発」と唱えてみよう：サバイバル方程式（2/2 ページ）

[増岡直二郎，ITmedia]

能動的な取り組みを加速させる

　ベンダー、ユーザーともに能動的に取り組み、ビジネス価値を向上させるシステムを構築するにはどうすべきか。IT導入成功条件の中で最も実務につながる「要件定義」に対する考え方を、変えなければならないのではないか。

　幸いにして、「要求はあるものではなく、開発するものである」という考え方で、要求開発の体系化を目指す集団「要求開発アライアンス」がある。そこから「要件定義」改革のヒントを得ることができる。これは数年前から出てきている動きだが、その後さまざまな方面から議論されており、今後ますます見逃せないトレンドだ。

　以下、「要求開発アライアンス」の考え方を参考図書から引用、要約しながら「要件定義」のあり方を説明してみよう。お断りしておくが、あくまでも1つの例として取り上げているに過ぎない。

　なぜ「定義」でなくて、「開発」なのか。「定義」という言葉から伝わるニュアンスは、要求がすでにユーザーサイドに存在し、それがシステム構築サイドに伝えられるという受動的なものである。しかし、本来の要求はユーザー、構築両サイドが協力して作り上げていくものではないか。とすれば、「開発」という表現が妥当と考えられる。正しい要求が開発されないと、それを受ける下流のシステム開発は無為になる。要求開発は、複数の関係者による「合意形成」であり、そのプロセスは一方向の命令統制ではなく「参加協調」が必要であり、その合意は複数フェーズにまたがる「多段階のコミットメント」となる。このプロセスは、「継続的改善」や「PDCAループ」を描く。つまり、要求開発には「コミュニケーション重視の創発的活動」が重要である。

　さらに、見えないと目的も手段も追跡できず、合意形成もできず、継続的改善ができないことから、「可視化」が出発点となる。

　このように「定義」から「開発」に変わると、当然のことながら方法論も変わってくる。「要求開発アライアンス」は、方法論として、「Openthology（Open Enterprise Methodology、オープンソロジー）」をベースとする。（参考図書「戦略的要求開発のススメ」安井昌男著　翔泳社、「要求開発〜価値ある要求を導き出すプロセスとモデリング」山岸耕二、日経BP社など）。

　以上はたまたま要件定義を例に挙げ、しかもある特定グループの主張を代表例として参考にしたが、要するにITに対するアプローチを始め経営手法は進化しているのであり、企業人は常に勉強をすることを怠ると時代の流れに取り残され、競合他社の後塵を拝することになるという警告を発したいのである。

　定義を開発と置き換えただけでも、業務システム開発の方法論の新しい道筋がほのかに見えてくるのではないだろうか。「定義ではなく、開発」と心の中で唱えてみるといい。これまでの仕事の流れを変えるべき点の1つや2つはイメージされるだろう。過去の経験から、あれこれとわがままを言うユーザーの意見をとりまとめ、何とかシステム言語に置き換えることが仕事だと決め付けてはいないか。「とことん仕事に活用されるシステム」を作るための根幹となる思想は、時間の経過の中で、変化しつつある。あきらめず、決め付けず、トレンドを追い続けることが大切だ。

過去のニュース一覧はこちら

プロフィール

ますおか・なおじろう　日立製作所、八木アンテナ、八木システムエンジニアリングを歴任。その間経営、事業企画、製造、情報システム、営業統括、保守などの部門を経験し、IT導入にも直接かかわってきた。現在は「nao IT研究所」代表として、執筆・講演・大学非常勤講師・企業指導などで活躍中。著書に「IT導入は企業を危うくする」（洋泉社）、「迫りくる受難時代を勝ち抜くSEの条件」（洋泉社）