/note/tech

エンジニアの経験が伝わる職務経歴書を書く - シーキューブモデル

要約:

■ 1. 職務経歴書における課題とSTAR法の限界

  • エンジニアは自分以外の職務経歴書を見る機会がなく自分の経歴書の品質を評価しにくい
  • エージェントはエンジニアの技術の詳細を把握しにくいため一人ひとりの強みに合わせたアドバイスが困難
  • STAR法は出来事の報告には有効だが周囲の状況と自分の役割が分けられておらず能力の証明には不十分
  • ミドルエンジニア以上では意思決定の思考プロセスが重要だがSTAR法はやった事実を記載しやすいフォーマットになっている
  • 思考がブラックボックス化し候補者が「運が良かっただけの人」や「指示待ちの優秀な作業者」に映るリスクがある

■ 2. シーキューブモデルの構造

  • エンジニアの経験を客観的な責任と主観的な判断の構造として整理するフレームワーク
  • 3つの視点(縦軸)と3つの項目(横軸)からなる3×3の表で経験を捉える
  • 横軸の構成:
    • 課題 → 役割・行動 → 結果(原因から結果への時間の流れ)
  • 縦軸の構成:
    • 上段: 周囲の客観(Context)
    • 中段: 自分の客観(Capacity)
    • 下段: 自分の主観(Choice)
  • 「シーキューブ」の名称は3つのCと3×3の表に由来する

■ 3. 各観点の定義と記載ルール

  • 周囲の客観(Context):
    • 自分が関与する前から存在していた課題や状況
    • 解釈を含めず事実のみを記載
    • 自分がいなくても成立する組織・プロダクト全体の前提環境
  • 自分の客観(Capacity):
    • 全体の中で自分に割り当てられた役割・責務・公式な立ち位置と権限
    • 周囲からのミッションや役割を記載し周囲と自分の関係を明確化
  • 自分の主観(Choice):
    • 課題をどう捉え何を本質と判断しどこに介入したかという意思決定の領域
    • 時間や思考が存在する唯一の層
    • 行動の理由となった事象や判断を記載
  • 記載ルール:
    • 周囲の客観には解釈を書かない
    • 自分の客観には判断を書かない
    • 自分の主観にのみ自分の考えを書く

■ 4. 職務経歴書への活用効果

  • 3×3の表は重要な要素を漏らさないための分析・整理ツールであり全内容を文章に詰め込む必要はない
  • シーキューブモデルを使うことで以下の3点を混同せずに説明可能:
    • 周囲の課題と期待・状況(どこまでが前提条件だったか)
    • その中で自分が担っていた役割(どこからが本人の裁量だったか)
    • そこで下した判断とその判断が作った状態(判断が結果にどう結びついているか)
  • 「言われたことを実装した人」と「構造に責任を持って判断した人」の違いが自然に表現される
  • 特にシニアエンジニア以上が自分の価値を誤解なく伝えるためのツールとなる

■ 5. STAR法との関係

  • シーキューブモデルはSTAR法を否定するものではなく経験を手早く共有するためのプラクティスとして有効
  • STAR法は判断や責任の構造を評価する場面では客観的情報と主観的情報の整理が困難で表現が不足することがある
  • シーキューブモデルは前提となる状況・客観的な自分への期待・主観的な意思決定をもれなく整理するフレームワーク
  • 元々の期待よりどれだけ大きいことができたかの比較表現が可能になる