モブプログラミングを色々な場所で体験してきた #mobprograming

はじめに

社外でモブプログラミングを色々と発表聴講&体験したので、そこで感じたことなどを書いていきます。

目次

初めての社外発表聴講『大企業だけど新規ビジネス開発をモブプログラミングでやってみた』 in XP祭り2017

「以前からモブプログラミングというやり方があるよ」というのは聞いていました。 2017年9月にあった今回の発表は、モブプログラミング体験者の声を初めて聴く機会となりました。

聴講レポートは既に書いているので、コチラを見てください。

nihonbuson.hatenadiary.jp

得た気付きや感想

  • そういう風にやり始めた世界があるんだ…という感じ。
  • 正直、この時には実感が湧いていなかったんだと思う。まだ遠い存在。

初めての社外見学「実況パワフルモブプログラミング」 in Developers Summit 2018

2018年2月頃はモブプログラミングを社内でやっていることもあったのですが、社外で初めて生のモブプログラミングを見ました。

発表スライドはコチラ

speakerdeck.com

得た気付きや感想

  • 「やったー」の回数がとても多い。

    • 感覚としては3分に1回ぐらいあった。
    • これはそれだけ粒度を小さく区切って進めている証拠
    • 以前に、「テスト戦略を語る夕べ」という勉強会 *1 で、「リリース間隔が狭いことで得たいものは、リリースを早くしたいのではなく学習機会を増やしたい」という話があったが、それを正に実践している感じだった。
  • 自分も社外の人とモブプログラミングをしてみたい!

初めての社外体験「モブプログラミングワークショップ」 in Developers Summit 2018

「実況パワフルモブプログラミング」を聴講した後に、同じ会場の別部屋で体験会があったので参加してきました。

connpass.com

会場のセッティングは、イベントページにあった、この画像のような感じでした。

モブプログラミングの題材と結果

  • FizzBuzz問題を使用。
  • 参加者の方々がほとんど触れたことがが無い言語(python)を使用。
  • 時間交代制。確か7分。
  • FizzBuzz問題を解いただけでなく、途中でテストランナーの作成まで行った。
  • 実装結果は以下のページに残ってる。

wandbox.org

得た気付きや感想

  • 「実況パワフルモブプログラミング」でも書いたけど、本当に「やったー」の回数がとても多い。
    • 細かい粒度というのは大切。
    • 例えば、3の倍数のテストが書けただけで「やったー」と言ってたり。
  • 心理的安全性が高い雰囲気にしている。
    • 分からなければすぐに言える雰囲気。
    • 分からないところに対してすぐに教えてもらえる安心感。
    • みんなで分からないときはみんなで調べるという一体感。

  • ということで、社内の人も一緒に体験してほしい!

2回目の社外体験「テスト駆動飲み会 - Test Driven Drinking」 at ヴァル研究所

「お酒も飲みながらモブプログラミングを楽しめる」と書いてあったので、参加してみました。

tddrinking.connpass.com

モブプログラミングの題材と結果

  • 100doorsという問題を使用。
  • Javaを使用。
  • イベントタイトルからも分かる通り、TDDで進めていく。
  • 自由に交代する形。
    • ただし、ドライバーが「そろそろ代わってよー」と発言するという、多少のグダグダ感。*2
  • cyber-dojoを使用。

cyber-dojo.org

  • 実際に利用した結果は画像の通り。

  • ちなみに、お酒もTDD(Red→Green→refactoring)を意識したものに。

得た気付きや感想

  • テスト失敗続きになったときの対処(revertの判断)は勉強になった。
    • revertの判断も、モブでやっているからこそ、色々と相談しながら進められた。
  • 最初にTODOをきちんと整理しなかったのは反省点。*3

3回目の社外体験「モブプログラミング現場訪問」 at 楽天株式会社

Developers Summit 2018でyattomさん( id:yach )と話して、及部さん( id:TAKAKING22 )なら、モブプロの現場見学ができるという情報を仕入れました。

結果、 kidaniさん( id:kidani_a )とそのチームメンバーである後輩3人を誘って、5人で現場見学が実現しました。

今回の話は、kidaniさんが既に記事にしているので、そちらも参考にしてください。

