上流工程に進みたいエンジニアが最初に変えるべき会話の仕方

上流工程では、会話の目的が変わる

開発フェーズでのエンジニアの仕事は、与えられた仕様をコードに変えることだ。顧客やPMからの情報は完成した状態で渡ってくる前提で動ける。

上流工程は違う。顧客の言葉はまだ「欲しいもの」に過ぎず、それが何のためなのか、どんな制約があるのか、誰が使うのかは、会話して引き出す必要がある。

ここに気づかないまま上流工程に入ると、技術解決策の話を早くしすぎてズレが生まれる。

「Aの機能を作りたい」と言われたとき、すぐ「それならこの技術で実装できます」と返すのは、開発フェーズなら正しい動き方だ。

上流工程では、その前に確認すべきことがある。「Aの機能を作りたい」の背景が、実は別の問題を解決するためだったとしたら、解決策が変わることがある。

最初から実装方法の話をすると、後で要件変更や手戻りが起きやすい。

「それで何を達成したいですか？」「その機能があると何が解決されますか？」

相手が「欲しい」と言っているものより、そのひとつ上にある目的を確認する。

「今はどうやって対応していますか？」「どんな状況でその課題が起きますか？」

現状の業務フローや手作業の状況を聞くことで、要件の輪郭が見えてくる。

「いつまでに必要ですか？」「使えるシステムや環境に制限はありますか？」「誰が使いますか？」

制約を知らずに設計方針を決めると、後で作り直しが起きる。

会話の中で聞いた内容を即座に整理する習慣を持つと、上流工程での動きが変わる。

記入例（受注管理の検索機能を依頼されたケース）：

項目	内容
目的	営業担当が受注状況をその場で確認できるようにしたい
現状	Excelで管理しており、検索に10分以上かかっている
問題	顧客への回答が遅れ、対応ミスも発生している
制約	6月末リリース希望・既存の販売管理システムとの連携が必要
優先度	検索機能は必須、CSV出力は次フェーズでよい

会議後にこのメモをPMと確認することで、認識の差異を早期に発見できる。

失敗1：解決策を先に話す 「それならXXフレームワークで実装できます」と技術解決策を先に出すと、「なぜそれが必要なのか」の確認が飛ぶ。要件が後から変わったとき、解決策ごと見直しが発生する。

失敗2：質問せずに推測する 「たぶんこういう目的のはず」と思い込んで進めると、実際の目的が違った場合に手戻りが大きくなる。顧客が明示していないことでも、確認しない選択がリスクを生む。

失敗3：確認した内容を共有しない 引き出した目的・現状・制約を自分のメモにとどめ、PMや他のメンバーと共有しないでいると、チーム全体の認識がズレたまま進む。確認した内容は簡潔でよいので、関係者に共有する習慣を持つ。

会話の変え方を練習するには、まず自分が普段の業務で「解決策から話していないか」を意識するところから始まる。

タスク単位でも「なぜこれをやるのか」「誰にとっての問題か」を確認する癖を付けると、上流工程での動き方が自然に変わっていく。

PL・PM候補として評価されるには、技術力だけでなく、このような会話の変え方が効いてくる。