モブプログラミング再入門 ー 基本から見直す、AI時代のチーム開発の選択肢 ー / A Re-introduction of Mob Programming

Scrum Fest Fukuoka 2026で登壇したときのスライドです。
https://confengine.com/conferences/scrum-fest-fukuoka-2026/proposal/49698/ai

■セッション概要
本セッションは、これからモブプログラミングを始めたい方や、過去に試してうまくいかなかった方に向けたビギナー向けセッションです。
モブプログラミングの基本的な考え方や目的をあらためて整理したうえで、AIによるコード生成や支援が当たり前になりつつある今、なぜモブプログラミングが再評価されているのかを解説します。

モブプログラミングとは、チーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピューターを使って行う開発のやり方です。

モブプログラミングは2017年頃から日本においても取り組むチームが増えはじめました。
また、COVID-19をきっかけにリモートワークやハイブリッドワークが広がる中で、チーム開発の進め方やコミュニケーションを見直す手段として再び注目され、ワークショップ的に取り入れるチームや、日常的な開発スタイルとして採用するチームも現れました。

一方で、生産性への不安などから
「何度か試してみたがやめてしまった」
「うまく運用できなかった」
というチームも少なくなく、必ずしも広く定着したとは言えないのが現状です。

私は2017年頃からチームでモブプログラミングに取り組みはじめ、その実践経験をもとに、コミュニティでの登壇や書籍での解説、アジャイルコーチとしての導入支援やコーチングを行ってきました。

その中で強く感じているのは、モブプログラミングの本質は「全員でコードを書くこと」ではなく、チームの学習と意思決定をどのように行うかにあるということです。

そして現在、AIによるコード生成や開発支援が急速に普及し、開発における「個人作業」はこれまで以上に加速しています。その一方で、チームとしての理解、判断、合意形成の重要性は、むしろ高まっていると感じています。

本セッションでは、モブプログラミングをあらためて基礎から整理したうえで、

モブプログラミングは何を解決しようとしているのか

なぜ誤解されやすく、定着しにくいのか

AI時代において、どのような価値が再評価されているのか

について、これまでの実践経験と現在の開発環境の変化を踏まえて解説します。

「過去に試したがうまくいかなかった方」
「名前は知っているが、まだ実践したことがない方」

どちらにも向けた、今あらためて考えるためのモブプログラミング入門セッションです。

■作者
フィードバックやお問い合わせはこちらまで！
https://agile-monster.com/profile/
https://agile-monster.com/contact/
https://x.com/TAKAKING22

Avatar for TAKAKING22

Transcript

1. モブプログラミング再入門 ー 基本から見直す、AI時代のチーム開発の選択肢 ー 及部敬雄 (@TAKAKING22) 2026/03/07 Scrum Fest Fukuoka 2026 1
2. 何が変わった？ 2 2021年のソフトウェア開発 2026年のソフトウェア開発
3. 何が変わった？ 3 2021年のソフトウェア開発 2026年のソフトウェア開発 プログラムを書いている プロンプトを書いている ※プロンプト=AIへの指示
4. ソフトウェア開発におけるAI活用は前提となった
5. AIによってはやく作れるようになった
6. 現場で起きていること レビュー負荷が増えた 分担作業が増えて人間とのコミュニケーションが減った 属人化が加速してしまっている 理解が追いつかなくなってきている 6
7. AIによってはやく作れるようになった でもそのスピードに追いつくことに必死
8. ソフトウェア開発、楽しんでますか？
9. ソフトウェア開発が楽しくなくなってない？
10. モブプログラミング再入門 ー AI時代のチーム設計 ー 及部敬雄 (@TAKAKING22) 2026/03/07 Scrum Fest Fukuoka 2026 10
11. 11 TAKAKING22 及部敬雄 制御不能なアジャイルモンスター 株式会社ホロラボ 執行役員 AGILE-MONSTER.COM アジャイルコーチ 最近ハマっているもの：No No Girls
12. We shapes our tools, and thereafter our tools shape us. 私たちは道具を形作り、その後、道具が私たちを形作る - マーシャル・マクルーハン -
13. 道具と人 道具によって人間の生活や活動が変わった例 印刷技術：思想や情報が大量複製され、不特性多数に同時に届くメディアが生まれた 蒸気機関：機械動力による大量生産が可能になり、工場制産業が成立した インターネット：情報と人が即時につながる地理的制約のほぼない社会を生んだ AI：？？？ AI（道具）を使って何をするのかだけでなく、
 AI（道具）を使う私たち（人間）はどうあるべきかを考えたい 13
