組織パターンの「託児所」から観た、職人と初心者で構成されたペアやモブで発生する緊張関係

職人たちが新人を鍛えるのにすべての時間を費やしている。こんな言葉が耳に入り始めた。「できる人の無駄遣いだよ」あるいは「できる人が何人かいれば、プロジェクト全体がもっと早く終わるのに」。実際に、その職人は期待通りに作業を進めることができていない。新人を鍛えるために、エネルギーも時間も集中力も使ってしまうのだ。しかし、新人は職人が鍛えなければならない。当然のことだ。と同時に、プロジェクト自体も前に進めなければならない。それゆえ：.....

James O. Coplien,Neil B. Harriosn. 組織パターン (Japanese Edition) (Kindle Locations 2187-2191). Kindle Edition.

ペアやモブを実施すれば、全て万事解決というわけではない。進捗と学習の観点から上のような緊張関係は多かれ少なかれ、ソロだけでなくペアやモブでも発生する。むしろ、ペアやモブを実施することでこの緊張関係がより顕在化することがある。

何も工夫しなければ、モブは訓練にフォーカスして初心者に合わせると進捗についてのフラストレーションが発生する。一方、モブが進捗にフォーカスして初心者を置いてけぼりにすると、できる人はますますできるようになって、初心者は初心者のままとなってしまう。

託児所パターン（別名：進捗チーム、訓練チーム）では、職人同士の進捗チームと、初心者の集まりと一人メンター役の職人の訓練チームに分け、免許皆伝になれば順々に職人チームに送り込む解を示している。

託児所パターンを使わない場合に、　モブの際に進捗と学習の緊張関係をどのように解くだろうか？

本家のモブの場合は、ノー見積もり＆開発主導の進捗管理コントロールする強い権限を持つのと、１日１時間のスキルラーニングセッションで安心して学べる場の設定（１日１時間は学習にフォーカス、残りの時間を進捗にフォーカス）、アナログなスキルマップの可視化して習得への主体的なコミット（より能動的なスキル獲得の仕組みづくり）で対応しようとしているようだ。他にもなにか工夫はしてそうだが、文面だけではわからない。

まぁ、プログラミング基礎、Gitコマンド基礎、オブジェクト指向プログラミング基礎、関数型プログラミング基礎、データベース設計基礎、採用しているフレームワーク基礎、WebAPI設計基礎、ユニットテスト基礎、AWS基礎、ドメイン知識基礎などなどを全部実案件の現場の実務で学べばいいは、あまりに雑すぎる。ロールプレイングゲームに例えるなら下手するとレベル1でラスボスとの戦闘やロンダルキアの洞窟に潜っているようなものだ。

モブ中の工夫としては、知らない人が何をどう書けば良いかを積極的に聞きながら書き、こまめな小さなふりかえりで引き上げようとしている。他にも何か工夫はあるはず。

組織パターンで示した託児所パターンや、本家のモブのようなコツが使えないコンテキストの場合、職人と初心者で起こりがちな緊張関係（進捗を進めなければならない＆職人によって初心者の訓練が必要だが時間はかかる）を私たちはどうのように解けば良いだろうか？

余談だが、緊張関係をキチンと言葉にしててJim Coplienはえらいなと感想を持ったのでした。