2025年12月AgileJapanから得た知見

Agile Japan 2025 に参加して得た知見を紹介 2025/12/3 弥生株式会社 小島 優介

Slackで感想の投稿を Slackの「#エンジニア全体」チャンネルにて 本発表用スレッドを立てていますので そちらに感想を投稿してもらえると嬉しいです どの部分が学びになったのかなどの感想は、 今後、知見を展開するときの入力にさせていただきます。 2

自己紹介 名前：小島 優介 弥生歴：2025年6月入社 所属：Next BU - 次世代給与 職種：エンジニアリングマネージャー 発信活動：こちら参照 3

• https://kojimadev.wraptas.site/

Agenda  はじめに  各セッションのポイント(13件)  明日から試すプラクティスの候補  まとめ 4

はじめに 2025/11/13-14 の Agile Japan 2025 に参加 1日目：現地参加 2日目：オンライン参加 2日間の全19セッションの中で 弥生で活用できる知見のみを厳選して紹介 各セッションの発表資料は以下参照 https://2025.agilejapan.jp/timetable_day1/ https://2025.agilejapan.jp/timetable_day2/ 5

• https://2025.agilejapan.jp/timetable_day1/
• https://2025.agilejapan.jp/timetable_day2/

本発表のゴール 参加者全員が、明日から試してみるプラクティスを 1件以上持ち帰ること 6

注意事項 以下の条件をすべて満たすチームは得るものがあまりないので その点はご了承ください 1. 改善活動として「問題を解消すること」と 「困ってないけど、より良くすること」の両方を継続している 2. 上記の後者について、世の中で実績のあるやり方を 参考にして、新しい取り組みを試し続けている 3. 試して得られた知見を言語化して発信している 上記を満たしていない場合は、得られる知見が多くあります 7

Agile Japan のセッション共通点 「現場が困っていない ＝ 現場が問題を観測できていない」 という事象に対して取り組んだ話が多い 補足： 現場が問題を観測できないことがあるのは当たり前 困っていなければ問題として観測するのは困難 だからこそ、「困ってないけどより良くする」ための活動が重要 8

Agenda  はじめに 早口で次々に 得られた知見を 紹介します  各セッションのポイント(13件)  明日から試すプラクティスの候補  まとめ 9

1. AI時代のソフトウェア開発を考える (1/6) 発表者：和田 卓人さん 2025年に Vibe Coding の登場で、プログラミングのかたちが変わった それを踏まえて、これからのソフトウェア開発がどうなるのかという話 バイブコーディングによる開発生産性の高まりが原因で、 開発規模が大きくなると発生する諸問題が、短期間で発生するようになった 内部品質への投資(適切な設計を考えた作り込み)の損益分岐点は 従来1ヶ月だったが、1週間まで短くなった (上記の損益分岐点の話の詳細は、こちらの発表資料のP48を参照) → だから内部品質へ投資を怠るのはNG 10

• https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition

1. AI時代のソフトウェア開発を考える (2/6) 「AIと伴奏」「AIに委託」の2種類のやり方を適材適所で活用 「AIに委託」の活用方法として、いろいろ並行でやらせてみて、 いまいちなら使わない、ということもできる 人間に対してはやりにくいことも、AI相手ならやりやすい (例) Cursor は標準機能で1つのプロンプト で複数のエージェントを同時に 実行して、一番良かった結果だけを 採用できる 11

1. AI時代のソフトウェア開発を考える (3/6) 包括的な構成管理： しばらくはモノレポ(1つのリポジトリに全部入れる)が有利 開発に関わるドキュメントもリポジトリに全部入れる ドキュメントはプレーンテキストで、コードの近くに置く方がAIを活用して ドキュメント作成およびメンテナンスしやすい そうしないとドキュメントが腐る 最初は、二重管理になってもいいから コードと同じリポジトリにもドキュメントを格納した方が良い 12

1. AI時代のソフトウェア開発を考える (4/6) MTBF から MTTR へ： MTBF（平均故障間隔）を重視する時代から MTTR（平均復旧時間）を重視する時代に変わりつつあったが AIによる生産性向上によりバグゼロの世界は非現実的となり それがより顕著になった 「バグを減らす」というマインドでなく バグが出ても「早く復旧する」ことがビジネス価値を高める 13

