生成AIの普及によって、ソフトウェア開発のアウトプット量は飛躍的に増えました。
ファインディ株式会社の調査では、73.1%のエンジニアが業務でコーディングエージェントを利用し、5割弱が自身のコードの半分以上をAIで生成しています。AIを「入れる」フェーズは、すでに終わりつつあります。

それにもかかわらず、多くの組織で「スクラムは回っているのに、事業成果につながっている実感がない」という声が消えません。プロセスは整い、開発は速くなった。
しかし何を作るべきかという判断の精度は上がらず、現場で得た学びは個人に閉じたまま組織に残らない。ボトルネックは、実装そのものではなく、その前後にあるのではないか――。

本イベントでは、79社のアジャイル開発を支援してきた株式会社 日立製作所の向坂太郎氏が、大企業ならではの「ビジネス・組織・IT」3つの構造的な壁とその越え方を語りました。
続くファインディ株式会社の鍛治東亜は、「アジャイルを測る」のではなく「意思決定と学習を測る」という視点から、判断力・実行力・学習力の3層で組織を捉える新しいアセスメントモデルを提示しました。

本レポートでは、単なるセッション要約ではなく「開発組織の課題解決ストーリー」として、両社の視点の違いが見える形で整理してお届けします。

イベント概要

• イベント名：アジャイルは回っているのに、なぜ価値創出が進まないのか？ — 日立×Findyが語るAI時代における “意思決定×開発×学習” の再設計 —
• 主催：ファインディ株式会社（Findy Team+）
• 形式：オフライン／オンラインのハイブリッド開催
• 開催日：2026年7月3日（金）
• イベントページ：https://jp.findy-team.io/events/hitachi_findy_260703/
• 登壇者
  • 向坂 太郎 氏
    • 株式会社 日立製作所／アプリケーションサービス事業部 アプリケーション・モダナイゼーション本部 APモダナイゼーション推進第一部 主任技師
  • 鍛治 東亜
    • ファインディ株式会社／Findy Team+事業部 事業企画）

セッションは「①株式会社 日立製作所による大企業アジャイル推進のリアル」→「②Findy Team+による新しいアセスメントモデルの提唱」の順に進行し、各セッション後には参加者からの質問に登壇者が答えるQ&Aの時間が設けられました。
会場・オンラインを合わせて多数の質問が寄せられ、現場の切実な課題が浮き彫りになった時間でもあります。

セッション①｜日立製作所：79社の支援で見えた、大企業アジャイルを阻む3つの壁

課題・背景

向坂氏は1999年に日立製作所へ入社し、金融系システム開発を経て、社内の開発フレームワークや開発標準の整備といったソフトウェア生産技術の開発・展開に従事してきました。その知見を生かして2019年にアジャイル開発コンサルティングサービスを立ち上げ、今年で7年目。昨年度までに79社の支援実績があります。

冒頭、向坂氏は丁寧に前置きを置きました。

「企業さんは規模も違いますし、文化も違いますし、抱えている課題も違います。ですので『大企業だったらみんなこう』という話をしたいわけではありません。私たちが見てきた企業さんの中で、ありがちな課題を3つほどピックアップしてお話しします」（向坂氏）

支援現場から抽出された「あるある」は、

• ビジネスの問題
• 組織の問題
• ITの問題

という3つのレイヤーに整理されると提言します。

取り組み内容

壁①（ビジネス）：ハンドルのない車を走らせていないか

最初のスライドに映し出されたのは、高性能なエンジンとタフなボディ、心地よい内装を備えた1台の車。しかし、ハンドルがありません。

「どんなに性能がいい車でも、運転ができないとただの置物になってしまいます。維持費ばかりかかって、あまり嬉しくない状況ですよね」（向坂氏）

経営者から見れば、ハイパフォーマンスな人材やチームが「いる」こと自体が目的ではありません。株主に対して成長を示す必要がある以上、欲しいのは人材そのものではなく、その人材が生み出す成果です。アジャイル開発が「できます」と言えても、それが本当に事業の成長につながっているのかを問い直す必要がある、というのが向坂氏の指摘です。

本来、そのハンドルを握るのはスクラムにおけるプロダクトオーナーです。
ビジネス戦略を練り、KPIを設定し、マイルストーンごとに目標値を定め、予算を確保する。
そして目標達成のための仮説をプロダクトバックログに積み、開発して市場投入し、結果を評価して次の仮説につなげる。
このループが回って初めて、アジャイル開発はビジネスの武器になります。