14. 最近感じていること 確かにAIではやく作れるようになった 人間やチームは変化に追いつくことに必死になってしまっている 結果としてソフトウェア開発を楽しめなくなっているのではないか ボトルネックは人間やチーム 人間やチームの理解をどうつくっていくのか AIを使う私たちはどうなっていればよいのか 14
15. 過去、「チーム」について衝撃を受けたもの 15 スクラム モブプログラミング
16. 今日のお話 今日のお話は、AI時代のソフトウェア開発において、 「ボトルネックが理解に移った」という前提から始めます。 AIは作る速度を上げましたが、理解する速度は上げていません。 だからこそ、理解を深め、共有し、より良い問いを作るための チーム設計が必要になります。 そこでモブプログラミングを「理解を作る構造」として再入門 し、AI時代のチームのあり方について考えます。 16
17. 17 AI モブプログラミング AI時代のチーム
18. ソフトウェア開発の楽しさを改めて認知する
19. アジェンダ AI時代のソフトウェア開発 モブプログラミング再入門 AI時代のモブプログラミング まとめ 
20. AIとソフトウェア開発の現在 90%が仕事でAIを活用している 主な利用用途は、新規コーディング、既存コード 修正、レビュー、ドキュメント生成、テストケー ス生成など 「作業支援」から「伴走」or「委託」へ 20 “State of AI-assisted Software Development 2025” by Google
21. AIとソフトウェア開発の現在 AI活用による効果は、個人レベルでは高い 一方で組織レベルではそれほど高くない ソフトウェアデリバリーのスループットは2024年 はマイナスだったが微増に転じた ソフトウェアデリバリーの不安定性は昨年より増加 個人レベルでのAI活用は進んでいるが、
 チームや組織が追いついていない 21 “State of AI-assisted Software Development 2025” by Google 人間がボトルネックになっていてAIの性能を活かしきれていない
