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

過去の仕事の延長線上での工夫や改善も大切だが、仕事に対する考え方を根本から変える発想はいつか必ず出てくる。過去にとらわれず、虚心坦懐にこれらの思想、アイデア、メソドロジーに触れ、思考パターンを変えていく必要がある。

[増岡直二郎，ITmedia]

競争に敗れる落とし穴

　企業人は、あるいは中間管理職は、不断の勉強をしなければならない。

　ものの考え方や問題解決へのアプローチの仕方など、経営手法はどんどん進化している。

　旧来のやり方に固執していると、時代の流れに置いて行かれ、競合他社の後塵を拝することになり、思わぬ落とし穴にはまりかねない。

　例えば、IT導入を成功させるための重要な条件の1つに、「要件定義」がある。「要件定義」の考え方や方法も変化してきている。いや、変化させなければならない。

　その他にIT導入成功の条件として、トップの適切な関与、目標の定量表示、プロジェクトメンバーの人材確保、意識改革、人材教育、BPRなど挙げられるが、中でもユーザーの意見を充分に取り入れなければならない「要件定義」は、実務につながる数少ない条件であるだけに極めて重要である。

　「ユーザーインタフェースが、なかなか決まらない」、「設計段階に入ってから、機能の追加要求が来る」、「仕様がいったん決定した後も、変更が相次ぐ」、これらの原因はユーザーの要求を正しくとらえていないからであり、またそれを正しく表現していないからであるとされる。つまり、要件定義のまずさが原因である。

　ユーザーが「仕様の定義が不充分」で、「要求仕様を明確に表示していない」と認識しているケースが66％にもなる（「全国IT動向調査2006」日本情報システム・ユーザー協会）。

　そもそも要件定義とは何か。業務をシステム化する場合に、顧客が潜在的に持っているものも含めて要求を聞き出し、あわせて現場の問題点とその解決方法も考慮に入れて、全体最適の視点から整理し、構造化し、仕様化することである。

　しかし通常行われている要件定義は、SI企業がユーザーから出された、あるいはユーザーから聞き出した要件を追認して、システムに落とし込んでいくという頼まれ仕事になりがちであり、一方ユーザーは現状業務を定義することで精一杯になりがちであり、まさに「要件」をただ「定義」することで終わってしまう傾向になる。ベンダー・ユーザー両方にとって、どうしても受身の仕事になり、システム構築も従来業務の置き換えになってしまうという問題がある。