一流エンジニアだけが知っている「真の問題」の見つけ方第1回：顧客の「ほしい」は嘘です。エンジニアが最初にやるべき仕事は“要望を疑うこと”

Last updated at 2026-04-22Posted at 2026-04-02

シリーズ：一流エンジニアだけが知っている「真の問題」の見つけ方

第1回：顧客の「ほしい」は嘘です。エンジニアが最初にやるべき仕事は“要望を疑うこと”

【お知らせ】新シリーズ始動！
前シリーズ 『脱・新人！現場で「一目置かれる」エンジニアの立ち回り術』 では、現場での振る舞いや信頼の築き方を学びました。
新シリーズでは、さらに一歩踏み込み、エンジニアとしての本質的な価値―― 「問題解決の思考法」 をテーマに展開します。

こんな依頼、受けたことありませんか？

「とにかく遅いのでサーバー増やしてください」
「とりあえずグラフ増やせば解決しますよね？」
「他社もやってるのでこの機能入れたいです」

これ、全部“間違っている可能性”があります。

この記事はシリーズの一部です。

📚 次の記事
→ 第2回：「遅い＝サーバー増強」は間違いです。ユーザーは“体感速度”しか見ていない

📚 このシリーズ全体のまとめはこちら

→ 一流エンジニアだけが知っている「真の問題」の見つけ方：記事一覧・重要ポイントまとめ

💡 この記事を読んでほしい人

顧客の要望通りに構築したのに、なぜか満足度が低いと感じる人
「仕様書通りに動けばOK」という空気感に限界を感じている人
AI時代に、単なる「作業者」で終わりたくない人

1. はじめに：届いた「要望」をそのまま実装するのは不親切である

ある程度経験を積むと、こんな依頼に何度も出会います。

「とりあえずサーバー増やしてください」
「グラフを追加すれば見やすくなりますよね？」
「この機能、他社もやってるので入れたいです」

一見もっともらしいですが、ここにそのまま乗ると危険です。

現場から届く「要望」というパケットには、ノイズが混ざっていることが多い。

このノイズを取り除かずに実装すると、
「動いているのに満足されないシステム」が出来上がります。

実際、多くの現場では「とりあえずサーバー増強」で一度は乗り切れてしまうため、
同じ問題が何度も繰り返されます。

↑ 目次に戻る

2. 「何を作ればいいか」ではなく「何が詰まっているか」を聞く

一流のエンジニアは、ヒアリングでこう聞きます。

「その処理、どのタイミングで詰まっていますか？」
「誰が困っていて、どの業務が止まっていますか？」

ここで重要なのは、「機能」ではなく「業務の流れ」を聞くことです。

避けるべき聞き方	踏み込むべき問いかけ
「どんな設定値にしますか？」	「現状、何がスムーズに運んでいないのですか？」
「どんなグラフを並べますか？」	「その数値を見て、誰が次のアクションを判断しますか？」

💡 具体例：監視ダッシュボード追加の依頼

リクエスト（表面）： 「監視画面に新しいグラフを5つ追加してほしい」
現場の痛み（深層）： 「データの異常発生に、夜間でもすぐ気付けるようにしたい」

もし痛みが「異常への即応」なら、
グラフを増やすよりも 「閾値判定＋通知」 の方が本質的な解決です。

↑ 目次に戻る

3. ケーススタディ：サーバー増強依頼の裏に潜んでいた「真犯人」

ある現場で、こんなやり取りがありました。

顧客：
「最近、画面の表示が明らかに遅いんです。ピーク時は8秒くらいかかってます。サーバーのスペック、倍にできませんか？」

自分：
「どの画面・どの処理が一番遅いですか？」

顧客：
「そこまでは分かっていませんが、全体的に遅いです」

この時点で、こう考えました。

リソース不足は“原因”ではなく“結果”かもしれない

まずはログとメトリクスを確認し、簡単なプロファイリングを実施。
すると、特定の検索APIだけが異常に遅いことが判明しました。

さらにクエリを確認すると原因は明確でした。

インデックスが貼られていないカラムに対してフルスキャンが走っていた

試しにインデックスを追加したところ、

レスポンス：8秒 → 0.6秒

まで改善。

結果として、サーバー増強は不要になりました。

もし最初の要望通りに動いていたら、
コストをかけたうえで「根本原因は未解決」のままだったでしょう。

↑ 目次に戻る

4. 実務で使えるチェックリスト

要望を受けたとき、最低限これを確認するだけで精度が上がります。

■ 要望を受けたときのチェックリスト