22. 最近よく聞くチームが抱える問題 レビュー負荷 認知不可 技術的負債 属人化 メンバー育成 ドキュメンテーション 22
23. 当初想定していたBefore/After 23 Before AI After AI AIによって作業が効率化され リードタイムが短くなる プロンプト
24. 実際に直面しているBefore/After 24 Before AI After AI 結果としてリードタイムは それほど変わっていない あらかじめ仕様理解や設計を十分に行い AIに指示をする必要 AIからのアウトプットを担当者もレビューし その結果をチームでレビューする 仕様理解や設計はほどほどに つくりながら足りないものを埋めていることが多かった プロンプト
25. SECIモデル 共同化 表出化 内面化 結合化 暗黙知 形式知 形式知 暗黙知 暗黙知（言葉になっていない知）と 形式知（言葉にされた知）の 相互変換がスパイラルアップしていく ことが知識の創造過程である Socialization Externalization Internalization Combination
26. SECIモデル 共同化 表出化 内面化 結合化 暗黙知 形式知 形式知 暗黙知 暗黙知（言葉になっていない知）と 形式知（言葉にされた知）の 相互変換がスパイラルアップしていく ことが知識の創造過程である Socialization Externalization Internalization Combination デイリースクラム ペアプログラミング モブプログラミング ユーザー観察 雑談／対話／共通体験 スプリントレビュー スプリントレトロスペクティブ インセプションデッキ ユーザーストーリーマッピング プロダクトバックログ化 設計 スプリント全体 スプリントプランニング リファインメント 開発 テスト ドキュメンテーション
27. SECIモデル 共同化 表出化 内面化 結合化 暗黙知 形式知 形式知 暗黙知 暗黙知（言葉になっていない知）と 形式知（言葉にされた知）の 相互変換がスパイラルアップしていく ことが知識の創造過程である Socialization Externalization Internalization Combination デイリースクラム ペアプログラミング モブプログラミング ユーザー観察 雑談／対話／共通体験 スプリントレビュー スプリントレトロスペクティブ インセプションデッキ ユーザーストーリーマッピング プロダクトバックログ化 設計 スプリント全体 スプリントプランニング リファインメント 開発 テスト ドキュメンテーション AIによる代替可能 （現段階では） AIによる代替が困難 AIによる支援可能 AIによる支援可能
28. 実際に直面しているBefore/After 28 Before AI After AI 結果としてリードタイムは それほど変わっていない 仕様理解や設計はほどほどに つくりながら足りないものを埋めていることが多かった あらかじめ仕様理解や設計を十分に行い AIに指示をする必要 AIからのアウトプットを担当者もレビューし その結果をチームでレビューする プロンプト
29. 29 Before AI After AI 結果としてリードタイムは それほど変わっていない 仕様理解や設計はほどほどに つくりながら足りないものを埋めていることが多かった あらかじめ仕様理解や設計を十分に行い AIに指示をする必要 AIからのアウトプットを担当者もレビューし その結果をチームでレビューする プロンプト 人間と人間の知の交換・相互変換によって、 アウトカムを創造していく過程 形式知⇒暗黙知、暗黙知⇒暗黙知、暗黙知⇒形式知 実際に直面しているBefore/After
30. 30 https://agilejourney.uzabase.com/entry/2025/08/29/103000
31. 最近よく聞くチームが抱える問題 レビュー負荷 認知不可 技術的負債 属人化 メンバー育成 ドキュメンテーション 31 これらはBefore AIの頃から、
 問題になりやすかったこと AIによって生まれた新しい問題ではない AIによって作業が効率化されたことで、 ボトルネック化しやすくなった
32. Photo by Its me Pravin on Unsplash AIは増幅器として機能する。 高いパフォーマンスの組織の強みを拡大し、
 課題を抱えている組織の機能不全も拡大する。 - State of AI-assisted SoftwareDevelopment 2025 -
33. アジェンダ AI時代のソフトウェア開発 モブプログラミング再入門 AI時代のモブプログラミング まとめ 
36. モブプログラミングとは 36 チーム全員で ・同じ仕事を .. ・同じ時間に .. ・同じ空間で .. ・同じ環境で .. すること オフライン／オンラインに 関わらず同じ空間で 技術やツールの進化によって 必ずしも同じマシンでなくとも 同じ環境を共有できるようになった
37. モブプログラミングの登場人物 37
38. モブプログラミングの進め方 ドライバー（キーボードをたたく人）とナビゲーター その場にいる全員で会話をして考えて判断をする 合意したことをドライバーが代表してアウトプットする ドライバーを任意のタイミングで交代しながら仕事を進めていく 任意のタイミング：15分ごとに交代、タスクごとに交代、好きなときに交代など 38
39. モブプログラミングのイメージ 39 作業 見る 見る 見る ਖ਼͍͠Πϝʔδ ナビゲーター ナビゲーター ナビゲーター ドライバー アウトプット ナビゲーター ナビゲーター ナビゲーター よくある誤解 インプット インプット インプット モブプロのイメージ ドライバー
40. モブ「プログラミング」？ モビングでプログラミングをする = モブプログラミング エンジニアの仕事の内、プログラミングは一部に過ぎない 複数人でも同じ目的のもとにチームで協力して成果を出す場面であれば、
 モビングを活用することができる 「モビング」や「モブワーク」と呼ぶこともある 40
