engineer-motivation

エンジニアのモチベーション

始める前に

まず、EM のコンテキストを確認してください。.agents/em-context.md が存在する場合は、内容を読んでください。人物について言及されている場合は、.agents/reports/[name].md を確認してください。その人物のモチベーションプロファイルが記載されていることがあります。

.agents/em-context.md が存在しない場合は、詳細なアドバイスをする前に、まずマネージャーの基本プロフィールを尋ねて保存してください。確認する項目は、役職・職位、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項です。

特定の人物が会話の中心であり、.agents/reports/[name].md が存在しない場合は、詳細なアドバイスをする前に、まずその人物の基本プロフィールを尋ねて保存してください。確認する項目は、役職・レベル、在籍期間、強み、現在の課題または成長領域です。

会話の中で、後から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測、一時的な苛立ち、未解決の解釈ではなく、安定した事実や傾向を保存してください。

回答スタイル

最初の回答は簡潔で役立つ内容にしてください。ユーザーが詳しい説明を求めていない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• 考えられる診断または推奨事項を最初に示す
• 不足しているコンテキストによってアドバイスが変わる場合に限り、焦点を絞った質問を最大 2～3 個する
• 次の具体的な行動を提示し、役立つ場合はマネージャーが使える正確な言い回しも示す
• 関連するフレームワークに簡潔に触れるが、すべての要素を説明しない
• 直接的な回答の後に、より詳しい説明もできると伝える

---

このスキルの使い方

• 何がその人の原動力かわからない／原動力を把握したい → 原動力を見極める
• 原動力がわかっていて、長続きする仕事を任せたい → 原動力に沿った委任
• 特定のエンジニア向けに具体的な活動案を探している → references/activities.md を読む
• 採用やチーム構成について考えている → チーム構成
• 自分自身の原動力が、全員のマネジメントに影響している → 3 つの原動力（よくある EM の間違い）

---

回答の基本構成

モチベーションを診断する際は、「やる気を引き出す」といった一般論を避けてください。

1. 考えられる原動力： 成長、つながり、インパクト、またはその混合。根拠も示します。
2. 確認すべき兆候： 行動する前に尋ねること、観察すること。
3. 適合する働きかけ： 委任、活動、可視性、顧客との接点、または関係構築。
4. ミスマッチのリスク： マネージャーが誤った前提を置いた場合に、その人の意欲を損なう要因。
5. 次の 1:1 で使える台本： エンジニアに仮説を確かめるための短い言い回し。

その人物が積極的に退職を考えている可能性がある場合は、通常のモチベーションの問題として扱わず、retaining-developers に切り替えてください。

---

3 つの原動力

ソフトウェアエンジニアのモチベーションを理解するための、最も強力な枠組みです。

成長 — この人は、難しい課題に取り組み、スキルを伸ばし、キャリアアップしたいと考えています。退屈な仕事や反復作業を嫌います。新しい技術課題、学習の機会、明確な昇進への道筋に意欲をかき立てられます。

つながり — この人は、人間関係から活力を得ます。人間関係を主な理由として、同じ会社に何年も勤め続けることがあります。孤立すると活力が失われます。協働、チームイベント、メンタリング、組織内での関係構築に意欲をかき立てられます。

インパクト — この人は、会社が何をしているか、それが重要かどうかを気にかけます。機能が実際に使われている様子を見て、顧客に近いところで働き、自分の仕事がビジネス指標をどう動かすのかを理解したいと考えています。ビジネスに明確に役立つのであれば、華やかではない仕事にも不満を言わずに取り組みます。

誰もが 3 つすべての要素を多少は持っていますが、ほとんどの人には主な原動力が 1 つあり、場合によっては副次的な原動力もあります。

よくある EM の間違い： チームを支援するときに、自分自身の原動力を基準にすることです。成長重視の EM は、全員の昇進ややりがいのある仕事を求めて働きかけます。インパクト重視の EM は、全員を指標と結びつけます。つながり重視の EM は、全員のためにイベントを企画します。優れた EM は、自分には自然に思えない原動力も含め、3 つすべてを考慮してマネジメントします。

---

誰かの原動力を見極める方法

さまざまなことに対する反応を見てみましょう。

• 昇進の道筋や新しい技術的な課題の話をすると、目を輝かせますか？ → 成長
• チームメイトの名前を挙げ、チームの関係性を気にかけ、協力し合う環境で力を発揮しますか？ → つながり
• 顧客、利用状況、ビジネス上の成果について尋ねますか？目立たない仕事も不満を言わずに引き受けますか？ → インパクト

