日本方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。
Hunter Industries にお邪魔してます
モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。２年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。
ビザの関係で生産活動には従事できないのだけど、横で立ってるのもなんなので、モブには参加させていただいています。ただ、たまに回ってくる私の番でやっていることといえば、「alt-tab押して」「もうちょっと上にスクロールして」「xxxって打って」っていう指示をもらってちょこちょこ動かす程度だったり、他の人同士で議論してたりとかしてて、なんか申し訳ない限りです。いることによって生産性は押し下げていることは間違いないです。
Hunterで学んだことその１: 帰るの早くて、体調良さそうで、機嫌もいい
だいたい16時にモブは終わり。多くの人は「またあしたー」ってサーッと帰っちゃいます。それもそのはず、始業は8時。8:30くらいにはモブが始まって12:00-13:00のランチを挟んで、休憩入れつつモブし続けます。
全体的に日本の職場に比べると余裕を持って仕事してる感じはあります。サボってるわけじゃないんだけど。代わりに、体調悪そうな人が職場にいません。機嫌も悪くない。変わった人はいますけど、機嫌はいいです。
そういえば、変わった人が機嫌悪いと怖いですよね。自戒を込めて。
Hunterで学んだことその2: モブの集中度合い
ペアプロやモブプロは集中するから効率がいい、というような説明をすることがあるんですけど、実際Hunterではどうなのか気になりますよね。
モブは大きな二枚のスクリーンの前で仕事するんですけど、感覚的には、SFで出てくる戦艦の司令室みたいな感じです。ドライバーがオペレータで、周りの人が状況確認しながら意思決定していく。
作業中、ずっと話してるのが印象的です。朝会の時だけ集まって話して、あとは自席で静かに作業する日本のありがちな現場とは対極です。たまに歓声あがってます。いいやり方見つかったんでしょうね。
予定があれば、いつ抜けても大丈夫です。30分くらいで大体ふりかえりや休憩を入れるので、そのタイミングで抜けるケースが多いようです。
Hunterで学んだことその3: 調査と打ち合わせとテストとコミット
コード書くだけじゃなくて、いろいろなことをモブでやります。
- テスト (BDD)、デプロイ
- アラートの調査
- Webでライブラリや書き方を調べる
- コミット、git pull/push (モブ間で同期)
- ミーティング (電話会議)
- メールを読む (POから、問い合わせ、人事異動)
これらすべてを分担しないで、モブでやっていきます。常に情報が共有され、アップデートされるわけです。
Hunterで学んだことその4: 慎重なコーディング
割とコード書くこと自体に慎重だと思いました。「こうしようと思うけどどう？」「いいね」という合意があって初めてコードを入力します。動作は最低限。ガーッといじることがないので、操作ミスがほとんど起こりません。
Webで調べた時にも、他のファイル見た時にも、コピペはそれほど多くないです。今時はIDEの力でミススペルは見つけてくれるからっていうのはあるかも。とにかく打ってコード補完を使う印象です。もちろんマジックナンバーとかはコピペですけど。
コミットのコメントも、ナビゲーターが言うことをドライバーが入力していきます。他のナビゲーターが「いいね」と言ったり、アイデアを足したり。
ペアではなくモブなので、3人以上を想像するかもしれませんが、最小の実施人数は2名です。4-5人の時もありますが、6人になった時は、しばらく後にみんなで相談して割ってました。
Hunterで学んだことその5: 「いいね」ってちゃんと言う
そこで、見逃しがちなポイントが「いいね」の表明です。ちゃんと他の人が言ったことに、同意するのかどうかを表明するのが大事っぽいです。だいぶ相手をしてくれているAndyの口癖は「Cool」です。
同意を表明することで、モブは前に進んでいくみたいです。
Hunterで学んだことその6: 立ち止まることを恐れない
モブの作業は進んでいくのですが、わからないところが出てくると、ちゃんと立ち止まって議論します。イラついたり焦ったりして適当に前に進むことがありません。
じゃあ今日の仕事が終わらなければどうするのか？Hunterでは見積もりをしません(No Estimation)。いつまでになにをやらなければいけないという約束もしません。
実はこれは昔 Woody Zuill がIT部門の長を引き受ける時にCEOに出した条件です。その結果、得られたものはちゃんと人の目が行き届いていて、バグの少ないないコード、そして、不具合の報告があればすぐに取り組むチーム、と言えるかもしれません。
私が参加したことや、カンファレンス参加者が多かったりして、スピードが下がるところもあるのですが、「そんな日もあるさ」と言ってました。事実としてそうなんですけど、日本の会社だとあんま言ったら怒られそう。
Hunterで学んだことその7: BDDのコードカバレッジとリファクタリング重視
BDDでの自動テストを重視しています。Specification by Example といって、仕様を想定ケースのテストコードとして書き出すのですが、それをやり続けます。「どんなテストを書くべき？」と言う議論もよく行われます。
コードカバレッジも一応見ています。ラインカバレッジや分岐のカバレッジに目標値はなく、テスト時に必ずカバレッズがチェックされて画面に表示されるので、それを見て、ふーんという感じ。機能 = ストーリーカードあたりに数個のテストは必ず書いているようです。
「どういうテストを書くべきかな？」「うーん、この機能だと...とかはどう？」「いいね。どこに入れるかな」「xxxってファイルあたりじゃないかな」「名前はどうしようか」「xxxxとか?」「うーん、xxxxとか」「それいいね」みたいな議論をよくしていました。
テストを先に書くかどうかはモブによって違うみたいです。モブ間の差異どうしてるかの話はまた書きますね。
Hunterで学んだことその8: ゼロバグリリース
テスト上で既知のバグ = Greenになっていないテストをゼロの状態でリリースします。Zero Bugs ないし Zarro Boogs というプラクティスです。ソースコード管理ソフトウェアにpushする際のフックスクリプトにもテスト実行が入っていて、チェックします。
コミットログもモブで編集して、コミット内容も2人以上で確認して、コミットします。トランクベースで直接最新の本線にコミットするときもあるし、試行的にやる時にはブランチを切ったりもしてました。
7年ほど前の最初のモブチームでは1年半バグが出なくて、その結果、人数を拡張してみることになったそうです。目の前の機能やコードを全員で見て進め、設計も見直します。設計の見直しといっても、UML図を眺めながら唸るなんてことはほとんどなくて、コードを見ながらよりよい名前をつけ、メソッドをくくり出したりするリファクタリングが中心です。すべてが一歩一歩。粗製乱造されて行数だけが多いコードとは対極にある感じはします。専従のQA担当はいません。
つづきます
いかがでしょうか。すでにモブプログラミングやBDDをやられてる方からすると、普通に想像できる事が多いのかなと思います。
今回書いているのは「モブプログラミング」という手法の話ではなく、現在の Hunter Industries で行われているプラクティスを、私の目で観察したところです。あと、日本語で書いている都合上、スタッフの人達に読んでもらうこともできないので、ちゃんと訳して確認してみるとちょっと違うよ、というところはあるかもしれません。にしても、何かしらみなさんのご参考になれば幸いです。
複数モブのすすめ方とかは、また数日中に書きますね。(追記: 書きました。)
旅行の余談 : リゾート気分
モブについてはいったんここまでにします。ここからはちょっと旅行の話を。
最寄りの大きな空港はサンディエゴなので、初日はサンディエゴに一泊して、海リゾート気分でした。
翌日からは丘の上のAirBnBで山リゾート気分です。
今日は駐車場で同僚の車に少しぶつけてしまって、レンタカー会社の指示で地元警察のチェックを受けるなど、新しい体験をしました。従業員の皆様におかれてはまったくもって邪魔でしかない状況ですが、私は元気です。ぶつけた相手の車の持ち主は初日のモブ仲間のScottで、終始笑顔で保険会社や警察と連絡とってくれて、ナイスガイでした。Hertzのレンタカーだとハワイに24時間対応の日本語デスクがあって助かりました。安心大事。
ではまた。
