実装エンジニアがITコンサルや上流側の仕事に進むとき、つまずく原因の多くは能力不足ではなく、実装の現場で身についた「良い習慣」が上流では逆に働くことにあります。仕様があれば正確に作る、分からなければ調べ尽くす、技術的に正しい案を出す、といった習慣です。この記事では、よくあるつまずきを6つに分け、それぞれの原因と対処を具体例で説明します。
職種ごとの役割の違いはFDE・SE・コンサルの違いで整理しています。
実装と上流では「良い仕事」の基準が違う
実装の仕事では、渡された仕様を正確に、速く、品質よく作ることが評価されます。上流の仕事では、そもそも何を作るべきかを顧客と一緒に決めることが評価されます。
| 観点 | 実装の仕事 | 上流の仕事 |
|---|---|---|
| 出発点 | 決まった仕様 | まだ言葉になっていない困りごと |
| 正解 | 仕様に書いてある | 顧客と合意して決める |
| 主な道具 | コード、設計書 | 業務フロー、課題一覧表、打ち合わせ資料 |
| 評価される点 | 正確さ、速さ、品質 | 論点の整理、合意形成、判断の根拠 |
この違いを知らずに上流に入ると、実装での強みがそのまま弱みとして表に出ます。以下のつまずきは、どれもこの基準の違いから起きています。
つまずき1：話を聞いた直後に解決策を出してしまう
顧客が「在庫の数が合わなくて困っている」と言った瞬間に、「バーコードで入出庫を記録すれば解決します」と答えてしまうパターンです。技術的には正しくても、顧客の業務を理解する前に答えを出すと、本当の原因を外したり、顧客が「話を聞いてもらえていない」と感じたりします。
対処
解決策が頭に浮かんでも、まず現状とあるべき姿を聞き切ります。「今は誰が、いつ、どうやって数えていますか」「数が合っていると、どんなことが楽になりますか」と聞くと、原因が入出庫の記録漏れではなく、返品の処理が別の帳票で管理されていることだった、という話が出てくることがあります。
解決策はメモの端に書いておき、ヒアリングの最後に「こういう方向もありそうです」と仮説として出すのが無難です。ASIS・TOBE・GAPをそろえる聞き方はヒアリングの記事にまとめています。
つまずき2：正解を探して動けなくなる
実装では、仕様書や公式ドキュメントに正解があります。上流では正解が最初から存在しないため、調べても調べても答えが出ず、手が止まってしまいます。
対処
情報を集めきる前に「たぶんこれが原因だろう」という仮の答えを置き、それを確かめるために何を見るかを決めます。例えば「受注処理が遅い」という課題なら、「原因は承認待ちの時間ではないか」と仮説を立て、承認の記録から待ち時間を確かめます。外れていたら別の仮説に移ります。
この進め方は仮説思考の記事とFDEガイドの仮説思考で詳しく扱っています。
つまずき3：課題を全部同時に解こうとする
ヒアリングで10個の課題が出ると、実装の感覚では「全部の機能を作れば解決する」と考えがちです。しかし期間も予算も限られているので、全部は解けません。
対処
課題を分解して、どれが他の課題の原因になっているかを見ます。イシューツリーで「なぜ起きているか」を掘り下げると、10個の課題のうち3つが同じ原因から来ていた、ということがよくあります。その原因に手をつければ、少ない作業で多くの課題が解けます。
顧客にも「この順番で進める理由」を説明できるようになるので、合意も取りやすくなります。分解の方法はイシューツリーの記事を参照してください。
つまずき4：資料が説明書になってしまう
実装経験者の作る資料は、調べたことや作ったものを順番に全部並べた「説明書」になりがちです。打ち合わせで最初から最後まで説明し、最後に「何かご質問はありますか」で終わると、何も決まらずに時間が過ぎます。
対処
資料の冒頭に「今日決めたいこと」を書き、そのための材料だけを載せます。例えば次の構成にします。
- 今日決めたいこと（例：TOBEの承認フローをA案とB案のどちらにするか）
- 結論の案（例：B案をおすすめする）
- 理由と判断材料（例：承認者の負担と、例外時の扱い）
- 決まらなかった場合の次の手
こうすると、打ち合わせが説明の場から決める場に変わります。資料の組み立て方はFDEガイドのミーティング資料作成が参考になります。
つまずき5：技術用語で話してしまう
「APIで連携して非同期でキューに積みます」と説明しても、業務部門の顧客には伝わりません。伝わらないと判断ができず、結局エンジニア側の判断に任されてしまいます。後で「そんなつもりではなかった」と言われる原因になります。
対処
説明を業務の言葉に置き換えます。「受注が入ると、倉庫の画面に自動で出ます。ただし反映まで数分かかるので、急ぎの注文は電話も併用します」のように、誰の作業がどう変わるかで話します。業務フローの図を見せながら話すと、言葉だけより伝わりやすくなります。
つまずき6：決まっていないことを自分で決めてしまう
実装では、仕様の小さな穴を自分の判断で埋めて進めることがあります。上流でこれをやると、顧客が決めるべきことをエンジニアが勝手に決めた形になり、後から手戻りが起きます。
対処
決まっていないことは、課題一覧表や課題ログに「未決」として残し、誰がいつまでに決めるかを書きます。自分の意見がある場合は、「この点は未決です。私の案はAで、理由は〜です」と案として出し、決めるのは顧客に任せます。
具体例：最初の上流案件の1週目
つまずきは、組み合わさって起きることが多いものです。ある架空の例で流れを見てみます。
製造業の顧客から「見積もり作成に時間がかかるので、システム化したい」という相談があり、実装経験5年のエンジニアが初めて上流担当として入ったとします。
初回の打ち合わせで、営業担当が「Excelの見積もりシートが重くて」と話した直後、エンジニアは「Webの見積もりシステムに置き換えましょう」と提案しました（つまずき1）。帰ってから見積もりシステムの機能を調べ尽くし、比較表を作るのに3日かかりました（つまずき2）。2回目の打ち合わせでは比較表を最初から順に説明し、何も決まらずに終わりました（つまずき4）。
同じ1週目を、対処を使ってやり直すと次のようになります。
- 初回は、見積もり作成の流れを営業・設計・購買の3人に聞き、業務フローに描く
- 「時間がかかる」を「1件あたり何時間、月何件か」まで数字で聞く
- 「原因は購買への単価確認の待ち時間ではないか」と仮説を置き、過去のメールで待ち時間を確かめる
- 2回目の打ち合わせは「今日決めたいこと：単価確認の待ちを減らす方向で進めてよいか」から始める
後者では、システムの種類を決める前に、何を解くかを顧客と合意できています。作るものはその後で決めても遅くありません。
つまずきを減らすための日々の習慣
6つのつまずきに共通する対処を、日々の習慣にまとめると次のようになります。
- 打ち合わせの前に「今日決めたいこと」を1行で書く
- 話を聞いたら、ASIS・TOBE・GAPのどれに当たるかメモに印をつける
- 調べ始める前に、仮の答えを1つ書く
- 解決策が浮かんだら、すぐ言わずにメモしておく
- 決まっていないことは、担当と期限をつけて残す
- 週に1回、できたことと次に伸ばすことを振り返る
実装経験はどこで活きるか
上流に進むと実装経験が無駄になるように感じるかもしれませんが、実際は逆です。作れる人が上流にいると、顧客の要望を聞いたその場で「それは2週間で試作できる」「それは既存システムの改修が必要で時間がかかる」と判断できます。生成AIで試作が速く作れるようになった今は、打ち合わせで出た案を次の週に動く形で見せることもできます。
つまずきの多くは、実装の習慣を上流の場面で使ってしまうことから起きます。場面に応じて使い分けられるようになれば、実装経験は上流での強い判断材料になります。
この記事のまとめ
- 実装と上流では「良い仕事」の基準が違い、実装での良い習慣が上流でつまずきの原因になる
- 解決策を先に出さず、現状とあるべき姿を聞き切ってから仮説として出す
- 正解を探し続けず、仮の答えを置いて確かめ方を決める
- 課題は分解して原因を見つけ、効く順番に手をつける
- 資料は冒頭に「今日決めたいこと」を置き、決める場を作る
- 技術用語は業務の言葉に置き換え、未決事項は顧客が決められるよう残す
- 実装経験は、上流でその場の実現性を判断する材料として活きる
課題を分解して手をつける順番を決める練習は、ロードマップのステップ3「課題を構造化する」にまとめています。ヒアリングから順に練習したい方は、ステップ2「聞く」から始めてみてください。