新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。
日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。
モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。
ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・チームにも適用できない体験というそのこと自体を共有したいと考えて書いています。
背景と課題
最近三か月ほど事情によりソロで Coil v2 というソフトウェアを開発していたのですが、それまでのペア・モブと比較してはるかに集中し、良い品質に仕上げることができました。 メトリクスで示すことは難しいですが、事実として v1 からのコンバーターツールの問題 1 件を除き Coil v2 は完成直後から不具合なく本番データセンターで稼働しています。 仕様・実装・テストのカバレッジなど様々な面において私の 20 年に渡る開発キャリアで最高の出来だと思います。ご興味あれば以下の記事をご覧ください。
長くモブプログラミングをしてきた間に、良い効果もあるものの、そうとは言えない場面も蓄積されていました。 そして Coil v2 の開発体験を契機に、今後のモブプログラミングとのかかわり方を見直すことにしました。
具体的には、以下のような点を課題と考えていました。繰り返しですが、これはパーソナルな経験でどこでも同じ課題が発生するわけではないと思います。
- 知識・経験差がとても大きいメンバー間ではうまく役割分担できない
- 品質について妥協するケースが多発した
- じっくり思索する時間がとれない
- モブでやらなくても済む作業を惰性でモブしてしまう
以下解説していきます。
知識・経験差がとても大きいメンバー間ではうまく役割分担できない
私は 20 年以上のソフトウェア開発経験を持ちます。インフラ領域は特に詳しく、Kubernetes の構造や Linux カーネルの諸機能やネットワーク・ストレージ関連の知識、セキュリティの実務など年数に応じた経験を有しています。チームでは Go 言語でほとんどの開発を行いますが、標準ライブラリのほとんどは諳んじていますし、並列・分散処理は得意です。
チームのメンバーが皆同じような経験の持ち主というわけではなく、むしろ多くはインフラ領域の開発経験は少な目なメンバーであったりします。チームにあとから参加したメンバーの場合は、それまでの成果物にまだ詳しくないということも良くあります。
そのようなメンバーでモブプログラミングをするとどうなるかというと、例えば Go の標準ライブラリのあれこれを使って〇〇して、という私は諳んじられるような作業にドライバが手こずることが頻発するわけです。ナビゲーター間で議論する場合でも、知識や経験量の差が大きいと一方的なレクチャーになることが頻発します。私がドライバをするときはスムースに作業が進むように見えますが、実態はモブプログラミングではなくソロ作業を皆が眺めるのに近くなってしまいます。
品質について妥協するケースが多発した
モブプログラミングの benefits の一つに技術的負債が溜まるのを防止できるという言説があります。 しかし、実際の体験としては真逆でした。
モブプログラミングは、とても強くメンバーの時間を拘束します。大変疲れるという人が多くいます。 また、日本人的というと主語が大きいですが、筋が悪いなと感じる設計やコードでもなかなか口に出せないという人もいます。 するとどうなるか。「流す」のです。
間違っているわけではない。動かないわけではない。テストは書いたのでリファクタはあとでできる。
などなどの理由をつけて、筋が悪いと感じる人がいるままマージされるケースが多々ありました。場合によってはテストを後回しにすることも。
それと、レビューがいい加減になる傾向もありました。モブ中に見ているはずだからと成果物をしっかり一から見直さずにマージする。 「皆が見ている」は存外「皆が見落としている」可能性を孕んでいます。
じっくり思索する時間がとれない
皆さんは、どのように新しい知識を吸収し、自分のものにしていきますか？
私は自分のペースで、記事や本を調べたり、コードを追ったり、手を動かして検証したり、悩んで StackOverflow に当たってみたりします。 誰かにあれこれ教えてもらって身に着けるということは、まずありません。あるとして、エディタの使い方のように数秒で把握できるものくらいです。 実際に Emacs から VSCode に乗り換えたときは、公式チュートリアルを丁寧に追い、キーボードショートカットを一通り試して覚えました。
何がいいたいかというと、ずっとモブプログラミングしていたらそのような学びの時間がとれないのです。
何かを設計するときも同じです。いろんな技術オプションや制約を調べ上げて、頭の中で有機結合させるには自分のペースで思索する必要があります。 そうでない人もいるかもしれませんが、私は一人で思索する時間が必要で、それはモブプログラミング中にはできないのです。
モブでやらなくても済む作業を惰性でモブしてしまう
例えばユニットテストを淡々と整備するとか、ドキュメントを書くといった作業は、モブでやる必要性が薄いことがあります。 しかしながら、それまでの作業の続きでなんとなくモブで作業してしまうことがありました。
新型コロナウィルスのため皆がオンラインになってからは特にこの傾向が強まりました。 リアルオフィスにいたころは、ちょっと声をかければすぐ集まることができるため、一時解散も頻繁に行っていました。 オンラインの場合、解散した後に「声をかける」動作がやりにくいということかなと思います。
良い点はないのか？
あります。最たるものとして、いつでもチームメンバーに声をかけて相談できることです。
各自がソロで作業をしていると、レビューしてほしいときにタイムリーにしてもらえないとか、相談したいときに捕まらないといったことがあります。 モブプログラミングはその点では苦労しません。
他社ではどうしているか
以下の事例は、何年もモブプログラミングでうまくやっているチームのやり方を紹介しています。 モブプログラミングでうまくいかないことについて掘り下げてはいないのですが、モブをやりたくない人にはその自由を認めています。
To make it easier on everyone, we do not insist that people participate if they don’t feel comfortable. Everyone is expected to contribute in the way they feel they best can, but no one is forced to sit and work with the team. It’s a personal choice. All are invited to join in but are free to work alone if they so choose.
以下はスマートキャンプ社の事例です。こちらは課題を多く挙げています。
なかでも「何のためにモブをするのか、チームで認識を合わせる」は大事な点であると思います。
Coil v2 開発ではどうしたか
Coil v2 では設計・実装ともに私がソロで行いました。
調べたり学ばなければいけない場面ではじっくり時間をかけることができ、自動テストの記述なども手を抜くことなく実装できました。 Coil v2 で新たに学んだのは以下のようなことです。
- Foo over UDP トンネル技法
- IPv6 プログラミング
- 特に Foo over UDP の IPv6 対応は調査に丸一日かかったので、モブだったら諦めていたかも
- Horizontal Pod Autoscaler (HPA) へのカスタムリソースの対応方法
レビュワーの確保は、以下のように工夫したことでタイムリーにレビューしてもらうことができました。
- 一日 1 Pull Request を目安に成果をまとめる
- 朝会でレビューしてほしい旨伝え、朝会後ただちにレビューしていただく
副次的な効果として、コミットをレビューしやすい単位できれいにまとめることができました。 モブでもできないわけではないのですが、複数人で書いているとどうしてもコミットが変なところでまとまったり、最後に squash して巨大になったりしがちでした。
ソロ開発だと、成果物のメンテナンスについて懸念があるかもしれません。 詳細は省きますが実際にはモブで開発しても、メンバー全員がメンテナンスできるほど詳しくなれる保証はないのです。
メンテナンスについては、しっかりとドキュメントを残し、テストを整備し、不具合改修や機能追加の際にレクチャーするのが最良の策だと思います。 その点 Coil v2 はドキュメントとテストを完備しているので、比較的容易にメンテナンスできると期待しています。
今後はどうしていきたいか
ソロであっても、レビュワーや相談相手の確保を工夫すれば、モブプログラミングより拘束時間をぐっと減らして成果を挙げることができました。 それを踏まえると、設計や実装という段階では私にはモブプログラミングは必要なさそうです。 要求分析や、あるいは不具合や障害など目が多いほうが良い場面もきっとあると思うので、そういう場面ではモブするのも良さそうです。
再度繰り返しますが、これは私という一個人の、パーソナルな経験と結論です。 設計や実装段階でモブプログラミングをすることでうまく回るチームや個人がいることを否定しません。
しかしながら、「モブプログラミングが最良の手段ではないメンバーもいる」「学習したい点ややり方は人それぞれ」といったパーソナルな面は私に限らずあるものと考えます。 モブプログラミングは時間と場所を非常に強く拘束しますので、スタイルが合わない人は参加しなくていいと認めるのが良いのではないでしょうか。 またモブに参加する場合でも、個人で思索する時間はたっぷり確保しておくほうが、それぞれの学習と成長を促せると考えます。
最後に、このような話をチーム内でしたおりに、レクチャーしてもらえるのはありがたいという声はありました。 新しいメンバーや経験の浅いメンバーに必要な知識をレクチャーするのは大事ですし、私もやぶさかではありません。 ただ、この場合はきっぱり「レクチャー」と呼ぶほうが紛れがなくて良いと思います。
