方法論はそれなりに整備されているものの不完全。ユーザー企業は要求を決めず，またコロコロ変える――このような状況から脱却するにはどうすればいいのか。結論を言えば，「銀の弾」は存在しない。やるべきことを地道に実践するのがベストだ。
要求定義に絡む問題は根が深い。ユーザーからあいまいな要求しか出てこなかったり，要求があとからコロコロ変わったりするケースが少なくない。しかも，よりどころとなるべき方法論は不完全。それどころか，標準的な方法論がない企業や組織もある。こんな状況に直面すれば，「要求定義をうまくやるなんて無理」と諦めてしまうかもしれない。しかも最近は，要求定義の難しさがますます増している（図1）。
だからといって手をこまぬいているだけでは，システム開発プロジェクトで品質，納期，コストを遵守することは難しい。プロジェクトを成功に導くためには，最上流である要求定義こそが最も重要だからだ。
4つの必須スキル
「プロジェクトによっても，ユーザーの協力度合いによっても条件は千差万別。すべての要求定義に共通するスキルなんてあるのか」と思うエンジニアもいるかもしれない。もちろん，「これをやればOK」という“銀の弾”は存在しない。
しかし，あらゆる要求定義に共通する「4つの必須スキル」がある。それは，（1）ヒアリング技法，（2）業種・業務知識，（3）要求定義の方法論，（4）要求をモデル化するための図法――の4つだ（図2）。要求定義を成功させるためには，まずこの4つの必須スキルを身に付けて地道に実践するしかない。
ヒアリング技法と業種・業務知識は，ユーザーとのコミュニケーションの“基盤”となるものだ。ヒアリング技法は，例えば「ユーザー企業の経営層を交えた全体会議は，本社から離れた研修所やホテルの会議室などで行う」，「開発者側からは，司会進行役と書記役の最低2人で会議に臨む」など，ユーザーとの協力関係を築いてユーザーの要求をより多く引き出すためのスキルである。
一方の業種・業務知識は，ユーザー企業社内や業界の専門用語，業界の慣行，他社事例，典型的な業務フロー，社内の各部門の役割，決済方式などの業務ルール，といった知識を指す。
方法論と図法を確立する
コミュニケーション基盤を確立したうえで身に付けるべき必須スキルが，要求定義の方法論と図法である。
方法論とは，要求定義を実施するための作業内容とその手順，および作成する成果物の種類と記述内容を定めたもの（図3）。行き当たりばったりに要求定義を行っていては，定義漏れが生じる可能性が高くなる。
方法論に付け加えて言えば，要求定義の詳細度にも気を配るべきだ。図4を見て欲しい。これは，ある大手ITベンダーのエンジニアが作成した要求定義書の目次と，一部の成果物の実例である。一見して，極めて詳細な要求定義書を作成していることが分かるだろう。
もう一つの図法も，極めて重要だ。ここで言う図法は，DFD（Data Flow Diagram）やER図（Entity Relationship Diagram），UML（Unified Modeling Language）などのこと。ただし，単にこれらの表記法をマスターすればいいわけではない。
ユーザーから収集した業務マニュアルや現行システムの各種のドキュメント，それにユーザーへのヒアリング結果に基づいて，業務フローやデータ構造などをきちんと描き，矛盾なく要求を定義できる必要がある。