ところが一定規模以上の企業では、このハンドルを握る人がチーム内にいないという状況が頻発します。

「プロダクトオーナーとしてチームの中に入っている人は、現場の判断をする権限は与えられているものの、ビジネスの決裁権は与えられていない。
決裁権を持っているのは、チームの外にいるマネジメントの方だという状況ですね」（向坂氏）

外にいるマネジメントがアジャイルを深く理解していない場合、ウォーターフォール型の計画が持ち込まれます。
結果として、ハンドルを切るタイミングが年に一度程度になり、ビジネスのアジリティそのものが落ちてしまうのです。

この状況に気づいた企業は、おおむね3通りのアプローチで解決を試みているといいます。

• ① 外にいるハンドルをチームの中に入れる
  • 当事者意識を持ってもらい、マインドチェンジを促す。ただし具体的な手法は各社の競争力に関わるため非公開
• ② 出島を作って権限を移譲する
  • アジャイルをビジネスとして回すには最も理想的な形。ただし組織そのものを動かすため負荷は大きい
• ③ 開発チームから報告を上げ、マネジメントを味方につける
  • 組織もプロジェクトの仕組みも変えずにコストをかけずに実行できる。開発の進捗だけでなくビジネスの進捗もログから自分たちで用意して報告し、裁量を自分たちの側に引き寄せる

「できるだけハンドルのない車ではなく、ちゃんとハンドルのある車で運転できるように、各社が試行錯誤をしているというのが今の状況ではないかと思います」（向坂氏）

壁②（組織）：縦割りのオーバーヘッドは「善意の防御行動」から生まれる

2つ目は、組織への責任感が強いステークホルダーが引き起こす問題です。

新しいサービスを立ち上げるとき、そのサービスは社内事務にも既存の関連システムにも影響を及ぼします
そして大きな企業では、事務を担う部署も関連システムを所管する部署も、たいてい別組織です。

セオリー通りであれば、インセプションデッキなどでステークホルダーを事前に特定し、協力を得られる状態にしてからプロジェクトを進めます。
しかし組織が分かれていれば、予算もミッションも別々です。

「新しいサービスを立ち上げるので、過渡期の間だけ元の事務はそのままに、新しい事務も少し担ってくれないかと相談するとします。
事務方は自分たちの人員でそれをやろうとすると、おそらく人が足りない。足りない中でやれば負荷がかかりすぎてミスも起こりやすい。とてもじゃないけれど、その要求を飲むわけにはいかない。つまり防御行動に入るわけですよね」（向坂氏）

ここで重要なのは、これが怠慢ではなく、自組織への責任感から生まれる合理的な行動だという点です。だからこそ説得と交渉に時間がかかり、走り出しが遅れます。
向坂氏はこれを「縦割り構造によるオーバーヘッド」と表現しました。

解決の方向は、組織と組織の間で起きる摩擦を、その上位でコントロールすることです。
向坂氏が挙げた事例では、経営者が定例的に課題を持つ担当者と対話する場を設け、その会議体に財務のトップも同席していました。課題が挙がって予算手当が必要と判断されれば、その場で予算がつきます。

「人がいないから無理と言っていたところに予算手当がされると、人を拡充できるのでできますよという形になる。うまくステークホルダー間の調整ができるようになります」（向坂氏）

壁③（IT）：アーキテクチャが、アジャイルとAIの両方の足を引っ張る

3つ目は、肥大化して複雑に絡み合った機能群です。
どこかを直すと、それがどこに影響するかわからない。
こうしたシステムでアジャイル開発をやろうとしても、向坂氏は「おそらく無理です」と言い切ります。

アジャイル開発は、同じリソースを何度も修正しながら進めます。
修正のたびに影響範囲を調査していては、開発に集中できません。

理想は、独立した機能に分割して影響範囲を絞り込める状態です。とはいえ、モノリシックなシステムを一足飛びに分割できるプロジェクトは存在しません。現実的な移行は、アジャイルで回すと利益が得られそうな部分だけを切り離して開発し、その範囲を少しずつ広げていくアプローチになります。

