モブプロが大好きなので熱い想いを言語化する

この記事はモブプログラミング Advent Calendar 2018 の22日目の記事です。

前日の投稿は huideyeren さんの「軽い気持ちでモブプログラミングを行ったら失敗した話」、次の日は nihonbuson さんの「モブプログラミングをやっている人（及部さん）にレビューを語ってもらった話 #JaSSTReview」です。

モブプロはもはや説明の必要もないほど浸透していると思っていますが、敬愛の意も込めて大好きな動画を張っておきます。

動機

私とモブプログラミングとの出会いは2017年ごろ、どういう話の経緯だったか忘れてしまいましたが、私の Agile 師匠の一人に教えていただいたのが最初だったと記憶しています。

Mob Programming – A Whole Team Approach by Woody Zuill

これを読んで、これは面白そうだということで、はじめは開発合宿のような特別なイベントを企画してチームで試してみました。

その後育児休暇で半年ほど休んだり、後述しますがこの論文を書いた Woody 氏との出会いがあったりと本当にいろいろあったのですが、最近ではチームのほとんどの開発作業をモブプロで行っていて、「みんなでやる」のが自然な姿になっています。

チームにこの働き方が根付くまで、いろいろな試行錯誤や紆余曲折があったのですが、モブプロが好き、と言う気持ちがその行動を促していたことは疑いようがありません。

というわけで、自分で率先してモブプロを導入することに労力を割いてもいいと思える程度にはモブプロが好きなのですが、自分にとって今年の最大の変化とも言えるモブプロと言う働き方が自分にとって何なのか、という振り返りと、「好きだ」という曖昧な感情だけで働き方を決めるのもどうかなぁと思うところもあり、思考の言語化ということでその気持ちの構成要素を分解、整理してみたいと思い至った次第です。

要素と言語化

マインドマップで頭の中を整理してみたところ、大きく４つの象限がありました。

楽しさ
合理性
学び
人の縁

順に言語化してみます。

楽しさ

モブプロがなぜ好きか、その要素を考えたとき、まっ先に頭に浮かぶ言葉が「楽しいから」でした。楽しいことはもちろん好きです。

せっかく仕事をするなら楽しくありたいし、楽しく働く権利があると思っています。こう思える様になったのは割と年をとってからですが、今では「楽しい」ことがチームの価値の１つであっても良いなと考えています。

プログラミングの楽しさの再発見

私は社会に出てからプログラミングを学びました。それから１０年以上が過ぎた今でもプログラミングがとても好きなのですが、モブプロをしていると、初めて自分で書いたコードが動いたときの喜びを追体験するするような、そんな嬉しさを感じます。

これは、後述のチームとしての一体感や達成感と関連していると考えています。

一体感と達成感の共有 - "Ba"

チーム開発は楽しいです。モブプロをやっていると、チームで仕事をしている、ということをとても実感できます。

はじめは「１つのワークアイテムを終わらせたら、みんなでバンザイする」のように意図的に大げさに祝福するスキームを共有して、楽しさや一体感を演出していました。実際これはとてもワークして、「モブプロは楽しい」という原体験がチームに定着したと考えています。

前述の通り最近私のチームではモブプロは特別なことではなくなっていて、普通にオフィスフロアやオープンなミーティングスペースで実施しているので、あまり大げさな祝福イベントはやってないのですが、それでもコンパイルが通ったとき、UTが通ったとき、結合試験で思い通りの結果が出たときには自然にメンバーに笑顔がこぼれます。

最近、 Jim Coplien 氏の CSM研修を受けました。研修の中で、課題ワークなどでチームに一体感が生まれたように感じた瞬間、彼が

「Guys, "Ba(場)"」

といってくれて、それがすごく嬉しかったのをよく覚えています。そのときの感覚、"場" がモブプロによって自然に育まれているように感じます。

個人の精神的負荷の低減

また逆に、「辛いこと」もモブプロならチームと分かち合うことができます。

私のチームは歴史もそれなりにあり、いわゆる「技術的負債」というやつにぶつかることもそれなりの頻度であります。例えばあまりうまくないコードに出会って、そこを直さなければならないときや、コードから仕様や実装者の意図がまるでわからないとき、老朽化したインフラで単調な作業をやらなければならないとき... など。

その不透明さ、不確実性に起因する恐怖や不安といった負荷も含めて、個人で負担する「辛さ」がうまく分かち合えていることも、「楽しさ」につながっています。

合理性

大学で物理を専攻したせいもあってか、合理的なものが好きです。

モブプロが合理的なものを目指して生まれたのではなく、自然とその働き方が発生した、というのをどこかの記事で読んだように記憶しているのですが（ソース忘れました、、）、その生い立ちが逆に真理に近づいているような気がして、また魅力を感じてしまいます。

Efficiency/効率

モブプログラミングは効率が良いのか？という話題はしばしば耳にします。過去に自分も同じような考察を書いてしまったのですが、今はその手の質問は的外れである場合が多いと考えています。

