AI技術の進化は、開発プロセスと組織のあり方の見直しを世界中のテックリーダーに迫っている。だが、AI導入・技術選定・組織の理想像のいずれにも「正解」は存在しない。
「成果が一部のメンバーに留まり組織に広がらない」「どこまでAIに任せるかの基準が定まらない」「AI時代のエンジニアの役割・評価基準の方針が出せない」──多くの開発現場がこの三つの課題を抱えながら手探りを続けている。

2026年5月19日、ファインディ株式会社が主催したイベント「なぜAI活用に『正解』はないのか？エンジニアの価値を高める開発現場の最適解」では、特定のツールや手法に依存せず、試行錯誤を通じて自社なりの最適解を見出してきた二社が登壇した。
組織横断でAI活用を推進するKDDIの鎌田宣昭氏とリクルートの鶴谷誠文氏が、現場発の成功事例を組織全体へ展開する意思決定プロセスと具体的な取り組みを語った。

本イベントレポートでは、役割分担の境界線の引き方、個人の取り組みを組織標準へ昇格させる手法、そしてAI時代に人が担うべき価値という三つの論点から、両社の実践知を読者の自社課題に引き寄せて整理する。

【イベント概要】

• イベント名：なぜAI活用に「正解」はないのか？エンジニアの価値を高める開発現場の最適解
• 開催日時：2026年5月19日（火）／ハイブリッド開催
• 主催：ファインディ株式会社
• 登壇者：
  • KDDI株式会社 先端技術統括本部 先端プラットフォーム開発本部 コミュニケーションプラットフォーム 部長 鎌田 宣昭 氏
  • 株式会社リクルート データ推進室 データプラットフォームユニット VP 鶴谷 誠文 氏

両社とも「組織横断でAI活用を推進する立場」という共通点を持つ。鎌田氏は通信を武器にしたプラットフォーム（CPaaS）と全社のモダンアーキテクチャ化、AI駆動開発の推進を担い、鶴谷氏はデータプラットフォームの組織長として、エンジニア組織横断のAI活用プロジェクトとAI基盤整備を率いている。
立場は似ていても、組織文化とアプローチには明確な違いがあり、その対比こそが本イベントの見どころとなった。

【テーマ① AIと人の役割分担 ― 開発現場における新たな分業のかたち】

課題・背景

AIが実装・テスト生成・コードレビューまでこなせるようになった今、「AIに任せる範囲」を多くの現場が手探りで決めている。
スピードと品質が向上する一方で、「人間が本質的に担うべき役割は何か」「どこに境界線を引くか」の再定義が各社に求められている。

取り組み内容

両社に共通するのは「全工程でAIを使う。ただし責任は人が持つ」という原則だった。

KDDIの鎌田氏は、要件定義からリリース、運用まで全領域でAIをフル活用しつつ、各工程で必ず人間が判断する体制を敷く。
鎌田氏にとって「判断する」とは「責任を取る」ことと同義だ。その前提として重視するのが、AIが安全に自律動作できる開発プロセスの設計である。
「ソースをあちこちに置くとAIは最大限の力を発揮できず、品質も悪化していく」と鎌田氏。

そこでKDDIはSSOT（Single Source of Truth）を徹底し、すべてのソース・ドキュメント・ルール（スキルを含む）を一貫した範囲に集約。「ここを見ればすべて完結できる」環境を作り、人間がハンドリングする。
やっていいこと・ダメなこと・伝えるべきことを、設計概念やステアリングファイルとして「どのタイミングで何を読むか」まで定義し、AIと人の双方を教育していく。
実装やテストはエージェントが自律的にこなすため、下流工程ほどサブエージェントやエージェントチームの成果を最終確認する役割となり、上流工程ほど人間のアーキテクチャ設計が品質を左右する。

リクルートの鶴谷氏も「ほぼ同じ」としつつ、工程ごとのAI介在度の違いを言語化した。
上流ほど壁打ち中心で人の依存度が高く、設計・開発・テストへ進むほど成果物の生成をAIに任せる比率が高まる。
一方で「AIが生成したアウトプットの責任は人にある。AIに丸投げしない、というのは社内の共通認識として常に会話している」と語る。
現時点では、最終のアウトプットの品質スタンプはどの工程でも人が押す必要があるとの立場だ。

