要件定義はとにかく難しい。炎上するプロジェクトはだいたい要件定義が失敗している。

 「この仕様は間違っている」「この項目がないのはおかしい」。プロジェクトの終わりが見えたころ、ユーザーがこう指摘してくる。エンジニアは仕様書や要件定義書まで遡って修正、設計・実装のやり直しを余儀なくされる。

 「我々の業務の常識を知らないのか」。指摘とともにユーザーが話すお決まりの言葉だ。ユーザー企業の利用部門で働いているわけではないエンジニアには耳が痛い。

 バックグラウンドや立場が異なる利害関係者の要求や制約を理解して、要件や仕様に落とし込んで合意を取る要件定義には、高度なテクニックが必要だ。「打ち合わせだけなら誰でもできる」と思うときっと痛い目を見る。

 要件定義が失敗する典型的な三つのパターンについて、それを回避する要件定義の達人が実践するワザを紹介しよう。

パターン1:後回しにしたがるユーザー

 「関係者全員を集めて合宿を開けますか」。アビームコンサルティング プロセス&テクノロジー ビジネスユニット ITMSセクターの渡邉正和シニアマネージャーは、要件定義の開始前にこうユーザーに投げかける。

アビームコンサルティングの渡邉正和シニアマネージャー
アビームコンサルティングの渡邉正和シニアマネージャー
[画像のクリックで拡大表示]

 目的は合宿そのものではない。「日常業務がどれだけ多忙であろうが、関係者全員のスケジュールを合わせ、何日間も拘束できるかを聞いている」(渡邉シニアマネージャー)。

 なぜこんなことを聞くのか。要件定義で特に危険なのは「ユーザーの本気度が低い場合」(同)であり、その本気度を見極めるためだという。

 「今決めなくても」「よく知らないし、忙しい」「どうせベンダーがやってくれる」――。後回しにしたがる、ベンダー任せにしたがる意識がユーザー側にあると、要件定義で漏れが多発する。

 「合宿」という表現は、ユーザーに気付いてもらうためのとっかかりだ。普通、「なぜそこまでしないといけないのか」との質問が返ってくる。

 返す刀で、要件定義がどれだけ重要か、要件定義を失敗するとコストやスケジュールにどう悪影響が出るかを事例を交えて説明。本気になって要件定義にユーザーが参加するのは、業務上の最優先事項であると腹落ちしてもらう。

パターン2:要件を言語化しきれていない

 システム更改を機に業務プロセスを改善するのはよくあるプロジェクトの例だが、こうしたケースに付き物なのが「新しい業務プロセスはどういったものか、ユーザーが細かく言語化できていない」という問題だ。曖昧なまま要件定義を進めると、間違いなく仕様漏れが発生する。

 この問題の解決策は「利用部門の担当者レベルでも分かる言葉で業務のシナリオを書くこと」。こう話す達人が、日立製作所 ICT事業統括本部 アプリケーションサービス事業部 生産技術部の向坂太郎主任技師だ。

日立製作所の向坂太郎主任技師
日立製作所の向坂太郎主任技師
[画像のクリックで拡大表示]

 画面一覧やシステム機能一覧、データモデルはシステム観点では的確な文書だが、利用部門にとって理解しやすい形式ではない。そこで、現場はどういう手順で業務を進めるように変わるのかをシナリオ形式で記述して、関係者で読み合わせ(ウォークスルー)を実施するという。

 シナリオの書き方のポイントは「ボタン名や項目名、内部処理などのシステムの動きではなく、業務の言葉で現場の動きを書く」(向坂主任技師)ことだ。「この場面では、2000件くらいの顧客データの一覧を見ながら業務を進める」などの、非機能要件を左右する重要な情報も自然に引き出せる。