Hello Ecomott!
おはようございます、こんにちは、あるいはこんばんは。またも前回執筆から約半年が経過、
>相も変わらず遅筆が身上、お久しぶりのクラウドソリューション開発部 伊藤です。
以前の記事では、「要件定義」工程の原理原則について取り挙げました。
前回の結びで、「次回はより実践的な内容で、お会いしましょう！」などと言ってしまったものだから、テーマ探しもまあ大変。
どうしたものかと頭を悩ませてみましたが……ここは敢えて奇を衒わず、上流工程の最上流にして花形(というイメージのある)工程、
「ヒアリング工程」についてお話しいたしましょう!
なお、本記事は「要件定義 ヒアリング工程」解説記事の前編となります。
まあまあ長くなりましたが、どうぞお付き合いください(このブログ見てるってことは時間あるでしょ)。
この記事を読むのにかかる時間は 約10分 くらいです！
この記事でわかること
前回のおさらい：要件定義工程とは
「要件定義」ってそもそもなんだっけ
本題に入る前に、前回記事で学んだ「要件定義」とはなにか、簡単におさらいしておきましょう。1. 要件定義とは：ユーザーの「願い」を「仕様」に変える工程である
⇒前回記事では、「機能・非機能・ビジネス」の３大要件を、レストランに例えて解説！
- ビジネス要件：ビジネスプロセスや業務フローに関する要件
⇒具体例：売上の増加、コスト削減などの実現したいこと
⇒レストランに例えると： (例)「手頃な価格」で「美味しいものを食べて」満足したい - 機能要件：システムが提供すべき具体的な機能やサービスに関する要件
⇒具体例：商品の検索機能など要求される機能
⇒レストランに例えると： 料理のコース内容やステーキの焼き加減など料理そのもの - 非機能要件：性能、信頼性、セキュリティなど、システムの品質に関する要件
⇒具体例：ページの表示速度、個人情報保護などの性能や品質
⇒レストランに例えると： 料理の提供スピードや接客の質などサービス品質
2. 要件定義の目的とは：一番はプロジェクトの「火種」を潰すためにある
⇒要件定義は、以下の3つの効果を期待して行われる工程であると紹介しました。
- プロジェクトの方向性を明確にする
⇒全員が目指すべきゴールを定める。 - 共通理解の形成
⇒ステークホルダー間の認識のズレをなくす。 - 共通理解の形成
⇒後工程での「そんなはずじゃなかった」を防ぐ。
3. 失敗するとどうなる？：「つらい」
⇒プロジェクト失敗の原因の過半数は要件定義工程にある、と紹介しました。
- リソースの無駄遣いの発生
⇒不要な機能の開発に時間と金と信頼が溶けていく。 - プロジェクトの迷走
⇒方向性が定まらず、スケジュールが崩壊していく。 - 精神的疲弊
⇒度重なる手戻りの発生が「つらい」、迷走するプロジェクトは、チーム全員の心を折る。
折れた者から消えていき、雪だるま式に負荷が増えていく。
サクッと振り返ってみましたが、「要件定義」の原理原則について、なんとなく把握していただけましたでしょうか？
ついてこれてないよ！という方は前回記事をご覧いただくとして、
次章からいよいよ、本題に入っていきましょう。
要件定義工程における「ヒアリング」とは
「要件定義」工程をフローで見てみよう
「ヒアリング」工程の話をする前に、件の工程がどこでどんな役割を目的としたものなのか、理解する必要があります。「要件定義」工程について、経済産業省が定めるところのシステム管理基準を基に、
簡易的なフローを作成してみました。
長々と語っていくのもボロが出そうなので、サクッと見ていきましょう。
要件定義プロセスの全体フロー
必ずしも決まった工程があるわけではありません。
ですが、ほとんどの場合に、欠かすことが出来ない必須の工程が、上記フローとなります。
こうして見ると、「ヒアリング」工程は「準備」工程の結果を踏まえて実施され、
「構造化・定義」の材料となっていくというフローであることが読み取れますね。
で、あれば。まずはヒアリングのための「準備」について知らなければなりませんね。
「ヒアリング」とは：ゼロから始めるものではない
システム開発……というかビジネスにおいて、本当の意味で「ゼロベース」、徒手空拳で行わなければならないケースは、実のところ極めて稀なケースと言えるでしょう。
それもそのはず、システムを開発するということは、「システムの目的」と「システムを使う人」、
そして「システムを提供する人」が必ず存在するからです。
逆を言えば、これらが不透明なままでは、ヒアリングという土俵にすら立てないということです。
はい、察しの良い読者諸兄であれば、もうわかりましたね？
「ヒアリング」工程の前段階に当たる「準備」工程とは、そういう工程となります。
以下にまとめてみましたので、「ヒアリング」の前提知識として、脳みそに叩き込みましょう。
初学者の方にはピンとこない部分もあるかと思いますので、今回も「料理」に喩えて雰囲気をつかんでもらえればOK。
「ヒアリング」とは：下準備が必要
1. 「プロジェクトの目的」を決めようこの段階で、「何をどこまでやるか」という「目的/ゴール」のマスタープランを
決めてしまいましょう。
今日の晩ごはんを作るとき、「何を食べたい？」と聞いてみて、「なんでもいい」
と返された時が一番困りますよね？
つまりはそういうことです。
食べたい料理が何もわからないと、調理するどころか材料すら買いに行けませんよね？
せめて「がっつり」なのか「あっさりめ」なのか、それくらいは決めたい。
ここはそういう「準備」です。
本項に限らず、要件定義の多くは「文書/ドキュメント」の作成と合意がワンセットで進みます。
この段階では、決め事として以下のような文書がやり取りされることが多いです。
| 文書名 | 概要 | 作成者 | 「料理」に喩えて |
|---|---|---|---|
| RFP（提案依頼書） | 「こんなシステムが欲しい」と要望をまとめた公式文書。 | 顧客/発注者 | 「お客様からのオーダー表」 「今日は肉が食べたい」「旬の野菜を使って」といったリクエスト表 |
| RFP / 概算見積 | 顧客の要望と、それに対する「だいたいの金額・規模」の合意。 | 開発陣(PM) →営業 |
「宴会の予約」 「1人5,000円で、肉をメインにしたコースを」という事前予約。 |
| 提案書 / SOW | 開発側が「この範囲をこの金額でやる」と合意した契約上のゴール定義書。 | 開発陣(PM) | 「本日のコース内容とご予算」 「1,0000円のコース」で合意し、予算内で出来るコースを考案できるようにする |
| プロジェクト計画書 | 「誰が」「いつまでに」「どの範囲を完成させるか」という「開発のルール」作成 | 開発陣(PM) | 「本日のコース内容と提供時間」 「2時間で全7品出す」という、店側と客側の約束事。 |
2. 「登場人物(ステークホルダー)」を整理しよう
システム開発でも料理でも、そこには「作る人」「使う人/食べる人」「代金を払う人」など、
様々な役割を持った登場人物が関わってきます。
ビジネスの世界においては、こうした利害関係を有する登場人物たちをステークホルダーといい、
そのロール(役割)やキャスト(誰がその役割か)について、ある程度整理することが望ましいとされます。
(「ヒアリング」するにも、誰から何を聞き出せばよいか、等で関わってくる)
なんだか難しそうですが、実のところ「誰が」「何をする人か」で繋げていくだけで、
プロジェクトが動き出した時点でなんとなく決まっている部分も多かったりします。
| 名称 | 概要 | 「料理」に喩えて |
|---|---|---|
| ステークホルダー・マッピング | 決定権者、現場担当者、その他関係者(法務部門、審査部門)などの関係性を図解したもの。 関係各所を漏れなく把握することで各種調整を円滑にする。 |
「どなたが主賓で、誰がお支払いを？」 食べるのは子供でも、金を払う親が「野菜も食べさせろ」と言えば、それが絶対のルールになる。 |
| 連絡窓口 / 体制図 | 「何かあった時に誰に連絡するか」「誰が最終決定するか」の公式なルート。 プロジェクト計画書に含まれることも多い。 |
「幹事⇔店間の連絡窓口」 追加注文やトラブルの際、誰と話せば話が早いのかを明確にしておく段取り。 |
一部は前述の「プロジェクト計画書」に掲載されたりという形で、公式文書となることもあります。
3. 「ヒアリング」の準備をしよう
遂に来ました、「ヒアリング」関連。まあここまでも全部関連っちゃ関連ですが。
ここまでの作業はどちらかというと受け身、顧客の要望や状況を確認する、いわば相手ターン。
ここからが俺のターン、というわけですね。
「ヒアリング」というと、実に受動的な工程にも聞こえます。
が！それは大きな間違い、 致命的と言ってもいいです。
ここで受動的になっていては、「何作る？」と聞いて「なんでもいい」
と返された時の困惑と何も変わりません。
料理を頼んでほしければ、まずメニューを作れ。
そんな、偉大なシェフが遺した格言があります
と、いうわけで。料理を作るより先に「メニュー表」を提示しましょう。
| 名称 | 概要 | 「料理」に喩えて |
|---|---|---|
| ヒアリングシート | 設計に必要な情報を漏れなく回収するための「問診票」。 事前に顧客に連携しておくと、より深堀りした問診に集中できる。 |
「オーダー確認票」 「焼き方は？」「ソースは？」と、プロとして聞くべき項目を整理したメモ。 |
| アジェンダ | ヒアリングの「目次」。今日決めるべきこと、話す順序を記した進行表。顧客の時間を奪わないための配慮であり、脱線させないための縛め。 | 「本日のお品書き（進行）」 「今日はメインの焼き加減を決めます」と、話し合いのテーブルを支配する。 |
実のところ、顧客も具体的に何を話せばいいか、図りかねているケースが大半だったりします。
そもそも「専門家」は「ヒアリングする側」であって、解決策を求めてエンジニアに
相談してきている場合がほとんどな訳ですからね。
だからこそ、「メニュー」を提示するように、情報収集の導線を準備する――といった形で、
主導権を握りながら進めていくことが、ヒアリングを実施するエンジニアには求められるのです。
上述の通り、多くの場合、顧客はエンジニアに、専門的知見による要望の実現を求めています。
敢えて露悪的な言い方をしますが、ガンガン誘導していくくらいのつもりで、
主体的にヒアリングを進めましょう！
4. 今ある「手札」を把握しよう
さて、上記で「ゼロベースで開発を行わなければならないケースは稀なケース」とした通り、
ほとんどの場合、プロジェクト開始の時点で、みなさんには何かしらの「リソース」や
「情報」といった「資産」があるはずです。
言ってしまえば、冷蔵庫の中身やキッチンの設備を確認したり、
作りたい料理のレシピを知っているかを思い返す、といったような工程ですね。
| 名称 | 概要 | 「料理」に喩えて |
|---|---|---|
| 現行業務資料 | 今の業務フロー、Excelの運用、現行システムの仕様書など。 | 「お客様のこれまでの食習慣」 「普段はこれくらいの量を、この時間帯に食べている」という現実のデータ。 |
| 自社のアセット/ナレッジ | 自社パッケージ、過去の類似事例、活用可能なエンジニアリソース。 | 「冷蔵庫の中身とシェフの腕前」 「得意料理は何か」「材料は揃っているか」という、自分たちの実力の把握。 |
| インフラ / 制約 | 使用可能なサーバー、予算、リリース期限などの物理的な「縛り」。 | 「キッチンの設備と客の持病」 「コンロが一口しかない」「塩分制限がある」といった、動かせない前提。 |
顧客の要望、抱えている課題に対し、
・自社で有しているパッケージソフトで対応できる
・類似事例への対応実績による知見がある
・PMが業界に明るい
などといった資産があれば、ヒアリングの際に、建設的な提案を行なったりできますよね。
逆に、
・その技術・業界の知見が自社にない
・人的リソースが無い
といった風に、資産に乏しい場合でも、それがわかったことが最大の収穫になり得ます。
不安材料を事前に把握できていれば、
・プロジェクト開始の段階で「知見のあるスタッフを調達する」
・追加人員の外注費を予算に織り込む
といった手を打つ余地が、この時点ではありますよね？
だってまだ、プロジェクトの方針を決める段階なんですからね！
いずれにしても、現状の手札を把握・整理しておくことが、
「要件定義」の第一歩となるといえるでしょう。
【まとめ】
「ヒアリング」を行なうためには、まず現状を多角的に把握し、整理することで、
顧客の要望を受け止める「準備」をする必要があります。
・「顧客と目的を明確化・共有する」
・「関わる登場人物を明確化する」
・「ヒアリングを主体的に進めるための『メニュー』を用意する」
・「『持ち得るもの』『足りないもの』を正しく把握する」
⇒ゼロから何もかもを「聞く」わけではなく、入念な「準備」をして、
顧客と向き合うことが求められる。
次回予告：「ヒアリングの実施」編
ごめんなさい！今回はここまで！！ここまでお送りいたしました、『1からわかる要件定義：ヒアリング【前編】下準備』、
いかがでしたでしょうか。
「なんだか当たり前のコミュニケーションをしているだけじゃないか？」
と、感じた方もいらっしゃるのではないでしょうか。うん、大正解。
プロジェクトにおける「当たり前」を作る工程なのだから、
「当たり前」のことをいちいち確認して、明確にする。
それこそが、このフェーズで求められる「準備」の本質だと私は考えています。
「ヒアリング」の前に準備が肝要という話を紹介したところで、
長～くなってしまったので今回はここまで！
次回は『1からわかる要件定義：ヒアリング【中編】深掘り術』
いよいよ「ヒアリング」工程の本筋について解説していきますよ～！
そういえば誰も触れてない・・・・・・？
㊗コーポレートサイトが新しくなりました
2026年2月19日——エコモットは、19歳の誕生日を迎えました！🎉未来の常識に挑み続け、20年目のシーズンを迎えるエコモットを、
これからも何卒よろしくお願いいたします！！
そしてお気づきでしょうか？なんとお馴染み エコモット公式サイトがリニューアル！！
ぜひ一度、遊びにいらしてくださいね！！
