Claude Code と進める少人数モブプログラミング

1. Claude Code と進める 少人数モブプログラミング ひとり開発・少人数開発で全部やったエンジニア LT 会 虎の穴ラボ株式会社　吉田一貴
2. よしだ 𝕏：@da_yoshi_k 使っている技術 現職：Ruby, Ruby on Rails, React, Google Cloud 前職：Java, RPA(UiPath) 経歴 2023年5月〜　虎の穴ラボ株式会社 現在自分のいるチームでは少人数（エンジニア5人）で フルリモート開発中 2018年4月〜　SI系のSES(PjM半分・開発半分) ←(New)最近Astroで自己紹介リンクページを作りました 　　　　
3. AIは増幅する（ちょっとしたズレも高速に） • コーディングエージェントによって、少人数のエンジニアでも文字通り人間離れ したアウトプット量は出せるようになった。 • ただ、「AIは知識の代替ではなく増幅器」と言われるように、少しでもメンバー 間で認識に相違があるまま進むとそのまま大きな溝になる。 • 仮説検証フェーズであり、仕様駆動開発 と言っても仕様も設計も正解がわからない 状態。（ここは状況に依る） 引用）AI時代のソフトウェア開発を考える（2025/07版） https://speakerdeck.com/twada/agentic-software-engineering-findy-2025-07-edition?slide=35
4. Claude Code＋人間ペアの「少人数モブ」 • 人間2人とClaude Code（planモード）で、 常に同期しながら進める少人数モブを昨年末 から複数回実施。 • 正解が分からない状況なので、分担より同期 を選んでいる。 引用）モブプログラミングで「一緒に働く」を戦略的に仕事に取り入れよう https://agilejourney.uzabase.com/entry/2022/09/27/103000 AIを使うと巨大な分業 タスクになりがち
5. • 要件や設計が確定しない前提で進める場合でも、Claude Codeのplanモードを活 用する。 ◦ 認識合わせを高速に回し、ズレを早く露出させてPlanを直す。 ◦ Planをその時点の最良の合意を言語化したものとして使う。 • Googleドキュメントにスナップショットとして残す。 設計を固める代わりに合意を言語化する
6. • 実装時は--dangerously-skip-permissions、通称YOLOモードは使わず、ペアと 実装内容の確認を都度行っている（個人の好み） • 実装中・動作確認時のフィードバックは、Planと違っても積極的に取り入れる。 ◦ 常に学びつつ最良をモブで探索していく。 ◦ 早期の計画づくりと探索で、レビュー時の悪い驚きは体感減少している。 • ただ、最終的な意思決定をどのように残していくかは課題感がある。 ◦ 本当は残した方がいいと思いつつ、先に進めることを優先してしまいがち。 実装の進め方と、Planとズレた時どう扱うか（課題）
7. • 「エキスパートがいるモビング（右書籍4.1章）」では以下の ような問題があると記載がある。 > エキスパートをタイピストに据えると、問題は瞬時に解決され、 > ほかのメンバーはただそれを見てうなずくだけになってしまう • コーディングエージェントや経験のあるエンジニアがゴリゴリ と進め、他のメンバーが理解していない状態は避ける。 • その他導入・利点・よくある問題も書かれているので右の書籍 はおすすめ！ (時間があったら補足)モブをする上での注意点 引用）モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める https://bookplus.nikkei.com/atcl/catalog/19/P89640/
8. Thanks!! 個人・少人数開発での泥臭話を 交流会で聞かせてください！ 会社HPも見てね https://toranoana-lab.co.jp/