ここで向坂氏は、想定される反論に自ら踏み込みました。
「面倒なことをやらなくても、AIで開発すれば一発では」という声への回答です。

「AIを使った開発は、インプットが大きくなってくると弊害が出てきます。どこを直すとどこに波及するのかよくわからない、どでかいシステムをインプットとしてAIに食わせたらどうなるか。
トークンが爆発します。超お金がかかります。処理時間もかかります。そして一番問題なのは、物忘れが激しくなります」（向坂氏）

出力される結果は当てにならなくなる。だから実際のプロジェクトでは、インプットが大きくなったら要約・集約して減らしたうえでソースコード生成に走る、という運用をしているといいます。

「インプットを増やさないようにすることは、生成AIを使ううえでかなり重要なファクターだと思っています」（向坂氏）

さらに、生成AIが書いたコードを生成AIにテストさせてそのまま本番投入できるかといえば、現時点ではそうではありません。
必ず人が確認して問題ないことを確かめてリリースする必要があります。そして、どこを直すとどこに影響が出るかわからないシステムでは、その人による確認すら成立しないのです。

つまり機能分割は、アジャイルのためだけの施策ではなく、AI活用の前提条件でもある。ここが本セッション最大の示唆でした。

成果・学び

3つの壁を並べたうえで、向坂氏は「これはアジャイル開発を推進する上での課題であると同時に、企業の変革を阻む要因でもあります」とスコープを引き上げました。

業務・IT・組織を別々に対策するのは極めて難しい。まとめて考えてグランドデザインを描き、一気に実装するのではなくマイルストーンを置いて順に対策していく。
グランドデザインとロードマップを引いたうえで、個別課題に対処していく。それが遠回りに見えて最短だという結論です。

「分かってはいるけれど、対策は結構難しい領域なんですよね」（向坂氏）

79社を見てきた立場からの、実感のこもった一言でした。

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

• 決裁権の所在が、組織のアジリティの上限を決める。
  • プロセスをいくら磨いても、ハンドルがチームの外にあれば変化には追随できません。まず「誰が、どの頻度でハンドルを切っているか」を可視化することが起点になります。
• 縦割りの抵抗は、悪意ではなく責任感から生まれる。
  • 相手を「わかっていない人」と捉える限り交渉は長期化します。相手のミッションと予算制約を前提に置いた設計が必要です。
• 組織間の摩擦は、上位の職位でしか解けないことがある。
  • 経営と財務が同席し、その場で予算判断ができる会議体は、強力な摩擦解消装置になります。
• モジュール化は、AI活用の前提条件でもある。
  • 影響範囲が絞れないシステムでは、トークンが膨らみ、AIの精度が落ち、人による最終確認も成立しません。
• 変革は「業務・IT・組織」のグランドデザインから。
  • 個別最適の改善を積み上げても、3つのレイヤーが噛み合っていなければ成果には到達しません。

Q&Aから：現場のリアルな問いに答える

Q. 大企業でボトムアップで動こうとすると苦戦します。偉い人の巻き込みパターンを知りたいです。

向坂氏は2つの方向を示しました。トップレベルを動かしたいなら、トップに直接インプットすること。「我が社もこれをやらないとまずいのでは」という危機感が生まれれば、そこから下のマネジメントに指導が降りていきます。中間マネジメント層については、先述の「外にいるハンドルを中に入れる」パターンが有効です。

「プロジェクトの仕組みとして『入って来い』ということをやっていたりするんですよね。仕組みで逃げられないようにするというのも一つの手かなと思いました」（向坂氏）

Q. 開発側のアジャイルシフトは進んでいますが、企画・ビジネス側が進んでいません。こだわりやバイアスのために仮説の修正ができていない状況です。

「マインドチェンジは難しいので、僕も答えを持っていません。ただ、うまくいきやすくするために、企画のときの負荷を下げてあげるというのは一つの手になると思います」（向坂氏）

何十ページもの企画書を書いたあとに「世の中の動向はそれじゃない」と言われれば、「これだけ作ったんだから」というマインドが働きます。
ならばエグゼクティブサマリーだけを保守する、リーンキャンバス1枚で企画を軽く済ませる。
そうすれば「方向性が違う」と言われたときに、直してもいいかと思える心理が働きます。マインドではなく仕組みの側から攻める、という発想です。