1. AI時代のソフトウェア開発を考える (5/6) AIから引き出せる性能は、組織(個人)の能力にそのまま比例する よって、能力向上が必要で、そのためにAI活用するとよい  AIに批判的なレビューさせる  何度もしつこくAIと議論する  あえてオーガニックコーディング(自分の手でコーディング)  研修に関しては、AIを活用して座学を学べるため、 反転学習(従来の研修と宿題のやり方を反転された方法)と アクティブラーニング(ディスカッションなど行動して学ぶ方法)を活用 14

1. AI時代のソフトウェア開発を考える (6/6) セッションのポイント： 「困ってないけど、より良くするための改善」を 次々に考えて試し続けている 15

2. 1%の変革が未来を創る (1/3) 発表者：安野貴博さん 従来の政治家は、ブロードキャストと1つ1つの意見を受け取る 安野さんは、そのやり方では受け取り側がパンクすると考えた (現場は、その問題を観測できていなかった) 対策： ブロードリスニングを用いた双方向のコミュニケーションを行い、 多くの声を上手に収集したことで課題を解消 都知事選にて、無名が1ヶ月で15万票を集める快挙を達成 16

2. 1%の変革が未来を創る (2/3) GitHubで政策改善のための意見や変更提案を行い、 都知事選では15日間でプルリク85個をマージ ただし、GitHubが一般人から分かりにくいという指摘あり 安野さんは事前にその問題を観測できていなかったが フィードバックを求めることで、異なる観点を持つ人が問題を検出 参議院選では「喋れるマニフェスト」を通じて意見収集を実施 ユーザーは話しているだけで、裏でAIがMCPを用いてGitHubの プルリクエストを作成 17

2. 1%の変革が未来を創る (3/3) セッションのポイント： 政治の世界でも、現場が観測できていない問題は存在する 異なる観点を持つ人は、現場が観測できない問題を検出できる 18

3. From Zero to Hero … (1/3) 発表者：加藤 敬介さん(JR東日本)とAWSの方々 JR東日本を顧客起点で価値創造をしていくような組織に変革したい しかし、組織を変革するのは険しい道のりで、AWSに相談した 古い体質の組織を変えるために、いろいろな活動をやった その中で最も特徴的な活動は、チームの価値観の統一 最初は関係者の価値観が異なっていたため、 26人全員で議論してプロダクトのMVVを定義し、価値観を統一した 19

3. From Zero to Hero … (2/3) MVV定義のために関係者26人で丸二日間缶詰めで AWSさんのファシリテートで全員で議論 関係者全員が、そのプロダクトをこれから実現するにあたって、 どんな価値観を大切にしたいのかを言語化した上で それをすり合わせていった このプロセスが重要で、その後はコミュニケーションが活性化 (なお、メンバーが増えたら、再び全員で2日間 議論し直した) そこまで議論して納得したものだからこそ、 UXで迷った時など様々な局面でMVVに基づいて判断できている 20

3. From Zero to Hero … (3/3) セッションのポイント： 自分のチームでの価値観の共有活動として MVVもしくはインセプションデッキを定義しているから 問題ないと考えてしまうことがある しかし、本セッションのような素晴らしい組織は、 関係者全員が各自の価値観を言語化して議論し、全員が納得した上で 価値観を定義し、それに基づいて判断できている それと比較すれば、自分の組織の価値観共有の問題点を検出できる 21

4. 金融会社でのアジャイル導入の挑戦 (1/3) 発表者：清野航さん(KDDI)、 岡樹太郎さん(三菱UFJ eスマート証券株式会社) 三菱UFJ eスマート証券はスピード感を失っていた KDDIの支援により、アジャイル導入に取り組んだ まずは関係する人が全員納得して、 本当にやりたいと思わないければ変革が進まない みんなの関心が高いのは「品質」で、そこの納得が必要 問題発生時にやり方を変えたせいと見られてしまうのが嫌だった 22

4. 金融会社でのアジャイル導入の挑戦 (2/3) 関心が高い「品質」とは何かを関係者にヒアリング → 品質とはリリース後に大きなバグが発生しないこと 従来の膨大なチェックリストの利用を維持することで リリース後に大きなバグを発生させない前提を 維持できるならやり方を変えても問題ないよね ということでアジャイルのプラクティスを取り入れていった 23

4. 金融会社でのアジャイル導入の挑戦 (3/3) セッションのポイント： 当初の現場は、アジャイル導入できない理由が なんとなく品質あぶなそうという理由だった (現場でアジャイル導入の問題を観測できていなかった) 別の観点を持つ人(KDDI)の介入により、 その問題が何かを明確にした その結果、関係者の納得を得てやり方を変えることができた 24