- その処理はどこで遅いのか特定されているか？
- 業務として何が止まっているのか？
- リソース不足は「原因」か「結果」か？
- ログ・メトリクスは確認したか？
- 一時的な対処で再発しないか？

この5つを通すだけで、「とりあえず対応」はほぼ消えます。

↑ 目次に戻る

5. キャリア論：AIには代替できない「前提を疑う」という決断

指示された通りにコードを書き、設計書を清書する。
これは今後、AIが最も得意とする領域です。

しかし、AIにはできないことがあります。

それは、
「そもそもその前提、正しいですか？」と問い直すことです。

そして時には、

「その開発、やめましょう」

とNoを出すこと。

これができる人だけが、
「作業者」ではなく「意思決定に関わるエンジニア」になります。

↑ 目次に戻る

6. まとめ：現場の「パケット」から真の意図をデバッグする

明日、何か依頼を受けたら、設定コマンドを打つ前に一呼吸置いてください。

「この要望を実装して、どの痛みが消えるのか？」

この問いがあるかどうかで、アウトプットの質は大きく変わります。

「要望を実装する」のは仕事ではない。
「問題を消す」のが、エンジニアの仕事です。

↑ 目次に戻る

この記事はシリーズの一部です。

📚 次の記事
→ 第2回：「遅い＝サーバー増強」は間違いです。ユーザーは“体感速度”しか見ていない

📚 このシリーズ全体のまとめはこちら

→ 一流エンジニアだけが知っている「真の問題」の見つけ方：記事一覧・重要ポイントまとめ

7. 連載一覧：一流エンジニアだけが知っている「真の問題」の見つけ方

回	サブタイトル	内容
第1回	顧客の「ほしい」は嘘です。エンジニアが最初にやるべき仕事は“要望を疑うこと”	顧客の「ほしい」は解決策であって問題ではない。言葉の裏にある「真の痛み」を掘り起こす、現場でのヒアリング術。
第2回	「遅い＝サーバー増強」は間違いです。ユーザーは“体感速度”しか見ていない	パフォーマンス問題を「サーバースペック」で解決しようとするのは典型的な誤り。ユーザー体験（UX）に基づき、体感速度を改善する実践的アプローチ。
第3回	「気をつけてください」は無意味です。ヒューマンエラーは“仕組み”でしか防げない	注意喚起ではミスは防げない。人に依存しない設計（バリデーション・自動化・制約設計）で、再発を防ぐ実務的アプローチ。
第4回	その自動化、未来の自分を殺します。便利な仕組みほど“運用負債”になる	自動化は万能ではない。短期的な効率化が長期的な運用コストを増やすケースを理解し、シンプルさを維持する判断力を養う。
第5回	その技術、使いたいだけでは？エンジニアが陥る「技術選定の罠」	「新しい技術を使いたい」という欲求に潜むリスク。ビジネス要件から逆算し、最適な技術を選ぶための実務的思考法。
第6回	そのタスク、本当にあなたの仕事ですか？“便利屋エンジニア”が潰れる理由	すべてを引き受けるエンジニアは長続きしない。責任範囲を明確にし、問題を適切な担当へ返すことで組織全体を健全化する。
第7回	「良いシステムなのに使われない」理由は技術ではなく“人間の心理”です	システム導入が失敗する本当の理由は技術ではない。現場の抵抗や心理的ハードルを理解し、受け入れられる改善を設計する。
第8回	あなたの価値はコード量ではない。「どれだけ悩みを消したか」で決まる	エンジニアの価値はアウトプットの量ではなく、解決した課題の質で決まる。問題解決者としてのキャリア戦略を総括。

↑ 目次に戻る

📋8. 過去連載シリーズのご案内

これまでの連載では、エンジニアとしての基礎固めから、現場で信頼を得るための立ち回り方まで、ステップアップに合わせた内容を公開しています。本シリーズと併せてご活用ください。

タイトル	内容（概要）
【新卒・未経験向け】NWエンジニア現場デビューへの道（全11回）：記事一覧・重要ポイントまとめ	【フェーズ：導入・基礎】現場に出る前に整理しておくべき「3つのポイント」を解説。IT業界の構造を理解した上でのキャリア形成、組織内での適切な振る舞い方、不確かな情報に惑わされず現状を正確に把握する手法など、エンジニアとして確実に仕事を進めるための土台となるシリーズ。
脱・新人！現場で「一目置かれる」エンジニアの立ち回り術：記事一覧・重要ポイントまとめ	【フェーズ：実践・応用】基礎を終えた後のステップアップとして、質問の仕方、作業の標準化、見積もりの考え方など、チームの円滑な運営に貢献し、周囲から信頼を得るための具体的なアクションをまとめたシリーズ。