はじめに：現場ヒアリングは「聞き方」よりも「準備」で差が出る
こんにちは。ソフトウエア・サイエンス ビジネスソリューション事業部の荻荘です。現場ヒアリング、要件定義、業務分析、業務システム開発の推進などを専門としています。
システム開発やシステム刷新の初期段階では、現場ヒアリングを行う機会が多くあります。
現場ヒアリングというと、「現場に何を聞くか」「どのように質問するか」に意識が向きがちです。
もちろん、質問の仕方も重要です。
しかし、現場ヒアリングで本当に大切なのは、ヒアリングを始める前の準備です。
特に、次の3つを整理しないままヒアリングを始めると、要件定義の段階で手戻りが発生しやすくなります。
- アクター：誰が、または何が、システムに関わるのか
- 目的：各アクターは、何を達成したいのか
- 用語：関係者間で、言葉の意味は揃っているか
現場ヒアリングの目的は、単に要望をリストアップすることではありません。
現場の業務を深く理解し、解決すべき課題の優先順位をつけ、本当に必要な機能を定義することにあります。
この記事では、現場ヒアリング前に整理すべきアクター・目的・用語について、要件定義の手戻りを防ぐ観点から解説します。
この記事でわかること
- 現場ヒアリング前に整理すべき情報
- アクター整理が必要な理由
- 「欲しい機能」と「本当に必要な機能」を分ける考え方
- システム化すべき範囲と、運用で対応すべき範囲の整理方法
- 用語のズレが要件定義や設計に与える影響
この記事はこんな方におすすめです
- システム開発やシステム刷新の要件定義を担当している方
- 現場ヒアリングを行う予定がある情報システム部門の方
- 現場からの要望が多く、整理の仕方に悩んでいる方
- 要件定義後の手戻りや認識のずれを減らしたい方
- 現場部門、情報システム部門、開発会社の間で共通認識を作りたい方
ソフトウエア・サイエンスでは、現場ヒアリングを通じて、システム開発やシステム刷新の背景・目的をお客様から伺い、業務に寄り添った要件定義支援を行っています。
現場ヒアリング前に整理すべき3つのこと
現場ヒアリング前に整理すべき情報は、大きく次の3つです。
| 整理すべき項目 | 確認する内容 | 整理しない場合に起きやすいこと |
|---|---|---|
| アクター | 誰が、または何が、システムに関わるのか | 機能の対象者や影響範囲が曖昧になる |
| 目的 | 各アクターが何を達成したいのか | 「欲しい機能」と「本当に必要な機能」がずれる |
| 用語 | 関係者間で言葉の意味が揃っているか | 要件定義書や設計書で誤解が起きる |
この3つを整理しておくことで、現場ヒアリングは単なる要望収集ではなく、業務理解と要件整理のための場になります。
一方で、この準備が不十分なままヒアリングを始めると、聞いた内容を後から整理し直す必要が生じたり、関係者間で認識がずれたりしやすくなります。
アクターを整理しないと、機能の対象者が曖昧になる
ヒアリングを始める前に、まず行うべきことは、誰が、または何が、このシステムに関わるのかを明確にすることです。
ここでいうアクターとは、システムを操作する担当者だけではありません。
システムに関わる人、組織、外部システム、ツールなども含めて整理する必要があります。
人のアクターを整理する
人のアクターには、たとえば次のようなものがあります。
- 現場担当者
- 承認者
- 管理者
- 外部委託先
- 最終顧客
- 情報システム部門
- 管理部門
同じシステムを使う場合でも、アクターによって目的や必要な情報は異なります。
現場担当者は入力のしやすさを重視するかもしれません。
承認者は判断に必要な情報を一覧で確認したいかもしれません。
管理者は、進捗や実績を集計して確認したいかもしれません。
そのため、現場ヒアリング前に、どの立場の人がシステムに関わるのかを整理しておくことが重要です。
システムのアクターを整理する
アクターには、人だけでなくシステムも含まれます。
たとえば、次のようなものです。
- 連携先の基幹システム
- 外部API
- 既存のExcelツール
- 帳票出力システム
- 会計システム
- 顧客管理システム
- 在庫管理システム
現場担当者が「入力項目を減らしたい」と言ったとしても、その項目が後続のシステム連携や帳票出力に必要なデータであれば、単純に削ることはできません。
人のアクターだけを見ていると、システム間連携や後続処理に必要な情報を見落としてしまう可能性があります。
IFの流れを俯瞰図で整理する
アクターを整理する際には、IF（インターフェース）の流れを俯瞰できる図を作ることが有効です。
たとえば、次のような観点で整理します。
- どのアクターが、どのタイミングでシステムに関わるのか
- どのシステムから、どのシステムへデータが渡るのか
- どの情報が、どの業務で必要になるのか
- 誰の操作によって、どのデータが作成・更新されるのか
- 後続工程や外部システムに影響する項目は何か
このような俯瞰図を持っておくことで、ヒアリング時に「この機能は誰のためのものか」「このデータはどこで使われるのか」を確認しやすくなります。
アクター整理は、現場ヒアリングの全体設計を行う作業だといえます。
アクターやシステム機能から、どのようなデータがどこへ連携されているかを俯瞰できる「外部IF概要図」を作成しています。
アクターや機能とIFをひも付けることで、なぜその機能を通じて連携する必要があるのか、その背景をヒアリングできます。
目的を整理しないと、「欲しい機能」と「本当に必要な機能」がずれる
アクターが整理できたら、次に確認すべきなのは、それぞれのアクターがシステムを通じて何を達成したいのかです。
ここで重要なのは、機能を聞くのではなく、目的を確認することです。
現場ヒアリングでは、次のような要望が出ることがあります。
- 「検索機能が欲しい」
- 「一覧画面が欲しい」
- 「CSV出力できるようにしてほしい」
- 「承認ボタンを追加してほしい」
もちろん、これらは重要な要望です。
しかし、そのまま機能として受け取るだけでは、本当に必要な要件を見誤ることがあります。
「何を」求めているのかを整理する
まず確認したいのは、アクターが何を求めているのかです。
たとえば、次のような観点です。
- どのようなアウトプットが欲しいのか
- どのような状態になれば業務が完了するのか
- 何を確認できれば判断できるのか
- どの情報が揃えば次の工程に進めるのか
- どの業務課題を解決したいのか
「検索機能が欲しい」という要望も、目的を深掘りすると、実は検索ではなく「特定のステータスのものを一覧で確認したい」だけかもしれません。
その場合、必要なのは自由検索ではなく、ステータス別の一覧画面や絞り込み条件かもしれません。
「どのように」求められているのかを整理する
次に確認したいのは、どのように実現したいのかです。
たとえば、次のような観点です。
- どのような頻度で利用するのか
- どのタイミングで必要になるのか
- どの画面から確認したいのか
- 何回程度の操作で完了させたいのか
- 誰が、どの端末で使うのか
- 急ぎの業務なのか、定期的な確認業務なのか
同じ機能に見えても、利用頻度や利用タイミングによって、必要な設計は変わります。
毎日何十回も使う機能であれば、操作性を重視すべきです。
月に一度しか使わない機能であれば、多少操作が多くても、開発コストを抑える判断ができるかもしれません。
機能ではなく、目的を確認する
現場ヒアリングでは、「何の機能が欲しいですか」と聞くだけでは不十分です。
より重要なのは、その機能が何のために必要なのかを確認することです。
たとえば、検索機能であれば、次のように問い直すことができます。
- なぜ検索したいのか
- 何を見つけたいのか
- 見つけた後に、どのような作業をするのか
- どの条件で探すことが多いのか
- 検索できないと、業務上どのような問題が起きるのか
このように目的を確認することで、「欲しい機能」と「本当に必要な機能」のズレを減らすことができます。
対象システムで対応すべき範囲を整理する
ヒアリングで出た要望をすべてシステム化すると、予算は膨らみ、画面は複雑になり、結果として使いにくいシステムになる可能性があります。
そのため、現場ヒアリング前には、対象システムで対応すべき範囲を整理する視点も必要です。
これは、ヒアリングの場で現場の要望を否定するという意味ではありません。
むしろ、要望を正しく受け止めたうえで、システムで対応すべきものと、運用でカバーすべきものを分けるための準備です。
すべての要望をシステム化しない
現場から寄せられる要望には、さまざまな種類があります。
- 自動化による効果が高いもの
- ミスが許されない計算処理
- 大量データの処理
- 人間の判断が必要なもの
- 頻度が極端に低い例外処理
- 一時的な運用で対応できるもの
すべてを同じようにシステム化しようとすると、開発範囲が広がりすぎてしまいます。
結果として、予算やスケジュールが膨らみ、画面や機能も複雑になり、かえって現場が使いにくくなることがあります。
システム化すべき領域と運用でカバーすべき領域を分ける
ヒアリングで出た要望は、次のように整理すると判断しやすくなります。
| 分類 | 内容 | 例 |
|---|---|---|
| システム化すべき領域 | 自動化による効果が高い、ミスが許されない、大量処理が必要 | 計算処理、データ集計、ステータス管理、承認履歴管理 |
| 運用でカバーすべき領域 | 頻度が低い、人間の判断が必要、一時的な対応で足りる | 年に数回の例外処理、個別判断が必要な承認、暫定対応 |
「それは本当にシステムで解決すべき課題ですか？」という視点を持つことで、プロジェクトのスコープを健全に保ちやすくなります。
業務の視点から人とシステムの役割を分ける
重要なのは、システム化するかどうかを技術だけで判断しないことです。
業務全体を見渡し、システムと人間の役割分担を最適化する必要があります。
たとえば、次のような観点です。
- 自動化した方がミスを減らせるか
- 人が判断した方がよい業務か
- 頻度に対して開発コストが見合うか
- システム化すると、かえって運用が複雑にならないか
- 他システムや既存ツールで代替できないか
現場ヒアリングでは、要望を聞くだけでなく、業務全体の中でどこまでをシステムで担うべきかを見極めることが重要です。
なぜ現在の業務の流れになっているのか、その背景をヒアリングすることで、アクター（人・対象システム・関連システム）と、それぞれの役割を整理できます。
用語を整理しないと、要件定義書や設計書で誤解が起きる
現場ヒアリング前にもう一つ重要なのが、用語の整理です。
用語の統一は、意外と軽視されがちです。
しかし、要件定義や設計においては非常に重要です。
同じ言葉を使っていても、部門や担当者によって意味が異なることがあるためです。
「受注日」の意味が部門によって異なることがある
たとえば、「受注日」という言葉があります。
一見すると、誰にとっても同じ意味に見えるかもしれません。
しかし、実際には部門によって次のように意味が異なることがあります。
- 現場A：注文書が届いた日
- 現場B：システムに入力した日
- システム部門：データベースにレコードが作成された日
この状態のまま要件定義を進めると、後から認識のずれが生じます。
- 画面上の「受注日」は、どの日付を表示するのか
- 帳票に出力する「受注日」は、どの定義なのか
- 検索条件として使う「受注日」は、どのタイミングを指すのか
こうした定義が曖昧なままだと、設計やテストの段階で手戻りが起きやすくなります。
曖昧な言葉を具体的な状態や数値に置き換える
用語整理では、曖昧な言葉も具体化しておく必要があります。
たとえば、次のような言葉です。
- なるべく早く
- 適切に処理する
- 必要に応じて確認する
- 重要なデータ
- 完了した状態
- 急ぎの案件
- 通常の手順
こうした言葉は、人によって解釈が変わります。
「なるべく早く」は、ある人にとっては当日中かもしれません。
別の人にとっては、3営業日以内かもしれません。
「完了した状態」も、入力が終わった時点なのか、承認が終わった時点なのか、後続システムに連携された時点なのかで意味が変わります。
そのため、曖昧な言葉は、数値や具体的な状態に置き換えることが重要です。
用語集を作成して共通言語を作る
ヒアリングの初期段階では、用語集を作成することが有効です。
用語集では、次のような内容を整理します。
- 現場で使われている言葉
- システム上の定義
- 部門ごとの使われ方
- 似た意味で使われている言葉
- 同じ言葉だが意味が異なるもの
- 帳票や画面で使う正式名称
現場で使われている言葉を尊重しつつ、システム上の定義とひも付けることが重要です。
用語を統一することで、要件定義書や設計書の記載内容に関する誤解が減り、コミュニケーションコストの削減につながります。
用語を統一するだけではなく、その用語が業務上どのような意味を持つのかを整理するようにしています。
業務上の意味を明確にすることで、それぞれのデータを正しくシステムへマッピングできます。
現場ヒアリング前チェックリスト
現場ヒアリング前には、次の項目を確認しておくと、ヒアリングの精度を高めやすくなります。
| 確認項目 | 確認したいこと |
|---|---|
| アクター | システムに関わる人・組織・外部システムを整理できているか |
| 利用者 | 実際に操作する人、承認する人、参照する人を分けて整理できているか |
| システム連携 | 連携先の基幹システム、外部API、Excelツールなどを把握できているか |
| IFの流れ | どこからどこへ情報が流れるかを俯瞰できているか |
| 目的 | 各アクターが何を達成したいのかを整理できているか |
| 機能要望 | 要望の裏にある目的を確認できているか |
| システム化範囲 | システムで対応すべきものと運用で対応すべきものを分けられているか |
| 用語 | 部門間で意味が異なる言葉を洗い出せているか |
| 曖昧表現 | 「なるべく早く」「適切に」などを具体化できているか |
| 成果物 | アクター図、IF整理、用語集などを準備できているか |
このチェックリストは、ヒアリング後の整理にも使えます。
ヒアリングで得た情報をこの観点で見直すことで、抜け漏れや認識のずれを発見しやすくなります。
「全体フロー」として表現することで、業務やデータの流れが可視化され、関係者間の共通理解を形成する資料として活用できます。
よくある質問
Q. 現場ヒアリング前に準備すべきことは何ですか？
主に、アクター、目的、用語を整理しておくことが重要です。
具体的には、誰が、または何がシステムに関わるのか、各アクターが何を達成したいのか、関係者間で言葉の意味が揃っているかを確認します。これらを事前に整理することで、ヒアリングの精度を高めやすくなります。
Q. アクター整理とは何ですか？
アクター整理とは、システムに関わる人、組織、外部システム、ツールなどを明確にすることです。
現場担当者や承認者だけでなく、連携先の基幹システム、外部API、既存のExcelツールなども含めて整理します。
Q. なぜ機能ではなく目的を確認する必要があるのですか？
現場から寄せられる要望は、必ずしも本当に必要な機能そのものとは限らないためです。
たとえば「検索機能が欲しい」という要望の裏には、「特定のステータスのものを一覧で確認したい」という目的があるかもしれません。目的を確認することで、より適切な要件に整理できます。
Q. すべての要望をシステム化すべきですか？
すべてをシステム化する必要はありません。
自動化による効果が高い業務や、大量データ処理、ミスが許されない計算などはシステム化に向いています。一方で、頻度が低い例外処理や人間の判断が必要な業務は、運用でカバーする方が適している場合があります。
Q. 用語の統一はなぜ重要ですか？
同じ言葉でも、部門や担当者によって意味が異なることがあるためです。
たとえば「受注日」が、注文書を受け取った日を指すのか、システムに入力した日を指すのか、データベースに登録された日を指すのかで、設計内容は変わります。用語を統一することで、要件定義書や設計書の記載内容に関する誤解を減らせます。
Q. 現場ヒアリングは、どのタイミングで行うべきですか？
システム開発やシステム刷新の初期段階で行うべきです。
ただし、ヒアリングを始める前に、アクター、目的、用語、システム化範囲をある程度整理しておくことが重要です。準備がないまま現場へヒアリングを行うと、後から情報を整理し直す作業が増えやすくなります。
ソフトウエア・サイエンスでは、現場ヒアリングを通じてお客様の業務や要件を正しく理解し、その内容を基に設計・開発まで行うことができます。
また、その業務理解をシステム運用にもつなげ、業務全体を見据えた支援が可能です。
まとめ
現場ヒアリングは、単なる要望収集ではありません。
お客様の業務を理解し、整理し、本当に必要な機能を定義するための重要なプロセスです。
本記事で整理したポイントは次のとおりです。
- 現場ヒアリング前には、アクター・目的・用語を整理することが重要
- アクターには、人だけでなく外部システムや既存ツールも含まれる
- 機能をそのまま聞くのではなく、その機能が必要な目的を確認する
- すべての要望をシステム化せず、システム化すべき領域と運用で対応すべき領域を分ける
- 用語の意味が部門ごとに異なると、要件定義や設計で誤解が起きやすい
- 用語集を作成することで、関係者間の共通言語を作りやすくなる
現場ヒアリングは、現場に行ってから始まるものではありません。
ヒアリング前に、誰に、何を、どの前提で聞くのかを整理しておくことが、要件定義の手戻りを防ぐ第一歩になります。
- 現場ヒアリングを予定しているが、何を整理してから臨むべきか分からない
- 現場からの要望が多く、優先順位やスコープを整理できていない
- 要件定義後の手戻りや認識のずれを減らしたい
- アクター図、IF整理、用語集などを整備したい
- 現場ヒアリングから要件定義、システム開発まで一貫して相談したい
このような課題をお持ちの場合は、SSIにご相談ください。
IT全般に関するコンサルティングから、設計、開発、運用・保守まで、一貫して支援できます。