現行踏襲に流されない要件定義の技術。現場の味方と御用聞きは違う
「今のままでいい」「変えると業務が回らない」——ヒアリングのたびに現場から返ってくるこの言葉に押し切られ、気づけば要件が現行踏襲になっていく。この抵抗は、担当者の説得力で崩すものではありません。抵抗を溶かす型は2つだけです。変える理由は経営者の口から語ってもらう。変えても大丈夫なことは画面モックアップで体験してもらう。そして忘れないでください。現場の味方であることと、御用聞きになることは違います。
この記事は、現場ヒアリングで「変わりたくない」の圧に流されがちな要件定義担当者・情報システム部門・PMに向けて書いています。読み終えると、現場の抵抗の正体が分かり、ヒアリング冒頭30秒の口上テンプレ、抵抗への返しフレーズ5選、そしてプロジェクト目的確認シート（全項目・記入例つき）が手に入ります。連載第1回「システムは経営リソースである」の考え方を、現場で実行に移すための回です。
御用聞き型要件定義とは（定義）
御用聞き型要件定義とは、現場の要望や現行のやり方をそのまま要件として受け取り、経営目的による仕分けを行わない要件定義のことである。
御用聞きは、短期的には現場に感謝されます。しかし出来上がるのは「今のやり方を高いお金で焼き直しただけのシステム」であり、経営の期待した効果は出ません。稼働後に苦しむのは、ほかならぬ現場です。
ここで区別すべきは「共感」と「同調」です。共感とは、現場の感情や事情を受け止めること。同調とは、現場の要望をそのまま要件にすることです。感情には全力で共感してください。しかし要件は、経営目的で仕分けてください。この線引きができる人が、本当の意味での現場の味方です。
なぜ「変わりたくない」に流されてしまうのか
原因1：現場の抵抗を「感情の問題」として扱っていることが原因です
現場の抵抗は、わがままでも怠慢でもありません。合理的な反応です。長年かけて習熟したやり方を手放せば、一時的に生産性は落ちます。新しい手順でミスをすれば、責任を問われるのは自分です。「変えると業務が回らない」は、現場にとっては切実なリスク認識なのです。
抵抗を感情の問題と捉えると、対処は「説得」になります。しかし合理的な理由で抵抗している相手は、理屈の応酬では動きません。必要なのは説得ではなく、リスク認識そのものを変える仕掛けです。
原因2：変える理由を「担当者の言葉」で語っていることが原因です
要件定義担当者やコンサルタントが「効率化のために変えましょう」と語っても、現場には「現場を知らない人間の理屈」としか聞こえません。むしろ語れば語るほど、抵抗は固くなります。
変える理由が現場に届くのは、それが「経営の意思」として語られたときだけです。国の機関も、経営が自ら目標を発信することの重要性を明言しています。
DXを目的としたシステム構築では業務の大きな変化を伴うため業務部門の理解が得られないことがあり、そのようなときは経営として数値レベルのシステム化目標を明確にすることが重要である。また「現行踏襲」「今と同じでいい」という要求はトラブルの元となる（要旨）
【実例】現場に押し切られた「現行どおりの機能」が、稼働後に作り直しになった
ホテルの基幹システムの案件で、現場の強い要望に押される形で、現行のやり方をそのまま踏襲した機能を実装したことがあります。結果はどうなったか。現行の例外的な運用を丸ごと写し取った機能は挙動が複雑になり、連携する他部門からはクレームが増え、肝心の要望元の現場でも結局ほとんど使われませんでした。最終的に、稼働後にシンプルな挙動へ作り直す再カスタマイズが発生し、開発費を二重に払うことになりました。
ここで知っておいてほしいのは、現行踏襲するために行った改修のコスト構造です。現場から見れば「今のやり方の機能を1つ足すだけ」に見えます。しかしシステム側では、その1機能のために連携する周辺機能の変更が発生し、変更した箇所すべてのテストが必要になります。要望としては1つでも、工数は乗数的に膨らんでいくのです。
抵抗に流されないヒアリングのやり方：4ステップ
手順は次の4ステップです。ポイントは、担当者が語る量を減らし、「経営の言葉」と「体験」に語らせることです。
ステップ1：ヒアリング冒頭30秒で「目的の錨」を打つ
ヒアリングの最初の30秒で、この場の目的を宣言します（口上の全文は記事末尾の「明日使えるボックス」に掲載しています）。骨子は3つ。①今日は◯◯という経営目的のために来た、②聞いた内容をそのまま要件にはせず目的に照らして一緒に仕分ける、③困っていなくても実態を率直に教えてほしい——です。
冒頭に錨を打っておくと、後で要望が膨らみかけたときに「最初にお伝えした目的に照らすと」と、角を立てずに戻れます。
ステップ2：変える理由は、経営者の口から発信してもらう
キックオフや全体会議の場で、経営者自身に「このプロジェクトで達成すべきこと」を現場へ発信してもらいます。ポイントは、変更を「お願い」ではなく「達成すべきこと」として語ってもらうこと。変えざるを得ない前提を、経営の言葉で作るのです。
担当者やコンサルタントが代わりに語るのは逆効果になり得ます。同じ内容でも、誰が言うかで現場の受け取り方はまったく変わります。経営者が多忙なら、発信文のドラフトをこちらで用意し、承認と発信だけをお願いしてください。
ステップ3：「変えても大丈夫」を、画面モックアップで体験してもらう
言葉でいくら説明しても、現場の「回らなくなるのでは」という不安は消えません。不安を消せるのは体験だけです。新しいやり方の画面モックアップを用意し、現場の実際の業務シナリオに沿って操作の流れを一緒に確認します。
「朝いちばんの受注確認はこの画面で、この順番で」と具体的に辿ってもらうと、「これなら回る」という納得が生まれます。作り込んだプロトタイプは不要です。紙芝居のような画面遷移で十分に機能します。
ステップ4：合意した目的を「プロジェクト目的確認シート」で固定する
ステップ1〜3で作った合意は、口頭のままでは風化します。目的・数字・やらないこと・判断者を1枚のシートに固定し、決裁者の確認を取ったうえで関係者全員に配布してください（シートの全項目と記入例は「明日使えるボックス」に掲載しています）。
このシートが、以降のすべてのヒアリングと要件判断の錨になります。
やってはいけないNGパターン
NG1：「そうですよね、大変ですよね」で終わる 共感と同調の混同です。感情への共感は信頼を作りますが、そのまま要望を要件にすれば御用聞きです。共感したうえで、要件は目的で仕分けてください。
NG2：現場の抵抗を、担当者の正論で説得しようとする 語れば語るほど「現場を知らない理屈」として抵抗は固くなります。説得をやめて、語り手（経営者）と手段（モックアップの体験）を変えてください。
NG3：「とりあえず現行どおりで作って、あとで直しましょう」と約束する 実例のとおり、現行踏襲の1機能は連携改修・テスト・作り直しで乗数的にコストが膨らみます。「あとで直す」は、二重払いの予約です。
よくある質問
現場に嫌われたくありません。それでも押し返すべきですか？
押し返すというより、判断の主語を変えてください。「私はこう思う」ではなく「この経営目的に照らすとこうなる」と語れば、対立の構図は「担当者 対 現場」ではなく「目的 対 要望」になります。
御用聞きは短期的には好かれますが、稼働後に使われないシステムで最も苦しむのは現場です。長期の信頼を選んでください。
経営者が現場への発信を引き受けてくれない場合は？
発信文のドラフトと発信の場（キックオフ・朝礼・社内報など）をセットで提案し、承認だけをもらう形にすると動いてもらいやすくなります。
それでも動かない場合は、経営目的そのものが曖昧なサインです。第1回の「経営ヒアリング冒頭質問5選」に立ち返ってください。
モックアップを作る工数がありません。それでも必要ですか？
作り込みは不要です。スライドに画面イメージを並べた紙芝居で十分です。重要なのは画面の完成度ではなく、現場の実際の業務シナリオの順番どおりに体験してもらうことです。
30分のモック確認が、稼働後の作り直し数十人日を防ぎます。
明日使えるボックス：冒頭30秒口上＋返しフレーズ5選＋目的確認シート
そのまま使える3点セットです。
1. ヒアリング冒頭30秒の口上テンプレ
「本日は、◯◯（経営目的）を実現するために、今の業務を教えていただきに来ました。今日伺った内容をそのまま新システムにするのではなく、目的に照らして一緒に仕分けをさせてください。今のやり方に困っていなくても、実態を率直に教えていただけることが、いちばんの協力になります。」
2. 抵抗への返しフレーズ5選
「変えると業務が回らない」→「回らなくなりそうな場面を、具体的に一緒に洗い出させてください。その場面を画面モックでお見せして、回ることを確認してから進めます」
「今のままで困っていない」→「困っていないことは分かりました。今日は困りごと探しではなく、◯◯（経営目的）のために変えられる余地を探しに来ています」
「前からずっとこのやり方だ」→「このやり方が守ってきた結果は何でしょうか。その結果が守られるなら、手順は変えられないか一緒に確認させてください」
「現場のことは現場が一番分かっている」→「おっしゃるとおりです。だからこそ実態を教えてください。そのうえで、どう変えるかは◯◯という経営目的で判断させてください」
「そんなことをしたらミスが増える」→「ミスが増えない設計になっているか、稼働前に業務シナリオどおりにモックで一緒に検証させてください」
3. プロジェクト目的確認シート（全項目・記入例つき）
以下の8項目を1枚にまとめ、決裁者の確認を取って関係者全員に配布してください。
プロジェクト名：（例）受発注システム刷新プロジェクト
経営目的（一文）：（例）出荷リードタイムを短縮し、欠品による機会損失をなくす
効果を測る数字：（例）受注から出荷指示までの時間 現状2日 → 目標0.5日
期限：（例）来期第2四半期の繁忙期前に稼働
やらないことリスト：（例）現行の紙帳票の完全再現はしない／年1回の特殊処理は対象外
要件が対立したときの判断者：（例）管理本部長
現場への発信：（例）キックオフで社長から「達成すべきこと」として発信（◯月◯日）
確認日・確認者：（例）◯年◯月◯日／代表取締役 確認済み
まとめ：今日の1アクション
この記事の要点は次の3つです。
現場の抵抗は合理的な反応。説得で崩すのではなく、語り手（経営者の発信）と手段（モックアップの体験）を変えて溶かす
共感と同調は違う。感情には共感し、要件は経営目的で仕分ける。それが本当の現場の味方
現行踏襲の1機能は、連携改修・テスト・作り直しで乗数的にコストが膨らむ。「あとで直す」は二重払いの予約
まずは、次のヒアリングの前に「プロジェクト目的確認シート」の項目2と3を埋めてみてください。埋められなければ、第1回の経営ヒアリング質問5選から始めましょう。
この連載について
要件定義と業務ヒアリングのスキルを「センス」ではなく「型」として学ぶ全25回の連載です。
前回：要件定義は経営目的から始めよ。システムは現場の道具ではなく、経営リソースである
次回：キックオフの30分が要件定義の成否を決める ― 「決めるのはあなたです」と伝える技術（公開後に追記します）
連載マガジン：要件定義ができる人、できない人 ― 業務ヒアリングの技術
アストロラボのほかのマガジン
noteでは、この連載のほかにも実務直結のマガジンを公開しています。
マガジン一覧はこちら：
業務調査からシステム開発まで、一気通貫のアストロラボ
私たちアストロラボは、小売・流通を中心に企業のDXを支援してきた会社です（2012年設立）。「レガシーを、セクシーに。」を合言葉に、いきなりシステムを作るのではなく、まず現場の業務を調べて流れを描き直す「業務設計」から入り、システム選定・ベンダー選定、そして最適な既製品がなければ自社での開発まで、一気通貫で伴走します。
この連載で紹介している質問の型やヒアリングの技術は、私たちが業務調査と要件定義の現場で実際に使っている考え方です。私たちはシステムを「現場の道具」である前に「経営リソース」だと考えています。現場の声を丁寧に聞きながらも、要件の採否は常に経営目的に照らして判断する。この軸があるからこそ、投資に見合うシステムを定義できると考えています。
「要件定義から手伝ってほしい」「今受けている提案や見積もりが妥当か見てほしい」「そもそも何から手をつければいいか分からない」といった入口の段階からご相談いただけます。
自社の業務に合わせた進め方を相談したい方は、お気軽にお問い合わせください。
ともに挑戦する仲間を募集しています（長期インターン）
「レガシーを、セクシーに。」——使いづらい仕組みを、思わず触りたくなるものへ変えていく。アストロラボは、その挑戦を本気で面白がれる長期インターンを募集しています（短期の受け入れは行っていません）。クライアントワーク（クライアントの現場にも足を運びます）、システム開発、営業、マーケティングまで、職種やフェーズの垣根を越えて、事業づくりの最前線をまるごと体験できます。任されるのは雑用ではなく、プロジェクトの一翼を担う本物の仕事です。腰を据えて打ち込むほど見える景色は変わり、実際に約2年のインターンを経て関連会社の社長に就任した先輩もいます。デザインやUI/UX、AI活用をはじめ、アパレル・小売・食品といった業界のDXに現場の当事者として関わりたい方を待っています。
応募はこちらのフォームからお願いします。
#要件定義 #システム開発 #アストロラボ
#現行踏襲 #業務ヒアリング #DX #ITコンサル #システム導入 #情シス #業務改善
【概要】
「変えると業務が回らない」に押し切られていませんか。抵抗を溶かす型は、経営者の発信とモックアップ体験の2つ。冒頭30秒の口上、返しフレーズ5選、プロジェクト目的確認シートを全掲載。連載第2回。