41. Photo by rawpixel on Unsplash Photo by Marvin Meyer on Unsplash VS 分担作業 モブプログラミング
42. 分担作業 ex. レビュー、承認、引き継ぎ.. ex. タスク分割、設計、キックオフ.. 分担作業の前後に 同期する作業が必要になる
43. ミスコミュニケーションによって 手戻りする可能性もある 分担作業
44. モブプログラミング ex. 設計、レビュー、ノウハウ共有 同期しないではなく、 常に同期している
45. モブプログラミングの特徴 モブプログラミングはリアルタイムレビュー アウトプット（結果）だけでなく、プロセスも含めてリアルタイムにレビューをする チームの特定の誰かではなく、参加しているチーム全員が合意している状態で仕事が進む モブプログラミングはフロー効率（仕事が流れること）を重視する モブプログラミングは究極の一個流し モブプログラミングが出そうとする生産性は、
 アウトプット（仕事量）ではなくアウトカム（生まれた価値） モブプログラミングは教育効果が高い 知識のジャストインタム（必要なときに必要な知識がインプットされる） チーム全員同席で学ぶ 45
46. 分担作業とモブプログラミング 分担作業 モブプログラミング イメージ 特徴 リソース効率重視 フロー効率重視 生産性 チーム全体で見たときに 生産される量が多い チームとして完成したものだけ が確実に生産されていく 問題解決 個人の経験知に依存する チーム全員の経験知に依存する 学習 個人に貯まる チームに貯まる 向いている仕事の質 単純作業 他者への依存度が低い仕事 問題解決をする仕事 得られた学習が重要な仕事
47. Photo by rawpixel on Unsplash Photo by Marvin Meyer on Unsplash 分担作業 モブプログラミング 仕事の質やチームの状況に合わせて 使い分けられる方がチームとして強い
48. モブプログラミングの近況（私調べ） 2017年ʙ　日本におけるモブプログラミング普及期 2020年ʙɹオンラインモブプログラミングが流行する COVID-19の影響で急速にリモートワーク化 コミュニケーションの問題解決を理由としたオンラインモブプログラミングの導入増加 2026年現在のモブプログラミング モブプログラミングを知っている／やったことがある人は一定数いる モブプログラミングを継続してやり続けているチームは少ない 継続していても限定的か必要に応じてやっていることが多く、
 モブプログラミング中心で仕事をしているチームはさらに少ない 48
49. アジェンダ AI時代のソフトウェア開発 モブプログラミング再入門 AI時代のモブプログラミング まとめ 
50. AI時代のチーム チームの小規模化 2から３人チームが最適に クロスファンクショナルチーム 技術領域による分担（ex.フロントエンド／バックエンド）をしない 隣接技術領域もAIの支援を受けて対応しやすくなった 50
51. AI時代のチーム チームの小規模化 2から３人チームが最適に クロスファンクショナルチーム 技術領域による分担（ex.フロントエンド／バックエンド）をしない 隣接技術領域もAIの支援を受けて対応しやすくなった 51 小さなチームであれば生産性をそれほど気にしなくてもよくなり、 さらにチームで完結できる仕事が増えることで、 モブプログラミングがしやすい条件が整ってきている
52. 最近よく聞くチームが抱える問題 レビュー負荷 認知不可 技術的負債 属人化 メンバー育成 ドキュメンテーション 52 これらの問題は モブプログラミングは効果的に作用する
53. AI時代のモブプログラミング 53 Before AIの モブプログラミング After AIの モブプログラミング プロンプト 会話を繰り返しながら 仕様や設計を形式知化し、 プロンプトを作成する AIからのアウトプットを 複数の目でレビューする
54. 仕事の中心が「開発」から「理解する」へ
55. モブプログラミングは理解を作る構造 「個人」ではなく「チーム」で理解をする 仕事の進め方（分担作業 or モブプログラミング）によらず必要なこと つくったものを見て共有するのではなく、
 一緒に仕事をすることで暗黙知も形式氏もまとめて共有する “三人寄れば文殊の知恵” 55
