クオカード デジタルイノベーションラボの飯島、小林、森です。７月末から１月半ほど本格的にリモートでのモブプログラミング・モブ作業を取り入れてみたので、やってみてわかったことを共有します。ちなみに、この記事もモブプロ(モブ作業)で書いています。
背景
入社してからまだ数ヶ月のメンバーがいたこともあり、業務知識を共有するためにペアプロが自然と行われるようになっていました。その流れで、流行のモブプロを導入してはどうかという提案もあり、取り入れることにしました。なお、メンバーにモブプロ経験者はいませんでした。
モブプログラミングとは『モブプログラミング・ベストプラクティス』 から概要を取り上げると、三人以上の人々が１台のコンピューターの前に座って協力しながら問題を解決していく手法です。2000 年代には考えられていたが、当時はペアプロの方が主流で、顧みられていませんでした。2015 年くらいにWoody Zuillさんが開発手法として再発見しました。
導入にあたっての不安
モブプロを導入するにあたって、次のような不安がありました。
- 一つの作業をみんなでやって本当に効率いいの？
- スキル不足でチームの足を引っ張るのではないか？
- 個人の成果がだせなくなる（評価）のではないか？
これらの不安がありましたが、いざやってみるとその不安を上回るメリットがあることに気づきました（後述）。
現在の進め方
1日のセッションは次のようなスケジュールで行っています。
- 10:30 ~ 10:45 朝会
- 11:00 ~ 12:00 モブプロ（20 * 3）
- 14:00 ~ 16:40 モブプロ (20 * 4 + 休憩 + 20 * 4)
- 16:40 ~ 17:00 反省会
朝会(デイリースクラム)
以前はメンバーがそれぞれ下記に示す内容をデイリースクラム前に Slack で報告して発表するスタイルでした。しかし、モブプロが始まってからは、各自の内容が被ってしまうため、今は朝会の場で参加者全員で確認するスタイルになりました。
- 前日の成果の確認
- 当日の目標の確認
- スプリント計画を達成できそうか確認
モブプロ
このようなルールでモブプロを行なっています。
- インターバル２０分
- １周したら１０分休憩
- 役割を定めて行う
- ドライバー: ナビゲーターに言われたコードを書く
- メインナビゲーター: ドライバーにやってもらいたいことを言う
- その他メンバー: アイデア出し、タスク管理（Google docs）
インターバル２０分
初期は時間を決めていませんでした（キリのいいところまでやっていました）が、人によって時間が偏ってしまうという問題が発生したので時間を区切るようにしました。最初は30分でしたが間延びしている感じがあったため、20分にしてみたところ、スピード感が出ているように感じています。20 分だと時間が短いという意識が入るので、早く交代しようと思うようになりテキパキと開発を進められているからです。
１周したら１０分休憩
意外と脳を使っているようなので、休憩しないと集中力が下がって生産性が下がってしまうように感じています。
また、モビングセッションが長時間に渡ってしまい問い合わせがその間に来ていることがあり、その問い合わせに対応するため、この休憩時間を使って Slack を確認（本業である twitter を確認）しています。
役割
モブプロを始めた頃は特に役割を決めておらず、ドライバー（タイピスト）が書いたコードを他のメンバーが追承認するような形になっていました。これはこれでよかったかもしれませんが、議論を活性化したいので、なるべくタイピストの意思で入力しないようなルールをモブプログラミング・ベストプラクティスを参考に定めました。
反省会（レトロスペクティブ）
初期はなにもしていませんでしたが、学習している感覚がなく成長している実感もありませんでした。毎回のモブセッションが改善されていくようにしたかったので、モブプログラミング・ベストプラクティスを参考に反省会を実施してます。
- 事実の確認(数字で語る）
- 例：4 つのインターバルで Terraform で設定すべき内容を明らかにできた
- 肯定的な感想
- 例 : 実験的なリソースを作成すると Terraform に落とし込みやすい
- 批判的な感想(人の批判をしない/仕組み的な部分を批判する)
- 例 : インターバル 30 分は長い/ドライバーの交代がもたついてしまう
- 建設的な問題解決(解決方法を考えて合意を得る)
モブプロ以外の時間は、調べ物をしたりしています。モブプロでやるべきコーディング作業とかはやりません。
使っている便利なツール
- くじ五郎
- モブプロの順番は、自作のくじ五郎という Slack bot を使って朝会の前に決めています。
- ランダムで mob の順番をシュッと決める
- mob cli
- https://github.com/remotemobprogramming/mob
- git 管理のソースをいじる時に、driver の交代とかをシュッと実現できる
- starting-new-session シェルスクリプト
- https://github.com/mike-neck/starting-new-session
- ブランチの作成 + initial commit + PR 作成をシュッと実現できる
メリット
約1ヶ月半、モブプロを継続する中で下記のようなメリットを感じています。
- コードを共有している感覚が生まれた
- PR やっている場合に比べて、コードに対する理解度が向上した
- 個人への依存がなくなり、チームとして保守性が向上した
- ◎◎さんがいないと対応できないという状況がなくなり、チームとして生産性が向上した
- プレッシャーが軽減された
- Terraformによるインフラの構築などを実行する
- 本番環境へのアプリケーションのデプロイ
- チームとして幅広い技術を身につけられる
長期的な視野で見ると、突然の出来事にも強く、生産性が落ちない組織になっているように思えます。
最初に書いた通り、始める前にいくつか不安がありましたが、実際にやってみてそれを上回るメリットがあるように感じます。例えば、一つの作業をみんなでやって本当に効率いいの？ という不安に対しては、特定の人に任せようみたいなことがなくなり、誰かがいなくても仕事が回るようになりました。
また、スキル不足でチームの足を引っ張るのではないかという不安ですが、質問しやすい雰囲気でモブプロできており、詳しい人もいるし失敗しても取り戻せるという感覚があります。
個人の成果がだせなくなる不安に関しては、チームで成果を出せれば良いと言う上司の理解があり、実は元から解決していました。
デメリット
始めたときには想定していなかった以下のようなデメリットがあることもわかりました。
- モブプロが終わると結構クタクタになっている
- 最初は緊張して疲れていたが慣れてきて軽減した
- プロダクトオーナーが寂しそう（モブプロに遊びに来た）
- 他のチームとのコミュニケーションが減少した
これらの改善が今後の課題です。
書ききれなかった感想
- 他の人のコーディング作業を見るのが単純に楽しい
- 『モブプロ』(kindle) を読むと良い
- 「誰かの頭に浮かんだアイデアをコンピューターに送り込むためには、まず誰かほかの人の手を通らなければならない」(Llewellyn Falco) に挑戦中
- 議論がまだまだ足りてない感じがある
- フルリモートでも、問題なくモブプロできている
- 慣れるまでは結構疲れる
- 初日はやばかった、今はちょっとくらい
- メンバーは4人 ちょうどいい人数
我々はモブプログラミングに対して概ね満足しており、今後も続けていきたいし、より良くしていきたいと思っています。
クオカードでは一緒にモブプロしたいエンジニアを募集しています。フルスタックエンジニア志向の方、今持っているスキルを世に広めたい方などのご応募をお待ちしております。