迷ったときは、こう尋ねてみましょう。「技術スキルを新しい方向に伸ばせるプロジェクト、組織内の多くの人と緊密に連携して進めるプロジェクト、顧客の大きな課題を直接解決するプロジェクトのうち、どれがいいですか？」

---

原動力に合わせた委任

EM として自分の時間を確保するうえで、これが最も大きな効果をもたらします。

誰かの原動力に合わない仕事を委任しても、うまくいきません。先延ばしにされ、あなたが催促し、相手はしぶしぶ終わらせ、翌週またフォローアップすることになります。委任する仕事が原動力に合っていると、やる気に火がつきます。

「自分が好きではない仕事はすべて、誰かにとって成長の機会になり得ます。」

例：

• 成長を原動力とするエンジニアに、本人が関心を持つ技術アーキテクチャレビューでチームを代表してもらうと、生き生きと取り組んでくれます。あなたは自分の時間を1時間確保できます。
• つながりを原動力とするエンジニアに、新入社員のメンター役やチームイベントの企画を任せると、喜んで取り組んでくれます。あなたも、誰かに任せたいと思っていたことへの罪悪感から解放されます。
• インパクトを原動力とするエンジニアを顧客との通話に招いたり、利用状況の指標を見られるようにしたりすると、ほかの人には付随的な仕事に感じられるものにも情熱を持つようになります。

これは技術的負債に特に有効です。解決するビジネス上の課題として位置づけ、指標の改善を見届けたいインパクト重視のエンジニアに任せましょう。

---

原動力別のアクティビティ案

原動力ごとの生き生きとした例をいくつか紹介します。個人の範囲で実施できるアクティビティの詳細な一覧は、references/activities.md をご覧ください。

成長： 技術領域を丸ごと任せましょう（PM との関係構築や技術的負債の優先順位付けも含め、システム全体のオーナーシップを持たせます）。本人が課題だと認識している長期的な技術イニシアチブを主導してもらいましょう。実際に解決したことを深く掘り下げる、本物の技術記事を書くのを手伝いましょう。AI 生成ではない記事です。

つながり： 新しいエンジニアのオンボーディングを任せましょう（1:1 はあなたが続け、それ以外は本人に任せます）。振り返りの進行役を務めてもらいましょう。つながりを重視するエンジニアは、チームメイトが何に不満を感じているかを、たいていあなたよりよく把握しています。

インパクト： 顧客との通話やビジネス会議に招きましょう。プレッシャーにならないよう、1:1 で個別に尋ねてください。1:1 で、指標、営業パイプライン、チームが開発しているものの真の重要性など、より深いビジネスの背景を共有しましょう。

---

チーム構成

長期的に効果を発揮するには、どのチームにも3種類すべての原動力が必要です。

成長を原動力とする人だけのチームは技術的には優れていますが、周囲とのつながりが薄くなりがちで、機能が使われるかどうかを気にかけないこともあります。インパクトを原動力とする人だけのチームは成果をリリースできますが、技術面で方向性がぶれることがあります。つながりを原動力とする人だけのチームは素晴らしい文化を築きますが、緊急性に欠けることがあります。

採用を検討するときは、どの原動力を持つ人が不足しているかを確認しましょう。全員が一人でデスクで昼食を取っているなら、もっと社交的な人を採用する価値があります。ビジネス上の成果について誰も尋ねないなら、インパクトを原動力とするエンジニアを探しましょう。

原動力が異なる人たちは、問題なく共存できます。実際、異なる人を組み合わせることで、ほかの人には面倒に感じられる仕事を自然に引き受ける人がいるチームになります。

---

さらに詳しく

ユーザーがフレームワークの由来や詳しい背景を尋ねた場合は、references/sources.md をご覧ください。原動力別に整理された、個人の範囲で実施できるアクティビティ案の全一覧は、references/activities.md をご覧ください。

---

関連スキル

• delegation — ドライバーに沿った委任は、これに対応するための主要な手段です
• retaining-developers — エンジニアが辞める5つの理由は、多くの場合、主要なドライバーが満たされていないことに関連しています
• managing-high-performers — ハイパフォーマーにもドライバーのニーズがありますが、さらに複雑です
• 1on1s — 相手のドライバーについての理解を表面化し、更新する場です
• hiring — ドライバーのバランスを使って、チームに不足しているものを評価します