Agile Japan 2018に参加してきました。Agile Japanは2013年に講演した時ぶりに参加させてもらいました。 今回は基調講演の「モブプログラミングと”フロー”の力（Woody Zuill）」についてレポートします。
-
セッション｜AgileJapan2018
AgileJapan2018 Why Agile？
2018.agilejapan.jp
レポート：モブプログラミングと”フロー”の力
モブプログラミング
セッション概要
5人で1台のコンピュータを使ってプログラミングをする？そんなことをして生産性は高まる？そんな疑問はもっともだと思います。その疑問に回答するのは簡単ではありません。我々が”フロー”の力を理解し始めるまでは - モブプログラミングはどうすれば一つのチームが一緒に効率よく働くことができるかということを探求する過程で発展してきました。一旦始めてみると、我々はモブプログラミングが次のような様々な面でより良い効果を生み出すことにすぐに気づきました。 ・今までよりも多くの作業を終えることができた ・より多くの重要な作業を終えることができた ・作業の品質が劇的に向上した ・チームのナレッジ、スキル、遂行能力が急速に進歩した ・そしてチーム全員がとても楽しんで仕事をしていた 1日を通してみんなで一緒に働くことがこれらの良い効果をもたらす主な要因であることは明らかでしたが、それでもこの働き方がなぜこんなにうまくいくのかをまだ理解できていませんでした。 これを理解するためのヒントが"1個流し”の実践にあることは早い段階で気付いていましたが、この重要性を本当に理解したのは”フロー”の力を探求し始めた時でした。 皆さん、私と一緒にこの探求の結果を考察してみて、モブプログラミングと”フロー”の力の理解をより深めてみましょう!
Woody Zuillさんはモブプログラミングの生みの親である。 WoodyさんがHunter Industriesに参加する時に、
- チームの邪魔をしないでください
- 見積りはしません
- 延期をする権利をチームが持ちます
という条件を出した。そこから現場改善に取り組んでいく中で生まれたのがモブプログラミングである。 「A day of Mob Programming」という動画を見たことがある方も多いのでないでしょうか？
この動画はHunter Industriesの現場でモブプログラミングをしている1日を早送りでまとめたものである。そして今ではHunter Industriesはモブプログラミング発祥の場として有名である。
モブプログラミングは、同じ仕事を同じ時間に同じ場所で同じコンピューターですること。Woodyはモブプログラミングは本当にアジャイルだと思っているそう。
モブプログラミングは、ドライバー（PCを操作する人）とナビゲーター（それ以外の人）という2つの役割が存在する。 よく勘違いされるが、1人が作業をしているのをまわりで見ていることがモブプログラミングではない。モブプログラミングはチームからのインプットを受けてチームでプログラミングをすることである。考えている人がまわりにいて、ドライバーはチームの考えをキーボードで打つだけなのである。 そして、今では世界中でモブプログラミングをしている。 （チームの写真を使ってくれてありがとうございます） モブプログラミングの話をしていると、いつも聞かれる質問がある。 「モブプログラミングは生産性があがるのか？」 この答えは私もわからない！ ただし、モブプログラミングによって仕事がうまくいくことはわかった。
1つ1つの仕事を組み合わせることでシステムができるのではなく、1つ1つの仕事の相互作用が重要でそれによってシステムができあがっていく。
以下の3つの視点がよく出てくる。
- 効率＝ものごとを正しくする
- 生産性＝アウトプット／インプット
- 効果＝正しいことをする
ただし、それぞれについて考えるとこうなってしまうことが多い。
- 効率＝仕事を忙しくする
- 生産性＝間違う
- 効果＝正しい
たいてい最初に浮かぶ問いは正しい問いではない。正しい問いは何なのかを考えることが最初の1歩である。正しくない問いにたいして頑張って答えることにあまり意味はない。問いの答えを探しても答えは存在しないので、それよりは正しい問いを見つけることが重要だ。 「モブプログラミングは生産性があがるのか？」 ではなく、 「モブプログラミングは効果的なのか？」 という問いに変えてみよう。そしてその問いを少し反対から考えてみて、 「本来一緒に仕事をするべき人達がバラバラに仕事をする場合にどうやってうまくいかせるためにはどうすればいいか？」 ということを考えてみる。バラバラに仕事をすることで効果的ではなくなってしまう要因は何なのだろうか？
以前、効果的ではなくなってしまう要因を考えるワークショップをやったときは50個見つかった。 これらの問題はモブプログラミングを始めるとすべてなくなってしまう。モブプログラミングは、効果的にするためにはどうすればいいかを学ぶことにフォーカスしたことから生まれたのである。
例えば質問をして答えが返ってくるまでのキューのことを考えてみよう。 1時間ごとに質問が1つ発生するとする。 質問に対して答えが返ってくるまでの待ち時間が2分の場合、1日に16分ムダになる。 質問に対して答えが返ってくるまでの待ち時間が10分の場合、1日に70分ムダになる。 質問に対して答えが返ってくるまでの待ち時間が1時間の場合、1日に4時間ムダになる。 質問に対して答えが返ってくるまでの待ち時間が1日の場合、1日中ムダになる。 この待ち時間をより効果的にするためにはどうすればいよいのだろうか。それは待ち時間の間に別の仕事をすることだ。しかし、このやり方は「在庫を抱える」という別の問題を生んでいる。 別の仕事をすることで忙しくなるので、一見効率がよくなっているように見えるが答えが返ってこないことが真の問題なのである。在庫はできるだけ少なくしないといけない。別の仕事をすることで症状を小さくできているかもしれないけれど、「在庫を抱える」という問題は一切解決していない。
この「在庫を抱える」という問題は、チームで一緒に働くだけで消えるのだ。答えを待つ必要がない。その場に答える人がいるのだから、自動的に1個流しになる。
フロー
今日のテーマである「フロー」について考えてみよう。2つのフロー（心理的なフローとリーンフロー）について考えてみたい。
心理的なフロー
心理的なフローとは、ゾーンに入っている状態のことだ。没入感が生まれ、時間の感覚がなくなる。チームで働くことで心理的なフローの状態をつくれるのだろうか。 他の産業で同じようなことをしている例を探してみた。
- バンド
- 手術室
必要な奏者がいないバンドの音楽を聞きたいだろうか？ 必要な人がいない手術室に運ばれたいだろうか？ 彼らはチームのゴールを持っていて、その上で個人のゴールも持っている。個人のフローとチームのフローは＆でつなぐことができるのである。モブプログラミングも同じだ。
リーンフロー
リーンフローとは製造業のフローのことである。製造業ではキューイング（在庫）が最も重要な問題だ。グリーンを増やしてレッド（待ち時間）を減らさなければいけない。
ではソフトウェア開発ではどうなのだろうか。やはり同様に、キューイングがない、待ち時間がない、割り込みがない、マルチタスクがない状態を目指す必要がある。
そしてそこに近づけるために、ソフトウェアのすべての工程で学ぶのである。 モブプログラミングは個人の仕事ではなく仕事のフローを最適化している。チーム全員で一番いい状態に持っていくのである。 結局、すべての問題の根幹はキューイングである。モブプログラミングはキューイングをなくすことである。
モブプログラミングは効果的なのか？
ここで、 「モブプログラミングは効果的なのか？」 という最初の質問に戻る。 モブプログラミングでは、フローとフローを組み合わせることで効果的にする。
- 個人のフロー
- チームのフロー
- リーンフロー
モブプログラミングはいつでも自由に出入りしていいので個人のフローが存在する。もちろんチームで一緒に仕事をするのでチームのフローも存在する。モブプログラミングはみんなの頭の中のContinuous Integrationなのだ。 そしてリーンフローもある。1個流しをすることでキューイングをなくし、常にフィードバックを受け続ける。 1つのことに集中すればいろんな問題が消えていくのである。
最後に
Woodyは26〜27歳の時に、Robert Henriという芸術家に会いに行った。Robertはどうやって芸術を作っているかを見せることはできるけどもっと重要なことがあるといってこの言葉を送ってくれた。
芸術をつくることが大事なのではなく、芸術をつくることができる素晴らしい状態にいることが大事なのである。
モブプログラミングも同じである。要するに環境を整えることが重要なのだ。環境が自然になると良い結果が生まれるのである。 ちなみに、Woodyのスライドのイラストはすべて彼の奥さんが書いたものだそうだ。
まとめ
Woodyが生んだモブプログラミングを知って、チームでモブプログラミング＝モブワークを続けてきてたくさんの学びを得ることができた。
昨年作ったこのスライドが少しだけ世の中に広まって、この後から日本でもモブプログラミングの場が一気に増えていったように思う。 自分達のチームでは「効果的じゃないと感じたらやめよう」というたった一つのルールのもとでモブプログラミングを始めたが、現在に至るまでずっとモブプログラミングを続けている。Woodyの話は自分達が体験していることがすべてつまっているように感じた。 自分もいろいろなところで話しているが、モブプログラミングはやってみないとわからないことが多いので、もしよかったら一度でいいので試してみてほしい。 もちろんなにかお手伝いできることがあればいつでもご連絡ください。
Thanks Woody!!
To Woody Thank you for great presentation and talk! We learned a lot from you.