Q. システムが複雑でアジャイル開発ができていません。AIを使ってもバグが頻出します。影響範囲を絞り込みたいのですが、開発リソースが逼迫していて確保できません。

「何かしら価値が出るとお金がつくという話になると思います。たとえば複雑なシステムから、ユーザーの取り込みをもっとやっていこうとか、ヘルプデスクに入ってきた要求に早く答えられるようにしようといったテーマをつけて機能の切り出しをして、そこでアジャイル開発をしていくのが現実ラインではないかと思います」（向坂氏）

Q. ステークホルダーの説得を、トップダウンではない方法で実施している実例はありますか。

「こちらの方が多いです」と即答したうえで、向坂氏が挙げたのは相手方のキーマンを抱き込むという方法でした。
担当者にいくら交渉しても「うちは無理です」で終わってしまうところを、キーマンを捕まえて話を進める。そして常に今の状況を共有し、味方でい続けてもらうよう振る舞う。
キーマンの見つけ方については「同じ会社の中なら『この人だ』となんとなく分かりますし、その部署の中で『キーマンは誰？』と聞くこともできます」と現実的なアドバイスが返りました。

Q. モノリシックな機能を分割するとき、抽象的な責任のオブジェクトから考えるのか、物理的な実装から考えるのか。

「あまりかっこいいことは言えないんですけれど、基本的に機能を分割するときは、データモデルで分割できるようにしないと後で苦労します。
トランザクションテーブルに相当するものは分割したい機能の中に入れて、そこを単独で回収できるように分割するのが基本です。
あとはインターフェースを介して隣の機能のデータを自分たちのデータベースに持ってくる。直接隣のデータベースを覗かないというのが基本になります」（向坂氏）

Q. 一度導入されたアジャイルが組織に定着するためのポイントやキーパーソンは。

うまくいっていないのであれば、外部の力を借りるのが一番早い、というのが向坂氏の答えでした。「外から連れてきた人のほうが、内部よりも言うことは聞くと思います」という指摘は、身も蓋もないようでいて多くの現場に思い当たる節があるはずです。

Q. 最終的に支援者がいなくても回る状態を目指すための教育メニューは。1プロジェクトにどの程度のリソースを貼るのでしょうか。

自走状態に持っていくには、最低限コーチがついたほうがよいという前提のもと、実案件がなくてもアジャイル開発ができるメンバーを事前に揃えたいという要望には、1ヶ月〜1ヶ月半かけてスクラムを疑似的に回すシミュレーション教育を用意しているとのこと。
体制に入ってスクラムマスターを務める場合は1人月フルで貼りつき、コーチの場合はイベントのある日だけスポットで参画するなど、予算に応じた形が取れると説明されました。

Q. 日立製作所が入られた案件で、相対的にうまくいかなかった例があれば教えてください。

「入ったプロジェクトで、自分たちでアジャイル開発を回したことのある経験者がキーマンとして動いているときに、動きにくいなということはありました。
ヘッドが2つあるような状態は少しやりにくかったですね」（向坂氏）

さらに「絶対に無理だとお断りすることもある」という話も。それは何かという司会の問いに、向坂氏はこう答えました。

「『日立製作所でプロダクトオーナーをやってください』ですね。
お客様のビジネスを私たちが担うわけにはいかないというところがあるので、そこはお断りさせていただいたことがあります」（向坂氏）

セッション②｜ファインディ：アジャイルを測るのではなく、意思決定と学習を測る

課題・背景

「今日皆さんに持ち帰っていただきたいのは、シンプルに『アジャイルを測る』のではなく『意思決定と学習を測る』というところです。
自分たちはアジャイルできているのか、という観点ではなく、自分たちはちゃんと正しいものを決めて、正しく学んで、そのサイクルを回せているのか。この問いの転換がテーマになります」（鍛治）

続いて登壇したのは、ファインディ株式会社でFindy Team+事業部の事業企画を務める鍛治東亜です。
現在はAI時代の開発組織をどう評価すべきかという新しいアセスメントモデルの検証・実装に従事しています。

このセッションの背骨になるのが、判断力・実行力・学習力という3つの軸です。

• 判断力
  • 何を作るべきかを精度高く決められるか
• 実行力
  • 決めたものを速く・安全に作れるか
• 学習力
  • 作った結果から学び、次の判断に活かせるか

