採用側は「工程における思考・判断・実行の中身」を見ています。今回、選考通過率を上げるために必要な書くべき各ポイント7つを、実務ベースでまとめてみました✨

① 工程ごとに 「何をしたか」ではなく「何を考えたか」 を書く

ただ「要件定義しました」「基本設計やりました」では、具体的内容が把握しにくいので、どういう情報を元に、どんな判断・整理を行ったかを書く必要があります

🔸悪い例：要件定義を担当
🔸良い例：顧客からの要望ヒアリング内容を業務フローに落とし込み、実現可否を検討。費用対効果を加味し、優先度づけして提案。

② 成果物・アウトプットを具体的に記載する

上流工程では、考えたことの“証拠”＝成果物が重要となりますので「どのようなドキュメントや設計物を作ったのか」を記載したほうがよいです

🔸例：要件定義書（業務フロー・機能一覧・課題一覧含む）、画面設計書（Figma）、ER図（dbdiagram.io使用）

③ 課題と対処、もしくは調整経験を記載する

とくに上流工程では、関係者との意見の食い違い・要件の変化・仕様の未確定といったトラブル対応力が重視されます

🔸例：曖昧な要件があったため、現場ヒアリングを実施し、業務上の前提を明文化
🔸例：顧客の要望と予算が合わず、機能の優先度見直し案を提示して合意形成

④ チーム内外との関わり方を具体的に書く

顧客・営業・開発・インフラなど、誰とどのようなやり取りをしていたかが明記されていると、上流適性が伝わります

🔸例：営業同席での顧客折衝に週1回参加。要件ヒアリング後、議事録と要件一覧に落とし込み、仕様定義へ連携
🔸例：開発チームとの仕様調整時、技術的制約を考慮し代替案を検討

⑤ 決定事項をどう導いたか、意思決定プロセスを書く

要件を「まとめた」だけでなく、何をどう比較・検討し、どのように決定を導いたのかを書くと、実力が明確になります。

🔸例：3案の構成案を提示し、コスト・納期・運用負荷を比較。クライアントと合意のうえ最適案を採用

⑥ プロジェクトの規模感・自分の責任範囲を明確に書く

プロジェクト全体と、その中での自分の立ち位置（リードか一部補助か）を明示する

🔸例：5人チームで基本設計を担当。自分は主要機能3つの画面設計・API設計を主導
🔸例：サブリーダーとして、設計レビューおよび後続工程への引き継ぎ資料を作成

⑦ 上流工程で“数字”を使って説得力を増す

「上流＝数字が使いづらい」と思われがちですが、説得力のある職務経歴書には定量情報が含まれています

🔸例：業務フロー8パターンを可視化し、非効率なルートを削減。手作業70%→20%に圧縮する要件に落とし込み
🔸例：プロジェクト期間：8ヶ月、要件定義期間：1ヶ月（顧客3社対応）

まとめ：工程名より「何を考えて何を決めたか」

上流ポジションにおいては「思考」「判断」「調整」などの行動が重要となります。
“やった”ことの羅列ではなく、そのとき何を考え、何を決め、どのように動いたかを具体的に伝えることで、選考の通過率は確実に上がります😊