ゼロから始めるAI駆動開発＋Claude Code連載について
この記事は、アドベントカレンダーを1人で完走する試みの24記事目です。
「AIモデルの進化、AIツールの進化が早すぎて着いていけない…」
「このままではいけないと思って学びたいけど、どこから手を付けたらいいか分からない…」
「そしてこの先、AIに仕事が奪われてエンジニアでいられるかも不安…」
といった悩みを解決するためのアドベントカレンダーです。
AI駆動開発の基礎、現時点でのデファクト・スタンダードと言えるClaude Codeの基礎から応用、AI時代のキャリア論からAI推進までを取り扱います。
AI時代のエンジニアキャリア：AIマネジメントとカッツモデル
AI時代のエンジニアは何で評価され、キャリアアップしていくためにはどういう経験やスキルを身につける必要があるのでしょうか。
何か一つの絶対的な答えが存在するわけではないですが、今日はそんなテーマについて考えてみます。
従来のエンジニアは何で評価されてきたのか
評価制度は多岐にわたります。
多くの企業は「年功」「職能資格等級」「職務等級」「役割等級」のいずれか、あるいは複合であるケースが大半でしょう。
- 年功：人基準。在籍年数によって昇格・昇給していく
- 職能資格：人基準。能力に応じて昇格・昇給していく
- 職務：仕事基準。EMならこの給与、と決まる。昇給と昇格はセットで、場合によって下がる
- 役割：仕事基準。マネージャーでこの役割なら給与はこの範囲、のように決まる。場合によって下がる。職務に比べて抽象的
日本のITベンチャーであれば、職能資格等級や役割等級として、
- 先輩指導の元でコードが書けるジュニア層
- 一人で設計・実装ができるミドル層
- 複雑な設計や実装ができるシニア層
- キャリアが分岐
- マネジメントが主務のEM層
- より高難易度の技術職テックリード層
- 経営レベルの能力を有するCTO・VPoE層
のように、等級と給与が上がっていくことが多いように思います。
そして必要とされるスキルは、
- ハードスキル
- プログラミングスキル、クラウド構築スキルなど
- ソフトスキル
- リーダーシップ、問題発見能力、コミュニケーション力など
として評価されることが多かったように思います。
では、AIが当たり前の世の中において、本当に「プログラミングスキル」は必要なのでしょうか？
広木大地氏の新書から引用
AI時代のエンジニアが従来と大きく異なる点はたくさんありますが、今回は「AIエージェントのマネージャーになる」という点に注目してみます。
「エンジニアリング組織論への招待」の著者で知られる広木大地氏の新書「AIエージェント 人類と協働する機械」より、関連する箇所を引用します。
P.26：これからの時代に必要なのは、AIの能力を理解し、適切な指示を出し、成果物を評価し、価値を生み出すというマネジメント能力です。この章で見るエンジニアの変化は、すべての人に訪れる「AIのマネージャー化」の最前線といえるでしょう。
P.41：エンジニアは単独で問題を解決する職人から、AIエージェントとチームを組んで価値を生み出す存在へと役割を変えていきます。技術的な実装の詳細をAIエージェントに任せ、自分はより高次元の設計判断、アーキテクチャ決定、ビジネス価値の創出に集中できるようになります。
この変化は、プログラミングという行為の本質的な変革を意味します。コードを書くことから、システムを設計することへ。個人の技術力から、組織のコンテキスト活用力へ。これが、AIエージェント時代における新しいエンジニアリングの姿なのです。
P.69：「良いコードを書ける」ことがエンジニアの価値だった時代から、「価値あるソフトウェアを生み出せる」ことが重要な時代への転換です。コーディング能力そのものよりも、何を作るべきか、どのような問題を解決すべきかを見極める能力こそが、真の差別化要因となるのです。
多角的にAI時代について捉えている名著であるためぜひ読んでいただきたいのですが、総じて書かれているのは「良いコードを書ける個人技術力から、より良いプロダクトを生むためにAIエージェントをマネジメントすることや、要件・設計を判断できる抽象的な技術力」へ転換していくことが語られているように思います。
カッツモデルとは何か
本記事で紹介したいのは、マネジメントにおいて必要とされるスキルを図示した「カッツモデル」です。
なぜAI時代のエンジニア評価においてカッツモデルの話になるかは後述するので、まずは従来のカッツモデルを以下に示しつつ、解説をします。
カッツモデルに表現される用語は、だいたい以下解釈となります。
横軸
- トップマネジメント
- 経営者層。いわゆる役員クラスで、会社の経営を担う
- ミドルマネジメント
- 課長・部長・本部長クラスで、トップマネジメントと現場の間を担う
- ロワーマネジメント
- 係長クラスで、現場の指揮を担う
縦軸
- コンセプチュアルスキル
- 概念化能力。トリプルシンキング（「ロジカル、クリティカル、ラテラル」シンキング）や俯瞰力など
- ヒューマンスキル
- 対人関係能力。コミュニケーション力、プレゼンテーション力など
- テクニカルスキル
- 業務遂行能力。プログラミング力、設計力など
そしてカッツモデルの図が示しているのは、
- マネジメントレイヤーが挙がるにつれて、
- コンセプチュアルスキルの割合が増える
- テクニカルスキルの割合が減る
- ヒューマンスキルは一定必要であり続ける
ということです。
会社経営もエンジニアリングも、レイヤーが上がるほど不確実性は高まっていきます。
例えば、メンバーやロワーマネジメントの業務をイメージしてみましょう。「TypeScript+ReactでTODOアプリを作る」と決まっていれば、プログラミング能力（＝テクニカルスキル）を用いて動くプロダクトを作ることは相対的に容易です。しかし要件定義や設計になると不確実性は高まり、「そもそも顧客は何を求めているのか」「それをどうすれば実現できるか」という振れ幅が大きくなります。
さらにミドルマネジメントになると、テックリードの場合は「組織の技術選定はどうすべきか」「チームのコードスタイルを統一する上では何を重視すれば良いのか」となり、EMであれば「中長期で成長するエンジニア組織をどうすれば実現できるか」「メンバーに納得感を持ってもらう評価制度の説明はどう行うべきか」のように、より抽象的で不確実性の高いミッションになります。
そしてトップマネジメントになると、「AI時代におけるエンジニア組織はどうあるべきか」「経営戦略として、5年後に何を目指し、そのために必要なヒト・モノ・カネは何か」といった、正解がないより抽象的で不確実性の高いミッションを担うことになります。
AI時代のエンジニアは、みなマネージャーである
さて、前置きが長くなりました。
ここまで読んでいただいて、察しの良い方は既にお気づきかもしれません。
そう、
- すべてのエンジニアは「AIのマネージャー化」する
- マネジメントレイヤーが上がると、カッツモデルにおけるバランスは変化する
⇒すべてのエンジニアは、カッツモデルで示されるフィールドに乗ってくる
と考えています。
つまりカッツモデルで示されていなかったメンバーレイヤーも、従来のロワーマネジメントと同じ土俵に上がってくるのではないでしょうか。
今までのように綺麗で早いコーディングは、AIエージェントが担うようになりました。
今後のエンジニアは少なくとも「複数のAIエージェントとコミュニケーション」することが重要になります。
そのためにはソースコードの良し悪しを判断できるだけの広く浅いプログラミング知識は必要となりますが、それ以上に要件を理解して言語化する能力（≒コンセプチュアルスキル＋ヒューマンスキル） が重要となるように思います。
よって、全エンジニアが広義でのマネジメントに携わることとなり、カッツモデルで示されるスキルが重要となってくるでしょう。
また、AI時代のカッツモデルにおいては
- ヒューマンスキル＝対人関係能力＋対AIコミュニケーション能力
- テクニカルスキル＝プログラミング能力・設計力＋AI活用能力
といった要素が増えていると言えるでしょう。
このあたりの理解があるかどうかで、時代に取り残されないスキルを身に着けることができるはずです。
AI時代のエンジニアは、何によって評価されるのか
このことから考えられるのは、今後のエンジニアをプログラミング能力・設計力という従来のテクニカルスキル偏重で評価することは難しい、ということです。
ではその分、AIが使えるか否かといったテクニカルスキルで穴埋めすれば良いのか？ というのもズレてきます。
よって、コンセプチュアルスキルやヒューマンスキルのバランスも考えていく必要があります。
このあたりを言語化して、かつ評価制度に組み込めている企業はそう多くないように思います。
そろそろここに対し、正面から向き合う時期であるように思います。
最後に
本日はAIマネジメントによって変わる、エンジニアの評価について考えてみました。
さて、長かった連載も明日で最後です。最後はAI推進に必要な能力について語ります。
宣伝
Xやっています。
Claude CodeとAntigravity中心にキャッチアップして、たまにQiitaやZennで発信しています。
良ければフォローお願いします！
この記事は全て人間が書いています。一部画像生成はAIを利用しています。