はじめに
基幹システムグループの大里です。
新年度になってもう2か月になりました。新年度になってから部署替えやチーム編成の変更も生じるかと思います。
私の所属するチームは去年の6月に他のサービスを担当していた2人とチームが合併して3人チームになりました。このチーム編成の変更の際にまず立ち向かわないとならない問題として、自分が担当しているシステムを他のメンバーに理解してもらわなければならない問題が生じました。その際にシステムのコードを理解してもらう方法としてモブプロを選び実施しましたが、その時に工夫したことや所感などを記載します。
チームで実施したモブプロのルール
モブプロの基本ルール
チーム内でナビゲーターとドライバーで役割を分担する
- ナビゲーター：ドライバーに対しどのコードを見て、どのようなコードを入力するかを指示する
- ドライバー：ナビゲーターの指示を聞いてタイピングや画面切り替えを実施する
それに加えてコーディング中に疑問があったら質問・回答を行う
チームの独特なルール
モブプロを実施する前に修正箇所の処理の流れをチーム全員で検討・共有する
システムを理解している人は基本的にナビゲーターとして固定する
使用したツール
Visual Studio Code チーム共有で使っているエディター
Visual Studio Live Share リアルタイムで共同開発できるVisual Studio Codeの拡張機能、ドライバーの修正内容の共有に使用
Meet ビデオ会議ツール、音声を共有するためやVisual Studio Live Shareの画面共有に慣れるまでの画面共有に使用
draw.io 作図ツール、コード処理の共有や検討に使用
工夫したこと
オンボーディング資料の準備
システムを理解してもらうためのモブプロの前にチームメンバーにはオンボーディング資料を読んでもらって、以下のような知識を共通認識として持ってもらうようにしました。
- 担当システムでどういうサービスを実現しているのか
- 担当システムにはどういったバッチやAPIがあるのか
モブプロを始める前にコード内容は分からない状態であっても、担当システムの概要を理解してもらうようにしました。
設計書の記述もモブで実施する
設計書の記述もモブで実施することで、コードが分からない状態でも修正するコードのフローを議論できる状態にしました。修正するコードのフローを議論する際に、全体的なフローを設計書ベースで理解してもらえるように工夫しました。事前に設計を共有することによってコード記述をするモブプロをした時に、チームメンバーはコードの全体像を早く理解できるようにしました。
ナビゲーターはコードの記述するときの思考を言語化する
ナビゲーターとしてコードを記述する際に考えることを一から言語化して伝えることで、実際に修正するコードだけではなくその周辺のコードや基本的な処理を漏れなく見せることを意識しました。チームの背景としてチームメンバーはシステムで使用しているフレームワークを触ったことがありませんでした。モブプロを通してチームメンバーが一人でコードを読めるようになるため、チームメンバーにとって初めて触れるフレームワークの処理の流れを説明する必要がありました。モブプロ中はコード修正をするときに最初に実施するであろう修正するコードを探すところから思考を言語化することに努めました。
良かったこと
チーム全員で設計の検討ができた
設計書の記述からモブプロをすることによって、チーム全員で修正箇所のフローを検討できました。今回のチーム編成の変更では、幸運にも別のシステムの開発担当者と同じチームになりました。そのため、モブプロによって設計の議論を設計書ベースで考えることができるようになることで、コードを見たことがない開発者の知見を設計に生かすことができました。
副次的な効果として、設計に関してはチーム全員で責任が持てるようになったことが良かったです。このチーム編成の変更で担当システムの有識者が自分だけのような状態になり、自分の責任を重く感じてました。しかし、設計つまりコード修正の基本指針はチーム全員で合意が取れたことで、自分の気が軽くなりました。
実装力の強化
設計書さえあれば簡単な機能追加は各々1人で実装できるようになりました。これの要因の一つとして、モブプロ前にオンボーディング資料や設計書をチームメンバー全員が読み通すことで、モブプロ中は設計書をどのようにコードに落とし込むかの説明に集中できたためだと考えています。フレームワークの細かい仕様の理解ができていなくても設計書からコードへの落とし込み方を理解すれば、どのようにコードを記述すればよいかのヒントを各々で探すことが可能になりました。
反省点
疲労する
これにつきます。
システムに慣れないドライバーの負担が大きい
今回のチームでは3人構成であったため、1人がナビゲーターとして固定されてしまい、他の2人がドライバーとなりました。さらに、ナビゲーターは見慣れたコードの修正を口頭で説明するだけで、ドライバーであるチームメンバーにとっては内部を見たことがないシステムの説明を聞きながら読み続けることになります。ナビゲーターとドライバーで負担が異なることになるため、意識して休憩を取らないと集中するのが難しいと分かりました。
モブプロの時間が長くなってしまう
この工夫は設計のタイミングからモブプロを実施するため、時間が長くなってしまいます。上に述べたようにこの方法はシステムに慣れていないメンバーの負担が大きいことが分かったため、設計とコード修正で日を分けるなどの工夫が必要だと感じています。
終わりに
システム理解を最優先の目的としてモブプロを実施したため、本来のモブプロの方法とは少し外れたルールで実施することになりました。次は開発速度を上げることやチームメンバーがコードに慣れるために、モブプロの本来の方法で実施できるように修正が必要だと考えています。