プロダクトの価値は、この3軸のループから生まれます。ループの回数と精度が、そのまま価値創出の総量になる。
逆にいえば、どれか一つだけが強くても意味がありません。

「実行力だけめちゃくちゃ強くても、判断が雑だったら間違ったものを作ってしまう。
この3観点をちゃんと担保しながらやる、というイメージです」（鍛治）

取り組み内容

「速くなった実感」の裏で起きている現実

AI活用は、すでに一部の先進企業だけの取り組みではなくなっています。
ファインディの調査では73.1%のエンジニアが業務でコーディングエージェントを使用し、5割弱が自身のコードの半分以上をAIで生成しています。
ファインディ自身の開発組織でも、AI未活用の時代から、AIを使いながら試行錯誤した時期を経て、ハーネスが整った現在まで、アウトプット量は段階的に伸びてきました。

しかし鍛治は、ここに2つの評価の穴が生まれていると指摘します。

穴①：実行力において「量」だけでは評価にならない

複数のレポートが同じ方向を示しています。

「量・スピードだけを見る指標は、AI時代にはむしろリスクを隠してしまう」）

穴②：判断力・学習力は、そもそも測る指標が存在しない

実行力にはDORAメトリクスやベロシティといった指標があります。
しかし判断力と学習力には、それがありません。

「根本的なところでいくと、やっぱりこういう判断とか学習のログがないので、計測自体が難しいという、このログの問題もあるかなと思っています」（鍛治）

これを裏づけるデータとして示されたのが、従業員1,000名以上の企業のリーダー職以上のソフトウェアエンジニア603名を対象にした調査結果です。「AIに過去の意思決定の背景を渡せているか」という問いに対し、55.1%が「渡せていない」と回答しました。

本来であれば、これまでの判断の経緯を踏まえてAIに渡し、良質なアウトプットを引き出すべきところ。
その本来やるべきことが、半数以上の現場でできていない。
学びは個人に閉じ、効果的ではない作業を繰り返す構造が、組織から時間を奪っている――という指摘です。

なお会場では「あなたの組織は意思決定や学習を蓄積できていますか」という5段階のリアルタイム投票も行われ、大半が3未満に集中しました。

「正直に答えていただいてすごく嬉しい限りです。胸を張ってやれているというところは、そこまでいらっしゃらないのかなという感じです」（鍛治）

開発組織を「開発資本」として捉える

こうした課題に対してファインディが提唱しているのが、判断力・実行力・学習力の3つを含めて開発組織を「開発資本」として捉える視点です。

開発資本 = 企業がソフトウェアを通じて価値を生み続けるために、組織へ蓄積された能力・知識・基盤

「ポイントはこの『資本』という言葉です。
これはちゃんと蓄積されて複利で効いてくるという概念を、開発組織として見るという視点に変えているところです」（鍛治）

開発資本は、Speed / Quality / Control の3つの大区分と、その下の9つの観点で構成されます。

• Speed：速く作って、出して、学べるか。作る速さだけでなく学ぶ速さまで含めているのがポイント
• Quality：コンスタントに価値を届けられているか。手戻りの少なさ、本番品質、保守性
• Control：変更を予測して制御できるか。構造・プロセス・複雑性の制御

従来はSpeedの中でも特に「作る」にフォーカスが当たっていました。
そこに「届ける・学ぶ」までを含めたスピードの進化、品質の観点、そしてAI時代ならではの制御の観点が加わっています。

指標が存在しなかった判断力・学習力は、たとえば次のようなメトリクスで計測を試みています。

まだ検証段階であることを繰り返し明示する姿勢が、かえって議論の誠実さを担保していました。

判断力を支える：Findy Insights と NTTドコモの事例

では、開発資本をどう高めるのか。
ファインディは「開発資本プラットフォーム」として、ディスカバリーから実装・運用までを支えるソリューション群を提供しています。

判断力の側面を支えるのが「Findy Insights」です。
商談、問い合わせ、アンケート、インタビュー、社内会議といった顧客の声をデータソースとして取り込み、AIが仮説検証・評価につながる形でナレッジ資産化・インサイト分析を行います。
中でもインサイトマネジメント機能は、散在する顧客フィードバックをAIが自動で構造化・優先度付けし、意思決定の共通の土台をつくるものです。

