モブプログラミング Advent Calendar 2018

この記事はモプログラミング Advent Calendar 2018の25日目です。

空いてるなーと軽い気持ちで登録したら思ったらトリだった...ということで緊張しながら執筆しています。

この記事では、

新規システムの研究開発にモブプログラミングを入れてみた所感
モブプログラミング・モブワークの未来（妄想）

を述べてみたいと思います。

はじめに

Rakuten Technology Conference 2017のMob Programming at Hunter Industriesでモブプログラミングの事例を聞いて、そしてJJUG CCC 2017 Fallのモブプロで実施する Cognitive Service & Bot ハッカソン #1で実際に試してみて、モブプログラミングの秘める効果や可能性にとても共感をしました。

私の業務の一つに、学生（学部4年生・大学院生）の研究成果を実用化まで進める担当があるのですが、これは例えるならば「未経験の新人」が書いた機能・モジュール・ライブラリなどの成果物を複数・短期間でリリース可能まで持って行くという作業になります。

ご存じのとおり、スキル・ノウハウ・連係が十分ではない状況で作られる成果物の保守性や持続可能性を引き上げるには、バグ・要件の見落とし・非機能要件の未達成、ルールの未徹底、etc...と、大小・多種多様・多数の問題・課題が浮かび上がってきます。

この打開を成果物のレビュー＆修正だけに頼っては、なかなかうまくいきません（しかも毎年新しい進級生＝新人状態にリセットされるので、チームメンバー側のノウハウ蓄積も期待できない）。

モブプログラミングによる「開発＆コミュニケーションの両立」の効果がでれば、この状況の一部分でも改善に向けられるひとつの方法になるかと思いました。

モブプログラミングの導入と所感

方針と概要

今年度から開発に入る某システムの研究開発に、モブプログラミングを導入し始めました。

モブプログラミングの風景、撮影者（私）を含めて3名の時のもの

チームに配属されている学生は進級したばかりの学部4年生3名で、開発に必要な技術のスキルや経験値はばらばら（プログラミングはどちらかといえば得意な2名、苦手な1名）、プロジェクトリーダー役は私です。

これまでの手法では、

担当となる機能やモジュールを学生のスキルにあわせて振り分け
仕様策定、開発＆テスト、レビュー
1と2を半年×2サイクル
- 前半は成果物のベースとなる部分
- 後半は研究的な評価が必要な部分（≒学生各個の研究テーマ）

という流れにしていました。

今年度は、

前半期は学生各個の成果物のベースとなる部分をモブプログラミング
後半は各個で研究的な評価が必要な部分（≒学生各個の研究テーマ）

という流れに変えてみました。

前半のモブプログラミングで「仕様・構造や実装状況、課題や工夫の可視化・共有を図る」「チーム内の見通しをよくする」ことを狙い、後半はそれを生かして各自の開発に入るという狙いです。

今回の取り組みがうまくいきそうなら評価指標などをしっかり定めて検証したいな、という試験段階なので、評価はまだ私の主観的な感想しかありません。後半も最後までモブプログラミングというのも良いかなと思っていますが、そこまでドラスティックな変更に踏み切れない大人の事情もあります......。

またモブプログラミングの考え方（？）についても、まずは一つの機能を一緒に開発しよう！というレベルから始めています。

準備したもの

モブプログラミングを始める前に、以下のものを用意しました。

プロジェクタ（85インチで投影）
ドライバーが共有する開発用ノートPC（と、自分用のUSキーボード）
- Mobsterインストール済
ホワイトボード2枚（180cm×90cm程度）
技術書（特にアンチパターン本）
お菓子
いいかんじのカフェBGM

どどんと大きなディスプレイをそろえることも考えましたが、まずは手元にあるもので...

あとは各自が自分のノートPCを持ち込んでいます。

思い通り・良くなったところ

前半部分の開発期間は短縮した
開発が始まるまで未定の部分を全員で共有して議論・方針決定できた
チームメイトのスキルや経験値もふまえて、改善点を確認できた

開発期間に関しては、学生のポテンシャルに依ってしまう部分も大きいですが、今回は例年よりも1ヶ月程度短縮できました。主にチームメイトが悩んでいる時間が少なくなった（悩んでいる所にピンポイントや実例・実コードでアドバイス・トレーニング）できたという、これまでにあった余計な時間が省かれた点と、次に述べる方針決定の早さが要因として大きいように感じます。

