リモート環境でも同じように楽しくやりたい！（後編）　〜2020年度 Coaching チームのモブプログラミング、オンボーディング事情 〜

再びこんにちは、 Quipper webエンジニアの @motorollerscalatron です。 前編には 自分の所属する開発チームでのリモート事情をとりあげました。後編では、そんな季節の中で、ちょっと癖のあるテーマ「モブプログラミング」「オンボーディング」をどうやって行って行ったかを、少し紹介させて下さい。

2 リモートで いつものプラクティスを続ける （モププロとオンボーディング）

ToC チームでは、もともと昨年度始め頃から、チームとしての開発力をあげる試みとして、「モブプログラミング」「オンボーディング」に注目していました。

この２つは、web開発者として様々な会社で開発プロセスを経験してきた中でも、私が Quipper に入社してから始めて出会い、挑戦してきたプラクティスでもあります。

そんな個人的な思い入れなんじゃないかと言われそうなこの２つのテーマについて、なぜリモートメインでの業務の文脈で改めて話すのかというと、以下のような理由があります。

• どちらも人と人とのインタラクションに関係の深いものだけあり、しかも暗黙的にデフォルトではオフラインでのやりとりを想定するようなプラクティスとして発展していそうである
• それでいて、この２つのプラクティスは現在のようなチーム特性をもったプロダクトチームの中では引き続き必要になるものであるし、有効に使えるツールである

モブプログラミングは （しつこく2回目の引用）@ohbarye の 新メンバーが多い大型プロジェクトでの不確実性との戦い方 にもあったように複数の異なるバックグラウンドのメンバーが入ってきている開発の中で、ドメイン知識の共有促進と、総合的な開発スピードの向上のために、意欲的に取り入れていたものです。

いっぽうのオンボーディングは、はやくは社内では @chaspy が SREチームでいちはやく導入、2019年度に短期間で web devs に新規メンバーが多めに join したときには、できるだけ立ち上がりを早くする目的で何ができるかを皆で考えた始めたムーブメントでした。そのときのエッセンスをテンプレート化する作業から我々が始めたものが、他チームでも取り入れられてもらい、徐々に様式の一つとして部内で定着しています。（この時期のオンボーディングの詳細なノウハウについては、昨年の夏頃に @motorollerscalatron が Engineer Onboarding Meetup にて、 プレゼン をしているので、ご興味のある方はどうぞ）

結論としては、どちらもリモートだからどうしても致命的な制約があったとはいうものではありませんでした。ですが、前編で述べた「新しいチーム体制」や「リモートのご時世」になってから特に面白い展開をした話だとも思っています。

今回はそんなお話にお付き合いいただければ幸いです。

2.1. モブプログラミング

2.1.1 今までやっていたモブプログラミング

私のいるチームでは、2019年度くらいにモブプロを「強め」に推し進めて取り入れていました。

最初は体系的なことを知りたいと思い、本テーマで頻繁にヒットする 「Code with the Wisdom of the Crowd」「mob programming - A Whole Team Approach -」の２冊 (※1) を読み、チームのメンバーにも一緒になってweb記事やソーシャルメディアでのアンテナをはってもらい、わかりやすい記事を共有して教えてもらったりディスカッションしたり・・で徐々に自分たちに合うモブの形を見つけて行っているつもりでした。

「流行るのかしら、これ。みな、続けてくれるんかな」

部内でそこそこ声を挙げてみたものの、正直リアクションをうかがいながら、月日が流れていったように記憶しています。

季節的に発生するタスクの種類の偏り、あるいは時間経過によるチームの構成や開発体制に移り変わりにより、あまりモブプロをやらない時期があってちょっと焦ったこともあります。ですが、自チーム外でも、新規導入技術を継承するようなワークショップの場でもモブプロが使われていくなど、目に見えて機会は増えていきました。

_{2019年、横断型のプロジェクトにて、モブプログラミングの形式で大きめのスペースでデモをやっているようす}

その頃には、次のようなタイプの案件には、特にモブプロが有効であることを体感し始めていました。