成果・学び

鎌田氏が最も実感を込めて語ったのが、開発体制の違いが生産性を激変させたという1年間の経験だ。
要件定義のみ自社・設計以降を委託する請負型、製造だけを委託する型、全体内製型と、さまざまなパターンでAI駆動開発を実践した結果、請負型のままではAI活用が「分断」され、生産性は頑張っても10%程度しか上がらなかった。

鎌田氏は、「分断は品質も分断する。検証する人が変わるので、違うものができてくる」と語る。逆に、一貫性のあるAIで一貫したチェックを、しかも上流で行うと品質はさらに高まるという。
要件・ビジネスの運用性を自社が握り、下流工程こそ複数のエージェントやスキルでチェックする。
見る観点が違っても、上流をしっかり押さえられるチェック体制のほうが品質を大きく左右する、という逆説的な結論だ。

印象的なコメント

KDDI 鎌田氏「請負開発のままだとAI活用が分断する。分断は品質も分断するんです。違うものを作ってくる。でも一貫性のある形でやると、しかも上流でやると、品質はさらに高まる。逆説的なんですけど」

リクルート 鶴谷氏「AIはHowの探索にものすごく強く、高速にアウトプットを生成できる。一方で確率的に動くので、人の意図を精度高く理解するのは苦手。何をなぜ作るかというWhy・Whatの提示と、アウトプットへの価値判断＝ジャッジは、人間が最後まで担い続けるのではないか」

このセッションから得られる示唆

• AIに任せる境界線は「工程の上流/下流」ではなく「責任とジャッジを誰が持つか」で引くと整理しやすい。
• AIを導入する前に、ソースとルールを集約し「AIレディネス」な環境を整えることが品質の前提になる。
• 開発契約・体制が請負型で分断していると、AI活用の効果が頭打ちになりやすい。自社の体制を点検する価値がある。
• 上流のアーキテクチャ設計と意図提示（Why/What）は、AI時代にむしろ人の重要性が増す領域である。

【テーマ② 個人のAI活用を現場から組織にボトムアップする】

課題・背景

「AI活用が進んでいるのは一部の人だけ」「個人の取り組みが組織に広がらない」──エンタープライズ規模では、アーリーアダプターとレイトマジョリティの差が大きく、なかなか浸透しないという悩みが共通する。現場発の成功事例を、いかに組織標準へ「昇格」させるか。ここで両社のアプローチの違いが鮮明になった。

取り組み内容

リクルートは「純粋なボトムアップ」を組織横断で集約する道を選んだ。
もともとボトムアップ文化が強く、以前から現場ごとに積極的にAI活用に取り組んでいた。だが個別最適ではノウハウが集約せず効率が悪い。
そこで昨年度からエンジニア組織横断のプロジェクトを立ち上げた。現場発が前提のため抵抗感はほぼなく、「横断でやってくれてありがとう」という反応から一気に進んだという。

鶴谷氏は組織横断で4つの取り組みを展開している。

(1) LLM・プロンプトエンジニアリングの基礎研修を内製の専門人材が作成・公開

(2) AWS・Googleクラウドのアカウントを払い出し「試して壊して学ぶ」サンドボックス環境の整備

(3) AIコーディングツールの検証とノウハウ共有のLT会による集合知化

(4) 室横断でのAIエージェントによる運用自動化の実践（アラート発報→ランブック参照→原因調査→対応提示を行う調査エージェントなど。精度確認とランブック更新でヒューマンインザループを設計）

研修・学習・実践・知見共有を通じて、設計・実装・運用までできるエンジニアリング力の獲得を狙う。

