社内でモブプログラミングをやってみました #Slack

エンジニアが新しく入ってきて、一通り研修も終わりプロダクトのコードを触り始めて1週間が経ちました。研修ではRailsチュートリアルを完了してもらったあとに、Trailblazerの研修や、ReactやReduxの研修をそれぞれ3日間ぐらいかけて行いました。
弊社ではRailsの上にTrailblazerというライブラリを利用しており、研修で学んだTrailblazerと実際に利用するTrailblazerとの難易度差はやはりあり、この差を埋めるために実際のプロダクトコードでTrailblazerを利用している部分の開発をモブプロで行いました。

TL;DR

モブプロをナレッジのシェアのために定期的に行っています
モブプロのナビゲータをやることで、チームメンバーのコードを書くときの癖が見られて面白いです
モブプロの際にSlackの画面共有を利用すると、「あれ」「それ」などの指示語が飛び交わなくなります

ペアプロとは

モブプロとは？を説明する前にまずはペアプロを説明したいと思います。

ペアプロとは読んで字のごとく、ペアでプログラミングすることです。
ペアのそれぞれの役割をドライバとナビゲータに分け、ドライバがコードを書きナビゲータがそれをサポートするというのを30分交代で行っていきます。1つのコードを二人で書き上げていくわけなので開発速度が落ちるのではないかと思われるかもしれませんが、そこまで落ちません。
一人でプログラミングする場合は、目的のものが出来上がるまでに紆余曲折を経ます。そのためにDDDやTDDがあるのかもしれませんが、それでも紆余曲ぐらいは経ます。開発開始をスタート、開発終了をゴールとした時に、その間を結ぶ直線を「真に効率的な開発」とします。すると、一人でプログラミングしているときの開発は、紆余曲折している濃い線となります。

また、開発粒度がある程度大きくなると、今自分は何を作っているのかわからなくなるという状況に陥いります。
有名な図ですが、例えばブランコを作ってくれと言われたとします。

その際に上図のようなものを作ってしまうことがあるかもしれません。ペアプロを行うことで（ナビゲータがいることで）こういう問題を未然に防ぐことができ、さらには自分一人では出なかったより良いアイデアが出て来ることもあります。
どう作るのかということ以外に、何を作るのかという部分も明確化され、本当に必要な機能だけの開発を最終的には行えるようになるかもしれません。

上図が、必要最低限な機能を備えたもの（顧客が本当に欲しかったもの）で、ペアプロをすることでこれ発見できる可能性は間違いなく上がるでしょう。先程のスタートからゴールまでの図を、ペアプロを行った際の線で結んでみます。

2人でやっても効率が半分に落ちないでむしろ上る可能性もあることが何となくイメージできると思います。

モブプログラミングとは

モブプログラミングとは、簡単に言うとペアプログラミングの人数が多い版です。ドライバ1人に対してその他の全員がナビゲータとなります。ペアプロで効率が上がるなら、人数をさらに増やせばもっと効率が上がるのでは、図にすると以下のようになるのではと次は考えるでしょう。

私が思うに、ペアプログラミングとモブプログラミングは役割が違います。
確かに人数を増やすことでプログラミングの効率は上がるでしょうが、それに対してかかる人件費が大変なことになります。つまりバランスの話で、私たちはチームとしてはペアプロがちょうど良いと思っています。業務では通常、一人かあるいはペアでプログラミングをしています。

ではどうしてモブプログラミングをやったのかというと、冒頭にも書きましたがナレッジの共有(他の人が、また別の人にコードを指摘されているのを客観的に見る)が主な目的です。これを1ヶ月に1回程度行っています。

モブプログラミングの進め方

仕様の確認を開始後10分で行う
Slackの画面共有機能を使い、各自のマシンでプログラミングを行う
- 画面共有のポインタ機能を利用することで、「あれ」、「これ」、「それ」などの指示語が飛び交わなくなる
ドライバは30分交代としてタイマーが鳴ったらどんなに作業途中でもgit commitして次の人にバトンを渡す
- 正確には次の人が画面共有を奪います

ペアプロとあまりやり方は変わりませんが、Slackの画面共有機能を使うことが一般的に言われるモブプロとは違う部分だと思います。Slackの画面共有機能にポインタ機能（お絵かき機能）があり、画面共有しているドライバ役の人の画面に線を引けます。「あ、タイポしてるよ」と言われると、どこだろうとなりますが、画面に線を引かれながら「ここ、タイポだよ」と言われるとすぐに訂正することが出来ます。

モブプログラミングでの発見

モブプログラミングをやったことで幾つかチームの人のコードを書くときの癖が見えてきたので、挙げていきたいと思います。

テスト結果や画面に表示されたエラーメッセージをちゃんと読んでいそう
コードを書く順番が自分と違い新鮮だった
fn+カーソルキーを利用した単語単位の移動などを行っている
RubyMineのバージョンによるキーバインドの変化に戸惑っている
どこから書き始めればいいか分からない（ので、分かるまではソースコードを読むだけでコードは書かない）
（モブプロだからか、）コードが正しく動くかを自分で担保せずに、ナビゲータに任せる
テストを書かない

コードを書く順番やカーソル移動する方法（エディタの使い方）が人によって様々で、真似できる部分は真似てみようと思いました。このコードを書く順番というのはかなり興味深かったので、機会があれば別記事として書こうかなと思っています。
改善の余地があるなと思ったのが、全員がナビゲータになれないことと、コードの担保をテストを書かずにナビゲータに任せていたことです。
全員がナビゲータになれないのは、まだ研修明け間もないためRailsの理解やRubyのシンタックスになれていなかったり、同じナビゲータの中に知識をより持っている人が居た場合にその人にナビゲータを任せてしまおうという心理が働いたためだと考えられます。
コードの担保をナビゲータに任せている部分については、業務コードでTDDを必須にしていないから¹というのが理由にあると思いますが、これはTDDのメリットをもう少しペアプロなどで布教していくのが良いかなと思いました。

それぞれの感想

参加したチームメンバーにモブプロを開催してどうだったかという感想をもらいました。
※貰った感想をそのまま記載しています...

見てる分には勉強になる
自分はゴミクズ？だな？と思った
やらないといけないと思った
いい感じに周りから監視されてよかった
けど、どうやればいいかわからない
わからないものを作ろうという攻めの姿勢が良かったです
自分の環境を使えてよかった
テストなどが動くように環境を整備しましょう
RubyMine便利そう
最初にもう少しコードの指針をしめしてもらえたら良かった
人の考え方の流れがあってよかった
いい感じに分かっていたや
モブプロはやりたくない（今はまだ）
やりたいことは分かる

最後に

モブプロして完成したコードをモププロ会に参加しなかったCTOにレビュー依頼したところ、「キレイに書けてて正直ビビりました」とメッセージをもらいました。モブプロを定期的に行うことで、チーム全体としての力が上がるなと思ったのと、やはりコードは複数人で書くときれいになるんだなという実感を得ました。

コードの担保は各自スモーキングで行い、テストは自分に安心を与えてくれるものという位置づけでした。 ↩