要件ヒアリングのコツ

突き詰めていえばＩＴ業界だけに限った話じゃないんですけど。

なにせ私がＩＴ業界の人間なものですから、Ｂ２Ｂのソフトウェア開発における顧客の要求事項を聞き取る工程…要件定義について説明していきたいと思います。

なかでもエンドユーザーに対するヒアリングには注意が必要です。二次請けの立場で元請けのSIerに聞くのとはわけが違いますし、仮に相手がエンドユーザーだとしてもその担当者が自社の業務を正しく理解しているとは限りません。

あ、ちなみにユーザー側の方に言っておくと、担当者をテキトーな人選で決めるとトラブル率が圧倒的に上昇するので気を付けてください。仮にどんなにSIer、ITベンダー側が優れていたとしても、彼らは「必要十分な情報」を揃えられない限りは上手くマネジメントできませんから。

さて、そんな開発側はその「必要十分な情報」を聞き取りするために色々と事前に知っておかなくてはなりません。なんとなくでは上手くいかないんです。

お客さまが「何を実現したいのか」「何を課題としているのか」を聞き出すのは、普段「どうやって実現するのか」「どう作ればいいか」ばかりを中心に考えている開発者には思いのほか難しいことです。

お客さまから要件をヒアリングする場合は、必要最低限のポイントとして５つの点を意識する必要があります。慣れは必要ですが、普段から意識することで徐々にヒアリングが上手にできるようになります。

手段ではなく目的の話をする

はい、いきなりエンジニアにとっては高い壁です。聞くだけなら特に技術が必要なわけでもなく容易なのですが、いかんせんエンジニアの心理というか性癖…がそれをさせません。

エンジニアは日頃の活動が内製中心であればあるほど、常に顧客と接点を持つ立場で無ければ無いほど

　「どう作るか」
　「いかに実現するか」

ばかりに目が行ってしまいます。仮に要件定義でお客さまと直接話をしても、お客さまの実情に興味を持とうとしません。ただただ心のなかでは「そんなことより、要するになにを作ってほしいわけ？」と考えてしまいがちです。

メーカーやベンダーとしての色が濃い企業であれば、それでよかったかもしれません。

しかしもしもＳＩ（System Integration）を生業としているいのであれば、今一度「ＳＩとはなにか？」「何をすることがビジネスなのか」に立ち返ってみるといいでしょう。少なくともＳＩができているプロジェクトマネージャーやエンジニアというものは、その中身を知っているか否かにかかわらず、私の知る限りこれまであってきた方々の中では極々わずかだったように記憶しています。

そう言ったＳＩに目を向けられないエンジニアでは、中心の企業やプロジェクトは要件定義だと言っているなかで、「業務」「システム」「機能」「非機能」「移行」といった要件のもととなる

　『要求事項（ニーズ）』

を整理できません。いきなり業務フロー作り出したり、画面設計書を書きはじめたりしているのではないでしょうか。「どのようなものにするか？」「どう実現するか？」にしか興味を持たないから作るにはそれで充分だと考えてしまっているのかもしれません。それは所詮、実現手段の１つでしかなく、本当にビジネスとして求められているのは「顧客の課題を解決する」ことなんですけど。

ですので、真にＩＴエンジニアを名乗るのであれば手段の話をする前に目的の話をしましょう。そうしないとプログラマーに毛が生えた程度と変わりません。

目的の確認と共有は要件ヒアリングの重要なポイントです。
たとえば

　「ブラウザは 〇〇 限定でよろしいですか？」
　「〇〇の機能には…」
　「このフレームワークを使うことによって…」
　「このツールを用いれば効率的に…」

などといった手段の話をし過ぎないでください。

エンドユーザーの場合、担当者の方のＩＴリテラシーが乏しいケースも多く話が噛み合わず場がしらけますし、不信感が募るばかりです。同業者のお客さまの場合であっても同様です。「本当にやることがわかってるのかな？」と心配されることになるでしょう。