KDDIは、トップのメッセージと現場の草の根を「ミドルアップダウン」でつなぐ。
「AI前提社会を考える」はトップからのメッセージであり、ソフトウェア開発でもAI活用が当たり前という空気が先にあった。同時に、公共事業的なサービスが多く品質も強く問われる。
鎌田氏は興味のあるテーマごとに「ギルド」と呼ぶコミュニティを多数立ち上げ、AIを使うギルドにメンバーが集まり、サンドボックス環境でツールを無制限に試せるようにした。
GUI・CLIを問わず使い込むうち、現場から「これがいい」という声が上がり、昨年10月頃にはClaude Codeへ収斂したという。

そして横展開の決め手として、成果を経営ボードに定量的に提示することを挙げた。
現場が楽しく成果を出しても、定量的に示さなければ他部門へはスケールしない。トップへの報告、現場の草の根、その間を中間層が往復させる「ミドルアップダウン」を繰り返してスケールさせる、というのがKDDIの方法論だ。

成果・学び

両社が口を揃えたのが、上層部・組織の長が率先してAIを使うことの効果だ。

鶴谷氏は「上長や上の人ががっつり使うと、理解が深まって共通認識が揃い、加速する」と語る。
リクルートでは、現場が「AI使いたい」と動く土壌の上に組織横断の仕組みが乗ったことで浸透が速かった。

一方で両社とも、個人・組織のAI活用成熟度の格差を率直に課題だと話した。
鶴谷氏は「AIをめっちゃ使いたい派と、まだ求める精度が出ない派がいる。その隔たりが、この冬ぐらいから埋まりつつある」と現状を共有。
KDDIの鎌田氏は、成熟度格差への一つの解として「個人で開発しないようにする」と述べ、3人程度のモブを複数つなげてマイクロサービスを作る体制を取る。気づいたことはすぐ発信し、AI駆動開発の振り返りを毎日行う。属人化を避けつつ、現場の学びを高速に共有する仕組みだ。

印象的なコメント

リクルート 鶴谷氏「もう上が恥をかいてもいいんですよ。室長たちと一緒に、みんなの見えるところでやる。一人がやればみんな恥ずかしくなくなる。組織や上の人がやると、みんな一気に安心する」

KDDI 鎌田氏「現場のちょっとした成功体験をいっぱい増やすことが大切。トップも『やれ』と言う。でもどこかで成果を経営ボードに定量的に出さないと、横には広がらない。だから私たちはミドルアップダウンと呼んでいます」

このセッションから得られる示唆

• ボトムアップを組織標準へ昇格させる鍵は二つ。上層部の率先利用による「安心」の醸成と、経営への定量的な成果提示である。
• 自社文化がボトムアップ型かトップダウン型かで打ち手は変わる。リクルート型（現場発を横断集約）とKDDI型（草の根とトップを中間層がつなぐ）を自社に当てはめて選ぶとよい。
• 成熟度格差は前提として織り込む。LT会・ギルド等の「場」と、属人化を避けるモブ体制が底上げに効く。
• ツールの乱立はノウハウのサイロ化を招く。試行を経て共通ツールへ収斂させる流れが、組織での会話と集合知化を促す。

【テーマ③ AI時代のエンジニアの価値とKPI設計】

課題・背景

AIがHowを担う時代に、人が担い続けるべき価値は何か。そして、その価値や成果をどう測るのか。
タスク消化量やコード量といった従来の評価軸が機能しなくなりつつある中で、両社は評価指標の設計に挑んでいる。

取り組み内容

人が担うべき価値について、両社の答えは重なった。
鎌田氏は「ビジネスデザイン、システムデザイン、運用設計」を挙げる。商習慣やビジネスの勘所、何を大切にし何を障害と見なすかという力点は、AIに聞いても一般論しか返ってこない。
プロダクトのディテールを握るのは人間のデザインであり、エンジニアがビジネスを知るほど良いプロダクトができる、という。

鶴谷氏は、AIが得意なHowに対し、人が担うのは「Why・What（意図の提示）」と「ジャッジ（価値判断）」だと整理した。AIは確率的に動くため意図の精度の高い理解が苦手で、アウトプットは何度もジャッジを繰り返さなければ良くならない。
この二つは人間が最後まで担い続けるのではないか、という仮説だ。これは冒頭で鎌田氏が示した「プロンプトエンジニアリングではなくコンテキストエンジニアリング」という考え方とも通底する。