活用事例として紹介されたのがNTTドコモです。
数名体制のPoC開発において、現場から届くフィードバックの粒度がバラバラで、その整理と優先順位付けに多大なリソースを奪われていました。
Slackやスプレッドシートでの管理では、後からまとめて書いてもらう運用となり、抜け漏れや粒度のばらつきが発生。
さらに、開発者の経験や思い込みによるバイアスがかかり、ユーザーの本来のニーズからズレるリスクもありました。

導入後は、多様な粒度のフィードバックをAIが自動でグルーピング・集計し、企画側が優先度をつけやすい状態に。
AIによる中立的な整理結果が社内議論における共通の判断材料として機能し、意思決定の納得感が向上しました。
1人で全フィードバックをさばく負荷から解放され、本来注力すべき開発・検証業務へリソースをシフトできたといいます。

学習力を支える：Findy Context とADRの自動生成

そしてこのセッションで鍛治が「最後に一番お伝えしたい」と語ったのが、学習力を支える「Findy Context」です。

議事録やSlack・GitHubなどに散在する一次情報を、AIが「判断コンテキスト」として構造化します。
単にインポートするのではなく、対象顧客・顧客のペイン・制約事項・決定した案・検討した代替案・関連コンテキスト・裏付けデータといった構造に落とし込むのがポイントです。
冒頭で示された「55.1%がAIに文脈を渡せていない」という課題に、正面から向き合うソリューションといえます。

具体的な機能として紹介されたのがADR（Architecture Decision Record）の自動生成でした。
Slack上の議論からは「この施策はどういうもので、なぜこれをしたのか。
どういう選択肢があったが、こういう理由でこう意思決定した」というログが残ります。
GitHubのPR上の議論からも同様にADRが自動生成されます。意思決定の背景を、書く手間をかけずに組織へ残す仕組みです。

成果として示されたのは、AIエージェントに開発をさせた際の比較検証でした。
各ツールから生データをそのまま引っ張ってAIに使わせた場合と、コンテキストを一度挟んでADRとして構造化した場合を比べると、次の違いが出たといいます。

• トークン量が減り、コストが減少
• AIが返す回答のスコア（品質）が大幅に向上
• そもそもの議論が短縮され、人のリソース時間が削減

日立製作所の向坂氏が「インプットを増やさないことが生成AIを使ううえで重要なファクター」と語った内容と、まったく同じ結論に、まったく異なるアプローチから到達している点は注目に値します。

成果・学び

鍛治はセッションを3点にまとめました。

1. 課題
   • AIで「作る」は速くなった。しかし手戻りの増加と、「決める・学ぶ」が組織に残らない構造が、価値創出のボトルネックになっている
2. 提言
   • 実行力だけでなく、判断力・学習力を含めた組織の力を「開発資本」として蓄積し、測る
3. 今日からできること
   • まずは自組織の意思決定と学びが「どこに・どんな形で」残っているかを棚卸しする

「そういう力をつけていく観点でいくと、まずは自分たちの組織の判断や学習がどこにどんな形で残っているのかを棚卸ししていくところからがスタートなのかなと思っています」（鍛治）

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

• 「速くなった」は、もはや成果の証明にならない。
  • PR数が14%増えてもリワークが2.6倍なら、正味のアウトプットは変わりません。速度指標は必ず品質指標とセットで見る必要があります。
• AIは増幅器である。
  • 整っていない組織にAIを入れれば、問題も同じ倍率で増幅されます。導入の前に、何を増幅させたいのかを決めることが先です。
• 測れない最大の理由は「ログがない」こと。
  • 判断力・学習力の指標が存在しないのは測り方の問題ではなく、そもそも意思決定と学習が記録されていないからです。指標の議論の前に、記録の仕組みを作る必要があります。
• コンテキストの構造化は、コストと品質を同時に改善する。
  • 生データをそのまま渡すのではなく、判断の構造に落として渡すことで、トークンコストが下がり回答品質が上がり、議論時間まで短縮されます。
• 「資本」という言葉が示すのは複利。
  • 単発の改善ではなく、蓄積されて効いてくるものとして開発組織を捉え直す視点が、評価のあり方を変えます。

Q&Aから