手段の話が先行すると視野が狭くなり、お客さまが本当に実現したいことからかえって遠ざかることもあります。

たとえば「ユーザーが入力した永続的にデータを保管する」という目的を実現するにはいくつもの手段があるはずなのに「ＤＢにデータを保管する」という手段に限定してしまうと、ほかの手段を検討する機会を失うことになります。中には

　・自分たちの経験値が一番高いから
　・自分たちがそれを使って実績をあげたいから

という理由だけで、お客さまのニーズとの適合性などを検討することなく「まぁ実現できれば別にいいじゃん？」みたいなノリの企業やエンジニアも結構いたりします。自社製品を持っている企業だと、自社製品を売って売上、利益を上げたいがために、ニーズとの相性が悪くても無理やり売りつけるケースも案外多かったりするものです（まぁどこのなにがとはいいませんけども…）。

これはお客さまと開発者相互にとってあまり良いことではありません。

検索性を特に気にせずただただ情報を保管するだけなら、他にも色々方法があるので安易にそのニーズだけでＤＢ使えばいいじゃんと思うのは早計です。

積極的に聴いたうえで理由を尋ねる

自分が正しいと思うことを理路整然と説明したくなるのが開発者の性ですし、それは悪いことではありません。提案が必要なケースだってあるでしょう。

しかし、ヒアリングはそもそも「聴く」ことが第一目的です。
まずは話をよく聴きましょう。そして先入観にとらわれないように柔軟でオープンな気持ちを持ってください。

それともう１つ。
聴くのは目的の第一義ですが、最終的に聴きだす対象は

　「答え」ではなく「理由」

です。

要件ではなく、その前段である『要求事項（ニーズ）』を聞き出す場合、私たち開発側に対して「〇〇してください」という答えを聴くことが目的にはなりません。それはむしろ悪手です。

ここで聴きたいのはあくまで『要求事項（ニーズ）』。
つまり、

　「今の現状（As-Is）を、理想（To-Be）にしたい」

という要望であって、それを具体的で実現可能な要件にするのは、提案も兼ねて私たち開発側の仕事です。そこを履き違えて「我々に何をしてほしいのですか？」という聴き方になってしまった場合…法的にも注意しなければならなくなってしまいます。それは

　善管注意義務

に違反しているかもしれないからです。

請負や準委任の契約には「善管注意義務」が伴います。すなわち専門的な技術や知識を持ったプロフェッショナル集団として、責任ある姿勢、取り組みを行う義務があり、実際これを疎かにしたことでＩＴ調停上、開発側に不利な採決をとられる事例もあります。

そして、ここでの善管注意義務違反とは

「要件定義とは、顧客のニーズから持ちうる技術力やノウハウを用いて、「業務」「システム」「実現機能」「非機能」「移行」etc.…それぞれの要件を整理し、必要に応じて提案する工程」

であるものに対し、その責任を果たそうとせず顧客側に「結局、何作ってほしいの？」と聞いてしまっている点にあります。その作業を顧客側に押し付けるのは、要件定義を遂行するＩＴ企業側の善管注意義務違反と言われても仕方がありません。

逆に、顧客側にその認識がなく、開発側に「アレやれ」「コレやれ」と指示・命令をしだし、その指示・命令を受け入れるのも同様に善管注意義務違反となります。『偽装請負』として顧客側にも問題があるのですが、それを甘んじて受け入れる姿勢を「プロのすることではない」と判断されてしまうからです。

ですので、聴き方には最大限の注意を払いましょう。

聴くのはあくまで「ニーズ」ですが、そこで途中に質問をはさむのであれば

　「なぜですか？」

を加えてください。
これはお客さまの課題を解決するプロフェッショナルとして必要不可欠なことです。仮にお客さまが「いいからやってくれ」みたいな横暴な態度をとったとしても必要と感じた場合は毅然と聞きましょう。

