はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。
そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。
先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。
現場に聞く！テスト/CI/DevOps、実際のところどうなの
伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレーション）やDevOpsなのですが（伊藤氏が公開したアジェンダ）、もう少し細かく、GitHubやPull Requestをベースにした開発やソフトウェアテストについて、コードレビューや、時間があれば開発における情報共有といった話も聞きたいと思います。
まずはGitHubやPull Requestについてなのですが、このエントリを去年の12月に書いて、はてブが1200もつきました。
要するに、石橋さんの会社もそうだし、Quiitaを開発しているIncrementsとか、そういう会社はGitHub使ってPull Requestを飛ばしながら開発をしていて、週に1回とか、多いところは日に10回とかリリースしてますと。
で、この記事には「こんな道具を使ってるんだ」って人から「こんなの当たり前」っていう人までいろんなリアクションが来ました。で、これはクックパッドの舘野さんに聞くのがいいのかな。クックパッドだと、いつ頃からこういう開発をはじめたのでしょうか？
舘野 僕は2010年の8月にクックパッドに入社したのですが、そのときにはcronで回しているCIがありました。そのときはただCIを回してるだけの開発で、重要なもの以外はコードレビューも入れてなくて。
GitHubのコードレビューを入れ始めたのは、GitHubのPull Requestを飛ばして、それをマージしてCIを回す、というフローはどうだろうと考え始めたのがきっかけで、2011年頃に永和システムマネジメントさんがGitHubを使った開発をしていたり、また当時はGitHub Enterpriseが出たこともあって。
伊藤 僕の記憶が正しければ、はてなでは（僕がいた）当時まだはまだテストは定着していなかったよね。
伏井 そんなに積極的にテストを書いたりTDD（Test-Drive Development、テスト駆動開発）まではいってなかったかなと。
伊藤 はてなでいちばん最初にテストを書いたのって、「はてなダイアリー」のはてな記法のときかな。コードのどこかをいじると別のところがバグるっていうどうしようもないことになって。
舘野 当時はCIがあるのは知ってたんだけど、それが僕らのWeb開発のメリットになるって想像が付かなくて。今だとコード書いたらレビューが入ってそのあとCI流してデプロイまで30分くらいはかかるけど、当時はもう2分でデプロイみたいな（笑）（注：舘野氏も以前、はてなで働いていた）
伏井 でもそのあとテストが全然メンテされなかった期間が長かったんです。有料会員向けの機能追加とかどんどんして、ある日気付いたらテストが全然動かない。しかし開発を進めなくてはいけないということで、ぜんぶやり直そう、ということになって。
伊藤 だから実はこういうやり方が定着したのは2011年とか2012年頃で、まだ1、2年くらいしかたってない。KAIZEN platformは最初から？
石橋 僕が1人で開発をやっていた頃は自分でテスト書いてデプロイしていたんだけど、開発者が2人か3人になったとき、「自動化した方がいいですよ」って頼りになる奴が言い出して。
3人くらいだとそういうのって「あってもいいかな」というレベルだったんだけど、開発チームの人数が増えて10人くらいになると「これがないとやってられない。チーム開発には必須だな」って痛感してる。
伊藤 僕の実感だと、（CIなどの自動化が）当たり前という人と、そうじゃない人のギャップがどんどん広がってきていて、この先どうなるのかなと。
舘野 これって実際に自分たちでフローを体験してみないと、文章などからだと良さの感覚が伝わりにくいですね。あとスタートアップとかでエンジニアが1人や2人のところだと、あうんの呼吸でできちゃうところがあって。
テストはどのくらい書けばいいのか？
伊藤 今日多分いちばん盛り上がる話だと思って持ってきたのがテストの話です。
これ「テスト考2014」は、Lingrを作った江島さんという人が書いたのですが、テストとかって原理主義的なところもあるし、テストを書きすぎると自分で自分の足を打ってる状態になることもあるよねとか。
そもそもそんなにテストをいっぱい書かないと動作が保証できないのは設計がまずいのではないかとか。あちこちで議論が盛り上がってて。
人によっては「いやいやテストってそういうものではなくて、コストを考えて書けばいい」という人がいるし、「自分で開発するためのテストと、ほかの開発者とのコラボレーションのための守りのテストは違うよね」とか。
それからhitode909くんの「テスト書きすぎ問題」は、江島さんの記事より前に書かれていたんだと思うけど。
伏井 hitode909くんは同じチームで働いている、はてなブログの開発をばりばりやってくれている人で、彼が書いているのは、DHHというRuby on Railsを作っている人が、あんまりテストを書きすぎるのは良くないって言っていて、それは江島さんと通じるところがあると思うのですが、hitode909くんはそういう、「テストは書かなくていいんだ」という言い訳を与えるのは良くない、といったことを書いていて。
でも僕はテストの必要性は完全にコンテキストによると思っていて、はてなのサービスみたいなものだとソフトウェアの寿命が長いんですよ。はてなダイアリーとかはもう10年くらい動いていて、まだメンテナンスしている。そのあいだには担当する人も移り変わるし。
伊藤 すいません（笑）
伏井 そういう意味じゃないんですが（笑）、担当者が変わると前の人がやっていることが分からなくなったり、たくさんの人がコードを触るということもあって、いろんな人がコードを触っても壊れないようにテストを書こう、という文化になったんです。
伊藤 実際にどのくらいテストを書いてるの？ はてなブログとかは。はてなエンジニアの座談会の記事を読むと、テストを適当に書いてコードレビューに出すとhitode909くんが怒るって書いてあるけど。
伏井 C0っていうのがあって、これはテストのカバーを計るものなんですが、テストを普通に実行するとどの命令も一回は動く、というのがC0で、C0くらいにはしようと。
C0はそんなに難しくないと思っていて、単に動けばいいだけなんです。
伊藤 例えばさ、C0を100％やろうとするとき、I/Oが発生してWebに非同期リクエストを飛ばして、みたいなことまでテストしようとすると、ちゃんとモックやスタブを使ってリクエストを何とかして、みたいなのをやらなくちゃいけないけど、それも含めてC0は難しくないってこと？
伏井 それは日々、はてな社内で鍛えているテストフレームワークみたいなのがあって、ちょっと書くだけでオブジェクトのモックができるとか、そういう前提があって。
まあ、あんまりC0、C0って言うと、はてなはC0厨って思われるかもしれませんが、そんなことはなくって、「あなたの書いたコードはテストでも一通り動いてますね」っていうのは、比較的いい基準だと。
テストに対するレビューが重要
舘野 僕はC0 100％とかはあまり重視してないんですけど。
伊藤 クックパッドはC0 100％とかじゃないんだ。
舘野 ないですね。ただ、自分がテストを書く側として見たときに、コードのカバレッジ率というか、この行ちゃんと通っているよねっていうC0の話は、自分が書いたテストが本当にその通り実行されているかっていう点では、すごくわかりやすいんだよね。
自分が、ifがtrueになってここを通っているつもりでテストを書いても、実は通ってなくて、ただ結果はテスト的には通っちゃってる、とかいうことがすごく分かるので、そういう意味では、テストして通ったというラインが視覚化されるのは気分がよいというか、そうだよねと。
伊藤 よく、テストをやったことがない人から「基準としてどこを目指せばいいんですか？」って聞かれるんだけど、会社としてだいたいここまでっていう基準はある？
舘野 明文化はある程度されていて、うちでは全体リリースっていうユーザー全員に対してリリースするものについては、基本的に全てのことにテストを書きましょうと。それがC0だとは明記されていないんですけど、実装に対するテストを書きましょうとしている。
あと、実装に対して適度なテストを行っているかというレビューは重要だと思っていて、例えば課金が発生しているのに、そこの部分の例外処理に対して無頓着なテストを書いていたら筋がよくないよねとか。
価値があるテストかっていうのをコードレビューで検証するのは価値があると思っていて。そういうところを口を酸っぱくして言うエンジニアがいるのは、ある意味正しいんじゃないかなと思います。
伊藤 そういうのって、テストの基準がほしい人にとっては説明しづらいよね。「いい感じで」としか言いようがないみたいな。ちなみに、はてなではてなブログ以外はどうなの？
伏井 やり方はチームごとに一任されてて、開発フローみたいなのはチームごとに育てているという感じになっていて。
伊藤 じゃあテストをどれくらい書きましょうといった考えは、チームによって違う？
伏井 僕らも、プルリクするたびにC0とか言ってるわけじゃなくて、あくまで1つの基準なんですが、機能をテストするのに十分か十分じゃないかは都度判断している感じになっていて、そういう基準も明文化されているわけではなくて。
そういうのがチームごとに、そういうのに詳しい、センスのある人が見てくれているっていう感じです。
StackOverflowはテストを書いていない？
伊藤 ここまでテストを頑張って書いてます、という話なんだけど、wazanovaの「Stack Overflowのアーキテクチャ」という記事に面白いことが書いてあって、それは、「テストはほとんどしないが、ユーザがmeta.stackoverflow.comで積極的にバグの報告などをしてくれる。」って。
（会場爆笑）
江島さんがこれに近いことをちょっと書いていて、要するにアクティブなユーザーがいるサービスなら、早く出してユーザーの反応を見て直す方がトータルでは速いときもあるんだよと。
舘野 はてなの初期もそれに近かったですね。新機能を告知すると、「動きませーん」ってよくオペラユーザーに怒られたり（笑）
伏井 その辺はバランスだと思っていて、テストである程度の品質を保証するのと、それ以上テストを細かくやると条件が爆発してしまって工数がかかりすぎるのとの。
伊藤 それは話を進めると、どうせバランスだという話になっちゃうんだけど、いまどきのWeb開発はバリバリとテストを書く感じの一方、StackOverflowみたいにテストを書いていそうなところでも書いてなかったりして、そこは意思決定が問題なんだよと思ったのと。
伊藤 それから、お客さんからお金をもらってるサービスだとちょっと考え方が違う？
石橋 違いますね。ささいなバグで1時間ぐらいで治せればいいけど、4時間くらいになると「やばい、どうやって謝ろう」とか。
伊藤 だからテストの話をするときは、まず背景を明確にする必要があって、テスト書きすぎ問題とかは特にそうで、hitode909くんは「テストをすごく書け」というのに対して「3カ月で終わりのプロジェクトにテスト書いてもしょうがないじゃん」みたいなコメントとかが来て、3カ月で終わりのプロジェクトのことなんか書いてないのに。
伏井 おっしゃるとおりで、今書いているコードが10年後も使う可能性があるというときにはテストはすごく欠かせない。
石橋 リクルートで2005年頃の業務システムを作っていた時代、「テストを書かせてくれ」って言うと、マネージングレイヤから「なんでお前は工数倍なんだよ、テストなんか書くな」って言われて。
でも頼むからやらせてくれと言って、実際にやった結果、2倍のコストに見合うものではないけれど、期待されたクオリティは維持されて継続メンテナンスとしては工数に見合う価値はあるねと、認められたことはあったね。
伊藤 テストをどれくらい書けばいいのか、基準を教えてくれ、という人はまさにその議論を上司としていて、でもここにいる人たちの答えは「いい感じで」みたいな。
石橋 だから継続的に1年のメンテコストなどで考えればテストは効果的ではないかなと。
≫後編に続きます。後編では、どうすれば組織としてCIやテストに取り組めるのか。そして組織内での情報共有などについての議論が進みます。
（2014/1/21 9:20追記 舘野氏の名称が一部間違っており。修正しました。冒頭の伊藤氏の発言をCIの回数からリリースの回数に修正しました。hitode909氏の記事は江島氏の記事より前に書かれたもので、対応する発言を修正しました。）
あわせて読みたい
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（後編）。CROSS 2014
≪前の記事
NetAppが2つのフラッシュストレージ製品を展開。激化するフラッシュストレージ市場を勝ち抜くため。NetApp Innovation 2014