未定の部分の方針決定は、はじめてみないと見えなかった課題（そういえばここは仕様が詰まってない、要件の解釈が各自で異なる、テストの基本方針など）をより早くキャッチアップして、どうするかの結論や周知がその場でできたという点が魅力でした。

改善点の確認は主にプロジェクトリーダー役として感じたメリットです。ドライバー時の所作、ナビゲータ時の提案内容、方針の議論の中で、チーム全体の改善点を考えることができました。例えばIDEの支援ツールをどれだけうまく使うかという細かい所一つとっても、確認や改善方法を共有できました。

これらの思い通り・良くなった所はまさに開発しながらコミュニケーションやレビューが行えるモブプログラミングの利点が現れたところだと思っています。

誤解していた・反省したところ

モブプログラミングをやるなら日頃から
モブプログラミングの成果は特別なもの
モブプログラミングの目的に合わせたファシリテーション・振り返り

せっかく利点が出てきても、モブプログラミングができる時間が限られているともっと大きな成果にはつながりにくい、という反省があります。まとまった時間のスケジュールを合わせるのはやはり難しく、今回も週に1,2度に数時間程度の機会になってしまいました。全員がスケジュールを合わせられる形に持って行く形への改善が、そもそもワークスタイルへの改善にもなるのかなと思います。

成果は特別なもの、は、モブプログラミングの効果は複数人で一つのものに取り組むからこその「現場の効果」が目立つように思います。例えば私たちの事例であれば、後半の個人開発に切り替えた途端、個人のスキルや経験値の差が原因と思われる進捗の差が大きくなっていきました。モブプログラミングの活動で出た良い進捗は、個々の開発でも同じ進捗を出せるようになる・なったことを裏付けるものではないということに注意が必要だと思います。

ファシリテーション・振り返りについて、チームもしくは個々でモブをやる意図・目的・ゴールの設定を行うことはとても重要に感じました。例えば、開発の進捗を目的においたモブと、スキル・経験値の共有を目的においたモブ、どちらもおそらく実現できるのでは無いかと思います。ただし、チームや個々での意図・目的・ゴールを明確にしないと、良い形でのモブプログラミングの進行を妨げる原因にもなりそうです。 @imagire さんの大学のゼミでモブプロ中の事例にもありましたが、ドライバーまかせになってしまう、ナビゲータをすべき時についつい割り込み業務に気をとられる、ダレてそれが定常化する、ということはどうしてもあるように思えます。「特定の人のワンマンが目立つ」「貢献度に大きな差が出てくる」という現象が現れてきたときに、個々やチームの目的やゴールを共有して、ファシリテーションやモブの進め方、個々人が心がけることを振り返る機会がないといけないかと思います。

これらの誤解や反省点はどこかで連動しているようにも思えるので、うまく改善点を見つけていきたいと思います。

モブプログラミング・モブワークの未来（妄想）

（ここから先は妄想です）

今後、モブプログラミングやモブワークがどのように広がっていくかは未知数なところがあると思いますが、実は私たちよりも若い世代は、モブプログラミング・モブワークの方法論を抵抗感無く選択していける可能性があるのではないかと思っています。

なぜならば、次の世代の人たちは、子供や学生の頃から（パソコンやプロジェクタの機材ではないにせよ）モブプログラミング/モブワークに近い形で、プログラミングに触れ始めているからです。

先日見学させていただいた、小学校でのプログラム教育事例。児童たちチームでひとつのプログラムを議論し、考える

自分たちの大学の事例。学生が複数人のチームでひとつのプログラム課題を議論し、考える

今、モブプログラミング・モブワークにチャレンジしている人たちが、自分たちの世代はもちろん、次の世代と一緒にモブできるといいなと願ってやまない毎日です。

おわりに

モブプログラミングの一事例の報告と、自分が感じている所をつらつらと述べました。

大学の研究開発現場は、企業のそれとは当てはまらない部分・乖離が大きい部分・企業の方がよっぽど進んでいるなと実感することもありますが、もし何かの参考になりましたら幸いです。