1. 開発者の中でも意思決定やレビューが時間を占めやすいような案件（開発者により設計志向の意見が分かれやすいタイプのタスク）
2. あるメンバーにとって新規ドメインとなる部分なので挑戦したいが、実は既に知識を持っている他メンバーがあり、アウトプット効率面から後者に繰り返しタスクが振られがちな案件

1 であれば、PRとしては爆速で完成したのにレビュー指摘が入りそれに対してテキストコミュニケーションでは十分満足できず、さらにそのレビュアーとのアポがとれずなかなかリリースできない、というのが防げます。

2 は、実際の問題解決への取り組み方を同じ目線で同時間軸で見ることで、短時間で現実的な問題解決のスキルトランスファーが可能です。また、その中でわからなかったとしても、どこまでわからなかったのか、が当事者間で体感的に共有されるので、次のアクションも組みやすくなります。

「○○勉強会」のようなくくりで抽象化したイベントとして開催したりその中にモブプロを取り組む、というやり方もあるのですが、実際issueベースでモブプロをやってみるとより小さい時間差でちょっとした知識差にお互いがすぐに気付けることでより納得のいく伝承が可能だと実感しました。

実質、オフラインで既にこれらを1年ほどやっていたことで、私たちにはある程度の慣れがあったと思います。その頃はたいがい皆オフラインか、せいぜいリモートからは一、二人が参加する（リモート側が少数派）のような形で行っていました。

2.1.2 リモートだからこそ、カジュアルに

リモート体制でモブプロをやる時期になった折には、ちょっと構えてしまい、何かと資料にもあたりました。

本をこっそり読み返したのですが、たとえば、先ほどの 「A Whole Team Approach」には 4.9に "remote mob programming" というそれらしい節がありました。ところが、こういった本ですらも、皆がリモートだけで仕事をしている、という環境を想定して話されていても、完全な今日直面している環境の問題を想定はしていないようでした。本を読み直してみると、「リモートで声をあげる時に発話がかぶらないようにする、そのルールをどうするか」「（自分たちの現在の状況をメタ的に）上手に説明をする必要がある」など、モブプロに限るというよりは複数人でリモート会議上で問題解決をしていくとき全般のアドバイスのようなものが主でした。

それでも、改めて置かれている状態を本の内容と照らし合わせて見直してみたときにひとつ目にあたったのが、

・リモート環境ではキーボードをどうシェアするのか（オフラインみたいに、「ハイ」と隣に渡したりできない）

という問題でした。

全員がリモートの状態であっても、基本的にモブプロの手順はいつもと同じです。

• モブタイマー（※2）を準備
• ナビゲーターとドライバーを決める
• 一定のインターバルでセッションを行い、タイマーが切れたところでドライバーを次の人にまわす（ローテーション）

最初は以前通りナビゲーターとドライバーをローテーションするようにしていたのですが、コーディングの分量やコミュニケーションの質を考えて、最近は VSCode Live Share (※3)を積極的に使うようになってきています。Live Share には特定のプロジェクトをシェアした状態で個人の手元にあるプロジェクトに各自のエディタ画面で皆が編集を加えていくことができます。

Live Share でやる場合には、時には説明と行動への反映の差分を狭くしていく上でもドライバー・ナビゲーターの分担を意識せずに、わりと自由に皆必要なところで声がけをしてキーボードを打って、「これでどうでしょう？」と進めたりしています。

オフラインでのモブプログラミングでは、ドライバーなどが決まっている状態でもキーボードを渡したりすることで即時的な協業ができるのですが、オンラインではエディタそのものをシェアすることができないので、これはありがたい機構です (※4)。

2.1.2 モププログラミング の再評価と課題の再発見

