# 一年間スクラムの中でリモートモブプロを続けて取り組んだこと、よかったこと

コロナ禍に際して、人々の暮らしが大きく変わった。対人との関わり方や食事に対する価値観、そしてワークスタイルも大きく変容した。

僕は最も大きく仕事のやり方が変わった社会人の一人だろう。

識者と対面で向き合えない中で始まった 新規機能開発チーム で取り組んだスクラム。

その中でも開発者に焦点を当てて、 モブプロ で培った経験をブログに残そうと思う。

物理モブプロとリモートモブプロの違い

先に読者には謝っておきたいことがある。僕たちが経験した新しいカタチのモブプロは今まで提唱されていたモブプロとは全く異なるということを。

当記事では、モブプログラミング・ベストプラクティス に記載してあるモブプログラミングの手法を 物理モブプロ と。

僕たちがリモート環境で経験した方法を リモートモブプロ と定義致す。

リモートモブプロと物理モブプロの違いを表に纏めた。

	物理モブプロ	リモートモブプロ
利用するツール	なくても開発可能	🙆‍♀️
コーディング環境	1つ	参加者にそれぞれ依存
開発者だけの空間	オフィス環境に依存	自身の作業環境に依存
ドライバーとナビゲータ	🙆‍♀️	🙅

参考： モブプログラミング・ベストプラクティス より引用

利用するツール

残念なことに、リモートモブプロを始めるためには専用のソフトウェアが必要だ。

簡潔に説明すると、ホストの開発環境を他者に共有する というものだ。

2021年1月17日現在では以下のツールが選択肢として挙げられる。

• Visual Studio Live Share

• Code With Me

ソースコードを同時編集できたり、ホストのコンソールを操作することができる。

細かい説明や仕様については割愛する。

コーディング環境

コードを書くプログラマにとって、キーボードやディスプレイどの物理環境は生産性や開発者体験によって大きな影響を与える、と僕は考える。

この点に関しては、物理もモブプロとリモートモブプロで圧倒的な違いが存在する。

物理モブプロの場合、モブメンバー全員が納得し、決めたコーディング環境を整えなければならない。

• 開発マシンのOS
• エディターのキーバインド
• エディターのテーマ
• キーボード
• ディスプレイ

開発者だけの空間

リモートだろうと物理だろうと、エンジニアだけの空間は必要不可欠だ。

それはソフトウェア開発に集中するために、ヘッドホンで世界の断絶を図ることと同じ意味を成す。

物理モブプロでは 会議室 が使われることが多く、リモートモブプロでは自分自身が作業環境を選ぶ自由と裁量がある。

何れにせよ、開発に集中できる環境を整えることは可能だ。

ドライバーとナビゲータ

これは公式のモブプロのやり方に倣っていないアンチパターンである。だが僕たちはそれを承知でチームに合わないと結論を下した。

そのため MobSter や mob timer は一切利用していない。

モブプロとして取り組んだこと

設計

設計で大切にしていたことは、 具体的な実装方法やコーディング内容は決めない ことだった。

僕たちにとっての 設計 とは方針決めであり、メソッド内の関心事については別タスクで進めるようにした。

ユーザ情報1件取得するAPI を例にとってLaravelの場合の設計方法をサンプルとして挙げる。

<?php

public function __invoke(
    GetUserService $service,
    $user_id
): JsonResponse {
    // TODO: サービス
    // $service = 
    
    // TODO: バリデーションで落ちた場合、422

    // TODO: DBに存在しなかった場合 404

    // TODO: 存在した場合 200
}

このようにメソッド内の具体的な実装はせずに、開発メンバーでコメントを残した。

設計が終わった段階で、僕たちはコメントのとおりにチケットを切り、スプリント・プランニングの時点でおおよその実装時間を見積もった。

実装

設計時点で残したコメントをもとにそれぞれ実装を進めた。

勿論、設計の時間とは別の時間軸で対応した。

例えば、以下のような役割分担を割り振ることもできる。

• メソッド名を考える人

• メソッドの引数を書く人

• ロジックを書く人

これはキーボードとマウスポインタがひとつしかない、従来の物理モブプロではありえない役回りである。

開発者ふりかえり

隔週で30分程度、開発者のふりかえりを行った。

毎日リモートモブプロを続ける中で 毎日する必要はない というチームとしての答えが出たことが理由だ。

開発チームが馴染むまでは毎回やってもいいかもしれない。

ちなみに、物理モブプロではもっと頻度が高い。

モブプロを継続してよかったこと

ほぼ属人化した開発環境

あらゆる文脈において 属人化 という表現はポジティブな表現ではないが、ここでは前向きな意味合いである旨を表明する。

開発者にとって、開発環境（物理）は譲れないものが各々あると思っている。

キーバインド、エディタやコンソールのテーマ、フォントサイズ、物理的なディスプレイの数や大きさ。

数え切れないほどのこれらの項目は、カスタマイズされた開発者個々人に依存しており、物理モブプロに挑戦したときは皆ここがストレスポイントになっていた。

大人数になればなるほど、ディスプレイまでの距離は皆が等しくないため文字が見づらい。

普段日本語配列でタイプしている人にとって、英字配列は ワケワカメ である。

この物理モブプロを経験したことのあるエンジニア以外理解されない問題が、上述したツールを利用することで解消できる。

自分の好きな開発環境で開発に向き合いつつ、チームとしてプロダクトコードを書くことができるのだ。

主語が「個人」ではなく「開発チーム」に変わった

チームが結成されて初めは様々な書き方や設計方法が飛び交った。

喧々諤々と議論が盛り上がるが、時間は永遠ではない。

だからこそ 開発チーム として、答えをどうするかという結論に帰結するようになった。

今までは個人がコードを書き、プロダクトを開発していくものだと思っていた僕にとっては雷に打たれたような衝撃であった。

チームで開発しているから、誰が書いても チームとしてのコードの書き方 になる。

もちろん、長年の悲願であった 正しいユニットテストの文化醸成 も果たすことができた。

コードの実装内容もチームに問い合わせがあるが、チームの誰もが実装方針を知っているため、実装に関する属人性は、チームの輪に広がる。

つまり、誰かがその場に居合わせなくても他のチームメンバーによって実装内容が補完されているため、ステークホルダーの安心材料になった。

最後に

きっと、緊急事態宣言下で人と会えない寂しさが募ったのだろう。寂寞の心の堰が切れた音がした。

とりとめもない話を自分がすればするほど、チームメンバーもたまには四方山話を聞かせてくれた。

リモートになって感じた、人の温かみ。己が、チームの一員であることの自覚。

結果、相手へのリスペクトを大前提 として開発メンバーの皆が自分の意見を表明はする文化が根づいた。

「最高のプロダクトをこのメンバーと作り上げたい」

開発方針に不満があったり、取り組んで善かったことに関して 開発者ふりかえり の時間をとって振り返ることで抱えていた問題を 代謝 することができた。

一人で抱え込まずに チームとして課題を解決する 意識を持ち続けたい。