モブプログラミングの強みはメンバーが体験を共有できること
佐藤治夫氏（以下、佐藤）：先ほど及部さんが、モブプログラミングでみんなが話す時間が増えて楽しくなったというお話をしていました。モブプログラミングは複数人を同時に同じ場所に集めるので作業は並行で進まないじゃないですか。
その裏返しで、モブプログラミングのことをプログラミングではないモブワークみたいな感じでモビングって言うんですかね？ それを採用する効果はどういうものを感じていますか？
及部敬雄氏（以下、及部）：よく言われるところで、1つ目に「教育的効果が高い」というのがあります。SECIモデルで出てくる例えばソースコードや手順書など、コードやドキュメントに落ちる言葉として発せられる知識だけではなくて、コードの書き方や、なぜこういう名前にしたのかという組み立て方ですね。エンジニアは書いたコードは渡せるし、自分の言葉で説明できることは伝えられるけれど、コードだけでは伝わらないこともあるじゃないですか。
プロダクト開発でも、なんでこういうふうに作ったのかとか、作る過程でどこでつまずいて、どういう意思決定をして問題解決をしたかとかは当然伝わらないと思います。そういうものを全部まとめて全員で一緒にやるので、共通体験にして共有することができます。
単純なことですが、仕事の中でけっこうすごいパワーを発揮するのはたぶんみなさんも想像できると思います。全員が知っている状態になるのがすごく強いのがやっぱり一番です。
2つ目は、「すごくわかりやすい」です。アジャイル開発でスクラムをやっている人がメチャクチャ多いと思います。当然ですが、モブプログラミングの場合、そこでできあがったものは、できた瞬間にチーム全員の合意が取れている状態です。
一方、分業している場合は、コードが書き終わってテストも終わっても、そのあとにレビューがあったりします。プロダクトオーナーに見せたときに違うと言われたりもするから、終わったかどうかはまだわからない状態じゃないですか。
モブプログラミングで作っているときは「これはできたな」と実感しているものが確実に積み上がっていくので、スクラムで言うところのインクリメントしているという感覚がチームの中で実感できます。
確実に仕事が積み上がっていくので、開発のリズムも生まれやすいし、精神的にも安定して仕事に取り組めるので、とてもわかりやすくて効果としても高いとよく言われます。
もう1個違う点で考えると、コストの話がよく聞かれるんですよ。僕もアジャイル開発を10年くらいやってきて、はまっていたんですが、分業したほうが効率がいいという先入観に捉われてしまっていたんですよ。
モブプログラミングに出会うまで捉われていたなと思います。例えばウォーターフォールの頃もそうですが、スクラムやカンバンも基本的には全部分業をして、分業をいかに効率的にやるかをがんばっていたと言っても過言じゃないと思うんです。
モブプログラミングはもっと単純ですよね。単純に一緒にやりましょうというだけじゃないですか（笑）。それは効率が悪いよねと僕も最初は思ってしまっていました。
ただ、実際にモブプログラミングをやったことがある人はわかると思うんですが、効率の面で言ってもモブプログラミングのほうが早く終わることがけっこうあります。分業だと手戻りが発生しやすかったり、ミスコミュニケーションが生まれやすかったりして、最初から全員でやっとけばよかったなって思った経験は誰しもがあると思います。
平鍋健児氏（以下、平鍋）：わかるわ。
及部：さっき言ったみたいにいろいろな点で効果が出る場面があるので、分業とモブプログラミングのどっちが良いとか悪いとか、どっちの効率が良いかとか悪いかとかが簡単に判断できません。仕事やチームの状況によって選べるのがいいと最近はよく説明していますね。
佐藤：状況に応じて選択するわけですね。
及部：そうですね。
エンジニアにとっては暗黙知も重要
平鍋：一緒にやっているときの文脈の太さみたいなものってあるじゃないですか。そのときにその場にいたかはやっぱりけっこう重要です。形式知情報に残すとは別に、「ここ悩んだよね～！」みたいな既視感のある記憶はすごく重要だと思っています。
UMLを作った最初の人の1人でGrady Boochという人がいて、Unixの開発の歴史について話していたときの設計情報はどこに残るかという問いに、トライバルメモリー（tribal memory）に残ると答えていました。それって部族記憶のことなんですよね。未開の少数部族や村の人々でもなんでもいいんですが、そのときにその場にいて、こんな問題が起こって、ここでこうやって会議をして、みんなでモブプログラミングしたらこんなコードになって、これがそれだよねみたいな記憶です。
そのときのコーディングスタイルにしても、決め方のスタイルにしても、情報がブロードバンドで背景にあったうえでの、このコードを選んだみたいなことをモブプログラミングからすごく感じます。
佐藤：先ほどの及部さんの話の教育効果なんですが、プログラミングを始めたばかりの人は一人前のプログラマーは悩まないでパパパパって作ると思っている人がけっこう多いと思います。
でも一人前のエンジニアが書いているのを見たときに、こういう人でも悩んだりするんだとか、やっぱりここは難しいんだみたいにわかって、自分のステップをどう踏んでいったらいいのかがわかりやすいのかなと思いました。
あとはツールの使い方もそうですね。暗黙知的なところがすごく多いのかなと思います。開発ではいろいろなツールを使うので、こういう場面でこの機能を使うんだみたいなことがありますよね。
平鍋：そうね。「ここはCtrlなんとかでしょ」みたいなね。
佐藤：そうそう。「あれ、今なにをやったの!?」「この機能があるんですよ」みたいな。特に最近のツールは日々進化しているからそんな機能があったの？ みたいなことはけっこうあります。
及部：今の話につながるかなと思うんですが、モブプログラミングに抵抗感を感じる人はやっぱりいます。そのときに多いのが「コードを書いているところを見られるのが嫌」なんですよ。
たぶんそれは今言ったものの裏返しでもあると思います。自分でいろいろと確認したり調べたりして、最終的にできたコードはレビューしなくちゃいけないから見せるのはいいけれど、書いている途中は自信がないし嫌だなって思ってしまっている状態ですよね。気持ちはわかるんですが、それを見せられるチームのほうがお互いにいいじゃないですか。
学ぼうと思ったら、うまい人から盗むほうが勉強になると思います。佐藤さんのお話を聞いて、そこが嫌だと思っている自分たちに気づくポイントでもあるなと思いました。
佐藤：モブプログラミングは1日のうちでどれくらいの時間を取るんですか？ 私は仕事のとき1人でポケーっとしたい時間もけっこうあります。みんなでずっとやっていると疲れちゃうなと思うんですが、及部さんのチームだとどれくらいの割合なんですか？
及部：おっしゃるとおりで、けっこう集中してやるので、特に初めてやるとメチャクチャ疲れるんですよ。
佐藤：そうですよね（笑）。
及部：最初の頃は一気にやろうと思っていたので、本当に1日中、朝から晩までやっていたんですよ。でも最近はそれもつらいので、むしろギュッとやってほかの時間を自由に過ごしています。
例えばそこで学んだことを整理するとか、ほかのことをやる時間にしていて、実際に全員で作業している時間だけで言うと、3時間や4時間でギュッとしています。1日4時間も仕事をしたら十分なんじゃないかなと最近は思っています（笑）。
佐藤：それで毎日進捗があるんですね。
及部：そうですね。
平鍋：今回書いた本にはモブプログラミング／モブワークという小さな節があって、そこは及部さんに書いてもらったんですが、その中にすごくいいエピソードがあるんです。
開発のメンバーで話しているときに営業の人が来て、提案書を一緒に書こうという話です。作ろうと思っている提案書をモブで大スクリーンに出してやったみたいな話があります。こういうこと、こういうこと！ と思いました。
佐藤：営業と技術の壁もありますもんね。
平鍋：壁破壊ハンマーとしてもモブプログラミングは使えます。
佐藤：場を作るみたいなところでも使えますもんね。ちなみに私は及部さんがなにかに書いているのを見て、モブプログラミングいいなと思って自社に導入しました。最初、ネットかなにかで及部さんが書いているのを見て、お～って思ったんです。でもそのときはまだ導入する勇気がありませんでした。
次に「DevLOVE X」の及部さんの発表を聞いて、「これはやってみよう」と思って自社に取り入れました。今は自社でモブワークやモブテストなどいろいろとやっています。
及部：ありがとうございます。うれしいですね。
プロジェクトでドキュメントはどう残すか
佐藤：モブはかなり取り入れていて、効果も出ています。1点聞きたいんですが、アジャイル開発宣言で「包括的なドキュメントよりも動くソフトウェアを」というところがあるじゃないですか。
そこを偏って解釈して、「ドキュメントは悪だ」とか、「ドキュメントは書きません」とか言っている人を時々見ます。及部さんや平鍋さんの会社のプロジェクトだとドキュメントをどういう視点で捉えているんですか？
特に平鍋さんはastah*作っていて、モデリングで使うソフトも作っている会社なので、ドキュメントやモデルについてをどう捉えているのかお聞きしたいなと思いました。
平鍋：いらないものは書かないほうがいいと僕は思っています。受託開発をしているから、僕たちのステークホルダーって誰？ とやっぱりなるんですよね。エンドユーザーも含めたその先にいる人として、例えば製造業だったら品証（品質保証）や、保守チームが別にあります。つまり文脈によってぜんぜん違うんですよね。
僕たちのお隣さんはぜんぜん違います。さらにそのお隣さんたちの中には、コードやテストだけではその製品とのインターフェイスがうまくいかないケースもたくさんあります。
そのときに必要な、読まれるためのドキュメントは何だろうと常に考えています。それはやっぱりバックログに積みますよね。だから完全文脈依存なんですよ。同じチームがずっと開発して、そのプロダクトにずっと関わっていくプロダクトチームだったら、僕は本当にいらないと思う。
プロジェクトは、人が入ってきたり出たりしますよね。部族記憶の中で、なぜこうなったのかがずっと伝わっているのであれば、それはそれでいいと思うんですが、例えば保守チームがいて、あるときからその保守チームに引き継ぎをしなければいけないんだとなったら、やっぱりなにかないとね。それは必要だと思います。
ドキュメントが到達できないところはQ&Aなんですよね。すべての質問に応えようとしても絶対無理なんです。問題発生時に「なんでこれは書いていないんだ！」って言われるけれど、それは問題が起きたから言えるのであって、そんなもの最初からわかっていたらきちんと書きますよ（笑）。
そんなことまで書いていないですというのは普通なんです。起こった問題がドキュメントにきちんと記載されているのは、むしろ稀と捉えるべきです。そんなものを全部書き始めたら当然コストは合わなくなるとて思います。
すごく文脈依存だし、もし部族が残っていくんだったら僕は別にドキュメントはいらないと思います。でもほとんどのケースはそうではなくて、周りにはお隣さんや町内会や東京都のルールがあるわけじゃないですか。これはメタファーですが、会社の監査とかそういう人に納得させるものは必要じゃないかなと思いますけどね。
佐藤：ありがとうございます。及部さんのチームはどうですか？
及部：これはすごくタイムリーで、僕らのチームでもちょっと前に話が出たトピックです。僕らはむしろ「ドキュメントは大事じゃん」と最近よく話をしています。
佐藤：それはどういう観点からですか？
及部：僕もコードのほうが好きなので、ドキュメントは嫌いだったんですよ。なるべくないほうがいいじゃんと思っていたんですよ。アジャイルソフトウェア開発宣言では、包括的なドキュメントよりも動くソフトウェアと書いてあるけれど、どっちも大事だねという文面の補足があるので、そこがよく勘違いされるポイントなんです。
それに、包括的なドキュメントよりも動くソフトウェアというこの節だけで言うと、動くソフトウェアって当たり前じゃんと思ったんですよ。動かないソフトウェア作る人なんて誰もいないですよね。それって僕らエンジニアの仕事の前提じゃないですか。
なのでここは別に比べるものでもなくて、動くソフトウェアが前提だって思ったときに、ドキュメントの残し方がうまいチームはチームのうまさが出るなと思いました。
平鍋さんがおっしゃったとおり、確かに文脈依存です。例えば誰かに渡さなきゃいけない残すドキュメントと、ずっと同じチームで必要なドキュメントは違うんですが、僕らは同じチームでずっと働いていて、同じチームという文脈でよく考えると、やっぱり人って忘れるんですよ（笑）。
佐藤：なるほど。人は忘れる生き物。
及部：ソースコードは動いているし、テストコードがあればあとからでも検証はできるのですが、忘れてしまったものはもう取り戻せません。これを書いておけばよかったなというのがけっこう僕らのチームもあります。
どういうドキュメントを必要最低限で残していくかは、残しながら「これはやっぱり必要だったね」と精度をより高めていく活動が必要だと思います。ドキュメントをどう残すかは自分たちのチームでも今かなりホットなトピックです。
佐藤：なるほど。わかりました。うちの会社もドキュメントはどうするの、何を残せばいいのみたいな話がけっこう出ます。
平鍋：びっくりすることにコードを書くのが上手な人はドキュメントも上手だよね。
佐藤：そうなんですよね！
（次回へつづく）
