トップ > やってみた > モブプログラミングをやってみた

モブプログラミングをやってみた

やってみた コミュニケーション

こんにちは、1年目エンジニアの三堀です。

先日、巷で話題のモブプログラミングという開発手法を試してみました。 そこで今回は、実際に試してみてモブプログラミングの「こんなとこよかったな〜」とか「ここがだめだよね〜」と感じたところをまとめてみました。 「これからやってみよう」と思っている方や「モブプログラミングなにそれ美味しいの？」っていう方にも読んでいただければいいなと思っております。

モブプログラミングとは

まず、そもそもモブプログラミングとは何かという話をしていきます。

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

  • 2012年ごろにHunter社で始まったもの
  • ドライバーを一人決め、それ以外はナビゲータとしてみんなで話し合いながら実装をする
    • ドライバー：コードを打つ人
    • ナビゲータ：ドライバーが書くコードを見て意見出す人

要するにみんなでわいわいプログラミングをするってことですね。ペアプロの複数版と言ってもいいのではないでしょうか。

モブプログラミングについては、以下のサイトがとても参考になりました。良かったら参考にしてみてください。

http://simplearchitect.hatenablog.com/entry/2017/06/19/080036

実施環境

今回は、こんな感じでモブプログラミングを実施しました。

作るもの

  • XCodeでiOSアプリの機能の一部を実装
  • 言語はSwift3を使用

用意したもの

  • プロジェクター
  • HDMIケーブル
  • PC(MacBook)

メンバー構成

  • Mさん：iOSアプリ開発経験豊富。Swiftかなり知ってる。
  • Kさん：Androidなら触ったことあるけど、iOS開発初心者
  • Iさん：Objective-CならやってたけどSwift初心者
  • Mさん：このプロジェクトに参加するって決まってからSwift勉強し始めたど素人←私

実施方法

ルール

実装25分、休憩5分を1セット 1セットごとにドライバーを交代させながら実施

手順

  1. 1セットの始まりにドライバーが自分のPCをプロジェクターに繋ぐ
  2. 実装する
  3. 編集したコードは交代する前に必ずコミットし、プッシュ
  4. ドライバーは実装をスタートする前に前の人のコミットをプルしてきて実装開始

やってみた感想

実施後、参加したメンバーで良かった点、悪かった点、改善策という3つの観点で振り返りをし、以下のものが挙がりました。

良かった点(Keep)

  • IDEの使い方など自分が知らなかったショートカットなどを知るきっかけになる
  • 文法や型などの不明点をその場で聞けるためググる手間が省ける
  • 全員が進捗状況を確認できる
  • コードレビューが同時にできる
  • 一人ずつ編集しているためブランチを分ける必要がない
  • 実装経験、知識が少ない人でもコードがかける
  • ドライバーでないときは一歩引いて見れるので気づきが多い

悪かった点(Problem)

  • 議論の余地のない作業中にドライバー以外が若干手持ち無沙汰になる
  • 時間で区切ると作業の途中でもコミットしなければならなくなる
  • できない人がドライバーやってると、できる人がだんだんイライラしてくる
  • 人数が増えると議論が白熱しすぎて実装が進まなくなる予感
  • 準備に手間取る、PCをつなぎ直すのが手間
  • 書ける人がいないと成り立たなそう

改善策(Try)

議論の余地のない作業中にドライバー以外が若干手持ち無沙汰になる

今回のケースだとまだ技術的に習熟しきれていない部分や議論の中で出てきた問題に対しての技術調査や復習をするのがいいのではないかと思いました。また、ある程度わかってきているのでれば今書いた部分に対するテストコード等を書くのもありなのではと思います。

時間で区切ると作業の途中でもコミットしなければならなくなる

これはストレートに作業単位で区切っちゃえばいいじゃんって感じです。ただ会議室を借りている場合など時間が限られているケースもあるため、そこは柔軟に対応するようにしないといけませんね。

できない人がドライバーやってると、できる人がだんだんイライラしてくる

今回はプロジェクタでドライバーのPC画面を表示していたため、ナビゲータの人が「あの〜の部分こうして」といった指摘をした際に、ドライバーが「あの部分ってどの部分？」という感じで、指摘したい場所がスムーズに伝わらずナビゲータがイライラしてしまうといったことが何度かありました。このことから、改善策として、以下の2つが挙げられました。

  • 単純にプロジェクターはなしで、一個のディスプレイに写して会議室のような形式にする
  • ナビゲータがレーザーポインターを持つ

人数が増えると議論が白熱しすぎて実装が進まなくなる予感

これはファシリテータ（司会・進行役）的な人を一人決めて話が脱線しないようにすることや、参加人数をあらかじめ制限しておくのがいいと思います。

準備に手間取る、PCをつなぎ直すのが手間

今回のケースだとプロジェクターの影響が大きいですが、単にディスプレイに繋ぐだけならそこまで手間ではないでしょう。

書ける人がいないと成り立たなそう

逆に書ける人がいないと、ハンズオン勉強会みたいな感じになってしまうと思うので、技術的にリードしていけるメンバーの存在が不可欠ですね。

まとめ

メンバー全員の知識共有がスムーズにできるため、私たちのようなプロジェクトの立ち上げフェーズには持ってこいだなと感じました。

また、コードをかけない人でも経験者の意見を聞きながら実装を進められるため、インプットとアウトプットのバランスがとても良いなと感じました。

ただ、今回のケースだとできる人の負担が多くなる点と実施環境によるストレスケアが課題であると感じました。

モブプログラミングとても面白かったです。皆さんも是非試してみてはどうでしょうか？