ヒアリングを積み重ねると、なぜか「大きすぎるシステム」ができる
「要件漏れがないように、各部門へしっかりヒアリングしましょう」
システム開発では、ごく当たり前に言われることです。
営業、経理、物流、情報システム、管理部門。それぞれの担当者から現在の業務や困りごとを聞き、必要な機能を洗い出していく。
丁寧にヒアリングするほど、良い要件定義ができそうに思えます。
ところが、実際には逆のことが起きる場合があります。
ヒアリングすればするほど、要件が増えていく。
- 営業から20個
- 経理から15個
- 物流から30個
- 情報システム部から10個
気がつけば大量の要件が並び、見積金額は膨らみ、システムも複雑になっている。
ヒアリングが足りなかったわけではありません。
むしろ、丁寧に聞いた結果です。
では、何が問題だったのでしょうか。
現場の要望は、だいたい正しい
例えば、販売管理システムを刷新するとします。
- 営業部：「外出先からスマホで入力できるようにしてほしい」
- 経理部：「一定金額以上は、必ず承認を通してほしい」
- 物流部：「今使っているExcelには出力できるようにしてほしい」
- 管理職：「売上状況をダッシュボードで見たい」
- 情報システム部：「監査ログは残してください」
という要望が出てくる。
どれも、それぞれの立場から見ればもっともです。
営業には営業の事情があり、経理には経理の責任があります。物流にも、管理職にも、情報システム部にも、それぞれ必要だと考える理由があります。
つまり、問題は、
「現場の要望が間違っている」ことではありません。
むしろ、現場の要望は、だいたい正しい。
問題は、その次です。
正しい要望を全部足せば、正しいシステムになるのでしょうか。
ヒアリングで「必要ですか？」と聞いてはいけない
例えば、現在使われている帳票について担当者に聞きます。
「この帳票は、新しいシステムでも必要ですか？」
おそらく、多くの場合、
「はい、必要です」
と返ってきます。
当然です。
今まで使ってきた帳票を、わざわざ自分から「なくして構いません」と言う理由はあまりありません。
承認フローについて、
「この承認は必要ですか？」
と聞いても、
「必要です」
となるでしょう。
Excel出力について、
「Excelに出せる必要がありますか？」
と聞けば、
「できれば残してください」
となります。
そしてヒアリングシートには、
- 帳票Aを出力できること
- 現行承認フローを継続できること
- Excel出力できること
と書き込まれていきます。
これを10部署で繰り返せば、要件は増えて当然です。
問題は現場ではありません。
質問の設計です。
「必要ですか？」という質問は、要件を判断する質問に見えて、実際には現行業務を新システムへ持ち込む確認になりやすい。
では、何を聞けばよいのでしょうか。
現場から集めるのは、「要件」ではなく「判断材料」
例えば営業部から、
「スマホから入力できるようにしてほしい」
という要望が出たとします。
ここで、
「スマートフォンから入力できること」
と要件一覧へ転記してしまえば、要件が一つ増えます。
しかし、まだ要件にする必要はありません。
まず聞くべきなのは、
「なぜ必要なのですか？」
です。
すると、
「外出していることが多く、会社に戻らないと入力できないからです」
という答えが返ってくる。
さらに聞きます。
「会社に戻ってから入力することで、何が困っていますか？」
「商談内容の入力が翌日になり、他のメンバーへの共有が遅れます」
ここまで来ると、
「スマホ入力」という現場の言葉の奥に、
「商談後、速やかに案件情報を社内で共有したい」
という目的が見えてきます。
スマートフォン対応が適切な解決策なのかは、その後で検討すればよい。
大切なのは、
WantとNeedとSolutionを、その場で一つにしないことです。
現場から出てきた「こうしてほしい」という言葉は、重要な情報です。しかし、それだけで要件が確定したわけではありません。
ヒアリングで集めるべきなのは、「必要／不要」という結論ではなく、例えば次のような判断材料です。
- 目的：何を解決するための要望なのか
- 頻度・量：誰が、どのくらいの頻度で使うのか
- 影響：対応しなかった場合、何が起きるのか
- 代替：システム化以外の方法で対応できないか
この情報が揃って、初めて会社として判断できるようになります。
例えば、「特殊な返品処理もシステム化してほしい」
もう少し具体的に考えてみます。
現場から、
「特殊な返品処理も、新しいシステムで処理できるようにしてください」
という要望が出たとします。
「必要ですか？」と聞けば、
「必要です。実際に発生しますから」
で終わります。
そこで質問を変えます。
「年間何件くらいありますか？」
年間3件。
「今はどう処理していますか？」
担当者がExcelで補助票を作り、1件30分程度で処理している。
「システム化しないと、業務が止まりますか？」
止まらない。今の方法でも対応できる。
ここまで分かれば、初めて議論できます。
特殊返品をシステム化すれば、例外分岐が増えます。設計だけでなく、開発、テスト、マニュアル、保守にも影響します。
一方、手運用であれば年間3件、合計90分程度です。
もちろん、これだけで「システム化しない」と決められるわけではありません。取引金額や内部統制、ミスが起きた場合の影響なども確認する必要があります。
しかし少なくとも、
「現場が必要と言っているから入れる」
という状態から、
「今回のシステムに実装する価値があるか」
という議論には変わります。
これが、ヒアリングで集めるべき情報です。
要望と要件の間に、「判断」を置く
ヒアリング結果を整理するとき、「要望」と「要件」を直接つなげないことが重要です。
例えば、次のように整理します。
| 現場からの要望 | 目的 | 頻度・対象 | 未対応時の影響 | 現在の代替 | 今回の判断 |
|---|---|---|---|---|---|
| 特殊返品も画面で処理したい | 入力ミスを防ぎたい | 年3件・担当1名 | 手作業が1件30分程度発生 | Excel補助票 | 対象外候補 |
| 外出先から案件登録したい | 商談情報を早く共有したい | 営業30名・日常的 | 情報共有が翌日になる | 帰社後入力 | 対応方法を検討 |
| 月次帳票Aを残したい | 不明 | 月1回 | 不明 | 不明 | 追加確認 |
ポイントは、左端の「要望」と右端の「判断」の間に、いくつもの列があることです。
「欲しい」と言われたものを、その場で「要件」にしない。
目的、頻度、影響、代替手段を確認し、他の要望とも並べてから判断する。
そうすると、同じ「必要です」という要望でも、意味が違って見えてきます。
これは、現場の要望を否定するための作業ではありません。
現場の要望を、会社として判断できる形へ変換する作業です。
「束ねる」とは、一つにすることではない
部署ごとにヒアリングすると、同じように見える要望が別々の言葉で出てくることがあります。
- 営業部：「顧客情報を一元管理したい」
- 経理部：「取引先情報を整理したい」
- 物流部：「納品先マスターを整備したい」
という要望が出たとします。
これだけを見ると、
「同じ会社の情報なのだから、一つのマスターに統合すればよい」
と思うかもしれません。
しかし、実際はそう簡単ではありません。
営業にとっての「顧客」は、営業活動や商談を管理する単位かもしれません。
経理にとっての「取引先」は、契約や請求、与信を管理する単位かもしれません。
物流にとっての「納品先」は、商品を実際に届ける場所です。
一つの企業に複数の請求先や納品先があることもありますし、商流によって契約先と納品先が異なることもあります。
ここで、
「全部同じ会社ですよね」
と無理に一つにすると、かえって業務が壊れます。
「束ねる」とは、何でも一つに統合することではありません。
重要なのは、
何が同じで、何が違うのかを整理することです。
- 共通化すべき情報は何か
- 部門ごとに持つべき情報は何か
- それぞれを、どのキーで関連付けるのか
こうした構造が見えて初めて、マスターやデータの設計へ進むことができます。
ヒアリングで出てきた三つの要望を、そのまま三つの機能にするのでもなければ、乱暴に一つへ統合するのでもない。
要望同士の関係を整理する。
これも、要件定義の重要な仕事です。
判断材料が揃っても、判断できるとは限らない
ここまで整理すれば、すべて簡単に決められるかというと、そうではありません。
先ほどの特殊返品について、
「年間3件」「手運用可能」という事実が分かったとしても、
「その3件で問題が起きたら、誰が責任を取るのか」
という意見が出れば、簡単には対象外にできません。
別の部門から、
「営業部の要望は入ったのに、なぜこちらは対象外なのか」
と言われることもあります。
これは珍しいことではありません。
ただし、ここで再び各部門と個別に、
「では、入れましょう」
と調整してしまえば、また元の足し算に戻ります。
だからこそ、要望を部門横断で並べたうえで、
- 事業への影響
- 発生頻度・対象件数
- リスク
- 投資額
- 代替手段
- 今回のプロジェクトの目的
といった共通の判断軸で比較する必要があります。
それでも、意見が割れるものは残ります。
そこで、もう一つ重要になるのが、
「誰が決める問題なのか」
です。
要件定義では、「誰が決めるか」も設計する
すべての要件を、現場ヒアリングの場で決める必要はありません。
例えば、
「入力項目をどの順番で並べるか」
であれば、実際に使う現場担当者を中心に決めればよいでしょう。
一方、
「特殊返品を今回のシステム対象に含めるか」
であれば、開発コストやプロジェクト全体の優先順位も関係します。現場担当者だけで決める話ではありません。
さらに、
「承認工程をなくし、一定の業務リスクを許容するか」
となれば、業務責任者の判断が必要になるかもしれません。
「全社で顧客コード体系を統一するか」
となれば、複数部門をまたぐため、プロジェクトオーナーや経営レベルの判断になる場合もあります。
例えば、次のように分けて考えることができます。
| 論点 | 主な判断主体 |
|---|---|
| 入力項目や画面の使い勝手 | 現場・業務担当 |
| 例外処理をシステム化するか | プロジェクト |
| 承認工程を変更し、リスクを許容するか | 業務責任者 |
| 部門横断でマスター体系を変更するか | プロジェクトオーナー・全社 |
| 業務標準化のため既存ルールを変更するか | 内容によって経営判断 |
重要なのは、肩書きを厳密に当てはめることではありません。
その論点について、責任を持って判断できる人のところまで上げることです。
要件定義担当者が、すべての要望について○か×かを決める必要はありません。
むしろ、
- 何を決めなければならないのか。
- その判断に何の材料が必要なのか。
- そして、誰が決めるべきなのか。
ここまで整理することも、要件定義の仕事です。
ヒアリングは「要件を決める場」ではない
ここまで整理すると、要件ヒアリングの位置づけも少し変わって見えてきます。
ヒアリングの場で、
「必要ですか？」
「では要件に入れましょう」
と、一つずつ○を付けていく。
これを繰り返せば、システムが大きくなるのは当然です。
ヒアリングは、要件を決める場ではありません。
要件を決めるための材料を集める場です。
現場から、
- 何をしているのか
- なぜ必要なのか
- 誰が使っているのか
- どのくらい発生するのか
- なくなると何が起きるのか
- 今はどう対処しているのか
を集める。
その材料を部門横断で並べる。
そこで初めて、
- これは同じ課題ではないか
- これは今回のシステムで対応する必要があるのか
- これは別の方法で解決できないか
- これは会社としてどちらを優先するのか
そして、
これは誰が決めるべき問題なのか。
という議論ができます。
つまり、
ヒアリングと要件決定は、分けた方がよいのです。
要件定義は、「取材」ではなく「編集」である
要件定義というと、
「誰にヒアリングするか」
「何回ヒアリングするか」
「要件を漏れなく洗い出せるか」
という話になりがちです。
もちろん、聞くことは重要です。
現場を知らずに、良い要件定義はできません。
だから、徹底的に聞く。
ただし、
聞いたものを、そのまま要件定義書へ転記しない。
- 現場の言葉を集める
- その背景を掘る
- 他の部署の要望と比べる
- 似たものの関係を整理する
- 判断材料を揃える
- そして、誰が判断すべき論点なのかを明確にする
流れにすると、
集める → 掘る → 比べる → 束ねる → 判断につなげる
となります。
ヒアリングは、この最初の入口にすぎません。
要件定義に必要なのは、単なるヒアリング能力ではありません。
集めた情報を構造化し、会社が判断できる形に「編集する力」です。
ヒアリングを10回行って、100個の要望が集まった。
それをきれいにExcelへ並べた。
それだけでは、要件定義をしたことにはなりません。
むしろ、そこからが要件定義です。
ヒアリングで要件を決めない。
ヒアリングで、要件を決めるための材料を集める。
その材料を編集し、部門横断で比較できる状態にする。
そして、
何を、誰が決めるべきなのかを明らかにする。
そこまで設計して、初めて要件定義です。
「要望の一覧」を、「会社が判断できる要件」へ
各部門へのヒアリングは終わった。
ところが、集まった要望が膨大で、どこから手を付ければよいか分からない。
どの要望も「必要」と言われる。
部門ごとに優先順位も違う。
さらに、誰が最終的に判断するのかも曖昧になっている。
この状態で要件一覧の○×を決め始めても、なかなか前には進みません。
オーシャン・アンド・パートナーズでは、発注側の立場から、現場の要望をそのまま採否判定するのではなく、
なぜ必要なのか。
どのくらい使われるのか。
対応しない場合に何が起きるのか。
他の要望とどのような関係にあるのか。
今回のプロジェクトで判断すべきことなのか。
そして、誰が判断すべき論点なのか。
を整理します。
私たちが代わりに、
「これは要らない」
と決めるわけではありません。
部門ごとの要望を、会社として比較し、判断できる状態にする。
そして、現場で決めること、プロジェクトで決めること、業務責任者が決めること、経営判断が必要なことを切り分ける。
そこまで含めて、発注側の要件定義を支援します。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
