はじめに：現場の「全部必要」をそのまま仕様にすると、なぜ失敗するのか
こんにちは。ソフトウエア・サイエンス ビジネスソリューション事業部の千葉です。現場ヒアリングから要件定義、業務分析、および業務システム開発の推進を中心に様々なシステム開発に関わってまいりました。
システム開発やシステム刷新の現場では、ヒアリングの場で次のような言葉を聞くことがあります。
「この機能は全部必要です」「どれか一つでも欠けると業務が止まります」「今の画面や帳票は、そのまま残してください」という現場からの切実な声です。
現場の業務を日々回している方にとって、今ある機能や帳票、入力項目は、どれも必要に見えるものです。実際に、その言葉の背景には、業務を止めたくないという責任感や、今のやり方を変えることへの不安があります。しかし、現場の要望をすべてそのまま仕様に入れれば、よいシステムになるとは限りません。
むしろ、画面が複雑になり、入力項目が増え、誰も使いこなせないシステムになってしまうことがあります。その結果、せっかく新しいシステムを作ったにもかかわらず、現場では紙の帳票やExcelが復活してしまうケースも後を絶ちません。
現場ヒアリングで大切なのは、要望をすべて聞き入れることではありません。「全部必要」という言葉の裏側にある不安や業務の本質を見極め、本当に必要な機能を整理することです。この記事では、現場の「全部必要」をどのように整理し、要件定義で機能を増やしすぎないようにするかを解説します。
この記事でわかること
- 現場が「全部必要」と言う背景にある不安や防衛本能
- 現場要望をすべてシステム化すると起きやすい問題
- 本当に必要な機能を見極めるための問い
- 機能を削るのではなく、業務の核を整理する考え方
- 要件定義で機能追加や保守負債を増やしすぎないための視点
この記事はこんな方におすすめです
- 現場ヒアリングで要望が多く、整理に悩んでいる方
- 要件定義で機能の優先順位を決めきれない情報システム部門の方
- 現場の要望をどこまでシステム化すべきか判断に迷っている方
- 新システムが複雑になりすぎることを避けたい方
- 本当に使われる業務システムを作りたい方
私たちはこれまで、現場ヒアリングの可視化から要件整理、本当に使われるシステム開発までを一貫して支援してきました。特に、現場の「全部必要」という要望を丁寧に解体し、真の業務課題を見極める要件整理を重視した支援を行っています。
「全部必要」という言葉の裏にある現場の不安
私はこれまで、数多くのシステム開発プロジェクトに関わってきました。かつては、現場の声を一言半句漏らさず仕様書に入れることが、エンジニアとしての誠実さだと考えていた時期もありました。現場が「必要だ」と言うなら、その機能は必要なのだ。現場が「これがないと困る」と言うなら、仕様に入れるべきなのだ。そう考えていたのです。
しかし、経験を重ねる中で、少しずつ考え方が変わっていきました。現場の「全部必要」という言葉は、必ずしも機能の必要性だけを表しているわけではありません。その裏には、今のやり方を変えることへの不安や、業務が止まることへの恐れ、責任を負いたくないという防衛本能が隠れていることがあります。
現場は業務を止めたくない
現場の方にとって、最も避けたいのは業務が止まることです。日々の業務は、多少の不便があっても、慣れたやり方で回っています。そのため、新しいシステムによって今の手順が変わることに、不安を感じるのはごく自然なことです。だからこそ、現場は「今あるものは全部残したい」と考えます。
今のやり方を変えることへの不安がある
業務には、長年の経験で積み上げられた手順や工夫があります。その中には、本当に必要なものもあります。一方で、昔のシステム制約や過去のトラブル対応が、そのまま慣習として残っているものもあります。しかし、現場にとっては、その区別がつきにくい場合があります。
「昔からこうしている」「念のため残している」「誰かが見ているかもしれない」といった理由で、実際にはすでに使われていない機能や帳票が「必要なもの」として扱われていることがあるのです。
「全部必要」は否定せず、分解して考える
現場の「全部必要」を、頭ごなしに否定してはいけません。その言葉の背景には、業務への責任感があります。だからこそ、必要なのは否定ではなく分解です。
- 何が不安なのか
- どの業務が止まるのか
- 誰が困るのか
- 本当に毎回必要なのか
- システムで解決すべきなのか
こうした問いを通じて、「全部必要」を一つひとつ整理していくことが重要です。
要望をすべて入れると、使われないシステムになる
20代の頃、ある受託開発で、私は画面の至るところにボタンや入力項目が並ぶ、非常に複雑なシステムを作ったことがあります。現場のリーダーからは、「どれ一つ欠けても、明日の業務が止まってしまう」と言われていました。
当時の私は、その言葉を何の疑いもなく受け止めました。現場が必要だと言うのだから、すべて入れるべきだと思ったのです。しかし、数か月後に稼働したそのシステムは、あまりの複雑さに誰も使いこなせませんでした。結局、現場では独自の紙の帳票が復活していました。
この経験から学んだことがあります。現場の要望をすべて入れることが、現場にとって使いやすいシステムを作ることではないということです。
複雑なシステムは現場に定着しにくい
機能が多いシステムは、一見すると便利に見えます。しかし、機能が増えるほど、画面は複雑になります。入力項目も増え、操作手順も増えます。結果として、現場は次のように感じることがあります。
- どのボタンを押せばよいのか分からない
- 入力項目が多すぎて面倒
- 例外処理の手順が分からない
- 覚えることが多すぎる
- 結局、紙やExcelの方が早い
この状態になると、新システムは現場に定着しません。
紙やExcelが復活してしまう理由
新システムを導入したにもかかわらず、現場で紙やExcelが復活することがあります。その理由の一つは、新システムが業務の本質に合っていないことです。
現場の要望をすべて入れた結果、システムは多機能になります。しかし、日々の業務で本当に必要な操作が分かりにくくなれば、現場は使いやすい元の方法に戻ってしまいます。つまり、機能を増やしすぎることは、現場のためになるどころか、かえって現場の負担を増やす結果を招くのです。
ヒアリングは「聞き出し」ではなく「業務の解体」である
現場ヒアリングの目的は、要望をそのまま集めることではありません。大切なのは、現場の言葉の裏側にある行動や課題を観察し、業務を解体することです。
よくある失敗は、現場の要望をそのまま機能として受け取ってしまうことです。「この集計表が欲しい」と言われたら、集計表を作る。「このボタンが欲しい」と言われたら、ボタンを追加する。「この項目も残したい」と言われたら、入力項目を残す。しかし、それでは要望のパッチワークになってしまいます。
「集計ボタン」ではなく「入力チェック」が必要な場合もある
たとえば、現場から次のような相談を受けたとします。「毎日夕方に3時間かけてデータを突合しているので、自動で突合する機能が欲しい」
このとき、すぐに突合を自動化するボタンを作るべきでしょうか。もちろん、自動化によって効果が出る場合もあります。しかし、まず確認すべきなのは、なぜ突合が必要なのかです。元データはどこから来ているのか、どの項目がよく間違っているのか、なぜ後工程で突合しなければならないのか。
深掘りしていくと、実は前工程のデータ入力ミスを、後工程でリカバーしているだけだったということがあります。この場合、本当に必要なのは突合ボタンではないかもしれません。前工程で入力ミスを防ぐバリデーション、つまり入力チェックかもしれません。
機能追加は将来の保守負債になる
機能を一つ増やすことは、単に便利なものを一つ足すことではありません。その機能には、開発コストがかかります。テストが必要になり、仕様変更時には影響調査が必要になり、将来の保守対象にもなります。つまり、機能追加は将来のメンテナンス負債を増やすことでもあります。だからこそ、現場ヒアリングでは、要望をすべて機能化するのではなく、必要な機能を見極める必要があります。
「全部必要」を整理するための5つの問い
現場から「全部必要」と言われたときに、すぐに採用・不採用を判断する必要はありません。まずは、次のような問いで要望を分解していきます。
1. この機能がないと、誰がどのように困るのか
最初に確認したいのは、その機能がない場合の具体的な影響です。「ないと困る」ではなく、次のように具体化します。
- 誰が困るのか
- どの業務が止まるのか
- どのタイミングで困るのか
- どのくらいの頻度で困るのか
- 代替手段はあるのか
この問いによって、要望の重要度が見えやすくなります。
2. その業務はどの頻度で発生するのか
頻度も重要な判断材料です。毎日何十回も発生する業務と、年に数回しか発生しない業務では、システム化の優先度は変わります。
- 毎日発生する業務なのか
- 月に数回なのか
- 年に数回なのか
- 特定の担当者だけが行う業務なのか
- 例外処理なのか通常業務なのか
頻度が高く、ミスが許されず、作業負荷が大きいものは、システム化の優先度が高くなります。一方で、頻度が低い例外処理は、運用でカバーする方が合理的な場合もあります。
3. その要望は課題なのか、慣習なのか
現場の要望には、本当の課題もあれば、慣習として残っているものもあります。「昔からこの帳票を出している」「念のため確認している」「誰かが見ているかもしれない」このような要望は、実際には必要性が薄れている可能性があります。確認すべきなのは、次のような点です。
- その帳票は今も使われているのか
- 誰が見ているのか
- 見た後に何を判断しているのか
- 法令や監査対応として必要なのか
- 過去のトラブル対応がそのまま残っているだけではないか
課題と慣習を分けることで、本当に必要な機能が見えやすくなります。
4. 前工程で解決できないか
後工程で発生している作業は、前工程の問題をリカバーしているだけの場合があります。データ突合、目視チェック、手作業の修正、二重入力などは、その典型です。この場合、後工程に便利な機能を追加するよりも、前工程でミスが起きないようにする方が効果的なことがあります。確認すべきなのは、次のような点です。
- その作業はなぜ発生しているのか
- 元データはどこで作られているのか
- 入力時点で防げないか
- 承認前にチェックできないか
- データ連携のタイミングを変えられないか
業務を一連の流れとして見ることで、作るべき機能が変わることがあります。
5. 運用でカバーすべきか、システム化すべきか
すべての要望をシステムで解決する必要はありません。システム化すべきものと、運用でカバーすべきものを分けることが重要です。
| 判断観点 | システム化を検討しやすいもの | 運用で対応しやすいもの |
|---|---|---|
| 頻度 | 日常的に発生する | 年に数回しか発生しない |
| 影響度 | ミスが大きな損失につながる | 影響範囲が限定的 |
| 判断の種類 | ルール化できる | 人の判断が必要 |
| 作業量 | 大量処理が必要 | 少量・個別対応で済む |
| 保守負荷 | 仕様が安定している | 変更が多い・例外が多い |
このように整理すると、「全部必要」という要望の中でも、本当にシステム化すべきものが見えやすくなります。
SSIでは実際のヒアリングにおいて、単に要望をヒアリングするだけでなく、業務プロセスの前後関係や例外処理の発生頻度を数値化して確認します。これにより、現場の主観的な必要を、客観的な業務上の重要度へと落とし込んでいきます。
機能を削るのではなく、業務の核を見つける
現場の要望を整理するうえで注意したいのは、機能を削ること自体を目的にしないことです。我々が、機能を削る冷徹な審判になってはいけません。大切なのは、現場と一緒に「業務の核」を見つけることです。
共通のゴールを握る
現場に対して、いきなり「その機能は不要です」と言えば、当然反発が起きます。そうではなく、次のような共通のゴールを握ることが重要です。
- 本当に必要な業務に集中できるシステムにする
- 毎日使う人が迷わない画面にする
- 将来の保守や改修がしやすい状態にする
- 現場の負担を減らす
- 業務の重要な判断を支える
「機能を減らす」のではなく、「重要な業務に集中できる軽いシステムを作る」と伝えることで、現場との対話は進めやすくなります。
「今は作らない」という判断も価値になる
要件定義では、何を作るかを決めます。しかし同時に、何を作らないかを決めることも重要です。
「今は作らない」「将来必要になったら検討する」「まずは運用で確認する」「利用頻度を見てから判断する」といった判断は、決して手を抜くことではありません。むしろ、将来の使いやすさや保守性を守るための重要な意思決定です。
本当に誠実なシステム開発とは、現場の痛みに寄り添いながらも、未来の使いやすさのために必要な整理を行うことだと私たちは考えています。
現場要望を整理するチェックリスト
現場から「全部必要」と言われたときには、次の観点で整理すると判断しやすくなります。
| 確認項目 | 確認したいこと |
|---|---|
| 利用者 | その機能を誰が使うのか |
| 目的 | その機能で何を達成したいのか |
| 困りごと | その機能がないと誰がどのように困るのか |
| 頻度 | その業務はどのくらいの頻度で発生するのか |
| 影響度 | 対応しない場合、業務や顧客にどの程度影響があるのか |
| 代替手段 | 運用や既存ツールで対応できないか |
| 前工程 | 前工程の改善で解決できないか |
| 慣習 | 昔からのやり方が残っているだけではないか |
| 保守負荷 | 将来の改修や運用負荷が大きくならないか |
| 優先順位 | 初期リリースで必要か、後回しにできるか |
このチェックリストを使うことで、現場要望を感覚ではなく、業務上の必要性や影響度で客観的に整理しやすくなります。
具体的には、要望一覧や機能要件定義書に加え、システム化・運用回避の判断基準を明文化した要求整理マトリクスや優先順位定義シートなどの成果物を作成します。これらを現場と情報システム部門の双方でレビューし、納得感のある合意形成を進めます。
業務フロー未整備のまま進めた場合によくある課題
- 要件定義で同じ確認を何度も繰り返してしまう
- 現場ごとに説明が異なり、正しい業務手順を決められない
- 例外処理が後から判明し、設計変更が発生する
- データ移行時に、どのデータを正とするか判断できない
- 予算確定後に、本来改善すべき業務課題が見えてしまう
- 稼働後に「実際の業務に合わない」という不満が出る
実際の現場では、「業務整理を後回しにした結果、要件定義の途中で前提が崩れ、設計をやり直すことになった」というケースも少なくありません。また、データ移行直前になって項目の意味が分からず、移行判断が止まるといった事例もよく見られます。
よくある質問
Q. 現場が「全部必要」と言う場合、どう整理すればよいですか？
まずは否定せず、その機能がないと誰がどのように困るのかを具体化します。そのうえで、利用頻度、影響度、代替手段、前工程で解決できる可能性、システム化すべきかどうかを整理します。
Q. 現場要望をすべてシステム化してはいけない理由は何ですか？
要望をすべてシステム化すると、画面や操作が複雑になり、開発コストや保守負荷も増えます。結果として、現場が使いこなせず、紙やExcelに戻ってしまうことがあります。
Q. 本当に必要な機能はどう見極めればよいですか？
要望の裏にある目的を確認することが重要です。「何のために必要なのか」「ないと誰が困るのか」「どの業務に影響するのか」を確認すると、必要性を判断しやすくなります。
Q. 機能を減らすと、現場の反発が起きませんか？
起きる可能性はあります。そのため、「削る」ことを目的にするのではなく、「重要な業務に集中できるシステムにする」という共通ゴールを握ることが重要です。
Q. システム化すべき要望と運用で対応すべき要望は、どう分ければよいですか？
頻度、影響度、ミスの許容度、自動化効果、保守負荷で判断します。日常的に発生し、ミスの影響が大きく、ルール化できる業務はシステム化に向いています。一方で、頻度が低く、人の判断が必要な例外処理は、運用で対応する方が適している場合があります。
Q. 要件定義で「作らない」と判断した機能は、どう扱えばよいですか？
判断理由を記録しておくことが重要です。「初期リリースでは対象外」「利用頻度を確認してから判断」「運用で対応」など、理由と今後の扱いを明確にしておくと、後から議論を戻しにくくなります。
現場ヒアリングの進め方や要件の優先順位付けに不安がある場合は、専門家の支援を活用するのも有効です。業務整理から要件定義、実装を見据えた機能の絞り込みまで一貫して支援できる体制を整えることで、複雑化を避けた確実なプロジェクト推進が可能になります。
まとめ
現場ヒアリングで出てくる「全部必要」という言葉を、そのまま仕様に入れることが、現場にとってよいシステムにつながるとは限りません。本記事で整理したポイントは次の通りです。
- 「全部必要」の裏には、業務を止めたくない不安や防衛本能がある
- 現場要望をすべて入れると、システムが複雑になり、使われにくくなる
- ヒアリングは要望の聞き出しではなく、業務の解体である
- 「この機能がないと誰がどう困るか」を確認することで、本当に必要な機能が見えやすくなる
- 機能を削るのではなく、業務の核に集中することが重要
- 「今は作らない」という判断も、将来の使いやすさや保守性を守るための価値ある判断である
現場の要望をすべて叶えることが、お客様を幸せにするとは限りません。本当に誠実なシステム開発とは、現場の痛みに寄り添いながらも、未来の使いやすさのために必要な整理を行うことです。ヒアリングの席で「全部必要です」と言われたときは、まず一番大切な業務の核から整理していくことが重要です。
- 現場ヒアリングで要望が多く、優先順位を整理できていない
- 「全部必要」と言われ、どこまでシステム化すべきか判断できない
- 要件定義で機能が膨らみすぎることを避けたい
- 本当に必要な機能を整理し、使われるシステムを作りたい
- 現場ヒアリングから要件定義、システム開発まで一貫して相談したい
このような課題をお持ちの場合は、SSIにご相談ください。SSIでは、現場への丁寧なヒアリングを通じて業務の本質（核）を解き明かし、真に必要な要件を定義・選定する支援を行っています。豊富な経験に基づく客観的な評価基準により、現場の納得感を得ながら、手戻りのないシステム開発へと導きます。