もともと今期モププログラミングを積極的に取り入れたのは、前記事でもふれた通り、2020年度での新体制において、これまではそれぞれ別々のチームで開発していたメンバー同志が混じった中での、メンバーのドメイン知識の属人化排除と共有を促進することが目的でした。知っている立場の人がモブプログラミング型で進めることをslackで宣言して積極的に人を募り、逆に知っていない立場の人はドメインA側の人が「ここはドメインB側の人もいれてペアプロでお願いしたいです」と声をあげれば極力モブで進める、として、普通のスプリントの中でタスクを消化していく中でスケジュールとして「共有の時間」をそれほど切り出して設ける、知識が伝承されていきました。(※5)

モブプログラミングは、複数の人数を拘束した状態で、見かけ上全体の開発速度としては落ちている（ように見える）ことがあるのですが、

• メンバー間での実装の細かい考えの違いを揃えていくのにかかる時間がそこに吸収されている
• 実は、各人の進め方・考え方や、それに基づいた細かいスキル伝授もその時間で行われていく

という部分にメリットがあります。前年度でもそれを体感してもらっていたことで、今期は違和感なくチームに導入してもらえて、リモート中心のような制限下でも、短時間でお互いへのスキルトランスファーが行われていきました。

一方で、ここまで解決していても、いくつか問題はありました。

以下はチームの KPT などで出ていた話です：

• （参加者の一人でも）MTG がたくさん入ったり時間変更の難しいスケジュールを持っていると、モブプロが分断されてしまう
• web devチームのようにやってみたいが、 Native だと開発環境や人数の関係でうまくできない

_{たとえば採用系タスクなどでスケジュールが動かせないメンバーがいると、モププロセッションが分断されがち}

これらはまだ完全な解決策を見出していませんが、 KPT で PM や他メンバーも交えて話してみると、そもそもデフォルトで必要以上の人数を拘束してスケジュールがつまりすぎている時間なども見つかり、予定していた会議をそのKPTの直後に解体する、という面白い事象が起こりました。

モブプロはいくつかある進め方のうちのひとつだと考えています。時には通常の個人でタスクをカンバンをとっていくやり方でやってしまうこともあります。チーム内では「雑」な meet 呼び出し を行っているので、ある時まで個人でやっていたものを必要に応じてモブで入ってもらう、など、最近ではフレキシブルに対応しています。

_{単独タスクを途中モブプロに展開し、セッションで得られた feedback を得て、再び自己タスクに戻した時のメモ}

2.1.3. いまでも、モブプロで苦手と思ってしまうことはある

と、ここまでこんな風に書いていると、読者の方は、私がもともとモブプロみたいなグループ手法に最初から相性が良かったようなタイプの人だったのでは、という印象を受けられたかもしれません。

ですが、私はもともとグループで何かをすることの効率にはどちらかというと懐疑的な方でした。 今までの働き方で自分がそういうことをしてこなくて、なんとなく合わないのでは、と思っていたのかもしれません。

私がモブプロ中の個人的に悩みと自覚することは色々あるのですが、コミュニケーションまわりでちょっと考えただけでもこれだけ出てきます：

• （ナビゲーターとして）自分が何をしようとしているのかうまく言語化できない
• （ドライバーとして）自分が受けた指示の意味がよくわからないときに次のアクションが止まってしまう
• わからないところで止めてね！と言われていても、自分だけに何かわかっていない、ように感じると言い出しづらい・・

何も、リモートのときだけ発生する、というわけではないのですが、リモートのように、声も表情も限られた帯域で見える状態だと「きちんと伝わっているかどうか」を知るのにも神経を使ったりします。マイク、しかもネットを通じてという装置を通したとき、そして視覚的情報が限られた状態で説明をするとき、コミュニケーションの難易度は上がっていると言えそうです。

先に挙げた文献をたどると、処方箋としては「そもそも初めからうまくことを期待しない」「その都度質問を細かくくりかえしていく」ということで改善していくような話だったので、ちょっと基礎的すぎるかな？と思うことも今のモブプロでは、基本に立ち返って、なるべく言葉にするようにしています。

さらに私の場合は、もともと考えながら話すと、しどろもどろな発話になりがち、というのもあり

• できるだけ文を区切る、まとめてから言う。
• 会話のターンを考えて、自分が次に話す番になっているとわかった時に、落ち着いて話す。
• ビデオはできれば何かしら表情が見えるように ON にする

