はじめに
私が勤めている会社では絶賛アジャイルを進めています。
そんな中、たまたまモブプログラミング(以下モブプロ, モブ)の記事をみることがあり、これであれば技術負債なく開発を気持ちよく進められると思い「モブプログラミングベストプラクティス」という本を読みました。
過去に本の内容をまとめています
そして、モブプロの威力を思い知ったので実際にチームで取り組むことにしました。
2カ月いろいろなパターンや方法で試して得られた知見をこの記事にまとめていきたいと思います。
モブプロを導入しようとしているチームがモブプロの効果を実感するのに役立つことを願っています。
経緯
■ 出会い
「モブプログラミングベストプラクティス」を読んだのから導入へ動き始めます。
この本がわかりやすいのでモブプロを進めていく上では必読です。メンバーの一人がこの本の考え方を完全に理解しているとモブプロの導入が円滑にできるようになります。
■ チームへのモブプロの周知
モブプロを始めるうえ「モブプログラミングベストプラクティス」の内容をパワーポイントにまとめてチームのメンバー(4人)に1時間ほど勉強会という形で紹介しました。モブプロを導入するには全員がモブプロを理解してその考えに賛同する必要があるかと思うので質問にもしっかりと答えます。
■ モブプロの実施
モブプロを実施したのは、
- 社内システム
- 外部発注でチームのメンバーがコードや処理を理解していない
- 経験が浅いメンバーが多い
という案件でした。社内システムなので仮にモブプロを導入して作業が遅れるような事態があっても大丈夫なように考慮はしました。また誰もコードを理解していないというのがモブプロで全体理解していくのに向いていました。
モブプロを導入する上期待していたのは、技術負債をなくす、技術レベルをチームで同じにしていくことでした。
最初の1週間
手さぐりになるので書籍と、モブプロを実践した記事を読みベストプラクティスっぽいものをすべて取り入れて行いました。
この時期のルールは以下でした。
- ZOOMのリモートコントロールでタイピストを変更する
- 時間は1回10分
- 30分ごとに5分の休憩
- 1日4時間モブプロを行う
- 最後の20分でレトロスペクティブ(反省会を行う)
- 作業を開始する前にTODOを作成して都度更新する
- Mainブランチにマージしたら「やったー」という(儀式)
- VSCodeを標準化する(setting.json)
- ショートカットは共有して教わったショートカットは使うように心がける
- ソロプロで書いたコードは2日以内に全員レビューしてからmainにマージ (技術負債回避)
基本的にはZOOMの他人の画面を触れる機能を使ってモブプロを行いました。
時間はWindowsのアラームを利用しています。
最後の20分ではレトロスペクティブを行っていて、KPT法で振り返っていました。
これに加えて、ショートカットが登場したら議事録に記録するようにしていました。
この期間でのチームでの反省会の内容は以下のようになります。
感想
- 発言が増えた
- 真のアジャイルを感じた
- 他人の使っているショートカットが知らないのが多い
- 集中力が継続する
- 開発のやり方(デバック方法、バグの特定方法など)を共有しながら作業できてよかった
問題
- タイピストが勝手に作業してしまうことがある
好感触だったので、本格的にモブプロで開発を進めていくことにしました
2週間～1カ月
本格的にモブプロを導入して、モブプロだけで開発を進めました
ここで追加されたルールは以下です
- VSCodeLiveShareを用いる
- わからない場合はモブを止めていい(テクニカルタイムアウトを宣言)
- 開始前に前回のレトロスペクティブのTryを確認する
- リファクタリングはモブではやらない(わいわい行う)
- 修正箇所は行番号で具体的にタイピストに指示する
- バットマンの導入(書籍参照)
- 人が3人集まればモブをする(1人別案件に入っても回る)
- Mobsterの利用(モブ用タイマーアプリ)
- 2人の時はペアプロに切り替える
- 検索のやり方も画面で共有する
- ボックス探求の導入(書籍参照)
- 休憩時間は仕事をしてはいけない(雑談をしていた)
- 時間できっちりとタイピストを入れ替える
- モブが終わったタイミングでGitにPushする
- 次の日の司会がLiveShareのリンクを共有する(ブランチをpullしておく)
- テストではナイスレッド、ナイスグリーンをいう
- モブ中に無言になったら「あれZoom止まった？」、「ping」と発言を仰ぐ
- ToDoリストのチェックボックスが終わるたびにナイスチェックという
- 参考になったサイトは共有の技術メモにリンクを張る
- タイピスト以外はカーソルを関係のないところにおく
- ボックス探求をするときは提案してから行う(勝手に行わない)
- 探求で情報共有をして、早く終わる場合にはすぐ中止してモブに戻る
- 無敵時間を宣言できる(経験の浅い人がずっとタイピストをして、説明してもらいながら実装を進めてもらう)
- デイリースクラムの廃止(すべてモブなので)
1カ月実施すると色々ルールが増えていきますが、ローカルルールを作ることでうまく回るようになりモブプロが盛り上がるようになりました。
タイマーは「Mobsterを利用しました。このアプリはモブに特化しているのでメンバーの入れ替えや10分の管理がしやすいです(時間が0になるとパソコンの操作ができなくなります)
反省会の内容は大まかに以下となりました
感想
- 残業時間が全員同じになった
- 人がかけても(休みや急な対応など)開発は同じペースで進む
- ToDoは歴が浅い人に作成してもらいそれを全員で粒度を下げていくのがToDoの作り方を学べて良さそう
- レビューなしでマージできるのがよい(デプロイ回数が増えた)
- 技術負債がいまのところない
- モブプロ以外での会議での発言が増えた
- メリハリのある仕事ができる
- できる人に質問が集中するのがなくなった(作業中断がない)
- 心理的負担が減った
問題
- タイピストが指示された内容を理解しているかわからない
- LiveShareの開始までにスムーズにいかないことがおおい(うまく接続できないことがある)
- まとまった休憩がない(10分休憩など)
- 理解している人だけで話が進んでしまうことがある
- 個人でしなければならない作業ができなくなった(勉強会の資料作成など)
- 簡単な作業(Typo修正)などはモブをやるほどではない
すべての作業をモブプロでやると個別の時間が取れないのが大きな問題となりました。
また、自分の1人の実力で開発をする機会もほしいという歴の浅い方からの意見もあり、2カ月目からは個別作業も取り入れるようにしました。
2カ月目
ソロプロ期間
まずはモブプロが効果があったと断言するためにソロプロを2週間する期間を行いました
- マージリクエストは2日以内に見ないといけない
- デイリースクラムを朝行う
- わからないことは15分で聞く
というルールを守り、あとはスクラム開発ソロ開発で進めていきました。
モブとソロプロの比較をする反省会を終業前に行いました。
感想
- ソロは自分で実装できるので楽しい
- 他メンバーの進捗がデイリースクラムでしかわからない(わからないことを15分で聞かないことが多い)
- 技術レベルに差が出る(フロントが得意な人にフロントを回しがち)
- 雑談がほぼなくなった
- モブよりも集中できた
- 休憩を自分の好きなタイミングでとれる
- 作業にのめりこんで休憩をとらなくなる
- モブだとできる人に頼りがちになっていた
- コードレビューが大変
- レビュー内容を個別で聞くので同じ内容を何度も説明した
- マージリクエストがたまる
- ソロプロが向いている作業はありそう(軽微な修正など)
- わからないところを聞く場合に、そこまでの経緯や問題の説明をするので時間がかかる
- 質問する技量が問われる
- 自分の作業とコードレビューで忙しい
- モブのほうが楽しかった
- 別の作業が入ってコードレビューが遅れてしまうことがある
- 残業が1人突出してしまった
- 個別作業なら作業の切り替えが簡単(急な対応など)
- ZOOMで人に聞くため「○○さんいますか？」と聞いてもいないことがある
モブプロとソロプロどちらにもメリット・デメリットがありました。
そこで、1日をソロプロとモブプロ半々で行うことにしました
ソロプロ&モブプロ期間
以下のルールを追加しました
- 午前はソロで作業を行う
- プランニングでソロ用の作業とモブ用の作業を用意して割り振る
- 午後はモブプロを行う
- デイリースクラムは継続
- モブ開始のタイミングで実装内容の理解時間(15分)をとって個別で理解する
感想
- 関係のない別の作業ができるのでよい
- 午後からのモブは眠気がこないので仕事に集中できる
- 午前に資料作りができたのでよかった
- ちょうどいいところでモブを終わらせられるようになった
問題
- モブで作業していたブランチに個別作業をしてしまってコミットしてしまった
- ブランチの切り替えが大変
- ソロプロ途中でモブに切り替えるのは気持ちがついていかない
- 週明けの午後は以前の作業を忘れる
ソロプロ・モブプロどちらの良さも取り入れられて、問題も大きいものはなくいい感じで開発を行うことができるようになりました。
今後の方針
ソロプロとモブプロを半分ずつ行うので落ち着いたので次はどこでモブプロに切り替えるかを調整していきたいと思います。
先日こちらの記事が公開されました。
まさにいま私たちがやろうとしていることでした。ここで行われている「キャプテン制度」を導入してチームとしてうまく回るかを確かめていきたいと思います。
それから1カ月(3か月目)
モブプログラミングを1日中するとやはり個別の時間がとれなくなるため勉強会の資料が作成できない、業務目標を達成できないなどの問題があり、キャプテン制度を利用しました
すると、簡単な内容(チームがMRを見ればわかるレベル)は個別で開発してMR作成する流れになり、個人の時間も十分とれるようになりました。また全員がMRのレビューをするため技術負債も減っています
さらに1カ月(4カ月)
ここでチームとしては扱ったことのない技術GoとReactを利用した開発が始まりました。チームで分担して1カ月ほど学習してから開発をスタートしてやはり知識がばらばらであったり、全員がわからないという状況になりました。そこでモブプログラミングをやることで分かる人がわからない人に教えていくという流れで知識の標準化ができるようになりました。同じことを何回もそれぞれに話す手間もなく、また全員がコードの隅々を理解しているのでこういう機会にもモブプログラミングは有効だなと思いました
有効と確認できたので社内に広める活動も行いました
全2回の勉強会で前半にモブプログラミングとは何か、やってみてどうだったか(本記事の内容)を紹介して、後半に実際に複数チームを作ってもらい「FizzBuzz問題」をモブプログラミングで40分ほどでやってもらいました
この企画のかなり好評でのちにモブプログラミング導入のための勉強会が開かれていました。
モブプログラミング勉強会のお題は以下の記事を参考にしてみるとよいです
おわりに
モブプログラミングを行う上で、チームで行っていることを記事にまとめてみました。
私自身が導入する際にチームでの決まり事(ローカル―ル)を知りたいなと思ったのですが、あまり記事になっていなかったので私たちのローカルルールがモブ導入の参考になればと思います。