KPI/KGIの設計では、両社のアプローチが分岐した。
KDDIの鎌田氏は、まずコスト圧縮幅というシンプルな指標から入り、システム単位での「AI駆動開発率」（例：フロント系SOEは100%、基幹系SORは10〜20%）を置く。
加えて、ハーネス設計やプロダクトマネジメントまで担えるかという「AIエンジニアリングのレベル」を人材指標とし、今後は「障害率」の導入を検討中だ。
これはFour Keysのような「切り戻し」ではなく、実際のビジネス障害の発生率を測り、人が開発するのと同等以上の品質を証明する狙いがある。

リクルートの鶴谷氏は、昨年からFour Keysなどを試した結果「組織ごとに事情が異なり、共通の指標は難しい」と判断。重視するのはROIだと語る。
Claude等のエンプラ利用コストは月額数百ドル（日本円で数万円規模）に過ぎず、それに対しリードタイム短縮やコスト削減でどれだけリターンを生むかを測る。
そしてボトムアップ企業らしく、指標は上から押し付けず「考え方を渡して現場でROIを考えてもらう」形にしている。

成果・学び

両社が示したエンジニアの将来像は力強い。
鎌田氏は、作るものに責任を持ち最小コストで素早く作れる「圧倒的な生産性」をベースに、AI駆動開発を競争力の源泉とし、FDE的により前のめりに顧客のビジネスへ入り込む姿を描いた。「エンジニアがリーダーとなってビジネスを立ち上げられたら、それがスケールの源泉になる」。
鶴谷氏も、要求仕様からリリースまでをいかにスピーディに回し、何度も顧客に当てて価値を磨くかが最も大事だとし、「やらないと淘汰されるという切迫感がある」と続けた。

印象的なコメント

KDDI 鎌田氏「作るものに責任を持ち、最小コストで素早く作れる。これがエンジニアの価値のベース。最終的にはエンジニアがビジネスの最前線で活躍する。エンジニアが一番輝く、そういう世界が持てるといい」

リクルート 鶴谷氏「リリースサイクルを速め、何度も顧客に当てて価値を感じるものを出す。それが一番大事だし、逆説的に、やらなければ淘汰される。だから頑張る必要がある」

このセッションから得られる示唆

• AIに代替されない価値は「ビジネスの勘所」と「Why・What・ジャッジ」に集約される。評価制度はここを軸に再設計する。
• KPIは借り物では機能しにくい。KDDIの「AI駆動開発率・障害率」、リクルートの「現場が算定するROI」のように、自社の事情から組み立てる。
• 品質指標は「切り戻し」ではなく「ビジネス障害率」のように、AIの成果が人と同等以上であることを示せる形が望ましい。
• リリースサイクルの速さそのものが競争力になる。失敗コストが下がる前提で「試して壊して作り直す」サイクルを設計に組み込む。

【Q&A セッション】

主な論点と各社の考え方

Q.AI駆動開発時代に高評価される人材は？
A.鎌田氏は「現場からの人気」と「経営からの人気」を分けて説明した。
現場で評価されるのは、量を測ってもわかるほどAIを使い込む人。単に大量のコンテキストを投げているのではなく、たくさん失敗し、いろいろ試しているからこそ多くを知っており、それをうまく発信する人がさらに評価される。
一方、経営から評価されるのは「効果を定量的に伝えられる人」。「経営からは『早く効果を出せ』と言われるので」と本音も覗かせた。

Q.自発的に情報共有する風土の作り方は？
A.両社とも「上がやる」で一致した。鶴谷氏は「上が恥をかいてもいい。一人がやればみんな恥ずかしくなくなる」とし、自らTechカンファレンスで見たエージェントのデモを真似してLT会で披露する例を挙げた。
鎌田氏は加えて「『資料を作るのが面倒』という声には、Claudeで自動的にスライドを生成するような、話しやすい状態を作るツール面の支援も有効」と補足した。