などを最近は、心がけています。

2.1.4. 人それぞれのモブプロの捉え方

内向的だったら向かないか、というとそうでもないみたい

Zuillの本（※1） の5章、各体験者からのレポート集のなかで語られている体験の中のひとつに、私が自分自身と重ね合わせたものがありました。その節は "Mob Programming for the Introverted" というタイトルで、自分がintroverted(内向的) であるということを自覚している筆者 Aaron Griffith が、性格上向かない、と思っていたモブプログラミングをちょっとした工夫でどうやって心地よく感じられるになったかが丁寧に書かれています。この節の著者はコンピューターサイエンスの専攻で学校を卒業してスクラム開発まで普通に経験してきて、モブプロを積極的にやっている新しい組織に移ったことを契機に、各々の段階で生じた気持ちの変化をトレースしている、珍しいレポートでした。

そこで、内向的な人間として、モブプロの方法論に衝突しそうと危惧された内容の中には、以下のようなものが述べられていました。

• レベルが異なる人が集まっている状態で流れを止めるような発言をしていいのかなどの葛藤が生まれる
• 心を開く（人と打ち解ける）のに時間がかかる
• グループ作業よりソロ作業が好き
• 自分が注目の中心になるのが心地良くない
• 話す前に考えがち

などなど、私自身も、完璧にこれに一致するとまではいかないまでも思い当たるような思考パターンを同じように経験したことがあったので、この人はどうやって克服したのだろう、と気になって読み進めていました。セクションの後半になると自分の変化と成長についても述べています。

• 数名程度のモブでは心地良いと感じ始める、人数が増えると再び不安に
• 人が途中で入れ替わるモブも落ち着かない

が、

• そういった不安からチームを固定したいと思う一方で、「学びたい」という観点からは、ペアリングやチームを積極的に変えたいという思いで自分が引き裂かれるよう

になり、結局のところのアドバイスとして言えるのは「フィードバックを与え、受け取ることにオープンになる」というまとめ方になっていて、なるほど、というよりは、そうなんだ、という気持ちでした。

私自身はたいがいは３、４名で固定メンバー、たかだか６人程度でしかモブプロミングを経験したことがなく、違った環境変数もあるとは思うのですが、どこか自分が心地良いといった部分から無理なく取り入れていくというのは自分もそうだったかもしれない、と思ったものでした。

ひとつの正解があるわけではない

生産性の面でいうと、私個人は最初の頃は、以下のようなコンプレックスがありました：

• エディタの使い方が疎かったりそもそもコードを書いている言語仕様とかがわかっていなかったりのボロが出ないか不安でいると、人前で何も手が進まなくなってしまう
• インターバル単位で他の人との生産性を比べてしまう。例えば、自分がドライバーのターンでコードにほとんど進展がないと、その度に落ち込んでしまう

ですが、最後は気にならなくなってしまいました。それより完成していく喜びのほうが強くなったとも言えるかもしれません。

チームのメンバーはメンバーで、また各々の性格や考え方によって全く違う考え方をしているはずとふと考えてしまうこともあります。ただ、その違いがあるのも、今は気にならなくなっています。

ひとつ視点を上にもっていくと、グループとしては、モブプロで開発を進めるときの生産性については、体験を繰り返す中でときには懐疑的になりながらも、わりと時間をかけて各自が利点を見出していきそれがチームで最大化するところでみな「ここではモブプロで進めよう」を声に出せるようになってきていることを体感してきているからです。

今季、単独作業になりがちなリモートでやっていると、閉じていた単独作業の世界からモブプロの予定時刻が迫るときは、いまだに緊張するのですが、やはりチーム感を感じるのもモブプロであり、そんな中でも今ではモブプロをやらない日のほうが少なくなってきている、という状況をちょっと面白く感じている次第でもあります。

2.2 オンボーディング

2.2.1 オンボーディングでの課題

もう一つは、オンボーディングという作業をリモート上でやる必要が出てきました。