kdnakt.hatenablog.com

モブプログラミングの題材と結果

  • 及部さんのチームが作っている製品が題材。
  • 時間交代制(7分、休憩1分)。
  • 1時間弱で、お客様に提案の形を示す程度のものができた。

得た気付きや感想

  • FizzBuzzとは違い、既にあるコードを使ってのモブプログラミングだったため、コードを理解するのに時間がかかった。
  • 今までの勉強会とは違い、社外勉強会に積極的に参加しているわけではない人と行ったため、「○○が分からない」と素直に発言するのをためらっている人がいた。
    • これはその人が悪いというわけでなく、「そういう人も存在するよ」という知見になった。
  • 心理的安全性やサーバントリーダーシップといった、チームビルディングの大切さを改めて感じた。

ちなみに、積極的になりきれていないチームでモブプログラミングを始める場合、今回のやり方は2つの部分で良かったです。

1. 時間交代制

時間交代制によって、コーディングに慣れていないメンバーにもドライバーとなってコードに触れてもらいました。

実際の現場では、時間交代制ではなく、ドライバーになりたい人が「代われ!」といって交代する方法をとっているようです。*4

また、途中でプロジェクトに参加した人がいた場合は、慣れてもらう意味でも、積極的にその人をドライバーにするとか。

2. 休憩時間の導入

休憩時間といっても、休むだけではなく、以下のような会話を行っていました。

  • 自分がこの7分間で何を行っていたのか。
  • 次のドライバーは何を行うべきなのか。
  • その他、この7分間の振り返り。

今回は、この休憩時間があったことで、なかなか慣れてない人から「コピペの仕方が分からない」という発言が出てきました。*5

休憩時間の導入は、発言を躊躇する人がいるうちは良い方法だと思いつつも、慣れてきたらそういう「分からない」発言もモブプログラミング中に話せると良いね、とのこと。

テストエンジニアとして、モブプログラミング体験から感じたこと

及部さんのスライドには、以下のような話があります。*6

  • 毎日 11:00~11:15にモブプランニングとして、今日やることを見定めて、1日中モブワークをしている。
  • モブワークは、コーディング以外にも、設計やレビューなどの工程を区切らず、常に同期している。

これらの話や図を見て、私は似たような図を思い出しました。それが次の図です。

そう、探索的テストの図です。*7

最初に計画を立て、それに基づいて学習・設計・実行を、短いサイクルで行うというところも似てます。

時間で区切る方法として「セッションベースドテスト」あったりするのも似ている気がします。ちなみに、セッションベースドテストについては、テスターちゃんの説明が分かりやすいかも。

testerchan.hatenadiary.com

通常の探索的テストは、学習・設計・実行を分担して行ったりします。

ただ、もしかしたらモブワークとの親和性が高いのかもしれません。

実際に、モブテストを行っている例もあります。

underscore42rina.hatenablog.com

上記の場合は、ドライバーをリナさんで固定にしています。

一方で、ドライバーを時間交代制にしたり、テストに慣れていない年次の浅い人をドライバーにする方法もありだと思います。

それによって、どこが上手くテストできないかが可視化できるかもしれません。

また、issueとして残すことが多いため、書記を置く方法というのは、モブテストならではかもしれないです。*8

まとめ

  • モブプログラミングの発表聴講、見学、3回の体験を行って、色々な違いを発見することができた。
    • そのほとんどは、チームとしての雰囲気や心理的安全性が大きく関わっていた
  • TDDの方針と同じで、とにかく粒度を小さくして、学習機会を増やすというのが本当に大切だと感じた。
  • テストの場合、探索的テストと親和性が高そうだと感じた。

*1:詳しくはこちらnihonbuson.hatenadiary.jp

*2:アルコールが入っているし、仕方ない

*3:アルコールが入っているし、仕方ない

*4:いわゆる「我が家」方式

*5:今回はvimを使っていた

*6: 次のスライドのP11とP35 speakerdeck.com

*7: 次のスライドのP27

www.slideshare.net

*8:issueは時間軸をまたぐため、暗黙知の共有、その場での同期だけで十分なのか…と検討の余地がありそう