「ベンダーへの発注前に、社内の業務フローを整理してください」——システム開発を外部に依頼しようとすると、こう言われて手が止まってしまう担当者は少なくありません。
開発会社からは「現場の業務をヒアリングしておいてほしい」と言われたものの、何を、誰に、どう聞けばよいのか。聞いた内容をどう整理すれば「使える要件」になるのか。社内には正解を知っている人がおらず、自分で進めるしかない——そんな状況に置かれている方に向けた記事です。
実は、このフェーズで実施するのが「ユーザーインタビュー」と呼ばれる活動です。要件定義書を書くベンダー側にとって、発注者の社内インタビュー結果は最も重要な一次情報です。逆に、ここが曖昧なまま開発を始めると、リリース後に「現場で使えないシステム」になるリスクが跳ね上がります。
本記事では、システム開発の発注前に行うユーザーインタビューについて、対象者の選び方・質問の設計・結果の整理方法・よくある失敗まで、非エンジニアの担当者でも実行できるレベルで解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ユーザーインタビューとは何か（要件定義における役割）
ユーザーインタビューとは、開発するシステムを実際に使う人（ユーザー）や、業務に関わる関係者から、業務内容・課題・期待する変化を直接聞き出す調査手法です。アンケートと違い、対話形式で深掘りできるため、本人も自覚していない潜在的な課題を引き出せるのが特徴です。
要件定義の前段階に位置づけられる活動
システム開発のプロセスは、おおまかに次の順序で進みます。
フェーズ | 主な活動 | 主な担当 |
|---|---|---|
要求定義 | 「何のために」「何を実現したいか」を整理 | 発注側 |
要件定義 | 要求を具体的な機能・非機能要件に落とし込む | 発注側＋ベンダー |
設計 | システム構造・画面・データの設計 | ベンダー |
開発・テスト | 実装と検証 | ベンダー |
リリース・運用 | 本番展開と保守 | 双方 |
ユーザーインタビューは、このうち要求定義の中核となる活動です。要件定義に入る前に、発注側が「現場の実態」と「解決したい課題」を把握しておくことで、ベンダーとの会話の精度が一気に上がります。
要求定義と要件定義の違いについては、要求定義と要件定義の違いとは？発注側がすべき準備を解説で詳しく解説しています。
なぜ発注側が自分で実施する必要があるのか
「ベンダーにヒアリングしてもらえばいいのでは？」と思われるかもしれません。しかし、発注側が一次情報を持たないままベンダーにすべてを任せると、次のような問題が起きます。
- ベンダーは現場の前提知識がないため、ヒアリングに想定以上の時間がかかる
- ヒアリングの方向性を発注側がコントロールできず、出てきた要件に違和感が残る
- 現場担当者がベンダーの前で本音を話さず、表面的な回答しか得られない
- インタビュー結果の解釈に齟齬が生まれ、要件定義書の手戻りが発生する
発注側が事前にユーザーインタビューを行い、業務の全体像と課題を整理しておくことで、ベンダーとの議論が「ゼロから聞く場」ではなく「整理された情報を確認・深掘りする場」に変わります。これは開発期間とコストの両方に直結します。
インタビュー対象者の選定（実務担当者・管理職・経営層）
「誰に話を聞くべきか」を間違えると、得られる情報が偏り、後の要件定義で揉める原因になります。一般的には、次の3層から最低1名ずつ選ぶのが基本です。
層別に聞くべき対象と理由
層 | 代表例 | 聞くべき内容 |
|---|---|---|
実務担当者 | 日々システムを操作する現場社員 | 実際の業務フロー・困りごと・操作上の不便 |
管理職（部門長・チームリーダー） | 業務の進捗を管理する立場の人 | 業務全体の流れ・KPI・部門としての課題 |
経営層・プロジェクトオーナー | システム導入の意思決定者 | 投資判断の基準・期待する事業効果 |
それぞれの層は見ている景色が違います。実務担当者は「目の前の作業」、管理職は「部門の生産性」、経営層は「事業インパクト」を語ります。この3層の発言を突き合わせることで、システムが解決すべき本質的な課題が浮かび上がります。
対象者を絞り込むときのコツ
実務担当者については、以下の観点で複数名選ぶのが理想です。
- 熟練者と新人の両方：熟練者は無意識に判断している部分を言語化しづらいため、新人の視点と組み合わせると業務の暗黙知が見えてくる
- 異なる拠点・チーム：本社と支店、東京と地方など、運用が微妙に異なる場合があるため
- 業務量が多い人と少ない人：業務頻度によって優先順位が変わるため
人数の目安としては、実務担当者3〜5名、管理職1〜2名、経営層1名の合計5〜8名程度が一般的です。少なすぎると偏りが出て、多すぎると整理に時間がかかります。
対象者の協力を取り付けるときの注意点
インタビュー対象者には、事前に次の3点を伝えると協力が得やすくなります。
- 目的：何のために話を聞くのか（例：「業務改善のためのシステム検討」）
- 時間：1人あたり30分〜1時間程度
- 発言の扱い：個人を特定する形では使わないこと、評価には影響しないこと
特に「評価に影響しない」と明言することは重要です。これがないと、現場担当者は上司の顔色を伺った回答しかしなくなります。
効果的なインタビューの質問設計
インタビューの質を決めるのは、当日の話し方ではなく、事前にどれだけ質問を準備したかです。準備なしの「ふんわりヒアリング」は、雑談で終わってしまいます。
質問は「業務フロー」と「困りごと」の2軸で組み立てる
非エンジニアが質問設計でつまずく最大の原因は、「機能の話」から入ってしまうことです。「どんな機能があると便利ですか？」と聞いても、相手は思いつきの回答しかできません。
代わりに、次の2軸で質問を組み立てます。
軸1：業務フロー（What & How）
「いま、どう仕事をしているか」を時系列で具体的に聞きます。
- 朝出社してから、最初にする業務は何ですか？
- その業務は、何（紙・Excel・既存システム）を使って行いますか？
- 1件処理するのに、どれくらい時間がかかりますか？
- 関わる人は誰ですか？（社内・社外）
- 月にどれくらいの件数を処理しますか？
業務フローの整理は、システム開発の発注準備に欠かせない作業です。詳しい書き方は業務フロー図とは？発注前に押さえたい書き方と5つのステップを参考にしてください。
軸2：困りごと（Pain）
「どこに不満・非効率があるか」を引き出します。
- その業務の中で、面倒だと感じる作業はどこですか？
- ミスが起きやすいのはどの工程ですか？最近のミスの実例を教えてください
- 「これさえなければ早く帰れる」という作業はありますか？
- 他部署との連携で、止まりやすいポイントはどこですか？
- 月末・月初など、特に忙しいタイミングはありますか？
ポイントは、抽象的な不満ではなく「具体的な実例」を聞き出すことです。「Excelで管理するのが大変」ではなく、「先月、Excelの数式が壊れて2時間調査に費やした」という事例まで聞けると、要件の優先度判断に使えます。
質問テクニック：5W1Hと「なぜ」の繰り返し
回答が浅いと感じたら、5W1H（Who/What/When/Where/Why/How）で深掘りします。
- 「ミスが多い」→「具体的にどんなミスですか？（What）」
- 「集計に時間がかかる」→「月に何時間くらいですか？（How much）」
- 「上司の承認が遅い」→「なぜ遅れるんですか？（Why）」
特に「なぜ？」を3〜5回繰り返すと、表面的な不満の背後にある構造的な問題が見えてきます。これは「なぜなぜ分析（5 Whys）」と呼ばれる問題解決手法と同じ考え方で、トヨタ生産方式でも使われる定番のアプローチです。
NG質問と置き換え例
NG質問 | NGな理由 | 置き換え |
|---|---|---|
どんなシステムが欲しいですか？ | 答えが「便利なやつ」になる | 今の業務で一番ストレスを感じる瞬間はいつですか？ |
AIで何ができそうですか？ | 技術ありきで、業務課題が見えない | この業務を半分の時間で終わらせるには、何が変わる必要がありますか？ |
不満はありますか？ | 「特にないです」で終わる | 直近1ヶ月で、業務中に「もう嫌だ」と思った瞬間はありましたか？ |
インタビュー結果の整理・活用方法
インタビューは「実施すること」ではなく「整理して活用すること」が目的です。録音や走り書きをそのままベンダーに渡しても、要件定義には使えません。
整理の3ステップ
ステップ1：発言録（生データ）の作成
インタビュー直後（できれば当日中）に、録音や走り書きを元に発言録を作成します。逐語録である必要はなく、「誰が」「どの質問に対して」「何を言ったか」が分かる形式で十分です。
【対象者】営業部 田中さん（実務担当者・在籍5年）
【日時】2026/04/20 14:00-15:00
Q. 月次の見積作成はどう進めていますか？
A. Excelテンプレートを開いて、案件ごとに過去の類似案件を社内ファイルサーバーから探してコピー。
そこから商品マスタを参照して単価を埋める。
この「過去案件を探す」部分に毎回30分くらいかかっている。
Q. ミスが起きやすい工程はどこですか？
A. 単価マスタが更新されていることに気づかず、古い単価で見積を出してしまうことが月1〜2回ある。
先月もそれで、5万円分の値引き対応が必要になった。
ステップ2：課題リストへの集約
複数人の発言録から、共通する課題・固有の課題を抽出して一覧化します。
# | 課題 | 影響範囲 | 頻度 | 影響度 | 発言元 |
|---|---|---|---|---|---|
1 | 過去案件の検索に時間がかかる | 営業部全員 | 毎日 | 中 | 田中・佐藤・鈴木 |
2 | 古い単価マスタで見積を出してしまう | 営業部 | 月1〜2回 | 大（金額影響） | 田中・佐藤 |
3 | 承認フローが紙で滞留 | 営業＋管理部 | 月10件 | 中 | 鈴木・部長 |
このとき、頻度と影響度の2軸でスコアリングしておくと、後の優先順位付けが楽になります。
ステップ3：業務フロー図と要件候補への落とし込み
抽出した課題を業務フロー図にマッピングし、「どの工程の、どの問題を、システムでどう解決するか」を整理します。これが要件定義書の元データになります。
要件定義の段階では、業務フローと並行して「ユースケース」という形式で機能要件を整理することもあります。詳細はユースケースとは？発注者が要件定義で知るべき意味と図の読み方で解説しています。
ベンダーに渡すべき成果物
ユーザーインタビューを終えた段階で、ベンダーに共有すべき成果物は次の3つです。
- 業務フロー図：現状（As-Is）の業務の流れを図示したもの
- 課題リスト：頻度・影響度付きの課題一覧
- インタビュー対象者リスト：誰に何を聞いたかの記録（必要に応じてベンダーが追加ヒアリングするため）
この3点が揃っていれば、ベンダーは要件定義の議論を効率的に進められます。逆に、これらが無いまま「とりあえず良いシステムを提案してください」と依頼すると、提案精度が大きく下がります。
よくある落とし穴と対策
最後に、ユーザーインタビューで失敗しやすいポイントを整理します。
落とし穴1：声の大きい人の意見だけが反映される
部長や声の大きいベテランの意見ばかり拾ってしまい、実務担当者の本音が反映されないケースです。
対策：
- 1対1のインタビュー形式を基本にする（複数人同席だと忖度が発生）
- 録音や記録は本人の同意を得て、評価には使わないと明言する
- 必ず3層（実務・管理・経営）の発言を突き合わせて確認する
落とし穴2：「現状の不満」だけ聞いて「あるべき姿」を聞き忘れる
不満は出るが、「ではどうなれば理想か」を聞かないと、システムの方向性が定まりません。
対策：質問の最後に、必ず「もし魔法でこの業務を変えられるとしたら、何から変えますか？」を入れる。回答が抽象的でも、優先順位の参考になります。
落とし穴3：機能要望をそのまま要件にしてしまう
「○○ボタンが欲しい」という現場の声をそのまま要件に組み込むと、本質的な課題解決から外れたシステムになります。
対策：機能要望の背後にある「なぜ？」を必ず確認する。「○○ボタンが欲しい」→「なぜ必要？」→「Aの作業の後にBに移動するのが面倒だから」と分かれば、ボタン追加ではなく画面統合という別解が見えてきます。
落とし穴4：インタビュー結果を発注前に整理しきれない
時間が足りず、生データのままベンダーに渡してしまうケースです。これではベンダーが整理する工数を負担することになり、結果的に開発費に乗ってきます。
対策：
- インタビュー実施前に「整理に必要な期間」を逆算してスケジュールを組む（インタビュー1日に対し、整理2〜3日が目安）
- 整理が間に合わない場合は、ベンダーに整理工程から依頼することを前提に見積を取る（コストは上がるが、品質は担保される）
落とし穴5：1回で終わらせようとする
最初のインタビューだけで要件が固まることはまずありません。発言録を整理する中で、追加で聞きたいことが必ず出てきます。
対策：1人につき2回（初回ヒアリング+確認・深掘り）の枠を最初から確保しておく。2回目は30分程度の短時間で十分です。
まとめ
ユーザーインタビューは、システム開発の発注前に発注者が行うべき最も重要な社内調査です。本記事の要点を整理します。
- 位置づけ：要件定義の前段階（要求定義）で行う活動。ベンダー任せにせず発注側が実施することで、要件定義の精度と速度が大きく向上する
- 対象者：実務担当者・管理職・経営層の3層から最低1名ずつ。実務担当者は熟練者と新人を組み合わせる
- 質問設計：「業務フロー」と「困りごと」の2軸で構成。具体的な実例と「なぜ？」の深掘りで本質的な課題を引き出す
- 整理方法：発言録 → 課題リスト（頻度・影響度付き）→ 業務フロー図への反映、の3ステップ
- ベンダーに渡すもの：業務フロー図、課題リスト、インタビュー対象者リストの3点
- 落とし穴：声の大きい人偏重・あるべき姿の聞き忘れ・機能要望の鵜呑み・整理不足・1回完結の思い込み
ユーザーインタビューに正解はありませんが、「準備された質問・3層の対象者・整理された成果物」の3点が揃えば、ベンダーとの要件定義は確実にスムーズに進みます。発注前のこの一手間が、リリース後に「現場で本当に使われるシステム」になるかどうかを左右します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
