アダコテック技術ブログ

株式会社アダコテックの技術ブログです。

AIベンチャーで実践するモブプログラミングのすゝめ

アダコテックのWebエンジニアの谷口です。

弊社のクラウドサービス開発チームで、この半年間でチーム間の知識共有目的で、モブプログラミングの実践をしました。この記事では、どのような背景でモブプログラミングを導入し、それにより開発生産性にどのような影響があったのかについて、文章にまとめました。

これからチームでモブプログラミングを導入してみたいという方は、ぜひ参考にしていただければ幸いです。

モブプログラミングとは?

モブプログラミングとは、コードを入力するドライバーとコードの入力を指示するナビゲーターに分かれて、複数人で協力して問題を解く開発手法のことを指します。

モブプログラミングの概要を理解するには以下の本がおすすめです。

 

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

https://amzn.asia/d/ddqWoEr

 

 

背景

クラウドサービス開発チームは元々、Reactに知見のあるフロントエンドエンジニアとPythonに知見のあるバックエンドエンジニア2名体制で開発を行なっていました。

少人数の開発体制で、役割分担も明確だったため、技術的にもコミュニケーション的にも特に問題なく開発することができていました。

昨年の秋ごろから、新卒のメンバーやWindowsアプリのエンジニアがクラウド開発チームに異動することになり、これまでの開発ノウハウの共有がチームの最重要課題となります。

日頃から、モブプログラミングの話を頻繁に目にすることもあり、小さいIssueから導入することになりました。

導入

やり方としては、Reactに知見の無い新卒のエンジニアやWindowsアプリのエンジニアにドライバーになってもらい、既存のメンバーがナビゲーターとして開発する内容を指示する形を取りました。

取り組むIssueについては、導入当初は軽い不具合修正から始めました。2~3ヶ月経ってチーム全体がモブプログラミングに慣れてきたら、新機能開発のIssueで実施するようにしました。

各Issueでモブプログラミングを実施した後は、メンバーで振り返りを行い、進め方の改善をしていきました。

【改善策の例】

  • ナビゲーターは一行ずつ細かく指示しない
  • ナビゲーターはドライバーのコーディングの様子をきちんと観察して、詰まりそうな箇所で適切に指示を出す
  • ドライバーは自分がこれから実装しようとしている内容を口に出して共有する

導入してよかったこと

オンボーディングの時間を半強制的に取ることができた

リソースの足りないベンチャー企業では、懇切丁寧に新卒のエンジニアにオンボーディングをすることができないのが実情です。ただ忙しいことを理由に、オンボーディングに時間が割かず、ソースコードレビューで差し戻しが頻繁に発生することになると、チーム全体の負担が結果として増えてしまいます。

そういう意味で「モブプログラミング」というある種の口実で、新規のメンバーのオンボーディングのために知見のあるメンバーが集まるきっかけを作ることができただけでも、大きな成果として実感することができました。

チーム内のコミュニケーションが活性化した

弊社も多分に漏れず、リモートワークでの開発が中心のため、意識しないと個人で黙々と開発することが多くなってしまいます。モブプログラミングを実践すると、協働で作業をすることになるので、自然とチーム内で会話が生まれ、会話の促進にもつながります。

新規メンバーが理解しづらい昔のコードの実装の背景など、「Slackであえて共有するほどではないこと」を、モブプログラミングでは気軽に伝えることができました。

失敗したこと

チーム全体がモブプログラミングが不慣れということもあり、さまざまな失敗をしました。

時間を明確に指定しなかった

初期のころは何となく1時間くらい会議室を取って、延長しそうであれば、そのまま会議室の予約も伸ばして続けてしまいました。こうしてしまうと終わりが見えないので、後半はただ疲れてしまうだけで生産性が上がらなくなってしまいました。

1回のモブプログラミングで実施するスコープを明確にしなかった

特に新機能開発で、開発範囲が多岐にわたるようなIssueに着手した際に陥ってしまったのですが、1回のモブプログラミングで「何をゴールにするのか」を明確にしないと、ナビゲーター同士の議論が白熱してしまい、全然違う箇所の設計や「そもそも論」で時間を費やしてしまいました。

このような議論が続くと、ドライバーが「結局今どうしたらいいのか」が分からず、生産的ではありませんでした。

知識に差がある状態で知見のあるメンバーがドライバーをやってしまった

まだ実装や設計の知識に差がある状態で、知識がある側がドライバーをやってしまうと、ナビゲーターがドライバーのコーディングについていけず、「モブプログラミング」という名のライブコーディング会になってしまいます。

「俺がやったほうが早い」状態の時には、ドライバーに立候補せず、我慢してナビゲーターとして指示を出す側になるほうが、結果としてチーム全体の生産効率に貢献できることを認知できるいいきっかけとなりました。

横展開

クラウドサービスの開発チームで一定の成果が確認できたので、会社全体でモブプログラミングを浸透させるため、開発合宿中にモブプログラミングの体験ワークを開催しました。

techblog.adacotech.co.jp

体験ワークでは、以下のGithubリポジトリを使ってモブプログラミングRPGを行いました。これはモブプログラミングで求められる役割をゲーム形式で担うことで、モブプログラミングに慣れていない人でも積極的に参加することを促すアクティビティになります。

github.com

短時間の体験ワークではありましたが、始めてモブプログラミングを経験したメンバーからは以下のような意見をもらいました。

  • 他のタイピストが使っていたCopilotやCursorなどのAIによるコーディング支援ツールが便利だということに気付けた
  • Pythonに慣れていない人が詰まるところを把握することができた
  • モブプログラミングなら、一人だと見落としがちなところをカバーできそう

まとめ

モブプログラミングは、一人で実装するのに比べて人数を割く手法ではあるので、実践するのは抵抗があるかもしれませんが、新規メンバーに多くの気づきが得られるという面で非常にメリットもあります。

モブプログラミングに興味がある、これからモブプログラミングを実践してみたいという開発チームの方は、まずは小さいIssueからTRYしてみて、その効果を実感するところから始めてみるといいかもしれません。