こんにちは。SmartHRプロダクトエンジニアの Kenta です。
普段は従業員マスタCというチームで開発をしていますが、2026年2月から一時的に従業員マスタBチームに合流しています。このチームには毎日モブプログラミング（以下、モブプロ）で実装を進めるという文化がありました。
「毎日2〜3時間って結構がっつりだな…」と最初は思いましたが、約2ヶ月間参加してみると、想像以上に学びの多い体験でした。この記事では、別チームのモブプロに飛び込んだ立場から、振り返りの仕組みや集合知の威力について紹介します。また、今エンジニアの間で最もホットなAIツールの一つである Claude Code をモブプロにどう組み込んでいるか についても書いていますので、ぜひ最後まで読んでみてください。
従業員マスタBチームのモブプロの進め方
まず、チームのモブプロがどんな形で運営されているかを紹介します。
基本ルール
- 毎日2〜3時間のモブプロセッションを実施
- ドライバー（コードを書く人）は1人15分で交代。順番はGAS（Google Apps Script）でランダムに決定
- 参加人数は日によって変わりますが、4〜6人程度
- ツールはGoogle Meetを使用
- チームにはNotionの「モブプログラミングの手引き」があり、新メンバーにも共有される
取り組んだ内容
私が参加していた期間では、具体的に以下のような作業をモブプロとしてやりました。
- DB設計の議論やカラム名・enum名の命名
- 画面のUI実装
- テスト（System spec・Request spec）の追加・修正
- 公開APIの実装
これらを1つのPRとして進めるのではなく、「毎日マージするくらいの気持ちで小さいPRにする」という方針で取り組んでいました。
モブプロの後には毎回振り返り ── シンキングハット法
このチームのモブプロで特に印象的だったのが、毎回のセッション後に行う振り返りです。
振り返りの手法は『モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める』を参考にして、シンキングハット法を取り入れています。エドワード・デ・ボノが提唱した思考法で、異なる「帽子」をかぶることで、意識的に思考の切り替えを行うものです。これをチーム独自のNotionドキュメント「モブプログラミングの手引き」に整備し、以下の5ステップで進めています。
| ステップ | 時間 | 内容 |
|---|---|---|
| 事実と数字 | 2分 | 事実だけを述べる（形容詞を使わないように注意） |
| 肯定的感想 | 3分 | モブプロセッションに対する肯定的感想 |
| 否定的感想 | 3分 | 批判的な評価、どこに不満を感じたか |
| 建設的な問題解決法 | 5分 | 批判的感想をどうすれば改善できるか |
| 軌道修正すべきことの決定 | 3分 | 建設的な問題解決法の中から1つだけ選び次回に試してみる |
なぜシンキングハット法がうまくワークするのか
実際に2ヶ月ほど体験して感じたのは、この振り返りが「感想で終わらない仕組み」になっている点です。
たとえば、「事実と数字」では「3時間やった」「2ローテーションいかないくらい」「PRを1つ作成した」のように、事実だけを淡々と述べます。ここで形容詞を使わないというルールがあるので、「長かった」「大変だった」は出てきません。感情は次のステップで分離して扱います。
肯定と否定を明確に分けるのも大事なポイントです。「迷ったらすぐに皆で相談できて捗る」「環境構築も爆速で直せた」といった肯定的な面をきちんと言語化した上で、「休憩のタイミングがむずい」「ローカル環境が壊れていてもったいなかった」という否定的な面を出します。
そして最後に「1つだけ選んで次回試す」というルールがあるおかげで、改善策が具体的なアクションに落ちていきます。「あれもこれも」ではなく、1つに絞ることで確実に試せるのです。
振り返りで実際に改善されたこと
シンキングハット法による振り返りを繰り返す中で、実際にチームのモブプロは目に見えて改善されていきました。いくつか具体例を紹介します。
休憩の設計
初期は「休憩のタイミングがむずい」という声が出ていました。その後「3時間しんどかった」という声を経て、「40分刻みで10分休憩」というルールや、各々好きなタイミングで休憩を取るというルールが合意されました。感覚的な「なんとなく疲れた」が、振り返りを通じて具体的なルールに変換されていく過程を見られたのは面白かったです。
コミット整理問題
モブプロではドライバーを交代するたびにコミットするため、作業途中の細かいコミットが大量に生まれます。加えて、リモートブランチの取り込み方法（pullかrebaseか）がメンバー間で統一されておらず、PRを出す前にコミットを整理しようとすると想定以上に時間がかかってしまいました。振り返りで「コミットの整理に時間がかかりすぎてもったいない」と挙がり、改善策として「stagingを取り込む時は git pull --rebase を使う」「手順をモブプロの手引きに書いて標準化する」が合意されました。次のセッションからはこの運用に切り替わり、同じ問題は発生しなくなりました。
途中参加・離脱の文脈共有
私自身が感じた課題として「モブプロに途中で出入りすると、どこまでモブプロでやったのか見えづらい」というものがありました。これを振り返りで共有したところ、「振り返り前にスレに簡単にメモを残す」という改善策が生まれました。
こうした小さな改善が毎日積み重なっていくことで、モブプロの進め方自体がどんどん洗練されていく感覚がありました。
モブプロで得た3つの気づき
迷いが消える
普段の開発では「この実装方針で合ってるかな」「命名これでいいかな」と迷う場面がありますが、モブプロではその場で即座に議論できます。
たとえば、あるカラムの命名を決めるとき、「この名前だと意味が曖昧では？」「こっちの方が既存の規則に沿っている」といった案がリアルタイムで出て、その場でプロダクト要求仕様書（PRD）も更新しました。1人で悩んでいたら数時間かかりそうなことが、モブプロでは数十分で着地します。
集合知でボトルネックを突破する
印象的だったエピソードがあります。テストが落ちていて、最初は「権限の設定が原因だろう」と全員が思っていました。しかし調べていくうちに、実はHTMLの label と input の紐付けが不足していて、テストフレームワークが要素を拾えていないだけだった、ということが判明しました。
1人で調査していたら「権限」という仮説に引きずられて時間がかかっていたと思います。複数人の目で「エラーの内容 → 対象ファイル → DOM構造」と視点を切り替えながら原因を特定できたのは、まさに集合知の威力でした。
チームの文化を体感できる
別チームに合流した立場だからこそ感じたのですが、モブプロはそのチームがどう働いているかを最も早く理解できる手段だと思います。
コードベースの全体像、PRの出し方、レビューの基準、命名規則、テストの書き方──これらを1人でドキュメントを読んで把握するのは大変ですが、モブプロで一緒にコードを書いていると自然と身についていきます。
初回のモブプロの感想として「雰囲気めちゃよかったです。慣れるように頑張ります！」とSlackに書いたのですが、そんなことを書いたのを忘れてしまうくらいすぐに慣れました。
モブプロ × Claude Code ── AIはチームメンバーになれるか
このチームでは、モブプロの中でClaude Codeを積極的に活用しています。具体的な使い方と試行錯誤の過程を紹介します。
Devinから始まり、Claude Codeに落ち着いた
当初はDevinにPR作成を任せていましたが、振り返りで「レスポンスが遅くてモブプロの流れが止まる」という否定的感想が出ました。改善策として「Claude Codeの方が速いのでは」という提案があり、実際に試してみたところモブプロとの相性が良く、チームに定着していきました。
PRコードフロー解説ドキュメントの自動生成
開発しているアプリケーション自体が大きく複雑なため、PRの変更がコードベース全体にどう影響するかをレビュアーが把握しづらいという課題がありました。ソースコードや仕様に精通したメンバーが限られている中で、「なぜこう変更したのか」「周辺の機能はどう動いているのか」を理解した上で自信を持ってレビューするのが難しかったのです。
そこで試したのが、PRの差分と周辺コードをClaude Codeに渡して、コミット単位でコードフローの解説ドキュメントを生成するというワークフローです。
- コミットを機能単位で分けておく
- Claude Codeに差分と周辺コードを渡し、コミット単位で解説を生成させる
- 出力されたドキュメントをNotionに保存する
- モブプロの冒頭で各自15分の黙読タイムを設け、気になる点があれば全体で読み合わせる
- その後、PRのコードレビューに入る
初回の振り返りでは「めちゃくちゃわかりやすくて良かった」「Reactの実装やinternal APIの流れが分かって勉強になった」という声があった一方、「ドキュメントをどこまで読むかの塩梅がまだわからない」「生成に時間がかかる」という課題も出ました。これも振り返りを通じて「PRが既にあるなら事前に生成しておく」といった改善策が合意され、運用が徐々に洗練されていっています。
実装のPlan作成
モブプロの冒頭で「今日のゴール」を決めた後、Claude Codeに実装のPlanを作ってもらうこともあります。AIが出したPlanをモブプロのメンバー全員で確認し、方針を議論してから実装に入ることで、ドライバーが迷わず進められるようになりました。
正直、課題もある
Claude Codeにタスクを任せている間、レスポンスを待つ時間が発生します。この待ち時間にモブプロの手が止まってしまうのは課題でした。対策として、待っている間に次のプロンプトを考えたり、実装した部分の周辺コードを読んで理解を深めたりと、受け身にならない過ごし方を意識するようにしています。
AIは「もう一人のチームメンバー」とまでは言えませんが、面倒な作業を引き受けてくれる頼もしいアシスタントとして、モブプロの生産性を確実に上げてくれています。
番外編：Notion AIで振り返りを分析する
Claude Codeとは別に、Notion AIも活用しています。チームではモブプロの手引きや議事録をNotionで管理しているため、振り返りの分析結果もそのままNotionに蓄積できるNotion AIが適していました。数日分のモブプロの振り返りSlackスレッド（4スレッド分）をまとめて、「モブプログラミングで行ったことやどのように変化していったか、更なる改善点を分析してまとめて」というプロンプトでNotion AIに投げてみました。すると、「実装相談中心だったモブが、PRを通すための総合戦に変化している」「振り返りの型が定着し、改善が具体化している」といった、モブプロの成熟過程が可視化されました。
モブプロの実装にはClaude Code、振り返りの分析にはNotion AIと、場面に応じてAIを使い分けることで、モブプロの改善サイクルがより速く回るようになっています。
おわりに
別チームのモブプロに飛び込んだことで、「モブプログラミングそのもの」だけでなく、「チームがどう学び、どう改善していくか」を間近で体験できました。
特にシンキングハット法による振り返りは、毎日の小さな改善を積み重ねるための強力な仕組みだと感じています。モブプロを導入しているチームも、これから試してみたいチームも、振り返りの型を工夫してみると、モブプロの効果がさらに引き出せるかもしれません。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