Q. 指標はハックされそうだと感じています。
本質を理解しないままアセスメントすると、「手戻りは悪」のような間違った使われ方をされそうです。
アジャイルマニフェストの世界観では、開発する人と企画する人の分断を埋めていく営みな気もしています。
そこを見えるようにすることの示唆はありますか？

「これは結構いただく声で、まさに特定の指標のみを見てしまうとハックされてしまう。
なので今回考えている概念が『開発資本』というもので、かなり多角的に見させていただいて、その中でどう高めていくかを考えているところです。
とはいえ、これがどう寄与するのかはまだ検証段階なので、ぜひ皆様もアルファ版をご興味あれば使っていただきつつ、フィードバックをいただけると助かります」（鍛治）

単一指標への集約を避け、多角的な構成にすること自体をハック対策とする設計思想が示されました。
同時に、まだ検証途上であることを率直に認め、参加者にフィードバックを求める姿勢で締めくくられています。

クロストーク・Q&A｜両社の視点が交わった論点

当日は各セッション後にQ&Aが設けられ、そこで浮かび上がった論点を整理すると、両社のアプローチの違いと共通点がくっきりと見えてきます。

論点1：AIに渡す「インプットの大きさ」は誰の問題か

日立製作所の向坂氏はこれをアーキテクチャの問題として捉えます。
モノリシックなシステムをそのままAIに食わせればトークンが爆発し、処理時間が伸び、物忘れが起きる。
だから機能分割によって影響範囲を絞り込むことが、AI活用の前提条件になる、と。

一方ファインディ株式会社の鍛治は、これをコンテキスト設計の問題として捉えます。
生データをそのまま渡すのではなく、判断の構造に落とし込んでから渡す。
ADRとして構造化することで、トークンコストが下がり、回答品質が上がる。

アプローチは違いますが、結論は同じです。
AIに渡すものは、絞り込み、構造化しなければならない。コードのアーキテクチャと、意思決定のアーキテクチャ。両方が問われているということです。

論点2：人間はどこに介在すべきか

向坂氏は「今のレベルだと必ず人が確認をして問題ないことを確認してリリースという話に持っていかなくてはいけない」と明言しました。
そして重要なのは、その人による確認が成立するためにも影響範囲の絞り込みが必要だという点です。品質担保の議論は、体制論ではなくアーキテクチャ論に接続されます。

鍛治は、Findy Insightsの事例で「開発者の経験や思い込みによるバイアス」を挙げ、AIによる中立的な整理結果が社内議論の共通の判断材料として機能したと語りました。ここでのAIの役割は、判断を代行することではなく、判断の土台を揃えることです。

論点3：組織を動かすのはトップダウンか、ボトムアップか

この問いには、向坂氏が最も具体的に答えています。トップを動かしたいならトップに直接インプットする。
中間層を動かしたいなら「プロジェクトの仕組みとして入って来い」と、仕組みで逃げられなくする。そしてトップダウンでない方法としては、相手方のキーマンを抱き込み、常に情報を共有して味方でい続けてもらう。
「こちらの方が多いです」という一言が、現場の実態を物語っていました。

ファインディの立場は、これを別の角度から支えるものです。
開発資本スコアという共通の物差しがあれば、「なんとなく良くなった気がする」という感覚論から抜け出し、経営と現場が同じ言語で議論できるようになります。

共通して見えたこと

両社が示したのは、開発プロセスの改善だけでは価値創出には到達しないという認識でした。
決裁権の所在、組織間の予算とミッション、システムのアーキテクチャ、意思決定の記録――アジャイルの外側にある構造こそが、成果を規定している。
この一点で、まったく異なる立場の2社が一致していました。

イベント全体のまとめ

共通課題

「アジャイルは回っているのに価値創出が進まない」という現象の背後には、共通した構造があります。

• 決める力の不在
  • ビジネスの決裁権がチームの外にあり、ハンドルを切る頻度が低い（日立製作所）／判断力を測る指標もログも存在しない（ファインディ）
• 学ぶ力の分散
  • 現場の学びが個人に閉じ、組織に蓄積されない。55.1%がAIに過去の意思決定の背景を渡せていない
• 速さの罠
  • AIによってアウトプット量は増えたが、手戻りと変更失敗率も同時に増えている。量の指標がリスクを隠してしまう
• 構造の負債
  • 影響範囲が読めないアーキテクチャが、アジャイルの反復にもAIの精度にも、人による最終確認にも同時に効いてくる

