AIによって実装のハードルが下がり、職種の垣根が溶けていく
直井和久氏は2024年7月にTRAILBLAZERへ入社し、現在は共創ソリューション事業部の部長として、グループのプロダクト開発を推進している。
セッションタイトルには、あえて「（仮）」の文字が残されている。その理由は、AIの進化があまりに速く、半年前と今とでは状況が様変わりし、今日話す内容も明日には答えが変わっているかもしれないからだ。そうした前提そのものが、直井氏のメッセージの土台になっている。
直井氏がまず投げかけたのは、「この1～2年で、働き方が大きく変わっていませんか」という問いだ。すると、会場の参加者の多くがAIをチャットで使い、Claude CodeやGitHub Copilotを開発にも活用していると回答。コードを書くこと自体は、すでにAIがかなりの部分を担えるようになっており、実装のハードルは着実に下がっている。
その結果として起きているのが、職種の垣根が溶け始める現象だ。エンジニアがプロダクトのことを考えられるようになる一方で、プロダクトマネージャーがエンジニアリングに近い領域まで踏み込む。フロントエンドの担当者がバックエンドの苦手な部分をAIに任せ、バックエンドの担当者がフロントエンドの経験がなくてもAIと一緒に手を動かす。そうやって職種や担当の垣根を越えて動くことが当たり前になり、エンジニアに求められる役割も変わっていく。
開発フロー自体も様変わりした。これまではPRD（要件定義書）を書いてデザイン、設計と工程を積み上げ、実際に動くものが見えるのは開発の後半になってからだった。今はPRDを書いた時点でバイブコーディングによってモックが作れるため、ビジネスサイドへの説明がしやすくなっている。エンジニアの観点があれば、実物に近いプロトタイプをその場で作れる時代になった。
直井氏自身の働き方も変わった。管理業務に軸足を置く立場になって以降、これまでは会議や1on1と資料作成などの作業時間がほぼ半々だったが、今は作業のほとんどをAIに任せている。資料の完成度を追い求めず、会議でフォローすればいいという前提に切り替えたことで、考える時間そのものを業務時間内に確保できるようになったという。
働き方が変われば、次に問われるのは成果の見られ方だ。AIが担った仕事量は、誰の実績としてカウントされるべきなのだろうか。
開発スタイルによって変わる、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と一緒に何倍のタスクを取れますか」という問いを、自身のパートの結びとして残した。
フルスタックエンジニア「のようなもの」と自称する背景
セッションの後半では西林拓志氏が、開発現場のリアルな声を紹介した。西林氏は2025年6月にTRAILBLAZERへ入社し、共創ソリューション事業部に所属。今年4月まではWESTERのAndroidアプリの改善や技術負債分析を担当し、4月からはtabiwaのチームでフルスタックエンジニア「のようなもの」として働いている。Androidアプリの開発歴は趣味を含めて2009年から、Kotlinは2014年からと、モバイルアプリの開発を軸にエンジニアのキャリアを歩んできた。
西林氏は自らを「T型の技術屋」と表現する。2010年に新卒でソフトウェアエンジニアとしてキャリアをスタートさせ、モバイルアプリの開発を中心に15年ほど、バックエンドもPerlとPHPで3年ほど経験。TRAILBLAZER入社前の直近2社では、テックリードやアーキテクトといった役割を約7年務めてきた。新しい技術を身につけてプロダクト開発に活かし、社内外のコミュニティで知見を交換しながらプレゼンスを高めていく。それが生成AI以前の生存戦略だった。
ところが生成AIの登場で、この前提が揺らいだ。コードを書くこと自体はAIが担えるようになり、専門知識もある程度はAIが補完してくれる。スペシャリストとして専門領域だけで勝負し続けられるのか、という不安がよぎった。そこで西林氏が選んだのは、自らが「狭義のスペシャリスト」と呼ぶ立場から、「広義のスペシャリスト」への転換だった。
具体的には、AIに概念や記法を教わりながら知識を広げている。「uvはどういう世界観で動いているのか」といった概念の解説から、得意なKotlinの技法をPythonでどう書くかという言語間の橋渡し、気になっているSvelteの書き方を演習形式で学ぶところまで、AIを知識のブースト装置として使い倒す。その結果、バックエンドとフロントエンド、モバイルアプリを一気通貫で開発し、Android以外のコードもメンバーの1人としてレビューする、フルスタックエンジニア「のような」立場に行き着いた。ただし、この転身について西林氏は率直な本音も語る。
ボトルネックは、自分の「評価できる力」だった
ここまでは前向きな転換に見えるが、西林氏は「実際はそんなにうまくいっていません」と明かした。理由は、コードが「動かない」のではなく、「正しいかわからない」という判断に時間が溶けていくことにある。AIが出したコードがモダンな実装なのか、既存の設計と乖離していないか、意図しない影響範囲がないか。AIに聞き直しても「大丈夫です」としか返ってこず、自分自身で判断がつかない。
Androidアプリ開発に関しては、16年間で身につけた「見分ける目」と「ニオイに気付く力」がそのまま生きる。設計の良しあしやバグの気配を一瞬で見抜けるため、手が止まることもない。だがそれ以外の領域では、ドメイン知識や仕様理解の不足から、AIのもっともらしい出力に紛れた間違いに気付けない。実装を終えてレビューに回すと、既存の実装との重複や仕様とのズレが見つかり、ちょっとした修正のはずが予想以上に時間を使ってしまう。同じAI、同じプロンプトを使っているにもかかわらず、Androidアプリとそれ以外とでは開発スピードがまったく異なる。
知識が不足していると、AIエージェントに指示を出すことはできても、できあがったものが本当に正しいかを評価する精度が低くなる。西林氏は「ボトルネックは自分の『評価できる力』にあるんです」と語る。
AIに使われるのではなく、使いこなす側へ
西林氏は今後、評価できる力をひたすら育てることに注力していくという。引き続きAIに教えてもらいながら知識のブーストを図り、まずはフロントエンドに関して、Androidアプリと同じレベルまでではなくとも、一般的なエンジニアの水準まで戦える領域として広げていく。
その先に見据えているのは、AIに使われるのではなく使いこなす側に回ることだ。最新情報のキャッチアップそのものをAIで行い、個人開発や業務、コミュニティで得た知見を、業務に最適化したAIエージェント環境の構築、いわゆるハーネスづくりに役立てていく。コードを書くことだけがAIエージェントの使いどころではなく、本セッションの登壇資料も西林氏自身がAIにインタビューされる形でアウトラインを組み立てたものだという。そのうえで、判断すること、責任を持つこと、そしてコミュニティに出てアウトプットや交流を続けることは、引き続き人間にしかできない領域として大切にしていくという。
実装がAIに移っていく時代に、エンジニアとしてどう価値を示すか。西林氏は自身のパートを、こんな言葉で締めくくった。「AI時代のエンジニアの生存戦略、どうお考えですか。めちゃくちゃ大変だと思いますが、がんばって生き残っていきましょう」。
TRAILBLAZERからのお知らせ
TRAILBLAZERではエンジニアの仲間を募集しています。開発環境やカルチャー、現在募集中のポジションなど、詳しくは採用情報ページをご覧ください。
