こんにちは、ラクスル事業本部 SCM（Supply Chain Management）開発チームの藤川です。
RAKSUL Advent Calendar 2021 2日目は私からお届けします！
今日はチームで取り組んだモブプログラミングについてのお話をします。
私事ですが、テックブログ初デビューです。緊張…！
2021年7月入社とチームの中では最も社歴が浅いのですが、チームを代表しての発信の機会をいただきました！
背景
SCM開発チームでは「ラクスルの事業成長を支える発注基盤システムの構築」をミッションとしています。
お客様に高品質・低価格な印刷物をお届けするために複数の印刷委託先と連携してサービス運営をしていく中で、安定稼動を実現しつつも最適な発注によってお客様のより良い購入体験を実現するための仕組みづくりを日々続けています。
さて、そんなSCM開発チームですが現在いくつかの課題を抱えており、そのうち代表的なものは下記です。
どれか一つは「あるある」と思っていただける方も多いのではないでしょうか。
- システムの歴史が長く続いていく中で正確なコンテキストや仕様を把握しているメンバーが限られており、特定の人にしかレビューできない部分がある
- ドキュメントが非常に少ない
- メンバー間でスキル差があり、コードの品質にブレがある
- 社内の様々なシステムとの連携が必要で、動作検証の実施方法などのノウハウが複雑化している
このように一筋縄ではいかないSCMチームでの開発作業ですが、上記課題の解消を目指して10月の頭ごろから開発体制をモブプログラミング（以下モブプロとします）にシフトしてみました。
その中で得た知見などを、やったこと・よかったこと・気をつけたこと・今後の課題の4本に分けてご紹介いたします。
やったこと
1日の作業をほぼ全てモブ体制で行う
モブ「プロ」と書きましたが、コーディングだけでなくテストやドキュメント作業も常に複数人で行うことにしました。
ちょっとした動作検証のやり方や便利なJenkinsのjobなどの共有も同時に行うことが目的です。
適宜メモを取りながら作業を進める
モブプロの目的の一つをコンテキスト共有としていますが、SCMの開発の歴史は長く、その内容は複雑多岐に渡ります。
ラクスルではNotionを使っているため、共同編集機能をうまく使いながらみんなでメモを取ることにしました。
先述した「ちょっとした動作検証のやり方」なども積極的にメモを取ることにしています。
ファシリテーターを置く
モブプロ中は全員で議論をしているので、つい時間を忘れて盛り上がってしまうことも少なくありません。
そして時には、その話題は全体の優先度から考えてあまりこだわるべきでないはずなのに、つい盛り上がってしまって想定以上に時間を使ってしまう…という事態が起きることもありました。
そこでモブプロの「場」を俯瞰する立場としてファシリテーターのポジションを設け、ちょっと議論が込み入ってきそうな時に
「ここって今この場で解決しきってしまいたい話題でしたっけ？」などの言葉でみんなの意識を引き戻す。というようなことをしています。
その他にも休憩時間を管理したりその日の作業内容を認識合わせしたり、モブプロのために設けた時間中に各メンバーにミーティングがかぶったりしていないかの確認とリマインドなど
開発作業に集中しているとつい疎かにしてしまいがちな部分はファシリテーターがある程度拾うようにしました。
よかったこと
みんなが同じ目線を持って開発できるようになってきた
長く開発している案件がある中で新規メンバーがjoinした場合「いきなり全部説明して理解してもらうのも大変だし、まずは簡単で分かりやすいタスクを…」と
軽微な改修などから少しづつキャッチアップしてもらう形式を取ることが多いと思いますが
その間新規メンバーからすれば他のメンバーが何をやっているか、またその目的は何かなどがよくわからないままだったりします。
しかしプロダクト開発においてはその長く開発している案件こそがそのチームにとっての最大の関心事であり、かつ中長期的な価値を生み出すものであることも少なくありません。
今回モブプロをすることによってその目的や背景を知ることができたため、担当プロダクトが持つ本当の価値について同じ目線を持つことができるようになり、チームとして一体感が増したように思います。
私見ですが、モブプロで得たものの中ではこれが一番大きいと感じました。
リソース効率の面で考えると簡単なタスクを渡すほうが効率はよいですが、早期のキャッチアップを目指すのであれば多少リソース効率を落としてでもモブプロで実開発をしながら説明を行うほうがよいと思います。
レビューにかかる時間がほぼゼロになった
全員で一つの開発作業に取り組んでいるため、その成果物には全員で議論した内容が既に盛り込まれています。
そのためレビュー時に上がる新たな指摘はほぼゼロで、あっても細かい修正（ユニットテストのケース名など）のレベルにまで減らすことができました。
お互いのサービス・技術への理解度を知ることができた
日々の業務をリモートワーク体制で行う中、SlackでのやりとりやGitHubのPull Request上での会話だけではやりとりの相手がプロダクトのコンテキストや技術への理解度をどれくらい持っているのか不明瞭なことが多いです。
特に私などはコロナ禍中での中途入社、他のメンバーがどの領域にどれくらい詳しいかを推測しながら日々の業務を行うのはとても困難でした。おそらくみんなも私に対して同じ意識を持っていたのではと思います。
ですがモブプロで日々会話を重ねることでそれらをお互いに確認することができ、以後は相手の理解度に合わせたやりとりをスムーズに行うことができるようになりました。
メモの内容をドキュメントに繋げることができた
SCM開発チームは歴史が長いものの、ドキュメントはまだまだ整っていないところが多くあります。
今回のモブ体制はドキュメント充実が目的ではないものの、モブプロ中に取ったメモを空き時間で簡単なドキュメントとして書き直すことでナレッジを明文化することができました。
集中した状態を長く続けることができる
モブプロの場では常に議論や実装が進んでおり、普段の業務なら立ち止まってしまうところでもスムーズに進むことが多いです。
結果、全員がほぼ常に集中している状態で作業を進めることになり、脳のリソース効率が非常に良いと感じました。
気をつけたこと
意識的に休憩を挟む
先述の通りですが、モブプロの場では集中した状態を長く続けることができます。
反面、集中した状態で作業をしているとつい休憩することを忘れて作業を続けてしまうことが多くなりがちですし、集中した状態を長く続けること自体とても疲れてしまいます…
結果、適度に休憩を挟まないと業務終了後はグッタリしてしまうことも多く…
以後は作業開始時にアラームを設定してから開発作業に臨むようにしました。
行き詰まったらそのタスクは後回しにできないか検討する
作業中に困難に当たった結果行き詰まってしまい、作業が進まなくなった状態のまま時間が経過してしまうことを「ハマる」と呼ぶことがあると思います。
モブプロの場で全員でハマってしまうと、ハマった時間 × 人数ぶんの時間が飛んでしまいます。
タスクの内容やタイミングにもよりますが、ハマってしまった場合はタスクを後回しにしたうえで別タスクとして解消や調査のための時間を取れないか検討することにしました。
ドライバーが率先して進めすぎないようにする
最初に書いた通りですが、現在SCM開発チームではメンバー間でスキルや担当プロダクトについての理解度に差がある状態です。
ですので理解度や技術力の高いメンバーがドライバーになってしまうと、ドライバーは最初からどう実装すればよいか分かっている状態なのにナビゲーターは調査してみないと正しくナビゲートできない…という状態になることも少なくありません。
ドライバーは作業をスムーズに進められる状態にあるため実際にコーディングを進めてしまいますが、状況理解が追いついていないナビゲーターが置いてけぼりに…
というようなことがあり、掲題の通り「ドライバーが率先して作業を進めすぎないようにしましょう」と意識的に決めました。
具体的には2つのことを実施しています。
- テックリードはドライバーにせず、ナビゲーター限定での参加とする
- 実装方法などについて議論する際は、必ず全メンバーの理解度を確認する
今後の課題
「自分の力でやりきったぞ！」という達成感が得づらい
モブプロでは全員で思考し、全員で議論し、全員で開発します。ですのでその場で出たアイデアは「全員で出したアイデア」という認識を自然と持つことになりやすいです。
ですので、個人にタスクを割り当てて開発をしている状態（モブプロでないとき）では難しい実装をやりきったり
自分で考えたアイデアをPull Request上で他の人から「いいですね！」などと言われたりすると達成感があり嬉しい…！みたいな気持ちがあると思うのですが、そういった感覚を得づらいことがあります。
モブプロ期間がある程度続くとチーム内から「もっと自分の力でコードを書きたい」などの声を聞くことがあり、この辺りはタスクを調整したうえでモブプロする日・しない日を定めてみてもいいかも？と思いました。
簡単なタスクでも時間を使うため、チーム全体としての進捗が気になる
これは我々がモブプロをする目的の一つに「コンテキストや仕様の共有」を置いている以上、必要なコストとはしているのですが
ある人には背景や修正箇所がわかりきっているタスクでも、全員の理解を促すために解説をしたり足並みを揃える時間を取る必要があります。
結果的に1週間を通してチーム全体でアウトプットできる分量が少なくなり、「当然とは分かっていてもアウトプットの量が少ないと不安」という感情が湧いてくることがありました。
じっくり考える時間を取りづらい
皆さんは普段、設計やコーディング段階でふと違和感を覚え「何か忘れている気がする…」などと考えこむ時はありませんか？（私はあります）
じっくり考えることで新しいアイデアが思いついたり忘れていたものを思い出せたりすることもよくあると思うのですが、モブプロでは常に皆で議論しながら作業が進む状態であるため、この「ひとりで考えこむ時間」が実質的に存在しません。
そのため、いつもなら時間をかけて考えれば気付けたはずの考慮漏れが起きたり、後になって「そういえばこんな実装方法もあったな」と思いついたりと、普段なら作業中に気付けたはずのことを後になってから気がつくというようなことが増えました。
これについてはまだ明確な対策を打つことはできていないのですが、ひとまず必要コストとして割り切ってしまい、気がついたタイミングで別途チケット化などを行うようにだけしています。
ファシリテーターが大変
先述したファシリテーターは、他のメンバーと同様にドライバーやナビゲーターとしてモブプロに参加している状態です。
ですので、時には議論に積極的に参加したり、時には場のことを考えて議論をストップさせたりなどの判断をする必要があり、そのため開発や議論に集中しきれないこともしばしば…
ファシリテーターは一貫して私が務めているのですが、気を多く遣って非常に疲れるので、ある程度ノウハウが溜まったら明文化して他の人でもできるようなると嬉しいなーと思いました。
最後に
以上、約2ヶ月ほどモブプロをやってみた中での感想やノウハウでした！
最後に個人的な感想としましては、モブプロは働き方をある程度変えて行う取り組みなので、もし試験的に導入する場合でもある程度慣れるまで続けてみるとよいのかなと思います。
今回はチーム全体としてのアウトプット量などある程度トレードオフにしたものもありますが、チームビルディングやキャッチアップなどの観点からリターンの大きい取り組みだと思います。もし今後「モブプロってどう？」などと知人から聞かれたらオススメしたいなと思いました！
今回は長くなりすぎるため書けませんでしたがモブプロの場は技術継承の場としても非常によく、リモート環境下でのティーチングに悩んでいる方は是非試してみてはいかがでしょうか？
コンテキスト共有とモブプログラミング
Featured posts
in #Methodology
