職務経歴書を書こうとして、手が止まってしまった経験はないでしょうか。「進捗管理」「課題管理」「会議体の運営」「要件定義の支援」。書き出してみると作業の名前ばかりが並び、「これで戦略ファームや経営企画のポジションに応募してよいのだろうか」と不安になる。総合系・IT系ファームでPMOやシステム導入、常駐型の支援に携わってきた方が、抱えやすい悩みの一つです。
しかし、その経験の中身が乏しいわけではありません。多くの場合、問題は経験そのものではなく、「何をしたか（作業）」だけが書かれ、「何を考え、どう判断したか」が書かれていないことにあります。本記事では、事実を変えずに伝え方を変える方法を、具体例とともに解説します。
※ 本記事の書き換え例は、すべて説明のために作成した架空のものです。また、評価の観点はファームや応募ポジションによって異なります。
なぜ「作業の説明」では伝わらないのか
戦略ファームや経営企画などの選考で読み手が知りたいのは、一般に「この人は、あいまいな状況で何を問題と捉え、どう考えて動く人なのか」です。ところが、PMOやシステム導入の経験は、次の理由で作業の説明に寄りやすくなります。
- 役割が「管理」「支援」「推進」といった言葉で定義されているため、そのまま書くと主体性が見えにくい
- 成果がプロジェクト全体のもの（稼働、リリースなど）になり、個人の貢献が切り出しにくい
- 日々の業務が多岐にわたり、どれも「当たり前にやったこと」に感じられる
裏を返せば、この3点を意識して書き直すだけで、伝わり方は大きく変わります。
「作業」から「論点と判断」へ言い換える3つの視点
1. 「何を管理したか」ではなく「何が問題だと見立てたか」
進捗管理や課題管理の中でも、「遅延の本当の原因はどこにあるのか」「数ある課題のうち、どれが致命的なのか」を見極める場面があったはずです。その見立てが、あなたにとっての論点設定です。
2. 「何を実施したか」ではなく「なぜそれを選んだか」
取りうる選択肢が複数ある中で、なぜその進め方を選んだのか。判断の根拠を一言添えるだけで、思考の過程が伝わります。
3. 「プロジェクトの成果」ではなく「自分の関与で何が変わったか」
システムが稼働したという結果だけでなく、自分の働きかけによって、意思決定のスピード、手戻りの量、関係者の動き方などがどう変わったのかを書きます。
Before/After の書き換え例（架空）
以下の3つは、いずれも説明用に作成した架空の例です。After に書かれている内容は、「実際にそうした事実があった場合の表現」である点にご注意ください。
例1：PMO
Before
基幹システム刷新プロジェクトのPMOとして、進捗管理、課題管理、定例会議の運営を担当。
After
基幹システム刷新プロジェクト（関係者約50名）のPMOを担当。複数チームで遅延が続いていた状況に対し、課題一覧を原因別に分類し直したところ、遅延の多くがチーム間の仕様確認の待ち時間に起因していることを特定。全体定例での報告中心の運営から、関係チームのみで仕様を即決する短時間の会議体へ切り替えることをプロジェクト責任者に提案し、導入。以降、仕様確認に関する課題の滞留期間が短縮した。
「管理した」という事実は同じでも、After では、原因の見立て、打ち手を選んだ理由、自分の提案による変化が読み取れます。
例2：要件定義
Before
販売管理システムの要件定義を担当。業務部門へのヒアリングを実施し、要件定義書を作成。
After
販売管理システムの要件定義を担当。業務部門から挙がった要望が当初の想定を大きく上回ったため、各要望を「業務への影響度」と「実現コスト」の2軸で整理し、現行業務の踏襲にとどまる要望と、業務そのものを見直すべき要望を区別。後者については、業務フローの変更案を併せて提示し、部門長との合意を経て開発対象を絞り込んだ。
要望を聞いてまとめるだけでなく、優先順位の基準を自分で設計し、業務側の意思決定を支えたことが伝わります。
例3：運用改善
Before
常駐先にて、システム運用業務の改善支援に従事。マニュアル整備や問い合わせ対応を実施。
After
常駐先にてシステム運用の改善を支援。問い合わせ対応の負荷が高い状況に対し、過去の問い合わせ内容を分類したところ、特定の操作に関するものが大きな割合を占めることを確認。マニュアルの拡充ではなく、該当画面の入力項目の見直しが根本的な解決になると考え、改修案と期待される効果をクライアントに提案。改修後、同種の問い合わせは減少した。
依頼された範囲（マニュアル整備）を超えて、問題の原因に立ち返って提案した点が、課題設定の力として伝わります。
なお、いずれの例でも数値は控えめに書いています。数字を入れる場合は、根拠を説明できるものに限り、守秘義務にも配慮してください。
盛らずに強みを引き出す棚卸しの問い
「自分にはそんな場面がなかった」と感じる方もいるかもしれません。しかし、当たり前にこなしてきた仕事の中に、判断の場面は埋もれているものです。プロジェクトごとに、次の問いに答えてみてください。
- そのプロジェクトで、最も難しかった局面は何でしたか。なぜ難しかったのでしょうか
- 指示された進め方に対して、「こうしたほうがよい」と提案したことはありますか
- 複数の選択肢があったとき、何を基準に選びましたか
- 自分がいなかった場合、何が違っていたと思いますか
- クライアントや上司から、特に感謝された・任されたことは何ですか
- うまくいかなかったことは何で、そこから何を変えましたか
答えを書き出すときは、「事実」と「解釈」を分けておくのがポイントです。事実として確認できることだけを書類に書き、自分の役割は実際の範囲で記載します。上司の判断だったものは「上司に提案し、採用された」のように、関与の仕方を正確に書きましょう。経歴を大きく見せる必要はありません。小さな判断でも、考えた過程が具体的であれば十分に伝わります。
面接での深掘りへの備え
書類に書いた内容は、面接で詳しく問われると考えておきましょう。一般に、次のような質問が想定されます。
- なぜそれが問題の原因だと考えたのですか。ほかの可能性は検討しましたか
- その打ち手以外に、どのような選択肢がありましたか
- あなた個人が担ったのは、どの部分ですか
- 今振り返って、別のやり方をするとしたら何を変えますか
- その経験は、応募先の仕事にどう活きると思いますか
備えとしては、エピソードごとに「状況、自分の見立て、選択肢と判断の根拠、結果、振り返り」の5点を、それぞれ一言で話せるように整理しておくと安心です。分からなかったことや、うまくいかなかったことを率直に話せることも、信頼につながります。
もう一つ、準備しておきたいのが「なぜ今の領域から移りたいのか」という問いです。現職への不満として語るのではなく、「実行の現場を経験したからこそ、その上流にある意思決定に関わりたい」というように、これまでの経験と今後の志向がつながる形で説明できるようにしておきましょう。
よくあるNG
- 作業名の羅列：「進捗管理、課題管理、会議運営」のように、役割の名称だけで終わっている
- 主語がプロジェクトになっている：プロジェクト全体の成果は書かれているが、本人の貢献が読み取れない
- 社内・プロジェクト固有の用語が多い：システム名や略語、フェーズの呼び方などが説明なしに使われている
- 役割を実際より大きく書く：面接で掘り下げられた際に説明が続かず、かえって評価を下げる原因になります
- 規模の大きさだけを強調する：予算や人数の規模は背景情報であり、それ自体が個人の強みを示すわけではありません
- 現職の仕事を否定的に書く・語る：経験を自分で低く評価している印象を与え、強みが伝わりにくくなります
まとめ
PMOやシステム導入、常駐支援の経験は、「作業の説明」のままでは伝わりにくいものの、「何が問題だと見立て、なぜその打ち手を選び、自分の関与で何が変わったか」という形に言い換えることで、課題解決の力を示す材料になります。大切なのは、事実を変えることではなく、事実の中にある思考と判断を掘り起こすことです。まずは直近のプロジェクトを一つ選び、棚卸しの問いに答えるところから始めてみてください。
Strategy Talentでは、総合系・IT系ファームでのご経験を踏まえた職務経歴書の添削や、面接に向けた経験の整理をサポートしています。自分の経験をどう言葉にすればよいか迷ったときは、お気軽にご相談ください。