先日、僕たちのチームの仕事の仕方を弊社のメンバーに取材してもらったものが記事になりました。

記事では「モブプログラミング」に焦点を当ててありますが、実は僕たちはプログラミング以外もほとんどの時間を「モブ」で作業しています。これは「モブワーク」と呼ばれているやり方のようです。
そこでこのエントリーはこの記事の補足とともにモブワークを4ヶ月ほどやってみたチーム内部の人間から「モブワークなかなかいいよ」という話をするエントリーになります。

「確実に前に進むことができる実感」がある

僕たちのやっているモブワークについて、僕の感じている一番のよさはここです。車でいうとギアをローに入れて進むようなもので、道が整っていない荒地でも進むことができ、多少の障害物でも止まることがありません。

障害物には例えば、どこから取り組んでいいのかわからない困難な問題、メンバーの疲労の蓄積、病気、割り込み作業、簡単な作業だと思ったら思いの外大変なやつだった、みたいなさまざまなものがあります。

"1 + 1 + 1" が "3" を超えるかも

モブワークをはじめてからチームでの成果がメンバーそれぞれが個別に作業した場合を超えている可能性が高そうだなと感じています。これはなぜかというと、おそらく複数人が同時に同じ課題について向き合うことで判断の質と速度を向上させることができるためです。各人の理解と共有、疑問の提示などの行動とその相互作用によって理解度や判断のブラッシュアップを高速に行えている、というのがいまの僕の理解です。
つまり何らかの判断を行う機会が多ければ多いほど、僕たちのチームではモブワークは効果的なのではないかと思います。

逆に例えば高速道路を走るときのように障害物がなく、先々の見通しがわるくない場合、何らかの判断を行う必要というのは少なくなります。この場合には僕が感じているモブワークの利点は活かされず、別のやり方の方が適しているのではないかと思います。

僕たちは1日の中で何度も障害物に行き当たる

僕たちの仕事の多くは何らかの課題解決です。これは多くの場合、問題の輪郭を明らかにし、それを解決しながら進めなければならないことが多く、この「多少の障害物でも止まることがない」利点がうまく発揮される場面が多くあります。

僕たちのチームのとある１日

以下にとある1日の出来事をリストアップしてみました。こうしてみると1日の間に数多く何らかの判断が発生していることがわかります。

9:30：メンバーが出社し始める。それぞれSlackのチェックや経費精算、調べ物をする
10:00：メンバーが揃ったので朝会。今日やることを確認
10:05：割り込み作業の依頼があったのでチームで取り掛かる。外部に出すデータを取得するSQLをレビューする。先方の欲しいデータはどういうものなんだ？みたいなことを話したりしながら見ていった結果、修正をはじめる
12:15：割り込み作業が午前中で終わらなかった。お昼休み+自由作業。と思ったら別のレビュー依頼をもらう。いつまでにみたらいいやつか確認し、急ぎじゃないのでタスクリストの後ろに積む
13:30：再開。SQLのレビューの続き。
14:00：採用活動の一環として人事の人からヒアリングをする。採用活動の方針について話したりする
15:30：なにしてたかな・・・
16:00：次のリリースに関してプロダクトマネージャー、セールスと相談
17:00：レビューしていたSQLに関して新たな制約条件がわかったのでそれを反映
17:30：SQLのレビュー（というかほとんど修正）を終える。今日ほとんどこれしかやってないな・・・。依頼されていた別のレビューを開始
18:30：シュッと終わるレビューかと思ったら思いもよらないポイントに行き当たる。いったん諦めて翌日の自分たちに託す

いまのやり方

僕たちチームはほぼ1日3人全員で同時に、同じ場所で、同じ課題に取り組んでいます。これまでに少しずつやり方は変えていて、いまは概ねこんな感じでやっています。

・１人がドライバー、残り２人がナビゲーター
・ドライバーは10分で順に交代
・ドライバーのPCをモニターに繋いで作業する
・ドライバーが考えながら作業をしたり助言を求めたりする
・ナビゲーターは作業をチェックしつつ指示を出したり意見を言ったりする
・1時間くらいを目安、もしくは疲れてきたら15分くらい休憩する
・何かを終えたら声に出して「やったー！」

モブワークは集中して作業を行うことが多いせいか結構疲れるので、夕方くらいから「箸休め的な作業」を片付けるようにしますか、ということにしています。

意外だった心理面でのプラス

これまでモブワークを試してきて得られた意外な効果のひとつとして、困難な問題の解決に対する自信？がついてきたというのがあるかもしれません。
ひとりで課題に向き合う場合、解決の糸口が見つからなそうな課題や想定外の事態の出現の際、心理的な負担から（短期的にせよ）モチベーションが下がるということがあったのですが、こういった事態に対して動じるということがなく淡々と「よし、やっていくかー」という気持ちで取りかかれるようになっている気がします。
これはこのやり方を始める前はあまり想定していなかった嬉しい副作用でした。

僕たちの「開墾」

課題解決にあたっては解決までの道のりが遠く、すぐには成果がでないけれどそれでも地道に取り組みを進めていかないといけない場面というのがあります。これはソフトウェアエンジニア的には「ヤクの毛刈り」などという表現で呼ばれているものとほぼ同じ構造です。
最近、僕たちのチームではこれを農業になぞらえて「開墾」と呼んでいます。

こういった状況になった場合、終わりが見えにくく、なかなか成果に繋がりにくいため、これまではモチベーションが下がりがちになってしまうことが少なくありませんでした。
最近はこれまでに挙げたようなモブワークの効果によって僕たちのチームではモチベーションを下げることなく着々と手を打ち解決に向けて進んでいくことができるようになってきたように感じています。

荒地を開墾する ≒ 弾み車を回す

もしかすると僕たちが進んで荒地を開墾していくことは、これまで考えていた以上によい効果を生む可能性があるかもしれないと考え始めています。

最近読んだビジョナリー・カンパニー2という本に「弾み車を回す」という概念が出てきました。何かを始める時にはなかなか成果が見えないよう見えるが、ずっと力をかけ続けていくと最終的には勢いが勢いを生み、良い循環を作ることができる、というような話です。

巨大で重い弾み車を思い浮かべてみよう。（中略）必死になって押すと、弾み車が何センチか動く。動いているのかどうか、わからないほどゆっくりした回転だ。それでも押し続けると、二時間か三時間がたって、ようやく弾み車が一回転する。
押し続ける。回転が少し早くなる。（中略）そしてどこかで突破段階に入る。勢いが勢いを呼ぶようになり、回転がどんどん速くなる。（中略）どの回転もそれまでの努力によるものであり、努力の積み重ねによって加速度的に回転が速まっていく。

「開墾」作業は弾み車の話と同じようにすぐには成果がでません。また、現時点で弊社や僕たちのチームが置かれている環境では「開墾」が必要な状況は決して少なくありません。
「開墾」作業がこの弾み車と同じようなものだとすると、諦めずにそれらをひとつずつ解決していくということを続けていくことで、いつしかよい循環を生むことにつなげることができるかもしれないな、ということを最近は少し意識し始めました。

さいごに

僕たちのチームがどのようにモブワークを行なっており、僕がどのような点を利点と感じているかということを書いてきました。４ヶ月程度続けてきて、うまく成果が出ているしなかなか面白いなと感じています。

次の記事は同じチームで一緒に作業をしている肉さんのエントリーです。こちらも併せて見てみるとより楽しめるかもしれません。