Hello Ecomott!
おはようございます、こんにちは、あるいはこんばんは。
以上前略、クラウドソリューション開発部 伊藤です。
今回は続編記事！というか長すぎて分割になった
というわけで本編前置きはサクサク終わります。
要件定義入門シリーズ、「ヒアリング」編の中編となります。
えっ、こんな記事が三部作？と思いました？
いやいや、どうせ時間おありでしょう？活字読むのがお好きなんでしょう？
きっとそうだと信じて。
能書きはさておき、前編では「ヒアリング」工程の「下準備」について解説しました。
前編を読まずにこちらを開いたあなた、それこそ「準備」が足りない。
とりあえず前編を読んでいただいてから、またお会いいたしましょう。
前編も履修済だぜ！という方は、いよいよ「ヒアリング」の本筋について、
お付き合い願います。例のごとくちょっと長いよ！！
この記事を読むのにかかる時間は 約10分 くらいです！
この記事でわかること
要件定義工程における「ヒアリング」とは
「ヒアリング」って何をするの？
「ヒアリング」、Hearing、「聞く」——この場合の和訳は、「聞き取り」とか、「聴取」が
適切でしょうか。皆さんもこれまで、幾度となく耳にしてきた言葉でしょう。
ITエンジニアに限った話ではなく、様々なビジネスシーンにおいて、
「ヒアリング」は行われていますから、恐らくこの記事を読んでいただいている方には、
今更「ヒアリングとは〜」なんてのは、釈迦に説法というものかもしれませんね。
ですが一応、前提知識の共有ということで。
ここでいう「ヒアリング」とは、顧客から要望や課題、意向の聞き取り調査を行ない、
情報収集する工程を指します。
ここまでは、それこそ今更語ることは求められていないでしょう。
ですので、ここで語るべきは、「システム開発の文脈における」、
「ヒアリングとは何か」という話になるでしょう。
システム開発の文脈における「ヒアリング」
それでは、「システム開発における」、もっと言えば、「ITエンジニアに求められる」、
ヒアリングとはどういうことか、について考えていきましょう。
まずは手始めに、前編で登場したフロー図から、ヒアリング部のみ抽出してみました。
経済産業省が定めるところの「システム管理基準」を基に作成した
こちらの図では、「ヒアリング」工程は、1つのアクションとしてではなく、
・ヒアリングの実施
・現状分析・要求のパース
・真意・ニーズの抽出
といった複数のステップが連なった「一連の処理プロセス」として表現しました。
そう、「ヒアリング」は、一方的に「聞く」だけの工程ではないのです。
①ヒアリングの実施
「ヒアリング」と聞いて、まずイメージするのがこの作業でしょう。
イメージ通り、顧客とのコミュニケーションにより、顧客の意向・要望を取得する、
インプットのための工程です。
まずは顧客の「生の声」を漏らさずキャッチすることが重要です。
前編で解説したような「準備」も踏まえ、「RFP」だけでは読み取れない、
より「深掘り」した要望・意向を情報収集することが、この工程の
最大の目的となります。
Ristorante Ecomott 👨🍳
(料理に喩えると：常連との世間話 兼 注文)
⇒ レストラン・エコモットには「おまかせメニュー」が存在します。
シェフ伊藤は、カウンターで鍋を振りながらお客様と小粋なトークをして、
お客様が「食べたいもの」を聞き取ります。
「残業長引いた」「昨日飲みすぎた」などといった世間話から、
シェフ伊藤は顧客が「本当に食べたいもの」のヒントを探ります。
②現状分析・要求のパース
「パース」と聞いて、ITエンジニアの諸兄であれば、まず思い至るものが
あるのではないでしょうか。
そう、「パース（構文解析）」のことです。XMLやJSONとか、
その類の「非構造化データ」を解析し、プログラム上で扱える形に変換する
あの作業の話をしています。
言ってしまえば、この工程では、ITエンジニアはそうした役割を求められます。
上述の「ヒアリング」で得られる顧客の要望は、多くの場合、
そのままシステム化できるような情報形式ではありません。
言ってしまえば、自然言語で語られる「非構造化データ」といったところか。
イメージつきにくいですよね？例えば、こんな会話が飛んでくると思ってください。
あと、山田さんが外出先でもスマホで見たいって言ってた気がする。
セキュリティはバッチリ、でもログインは楽な感じでお願いね！」
——お分かりいただけたでしょうか。
これが偽らざるリアル。これぞ人間のコミュニケーション。
つまり、「システム化するには曖昧すぎる」ことがほとんどなわけですね。
(なんなら、筋道立ってる分これでも易しいくらい)
-
1. 「山田さん」：急に知らない人の話出さないで（エンティティの欠如）
割と良くあることとして、「登場人物(ステークホルダー)」の整理をしていても、
ヒアリングの中でいきなり知らない人の話や要望が出ることがあります。
山田さんは「ユーザー」なのか「管理者」なのか、はたまた「外部業者」なのか全く不明です。
そもそも「山田さんの意見」自体、特定の個人の願望なのか、組織としての要件なのか。
「山田さん」という変数を定義できない曖昧さが困る。 -
2. 「いい感じ」じゃ実装できない（関数の不備）
「自動化」、素晴らしい。我々の専門分野です。実にいい。
――いいのですが、トリガーは何で、どこにデータを出力するのか。
「いい感じ」って、「どういう感じ？」
曖昧な要求が一番困る。
エンジニアはここで「具体的なステップ」まで分解（デコード）する必要に迫られます。 -
3. 「バッチリ」と「楽」の矛盾（トレードオフの衝突）
セキュリティをガチガチに（バッチリ）すれば、利便性（楽）は損なわれるのが常。
この矛盾した値をどう調整するか。優先すべきはどっち？
というか何をもって「バッチリ」とするか、「楽」とするか。
感覚だけで要望されるのも割と困る。
こうした曖昧さ、不確定さを含有する「要望」に対し、
システムと人間の境界に立つエンジニアは、システム化するために
可能な限り曖昧さを排除し、要望に含まれる情報を最小単位まで
分解する役割を求められるのです。
顧客要望を「パース（構文解析）」しよう
● 誰だよ！な「山田さん」をオブジェクト化する
「山田さんは、外出先でスマホを使ってどんな作業をされる方ですか？」と質問します。
これにより、山田さんが「外勤営業」であると判明しました(ロール)。
さらに、必要な「権限」や「表示すべきデータ範囲」という属性を深掘りし、定義していきます。
● 「いい感じ」を具体的なロジックへ分解する
顧客要望を深掘りし、「入力が面倒」の正体を突き止めましょう。
手入力が嫌なのか、二重入力が嫌なのか？
解決策は「既存のExcelをインポートする機能」か「APIによる自動連携」なのか。
「いい感じ」という希望を、具体的な仕様に昇華させていきます。
● 「矛盾」に優先度（Priority）を付ける
「セキュアかつ楽」という二兎を追う顧客に対し、こちらから優先順位を示しましょう。
「生体認証を使ってログインの手間を省きつつ、二要素認証でセキュリティを担保する」
といった具体案を提示したり、あるいは「今回は利便性を最優先にする」といった合意を取り付けます。
矛盾というロジックエラーを放置せず、その場で解消するのがエンジニアのヒアリングです。
Ristorante Ecomott 👨🍳
(料理に喩えると：謎の持ち込み食材の鑑定)
⇒ シェフ伊藤は、ある日常連さんから、持ち込み食材の調理を依頼されました。
「これ、山田さんの家の庭で採れた謎のキノコなんだけど、いい感じに調理してよ！」
その常連さんは、そう言い残すと酔いつぶれて寝てしまいました。
手がかりは、それだけです。
「毒はないか？ 生でいけるか？ そもそも食べ物か？」
料理以前に、まず食材の鑑定（現状分析）を行なわなければいけません。
シェフ伊藤はキノコを図鑑と照らし合わせ、種類を特定し、食べられるキノコであると断定します。
さらに、「これは煮ると出汁が出る」「これは軸が固い」「これは熱を通すと香りが立つ」
と特徴を分解（パース）していきます。
ここまでくれば、シェフ伊藤の頭の中には、いくつかのレシピが浮かんでいます。
「この軸は細かく刻んでスープのベースに、傘の部分は食感を活かしてソテーにしよう」
そうした細かい「仕様」へと落とし込んでいくのです。
③真意・ニーズの抽出
顧客のヒアリングを進め、対話を進める中で、その要望を明確化・分解までは
行いました。が、まだ具材が揃っただけ。その具材の中から、要望の「本質」を
抽出しなければ、システム化は実現できません。
顧客の語る「要望」の中には、必ずその要望を抱くに至った原因、
すなわち、「真意」や「ニーズ」が隠れています。
では何故、「真意・ニーズの抽出」が欠かせないのでしょうか？
その最たる理由は、
・技術者が考える「最善」と顧客の考える「最善」のズレ
・顧客の思い込み
にあります。
そのズレを正しく修正するために、「真意・ニーズの抽出」が
必要となるのです。
【例】「計測データをエクスポートしたい」という要望の「真意」
● エンジニアの考え
「Excel出力で、見た目も綺麗に整形してエクスポートすれば、
すぐに使えて顧客にとっても利便性が高いだろう（＝技術者の最善）」
● 顧客の真意
「計測データをエクスポートしたい」
(構文解析……)
⇒「30年前に導入された基幹システムにデータを取り込む必要があり、
そのシステムがCSV形式しか受け付けない」
(真意)
⇒「30年前に導入された基幹システムにデータを取り込めるよう、
CSVでデータをエクスポートしたい」（＝顧客の最善）
極端な例ですが、担当の顧客がエクスポート形式なんて知らない、現場から
遠い方であれば、このような善意のすれ違いは発生し得るでしょう。
このように、顧客の語る「要望」には必ず「背景」があり、その事情によっては、
技術者が考える「最善」が「最善とは限らない」ケースも多々あります。
顧客とのコミュニケーションによって、「要望」だけではなく、その根源となった
「背景事情」や「展望」なども組み上げて。「本質的な最善」に導くのが、
「ヒアリング」の本質と言えるでしょう。
【例】要望に潜む「思い込み」を技術者視点で「補正」する
● 顧客の要望
「現場の点検結果を本部に報告するために、スマホで撮影した写真をメール送信する機能が欲しい」
● 要望に潜む「思い込み」
・「情報の共有＝メールを送る」という、既存の業務フローに固執した手段
（メールを送る手間や、添付し忘れ、本部での受信・整理といった付随する苦労、
現行でのメール運用でのオペミスまでそのまま新システムに導入してしまう）
● エンジニアの知見を活かした補正
「メール機能ではなく、アプリからクラウド側へ写真をアップロードする機能を作りましょう。
メールを送る手間は不要ですし、本部も好きな時に監視画面を開けば良いだけです。
通知機能があれば確認漏れ対策にもなりますし、パッケージの標準機能なので安価で実装できます。」
先の例とは逆に、顧客が「こうしなければできない」「これはできない」と
思い込んでいたことが、エンジニアの知見では「もっとシンプルにできる」
「簡単に実現できる」というケースも往々にしてあり、また顧客が期待している仕事
でもあります。
いうならば、ヒアリングにおけるITエンジニアの腕の見せどころ、というわけですね。
最後に、「レストラン・エコモット」の例で、ここまでの「ヒアリング」について振り返ってみましょう。
Ristorante Ecomott 👨🍳
(料理に喩えると：食材を知り尽くしたプロのオススメ)
⇒
「なんか面白い肉とか入荷してない？最近ゴー○デンカ○イの映画観たから
ジビエに興味あるんだよね」
ある日、常連のひとりにそんな質問を受けたシェフ伊藤。少し考えた末、答えます。
「ちょうど、先日駆除されたてホヤホヤの熊肉がございます」
「シェフってたまにノンデリなことあるよね……まあいいや。熊肉食べたい」
「かしこまりました。料理のご希望があれば承りますよ」
シェフ伊藤の申し出に、常連さんは考え込みます。
「あ～、熊肉って臭みあるイメージなんだよね。獣臭いの苦手だからなあ。
よく聞くのはカレーだよねえ」
（ヒアリングによる【顧客意向・懸念の抽出】）
「はい、ですので用意がございます。すぐにご提供できますよ」
実際、熊肉の食べ方としては熊カレーはポピュラー。熊肉を入手した時点で、
シェフ伊藤はカレーを鍋いっぱいに煮込んで準備していました。
（【事前準備】予測されたニーズに対して、準備しておくとよい）
しかし、常連さんは渋い顔で言います。
「カレーはなあ、昼に食べちゃったんだよ。でも熊食べてみたいし……
クセ強いのはちょっとだけど、カレーだとカレーの味になっちゃうのがなあ」
（【制約事項の発覚】昼飯との重複。カレー味＝本来の価値を損いたくない）
ここでシェフ伊藤は、こう分析します。
【要望の分析（パース）】
①お客様は熊肉に興味=「ジビエ体験への期待」がある
②お客様は昼にカレーを食べた=今は「最善」な手段ではない
③お客様は臭みは苦手=品質的なNGは明確
【真意の構造化】
「カレーを食べたい」ではなく「臭みのないジビエを、カレー以外で楽しみたい」と定義
（【知見による補正】ヒアリング結果と料理人の知見から、本質的要望に寄り添う解決案の提示）
「——承知いたしました。では、香草ローストというのはいかがでしょう？」
シェフ伊藤がそう判断したのには、理由があります。
ひとつ、この熊肉は、昨日狩猟されたばかりで鮮度が良く、処理も完璧な逸品だから。
ふたつ、ハーブでマリネされ、黒胡椒が利いた香草ローストなら、獣臭さは緩和できるから。
そして、みっつめの理由は――
（【付加価値の提案】顧客の背景に合った、最後の一押し）
「臭みはありません。特有の風味がありますが……すごくビールに合いますよ。」
（【合意形成】本質的なニーズが満たされる）
それを聞いて、常連さんは笑顔で答えます。
「……それだ！シェフ、それで作って！」
長くなりましたが、ここまでが「ヒアリング」工程とはどういうものか、という解説となります。
こうしてみると、「ヒアリング」が「顧客の声」から始まって、その本質を抽出するために
「深掘り」していく工程であることがわかりますね！
このように、「ヒアリング」とは「御用聞き」に非ず。
論理思考力がおおいに求められる工程となります。
言ってしまえば、リアルタイムでロジックを組み立てながら、同時並行で
コミュニケーションを行なう厄介な工程といえます。
要領だけであれば、上述の通り、思ったよりはずっとシンプル。
でもこの工程は、システムではなく「人間」が主役。だから難しいんですね。
営業とITエンジニアの「ヒアリング」の違い
Q： 営業の仕事じゃないの？
さて、若いエンジニアが「ヒアリング」の場に駆り出される時、
8割方がこう考えるとされています。
これ、営業の仕事じゃね？
いや、さっきプロの知見がどうのと書いたくらいだし、ITエンジニアが
ヒアリングをする意義はわかる。わかるよ？
でもそれを言ったら、顧客とのコミュニケーションの「プロ」って誰だ？
・・・・・・営業じゃん
何か矛盾しているような気がしてきたような、そうでもないような。
本当に、「ヒアリング」はITエンジニアが行なうべき工程なのでしょうか？
せっかくなので、そうはいかない理由についても、ざっくり解説してみましょう！
A: 役割が違います
身も蓋もないことしか言えない議題なので、結論から言います。
果たすべき「役割」が違うので、エンジニアがするべき「ヒアリング」は
営業にはできません。逆も然り。
一流はどちらもできちゃうんだけどね、すごい
以上、閑話休題！は流石にアレなので、もう少し解説を。
正確には、エンジニアと営業では、「ヒアリング」で深掘りしたい「目的」が違うのです。
| 比較項目 | 営業担当のヒアリング | ITエンジニアのヒアリング |
|---|---|---|
| 主な目的 | ビジネスの合意・受注 | 実現性の検証・仕様の確定 |
| 注視する情報 | 予算・納期・決裁フロー（契約） | 整合性・データ構造・制約（製品仕様） |
| 得意なアプローチ | 期待を「広げる」 | 実現を「深める」 |
こうしてみると、一目瞭然。「顧客と話す」という手段が共通しているだけで、
そもそも「目的」が異なることがわかりますね。
実際には、それほど明確に切り分けられないところも多いのですが、少なくとも
・営業は「ビジネス(契約)」主体
・エンジニアは「製品/サービス」主体
で、知りたい/決めたいことがあり、顧客に対して深掘りしていく必要がある、ということです。
具体的にどう違う？
5W1Hという、みなさんご存じのフレームワークがありますね。
前項で、ヒアリングがどういう工程かについては嫌というほどみてきましたが、
言うなればヒアリングは、5W1Hを明確にして、突き詰めていく工程と言えます。
ヒアリングにおけるエンジニアと営業の役割・目的の違いは、
この5W1Hへのアプローチに、明確に表れます。
| 項目 | 営業担当の主な関心 | ITエンジニアの主な関心 |
|---|---|---|
| Who / Why | 「誰が」決裁し、「なぜ」予算を出すのか. | 「誰が」使い、「なぜ」この機能が必要か。 |
| When / Where | 「いつ」受注し、「どこで」他社に勝つか。 | 「いつ」バッチを回し、「どこで」使われるか。 |
| What / How | 「何を」売り、「どう」期待に応えるか。 | 「何を」作り、「どう」実装・運用するか。 |
同じ「いつ（When）」に対しても、営業が気にする「いつ」と、
エンジニアが気にする「いつ」の意味がまるで異なることがよくわかりますね。
日本語って面白い。
特に向き合い方の違いが出るのは、「What」と「How」、つまり、
・営業：「何を（What）」について合意するプロ
・エンジニア：「どうやって（How）」について具体化するプロ
として、それぞれのアプローチで、顧客の要望に向き合っていく作業であると言えるでしょう。
なぜエンジニアが「ヒアリング」するのか
違いが分かったところで、結論編となります。
ITエンジニアがヒアリングに関わる必要がある最大の理由は、「実現可能性」の批評と、
「仕様の解像度向上」のためといえます。
言ってしまえば、「北風と太陽」の「北風🌀」の方。顧客要望に対し、
営業は「出来る！」前提でポジティブな、足し算的アプローチを行ないますが、
エンジニアは「出来るのか？」と敢えてネガティブな、引き算的アプローチを行なうのです。
(エンジニアと営業のアプローチの差異)
| 項目 | 営業のアプローチ | エンジニアのアプローチ |
|---|---|---|
| 主な目的 | 課題の把握、予算・納期・成約の合意 | 技術的な実現可否（フィジビリティ）の確認 |
| 視点 | 顧客のビジネスゴール、対価 | システムの構造、データ、運用負荷 |
| 深掘りする点 | 「なぜこれが必要か？」 「いつまでに？」 |
「例外処理はどうするか？」 「今のシステムとつながるか？」 |
| リスク管理 | 予算オーバー、失注、競合他社 | 技術的負債、バグ、仕様の矛盾 |
(エンジニアでなければできないヒアリング)
-
1. 膨らみ過ぎた夢と希望に「待った！」
顧客の「やりたい（What）」に対し、システム的な制約から
「それはできません」「やるならこれだけのコストとリスクが伴います」
と判断できるのは、実装を知るエンジニアだけです。
And what’s more, 「こうすればできます」と手を差し伸べられるのも、
エンジニアだけなのです。
技術者視点で「正しい着地点」を探ることが、プロジェクトの迷走を防ぎます。 -
2. 「言外の制約」を掘り起こせる
顧客は「データが壊れる可能性」や「特殊な操作をした時の挙動」まで
考慮して要望を出すことはありません。
エンジニアが直接話を聞くことで、顧客自身も無意識に前提としている
「当たり前（非機能要件や例外処理）」を、設計に必要なレベルまで「深掘りして」
引き出すことができます。
つまり、エンジニアのヒアリングとは、「御用聞き」ではありません。
営業が結んだ「What（何を作るか）」という約束を、エンジニアが「How（どう作るか）」
という現実的な設計に具体化させる。
このコンビネーションの実現こそが、エンジニアがヒアリングに駆り出される理由といえるでしょう。
まとめ：ヒアリングは難しい
中編では、今回は要件定義の「ヒアリング」について、その定義とエンジニアが参加する意義について解説しました。
- ヒアリングは「聞く」だけではない：
情報のインプットに加え、「構造化（パース）」し、「本質を抽出」するまでが一連のプロセスである。 - ヒアリングの本質は「深掘り」力：
顧客の要望から細かく深掘りしていき、要件化する論理思考力が必要である。 - 営業とエンジニアのヒアリングは別：
営業がビジネス的な「What（合意）」を取り、エンジニアが技術的な「How（実現）」を担保する。
いわば車の両輪、どちらが欠けてもプロジェクトは走り出せない。 - 「ヒアリング」でのエンジニアの役割：
顧客の「要望」に対し、技術的な実現可否を批評する。
ここまで読んでみて、初学者の方はきっとこう思うはずです。
——なんか、ヒアリングって……ムズくね？
ってな具合に、身構えてしまった方もいらっしゃるかもしれません。
そう、残念ながら、ヒアリングは難しい工程なのです。
と、いうわけで次回は、「実践編」です。
「なぜヒアリングは難しいのか」を深掘りし、その上で「実践」の考え方やテクニックについて、
紹介していければと考えています！
採用情報
エコモットは今年で19周年！🎉
エコモットでは、共に「未来の常識を創る」スタッフを随時募集しています。
ヒアリングのスペシャリストとかお待ちしてますよ
弊社に興味がある方はぜひ下記の採用ページをご覧ください！