基本的にはモブプログラミングと同じような形で google meetup で参加して画面共有をする形となるのですが、机を並べて他の人も仕事をしている場でのセッションではなくなったことで、今まで私たちが誇りにしてきた「オープンな形でオンボーディングを」ができないのは、ちょっとしたフラストレーションでした。

最近では、ToBチームの新異動メンバーへのオンボーディングのふりかえりインタビューを経て、次のようなことをヒアリングしていました。

devs handbook に鮮度の高いドメイン知識が文書化されていてよかった
事実上のドメインエキスパートともいえる @kechol によって説明されたのでフォーカスも外れていなかった
暗黙知が思わぬところに落ちていて、文脈を知らずに議論に参加してしまうとつらかった
リアルな歓迎会などがやりづらいと残念・・

リアルな場でやっていた ○○ のようなセレモニーイベントがしづらい、というのは他の場でも言われていたのですが、やはり今の社会情勢ではなかなかリスク上やむをえない部分もあります。

そんな中、私たちがなるべく今まで通りやっていることとしては、

• 予定共有をわりと大きめのチャネルで雑にしてしまい、観客に来てもらう
• オンボーディングを行うチャネルを、人ごとに作って、よりパーソナライズ感を出す
• 今まで通り完了インタビューを行なってセレモニー感を出す

といった試みです。

上記のインタビューはオンラインのMTGで行いましたが、中継自体もオープンな slack で行い、つながる話題と一緒にslackチャネル内に投稿されていくので、即時に ポインタを示すこともやりやすいです。また、終わり側に「業務で直接関連する人以外とはなかなか話す機会がなかったので良かった」というFBもあり、オンボーディング関連イベントの思わぬ利点があったと思いました。

_{SRE チームでの new joiner @int128 が join 後に早速 onboarding用のチャネルに案内されている様子}

ですので、課題はこのチャネルの存在を今一度より大きい組織単位へ周知することかとも思っています！

2.2.2 垣根を超えたオンボーディング

新チームでは、複数の職種の人がプロダクトに向かうようになり、担当する分野にはよりフォーカスした知識が求められている部分もあります。最近では、web dev team の一員として自分がドメイン知識を共有するため　Native devのメンバーやデザイナーに対してオンボーディングを行ったこともあります。

_{もともとは、簡単な説明会として考えていましました・・が、}

結果としては・・、説明会としては思ったより難易度が高かったことがわかりました。

まずは、リモートでの操作体験の共有は、予想通り難しかったのが一点です。オフラインならワークショップ的にやって、手を挙げた各メンバーのもとに説明しに行ったりできるのが、オンラインでは基本は１つの画面を皆で見ることになり、共有される側（複数人）もペースを合わせたりどこで相槌を打ったらいいのか、と思いながらだとそれなりの集中力が要りそうです。（デモの準備が少し不十分だったのも反省点ではありますが・・）

ですが、もう１つ時間変数に影響された要因がありました。オンボーディングはタイミング良くやるとより効率的だった、という点です。

期初は、かなり coaching ドメインの特殊なユーザーのフローやアプリ構成などの理解に苦労しているという声をもらっていたのですが、結局この説明会を実施する頃には、どのメンバーもある程度この数ヶ月の業務で知識を獲得してしまっていたため、 まっさらな new joiner の状態ではありませんでした。ドメイン知識がほぼない状態なら、ある程度説明する側が体系を作って説明することができるのですが、実際は受講者に質問を受けると、それぞれが独自の視点で質問や提案を持っている状態であることがわかりました。それなので、説明をしてみると、「もうそこはだいたいわかっている」ということで逆に「最初にこういう説明をしてもらうと、わかりやすかったのに！」という部分を説明する立場の自分が学んだりする時間にもなったのでした！

_{説明会のつもりが、自分がいろいろ既存のオンボーディング課題に気がつくことにもなり・・}

とはいったものの、結果 web dev team の側のオンボーディングの改善にも役に立つフィードバックが得られたことはありがたい事実です。