各社のアプローチの違い

日立が構造を変えるアプローチであるのに対し、ファインディは見えるようにするアプローチだといえます。
そして両者は対立せず、補完関係にあります。構造を変える意思決定をするためには、まず現状が見えている必要があるからです。

成功要因

• 決裁権を持つ人を、意思決定サイクルの内側に取り込む設計をしている
• 相手組織のミッションと予算制約を前提に置いたうえで交渉している
• 影響範囲を絞れる単位に機能を分割し、アジャイルとAIの両方が機能する土台を作っている
• 意思決定と学習を「後から書く」のではなく、業務の流れの中で自動的に残る仕組みにしている
• 単一の指標に頼らず、多角的な構成で組織能力を捉えている

今後重要になるテーマ

判断と学習の記録可能性です。実行力の計測手段はすでに整っています。
次に問われるのは、「なぜこれを作ると決めたのか」「作ってみて何がわかったのか」が組織に残る構造をどう作るか。
それは人間のためであると同時に、自律的に動くAIエージェントのための基盤整備でもあります。

そしてもう一つが、業務・IT・組織を一体で描くグランドデザインです。
どれか一つだけを改善しても、他の二つが足を引っ張る。この3レイヤーを同時に見渡せる視座を持つ人材が、これからの開発組織の要になっていきます。

読者へのメッセージ

このイベントで語られたことの多くは、目新しい技術の話ではありませんでした。
「誰がハンドルを握っているのか」「なぜそう決めたのかを残しているか」「どこを直すとどこに影響するかを説明できるか」――いずれも、良い開発組織が当たり前にやってきたことです。ただ、AI時代においてはそれらの整備状況が、そのまま成果の差として増幅されて表れるようになりました。

だからこそ、明日から着手できることがあります。まずは自組織の意思決定と学びが「どこに・どんな形で」残っているかを棚卸しする。ハンドルを切る頻度を数えてみる。速度指標の隣に、手戻り率を並べてみる。

両社の登壇者がそろって「答えを持っているわけではない」「まだ検証段階」と率直に語ったように、完成形を持っている組織はまだありません。
だからこそ、走りながら整えていくしかないのです。

この記事の要点

1. AI導入は完了フェーズに入り、73.1%のエンジニアがコーディングエージェントを業務利用している。問われるのは「AIがある前提でどう進めるか」に移った。
2. 速さは手に入ったが、スタンフォードの調査ではPR数14%増に対しリワークは2.6倍。量の指標だけを見ると、AI時代はむしろリスクが隠れる。
3. 大企業でアジャイルが成果に届かない最大の要因は、ビジネスの決裁権がチームの外にあること。「ハンドルのない車」状態では、ハンドルを切る頻度が組織のアジリティの上限になる。
4. 解決策は3通り。外のハンドルをチームに入れる／出島を作って権限移譲する／報告でマネジメントを味方につけ裁量を引き寄せる。
5. 縦割りのオーバーヘッドは怠慢ではなく、自組織への責任感から生まれる防御行動。組織の利害を超える職位の力（経営＋財務が同席する会議体など）が解消装置になる。
6. モノリシックなアーキテクチャは、アジャイルの反復だけでなくAI活用の足も引っ張る。インプットが大きいとトークンが爆発し、処理が遅く、AIの「物忘れ」で出力が当てにならなくなる。
7. 機能分割の基本はデータモデル。トランザクションテーブルは分割する機能の中に入れ、隣のデータベースを直接覗かずインターフェース経由で参照する。
8. 判断力・学習力に指標が存在しない根本原因は「ログがない」こと。1,000名以上企業のリーダー職以上603名の調査で、55.1%がAIに過去の意思決定の背景を渡せていない。
9. コンテキストをADRとして構造化してからAIに渡すことで、トークンコスト削減・回答品質向上・議論時間短縮が同時に実現した。まず自組織の意思決定と学びが「どこに・どんな形で」残っているかの棚卸しから始めたい。

次回イベントのご案内

Findy Team+では、AI駆動開発・開発資本・開発組織マネジメントをテーマにしたイベントを継続的に開催しています。
最新の開催情報は下記からご確認ください。

• イベント一覧：https://jp.findy-team.io/events/
• Findy Team+ サービス紹介資料：https://jp.findy-team.io/download/service-document/