今村といいます。ベトナムハノイのオフィスでベトナム向けサービスを開発しています。今回はハノイオフィスでモブプログラミングに挑戦してみたのでその経験をシェアしたいと思います。
モブプログラミングとは
簡単にいうとペアプログラミングを複数人でやるものです。ひとつのPCと大きなスクリーンを使って複数人で交代しながらひとつのタスクをこなしていきます。
ルール
- 全体
- 皆で協力しながらひとつのタスクをこなす
- 一つのPCを使って15分ごと、ないしはキリのいいところで交代しながらコーディングする
- コーディングを開始する前には大まかな設計を一緒に行って何を作るのか認識を合わせる
- Driver (コードを書く人）
- 作業をしながら常に何を考えているかを発言しつづける
- 指摘を受けても防御的にならない。
- Navigator（それ以外の人）
- コーディングのミスがあれば指摘する
- 良くないコードが書かれても非難はしない。問題と改善にフォーカスする。
- わからないところがあったら質問する（わからないところを放置しない）
互いを攻撃しあって雰囲気が悪くなってしまうのは最も避けたかったことなので最初に「対立せずに協力する場」だということを強調しました。
それって非効率じゃないの？
ひとつのタスクを複数人でやるのって非効率では？と思うかもしれません。この疑問に対する一般的な反論は以下のようなものがあります。
- 節約できる時間が沢山ある
- 常に会話しながら作業をしているので各種ミーティング・ドキュメントが不要
- コーディングとコードレビューが同時に行われるので余計なタイムラグが無い
- 問題解決にかかる時間が圧倒的に短い
- ケアレスミスの多くがその場で検出される
- コードの設計や仕様に関する共有がなされる。コードを書いた人しかその部分を修正できない、という状況がなくなる。
- 品質が良い
- コードは常にレビューに晒されるためコード品質が良い
- バグが少ない
- 高速に学習できる
- チームが均質でない場合（知識レベルに差があったり違う文化を持っている）には知識やスキルの伝達が高速に行われる
作るもの
Rails で書かれた自社サービスの検索APIを高速化するために Crystal という言語で書き直します。
Crystal とは Ruby によくにた文法の静的型付き言語で、Ruby のコンパクトな表現力のまま型安全性・高速動作を実現した言語です。
参加者
- 自分(Crystalの経験あり）
- ベトナム人エンジニア２人(Java, Ruby の経験はあるが Crystal 未経験)
設備
- ラップトップ２台(コーディング用＋調べもの用）
- キーボードは各自好きなものを
- ５０インチテレビ
- ホワイトボード
風景
期待
モブプログラミングをやろうと思ったのは以下のようなことを期待していました。
- Crystal の経験が自分しか持っていなかったので、知識を効率よく伝達できる
- その他一般的なプラクティスやツールの使い方を共有できる
良かったところ
- まず何よりずっと話をしながら作業をするので雰囲気は良くなります。メンバーにもよるとは思いますが、和気藹々とコーディングができました。
- 宣伝文の通り、知識伝達は効率的だったと思います。以下のようなケースは彼ら一人でやってもらうよりもスムーズに進めることが出来たと思います。
- 新規開発環境のセットアップなど知識まっさらの状態での作業
- コンパイラオプションなどハマりどころ
- アルゴリズム的な箇所やジェネリクスの使い方などのちょっと考えないといけないところ
- 逆に他の人から最近のツールの使い方など教わることもありました
- たまたま別件で５０インチテレビを買ったのですが、プロジェクターよりも解像度が高くくっきり見えるので10ptのフォントでも支障なく作業ができます。
- 一人で作業しているよりも集中度合いは高いと感じました。単純によそ見できませんし、コード書いているときも見られているという感覚が襟を正してくれます。
- 認識の齟齬が起きないように気をつけて説明する、みたいなことが必要ありません。間違えていればその場で指摘して勘違いを正すことができます。これはストレスの面で非常に良かった。
- インデントやコーディングスタイルの議論で無駄に時間を使わないためにも必ずフォーマッタを使うべきです。
コードレベルの細やかなコンテキストが共有できているグループが一つのタスクに集中するというのは新鮮な経験でしたが本当に余計なことをしなくて済む、という感覚です。
良くなかったところ
各自 Crystal の書き方をだいたい把握して、同じようなコードを書く流れ作業の状態になると途端に効率が落ちるように感じました。
指摘できるコメントは些細なものばかりになり、Navigator が手持ち無沙汰になります。この状態になってしまうと各自ばらばらで作業したほうが良かったんじゃね？ってなってしまいます。
開発しているシステムのドメインが複雑で常に難しい問題が供給され続ける環境などでない限り
このような状況にならないように皆で解く価値のある問題を探し続けてそこに時間を注ぎ続ける必要があります。
最初この状態になった時にしばらく気づかずにぼーっと過ごしてしまいました。その後、皆で解くと効果的な問題に集中しよう、と改めて目的を定義しました。
メンバーに能力差知識差がある場合、経験値の高い人からすると経験値の低い人の作業を見ている間は相手の手が遅いように感じてストレスが溜まるかもしれません。
でもそこで「俺がやったほうが速い」とばかりにキーボードを奪い取ってしまうと最悪です。何のためにモブプログラミングをやっているのかわからなくなります。
見かけ上のコーディングの速度を最大化することが目的ではないことを明示的に宣言しましょう。
あなたがノリノリでコーディングしている間のメンバーのお気持ち
失敗したこととして、モブプログラミングは社内では初の試みだったので自分を含め３人で行いましたがもちろん他の人も気軽に覗いてもらって雰囲気を掴んでもらえると良いなと思っていました。
しかしミーティングルームのドアを閉じて作業を行ったので「邪魔をしては行けない」感じが出てしまったのは失敗でした。
時折他のメンバーが誰かに用事がある時に「すみません」と言いながら部屋に入ってくる状態になってしまいました。
どういう時に使えるか
モブプログラミングないしはペアプログラミングは常に効率的だとはちょっと言いづらいですが、使い所を見極めれば非常に良いプラクティスだと思います。
- 新しい技術を導入するとき
- プロジェクト初期の設計が固まっていない時期
- 新しいメンバーがチームに加入したとき
- 難しい問題を解く時
言い方を変えるとチームに何かしら不確定要素（リスク）がある時にリスクにフォーカスするための良いツールだと思いました。
メンバーは固定でやるよりも毎回変えるのが効果的だと思います。
また今回は皆楽しんでくれましたが、このやり方が性に合わない人もきっといると思います。
個人的にはまた何度もやりたいと思いました。
リードプログラマーで、mmjベトナムの代表取締役。現在はベトナム、ハノイ在住で、現地エンジニアの指揮を執っている。