私たちはチームごとのオンボーディングプログラムは「テンプレート」を用意していってはいるのですが、往々にして本当のメンバーが加わらないと更新が行われない、というジレンマもあるのでこういったタイミングでこまめにテンプレートを更新できたのも収穫でした。

3 番外編: 共有slack と snippet という救い

ということで、後編のモブプログラミング・オンボーディングについてまではここまでとなるのですが、この番外編では、私個人がリモート中心になってから悩んだときに、救われたという既存のツールについて改めて話してみたいと思います。

3.1 slack で直接業務にかかわらないことも話す

slack はもともと quipper では github issue と伴って使われているメインコミュニケーションツールの一つですが、即時性の強さと平等なコミュニケーションという意味では、不可欠だと思っています。

リモート中心になってからは、対面でのコミュニケーションが断たれたせいもあり、slack やビデオ会議などのオンラインコミュニケーションでの情報をより深く読み取ることを強いられていると思います。 ですが、既に @akane-suzuki568 の 「Quipper 流の STAY HOME」 でもあったように、 remote-tips-ja というチャネルができ、機材や環境に関するちょっとした話題を話せるようになりました。

もともと quipper では slack チャネルの中に、写真や、犬猫などの動物をテーマにしたチャネルなど、ひと息つきたいようときにも見られる場所があります。もっとオフラインのような雑談感を醸し出そうと、いろいろな試みを模索中ではあるのですが、手軽にいろいろな話題で人をつなぐことができる場があることが、今の仕事のしかたではよりいっそう貴重に感じています。

また、quipper の特色なのかわかりませんが、slack のチャネルで話題がそれたりすることでも、急にリダイレクトを急かしたりせずに、その場でレスとして話題を進めていくのを比較的許容してくれることも、交流の促進を産むことを始め、実は心理的安全性を担保する大事な機構として、どこかで行動様式にインストールされているのかもしれない、と分析もしています。

_{fishチャネルは シェルの話をするチャネルをするはずだったが、いつの間にか・・}

3.2 issue にするには内省的すぎる内容かな？と思ったら、 snippet に

Quipper では github issueで面白い使い方をしている部分があります。それは、プロジェクト要件とかでなく、わたしたちが「ポエム」と呼んでいるものように専用の プロジェクト snippets があるということです。

_{snippets プロジェクトは、もっとフリースタイルで仕事に関するあれこれを書いていくのを許容してくれる場。そう感じ取って、「自身」とつけたのが私の モブプログラミングをテーマにした snippet の連載の始まりになりました。}

ポエムときくと何か完全にプロダクト開発作業とは別の余興か何かを想起してしまう方もいらっしゃるかもしれません。弁解すると、snippets は ポエム専用に作られたものではありません。実際、日報、先行技術調査、オフィス周辺のランチ事情、会社の備品購入の雑談相談などなど、書く人で内容はさまざまです。あえて定義するなら、「直面する業務とは関係ないが、会社生活の中でみんなにも見られてもいい、けど独り言っぽい文書」をしたためる場所と言えるのかもしれません。

もちろんここだけでなくても、例えば slack には自身の times チャネルを作ってそこに自身の世界を展開しているメンバーもいます。ある目的に対して手段の多様性を認めているところは Quipper が会社の five identities で提唱している diversity の実現形の一つだと思っています(もちろんそこには自己責任と ownwership の追求も伴ってはいますが)。

そんな中でも、私はというと、もともとエッセイや創作は好きなほうでしたし、純粋な技術情報的価値はともかく、後になってチーム開発を振り返る時にある程度読み返すことも考えて、times よりかはある程度形に残る snippets を好んで書くようにしています。本題とはずれますが、こういった outlet の部分を単一フォームに規定しすぎないゆるさも、 Quipper のもっている diversity の一つのような気がしています。

3.3 リモート業務中心の生活になったときに、不安をまわりに共有したら、楽になった