まず、概ねベロシティやスループットの多寡だけが問題にされている場合、つまり暗黙的にリソース効率を比較しているケースが挙げられます。リソース効率を意図的に最大化したい場合（Waterfallの大規模開発とか？）であれば、モブプロを選ぶべきではない、という意味で問題ありませんが。

モブプロでは複数名が同時に同じ作業項目に取り掛かるため、自然とチームのWIP（work in progress）が小さい方に制限されます。これは自然とフロー効率を高める方向に働きますし、さらに依存と待ち時間、マルチタスクのスイッチングコストを最小化することでフロー効率が最大化される... というのはこの資料にもある通りです。

Mob programming and the power of flow agilejapan 2018 from Kenji Hiranabe

モブプロはフロー効率を高める手段として合理的である、ということが言えるかと思います。

Effectiveness/効果

さらに、そもそもフロー効率であれリソース効率であれ、「効率」だけをソロワークと比較して判断しようとすると、モブプロの持つパワーを過小評価する可能性が高いです。アウトプットされたものの（曖昧さをあえて包含しての）品質や、それが生み出した成果まで含めて比較することで初めてその真価を評価できます。

初めて Woody 氏にお会いした際、「モブプロしているときのメトリクスとして、何を計測しているのか？」という旨の質問をしてみたところ、「ほとんどメトリクスは取ってない」との回答をいただきました。だけど「自分たちが正しいことをやっているのは知っている」と。

当時「メトリクスを取ること」はある種正しいやり方であることを証明するための前提条件のように考えていて、この言葉を聞いたときには衝撃を受けると同時に「流石にナイーブすぎるのでは...」と感じましたが、いま自分が多くの仕事をモブプロでやるようになって、その意味が少しずつ理解できてきたように思います。

これはメトリクス - 特にアウトカムを計測する必要がない、という主張ではありません。

モブプロはチームが「effectively:効果的に」働くことを「最適化」する働き方であり、この意図を持って合理的だ、と考えています。

学び

新しいことを学ぶのが好きです。ソフトウェアエンジニアリングを愛する人であれば、程度の差はあれど理解してもらえるのではないでしょうか。そしてモブプロでは、情報伝達が常に顔を合わせてのコミュニケーション、という最高密度の手段となるため、ソロワークと比べ学びの [機会 x 密度 = 量] が圧倒的に多いです。

伝える側としての学び

モブプロでは仕事を進めるために絶えず対話し、自分の知識を相手に伝わるように言語化しなければなりません。その作業を通じて、たとえば既存のシステムの仕様が整理されている箇所、されていない箇所が明らかになったり、自分の理解の及んでいないところが明らかになります。

テクニカルスキルについても同様で、「ドライバーの理解度に応じた説明をする」というプラクティスを通じて、自身の技術への理解や習熟度も上がります。

伝えられる側としての学び

「ナビゲータを信頼する」プラクティスの副作用として、自分の認知バイアスをうまく回避して新しい概念を取り入れることができるように思います。書き終わったコードにレビューされる場合や、手順書やTipsなどのドキュメントを読む場合と比べると、自分の知識や技能の欠陥に気づいた際の歪みが小さいように感じるのです。

これはおそらくフィードバックのタイミングと、文字と対面のコミュニケーションの性質によるところが大きいのだろうと考えています。

チームとしての学び

伝えることと伝えられること、２つをチームが高頻度で濃密に経験することによって、チームの "練兵" というか、チーム全体でのシステム習熟度や技能向上がすごい勢いで起こります。

この効果はモブプロの経験回数が少ないほど高くなります。またこの効果の多寡はチーム/チームメンバーの継続年数への依存が小さく、メンバー間のコミュニケーションの密度に大きく依存すると考えています。

つまり、長く存在するチームでもコミュニケーション密度が低ければ効果は高く、ペアプロをプラクティスとして取り入れているチームにとっては効果は高くない、ということが起こり得る、ということです。

何れにせよ、モブプロはソロワークと比べより多くの学びが得られるスキームであると考えています。

人の縁

最後の要素として、モブプロの第一人者である Woody Zuil 氏との出会いと、不思議な縁が挙げられます。

今年同僚に誘ってもらって AgileJapan に初めて参加したのですが、彼はその基調講演で日本にいらしていて、当時からすでに私は彼のファンだったので、ネットワーキングセッションで話しかけていろいろとお話を伺う機会を得ることができました。

半分くらいはモブプロや、ソフトウェアエンジニアとしてのキャリアの話をお伺いしていたのですが、 Twitterアカウントを交換しようとして、私のTwitterのアイコン(D-28)を見て「ギター弾くの？」という話になり、その流れで私が大学時代にやっていた Bluegrass という音楽を彼が昔かなりやっていたことがわかり、それから延々音楽の話をさせてもらいました。

その後、Agile2018 に参加して San Diego で再開し、向こうでもいろいろとお世話になったりと、勝手に何か不思議な縁を感じています。

これは本当にただただエモいだけで、自分にしか当てはまらないのですが、自分の中での要素としては他と比べても全く遜色ないほど大きな割合を締めています。