はじめに
Developers Summit 2018 (http://event.shoeisha.jp/devsumi/20180215) 2日目(2/16) のセッション「実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 -」にて、モブプログラミング(以下モブプロ)の実況・解説が行われました。
私も最近、モブプロっぽいことをする機会が増えてきたので、自身の経験や業務と重ねたりながら見ていました。
この記事では、モブプログラミング・ペアプログラミング(以下ペアプロ)に関する自身の経験や、上記の実況を見て感じたことを書いていきます。
「モブプログラミング・ペアプログラミングとは」といったことは書きません。
自身のモブプログラミング歴
新人研修でのペアプログラミング
新人研修にてシステム開発をする際に、全員が2人1組でペアプログラミングを行いました。
覚えている範囲ですが、以下のようなルールがありました。
- 1時間ごとにドライバーとナビゲーターを交代する
- 30分だったような・・・忘れました。とにかく一定時間ごとに2人の役割を替えていました。
- 「全員をある一定レベル以上にする」という目的はある程度達成できていたと思います。
- 小さな成功をおさめたらお互いにハイタッチする
- これが、チームの雰囲気を和やかに保つのに一役買っていたと思います。
- 否定から入らない
もっと色々あった気がしますが忘れました。
VR開発でのモブプログラミング
有志で1つのVRコンテンツを開発する機会がありました。開発メンバーは2〜6人くらいでした。
明確な開始時間・終了時間が定まっているくらいで、特にルールはありませんでした。
ドライバーはその場の雰囲気で替わっていました。
私が他のメンバーより少し多くノウハウを持っていたので、他のメンバーが同じレベルで開発できるようになることを意識して進めていました。
これまでのモブプロ・ペアプロを通して感じたこと
情報系学生の端くれだったこともあり、メンバー間でスキル差があり私がリードしつつ進めていくという状況が多かったです。
これまで(楽天のモブプロを見学する前時点)の自身ペアプロ・モブプロを通した気づきや学びを以下に挙げます。
実装する機能を共有してから作業にかかると良い
「○○を表示する」とか「ボタンを押すと画面遷移する」など、ある程度粒度を小さくなっていると、小さな成功体験が数多く共有できる形になるので良いと思います。
「○○というクラスを実装する」というように、コードを書くことを目的としない方が良いと感じました。
メンバーの技術的なバックグラウンドを考慮してコミュニケーションを取ると伝わりやすい
「○○という技術でいう××のようなもの」という話し方をするとすんなり理解してもらえることがあります。
バックグラウンドを把握するために「○○は知ってる？」などと適宜質問をして進めるのも効果があると感じました。
生産性が上がるわけではない
むしろ下がっていると感じることが多いです。1つの機能開発に複数人のリソースを投入しているので・・・
あと、スキル差のあるメンバーと組むことが多かったので、「一人だともっと早くできるけどなぁ」と感じることもありました。
属人化を防げる
これがペアプロ・モブプロの最大のメリットだと感じています。メンバーに等しく学びの機会が得られますからね。
上で挙げた生産性とのトレードオフだと思っています。
楽天のモブプログラミング
ようやく本題です。
「実況パワフルモブプログラミング」では、セッションの中で30分ほどモブプロを会場で実演する時間がありました。
メインの開発メンバーは3名。
基本的に、いつものメンバーでいつも業務でやっているようにプロダクトの開発を進めていくだけなのですが、もともとチームメンバーでない方も1名混ざっていました。
以下、実況で話されていたことや場面をピックアップしていき、自身の感じたことを書いていきます。
小さな成功をしたとき「ヤッター！」と会場のみんなで言う
この「成功体験の共有」がモブプロにおいてかなり大事だと気づかされました。
上で書いた新人研修の頃の「ハイタッチ」を思い出しました。
今はモブプロをやっていても淡々と進めているだけでしたが、これからは喜びの感情はもっと前面に出していった方が良いと思いました。
まず何をやるか共有
大きな紙に図や絵を書いて話していました。
次に設計のディスカッション
データの渡し方などを議論していました。
最終的に、やることをいくつかの付箋に書き出していました。
ここまでで体感5分くらい？時間を測れば良かったですね・・・
ドライバーはやろうとしていることや悩んでいることを口に出す
私自身も気をつけていることですね。
ただ、私は追い込まれると黙って手を動かしてしまう癖があるので、そういう場合はナビゲーターからドライバーに適宜話を振るのも大事だと思います。
「サンプルコードをペッ」という会話
リアルすぎて笑いましたw
まずは動いた実績のあるものを貼り付けてから調整する、という手法をとるのもありですよね。
「出入り自由」のルール
モブプロの参加者は、トイレに行ったりミーティングに参加するために途中離脱するのはありとのことです。
時間が決まってるわけではない
「なんとなく始まって、なんとなく終わる」という形のようです。
役割変更も自由
時間が決まっているわけではなく、「替われ！」と言われたらその人がドライバーになるそうです。
エラーが出て会場が沸く
良い雰囲気でしたw
あまり深刻になりすぎないのも大事なのかも知れませんね。
「もともとチームメンバーでない人」がドライバーをやる
手を動かし始めた途端にエディタが真っ赤にw
他のメンバーから変数名などの説明を受けていました。
新人さんが配属された場合や、プロダクトコードを知らない人が入ってきた場合に、あえてその人にドライバーをやらせるのは効果的だそうです。
合う合わない、はある
チーム内でコミュニケーションを取りながらコーディングを行うので、コミュニケーションに関する問題は顕在化しやすいとのことでした。
コミュニケーションとか人間関係に問題があるとパフォーマンスに影響しやすい、というのは確かに、と思いました。
特に新人研修の場など、事前にチームビルディングされていない場合はコミュニケーションの問題が起きやすい、という話もありました。
そういえば、自身が経験した新人研修のペアプロでもうまくいっていないペアはありましたね・・・
コミュニケーションをうまく取れない人は新しい情報をキャッチできない
書籍には新しい情報は書いていない、新しい情報はSNSやカンファレンスなどから得られる、とのことでした。
これは共感しました。人を直接経由しないとキャッチできない情報もありますしね。
予定した作業が終わったら、貪欲に次のことをやっていく
一休みする、ではないのですね。
vimとemacs使ってる人どうする？
モブプロは基本的に1台のマシンを交替で触りつつプロダクトの開発をしていくのですが、
実際の現場では、ドライバーが好みのエディタをインストールした環境で git pull してやっているそうです。
最後に、今日やったことのおさらいと、明日何をやるかを話す
この情報を残しておくと、最後にその場にいなかったメンバーでも次の日に問題なく作業に入れるようです。
モブプロにより同期作業が不要になった
モブプロにより常に同期するので、別途同期作業をする必要がないとのことでした。
直属の上司など、チームメンバー以外にもステークホルダーがいるという自身の状況を考えると、作業を見える化したいので、カンバンや見積もりをなくすのは少し抵抗があります。
個々での分担作業とモブプロとの違い
「リソース効率」「生産量」の観点ではモブプロはやはり効率が悪いものなんだな、と思いました。「学びとのトレードオフ」という自身の見解も間違ってはいないと感じました。
そして私が上の自身の経験のところで書いていた「生産性」という言葉は、このスライドでいう「リソース効率」「生産量」という観点のみで見ていたということに気づきました。「同期コスト」や「学びの機会」など、色々な観点から「生産性」を考えた方が良いと思いました。
結果だけでは伝わらない情報が過程にはたくさん存在する
モブプロにより形式知や暗黙知も合わせて共通体験になる、と話されていました。
確かに、言語化できない体験もメンバー間で共有できるのは、モブプロの大きなメリットだと思いました。
おわりに
セッションの冒頭で「モブプロは、やってみて得られる学びが多い」と話されていましたが、その通りだと思いました。
私が今まで経験したことは間違いではなく、「同期作業を減らす(なくす)」「学びや体験の機会を多く与える」などのモブプロのメリットが享受できるのであれば、手段は問わないと分かりました。「出入り自由」「なんとなく始めて、なんとなく終わる」という話を聞いたときは驚きました。
今私がいる開発チームは若いメンバーが多いので、学びの機会を多く与えるという意味で、ペアプロ・モブプロを積極的に採用していこうと思いました。