5. 変革の壁をどう超える？… 発表者：西嶋 優子さん(NTTデータグループ) 組織全体にアジャイル導入した際の組織としての取り組みの紹介 トップダウンで組織構造をどう変えるかという話や 抽象度の高い話が多いため、内容は割愛 最後のまとめは「安心より前進を選べるチームになろう」 セッションのポイント： 安心の同じやり方よりも、失敗するかもしれないけど新しいことを 試すチームになろうは、多くのビジネスマンが共感する言葉 25

6. アジャイル初心者の成長ロードマップ (1/2) 発表者：三木 千佳さん(野村ホールディングス株式会社) アジャイル初心者たちで、アジャイルチームを立ち上げた アジャイルコーチが後から入ったことで様々な問題を検出して 世の中で実績のあるやり方で改善した(以下は例)  ふりかえりの改善アクションは、確実に実行される仕組みを 入れる(担当者を決めて次回のふりかえりで状況確認)  開発チケットの設計方針、実装方針を複数人で議論して 共有してから進める 26

6. アジャイル初心者の成長ロードマップ (2/2) セッションのポイント： 当初、現場は自分たちのやり方に問題があると思っていなかった (現場は問題を観測できていなかった) しかし、アジャイルコーチから見れば、典型的な問題があった (異なる観点を持った人は、現場が観測できない問題を検出できた) アジャイルコーチは、世の中で実績のあるやり方を提案して それを現場が素直に受け入れて改善した(素晴らしい) 27

7. アジャイル・マイクロリブート (1/3) 発表者：カリルセルジオさん(ソニー株式会社) 「マイクロリブート」という手法で今のやり方を変えてみる 例1：23%もの工数を不具合修正に使っていた → UT作成を任意から必須に、結合テスト実施を実装の翌日必須に、 E2Eテスト実施をスプリントごとに必須にした これにより、不具合修正に使っていた工数が半減 これは入念な 例2：スクラムマスターは固定じゃなくてもいいのでは？ → エンジニアが交代でやるようにしてみたがこれは失敗 準備が必要。 成功させる 方法はこちら 28

• https://note.com/kojimadev/n/nae0d5101b0ef

7. アジャイル・マイクロリブート (2/3) 「マイクロリブート」のやり方は以下の通り 1. 不満点や問題点を挙げる 2. 質問形式で問題を設定する (例：なぜ私たちの朝会は25分もかかるのか？) 3. 問題を解決する方法を提案する 4. それを1週間くらい試してみる → うまくいかなかったらやめる 29

7. アジャイル・マイクロリブート (3/3) セッションのポイント： 今のやり方から新しいやり方に変えてみるという考え方 「うまくいかなかったらやめる」を繰り返し共有する 新しいことを試そうとしても、失敗する可能性があることで 今のやり方を変えることに躊躇しやすい組織で有効な理論 失敗も学びになるし、成功するかもしれないなら試すべき というマインドを共有することで、新しいことを試す風土を作る (私もそのテーマで1600いいねの記事を公開し、何度かカンファレンス発表している) 30

• https://qiita.com/kojimadev/items/4b28f801863cf4e8f0da

8. アジャイルコーチングの事例 (1/3) 発表者：天野 勝さん、一條 凌佑さん(永和システムマネジメント) チーム発足から1年半の7人のチームが、やっと最近リリースできた しかし手応えよりも、モヤモヤの方が大きかった そこで社内の別チームのアジャイルコーチに相談した アジャイルコーチがヒアリングした結果、そのモヤモヤの正体は以下だった  ビジネスと開発の達成感のズレ  うまくいったこと・いかなかったことの整理ができてない  技術的負債の積み上がり 31

8. アジャイルコーチングの事例 (2/3) アジャイルコーチはそのモヤモヤを解消するために 適したふりかえり手法を実施した(手法の詳細は割愛)  タイムライン × 感情曲線 ふりかえり → プロジェクトの発足からリリースまでの歩みと感情を可視化  SailBoat ふりかえり → 自分のチームを船として、次のゴール・課題・リスク・強みを整理 実施した効果  お互い（ビジネス/開発）の気持ちが少しわかった  次の具体的なアクションを決めることができた  リスクの共通認識ができた 32