Q.AI時代のエンジニアが身につけるべきスキルは？
A.鎌田氏は「コテコテのソフトウェア工学の基礎が今こそ最も大切」と断言。要件定義の仕方、なぜそう考えるか、構造的にどう設計するか──こうした基礎がないと、AIの出力を「信じるしかなくなる」。自分の骨格を描けず、良し悪しを問答できなくなるという危機感だ。
鶴谷氏も「最後にジャッジする力は今までと変わらない。手を動かした経験があるからジャッジでき、AIにフィードバックできる」と応じた。

共通して見えたこと

AIがHowを引き受けるほど、人に残るのは泥臭い基礎力とジャッジである、という点で両社の見解は完全に一致した。
「今や全員がエンジニアリングマネージャー、つまりAIをマネジメントする立場になった」と総括した。

【イベント全体のまとめ】

共通課題

両社が向き合っていたのは、本イベントが掲げた三つの共通課題そのものだった。
すなわち、AI活用が一部に留まり組織全体へ広がらないこと、AIに任せる範囲の基準が定まらないこと、そしてエンジニアの役割・評価基準の方針を打ち出せないことである。

各社のアプローチの違い

立場は似ていても、組織文化を起点に方法論が枝分かれしている点が示唆深い。自社がどちらの文化に近いかを見極めることが、打ち手選択の出発点になる。

成功要因

(1) 全工程でAIを使いつつ「責任とジャッジは人」という原則を揺るがせないこと
(2) 上層部が率先して使い「安心」と共通認識を作ること
(3) 成功体験を場（LT会・ギルド）で共有し集合知化すること
(4) 成果を定量的に可視化し経営と現場の双方を動かすこと
(5) 試行を経て共通ツールへ収斂させること

今後重要になるテーマ

今後の焦点は、個人・組織の成熟度格差の「底上げ」と、組織の壁を越えた「ワンチーム化」だ。
失敗コストが下がる時代には、要求仕様からリリースまでを一気通貫で高速に回す体制が競争力を決める。
そのためのKPI設計と、AIに代替されない人材の育成・評価が、各社の次の論点になる。

【記事の要点】

1. 両社はともに全工程でAIを活用するが、「最終的なアウトプットの責任とジャッジは人が持つ」という原則を共有している。
2. AIに任せる境界線は工程の上流/下流ではなく、「誰が責任とジャッジを持つか」で引くと整理しやすい。
3. KDDIは請負（分断）型より一貫体制のほうが生産性も品質も伸びると実証。AI導入前の環境整備（SSOT）が品質の前提となる。
4. ボトムアップを組織標準へ昇格させる鍵は、上層部の率先利用と、経営への定量的な成果提示の二つである。
5. 組織文化で打ち手は分かれる。リクルートは現場発を横断集約、KDDIは草の根とトップを中間層がつなぐ「ミドルアップダウン」。
6. ツール乱立はノウハウのサイロ化を招く。試行を経てClaude Codeなど共通ツールへ収斂させる流れが集合知化を促す。
7. KPIは借り物では機能しにくい。KDDIは「AI駆動開発率・障害率」、リクルートは「現場が算定するROI」と自社事情から設計している。
8. AIに代替されない価値は「ビジネスの勘所」と「Why・What・ジャッジ」、そして「コテコテのソフトウェア工学の基礎」に集約される。
9. 個人・組織の成熟度格差は前提として織り込み、場（LT会・ギルド）とモブ体制、共通の仕組みで底上げする。
10. 失敗コストが下がる時代には、要求仕様からリリースまでを高速に回すワンチーム体制と、ビジネス最前線に立つエンジニア像が競争力を決める。

最後に

AI活用に唯一の正解はない。
だが両社の実践は、最適解を見出すための「型」を確かに示している。
自社の体制がAI活用を分断していないかを点検し、責任とジャッジを起点に役割を再定義し、自社文化に合った展開方法と評価指標を組み立てる。
そしてエンジニア自身が、コテコテの基礎力とビジネスの勘所を武器にビジネスの最前線へ踏み出す──その一歩が、自社なりの最適解への道筋となる。