なぜなら、お客さまは100%正しいとは限らないからです。

お客さまが我々開発側より開発について知っているなら、わざわざ外部発注する必要がありません。お客さまのニーズにしても、それで本当にお客さまの課題が解決できるかどうかわかりません。

だからヒアリングのなかで

　「え？それで本当に今の課題って解決するの？」

みたいな疑問が浮かんだ場合、疑問点に関してはその理由を尋ねます。

個人的な経験則ですが、特に帳票に関してはその存在意義を改めて尋ねましょう。このご時世にまだ「印刷」をしたいというニーズがある場合は特に「なんで？」という疑問を持たなければなりません。システム化する業務のなかで印刷物があるというだけでも、業務負荷となりうる可能性があるからです。なかには変化を嫌う人の「今までそれでやってきたから」「その方が（個人的に）効率がいいから」なんて理由で依頼してきている可能性もあるわけです。一度システム化してしまったら数年～10年以上変えられない可能性もあるので、それが本当にその企業全体にとっていいことかどうか吟味しなくてはなりません。

帳票は画面と違って関連する人（印刷する人や回覧される人、ファイリングする人）が多いため一旦できてしまうと廃棄することが少なく、それが本来不要なものであっても延々と生き残りがちです。なかにはそのためだけの棚や倉庫を設けなくてはならないほどだったりします。

要は、無駄になりやすい部分なのです。

また、何か話がかみ合わなかったり、聞きなれない用語が出てきた場合にはその場で尋ねてしまいましょう。実は用語の使い方が開発者とは違っているのかもしれません。

まさに「聞くは一時の恥」です。

なお、聴きに徹しているうちにお客さま同士の利害関係も見えてきたりします。利害関係の不一致は要件をまとめるうえでの大きな課題であり、その回避策のために無駄な要件や機能が増えることすらあります（特定の部署専用の帳票や極端な過去互換性など）。

お客さまの利害を完全にコントロールすることは困難で、妥協案として無駄な機能が増えるかもしれません。しかし、その理由を把握しておくことでよい代替案が浮かびやすくなります。

追い詰め過ぎない

開発者がやりがちなのが、決定を迫り過ぎることです。

　「AとBどちらがよろしいでしょうか？今週中に決めてください」

などといってお客さまを追い詰めてはいけません。もちろんプロジェクトには期限がありますし、その期限中に完遂させないと利益率の損耗…ひいては赤字になってしまうかもしれませんので、すべてがすべてお客さまの希望通り…というわけにはいきませんが、可能な限りお客さまを追い詰めないスケジュールコントロールが求められると思っておいた方がいいでしょう。

中には、責任を取ることに臆病で、自分で決めるのがいやなタイプのお客さまもいます。それ自体、正直「どうなのよ」と思わなくもありませんが実際にいるのですから仕方ありません。

こういう場合は選択肢をあまり多くせず、こちらからの提案という形で案を絞り込んでしまうのも手です。

そこで最も効果的なのがクローズドクエスチョンです。

　「〇〇と言う案で行こうと思いますが、いかがでしょうか？」

それがダメなら、

　「ＡとＢと言う案があります。Ａのメリットは…」
　「どちらがお好みですか？」

という感じでも良いでしょう。
ここで重要なのは、

　「御社にオススメなのはＡです」

と言い切ってしまわないことです。善意でもなんでもこちらの意見を押し付けるのではなく、あくまで相手の自由裁量を尊重していると言う姿勢が重要です。

もちろん、提案に対して意見をもらえるのであれば喜んで話を聴きましょう。

一般に、要件や機能を選ぶ場合、

　開発者は「効率」と「美しさ」を優先し
　お客さまは「確実さ」と「周りへの影響」を気にしがち

です。このあたりの心情を理解したうえでの提案のコントロールが行えるようになると、お客さまの判断もずっと早くなることでしょう。

