日本は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。
Hunterで学んだことその8: 仕事領域 = モブ != 人
3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。
これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じところをいじるとマージが発生しますが、声をかけて避けているようでした。目の前で衝突とマージは起こっていません。作業が終わったらコミットして、 git push / pull / テスト で同期します。
Hunterで学んだことその9: ウィンドウはそのまま!
モブごとに2枚のディスプレイを使っているのですが、ウィンドウの配置はそのままにします。前の作業で開いたウィンドウはそのまま。IDE、シェル、ブラウザ、クラウドの管理コンソールのウインドウは基本すべてそのまま置いときます。シェルのヒストリに必要なものは全部残ってますので、思い出したり調べたりするのが楽です。ローカルで起動した開発用のサービスなどもそのまま使い続けます。ということなので、初めて参加する人がいても、環境構築タスクはありません。
ウインドウ構成の基本は、右画面がコードで、左画面がUI(ブラウザ)でした。テストを書くときは、左右にそれぞれコードとテスト。SQLスキーマやデータを調べるときは、左画面がDBで右がコード。ログを見るときも左画面に出すことが多かったです。
デプロイはもちろん自動化しているので、ローカルでの確認から、デプロイまでは一貫しています。本番リリースもモブで決めているようです。
ということなので、初めて参加する人がいても、環境構築タスクはありません。
Hunterで学んだことその10: モブでメールを出し、モブでメールを受ける
モブごとにメールアドレスが付与されているので、モブからメールを出し、モブで受ける感じです。「メール本文にモブの参加者名を書いておく」という慣習のようでした。
ハードウェアが絡む開発の場合、ハード内蔵ファームウェアの開発者との連絡が必要になります。Hunterではハードウェアの担当や、運用監視の担当は別のオフィスにいるのですが、適宜電話やチャット、メールで連絡を取ります。連携するハードウェアの実機も置いてあるので、常に確認しながら進み、何かあれば運用担当にログを解析してもらったり、ハードウェアの担当にファームウェアの仕様を確認してもらったり。「都合のいいとき電話して」といっておいて、モブはいつでも電話に出る、というようなこともやっていました。あと、近くのオフィスの人はたまに歩いてモブまで来てました。
Hunterで学んだことその11: やり方はモブ次第、モブをまたいだ問題解決も
3つのモブがあるのですが、びっくりしたのはやり方がバラバラなことでした。スキルも、タイマーの時間もバラバラ。モブで決めて、実験する。変えたほうがよければ変える。テストファーストで進めるかどうかもモブ次第でした。ローカルに置くテスト用のサーバの起動の仕方すらまちまちなのがすごいなと思いました。正解を決める判事も、取り締まる警官もいないので、正義を争う宗教論争にもならないのだろうなと思います。
ある時、隣のプロダクトから「ちょっとこれから一人参加してくれない？SQL query についてのセカンドオピニオン欲しいんだけど」と相談があって、一人手を挙げてさっと動いていきました。
Hunterで学んだことその12: このPCしばらく使えないから、あっちのモブに行こう
ちょうど大きめのWindows Update がありまして、モブ用のPCにアップデートを当てるためにしばらく使えない、ということになりました。他にもちょっと不調があったみたいで、しばらくだめだぞと。そこで10分もかからずに「あっちのモブで作業しよう」ということになりました。幸いカンファレンスで人がいないので、隣のモブスペースはあいてます。
移動して、さて前の仕事をそのまま継続するのかと思ったら、なんと移動先のモブのやりかけの仕事をはじめました。一人は隣のモブをやってた人だったので、内容はわかるのですが、さっきの続きじゃないのかーい。
「仕事領域 = モブ != 人」なので、考えてみれば、そのままの環境で作業を進めるほうがよいのですが、驚きました。
Hunterで学んだことその13: 休憩はいつでも
休憩はいつでも取ります。ちょっと抜けるわー、って言って電話に出たり、おやつを買いに行ったり。残っている人でモブは進みます。コードがよくわかっている主力の二人が抜けたときにも、そのまま続きをトライしていました。進みは悪いかもしれないけど、ちゃんと自分で考えて進めてみる。少なくとも学習は進むのだろうなと思いました。
ちょうど16時になったときに数人帰って、主力の二人が残ったのですが、グリーンの状態で15分くらいリファクタリングしてました。それもまた見てて勉強になりました。
Hunterで学んだことその14: カンファレンスで人が半分いないときも進む
ちょうどカンファレンスが重なって、半分くらいモブからいなかったのですが、残った人でバグフィックスやPOからの優先の要望を着々と進めてました。
Hunter の場合は、見積もりもしないし、事前にビジネス側に進捗の約束を行わないので、ベロシティが落ちるとか、スケジュールに間に合わない、と焦ることはあまりないようです。逆に、人がいないから、上司がいないから、ということで進めないこともないようです。
・・・という状態で大丈夫にするために、経営陣との間で様々な調整をしてきた結果だと思いますので、他の組織で簡単に真似できるものでもないのでしょうけれど、信頼貯金を貯め、ソフトウェアについて理解のある経営陣であれば、できるのかもしれません。
Hunterで学んだことその15: 金曜夜にコミットしない
これは海外の企業でよく聞くパターンですが、やはり金曜の夕方に慌ててコミットやデプロイはしません。コミットはすることがあると思いますけど、テストが通っている事が前提で、慌てません。「また月曜朝に考えよう」で作業終了してました。
Hunterでは、金曜14時から「Learning Time」になっていて、作業を中断してそれぞれの学習に時間を使います。AWSのe-Learningをやったり、言語を勉強したり、組織に関する本を読んだり、ということをしているようでした。
Hunterで学んだことその16: モブ解散後は自由時間
毎日だいたい16時にモブは解散になりますが、さっさと帰る人もいれば、個人ブースでメールを読んだり、勉強したり、様々に時間を使っているようでした。
16時に外に出てみると、まあ明るい。夏時間ということもあり。こんなに早く帰っていいのかな、と思いながらスーパーで惣菜買って帰る毎日でした。
だいたいメモしたことは書きました
だいたいメモは以上なのですが、まだ数日いるので、また気がついたことがあれば書くかもしれません。あと、写真をいろいろ撮ったのですが、これはそのうちまとめて許可もらって貼るつもりでいます。
下は、雨がふって出てきたカタツムリ。珍しいそうです。
前回のエントリはこちらです。あわせてどうぞ。
