昨今のシステム開発においてコード生成AIは欠かせない存在となっており、Claude Code などエージェント型コーディングツールの出現により、エンジニアはAI部下を持つエンジニアリングマネージャーとなる未来が予想されています。
コード生成をしたことがある人は「AIにどこまで任せるべきか？」という問いを一度は考えたことがあると思います。マネジメントにおいてタスクの責任を自分から部下へ移動させることを「委譲」と呼びます。
委譲とは、タスクの責任を自分から部下へ移動させることです。
— 『エンジニアリングマネージャーのしごと』オライリー・ジャパン, p.49
書籍『エンジニアリングマネージャーのしごと』の「3.2 委譲」の章を参考に、この概念をAIとの協働にも応用できる可能性を考えてみたいと思います。
エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法
委譲の基本概念
まず、委譲において本書では責任を以下の2つに分類して説明しています。
- 説明責任：タスクを求められる品質で完了させる責任
- 実行責任：タスクを実際に自分で行うということ
説明責任は移動することができないため、AIにタスクをお願いした場合でもそれを評価するための技術力は必要になります。例えば、生成したコードの動作原理や選択したアルゴリズムの根拠を説明できる能力が求められます。また、コードに限らず出した結論や提案の妥当性を評価し、必要に応じて根拠を示せることも重要です。
つまり「AIにどこまで任せるべきか？」という問いは「生産性や品質を担保しつつ実行責任をどこまでツールに移動してよいか？」と言い換えることができます。
委譲の失敗パターン
本書にて適切に委譲が行えていない例として以下の2つが挙げられていますので、ツールを利用した場合に読み替えて考えてみます。
1. マネージャーが全く委譲できていない状況
これはAIを全く信頼せずにマイクロマネジメントをしている状態です。マネージャーが全てのタスクに説明責任と実行責任を持とうとすると、自身は細かな意思決定やレビューに忙殺され、本来発揮できる能力が十分に活用されません。ツールを活用する最大の利点の一つはスケーラビリティですが、マネージャーがボトルネックになることでその利点が失われてしまいます。
マネジメントにおいても、これは「重要な仕事は全部自分がやらなければならない」という思い込みから生じるとあり、この考え方を変える必要があるのはツール活用においても同様です。
2. 委譲しない反対「丸投げ」
反対に、AIを信頼しすぎて実行に関わる意思決定を全て任せてしまう状態も問題です。この場合、フィードバックが行われない状態となり品質管理が困難になります。結果に対するフィードバックやそれを蓄積し次回に活かすプロセスはマネージャーとして不可欠な役割です。
また、最悪なのが説明責任を放棄している状態であり、そのような場合は人である必要がなくなってしまいます。
委譲の物差し
上記のような極端な例に陥らないように本書では委譲のレベルを7段階に分けた「委譲の物差し」が紹介されています。
この図が示すように、適切な委譲の度合いを選択するのはマネージャーの責任です。アウトプットの品質をチェックしながら少しずつ委譲のレベルを高めたり、重要度の高いタスクについてはコントロールを強めるなどの調整が必要になります。
ツールの場合は、人とは異なり育成や成長の観点が無いことや、いちど渡したタスクを取り返してもエラーにはならないなど、試行錯誤はしやすい一方で良い活用にはツールを使う側の成長が求められる場面も多いと感じます。
自身が何に衝動を感じるのかはそれぞれだと思いますので、生産性や品質だけにとらわれずに、試行錯誤の中でより良い関係を探っていきたいと思います。
まとめ
エンジニアリングマネージャーの委譲スキルについて、AIとの協働においても応用できるか考えてみました。
テクノロジーの進化により前提は変わり続けるため、より良い働き方を考える上で、マネジメントの技術とプログラミングの技術をあせて学び続けることが大事かもしれません。