開発スタイルによって変わる、AIと一緒に抱えられるタスク量
直井氏の答えは、AIと一緒にアウトプットを増やし、2～3人分のタスクを自らの成果として抱えていく、というものだ。ただし「どれだけ抱えるか」の見極めは難しい。
この見極め方は開発スタイルによって変わってくる。内製でアジャイル開発を行っている現場では、比較的自由にタスク量を調整できる。プランニングの時点で多く見積もれなくても、スプリントを振り返った際に実質2～3人分をこなしていたとわかれば、次のプランニングで調整すればいい。イテレーション単位で実績を積み上げながら倍率を上げていけるため、AI駆動の働き方と相性がいい。
一方でウォーターフォール開発は、スケジュールが長期化しやすく変化に弱い。AIを使って数人分の成果を出すこと自体は可能でも、安全マージンとして2倍程度に抑えるのが現実的だ。加えて注意すべきなのは、AIが予算や規約変更、障害などの理由で突然使えなくなるリスクだ。タスクを抱えすぎた状態でAIが止まれば、それ自体がリスクになる。最初から何倍もの仕事量を前提にするのではなく、実績を丁寧に積み上げていく姿勢が欠かせない。
この構図は、SIerの人月単価という商習慣にも影響する。TRAILBLAZERは親会社であるJR西日本の内製開発を担う一方で、SIerとしての側面も持つ。事業会社の内製開発の視点では、生産性が2倍になったからといって給料が2倍になるわけではなく、売上に直結するアウトプットの増加につながって初めて還元される。SIerではさらに根深い問題があり、仮にAIを活用して2人分働いても、稼働しているのは1カ月分に過ぎないため、見かけ上は1人月分をタダ働きしているようにも映る。工数ベースの値付けから成果ベースの値付けへ。直井氏は、SESのような働き方よりも受託開発のほうが成果を見せやすいのではないかと述べつつ、その分の責任の重さも指摘した。
こうした変化の先で、エンジニアに求められる価値は「How」から「What／Why」へと移っていく。どう作るかの多くをAIが担うようになる分、なぜそれを作る必要があるのか、何を作るべきなのか、それがビジネスにどう貢献するのかを語れる人材の価値が相対的に高まる。フロントエンドの担当者がバックエンドを、プロダクトマネージャーがエンジニアリングを担うといった形で、垣根を越えた動き方が当たり前になる中では、何のためにそれをやるのか、どんな事業貢献になるのかを自分の言葉で説明できるかどうかが、エンジニアの価値を分ける。
ただし、すべての役割がなくなるわけではない。セキュリティなどの品質担保や、テックリードに求められるアーキテクチャ設計といった専門性は、なお重要な領域として残る。もっとも、こうした専門性もAIで賄える範囲が徐々に広がっていくため、椅子の数自体は少しずつ減っていく。
変わり続けること自体が、新しい役割だ
こうした変化を前に、エンジニアに新しく求められるのが、言語化・概念化する力と、別のロールの人たちと動けるコミュニケーション能力だ。これまではスペシャリストとして自分のロールに専念していればよかったが、やるべきことが一気に増える。事業への理解やオーナーシップを持ち、ビジネスへの貢献を意識する姿勢も、全員に求められるようになる。
組織のあり方も変わらざるを得ない。採用予算の一部をAIに振り向ければ、単純に採用できる人数は減り、組織はどうしても少数精鋭に寄っていく。ただし、少数精鋭に寄せるほど、ジュニア層が実践を通じて成長する機会は失われやすい。AIに教えてもらうことである程度は補えるとしても、あえて任せる仕事や余白を意図的に設計し、成長の機会をつくっていく必要がある。このバランスを取ることが、これからの組織マネジメントの課題になる。
直井氏が最終的にたどり着いたのは、「変わり続けること自体が、新しい役割だ」という結論だった。AIが進化し続ける限り、あらゆることが変わり続ける。だからこそ今日話した内容もすべて「仮」であり、自分1人分以上の仕事をしっかりやっていくことが、これから先の価値を示すことになる。直井氏は「AIと一緒に何倍のタスクを取れますか」という問いを、自身のパートの結びとして残した。
