はじめに
2025年11月13日に Agile Japan 2025 の1日目に参加しました。
タイムテーブルは以下です。
https://2025.agilejapan.jp/timetable_day1/
発表者ごとに、どんな発表だったのかと、そこで学んだ気付きなどを書きます。
安野貴博さん
テーマ：1%の変革が未来を創る
最初は、これまでのキャリアの話。
エンジニアの後に2回起業。
1回目の起業は、AIの黎明期にチャットボットを作成して広くシェアを取った。
2回目の起業は、法務関係の日本語は人間が読むには難解だがAIが理解しやすい日本語であるという点に目をつけてプロダクトを開発して広く使われた。
SF作家として、テクノロジーがあったときに、それをどう活用するかを考えた話を作った。
政治家としても、テクノロジーを活用して、政策としてアウトプットしている。
ここまでのキャリアは、テクノロジーを通じて未来を構想する、を一貫して実施している。
今回は、AIを用いたDXを紹介。
AIと政治は遠い関係に思われているが、そんなことはないと考えていた。
その例を以降で説明。
都知事選では、無名の状態から1ヶ月で15万票を取れた。
それができた仮説は、AIなどのテクノロジーを使って双方向の選挙をやったから。
従来は、ブロードキャストと1つ1つの意見の受け取りをしていた。しかし、既存の意見募集では受け取り側がパンクする。
そこで、ブロードリスニングを用いた双方向のコミュニケーションを行い、多くの声を上手に収集したことが成功の要因。
重要なポイントは、聴く→磨く→伝えるのサイクルを高速に回すこと。
以降に①②③で詳細を説明。
①みんなの意見を聴く
政策について意見をもらい、その意見をAIを活用して可視化して分析。
その可視化ツールは、オープンソースだったが、日本語対応していなかったので、日本語対応して利用した。
②みんなで案を磨く
GitHubで政策改善のための意見や変更提案ができた。
都知事選では15日間で、232個の課題提起、104個の変更提案、そのうち85個を反映。
ただし、GitHubが一般ユーザーからはわかりにくいという指摘もあった。
そこで、参議院選では、喋れるマニフェストを通じて意見収集を実施。
ユーザーが喋れるマニフェストと話しているだけで、裏ではAIがMCPを用いてGitHubのプルリクエストを作成し、1万件のプルリクを作成した。
しかし、1万件ものプルリクエストをどう反映させていくのか、という別の問題が起きたので、それは今後解決していくように動いている。
意見を収集するにあたって、オープンな場で議論は荒れなかったのか？という質問がよくあるが、AI技術は建設的な議論のためのモデレーションにも活用できるのでそれで解決した。
③みんなに伝える
Youtubeライブで24時間伝える活動を実施。
参議院選では、YoutubeのAIあんのが17日間で24,000件を回答、電話のAIあんのは1,350件以上を回答。
まとめ
- 遠い分野でもよくよく考えるとAIの使い方は山程ある
- DXは既存のプロセスをただデジタル化するのではなく、新しい価値創造が可能
- エージェントが間にはいることでコミュニケーションのあり方が変わる
質問時間があったので、私は以下のように質問しました。
Q.
「みらいまるみえ政治資金」など、素晴らしいプロダクトをリリースした永田町エンジニアチームについての質問です。
開発チームのメンバーのそれぞれの活動の透明化は、どの程度やっているのか知りたいです。
たとえば、朝会で各自が今日の目標を宣言して、帰る前に実績を報告したり、着手するチケットをどのように進めていくつもりなのかを記載したり、分報（timesチャンネル）を使って何をどのように進めているのか実況したりなどで透明化することで、メンバー同士でフィードバックしあって生産性を高めるなどの活動があります。
A.
正直な話、まだチームができたばかりなので、あまり透明化の練度は高くないので、むしろ教えていただきたいと思っている。
現状として、関係者で集まる定例会議は週1回、多くはリモート働いていて、主にSlackで連絡しあっている。
タスク管理は Linear を利用している。
主に Claude Code を利用していて、それを前提でAI活用しやすいような技術選定やアーキテクチャ選定を決めた上で開発している。
所感：
質問の回答について、安野さん本人から、エンジニアがリモート中心でありながら、そこまで透明化はしていないとのでした。
ただ、これは予想の範囲内で、私の仮説としては、「めちゃくちゃ優秀なエンジニア」は、各自の活動を仕組みで透明化しなくても、必要な報告や相談はするし結果も出すので、そういう優秀なエンジニアばかりのチームでは、こちらで私が書いているような各自の活動を透明化する仕組みはなくても問題ないと考えています。
逆に、ジュニアレベルを含むチームの場合は、メンバーの生産性の底上げのために透明化の仕組みが必要と思っています。
また、「遠い分野でもよくよく考えるとAIの使い方は山程ある」という視点で具体例をたくさん紹介いただいたことに関しては、自分のそのようにもっと柔軟に様々な可能性を考えられる人になりたいと思いました。
市谷 聡啓さん(株式会社レッドジャーニー)
テーマ：作る、試す、正す
デッドエンド・ジャーニーに陥ってしまうことはある。
問題の本質は、適応課題。
始めたからには事業化するんでしょバイアスにかかってしまい、仮説が不十分でも事業化にゴーしてしまうことがある。
そして、気付いたときには手のうちようがなくなっていることがよくある。
その分水嶺は、MVPの特定時にある。
どれだけ考えたところで一手目の時点(MVPの特定時)では、勝ち手が見えてないことがある。
二手目が大事。
一手目（MVP）の仮説を立てた後（仮説キャンバスで仮説を明らかにした後）、二手目以降の仮説展開を見えるようにすることが重要。
我々の開発の営みは以下の3つに分かれる。
ソフトウェアづくり：課題を前提に実現手段を探索、目指すのはアウトプット
プロダクトづくり：状況を前提に課題から探索、目指すのはアウトカム
システムづくり：状況自体を作り出す経時的な変化を扱う、目指すのはインパクト
やはりキャンバスに描くことが大切(市谷さんが以前から推奨しているのは「仮説キャンバス」という方法)。
キャンバスによって、何を考えるべきか？の対象を捉える、対象と対象の関係を捉える、考えることと動くことの間の距離を縮める。
エナクティヴィズム（行為的認知）
これはXPの考え方と同じ。
知ろうとすることで、わかる、自分たち捉える世界が更新される。
何を知るのか？結果として何を知ったかを可視化するための手段を講じる。
アジャイルとは、エナクティヴィズムを強調したあり方と言える。
本日の発表についてのより詳しい話は、書籍「作る、試す、正す。アジャイルなモノづくりのための全体戦略」を読んでくださいとのこと。
質問時間があったので、私は以下のように質問しました。
Q.この考え方は、新規プロダクトを考えるときだけでなく、既存プロダクトに新機能を開発するときにも使えますか？
A.使えます。既存プロダクトでも、不確実性の高いことをやろうとしているときには、活用できます。
所感：
ものすごいスピード感で、テンポよく発表いただいていたので、市谷さんの書籍やこれまでの発表を拝見していない私にとっては、理解が追いつかない点もあり難しかったです。
市谷さんは note でご自分の考え方を言語化してくださっているので、あらためてこちらを読んでみようと思いました。
加藤 敬介さん(JR東日本)、八巻 智和さん、大西 浩二さん(アマゾンウェブサービスジャパン合同会社)
テーマ：From Zero to Hero：伝統的な大企業がチャレンジする未来想像
JR東日本を、顧客起点で価値創造をしていくような組織に変革したい。
しかし、組織を変革するためには、問題がいろいろあって険しい道のりだった。
大きなミッションを背負ったパイオニアの3人は、悩んだ末、AWSに相談した。
AWSが入ってまずやったことは以下。
ステークホルダー特定 → インタビュー設計 → インタビュー実施 → 現状分析
そして、ステークホルダーの期待とチームの想いから活動スコープを策定。以下を実施。
①プロダクトの刷新
ビジネス価値と顧客価値に迅速に対応できるプロダクトの構築
②ビジネスアジリティと品質を両立させた新しい開発プロセスの定着化
関係者が共通の目標を持ち、価値あるものから小さく確実に進むスタイルへの変革
開発を進めるにあたって、内製化チームの組成により、持続可能な開発体制を作る。
ポイントとして、エンジニアのほとんどがパートナー起業である中、少数のエンジニアに「育成枠」として、自社社員を配置(将来的な技術力の内製化のため)。
チームづくりとして重要視したのは、チームの一体感のための価値観の統一。
最初は、価値観が異なっていたので、MVVを定義して、価値観を共有した。
26人全員でMVVの合意を取った。
質問時間があったので、私は以下のように質問しました。
Q.MVVは、そのプロダクト特有の尖ったものを定義するのは難しい。実際に、MVVに立ち返って判断するようなことはあったか。
A.たくさんあった。まず、MVVを定義するのに、関係者全員(26人)で丸二日間、缶詰めになってAWSさんのファシリテートのもと全員で議論して決めた。さらに3ヶ月後にMVVの見直しとして、再び全員で丸二日間、缶詰めになって見直した。
やり方として、関係者全員が、そのプロダクトをこれから実現するにあたって、どんな価値観を大切にしたいのかを言語化してもらった上で、それをすり合わせていった。
そこまで議論して納得したものだから、MVVのValueの定義に基づいてUXで迷った時などに判断できている。
所感：
MVVの定義の過程が、凄い！と思いました。
MVVは、そのプロダクト特有の尖ったものをしっかり定義するのは難しいと思っていました。ちゃんと判断の礎になるものを定義するには、ここまで時間をかける必要があるんだなというのも学びでした。
秋葉 啓充さん(株式会社SHIFT)
テーマ：巨匠たちのすれ違いから学ぶ、AI時代のアジャイルで重要なこと
ケント・ベックについて話す。
ケント・ベックは、XPの考案者で、JUnitを開発し、TDDの普及に尽力。
秋葉さんのキャリアスタートは、Javaプログラマー。
JUnitのおかげでテスト工数が削減されたので、ケントベックは自分にとって神。
アジャイルマニフェストが2001年に誕生後、2002年にある開発カンファレンスでケントベックが登壇。
そこでアラン・クーパーとの間に論争が起きた。
ケントベックの主張
- 実装が先
- ゴールは予測できない
- 実践と対話を繰り返すことが重要
- 対話と変更こそが設計そのもの
アラン・クーパー
- 設計が先
- ゴールから考えないといけない
- 間違っていたとしても差分が明らかになる
- 正しい設計がすべての出発点
すれ違いの理由は、それぞれが用いているユーザー、デザイナー、エンジニアの用語の意味に相違点があったこと。
二人は、ユーザー行動を想像していくプロセスに違いがあった。
その後、世界は、ケントベック的なアジャイルが主流になった。
そして現在。AIでそれは加速された。
しかし、AIのレポート(DORAレポート)によると、AIは「開発の生産性」は高めたが、組織スループットは高まっていない。
まとめ
- 現代は世界中がAIに夢中
- AI時代の巨匠たちの「設計か実装か」の20年前の論争は終わっていない
- はたして、われわれはAI利用によって対話的生成のスピードが上がることに一喜一憂して良いのでしょうか
私は以下の質問をしました。
Q. 用語の確認です。ここで言う設計とは、プログラムのアーキテクチャなどを定義するソースコードの内部の設計のことか、ユーザーにとってそのプロダクトがどのように動作するのかという要件定義のことか、どちらですか？
A. ありがとうございます。最初に用語の定義を説明すべきでした。後者です。アラン・クーパーは、ユーザーにとってどういう動作をするのかを設計と呼んでいて、ケントベックもプロダクトがどういう動作をするのかも含めて試行しながら決めるということでした。
所感：
ケント・ベックとアラン・クーパーとのすれ違いが用語の意味に相違点があったことであり、今回の発表の中でも「設計」をどういう意味で解釈するかという点があったことから、用語の意味を揃えるのって、とっても大事なんだなと思いました。
あと、AIで個人の生産性が上がったことに一喜一憂するだけでなく、組織全体でより価値の高いものをより早くより安く届けるという点で考えることも大切ということを学びました。
清野 航さん(KDDI)、岡 樹太郎さん(三菱UFJ eスマート証券株式会社)
テーマ：金融会社でのアジャイル導入の挑戦
対話を主軸としたアジャイル導入の事例の紹介。
アジャイル導入前の状況は、かつてのスピード感を失っていた。
そこからアジャイルに取り組んで改善した。
大企業で変革が進まない理由は以下。
動機づけが不十分、巻き込みが不十分、成熟が不十分。
まずは関係する人が全員納得して、本当にやりたいと思わないと変革が進まない。
今回のポイントは、対話を中心としたアプローチ。
みんなの関心が高いのは品質 → 問題発生時にやり方を変えたせいと見られてしまう。
まずは現場との対話を実施（勉強会の実施）。
アジャイルをなぜやる？のWhyに特化した勉強会。
その中で、疲弊の原因がドキュメントと承認フローにあることが分かった。
ビジネスサイドとの早期対話も実施。
リードタイムの短縮、気軽にリリースしたいなどの声があり、アジャイル導入の賛同が得られた。
開発フローの見直しは、会社のルール見直しが必要でめちゃくちゃ大変そうなので、正直やりたくないなと思った。
でも、覚悟を決めてやった。
バリューストリームマッピングをやった。
リリースまでの一連のプロセスを明らかにして、無駄な部分を探す。
1ヶ月くらいかけて、新しい開発フローを作成。
まず小さく始めた。
関心が高い品質について、品質とは何かを定義。
品質で重要なのか、リリース後の大きなバグや障害が発生しないこと。
よって、過去の開発における知見をフル活用し、あえて従来のチェックリストも利用。
所感：
業務フローを新しく見直して変えちゃうのは凄いと思いました。
また、「品質が大事」という抽象的なものを、実際に何が大事なのかというのを深堀って、リリース後の大きなバグや障害を発生させないことと特定して、そこにしっかり対策を立てるという考え方は、他にも応用が効きそうな考え方なので、参考になりました。
伊芹 久美子さん(JSTQB)
テーマ：ソフトウェアテストの学習に役立つJSTQBのシラバスと試験のご紹介
JSTQBとは、ソフトウェアテストのシラバス公開やソフトウェアテスト技術者資格認定をしている。
効率的・効果的にテストをするのは割と大変。
公開中のシラバスを使った学び方を紹介。
日本語訳が公開されているシラバスは13件。
テストの初学者へのお勧めは「Core Foundation FLシラバス」
アジャイルテストに関係するシラバスもある。
探索的テストを実行することも記載されている。
探索的テストでは、準備済みのテストチャートに従って、テスト設計とテスト実行を同時に行う。テスト時には、一連のヒューリスティックを適用できる。
ストーリーマッピングは、ユーザーストーリーを並べることで構成される。
シラバスの活用を勧める理由
- テストの効率や効果を支える多様なトピックを学べる
- 無償で利用でき、教材として利用しやすい
- 大本は、英語のISTQBシラバスであり、国内外の別組織の人とも同じ用語や概念で会話しやすい
所感：
探索的テストで、自分は「ヒューリスティック」という用語を使ってメンバーに説明していましたが、JSTQBでもその用語を使っていたので、自分が使う用語の妥当性という意味で安心しました。
「国内外の別組織の人とも同じ用語や概念で会話しやすい」という話は、「確かに」と納得しました。あと、自組織のみんなで理解していると、同じ用語と考えで議論できるので、そういう利点もあるのは良いなと想いました。
西嶋 優子さん(NTTデータグループ)
テーマ：変革の壁をどう超える？アジャイル組織づくりのリアルと工夫
最近、ビジネススピードが加速し続けている。
やろうとしたことが、数カ月後にはあまり価値が出ない状態になってしまうことが多くなってきた。
変革できる起業は、攻めの経営で、将来を見て危機感を持ち変えようとする。変えるリスクを受け入れる。成功事例を先に作る。
従来組織の世界
組織構造は、階層型、専門性と効率性で分担。
アジャイル組織の世界
社員全員が自分たちで最適解を考え、短いサイクルでPDCAを回し、検査と適応によりゴールを目指す。
ネットワーク型組織、自律的。
NTTデータで組織変革しようとした結果、いろいろ課題が出た。
その課題と打ち手を紹介。
課題1：アジャイルが目的化してしまう。ビジネススピードが変わってない。
打ち手：ビジョンを整理し、成功基準や評価指標を明確にする。MVPや段階的リリース。
課題2：タイムリーに意思決定できない。チームがプロダクトの改善点をすぐに取り込めない。
打ち手：開発チームがビジネス部門との共通ゴールを持つ。ビジネス部門のメンバーがチームに参画。組織リーダーと近くで会話できる環境づくり。
課題3：アジャイル人材不足。
打ち手：育成への投資。評価制度見直し。エンゲージメント向上施策。継続的なパートナー。
課題4：組織変革が進まない。
打ち手：変革推進チームをアサイン。リーダーから伝え続ける。小さな成功を積み重ね、賛同者を増やす。
課題5：過去習慣に戻ってしまう。
打ち手：変革推進チームが継続的にリード。組織ビジョンを定期的にアップデート。適用範囲の拡大をあらかじめスコープに入れる。
課題6：経営施策を迅速に軌道修正できない
打ち手：大枠で予算を確保し、一部の優先順位の判断をチームに移譲する
まとめ
安心より前進を選べるチームになろう
所感：
リスクをとってでも新しいことを試していくマインドは凄く大事なんだなと思いました。
安心(安定した同じやり方)よりも、前進(失敗するかもしれないけど、新しいことを試す)を選べるチームをつくっていこうと思いました。
三木 千佳さん(野村ホールディングス株式会社)
テーマ：アジャイル初心者たちの成長ロードマップ
アジャイル初心者たちで、アジャイルチームを立ち上げた。
アジャイルコーチが入った当初、以下の問題があった。
- 朝のデイリー長い
- 毎週ふりかえりしているけどよくなっていない
- 毎週のユーザーミーティングに成果物が揃っていない
ふりかえりのやり方を変えてみた。
- スプリントの予実を全員で確認
- 見積もりSPと乖離しているアイテムの原因を議論
- 具体的な改善項目や留意点を特定
- 前回のアクションの実行状況を最初に確認
- アクションを設定し、期日や担当者を明確にする
その結果
- 自分たちで改善アクションを意識するようになった
- ストーリーポイントの見積もり精度向上
- ドキュメントの整備やテスト実施前のレビューの品質向上
- メンバーからのアイデアがどんどん出るようになる
スプリントの期間を変えてみた
- 1週間スプリントを2週間スプリントに変更
- ユーザーに見せられるインクリメントをしっかり作る
- 会議体の長さや参加者の見直し
- プランニング：2時間
- レビュー準備：30分
- レトロスペクティブ：毎週開催
さらに様々な改善を行った。
- 毎週金曜に30分のTips会など
チームが成長してきたことを知るために、チーム成熟度を測る仕組みが必要。
そこで、アジャイルフルエンシーモデルをベースに計測する仕組みを作った。
所感：
いろいろな改善は、とても参考にしたいものが多かったので、資料を見返したいと思いました。
この記事を書いている時点では、発表資料が公開されていないので後日に確認します(発表者に質問したところ、後日にAgileJapan公式ページから公開されるとのこと)。
カリルセルジオさん(ソニー株式会社)
テーマ：ACEマインドセットで実現するアジャイル・マイクロリブート
マイクロリブートで様々なやり方を変えることを試した。
以降で例を紹介。
23%もののストーリーポイントを、不具合修正に使っていた。
UTを任意から必須にして、結合テストを実装の1日後にして、E2Eテストはスプリントごとに実施した。
これにより、不具合修正に使っていた工数は半減した。
スクラムマスターを固定じゃなくて、エンジニアが交代でやるようにしてみた
それはうまくいかなった
マイクロリブートのやり方は以下の通り。
- 不満点や問題点を挙げる
- 質問形式で問題を設定する(例：なぜ私たちのデイリースクラムは25分かかるのか？)
- 問題を解決する方法を提案する
- それを1週間くらい試してみる(うまくいかなかったらやめる)
所感：
今のやり方をもっと良いかもしれないやり方に変えて試してみることは、やっぱり大切だと思いました。
うまくいかなかったらやめるという点が、私が公開しているこちらの施策と共通している点も多いなと思いました。
まとめ
Agile Japan 2025、とても学びになりました。
発表してくださった皆様、ありがとうございます。
2日目のレポートはこちら↓