8. アジャイルコーチングの事例 (3/3) セッションのポイント： 現場は、なにがモヤモヤしているのか分かっていなかった (現場は問題を観測できていなかった) 異なる観点を持つ人(アジャイルコーチ)の介入で、問題を明確にした 問題が分かっても、その解消策の選択肢を現場を知らなかったが ふりかえりの社外勉強会などに参加したことある人なら 状況に合わせたふりかえり手法が存在することは知っている 大切なのは、世の中で実績のあるやり方を状況に合わせて実践すること （AIの普及により状況に合わせたやり方を実践する難易度は下がっており 今回のふりかえり手法はAIに提案してもらうことも可能） 33

9. 中部電力ミライズにおけるアジャイル… (1/2) 発表者：市場 愛望さん(中部電力ミライズ)とMSOL Digitalの方々 中部電力ミライズにて古いやり方でずっと開発していた MSOL Digital が介入して、問題点を検出 世の中で実績のあるやり方で改善した  ビジョンの希薄化 → インセプションデッキの見直し  技術負債が溜まる → 技術負債解消もバックログに入れて透明化  コミュニケーション希薄化と属人化 → モブワーク・ペアワークを導入 34

9. 中部電力ミライズにおけるアジャイル… (2/2) セッションのポイント： アジャイルコンサルタントの会社が 現場が観測できていない問題点を検出 世の中で実績のある改善策を提示し それを現場がしっかり実施することで改善された 35

10. 1%のご近所さんが心の支えに！ (1/3) 発表者：原田 聡さん(コニカミノルタ株式会社) 大きな会社だと、関わる人が多い 関わる人が多いと、やり方を変えるのは難しい アジャイル社内普及を推進していたが困難な道のりだった なにかを変えたいと思って行動したときに、何も変わらなかった しかし、本当に何も変わっていないのか？ 小さな変化は観測しづらい だが大きな変化は小さな変化から始まる 36

10. 1%のご近所さんが心の支えに！ (2/3) アジャイル社内普及の活動をしても、最初は観察者が多い そこから、社内コミュニティのイベントに参加してくれたり、 一緒に社外イベントへ参加してくれたり そういう仲間を増やしていく それを見えるようにする そういう小さな変化が 大きな変化につながると信じている 37

10. 1%のご近所さんが心の支えに！ (3/3) セッションのポイント： 他チームの開発のやり方を変えることは簡単にはできない 自分のチームで凄く効果のあったやり方を他チームに紹介しても 試してもらえなかったというのはよくある話 でも、相手に「新しいことを試す」という大きな変化はなくても 「検討する」という小さな変化は起きている だから、小さな変化を起こすことを繰り返すことが重要 1つだけじゃなく様々なやり方を説明したり、 社外にそのやり方を発信してバズらせることで有効性を証明したり、 社内で試してくれそうなチームで先に試してもらって実績を積んだりなど、 やれることはいくらでもある 38

11. 大企業の壁を突破せよ！… (1/2) 発表者：中村 孝大さん、他2名(三菱電機株式会社) スクラムで開発していた若手メンバーが ウォーターフォールの開発チームに異動後にやった改善の取り組み 異動後のチームは「今のままで十分」「変わる必要がない」という考え方が蔓延 (アジャイル導入も必要ないというスタンス) しかし、前のチームと比較すると問題だらけだった 前のチームでやっていたプラクティスのうち、 ウォーターフォール開発でもやった方が良いものを 「アジャイル開発の用語」を使わずに導入した 39

11. 大企業の壁を突破せよ！… (2/2) 問題①各自の担当作業の状況が不透明 → 朝会でカンバン(TODOリストと呼ぶ)を使って状況を透明化 問題②業務改善のサイクルが遅い → 数カ月ごとのプロジェクト終了時のみ実施していたふりかえりを 2週間ごとに行うように変更 セッションのポイント： 当初、現場は問題を観測できていなかった 透明化と改善が適切に行われていたチームを経験したメンバーは 異なる観点を持つので、現場が観測できない問題を検出できた その問題を解消するために、世の中で実績のあるやり方を導入した 40

12. 変われない組織で変わり続けることを (1/2) 発表者：壽山 雄己さん、松本 俊さん(株式会社テクノプロジェクト) 受託開発にて7年間、アジャイルを推進 ウォーターフォール前提の承認プロセスが変えられない制約の中で できることからアジャイルのプラクティスを実践  一度決まった設計を後からFBを元に変更することを顧客と合意  何を実現するか、どの順番で実現するかを定期的に見直す場を設置 その結果、顧客のプロジェクトでアジャイル開発を採用するケースが増えた 41

