社内hackathonでモブプログラミングをやった話

このブログ記事はモブプログラミング Advent Calendar 2018の6日目の記事です。前日は@sato_ryuさんのモブプロ始めてからやらなくなったアレ、やらなくて良いって訳じゃないし、最近また始めたし。でした。この記事では経験を共有することで、やってみようかなという人の後押しになればと思います。

概要

会社では毎年hackathonをやっています。私も一昨年は、画風変換、昨年はブロックチェーンを題材にしたプロジェクトに参加しました。アイデアは事前にアイデアソンやって、エレベーターピッチして、人集めてって感じで決めるんですが、今年は自分でアイデアを出してやりました。私のアイデアはLLVMプロジェクトのリンカlldの作者で有名なRui Ueyamaの作った簡単なプログラミング言語を作るライブコーディングをRustにポーティングしようと言うもの。そして時間があれば機能追加をしようと言うものでした。

hackathonのお題としてはちょっとチャレンジングじゃない感じですが、これは二つの意図があって

"hackathonの2日楽しくプログラミングをすること"だけを考えることができる
分割が難しくモブプログラミングに適していそう

と言うことで社内で人集めしましたら、結構トントン拍子に人が集まり、最終的には5人でやりました。アイデアもきてくれた人の1人が自作のマイコン(CPU, memory, display, bus, timer)シミュレーター(C++)と自作のアセンブラー(C++)を作ったことがあるとのことだったので、最終形は

「簡単なプログラミング言語を自作のアセンブラーでアセンブリして自作マイコンシミュレーターで動かす」

と言うことになりました。

メンバーは

自作マイコンシミュレーターと自作アセンブラーを作ったことのあるサーバーサイドエンジニア
Rustを趣味で勉強しているPerlサーバーサイドエンジニア(@ryutaro_mizokam)
goのツールチェーン周りを触ってみたかったJavaエンジニアかつSREなエンジニア (@matsumana)
swiftで自作言語のコンパイラーを作っているiOSエンジニア (@freddi)
私

内容が初心者向けと言うこともあって、私を含めRustを少し知っている人は2人、アセンブラーやマイコンに詳しい人は1人という感じでした。みんな違うプロダクトチームに属していてほぼ初めて一緒に働くと言うメンバーでした。

hackathon前

アイデアをプレゼンした後は、五月雨で興味ある人が声をかけてくれたんですが、新しいメンバーが入る度にランチで自己紹介と雑談したり、hackathonでの実施内容を固めたりしていました。チームビルディングを意識したわけではないですが、今思うとfearless changeのDo Food(何かを食べながら)のパターンになってよかったのではないかと思っています。

hackathon初日

モブプロと書いていますが、初日は、同じ部屋にいて、すぐに話し合えるものの、マイコン/アセンブラチーム2人、コンパイラチーム2人に別れてやりました。二つのチームの境界線は明らかで、基本的にアセンブラ言語の言語仕様自体はほぼ変更しない方針でしたので以下のようにslackや口頭で何やるかを伝え時々認識齟齬がないか同期しながらやりました。 f:id:nakaly:20181206020521p:plain f:id:nakaly:20181206020610p:plain

hackathon2日目

マイコン/アセンブラチームは初日にほぼやることを終え、かつ初日欠席だったiOSエンジニアも加わってみんなでモブプログラミング。 f:id:nakaly:20181203035846p:plain iOSエンジニアと私がテスト通ったりすると「よっしゃー」って言ったりガッツポーズをしたりワイワイやっていました。

関数導入時にスタックの一番上に戻りのアドレスが書いてあるってのを知らずに実装して無限ループになったり、
2引数関数でグローバルな状態を導入した際にRustの言語仕様にちょっと苦労させられたり、

それなりに詰まったこともあったけど、フィボナッチ数列を取り扱えるところまでは行きました。作成したもののレポジトリはこちら

モブプログラミングの感想

楽しい
- 自信を持って言えることはめっちゃ楽しかったです。ほとんど割り込みなくプログラミングに集中するのも久しぶりでしたし、うーんって悩むところもみんなで考えて、他の人のアイデアにおおそれ天才じゃない？みたいに感謝しながらも自分も何かしら貢献していた気がするのは本当に楽しかった。
メンバーの心理的安全性大事
- 後悔しているのは、メンバーの1人が自分がコーディングしているのを後ろからみられたくないと言うことで、ドライバーをやらずナビゲーターのみをやっていました。よく、およべさんがモブプロはチームの問題を可視化すると言っていましたが、私たちのチームでは心理的安全性が十分ではなかったのだと思います。
フロー効率良い
- そして、よく言及されるモブプログラミングと生産性ですが、マイコンとアセンブラーはほぼ完成していたものの、この内容を即席チームで二日それも10:00 - 16:00 お昼休憩ありの実質10時間ぐらいで仕上げたのはなかなか早いのではないかと思っています。
どういうときにモブプログラミングするか
- 私たちは初日はチームを二つのコンポーネントごとに分割し、2日目に統合しました。初日の終わりにお互いのやったことを同期する時間を設けて2日目をスムーズに迎えました。同期のオーバーヘッドはそれほど多くなかったと思います。というのもコンパイラーを書いていたチームはマイコンの実装の詳細を知る必要なく、インターフェース(今回だとアセンブリ言語)さえ知って入ればよかったからかと思っています。これはハッカソンでなくても、プロダクトをコンポーネントごとに分けても、繋ぐインターフェースが明確で疎に結合する場合、分けた方がフロー効率がいい場合もあると思います。

他のメンバーの感想

f:id:nakaly:20181206020634p:plain:w600

最後に

自分のチームではプロダクト開発にもモブプログラミングやモブレビュー取り入れていますが、もっとやっていこうと思いました。あと、これやったことでTuring Complete FMがもっとわかるようになっているといいなぁ。10日目は@matsuoshiさんの記事です。引き続きモブプログラミング Advent Calendar 2018をお楽しみください。