モブプロはわからないことがわからないものを明らかにするものと見つけたり（長い）

ふりかえりの場にて、歴の長い人（シニアとする）と短い人（ジュニアとする）で進み方にばらつきがあるからなんとかしようという話になって、その解決のtryとしてペアプロ・モブプロをやろうという話になった。

その時に出た会話で「今でもわからないことがあればすぐにslackで質問することはできているのにわざわざペアでやって（リソース）効率を下げることもないのでは」という発言があった。

この発言を受けて、知識や経験の平準化という意味で確かにそうかもしれないなと一瞬思ったが、よく考えてみると一緒にやることで得られる知識には本人が気づいてない知識も含まれてるのではないかということに気づいた。

質問すればいいというのは確かにそうだし質問ができることは大事だが、そもそも質問をするには自分が何に困っているのかを知らなければならないし、それは質問できる。
しかし自分が困っていることに気づいていないようなことは質問することはできない。なぜならそれが問題だと気づかないから。

わからないことがわからない問題とは

自分だけでは気づかないような問題とは何か。

例えばVSCodeの機能やショートカット、拡張機能やコンソールのコマンドやショートカットなんかはそうかもしれない。知っていれば作業が効率化されるが、知らなくても作業自体は出来てしまっていると、意外と気づくタイミングがない。

他にはシニアなら数分でぱぱっと書けるようなコードをジュニアが1時間かけて書いているようなときである。これは個々で作業していると見つけるのが難しい。なぜならPRとしてはちゃんと出来上がったものが出せるから。

シニアと一緒に作業していればちょっと詰まってそうな段階で声をかけて取っ掛かりを作ることも出来るし、シニアがどういうふうに考えて実装しているかを話しつつコードを書くところを見せて学んでもらうということも出来る。

あとは社内の共通基盤やライブラリの機能を使えば一発で出来ることを知らずにわざわざ実装してしまったりなどもある。頑張って書いてPRを出したあとに「この部分はここの関数を使えばできます」とかコメントつけられるのは悲しい…。

実際にペアプロしてどうだったか

そんな事を考えつつも実際に常にペアプロ・モブプロという状態で1週間を過ごした。

知識の平準化

知識の平準化という点で見ても効果があった。

一応シニア枠の自分から見ていると、暗黙的に理解して従っている原則や思想のようなものがジュニア勢には自分が思っているよりわからないっぽいということがわかった。
しばらくは計画の段階で「これくらいわかるよな」のレベルをもう少し下げて具体的なコードの説明をすることが必要そう。

あとはプロダクトの設計方針に関する歴史的経緯が結構ネックになっていることもわかった。どうしてこういうコンポーネント構造なのか、変えると何がまずいのかをよく説明した。
単純に目の前の機能を作るだけなら問題なくても後続の開発で問題になりそうな部分の当たりの付け方などはやはり歴史を知っていることと経験値の影響は大きそうと思った。

あるいは設計に関する本とか記事とかを読んで勉強する会とかやってみてもいいのかもしれない。