はじめに
2025年11月14日に Agile Japan 2025 の2日目に参加しました。
タイムテーブルは以下です。
https://2025.agilejapan.jp/timetable_day2/
発表者ごとに、どんな発表だったのかと、そこで学んだ気付きなどを書きます。
なお、1日目のレポートは以下で投稿済みです。
和田 卓人さん
テーマ：AI時代のソフトウェア開発を考える（2025/11版）
今までのプログラミングは終わる。つまり、プログラミングのかたちが変わる。
世界はバイブコーディングの炎に包まれた。
バイブコーディングは、ソフトウェアエンジニアリングの観点では、製品品質の中の機能適合性のみを実際の動作確認で検証することで、コードレビューを省略し、開発のスループットを最大化している状態。
バイブコーディングによる開発生産性の高まりが原因で、開発規模が大きくなると発生する諸問題が、ごく短期間で発生するようになった。
内部品質への投資の損益分岐点（従来は1ヶ月程度）は、1週間まで短くなった。
(上記の損益分岐点の話の詳細は、こちらの発表資料参照)
目指すべきは AI とソフトウェア エンジニアリングの融合
今後の開発は、15分でウォーターフォールを回すようなイメージ。
AIと伴奏、AIに委託の2種類のやり方を、適材適所で活用することが必要。
AIに委託の活用方法として、いろいろ並行でやらせてみて、いまいちなら使わない、ということもできる。人間に対しては、それはやりにくいが、AI相手なら、それがやりやすい。
自動化から自働化へ
望ましい状態を宣言的に定義し、評価関数（適応度関数）を与えると、エージェントはその状態に収束するよう自律的に働く。
AI は自走するが暴走/迷走もする。ガードレール設計としてのソフトウェアエンジニアリングや技術の3本柱（バージョン管理、テスティング、自動化）の重要性がさらに増している。
テスティング
テスト容易性を高めてくれ、という抽象的な指示では駄目。AIに根拠ある判断基準を与えることが必要。
包括的な構成管理
しばらくはモノレポが有利。開発に関わる全てをリポジトリに入れる。
ドキュメントはプレーンテキストで、コードの近くに置く(同じリポジトリに置く)方がAIを活用してドキュメント作成およびメンテナンスしやすい。そうしないとドキュメントが腐る。最初は、二重管理になってもいいから、コードの近くにドキュメントを格納した方が良い。
MTBF から MTTR へ
確信、把握の度合いを落として開発スループットを上げる選択をしている。
バグゼロのゼロリスク信仰から離れなければならない。
レビュー負荷軽減の工夫
書籍「Tidy First?」の知見を活用する。
高度なAIは組織の鏡みたいなもので、AIから引き出せる性能は、組織の能力にそのまま比例する。
労力は外注できるが、能力は外注できない。
個人と組織が共に能力を上げなければならない。
能力向上のためのAI活用
- アウトプットを出すためだけでなく、能力を上げるためにAIを使う
- 批判的なレビューさせる
- 何度もしつこくAIと議論する
- 新しい言語を学ぶためにAI利用
- あえてのオーガニック・コーディング
- 多くのフィードバックが得られる
- コード差分からドキュメントを生成
- 何回同じことを聞いても即時フィードバックを得られる
- 曖昧な質問から専門用語にたどり着ける
- 研修などの学習に関しては、AIを活用して座学を学べるため、反転学習・アクティブラーニングを活用
コーディングは競争力を失うのだろうか？我々はコーディングをやめるべきなのだろうか？
→ 決定を遅延すれば良い。選択肢を広げれば良い。賭けるのではなく「両にらみ」で行けば良い。不確実な状況下において選択肢を狭めるのは危険でしかない。
所感：
最後の質疑応答のところで、以下の回答があり、そこも凄く学びになりました(質問者さんに感謝)。
ドキュメントはコードの近くに置くとは、同じリポジトリに置くという意味。その方がAIを活用してドキュメント作成およびメンテナンスしやすい。そうしないとドキュメントが腐る。最初は、二重管理になってもいいから、コードの近くにドキュメントを格納した方が良い。
研修などの学習に関しては、AIを禁止するのはナンセンスで、AIを活用して座学を学べるので、それを前提にやり方を変えた方がいい。反転学習・アクティブラーニングを活用することが多い。
また、このセッションで、AIをどう活用して、今後どういう心構えでいけばいいのかの指針をもらったと感じました。
能力を伸ばすことが大事だと感じたので、自分と組織の能力を伸ばすことを頑張ろうと思いました。
天野 勝さん、一條 凌佑さん(永和システムマネジメント)
テーマ：アジャイルコーチングの事例
チームのRebootの話をする。
①ふりかえりのRebootの例
最近リリースしたけど、もやもやがあった。
そのもやもやは、ビジネスと開発の”達成感のズレ”、うまくいったこと・いかなかったことの整理ができてない、技術的負債の積み上がり。
そこでアジャイルコーチが半日かけて、ふりかえりのワークショップを実施。
タイムライン × 感情曲線 ふりかえり
→ プロジェクトの発足からリリースまでの歩みと感情を可視化
SailBoat ふりかえり
→ 自分のチームを船として、次のゴール（宝島）・課題（錨）・リスク（暗礁）・強み（追い風）を対話で整理
やった感想
・お互い（ビジネス/開発）の気持ちが少しわかった
・次の具体的なアクションを決めることができた
・リスクの共通認識ができた
②合宿でのRebootの例
合宿（1泊2日）という場をつくった。以下を実施。
・偏愛マップ ＆ 他己紹介
・紙ヒコーキ スプリント体験
・“自分たちのスクラム” を描くワーク
・ユーザーインタビュー準備ワーク
その結果
・新メンバーを含めたつながりがより強くなった
・チームの進む方向がそろってきた
・“自分たちで動く” 行動が増えた
所感：
もやもやしている問題点をしっかり言語化し、その原因を解消するためのプラクティスを実践できる点が素晴らしいと思いました。
原田 聡さん(コニカミノルタ株式会社)
テーマ：1%のご近所さんが心の支えに！〜アジャイル社内普及ご近所さんマップを作ろう〜
大きな会社だと、関わる人が多い。
事業横断のテーマを扱うのに、時限制かつ任命制の委員会という取り組みは効果がある。
Agile CoE
会社に公式に認められた委員会。時限制かつ任命制。
社内アジャイルコミュニティ
Agile CoEが運営。無期限。自ら主体的に加入。脱退自由。
運営と参加者に線引きはない。
常に何かしらの勉強会やディスカッション会が行われている。
失敗した話。
なにかを変えたいと思って行動したときに、何も変わらなかった。
しかし、本当に何も変わっていないのか？
小さな変化は観測しづらい。だが大きな変化は小さな変化から始まる。
アジャイル社内普及として、最初は観察者が多い。
そこから、社内コミュニティのイベントに参加してくれたり、一緒に社外イベントへ参加してくれたり、そういう仲間を増やしていく。
それを見えるようにする。
そういう小さな変化が大きな変化につながると信じている。
所感：
自分が信じることのために集まった仲間を少しずつでも増やしていくことが、大きな変化につながるんじゃないかという信念で活動しているところは、すごくエモいと思いました。
私の場合は、アジャイル関係なしに、私が紹介したプラクティスを社内で実際に試行してくれた方々を増やすことが嬉しくて、ちょっとずつでもそれを増やしていこうとしているので、たぶんその点は原田さんと近い考え方でやっているのかもしれません。
市場 愛望さん(中部電力ミライズ株式会社)、斉藤 りんさん(株式会社MSOL Digital)、鍾涛さん(株式会社MSOL Digital)
テーマ：中部電力ミライズにおけるアジャイル先駆けプロジェクトが挑む再出発
チームが抱えていた問題
① ビジョンの希薄化
② 技術負債が招く役割間の対立
③ チームのサイロ化(２つのチームで独立した状態)
そこからReboot。
①の対策：インセプションデッキの見直し・更新
ステークホルダーとエンジニアが話す機会を持つことで、エンジニアが何のために機能をつくるのかのWhyが理解できた。
エレベーターピッチとトレードオフスライダーを見直し。
②の対策：技術負債と向き合える環境づくり
・“お客さまの価値”を共通の判断基準として再定義
・業務要件と同じ基準でエンジニアとPOが対話
・実施する作業は全てバックログに入ることで透明性が担保される
③の対策：コミュニケーション機会を創出
モブワーク・ペアワークを取り入れて会話のきっかけを創出。ペアをスプリントごとに決める。スプリントごとにペアを交代。
不定期で対面作業日を開催。
まとめ：大事なのは改善し続けること。
所感：
発表資料には書いてありませんでしたが、最後のまとめのページで「大事なのは改善し続けること」という話があったのことが印象的でした。
やっぱり、試行錯誤を継続することが、すごく大切と思いました。
中村 孝大さん、玉置 健太さん、乙部 達生さん(三菱電機株式会社)
テーマ：大企業の壁を突破せよ！一般社員が仕掛けるアジャイル革命
アジャイルを浸透させるためにやったことを紹介。
組織の現状分析
「今のままで十分」で「変わる必要がない」という考え方が蔓延していた。
情報共有の場がない。横のつながりが希薄。
対策の実践
「アジャイル」という用語を使わずに、こっそりアジャイルのプラクティスをやる。
デイリースクラムをデイリーミーティングと呼び、カンバンをTODOリストと呼んで実践。
プロジェクト完了時にしかやっていなかったふりかえりを短いスパンで定期開催。
飽きないように、ふりかえりカタログを使って、毎回異なるふりかえりを実施。
焼肉レトロスペクティブは、ふざけているように見えるかもしれないが、「なぜそれを焦げた肉にたとえた？」という話から、他の人の話を真剣に聞くという効果があってよい。
新人の話
新人がスクラムに入ったとき、最初はなんもわからなかった。
そこで、朝会を学びと改善の場とした。
とにかくしゃべる → 振り返る → 改善する → 共有するのサイクルを繰り返した。
ペアプロ・モブプロを導入して、開発速度が向上、作業が進むとモチベーション向上、学びが増える。
その効果が知られ始め、組織内でも、ちらほら実施されるようになった。
所感：
アジャイルを導入するのでなく、ウォーターフォールでも有効なプラクティスを導入するという考え方は、とても共感できました。
あと、以下の考え方は、とても素晴らしいと思ったので、参考にさせてもらいます。
飽きないように、ふりかえりカタログを使って、毎回異なるふりかえりを実施。
焼肉レトロスペクティブは、ふざけているように見えるかもしれないが、「なぜそれを焦げた肉にたとえた？」という話から、他の人の話を真剣に聞くという効果があってよい。
高橋 裕之さん(ファインディ株式会社)
テーマ：ソフトウェア開発現代史: 55％が変化に備えていない現実
戦後、日本のものづくりは「安かろう、悪かろう」だった。その後、品質を鍛え抜いて世界を驚かせた。
50年が経ち、ソフトウェア・ファーストな現代Big Techと呼ばれる企業は日本に存在せず、そのほとんどは米国企業。
21世紀になり、アメリカはアジャイルとドメイン駆動設計などでソフトウェア開発が復活してきたが、日本は停滞している。
ITエンジニア800人くらいのアンケート結果のレポートでの衝撃の結果。
- 50%くらいがアジャイルではない
- 15%くらいがVSSを利用
- チームのCICDの満足度は15%
AI活用について、DORAレポートからの見解。
AIは増幅器（amplifier）。
AIは、高パフォーマンス組織の強みと、苦戦している組織の機能不全を拡大します。
AIによるソフトウェア開発は、皆さんの組織で何を「増幅」させていますか。
所感：
やっぱりAIを活用するためには、組織の能力を高めることが重要ということを再認識しました。
それと、50%くらいのソフトウェアエンジニアが、アジャイルではないということで、フォーターフォールでもアジャイルでも有効なプラクティスをこれからも発信していこうと思いました。
壽山 雄己さん、松本 俊さん(株式会社テクノプロジェクト)
テーマ：変われない組織で、変わり続けることを選んだ
受託開発にて、アジャイル開発を実践そこから7年間、管理者、現場の立場でアジャイルを推進。
工夫した点や気づきを紹介。
ウォーターフォール前提の承認プロセスが変えられない制約の中で、できることからアジャイルのプラクティスを実践。
その結果、顧客のプロジェクトでアジャイル開発を採用するケースが増えた。
顧客作成資料をもとにユーザーストーリーマッピングのたたき台を準備し、模造紙に付箋を貼り出し、発注先の会議室でPOとSMで並んでワークを実施。同じ壁を見ながら、同じ付箋を指差し、手を動かして考える。
→ 画面越しでは生まれなかった信頼の空気が流れた。オンラインに戻っても自然な対話が続いた。
所感：
変えられない制約がある中でも、自分にできる変えられるところを探して、変えていくための努力を継続している点は素晴らしく、見習いたいと思いました。
菅沼 拓也さん(株式会社 三菱ＵＦＪ銀行)
テーマ：MUFG×大規模アジャイル 2年目の挑戦と現在地
アジャイル運営で出したい成果を明確にした。
①価値を早く提供
②環境変化に即応
③働きがいを向上
アジャイル運勢の推進のために、アジャイル変革推進室を立ち上げた。
それでアジャイルを推進し、それに対して現場の方々に、この場でインタビューを実施。
動くシステムを早く確認できるという点で、早くフィードバックを得られるメリットを現場の人たちが感じているようだった。
アジャイルでもっと早くリリースしましょうという話ではなく、フィードバックを早く得た方がリスク軽減できるし、より良いものになりやすいので、そうしましょうという考え方を、現場の人たちに理解してもらうように努めているようだった。
所感：
実は菅沼さんとは、1日目の懇談会でお話をいろいろ聞いたので、上記の発表以外で、詳細な困りごとや知見をお聞きして、すごく学びになりました。ありがとうございます。
森實 繁樹さん(株式会社レッドジャーニー)
テーマ：あなたのアジャイルがうまくいかない10の理由
以下に共感した話を列挙。
- 開発者でも、UXデザイナーやPOやスクラムマスターやユーザーの帽子(ロール)も被った方が良いよ
- 権限委譲は責任まで渡しちゃ駄目。実行は任すけど責任は取るよ。そして権限は小さく渡すよ
- ふりかえりで感謝や良かったことをもっと出そう。成功体験を共有した方が、再現性がある
- チームに与えられているのは実行責任であり、説明責任は誰か1人が担うべき
- チーム力を高めるためには、まず個人と向き合い、個人の特性や強みを認め、それを最大限引き出せる、あるいは伸ばせるための策を講じる
所感：
豊富な現場の経験から、実際の現場でよく起きそうなことを挙げてくださったので、学びになりました。
平鍋 健児さん
テーマ：Agile Japanで描くAI時代の私たち
これまでの話
Agileの考え方で大事なこととして、考える人とやっている人が同じであるのが大事で、それがAgileの本質！
やっている人が最初に気づくんだから、考える人と別々にしたら駄目。
ぼくたちは、変われたか？
変わった。変えた。
でもまだ、旅の途中。
いつでも新しいことを始めることが大事。
これからの話
プロセス・ルール・役割・人の性格などを「チーム運営知識」と定義し、それもAIにプロンプトとして渡せるようになるのでは？
(ちょっとキツめの言い方をされるとしょんぼりしてしまう性格の人には、優しい言葉をかけるなども含む)
そういう情報も含めてぜんぶAIでかき集められるようになれば、ふりかえりもAIでできるのでは？
つまり、だんだんAIも暗黙知を取り入れて形式値にしてくれるようになる。
野中さんの言葉
イノベーションを起こせ！
大いなる挑戦を！！
安野さんに原動力は何かと聞いたら「好奇心」ということだった。
好奇心をもってチャレンジしよう
所感：
好奇心をもって、新しいことを始めることに、今後も全力でがんばろうと思いました。
それを伝染させるために、それを楽しくやっていきたいと思いました。
まとめ
改善をするときに、今のプロジェクトで見えている問題をもとに改善する手法はよくあります。
今回の様々な発表の中で、現場のプロジェクトが見えていない問題を可視化するために、「理想の状態」をイメージして、それと比較することで現状に伸びしろがあることを示して、その差分を埋めるために改善するという考え方が大切だと思いました。
1日目は現地、2日目はオンラインで参加しました。
両日とも、とても学びになりました。
運営および発表者の皆様、ありがとうございます。
あと、現地で、話してくださった方々、私を知っていて声をかけてくださった方々、とっても楽しかったです。ありがとうございました。