12. 変われない組織で変わり続けることを (2/2) セッションのポイント： 会社の仕組みは、簡単に変えられない だから、変えられるところを探して、「より良くするための改善」として 世の中で実績のあるやり方を試し続けた 42

13. MUFG×大規模アジャイル… (1/2) 発表者：菅沼 拓也さん(株式会社 三菱ＵＦＪ銀行) アジャイル推進のために、アジャイル変革推進室を立ち上げた しかし、アジャイル開発をやったことのない現場を変えるのは大変 アジャイル変革推進室が現場に伝えたことは、アジャイル開発により リリースを早めることでなく、早くフィードバックを得られるようにすること 最初の頃は、現場から「あれこれ言われてぜんぜん計画通りに進まない」 などの不安の声があった でも、まさにそれは良い傾向で、早くフィードバックを得られるからこそ 後から大きな手戻りが起きるリスクを軽減できた 43

13. MUFG×大規模アジャイル… (2/2) セッションのポイント： 現場は、やり方を変えたことで 関係者にあれこれ意見されて計画通りにいかず不安があった (現場はもともと抱えていた問題を観測できていなかった) 違う観点をもった人(アジャイル推進者)が問題を検出して 世の中で実績のあるやり方(早く関係者のフィードバックを得るやり方)を 行うことで手戻りリスクを軽減できた 44

Agenda  はじめに  各セッションのポイント(13件)  明日から試すプラクティスの候補  まとめ 45

Agile Japan のセッションから学んだこと 「現場が困っていない ＝ 現場が問題を観測できない」 という事象に対して取り組んだ話が多い 困っていなければ問題として観測するのは困難なので 「困ってないけど、より良くする」ための活動が重要 新しいやり方を試す時、完全オリジナルである必要はなく、 世の中で実績のあるプラクティスを試して成功したチームは多い → 明日から試すなら実績のあるプラクティス！ 46

世の中で実績のあるプラクティスを試す方法 「困ってないけど、より良くする」ために、実績のあるプラクティスを 何かを試したいけど、それを調べる時間がない時は・・・ 実績のあるプラクティスの中で、私がやって効果があったものの やり方と効果の紹介記事がある Software Design というIT月刊誌の 連載記事なので読みやすいはず (全39回) Web公開版のリンクはこちら 47

• https://note.com/kojimadev/m/me68d438e12d4

その中でも一推しの生産性の上がる3つを紹介 1. 朝会での目標宣言 2. タスク着手時に進め方を検討して明文化 3. 日中は分報で開発状況を実況 これは「メンバーの活動をめっちゃ透明化する」手法 フィードバック文化を醸成するためにも透明化は必要 私の前職と次世代給与Bチームで生産性1.5倍、 次世代商取引チームなど弥生の複数チームで改善効果あり、超オススメ 48

1. 朝会での目標宣言 － やり方 • 朝会で各自が今日の目標を宣言して Slack に投稿 • デイリースクラムで「今日やること」を報告することに近いが ポイントは「どこまで進めるつもりなのか」をしっかり宣言すること • 帰る前に目標に対する実績を Slack で報告する 目標宣言用スレッドに 各自が朝会の開始までに 目標を投稿した時の例 メンバーA(memberA) 49

1. 朝会での目標宣言 － メリット • • • • 目標を宣言して達成を目指すことによるパフォーマンス向上(目標設定理論) 目標達成すると、達成感が得られる 他メンバーから助言をもらいやすい 全員がチーム全体の進捗をより強く共有できる 帰る前に目標に対する実績を Slack で報告する時の例 達成すると皆が祝ってくれて 達成感も増加 メンバー A(memberA) メンバーA(member) 50

2. タスク着手時に進め方を検討して明文化 タスク着手時に、そのタスクのレビュアーと一緒に 「どう進めるか」を決めて、タスクのチケット(Jiraなど)に書き残す メリットは以下 • タスクの進め方を熟練者と事前に相談しないことで 非効率な進め方になってしまうことを回避 • 途中段階でのレビューや相談するポイントを事前に決めておくことで 成果をすべて作り切ってからレビューすることによる大きな手戻りを回避 • タスクの進め方が透明化されることで、他のメンバ－からのフィードバック も受けやすくなる(先にこっちをやるとか、ここはペアプロした方が良いとか) 51

