要求はできるだけたくさんのレベルの人に聞く

要求定義研修でよく質問されるのが、

「どの程度の範囲で要求をヒアリングしたり、掘り起こしたりすべきか」

というものです。実際、この質問は「ヒアリングを適当なところで切り上げられないか」という効率面を考えたものです。しかし、要求のヒアリングを効率面だけで判断すると、

要求が漏れることで、追加要求が発生して開発工程の後戻りが起こる

ことになります。ですから、可能なら、要求はたくさんのレベルのところから引き出す必要があります。

要求にはレベルがある

　ヒアリングでは、対面で要求を確認するわけですが、要求にはレベルがあることを認識すべきです。経営者がシステムに対して要求することと、現場レベルの従業員がシステムに対して要求することには大きな差があります。また、その目的も異なることが多いでしょう。

　経営者はシステムに対して「経営に役立つ情報が見たい」「どの程度、人員を削減できるのか」「売上の上昇に寄与するのか」といった点で考えやすいでしょう。一方、現場レベルでは「効率的に仕事をするための情報が見たい」「業務上の間違いを起こさないためには」という視点になりがちです。そうなると、やはりシステムに対する要求は違ってきます。対立することは少ないかもしれませんが、要求の大きさはだいぶ違うでしょう。

現場レベルの要求が細かくなりやすい

　上述のように、現場での要求は細かくなりやすい傾向があります。このため、管理職レベルへの要求ヒアリングで確定していた要求にしたがってシステムを作ってみても、現場に導入する直前で「このデータが見られない」「この項目を入力したい」といった細かな要求が次々と出てきてしまうことがあります。

　管理職が現場の作業を細かく把握していないということも原因のひとつですが、システムエンジニア側が現場をよく見ておらず、要求を把握し切れていないということもあるでしょう。また、管理職や現場リーダーレベルのヒアリングで出てきた要求の「意図」を理解せずに機能を作りこんでしまうことによって、要求は実現されていても使い勝手や意図通りに動かないというシステムが出でき来上がる可能性もあります。

頓挫しないためにはきめ細かなコミュニケーションが必要である

　こうしたことが起こって、デスマーチにならないようにするためには、きめ細かなコミュニケーションが必要と言えます。ヒアリング結果で得た情報で「プロトタイプ」や「絵コンテ」を作って、現場レベルも含めて要求の確認をしたり、機能の方向性や意図を再認識したりすることが重要です。

　また、起こってしまった場合にもしっかりと「裏の意図」を再度確認して、追加で出てきてしまった要求を取捨選択、優先順位付けし、現場リーダーや経営者と合意した上で、追加機能を作るかどうか決めるといったコミュニケーションも求められます。

　すべての要求を把握することは実際、不可能だろうと考えられますが、その手からこぼれる量を減らす工夫は必要です。アジャイル開発をするにしても要求をきちんと把握して、その手から漏れ出す量を減らすことは重要ですから。