はじめに
こちらは弥生アドベントカレンダー2021の16日目の記事です。
こんにちは。新卒1年目エンジニアの田邊慎史と申します。
SMARTという、銀行の明細や紙の領収書などの様々な「取引データ」を「会計データ」に変換する機能を開発しているチームに所属しています。
入社してからまだ8ヶ月ですが、以下のように過ごしてきました。
2021年4月：新卒として弥生に入社。 2021年6月：開発本部システム開発部に配属。導入教育・開発研修を受ける。 2021年9月：SMARTプロジェクト業務を開始。
さて突然ですが、皆さんは個人作業とチーム作業のどちらが好きですか？
人それぞれだと思いますが、私は個人作業の方が好きで、黙々と一人で没頭するのがとても好きなタイプです。
しかし、開発本部配属直後の開発研修において、チーム全員での作業（モブプログラミング）をすることになりました。
最初は正直あまり乗り気ではありませんでした。しかし、実際にやってみたら奥が深く、楽しみながら学ぶことができました。そんなモブプログラミングの面白さについてお伝えしたいと思います。
研修の内容
モブプログラミングの話に入る前に、少しだけ研修の説明をします。開発研修は以下の3つのフェーズに分かれていました。
今回はチーム開発に焦点を当ててお伝えします。10営業日にわたり、他の新卒2人を含めた3人チームで、モブプログラミングによるECサイト改修を行いました。既に完成している、最低限の機能をもつECサイトを改修するというチーム開発でした。
モブプログラミングとは？
モブプログラミングとは、複数人で1つの画面を共有し、同時に1つの作業を行う開発手法です。
- タイピスト：1人。キーボードを持ってコードを書く人。
- モブ：他の全員（今回のチーム開発では2人）。画面を見ているがキーボードは持たない。タイピストに指示を出す人。
モブが「このコントローラーにこのメソッドを追加してください」や「このメソッドの引数を修正してください」などの指示を出します。タイピストはその指示を受けてコーディングを進めます。
このロールを3人で15分交代で行いました。
やってみて感じたメリット
モブプログラミングを初めて知ったという方は、「こんな方法、非効率じゃないの？」と思った方もいるかもしれません。ちなみに私はそう思いました。 最初に書いた通り、私は一人で黙々と作業するのが好きなタイプなので「全員でやるのはどうなんだろう......?」というのが第一印象でした。
しかし、そんなタイプの私でも、実際にやってみるといくつかのメリットに気づきました。
知識習得・定着がしやすい
常に一緒に作業しているので、分担作業に比べ、チーム内での質問も多くなります。質問はする側、される側両方にメリットがあります。質問する側は疑問に感じたことをすぐに聞くことができます。質問される側は、質問に答えることで理解が深まり、自分の理解不足に気づくこともできます。
特に「質問される側」という点がポイントです。通常の研修であれば、受講生が質問されることはあまりありません。しかし、質問されることでアウトプットの機会を得ることができ、理解を深めることができます。
私も、「理解したつもりになっていたが質問されると答えられない」という場面から、改めて公式のドキュメントを確認して理解しなおしたり、自分の勘違いに気づいたりすることがよくありました。逆に、他の人のコーディングのやり方も見ることができるので、「他の人はこうやって考えるのか」「こういう実装の方法があるのか」などと勉強することもできました。
情報共有のコストが低い
分担作業を行っていると、事前の打ち合わせで合意したはずなのに、完成したものを見せたら相手と認識がズレていた、ということはありませんか？どうしても分担する場合は情報共有を入念に行わないと認識がズレることがあると思います。
しかし、モブプログラミングでは、同じ作業を皆で行うので、そのような認識のズレが起こりづらいです。もし起こったとしても、その場ですぐに修正することができます。そのようなコミュニケーションコストがかかりにくい点は大きなメリットになります。
実際に作業をしていて、UI上どこにボタンを配置するか、またあるメソッドをどこに配置するかなどで意見が分かれることがありました。そのような際に、言葉だけで自分の想定を伝えようとしても伝わりにくかったり、間違って伝わったりしてしまうことがあります。しかし、モブプログラミングであれば、全員で同じ画面を見ているため、実際に実装してみて見比べるなどができます。そのようなコミュニケーションの齟齬を防ぎやすいことも含めて、モブプログラミングにはコミュニケーションコストを減らすメリットがあると感じました。
品質の高いコードを書ける
常に複数人でコーディングするので、間違いに気づきやすいです。いわば、常にレビューしあいながらコードを書いているという状態です。
実際に作業していると「そのメソッドの引数の型がおかしい」「その条件分岐だと正確に分岐できない」などと、指摘がチーム内で出ることでミスを減らすことができました。さらなるメリットとして、他人から指摘されることで、「自分はこういうミスをしやすいんだな」と気づけることもあります。
難しかったこと
そんなモブプログラミングですが、もちろん良いことばかりではありません。良い部分だけ抜き出してお伝えしてもフェアではないので、難しいと感じたこと、どう対処すればよいと思ったかについて以下でお伝えします。
詰まりやすい
これは初心者の研修特有の現象かもしれませんが、分からないことに詰まってしまうことが頻繁に発生していました。
通常のモブプログラミングでは、集団でコーディングすることでみんなの知識を総動員させることができるので、問題を解決しやすいというメリットが挙げられることが多いです。
しかし、我々新卒3人のチームでは、それぞれ持っている知識が広くはないため、分からないことを全員で解決させることが難しかったです。基本的に全員持っている知識に差がほぼ無いので、詰まったときに誰かが解決できるということは少なかったという印象でした。
もちろん今回は研修だったので、詰まったときにどう調べて解決するかという点も含めて勉強になりましたが、実際の業務では、技術面をリードできる人がいたり、知識のプールが異なる人と一緒に実施したりすると良い形になるのではないかと感じました。
意思疎通ができないと困る
常に一緒に作業する以上、コミュニケーションを取りながらの作業になります。意思疎通の機会の多さは、上記のように質問しあえるという大きなメリットにつながります。しかし、逆に言えば、コミュニケーションがうまくいかないとモブプログラミングの利点を活かせません。
今回の新卒チームは4月から一緒に研修を受けてきたので、すでにコミュニケーションを取りやすい関係性が構築できていました。そのため、モブプログラミングを進める上で困ることは殆どありませんでした。しかし、そのような関係性が無い状態で行う場合は、指摘しづらい、質問しづらいなどの原因で、モブプログラミングが進めにくくなる可能性があります。
業務でモブプログラミングをやる場合、関係性ができているチームメンバー同士では特に問題ないと思います。ただ、これまで関わりがあまりなかったメンバー同士でやる場合は、アイスブレイクなどを通してコミュニケーションを取りやすい関係性を構築することも重要だと思います。
まとめ
モブプログラミングの良かったところ、難しかったところについて、私の体験で感じたことを紹介してきました。
自分の知識を深めることができ、さらに他人の持つ知識も得ることができます。また、煩雑なコミュニケーションコストを低減でき、そしてバグの少ないコードを書ける、そんなモブプログラミングの面白さが皆さんに伝われば嬉しいです。