進捗を示す

要件定義フェーズで怖いのは「いつになっても終わらないこと」です。

要件定義では「どうなったら完了」と言うゴール設定も曖昧なことが多く、そのまま時間切れで開発に突入してしまいます。

ですからお客さまに進捗を示すことは重要です。

ヒアリングも回数を重ねると堂々巡りになることがあります。前回の打合せ課題を継続検討していたり、「そもそも論」に立ち戻っていたりしてはスケジュールどおりの完了は見込めません。

進捗を示す際には「全体として半分程度進んでいる」といったあいまいな説明ではなく、「注文業務は完了。発注業務はレビュー待ち…」などというように作業の状態（ステータス）を具体的に明確化します。

ただし、これまでも何度かお話してきたように大事なのは

　「今どの程度進んだか？」

ではなく

　「あとどの程度で終わりそうか」

という考え方で進めることです。特に要件定義のような何かが「決まるまで」の進捗は一般的な「進み」の程度を確認しようがありません。何かが「決まるまで」の進捗は「残り」の程度を示します。

そもそもそう聞いた方がその先の計画も見通しやすくなるのですから、過去の経過具合なんて聞くだけ無駄なんです。

記録を残す

不毛な「言った言わない問題」を防ぐには記録を残すしかありません。
これはお互いのためです。

公式な会議は議事録として記録を残し、関係者がいつでも参照できるようにしておきます。議事録を残すのはビジネスパーソンとして当然の常識なのですが、小規模プロジェクトでは油断からなおざりになることがありますので注意しましょう。

そのせいで小規模プロジェクトばかりで実力を身につけてきた中堅エンジニアは残念なことに「議事録」の正しい書き方を知らない人も多いのが実情です。

そうこうしてエンジニアリングの技術力だけで出世し、大規模プロジェクトのマネージャーなんかを任されたころには、自分で議事録を作らず、下のメンバーに書かせたりするので、ますます「記録管理」の重要性を理解する機会もなく、たまたまプロジェクトで大きな問題が起きなかったりするとそのまま課長、部長へと上がってしまい、一生ロクに記録管理もできない管理職／経営層の出来上がりです。

実際、そのような上司や経営者…というのは多くの企業で散見されます。

この現象のなかで特にマズいのは、そうした上司や経営層の下では、部下たちにも正しい教育が行き渡らないことです。教育できる知識やノウハウもないし、自分自身は大事だと思ってこなかったからその必要性を理解できませんし、仮にそのせいで問題が起きても今となっては下にたくさんの部下たちがいるので

　「なんで議事録をとらないんだ！」
　「おい、議事録とっといて」

というだけで自分は責任を果たしたと勘違いしてしまっていることでしょう。もちろん説明されたわけでも、教育されたわけでもないので部下たちも満足できる議事録を作成するのが難しく、いつまで経ってもビジネスコミュニケーション上の課題が解決しない組織の出来上がりです。

ときおり休憩所や喫煙室など非公式な場で決まってしまうこともありますが、その場合にはメールにて記録を残しておけばあとで追跡できるので便利です。

「先ほどの喫煙室でお話いただいた件ですが今一度確認させてください。
　　…（中略）…　
　という認識でよろしかったでしょうか。」

といったメールを、しかもCcなどで複数の関係者も巻き込む形でお送りしておくと、後々後腐れが無くなります。

漏れがなく、あとから記録を追いかけやすい質の高い議事録を残すためにも、ヒアリングの際は自社から２名以上で行うといいでしょう。

私の経験から言えば、

　「右脳人間と左脳人間のペア」

はうまくいきます。右脳人間がお客さまの話を引き出し、左脳人間がそれをロジカルに整理し、記録として残します。私自身は、個人的に自分のことを左脳人間だと自覚しているのですが、案外器用な人間なので前者の役割を担うことが多いかも知れませんけど…。