_ 実況パワフルモブプログラミング 感想戦 #devsumi

先日お伝えしていた通り、Developers Summit 2018にて仕事をしてきました。 目黒雅叙園の一室を1時間弱お借りして、仕事をしてきました。事前予約通り満席となり、さらには立ち見まで出て、講演者の我々は大変驚きました。朝一のセッションにもかかわらず、来て下さった皆様、ありがとうございました。 デブサミのテーマが「変わるもの、変わらないもの」でしたが、ただの変わり者の私たちはいかがだったでしょうか。

参加者の皆様の感想については、実行委員の方がToggetterにまとめてくださいました。そちらをご覧いただくと雰囲気が伝わると思いますので、ぜひご覧ください。

• 【デブサミ2018】16-C-1「実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 -」 #devsumiC #devsumi - Togetter

一夜明け、昨日のことを振り返ってみて、モブの中の人として伝えたかったことを書いてみます。

変わり者達

セッションでプロダクティブなデベロップメントを魅せたクレイジーな開発チームを紹介します。

• Gota Miyazaki: 普段からモブしてるモブの人。PHPの使い手。
• Tatsuya Sato（私）: 普段からモブしてるモブの人。昨年からPHPに真面目に向き合ってる。ボッチじゃない。
• Hiroaki Ono: 今回のキーパーソン。普段は別の部署で別のプロダクトを開発してる人。PHPは使ってない、

この最後の小野さんが今回一番重要なポジションでした。「プログラミング、チーム開発は普通に出来る人、けれど今回触るプロダクトについての知識はゼロ」という状況です。ですので、参加者の皆さんは、 「これまで違うプログラミング言語で開発してきた、中途入社の社員」 として見ていただけたのではないでしょうか。

「どこまでやるか」と「どうやるか」

モブプロ開始した時に、朝礼をまずやりました。 これは、スクラムのスタンドアップミーティングとかそういうものや、全く堅苦しいことではなく、

• 今日どこまでやるか
• どうやるか

を決めるだけです。 このセッションの時は、事前に「どこまでやるか」は決めていたので、それの再確認から始まりました。普段においても、せいぜい数分程度で済ませます。メンバーそれぞれが別々のタスクをアサインされる場合、朝礼ではそれぞれが何をやったのかを共有し、それぞれが抱えている問題を相談したりします。ですが、モブだとチームでできることは1つであり、一緒に活動しているので、それは既に共有されています。ですので、朝礼ではやることの再確認程度です。 なので、このセッションでは「どうやるか」にすぐ自然と移りました。 「どこまでやるか」と「どうやるか」を決めるフェーズは明確には別れていません。それは、「今日」*1の中で終えられるかどうかを考えなければならないので、「どこまで」いけるかは「どうやる」によって変わる可能性があります。

今回のやることは、管理画面に出ているデータが数字だけではわかりづらいので、「棒グラフでデータを表示する」というものでした。これに対して、次のようなタスクに分けて、進めることにしました。

1. とりあえず何でもいいからグラフを出す。
2. PHPからダミーのデータを渡す。
3. データベースからデータを抜き出し、ダミーデータを置き換える。

ここでは、会場に来ている参加者の人達が少しでも進捗が見えるようになればと思い、まずは画面のアウトプットを出し、それが徐々に精緻化されていくことで、「本当にゴールに向かって開発が進んでる」という感覚を持ってもらおうという意図があります。 ですが、これは普段でもわりとやります。目に見えてない段階では想像でしか出来栄えについて議論できないので、その議論は無駄になりがちです。ですので、ダミーデータでもいいので何かしらアウトプットを出すところから始めるようにしています。もちろん、すぐにアウトプットまで作れそうな場合は、SQLを組むところから始めることもあります。

見積もり

今回は意識してそれぞれにかける時間を見積もりました。この日は30分しかないということで、分単位の見積もりをしましたが、これは初めての試みでした。 いつもは1日単位で、その日のやることを決めてます。 ランチタイムや休憩時間といったタイミングが入ったりするので、その時点であとどれくらいいけそうなのかどうか確認をします。

設計

朝礼の時にやっていたように、その場でプロダクトの画面を見ながら完成のイメージについて絵を書いています。ホワイトボードだったり、そこら辺に置いてあるコピー用紙とかで絵を書いたりしてます。書いたものは残したりはしてません。セッション後に「ドキュメントはどうしてるんですか？」と聞かれたけれど、必要な時にその時の相手向けに書いています、としか回答できなかった。伝えたい相手に伝えるための手段なので、その時々に書くしかないのだと思う。プロダクトについて網羅的に書くのは、今のプロダクトはシンプルだから出来るかもしれない。けれど、作ったところで誰が見るのかがわからないものは無駄になりそうなので、多分やらないと思います。

ちなみに、この時に使っていたホワイトボードはnu boardです。

ドライバー選択

やることが決まり、それをどう進めるかも決まったら、最初のドライバーの選択です。普段なら誰が誰がどの順でやっても良いのですが、今回は、プロダクトについて知らないメンバーが1人います。彼にはプロダクトの知識が必要なものを敢えてやってもらう必要があるので、最後の3つめのタスクをやってもらうことにしました。その他2つはPHPやJavaScriptといった技術に関する知識で解決できてしまうため、ナビゲーターが持つプロダクトに関する知識を引き出す機会はほぼ無いでしょう。新しく入ったドライバーが進めなくなった時、その時がナビゲーターの持つ知識がドライバーの背中を押すタイミングだと思います。

YATTA!

この盛り上がりはリアルなやつなのかなw上手く行ったらマジで喜ぶのか、今の場がこうさせてるのか #devsumiC

— ryoichi (@saitoryc) 2018年2月16日

はい、大げさにやりましたｗ 普段のオフィスではここまでやりません。「よし！」とか言ったりします。 このYATTA！の本質は、「成果の喜びを共有」し、「そこに行き着くまでの過程を称える」ことだと思っています。単に出来て良かったということだけでなく、それのどこが良いのかを話したりします。例えば、「あそこのエラー、わかりづらかったけど、無闇にはまらずに別の方法に変えてよかったね」とか、「事前にあの辺りのことを調べておいてもらって助かりました。」とか。こういう良いことを言われると、自然とそれを再現させたくなります*2。 もちろん、嬉しいことをいつものメンバーと嬉しいと言えるのはとても楽しいので、喩えモブプロをしていないとしても、是非みなさんもやってみましょう。周りの騒音にならない程度に。

一日の終り

事前の打ち合わせでは、時間内にゴールまでたどり着かなくても、それはそれで問題にモブで立ち向かうことで見てもらえるものはあると思っていたのだけれど、予想外なことに最後に時間が余ってしまった。 なので、途中で後回しにした見た目の修正などをまとめる作業に入りました。これも普段の一日の終りにやることです。開発中は、機能として中核となる部分から作り、少しずつ精緻化していくやり方でした。このやり方だと、本質的でない部分は飛ばしてしまいます。このセッションでは、グラフの縦幅が大きすぎるので小さくしないといけなかったり、棒グラフの色を統一させないといけなかったりや、クエリにorder byを付けないと順番が保証されない、など細かい修正タスクを事後のやることとして出しました。

おわりに

やってる方も、見てる方もとても楽しんでいただけたようなので、とても満足しています。参加してくださった皆さんの普段のお仕事が少しでも楽しいものになれば、幸いです。