今年初開催となる名古屋支社の楽天テクノロジーカンファレンスに行ってきた！面白かったー！今、帰りの新幹線。僕は何かあったときに助けてねってくらいでいたんだけど、何もすることなかったし、みんな楽しんでたし、ピザとチョコとビールとチョコおいしかったし最高だったなー！スタッフのみんなも、来てくださったみなさんも、素敵でした！お疲れ様でした！

さて。そんな中、「名古屋に行くよー！」って言ってたら、なんと、きょんさんが遊びに来てくれて。しかも僕の相談に乗ってくれたのでした。幸せすぎた。ので、そのおすそ分け。

僕の相談？

こんな話:

どんな風に開発してる？
どこまで自動化してる？
TDDやってる？
知識の共有をどんな風にしてる？
ドキュメントは書いてる？

どんな風に開発してる？

スクラムって最大30日で1スプリントとかいうよね。僕のチームはそれよりは短くて10営業日で1スプリントが多いかな。でも、まだ慣れてないときは1週間で1スプリントにしたりする。でも、1週間だと結構短くて大変。だよね。

そんな中。きょんさんのチームは、1日スプリントをやってたんだって！短っ！だけど、しばらく前にそれもやめて、1時間スプリントになったそうな。1日の始まりにDaily Planningがあって。1時間ごとにスプリントプランニング・開発・スプリントレビュー・レトロスペクティブ。1日の最後に、Daily ReviewとDaily Retrospective。

・・・エクストリームだな！

面白いなーって思ったのは、非同期のコードレビューがないこと。ペアでリアルタイムレビューしてそれでOK。んで、それをDaily Reviewで簡潔に説明してお終い。なるほどなぁ。非同期のレビューほど時間を食いつぶすもんはないもんなぁ。

このやり方の良いところは、1時間単位でピボットできるところ。1日で完結してしまうところ(夜頑張るとかできない)。1日単位で開発チーム内の知識が共有されること。らへんだよな。確かに、理にかなってるなー！って思った。

どこまで自動化してる？

ってのも聞いてみた。

「全然自動化してなくて、マニュアルテストですよ」って言うので「ほほー」って話を聞いてたら、UTは95%くらいを自動化、ITは30%、System Testは5%くらい。んー。結構自動化してるぞ。。。

というのは置いといて、自動化に頼るんじゃなくて最終的には「どれくらいシステムを手になじませるか」ってのを大切にしてるんだって。開発チームはずっとその対象のサービスを触り続けていて、それで手触りを感覚として身につけることを大切にしてる。

それ分かる気がする。結局、システム触ってて「あれ？聞いてると大丈夫そうなんだけど、なんか違和感あるぞ？」みたいな「感覚」で問題に気づくことが多いもんね。コードを読んでてもそういうところあるね。

それを「誰にでも分かるように形式知化しよう」とするんじゃなくて「みんながその感覚を持てるようにシステムをたくさん触ろう」というのは良いな。咳さんとみわさんのところにも近い雰囲気ある。

UTとITとかの定義って何？

きょんさんのとこでの、UTとITとかの定義って何？って聞いたら、

UTはデプロイ前
ITはデプロイ後
SystemTestは自分たちの管理外のシステムとの連携をするテスト

ふむふむ「UTの中でも仕様に対するテストとコンポーネントに対するテストとあるよね？」って質問したら。

仕様に対するテストは、サービスレイヤに対するテストになり、それには5,6個以上のクラスが絡んでくる
その「仕様に対するテスト」では細かく見きれない部分として、「ログ」「例外」「並列処理」のテストを1,2個のクラスに対して実施してる

なるほどなぁ。確かに。「TDD的に進めると、あとで要らなくなるテストもあると思うけどどうしてる？」って聞いたら。

テストのリファクタリングを毎日の作業の中でやってる
その中で、不要なテストを削除したりもしてる

だって。いいね。

TDDやってる？

僕は最近あんまりTDD的に開発をしてないから、きょんさんとこはどんなんなんだろう？って聞いてみたら。「やってる」って。

というのもスプリントが1時間なので、彼らのタスクの粒度は分単位で。途中でペアの交代をしても「何をしようとしていたのか？」がテストとして先に表現されているようにする。んむー。良いな。

面白かったのは、個人個人がリモートリポジトリを持っていて、そこにpushしたコミットがCIを通ったらセントラルリポジトリに反映されるようにしてるってこと。だから、UTを通ってないコードはセントラルには反映されない。

知識の共有をどんな風にしてる？

ここまでの話でも分かるように、まずペアで作業をしてるのでその間で知識が共有されて、さらにスプリントが1時間単位なので1時間単位で作業の内容が共有されて、1日の終りには全員でコード共有が実施される。だから、少なくとも1日単位で知識の共有は行われる仕組になってるのだった。んー。面白い。

それに加えて、お客さんに成果を見せて信頼を得ることで、少しずつ「自分たちのスキルが上がる分だけより良いものができる」というのをお客さんや自社の上の方の人たちに理解してもらって、チーム内のスキルアップのための勉強に時間を費やすことができるようにしてる。

全てに明確なゴールを

徹底してるなぁと思ったのは、プロダクトオーナーとしての要望も、開発チームの作り上げるものも、スキルアップのための勉強会も、全て「目的、達成しようとしていること、そのためにやること」などを明文化して、共有してから始めているってところ。

自動化ひとつにしても「自動化したほうが便利だから」じゃなくて「今回かかる時間」「それによって具体的に何がどのくらい短縮されるのか」などを具体的な数字として表現するようにしてるところ。

バグチケット

これも面白かった。バグはもちろん、コードへの指摘も全部、バグチケットとして起票するんだって。んで、それを修正したらクローズするんだけど。このバグチケットを毎朝読み合わせるんだって。んで、ずっとやっていったら全部読み終わるから、そしたらまた最初から読み直すんだって。んで、これだけは定量的にではなくて、定性的にタグ付けをしてる。「なんかやばそう」「変だった」「重要そう」みたいな。

そういう風にしておいて、読みあわせをすることで「過去に僕らはどんなバグを作ってしまったか」「どんな指摘をコードに対して受けたか」みたいなのをチームの中で共通認識として得るんだって。確かにこれはいいなー。過去のバグを知っているかどうか、で気づけることもたくさんあるもんね。これも「手触り」の部分につながるね。