職務経歴書に何を書いたらいいか分からない問題
転職や仕事探しは何度やっても慣れるものではありません。採用担当やエージェントであれば毎日数多くの職務経歴書を見ているため、どの職務経歴書が分かりやすかったか比較して知ることができます。
しかし、仕事を探すエンジニアは自分以外の職務経歴を普段は見ることはありません。では、エージェントさんは良い職務経歴書を知っているのだから教えてくれても良いのでは？という話になるのですが、エンジニアの技術を詳しくわからないことと、一人ひとりの強みが違うため、それぞれの強みに合わせた表現をアドバイスするのは非常に高度なスキルのため、難しいのです。
そこで、エンジニアの経験を整理する手法として、STAR法（Situation / Task / Action / Result）は広く使われています。職務経歴書や面接において、経験を簡潔に伝えるという点では、現在でも有効なフレームワークです。
しかし、私が採用担当としてエンジニアの職務経歴書を多く見る中で、フォーマット通りやって書かれていても、候補者の方の価値が十分に伝わらないと感じる場面がよくありました。
やったことは伝わっても、考え方が見えないため、観点やスタンスが見えなかったり、当たり前の役割だったのか課題感から自分で動いた主体性だったのか分からないことがよくありました。
この記事はSTAR法では足りなかった理由を整理した上で、経験の伝え方を整理しやすくするフレームワークとしてシーキューブモデルを提案します。
STAR法が抱える構造的な限界
STAR法は、「何が起き、何をして、どうなったか」を時間軸に沿って説明するのに有用です。
しかし、STAR法では周りの状況と自分の役割が分けられておらず、周りと自分の定義が不十分であるため、期待通りのことをやったのか、期待以上のことをやったのか、事実からだけでは分かりにくい表現になることがあります。
また、思考の部分も切り分けられていないため、やったことだけを記載しやすいフォーマットになっています。ジュニアエンジニアであればやった事実だけでも十分かもしれません。しかし、ミドルエンジニア以上であれば、意思決定の思考が重要になります。なぜその実装や設計判断をしたのか、他にどんな選択肢があり何を捨てたのかなど、結果だけではなく技術的なトレードオフをどのように選択したかという点が重要です。
STAR法ではこれらの情報がS・A・T・Rの全てのステップで混ざりやすく、判断の質や責任の範囲が曖昧になり、結果的に職務経歴書に十分な記載がされないこともあります。
結局のところ、STAR法は「出来事の報告」には向いていますが、「能力の証明」には不十分なのです。 特にミドル以上のエンジニアにとって、本当に伝えるべきは「何が起きたか」という現象ではなく、その混沌とした状況（Context）の中で、プロとして何を優先し、何を捨てたのかという「判断の質（Choice）」のはず。 現象だけをなぞった職務経歴書は、どれだけ実績が素晴らしくても、読み手には「運が良かっただけの人」か「指示待ちの優秀な作業者」に映ってしまうリスクがあります。この『思考のブラックボックス化』を解消するために考案したのが、シーキューブモデルです。
シーキューブモデルの考え方
シーキューブモデルは、エンジニアの経験を客観的な責任と主観的な判断の構造として整理するためのフレームワークとして作りました。
広く職務経歴書をまとめるケースで利用できる型になっていると思います。
このモデルでは、経験を3つの視点（縦軸）と、3つの項目（横軸）からなる 3×3 の表として捉えます。
- 横軸：課題 → 行動・役割 → 結果
- 縦軸：周囲の客観 → 自分の客観 → 自分の主観
| 観点＼項目 | 課題 | 役割・行動 | 結果 |
|---|---|---|---|
| 周囲の客観 Context | チームやプロダクトの 課題・状況 | チーム体制や制約 などの取り組み方の前提 | 周囲にとって 得られたアウトカム |
| 自分の客観 Capacity | 全体課題の中で 自分に割り当てられた課題 | 公式な役割・責務と 他メンバーとの関係 | 自分が直接生み出した アウトプット |
| 自分の主観 Choice | 自分が感じた 本質的な課題 | 検討した選択肢と 実行に移した判断 | 判断の結果で起きたこと 実現した状態 |
この表は、
横方向に読むと「原因から結果への時間の流れ」を、
縦方向に読むと「責任と視点の違い」を表します。
上段は 周囲の客観（Context）
自分が関与する前から存在していた課題や状況、組織やプロダクトとして設定されていた期待や制約です。
ここには解釈を入れず、事実のみを置きます。
自分がいなくても成り立つチームや組織全体の状況です。
自分の仕事をする上での前提となる環境を整理します。
中段は 自分の客観（Capacity）
全体の中で自分に割り当てられていた役割や責務、公式な立ち位置や権限を示します。
「何を任されていたか」を表す層です。
周囲から自分へのミッションや役割を書きます。周囲と自分の関係を明確化します。
下段は 自分の主観（Choice）
課題をどう捉え、何を本質と判断し、どこに介入したかという意思決定の領域です。
時間や思考が存在するのは、この層だけです。
自分の頭の中で起きていたことを書きます。行動の理由になった事象や判断です。
ちなみにシーキューブモデルのネーミングはこの３つのCと3x3の表から来ています。
重要なのは、
- 周囲の客観には解釈を書かない
- 自分の客観には判断を書かない
- 自分の主観でやっと自分の考えを書く
というルールを守るためのフレームワークになっているということです。
この観点を入れて職務経歴書を書くことで
- どこまでが前提条件だったのか
- どこからが本人の裁量だったのか
- 判断が結果にどう結びついているのか
文章の中で分かるようになります。
職務経歴書に記載する具体例
バックエンドエンジニアの経験を例にシーキューブモデルで記載してみたいと思います。
周囲の客観（Context）× 課題
ユーザー対応を行う運用チームの手作業が増加し、対応遅延やヒューマンエラーが多数発生、リカバリーのためのエンジニアの工数も大きく取られ開発が遅れる状態が発生していた。
主に自分がやるべき理由であるWHYを書く。
周囲の客観（Context）× 状況
プロダクトマネージャ、エンジニア４人の体制
テックリード１人、バックエンドエンジニア２人、フロントエンドエンジニア１人のチームでメイン担当の領域に分かれて役割を分けていたが、バックエンドもフロントエンドの実装をしたり、フロントエンドもバックエンドの実装をすることもあった
テックリードはいるが、設計方針は実装の担当に一定の裁量が与えられていた。
自分の所属するチーム構成やベースとなる活動方法を書く。
周囲の客観（Context）× 結果
管理画面からユーザー状態を操作できる機能がリリースされ、運用チームによる手作業が削減され、業務フローが安定して回る状態となった。問い合わせ対応やエラー対応も削減でき、開発もスケジュール通り進められるようになった。
得られた アウトカムを書く。 狙ったアウトカムが上手く得られなかった場合は代わりに得たそこで分かったことや学びを書く。
自分の客観（Capacity）× 課題
この課題を解消するため、管理画面からユーザー状態を操作できる機能の追加が求められていた。開発も逼迫していたため早期のリリースを目指し、２週間でリリースすることを目指して進められた。
全体の課題から落とし込んだ解決方針を書く。WHAT、WHEN、HOWなど。
自分の客観（Capacity）× 役割
管理機能に関わるバックエンド処理の設計・実装が自分の担当スコープとして割り当てられていた。
テックリードの人にレビューをしてもらいながら、フロントエンドエンジニアと設計や実装を進めた。
全体の他の人と自分の関わり方を書く。
自分の客観（Capacity）× 結果
管理画面操作用のAPIおよび関連するデータ更新処理を実装し、仕様どおりに機能が利用可能な状態を実現し、短期間でのリリースを求められたがバグも起こさずリリースできた。
自分が作ったり活動して発生した アウトプットを書く。 成果と呼ぶとアウトプットとアウトカムが混ざってしまうことがあるが、アウトプットは自分が直接作ったもの、アウトカムは利用者が得られたもの、と言う観点になる。
自分の主観（Choice）× 課題
単純にユーザー状態を更新するAPIを追加した場合、今後状態種別や操作パターンが増えた際にビジネスロジックが各所に分散し、変更や保守が困難になると考えた。
与えられたテーマ以上に自分が感じたり考えた課題を書く。
例えば将来の状況を想定するとやっておくと良いこと。
できるかできないかは別として、自分が考えた理想の状態とそのギャップを書く。
自分の主観（Choice）× 役割
CRUD中心の実装は選択せず、状態遷移のルールを一箇所に集約する構造を採用した。初期実装コストが増える点は許容し、将来の拡張や運用変更に耐えられることを優先した。
短期間のリリースを求められていたが、期限に間に合う形で負債にならないように工夫した最低限の土台を作れると判断した。
検討した選択肢とトレードオフを検討した結果の判断を書く。
自分の主観（Choice）× 結果
実際の開発では想定の見積もりよりも時間がかかったが、集中して仕事をしたことで期限内に開発することはできた。
その後、ユーザー状態に関する仕様追加や変更が発生したが状態遷移ロジックの修正は集約した箇所のみで対応可能にしたため、既存APIや他機能への影響を最小限に抑えたまま対応できた。
これらの観点を整理した上で職務経歴書に書く例
▼ プロジェクト概要 (アウトプット)
・ 社内運用チーム向け管理機能の追加
▼ チーム体制・進め方 (周辺)
・プロダクトマネージャ：1名
・エンジニア：4名 （テックリード：1名、バックエンドエンジニア：2名、フロントエンドエンジニア：1名）
・設計方針は実装担当に一定の裁量があり、専門領域をメインにしながら相互にバックエンドとフロントエンドの開発に関わりながらアジャイルに進める体制
▼ プロジェクトの詳細
運用チームの手作業増加により、対応遅延・ヒューマンエラーが頻発しており、リカバリー対応でエンジニア工数が圧迫され、開発スケジュールに影響が出ていました。運用チーム向けのユーザー管理機能を開発することとなり、2週間での短期リリースが求められていました。 （目的と制約）
開発の際に今回必要な要件だけでなく、将来の仕様拡張を見据えて状態遷移を一元管理する構造を提案して実装しました。短期間でのリリースを求められましたが、将来に必要な拡張性を持たせる必要性を説明して進めることができました。（思考と行動、判断ポイント）
その結果、初期リリース後の変更にも影響範囲を限定した対応でき、運用と開発の安定化に繋がりました。（成果）
このように、重要な観点を確認してから文章化することで、十分に周囲の状況と自分の役割と自分の思考を伝える文章を書きやすくなります。
ここでは3x3の全ての内容を文章に詰め込もうとすると、文章が長くなりすぎてしまうため、あくまで3x3は重要な要素を漏らさないための分析や整理のためのツールだと考えてください。
事例のまとめ
| 観点＼項目 | 課題 | 役割・行動 | 結果 |
|---|---|---|---|
| 周囲の客観（Context） |
なぜその取り組みが必要だったのか（WHY） ・組織／プロダクト全体で起きていた問題 ・放置すると何がまずかったか |
チーム構成や前提条件 ・人数、職種、役割分担 ・意思決定のされ方、裁量の所在 |
周囲から見てどう変わったか（アウトカム） ・業務フローの変化 ・チーム／ユーザーへの影響 |
| 自分の客観（Capacity） |
全体課題から自分に割り当てられた解決範囲（WHAT / WHEN / HOW） ・何を解く役割だったか ・期限や制約 |
自分の公式な立ち位置と関わり方 ・職種、担当範囲 ・他メンバーとの関係 |
自分が直接生み出したもの（アウトプット） ・実装、設計、仕組み ・完成させた成果物 |
| 自分の主観（Choice） |
自分が感じた本質的な課題 ・将来を見据えた懸念 ・理想の状態と現実のギャップ |
検討した選択肢と判断・トレードオフ ・採用しなかった案 ・制約下での意思決定 |
判断が効いて成立した状態 ・変更耐性、拡張性 ・後続対応への影響 |
今回は具体的な言語やフレームワークを出さずに説明しましたが、全体の技術、個別の技術、選択した理由などでもっと具体的な説明が可能になると思われます。
シーキューブモデルを使うことで、
- 周囲の課題と期待、状況
- その中で自分が担っていた役割
- そこで下した判断と、その判断が作った状態
を混同せずに説明できます。
その結果、「言われたことを実装した人」と「構造に責任を持って判断した人」の違いが、自然に分けて表現されます。
まとめ
シーキューブモデルはSTAR法を否定するものではありません。STAR法は経験を手早く共有するための優れたプラクティスです。しかしで、判断や責任の構造を評価したい場面では、客観的な情報と主観的な情報を上手く整理することが難しく、表現が不足することがあります。
シーキューブモデルは、前提となる状況、客観的な自分への期待、主観的ある頭の中で起きていた出来事、をもれなく整理するフレームワークです。
この内容を前提に職務経歴書をまとめることができれば、前提となる状況と自分への期待と自分の成果を比較することが可能になり、元々の期待よりもどれだけ大きいことができたのかを表現できるようになります。
つまり、エンジニアの経験を経歴の羅列や自分の物語ではなく、判断と責任の構造を明確にしてバランスよく説明するための観点を見つける整理法です。
特にシニア以上のエンジニアにとって、自分の価値を誤解なく伝えるためのツールになるのではないかと考えています。
技術的な観点での判断の深堀り
今回は技術的な観点の整理はしませんでしたが、こちらのnoteで技術的な意思決定の観点を深堀りして整理しています。
自分の頭の中で起きていた Choicex行動の判断がどのように行われたかを整理するにはこちらの記事も参考にしてください。
個人のエンジニアの方が転職するときに使っていただいたり、エンジニアのエージェントさんも広く伝わって、活用していただきたいと考えています。
もし、この記事が気に入ったのであればスキ、シェア、フォローなどをお願いします！