はじめに
前回までは何故か「である調」で書いていたので「ですます調」にしてみます。
(語尾を統一しようと意識していたら無意識のうちに「である調」になっていた…)
今回は前回の続きの記事です。
モブプロをやってみた感想になります。
プログを書いている時点でモブプロを2回やりました!
準備
1回目、2回目ともに以下のような感じで実施しました。
どちらも簡単な修正ですが、自分が中途入社したばかりでアプリの内容を知らないため、
設計とコードレビューの効率化を狙ってモブプロの対象としました。
また、Androidアプリと同じ修正をiOSにも入れるため、
iOS担当者への仕様伝達も目的のひとつ。
対象
1回目、2回目どちらもAndroidアプリを対象にちょっとした修正。
詳しい担当者なら1時間で修正完了し、
レビューまで含めても2時間かからないくらいの規模。
場所
モブプロ用に環境構築とかはしていないので、
会議室からメンバーのPCにリモートして開発しました。
ドライバー交代時のソースの共有
修正したソースをGit経由でやり取りするのが面倒だったので、
今回は私のPCで全員開発を行いました。
そのため、ドライバーが変わってもソースの共有をする必要はありませんでした。
やってみた感想。
結果として1回目、2回目どちらも1時間30分～2時間程度完了。
以下に良かった点と課題をそれぞれに挙げていきます。
良かった点。
- Android Studioの知らないショートカットを知れた。
- 影響範囲確認漏れに気づけた。
- 教える側もアウトプットするのが壁打ちになって良い。
- 修正する際のアプローチパターン増加
- 横展開する際の情報伝達速度、確実性、鮮度アップ。
- Androidやプロダクトに関する知らない仕様を知れた。
以下、詳細が必要な部分についてのみ補足。
2.影響範囲確認漏れに気づけた。
これは良いと盛り上がりました!
最初に影響範囲を調査した際は修正対象のキーワードでgrepして、
影響する場所を直すというよくあるパターン。
実装中に「あれ?あの機能も直さないとダメじゃね…?」となって、
その場で確認したらやっぱり対象でした。
たぶん気付いた人が担当していたら手戻りにならなかったけど、
自分がやっていたら気づかなかった(そもそもそんな機能があることも知らなかった)。
そのためコードレビューで気づくか、
そのままリリースしてさらに大きな問題になっていた可能性があるので、
モブプロの効果を実感したことのひとつです。
3.教える側もアウトプットするのが壁打ちになって良い。
やる前は分からなかったメリットとして、
教える側にもメリットがあることが分かりました。
例えばプロダクトに詳しい人は実装中に仕様を教える事が多くなりますが、
その教えるためのアウトプットによって自らも学べるという点です。
よりわかりやすい伝え方が出来るようになったり、
当たり前だった機能や実装を教えるために客観的に見直してみて新たな問題に気付いたり。
このように仕様や技術に詳しい人でも一方的に時間を浪費されるだけではなく、
メリットもあるということが分かりました。
4.修正する際のアプローチパターン増加
既存のコードに修正を加える場合、皆さんはどういった手順で作業していくでしょうか?
チーム内でもこの方法がバラバラでこの作業パターンが増えたことがメリットの一つになりました。
例えばメンバーの1人は修正が必要そうなソースの当たりをつけたら、
アプリのエントリーポイントから一個ずつソースを追いかけていき必ず構造理解をしていたそうです。
対して私は先に修正が必要そうなソースの当たりをつけたら、
さっさと直してしまいテストするやり方を取ります。
I/Fに影響がなければそこまでの処理の流れは追いかけません。
(I/Fに影響の影響というのは引数を増やすとか戻り値を変えるとかグローバル変数を変更するとか…)
どっちの方法が良い悪いではないと思いますが、
そのメンバーはそれしかやり方を知らなかったので新鮮だったと言っていました。
このような内容は分担作業をしていたら絶対に分からなかった点だと思います。
5.横展開する際の情報伝達速度、確実性、鮮度アップ。
今回はAndroid版アプリの修正をしましたが、
同じ修正をiOSにも入れる必要があります。
iOSは担当が別なのでいままでは個別に仕様を伝えて修正しレビューしていましたが、
今回はiOS担当も参加してANdroidの修正をしたので仕様伝達が最速となりました。
また開発中に発生した問題もリアルタイムに鮮度抜群で共有できたので、
iOS版では同じ問題は発生しませんでした。
こういった問題や追加仕様は口頭で言われると時間がたったときに忘れたりしがちですが、
自分もその場にいて経験すると忘れづらくなると思います。
(絶対に忘れないとはいいませんが…)
課題。
- 新卒の人間がチームに入ってきたときもモブでやるの?効率悪くない?
- すぐ答えが聞けてしまうと成長しないのではないか?
- 意見を表明し辛い問題
以下、補足。
1. 新卒の人間がチームに入ってきたときもモブでやるの?効率悪くない?
これは目的の違いだと思います。
たとえば障害対応ですぐコードを吐かないと行けない場合などでは入れるべきではないと思います。
ですが、新人の教育を目的としてやるのならこれ以上無い教育の場となると思います。
例えば簡単な修正を新人も入れてモブでやると、
どんな流れて開発しているのかも分かるし、
先輩も操作(ショートカットや調べ方の方法など)も学べます。
また障害対応でも、ドライバーをやるのではなく見学として同席して、
1人が説明担当として張り付けば良い勉強になるでしょう。
まとめると以下の通り。
- コード"だけ"出力したい場合は新人は参加させない。
- 教育目的であれば参加させる。
もし参加させないと判断した場合、
新人だけ黙々とやっていて先輩は楽しそうにモブでやるとかは絶対NGです。
そうなりそうならモブワークとして一緒のテーブルを囲いつつ、
環境構築をってもらうとかが良いと思いましす。
2. すぐ答えが聞けてしまうと成長しないのではないか?
バグが解決出来たときなどハマった時間が長いほど達成感を感じます。
そのため、モブですぐに解決出来てしまうと成長しないのでは無いか?という話がありました。
コレについては個人の感覚もあるので一概には言えないと思います。
ですが「成長」という点だけにフォーカスすれば、
一つの問題に時間をかけて解決した経験よりも、
複数の問題をすばやく解決していったほうがより多くの経験になると思います。
また個人としてはハマった事で記憶に残りますが、
それはチームにはまったく伝わらない知見になってしまいます。
チームで解決した方がメンバー全員に知見が残るので良いと思います。
この問題はモブプロの問題というよりも、
1人でやるか皆でやるかどっちが好き?という問題だと思っています。
そのメンバーは1人でやるほうが好みと言っていたので、
そこのミスマッチだと思います。
今までの開発ではレビューのときだけ会話すればよかったから、
そこだけ覚悟して臨んでいたようです。
チーム内の嗜好も含めて考えないといけないのが悩みどころです…。
3. 意見を表明し辛い問題
もともとコミュニケーションが苦手な人は意見を言いづらい、ということがあります。
(これもモブプロ固有の問題ではないのですが…。)
実装方針が決まって「これで良いですか?」と周りに聞くとみんなOKと言ったのに、
あとで聞くと実はあそこでココが…みたいなことがありました。
意見が言いづらいと感じる事はもう仕方ないので、
そこに合わせてコミュニケーションをする必要があると思います。
そのため、以下のような工夫をしてみようと思っています。
- 喋らなくても良いようにする。
例えばSlackや紙に書いて定期的にそれを確認するなど。 - 「これで良いですか?」「意見はありますか?」と全体に「はい/いいえ」で終わるような聞き方ではなく、
個々人に「どう思いますか?」「この実装方針の改善点は無いですか?」と聞くようにする。 - 座る場所を工夫する。
モニタのすぐ前の両側によく喋る人を置かない。
お互いに話して先に進んでしまうため。
よく喋る人は全体が見える位置に置いて、喋らない人に確認しながら進める。
感想
個人の感想としては非常に楽しい!
以下のような手順を踏んで開発するよりも効率的に進むのが実感できました。
- 1人で調べて設計して実装してコードレビューして差し戻しを食らって…
特に中途入社したばかりの自分には学べることが多いのでありがたいです。
チームで同意したアウトプットが出せるので前に進んでいる実感がたまらなく良いです。
今までは1人で悩んでいる時間が多かったので、
すぐ相談して先に進められる環境は非常に安心できています。
今後について
環境
今回は会議室からリモートで実施しましたが、
個々人にノートPC(Macbook Pro)を用意してやってみるつもりでいます。
ソースの共有はドライバー交代時にGit経由でpush/pullするつもりです。
続けるのか?止めるのか?
チーム内では1人でやる方が好きという人もいるので、
あと何回か試してみる予定でいます。
チームの大多数には好評なので継続していきたいです。
ですが、無理に押し進めて問題がでるのは本意ではないので、
なるべく個々のメンバーの負担が軽くなるように調整していきたいと思っています。