(多くのIT系の会社で務める方もそうだったとは推測しますが)リモート主体での業務が始まると、勤務時間以外の生活もいびつな部分が生まれてきました。特に最初は世の中の様子も刻一刻とチェックしていなければという強迫観念が生まれて、遅くまでニュースを見たり、それがおさまると今度はネットの情報を必要以上に pull してこないと気が済まなくなっているような状態になったり。

また、リモート会議でもちょっと沈黙が続いたとき、あるいは皆が一度にしゃべって一瞬集中力が削がれてしまった時なども、ききなおせばいいのにパニックしてしまったり、自分の行動のひとつひとつがあたかも何か仕事の進行を疎外しているような妄想にとらわれることもあり、冷静に考えるとそんなはずはないのですが普段と違った気持ちになっているの自覚しつつ気づかないふりをしているもう一人の自分をなんとなく見ているような状態でした。

今見返すと、社会情勢に対する漠然とした不安はある程度社会的にも認知されている状態だから、自分もそんなものなのだろうか、と思ったまま本当は気持ちは沈んでいっていったのかな、とも思っています。そうやって暮らしていた時間もあったのですが、言語化しないでいると何も学びがないのではないか、と思った時に、やはり自分にとっては一番声をあげやすかったのが、slack と snippet というメディアだったのでした。

不安の解消や困難の克服の方法は、人によって様々だと思います。

仕事の場が全てを解決することを期待しすぎてもいけないとは思いますが、さまざまな形で変化を受け止めることのできるチーム体制や組織体制があるというのが、これまで以上に強く感じられた季節だったと思います。形は時代を経て変化していくのかもしれないですが、共感と信頼の場があり（そこで初めて忖度なく議論もできる）ことが長期的なエンジニアリング文化の形成につながっていくのかもしれないです。

4 まとめ

以上、前編後編と、リモート環境での 新しいCoaching チームの事例を紹介いたしました。

開発プロジェクトと同じで開発チーム体制もいつでもワンアンドオンリーなのは世の常だと思いますが、少しでも事例が皆様のweb開発に役に立てば幸いです。また、役に立っていなくても、お読みいただけたのなら、それも幸いです。

Quipper では webエンジニアをはじめとした各種ポジションを募集しております。

https://www.wantedly.com/companies/quipper/projects

5 注釈

※1:参考文献

Code with the Wisdom of the Crowd: Get Better Together with Mob Programming Mark Pearl 日本語書籍版は、 モブプログラミング・ベストプラクティス

mob programming: A Whole Team Approach Woody Zuill and Kevin Meadows

※2: mobster というもあるのですが、今、coaching チームでは mobu という @pankona のお手製ツールを使っています。web版は モブは祝い というめでたい名前で、チームの皆が祝福された気持ちで使っています。

※3: これは私の大好きな vim がモブプロに使えないというおおきな欠点があり、今は泣く泣く自分の作業用に使い分けています。

※4: zoom には直接シェアされている画面のリモートコントロールを取る、という手法もあるのですが、皆エディタの傍には、自分が開きたい資料やslackをおきたいので、VSCode のようなスタイルが、今のメンバーには好まれています)

※5: 本筋とはそれますが、もともとここに私が個人的なモチベーションがはたらいたのは、キャリア経験上の一種のトラウマがきっかけにもなっています。知識が属人化した状態を解消するのを、その人が抜けるタイミングに全部寄せていると、たいてい継承し切れない（かった）、という過去の経験があったこと。それもあって、ある知識が一人に閉じている状態を必要以上に長期化させたくないというのがありました。と同時に、「最後までこのプロジェクトにいるはずだった人が一定期間または恒久的に抜ける」というのは避けられないことだと思っていて、かといって最初から抜ける分差し引いてリソースを計算するのも、プロジェクト上許容してもらえることがないと経験上感じていました。（ここでいう「人が抜ける」というのは組織上のものにかかわらず、個人的な都合で１日会社に出られない、とかも入っています）

※6: 「モブプロだと遅くなる」の話題については、「Code with the Wisdom of the Crowd」 の8章、 Mobbing Over Time あたりを再読していました。ほかにも、新しい人が加わった場合、経験が浅い人が入った場合にも触れていて、面白い章です。