56. モブプログラミングとSECIモデル ソフトウェア開発における暗黙知になりやすい部分 アウトプットの読み方や使い方 アウトプットに至るまでの議論の内容 ツールやショートカットの使い方 コードの組み立て方 問題の発見のしかたと問題解決のプロセス 大変だったところはどこなのか ソフトウェア開発における暗黙知の価値はとても高い 56
57. SECIモデル 共同化 表出化 内面化 結合化 暗黙知 形式知 形式知 暗黙知 Socialization Externalization Internalization Combination モブプログラミングが 効果的なところ
58. 私たちの組織のモブプログラミング 小さなチーム（3人）×2チーム チームで自分たちの開発プロセスを定義して実行する チームA：コアタイムを決めてモブプログラミング（10:00-17:00） チームB：必要に応じて時間で区切ってモブプログラミング（平均すると1日2、3時間） 各チームから出てきた感想 モブプログラミングを再開するときに不安だったが、むしろ生産性が上がった いかにコミュニケーションが足りていないかがわかった “空いた時間を何にするのか”を考えることが増えた 58
59. AI時代のモブプログラミング 59 Before AIの モブプログラミング After AIの モブプログラミング プロンプト 会話を繰り返しながら 仕様や設計を形式知化し、 プロンプトを作成する AIからのアウトプットを 複数の目でレビューする 空いた時間 空いた時間
60. 空いた時間を何に投資するのか Photo by Towfiqu barbhuiya on Unsplash
61. SECIモデル 共同化 表出化 内面化 結合化 暗黙知 形式知 形式知 暗黙知 Socialization Externalization Internalization Combination AIが効果的なところ モブプログラミングが 効果的なところ
62. AI＋人間のチーム 62 人間： 共同化を活動の中心にし、暗黙知を集め、 チームの理解を深めていくことで より深い問いを形式知に変換していく ※効果的な選択肢の一つがモブプログラミング AI： 形式知から先はAIの代替・支援が受けられる ただし投げかけられる問い（プロンプト）によって アウトプットの質が決まる ✘
63. 空いた時間を何に投資するのか AIによって作業効率が上がったからといって、
 どんどん機能を追加したり、開発スピードを上げることに固執しない アウトプットではなくアウトカムを上げることを考えたときに、
 なにをするとよいのかを考えてそこに時間を投資する 「チームで空いた時間を何に投資するのか考えて判断して実行する」
 これこそが空いた時間にやること（混乱） 63
64. 余談：マネージャー視点のモブプログラミング 私たちが変化をするときのボトルネックになりやすいことを自覚する 私たち ＝ 経営者、ミドルマネージャー 一方で、私たちが変化を支援する側にまわることができれば、
 チームや組織の変化を加速させることができる マネージャーにとって必要なケイパビリティはチームを支援する力 チームをコーチングする チームの変化を妨げるものを取り除く チームの変化を促進させる チームの生産性を疑うのではなく、支える 64
65. アジェンダ AI時代のソフトウェア開発 モブプログラミング再入門 AI時代のモブプログラミング まとめ 
66. 今日のお話 今日のお話は、AI時代のソフトウェア開発において、 「ボトルネックが理解に移った」という前提から始めます。 AIは作る速度を上げましたが、理解する速度は上げていません。 だからこそ、理解を深め、共有し、より良い問いを作るための チーム設計が必要になります。 そこでモブプログラミングを「理解を作る構造」として再入門 し、AI時代のチームのあり方について考えます。 66
67. ソフトウェア開発、楽しんでますか？
68. AI時代のソフトウェア開発 AIによってソフトウェア開発の変化はとてもはやくなっている その変化のスピードに追いつくことに必死になってソフトウェア開発の楽 しさを、チーム開発の楽しさを忘れていないか AI時代に入って多くのチームが直面している問題は、実はこれまでも立ち 向かっていた問題とそれほど変わっていない やらなければいけないことは変わっていないし、
 ソフトウェア開発の楽しさは変わっていない ほら、問題の解像度が高くなると気が楽になるでしょう？ 68
69. ソフトウェア開発って楽しいよね
70. @TAKAKING22 及部 敬雄 https://agile-monster.com/ 一緒に取り組んでいきましょう！ 現役のアジャイル開発実践者による アジャイルコーチ お仕事のご相談も雑談もぜひお気軽にお声がけ下さい！
71. 参考文献 モブプログラミング・ベストプラクティス（書籍） A day of Mob Programming（YouTube動画） A day of Mob Programming 2016（YouTube動画） AI時代のアジャイルチームを目指して ー スクラムというコンフォートゾーン からの脱却 ー（スライド） モブプログラミングで「一緒に働く」を戦略的に仕事に取り入れよう（記事） 71