モブワークがチームの中に溶け込んでしまうということ

## 今週は全員同席モブワーク

先週はこういうことを大阪からのリモートでやってた:

bufferings.hatenablog.com

今週は東京に出張だったので、僕も入れて4人で全員同席のモブワークを実験してみた。そしたら、沢山の学びがあった。

## 実験:モブワークが日常な場

今回のモブワークで実験してみたかったのは、モブワークが日常な場。つまり、チームにとってモブワークをすることが普通で、それ以外が非日常な場。

これまでもモブワークはしたことがあったのだけど、モブワークをすることは非日常なことだった。普通はペアで仕事をしていて、たまに「ちょっとモブワークしてみようか?」って言って、特別に集まってたのだ。

そうじゃなくて、モブワークを自然な状態にして、たまに「ちょっと別々に動いてみようか」みたいにすることができたら、ちょっと感じ方が違うんじゃないか?という気がしていた。なので、チームにお願いして試させてもらった。

いつもとは違う場を作りたかったから、通常の席とは別のオープンスペースにモブワーク実験会場を作って全員でそこに集まって開発をしてみた。

## 1日の流れ

朝9時にみんなが会場に集まる。朝会ではコーヒーを飲みながら「今週のゴールに対して今の進み具合はどうか?そして、今日のゴールはどこに定めるか?」みたいな話をする。

それが終わったら学習セッションを始める。お菓子を食べながら、PhpStormのチートシートを眺めてみんなで「おぉ」とか「これは便利」とか言いながら楽しむ日もあれば、プロジェクトの中で気になってたことを相談して楽しむ日もあった。

学習セッションが終わったら、プロジェクトのための開発を始める。ここは毎日時間割を変えてみてた。一人で落ち着いて考える時間を作ってみたり、休み時間を増やしたり減らしたりして、どんな時間割がいいかなーってチームで試行錯誤してた。実はまだしっくりくる時間割は見つかってないので、みんなとは「これからも色んな時間割を実験してみよう」という話をしてる。

夕方には、今日のレビューとふりかえりをして後片付けをして帰る。

## 守

今回は、意図的に「全てのタスクに対して全員で取り組むこと」をルールとさせてもらった。つまり、全てのタスクに対して、1つの大きなディスプレイを全員で見ながら、1つのキーボードを使って開発をする、というルール。メインのディスプレイの横にサブのマシンを置いて、ちょっとした調べ物なんかはそちらでできるようにしておいたけど、基本は全員でタスクを進める。

というのも、そういうルールがないと、ちょっとうまくいってないかも?と感じたときに、すぐに元の開発方法に戻ってしまうから。そうじゃなくて、モブワークの中でもがいてみることで、もっと学びを得たいなと考えた。これは実際に当たった。もうちょっとしっくりくるやり方をできないか?と常にチームで試行錯誤することができた。

ちょっと自分の中で葛藤があったのは「モブワークが手段じゃなくて目的になってるんじゃないか?」ということだったが、これは最終的には自分の中で解決した。後で説明する。

## 2つの変化

モブワークによって、レビューや手戻りがなくなって「終わったと言ったときには終わったのだ!」ってなるのは前回も感じた通りだが、今回の実験によって、それとは別の変化がチームに起こった。

ひとつは、「学び」が当然のものとして開発の中に取り込まれたこと。

何かを学んだときに付箋をはるようにしていたら、毎時間何かが貼られていた。Winキー + ←→でWindowが左右に配置されるというようなことから、VimのVisual-modeまで。以前は学びがあるとは言っても「こんなことも知らなくてすみません」みたいなところがどこかにあったのだけど、今回は「新しい学びを得た!3yy p!」「それは圧倒的成長!!!天才か!!!」とかそういう感じ。

もうひとつの変化は「チーム」になった、ということ。

コードもドキュメントも設計も、これまではどこかに「それを担当したペアが作ったもの」という認識があったんだなって気付かされた。今は「チームとして作ったもの」になっている。だから何かの見落としに後で気づいても「もっとしっかりしてほしいなぁ」とかならずに「あー!しまったー!次はこの観点でも見ることにしよう」と、チームとして全員で協力して改善していける感じ。

## 破

さて。そんなこんなで最終日を迎えた今朝の計画のときにメンバーから「進んでるけど進んでない」「もっと速く開発できないだろうか?」という意見が出た。ので、こう返事をした「良いね。昨日までは、どちらかというと『学び』に軸足を置いてたんだよね。だけど、チームとしてのアウトプットに少し重心をずらしてみようか?」。

1週間の中で色々と伝えるためには、ちょうど「破」をしといた方が良いかもなと思ってたので「守」を解いて「じゃ、分担してみよう」という提案をした。「今、このチームは、本当にチームとして機能しはじめてるようにみんな感じてるよね。なので、作業を分担したとしてもこのチーム感をキープしたままにできれば良さそう」

ということで、2人ずつに分かれて作業をしたのだけど、結果としてはこれまでのペアワークとは異なって、チームとしてのペアワークになってたかなと思う。隣のペアの方が詳しそうなことは「ここちょっと手伝って」とか「ここで悩んでるんだけど、どう思う?」とか聞いたり、何か面白そうな話をしてるなーって思ったら、そっちのペアの作業に入ってみたりしてた。

それから、きりのいいところで、お互いの作業過程や結果を共有して、次に進んでいって、昨日までより速く開発を進めることができた。誰かが会議でいないときは、3人で進めてたり、2人と1人に別れたりして、臨機応変に動いてた。チームという「場」になったんだなぁって実感した。

## トレードオフスライダー

そんな風に開発をしてたら、「スピード」と「学び」と「技術的負債」と「不安」のトレードオフスライダーをどこに置くか、を朝の計画のときに話したら良さそうだね。という意見がでてきた。学びも大切だけど、スピードも大切だから、そのバランスをチームで毎朝確認しながら取り組んでみよう。って。良い気づきだな。

## チームの在り方

先程の「モブワークが手段じゃなくて目的になってるんじゃないか?」という自分自身からの疑問に対しての僕の答えは「モブワークはプラクティスじゃなくて、チームの在り方だった」。だから、モブワークをやる、ということではなくて、チームで開発をしている、というだけのこと。それは、手段とかそういうのではない。

まだしばらくは意識して「モブワークをやる」ということになるかなとは思うんだけど、それはそのうち単に「チームで開発をしている」ということに溶け込んでしまうんだろうなぁという学びを得た。

そんな感じ。他にも沢山の学びを得たし、なにより、メンバーに恵まれて僕は幸せだなぁ。