2. タスク着手時に進め方を検討して明文化の具体例 不具合修正のチケットを、レビュアーと検討して進め方を記入した例 検討時に具体的な 修正方針を 赤枠部分のように 追記してから 着手することで 手戻り防止 52

3. 日中は分報で開発状況を実況 作業中は、自分の分報チャンネルで 「いま何の作業を進めているか」「どう進めているか」を実況しながら進める 各自の作業状況が透明化されることで、他メンバーの助言により 早く課題が解消される(分報のやり方の詳細はこちら) 各自の状況を実況することで 助言し合うなどの コラボレーションが促進 53

• https://note.com/kojimadev/n/n1a9f5364c630

3. 分報の活用例 AIへのプロンプトと結果を公開したら、熟練者から助言をもらった例(こちら) プロンプトと結果を見て どう判断したかを記載 レビュアーは意図した方針で 作業を進めているか確認できる 意図しない方針の場合は 助言して作業方針を随時修正 することで手戻りを削減 全員の分報を見る必要はないが レビュアーはレビュイーの 分報を見て助言した方が 生産性アップの効果が高い 54

• https://yayoi-kk.slack.com/archives/C091G1U45FB/p1761289712908149

透明化の仕組みを試す上での注意点 チーム全員がトップレベルのエンジニア集団の場合、 透明化の仕組みを入れても生産性アップに繋がらない可能性あり 「超優秀なエンジニア」は、各自の活動を仕組みで透明化しなくても 必要な報告や相談をして成果も出す (例) 安野さんに永田町エンジニアチームの透明化のレベルを質問したところ 「透明化はできていない」とのことだったがチームは成果を出している 逆に、ジュニアレベルを含むチームの場合は、透明化の仕組みを入れた方が ほぼ間違いなくメンバーの生産性が底上げされる 論理的には、熟練者とジュニアレベルのメンバーの生産性の差が必ず縮まる 55

Agenda  はじめに  各セッションのポイント(13件)  明日から試すプラクティスの候補  まとめ 56

本発表のゴールを達成したか確認 本発表のゴール  参加者全員が、明日から試してみるプラクティスを 1件以上持ち帰ること 達成できた人は、Slackの本発表用スレッドに その旨を投稿してもらえると嬉しいです 試してうまくいかなかったら、やめればOKです！ 57

最後に 私は6月入社なので、自分のチーム以外の開発のやり方をあまり知りません 勉強のために、チームの会議をちょっと見学させてもらえると嬉しいです (例：朝会やふりかえりなど) 見学歓迎だよ、という人はSlackの本発表用スレッドにその旨を書いてもらうか DM送ってくれると嬉しいです なお、アドバイスしたいとか、そんなおこがましいことは考えておりません 勉強させていただければ幸いです 少なくとも、そのチームのやり方の素晴らしい点を言語化することはできます (言語化できれば、再現性を維持しやすいですし、他チームも参考にできます) あと、Skackのスレッド元のリンクからアンケート回答してくれると嬉しいです 58

おまけ：カンファレンスに現地参加する意義 (1/2) Ｑ. カンファレンスの録画が公開されるなら、 わざわざ現地参加しなくても、あとで録画を観ても同じでは？ Ａ. 同じではないです。学びの密度が下がります 59

おまけ：カンファレンスに現地参加する意義 (2/2) 後日に録画を観るのでは、以下の熱量を持った取り組みができず、学びの量が低下 逆に、これらのメリットを活かさないと、現地参加する意義が小さい 1. 学びを加速させるにはセッションに質問した方がよいが、現地じゃないと 双方向コミュニケーションの質問ができない（場合がある） 2. セッションの合間に発表者を捕まえて質問するのも、イベント後の懇談会で 発表者に質問するのも現地でなければできない 3. 学んだことを言語化して発信した方が脳科学的に学びが加速されるので、 当日にXで学びをポストした方がよい。その方が他の人への刺激にもなるし、 フィードバックも得られる 4. 参加レポートの記事を書きながら参加してイベント終了直後に投稿することを 目標にした方が密度濃く学べる 5. イベント後の懇談会で、知らない人に話しかけまくることで、 リアルな現場の知見が手に入る 6. 現地で歩いていると、「記事を読んで参考にさせてもらいました」 「小島さんが開催したイベントで初めての社外発表させてもらいました」など 声をかけてもらって情報交換するというエモい体験が起きる 60