この記事は Cybozu Advent Calendar 2022 の13日目の記事です🎄
こんにちは、 kintone 開発チームの @mckyhrs です。ソフトウェアエンジニアとして kintone の新規機能開発に取り組んでいます。サイボウズには2022年の9月に入社して早3ヶ月が経ちました。
この記事では、モブプログラミングの経験がなかった私がサイボウズに入社後、「サイボウズのモブプログラミング文化にふれて感じたこと」を紹介できればと思います。
サイボウズにはモブプログラミングの文化がある
サイボウズにはモブプログラミング（以下、「モブ」という）の文化があります。 kintone 開発チームのメンバーは各地に住んでおり、在宅で働いている方も多いので、Zoomなどのツールを使いリモートでモブをしています。
モブについては公開している研修コンテンツや関連するブログもあるのでぜひご覧ください！
前述の通り私は入社前までモブで開発を行った経験がありませんでした。
入社前の選考中に「開発は基本的にモブで実施している」ということを聞いて、驚いたのと同時に、「自分に合うかな？足を引っ張ってしまわないかな？」と少し不安に思っていましたが、後述する通り日々の業務の中で徐々にその不安は払拭されていきます。（ちなみに内定承諾前に社歴が浅めの方との座談会を設けていただいたおかげで、入社前にある程度の不安は払拭していました！）
ちなみに私が所属するチームでは毎日11:00-17:00の時間帯でモブで作業をしています。基本的にはソフトウェアエンジニアだけで作業することが多いですが、作業内容によってはQAなど他の職能のメンバーにも入っていただいています。
モブプログラミングのメリット
実際にモブをやってみていくつものメリットを感じることができました。一般的に語られているモブのメリットとは必ずしも一致しないかもしれませんが、モブを始めて間もない視点で感じたことを紹介します。
オンボーディングに最適
まずはオンボーディングを受ける身として、「モブで助かるなぁ」という感想を持ちました。kintone は歴史のある、規模も大きなサービスで、コード量も必要になるドメイン知識も多いです。社内のドキュメントは充実していますが、すべてを個人でキャッチアップしようとすると結構大変です。
そこでモブの出番です。モブで作業することでコードやドメイン知識、開発ツールの使い方なども手っ取り早くキャッチアップすることができて、個人で作業するよりもはるかにスムーズにオンボーディングできている実感があります。
実際にモブを始める前までは「足を引っ張ってしまわないかな？」と不安に思っていましたが、チームメンバーの方からも「わからないことがあれば止めていいので質問してくださいね」と受け入れていただきましたし、たとえ間違っていても良いので意見を伝えたり、わからないことは素直に質問してみたりするだけでも、意外とドライバーの方が気づいていない観点があって感謝されることもあります。そうしていく中で当初の不安は払拭されていきました。
また、リモートで働いていると会話するためには能動的に機会を作る必要がありますが、モブをしていると必ず会話が発生しますし、時には自然と雑談を交えることもあります。チームのメンバーと話しやすい状態になることで心理的安全性が高まるため、そのような面でもオンボーディングに適しているのではないかと思います。
実装の手戻りが少なくなり、品質が高くなる（かもしれない）
個人で開発を行う場合、実装 → レビュー → 修正 → 再レビュー → マージのような手順を踏むのがよくある流れかなと思います。
この流れだと実装の手戻りが発生する可能性があったり、レビュワーがプルリクエストを初めて見るといった場合にはコンテキストの把握に時間を取られたりしてしまいます。
モブで作業を行う場合、作業中に複数人の目が入るため、間違った方向に進みそうであれば早めに軌道修正できます。また、常に複数人でレビューしている状態になるので、 kintone 開発チームではモブで実装した場合にはレビューは必須としないルールになっています。これによりレビューのリードタイムもありませんし、コンテキストを正しく把握していない人がレビューしてしまいレビュー漏れが発生する、といったことも起こりにくいです。
結果、実装の手戻りが少なくなり、品質が高くなっている実感があります。
チームのタスクとして取り組むので安定して進捗を出せる
個人でタスクを持って作業している場合、ミーティングなどが立て込むと進捗が出なくなってしまいます。前職では個人でタスクを持っていたため、ミーティングや休暇などの予定の調整にはストレスがかかることが多かったです。
kintone 開発チームでは基本的にモブで開発を行うため、タスクは個人ではなくチームにアサインされます。チームのタスクとして取り組むことで、例えば1人がミーティングで一時的に抜けても作業が止まることはありません。よって、常に安定して進捗を出せるため、予定の調整も比較的やりやすいように感じており、地味に助かっています。
これはモブの直接的なメリットではないかもしれませんが、良いなと感じているポイントなので紹介させていただきました。
モブプログラミングだからこその悩み
モブで作業をしていく中で良い話ばかりではなく、悩みが出てきたのも事実です。
貢献感を得にくい
個人で作業する場合、プルリクエストを作ってマージされると、自分がどのように貢献したかが目に見えてわかるため、貢献感を得やすいように思います。
前述したように現在はチームのタスクとしてモブで取り組んでいるため、成果物のどの部分に自分が貢献したかが明白ではありません。そのため、「自分がどのくらい貢献できているのかがわからない」という悩みが出てきました。
この点については、人材マネージャーとの1on1でも相談しており、「モブは貢献か学習をできていれば価値がある」とアドバイスいただいたことで、焦る必要はなく、学習が進みナビゲータとしてしっかりサポートできるようになるにつれ、貢献感も高まっていくのではないかと考えるようになりました。
タスクによってはモブではない方が効率が良い場合もある
設計、実装、テスト実装、問い合わせの調査など、基本的にはどの作業もモブで行うスタンスですが、時にはモブではない方が効率が良い場合もあります。
例えば、テストの実装において方針はモブで相談して最初の1, 2ケースを実装すれば、その後は方針が大きくブレる可能性は低いので、残りのケースは1人でも実装できそうです。
日々の業務の中でちょっと気を抜くと、惰性でモブでの作業を選択してしまっている場合もあるように思います。
チームのふりかえりでも同様の話題が上がり、最近はタスク状況によってモブを2レーンに分けたり、1人に作業をお願いしたり、と臨機応変に対応するようにしています。
また参考までに、 kintone フロントエンドリアーキテクチャプロジェクト（フロリア）のチームが取り組んでいる、ソロプロとモブプロを両立した手法についての紹介記事もあるのでぜひご覧ください！
モブプログラミングは、いいぞ！
総じて言いたいのはこれです！
取り組む前は不安もありましたが、今ではたくさんのメリットを感じられています。
私自身としては早くナビゲータとしてしっかりサポートできるように頑張っていきたいと思います。
この記事を読んでくださった方で、もしモブプログラミングに興味をお持ちであれば、ぜひTryしてみていただけると嬉しいです。
