ミクシィにおけるTDDの取り組みと実態
坂本大輔氏（以下、坂本）：よろしくお願いいたします。
（会場拍手）
ありがとうございます。まずは簡単に自己紹介から。株式会社ミクシィの坂本と申します。
2017年度に新卒として入社しまして、今2年目です。ふだんはサーバーサイドのエンジニアとしてやっていて、Rubyを書いたりAWSと戯れたり、ElixirやJavaScriptやgolangを書いたり、いろんなことをしております。
右の写真は私のSlackのアイコンなんですけど、スピーカー（の紹介のところに）よく見たら「エンジニア」って書いてあって。
「そんなもんわかってるわい！」みたいなすごいざっくりとした説明がされています。
さっそく本題に入っていきたいと思います。まず、今日話すことと話さないことについてです。
TDDというといろいろ議論が巻き起こるんですが、今日話すこととしては、弊社でテスト駆動開発についていろいろ研修をやっているので、そういった研修がどういったものかということを簡単にご説明いたします。
あとは、社内全体に対して「TDDどうですかね？」みたいな簡単なアンケートを取ったので、その結果と簡単な考察をみなさんに共有できたらと思います。
あと、私個人の感想です。「感想」というところを強調しております。話さないこととしては「TDDとは何ぞや？」とか「こうやればいい」とかいうことですね。そのへんはまた別の話になりますので、今回はあまり触れません。
さっそく弊社の取り組みの話をしようと思うんですけど、ちょっと会場の雰囲気というか、層を見ておきたいんですが、学生の方ってどれくらいいますか？ 挙手してもらっていいですか？
（会場挙手）
お～半分、いや、6割7割くらい。じゃあ、テスト駆動開発について、詳細に説明はできなくても多少は知っていて、やったこともある方はどれくらい？
（会場挙手）
なるほど、なるほど。あと、日常でテストちゃんと書いてるよって人はどれくらいいらっしゃいます？ 仕事、趣味問わず。
（会場挙手）
あ、意外と少ない。みなさん挑戦的ですね（笑）。
テストに関する研修を実施
まず、弊社の取り組みについて話をしていきます。大きく2点あります。1つは、テストに関する研修と、あとTDD Challengeといわれるイベントを開催しております。
1つ目のテスト研修について、テストの研修をやっているんですが、なんでそんな研修を行うのか？ というところをお話しします。
今聞いた感じだと、テストを書いたことがある人はぽつぽつだったんですけど、自分たちの書いたプロダクションの品質がちゃんとしているかどうかを保証する一指標としてテストを書くことは一般的ですし、弊社でも部署にかかわらず行われています。
ですが、（みんな）過去それをちゃんと新卒研修として行なったことがない。今聞いた感じだと、やっぱり学生時代だととくに、テストをそもそも書いたことがないとか、そういうツールとか存在は知ってるけどちゃんと書いた経験はないという人がけっこういる。
テストを書いたことがない新卒が各部署に散り散りと配属されていて、あとはその部署に任せるという感じだったんですが、やはり現場としては、最低限軽い研修でもしておいてくれないと困る。
テストコードを書いたことがない人に「じゃあ書いて」って言っても、正直質があまりよろしくなかったり。そもそもテストを書くという文化がなくて、レビューで「テスト書こうね」って指摘する、みたいなことがあったりする。
そういった現場の声を踏まえて、ぜひ研修でやってきましょうよとなって、研修を行っております。始めたのは実は最近で、2017年新卒、僕の代からですね。テストに関する研修が導入されて、その中でTDDという仕組み、開発手法をみんなで学んで研修するということをやっております。
具体的にどういう話をしているかというと「速度を求めるスクリプトを書きなさい」ってやって。「ちゃんと実装していこうね」ということをやってます。
特徴的なのが、プログラムを書かせたあと採点をするんですね。テストデータを出すから結果を返せって言って、結果があっているかどうかを講師が確認するんですけど。
1回しか確認できないという制約を設けています。ですので、1発でちゃんと動くようにきちんとテストを書こうねという研修をやっています。
学生向けイベント「TDD Challenge」
もう1つ、TDD Challengeといわれるイベントもやっております。こちらは、先ほどのテスト研修が17新卒と18新卒の間で非常にウケが良かったです。これはやってよかったということをみんなから聞いたので、学生向けイベントとしてアレンジしたものがTDD Challengeです。
繰り返すようですが、学生時代はなかなかテストを書くことがない。私もあまりちゃんと書いてなかったというか、書いてもすごく適当なことしか書かなかったんですけど。
そもそも、アーキテックというものがあるぞとか、ユニットテストというものがあるぞということを、みんな知ってはいてもちゃんと書いたことがないし、どうやって書けばいいかわからないし、参考になるコードもない。どうしたらいいんだろうという人がなかなか多いんですね。
こちらの研修では、このイベントではPythonを使うと決めているんですけど、「テストというものはこういうふうに書きます」「こういうお題について書いてみましょう」というものを研修の内容から引っ張ってきて、学生向けにイベントとして行なっています。
これはかなり最近の話題で、つい先日、一昨日ぐらいの金曜日にも開催しました。
実際にやってみるとそもそもテストを書いたことない人がほとんどで、経験者は1人しかいないみたいな感じでした。最初にハンズオンでテスト書くぞみたいなところからやっていました。
こういったイベントを通して「テストをちゃんと書こうよ」という話とか、テスト駆動開発という「良い品質のプロダクトをちゃんと作っていきましょう」という啓蒙活動をやっております。
全社でTDDを採用しているわけではない
ここまでいろいろやったんですけど、社内で「みんな結局のところどうよ？」ということをちゃんと聞いたことがなかったんですよ。17年と18年の新卒は研修をやっているので「どう？」って聞いたら「最高」って言うんですが。
じゃあ社内の何年もキャリアを積まれているベテランの方々はどう思っているんだろうと気になって、アンケートを取りました。その結果を発表いたします。
まず、前提を共有しておきます。弊社では本当に多種多様なサービスをやっています。
SNSサービスをやったり、モンスターストライクというスマホアプリを作ったり、最近だとみてねという家族向け写真共有アプリだったり、本当に多種多様なアプリをやっている。
その多種多様さが技術スタックにも大きく現れていて、いわゆるWebアプリケーションや、 AndroidやiOSのネイティブアプリや、Unityによるゲームのアプリとか、本当にたくさん、いろいろなものを使っている。
なので、全社でRuby on Railsを使えとか、その手のこのフレームワークを使えとかアジャイルをやれとか、そういった方針みたいなものは、実はまったく強制していないんです。各組織の人たちがいいと思ったものを採用してくださいというスタンスを取っております。
ですので、この発表はおそらく「TDDが最高だ」みたいな雰囲気をかもし出しているんですが、実は全社で採用してるわけではないということだけ、誤解のないようにしていただけるとありがたいです。
では、どういったアンケートをやったのか。いろいろやりました。回答者数は38名で、ちょっと少なく見えるんですけど、だいたい各チーム1人ずつくらいには聞けているので、全社の雰囲気は掴めているんじゃないかなと思います。
TDDを実践して感じたメリット
全部長々と説明してもいいんですが、それも退屈なので、今回は1つだけ。「TDDを実践してどうだった？」という、メリットとデメリットについて、簡単に話そうと思います。
まずよかったことで、1つは疎結合な実装、仕様や動作サンプルのテストによる明文化。
テスト駆動開発はテストを先に書く開発手法の1つですので、自然的にテストを書きやすいように実装しなくてはならない、設計しなくてはならなくなるというあたりで、ちゃんとした疎結合な実装になりやすくてよかった。
テストコードをちゃんと書けば、それがそのまま仕様になったり動作サンプルとして機能するから非常によかった。ほかにも、実装し忘れを防ぐことができた。これはテストがちゃんとある場合ですね。
あとはレアケースや境界をこぼさずに書けるし、グリーン・レッドを繰り返すことで達成感が得やすい。これはいわゆる、某氏が黄金の回転と言っているやつですね。
1回テストを書いて最低限通るコードを書いたあとリファクタするという、そのフローが非常に良い。達成感が得やすいという意見がありました。
とくにこれは、僕も聞いてて「あ、そうだよね」と思ったんですけど、テストファーストじゃなくても、テストを書きながら進めると安心感がある。テストでちゃんとこの仕様だと落ちる、この仕様だと通るということがわかるので安心感があっていい、とか。
急に知らないコードや覚えていないコードで修正が必要になっても、テストがちゃんと落ちてますよって教えてくれるので安心して進められる、とか。
テストが先行することで、その場しのぎの実装じゃなくてちゃんとテストができる実装ができたり、リファクタするときに安心してできて最高だという意見が得られました。
やってみてわかったデメリット
反対にデメリットをお聞きしたところ、これもなかなかたくさん出てきました。
まず1つ挙げられたのは、テストコードの管理コストです。そもそもテストの質がよくなかったり、いろんなケースをカバーするためにめちゃくちゃ長いテストコードを書かれたりするんですね。
そういった、質が悪かったり、微妙なテストもあるし、ちゃんとした人のテストもあるけどそういうテストコードを常日頃ちゃんとメンテナンスするコストが正直高い、ということが意見として挙げられました。
ほかにも、そもそも既存ベースのところでテストコードが整っていないと、テストを導入するのに時間がかかる。これはテストしにくい設計になっているということの裏返しだなと思っているんですけど。ここらへんを、ちょっとデメリットだと感じている方がいる。
これはだいぶ成長したあとの話になるんですが、プロジェクトが巨大になると、いちいちテストをやってたら正直時間がかかっちゃうという意見も得られました。
私が今所属しているプロジェクトでも、1回フルで回すと、なんとかまだ10分で収まっているんですけど、10分止められるとうっかりTwitterを見てしまって最悪ですね。
（会場笑）
ほかには、例えば新規事業をやってると作り直しとか仕様変更がめちゃくちゃな数なのでテストがすぐ意味なくなったり、検証のためのコードだけどテスト書く必要ある？ となってやめてしまった例もありました。
2つ目は、クライアントアプリのようにビルドテストに時間がかかったり、仕様がコロコロ変わると。クライアントアプリですと見た目の話が入ってきて確認が入るので、テスト時間もかなり大事な要素の1つなのかなと思いました。
ほかにも、ゲームなどの開発では、TDDが向いている点、向いていない点があって正直扱いが難しいという意見があります。
最近ですとUnityでTDDできるようなDIのライブラリの仕組みがあるとかないとかチラッと聞いたんですけど。まだまだやりにくい状況下ということはあるのかなと思いました。
TDDの導入が適さない場合もある
アンケートをまとめますと、やっぱり、テストをちゃんと書こう。テスト駆動については絶対書けと言うわけじゃないですけど、原則として。
テストを書くことを考えながらやるから「どういうケースがあるんだっけ？」「どういう異常系があるんだっけ？」とかちゃんと考えて作るので、仕様漏れなどを回避できるし、ちゃんと設計ができてきていいよね、と感じている人が多い。
あとは、不安をコントロールしながら1歩ずつ進める安心感がメリットとして感じられる。
反対に、テストを回すうえでの環境整備がそもそもかなり重いコストだったり、テストコードをちゃんと使えるようにふだんからメンテナンスすることが大変なところがある。
とくに、大規模なプロジェクトになりますと数年単位でやっているので、数年前のテストコードがあるけど誰もメンテしてないというようなことがあるとちょっと大変だったりする。
ほかにも、僕がとくに大事だなと思った点が、開発するプロダクトの性質だったり、チームのフェーズによって不適当な場合もあって、だから導入していないというパターンもある。導入がよろしくないこともあるんだなと思いました。
TDDとは、プログラミング中の不安をコントロールする手法である
あと、これは個人的な気持ちなんですけど。
『テスト駆動開発』という、和田（卓人）さんが翻訳した、テスト駆動に関する本があります。その中で僕がすごく「そうだよね！」となったところが「テスト駆動開発はプログラミング中の不安をコントロールする手法だ」というまえがきの文で。
我々、プロダクトを書くときに「こういった仕様で作っていきましょう」ってみんなで決めて作っていくんですが。仕様が1個ドンってあると「なにから作ればいいんだっけ？」「こういうケースも考えなきゃいけないよね」っていろんなことを考え出すんですね。
そういう不安が、常にある。不安に押しつぶされてストレスで吐きそうになるようなことがけっこうあるので、テストをまず書くというか、どういうテストケースがあるかを1個ずつ書き出して、不安な点を明らかにしながら進められることはいいと思います。過程で仕様や設計について深く考える必要があるので。
さらに考えてみると「このケースってどうするんだっけ？」という漏れみたいな部分が意外と出てきたりするので、この手法をやるようにしているところが、僕としてはあります。自分が1番信じられないので、こういった手法で無理やり強制しないとつらいですね。
ただし、これ、僕は最高だと思っているんですが、やっぱりこれがそぐわないケースも存在しているので、誰にでも「今すぐやれ」って押し付けることはあまりよろしくないかなと思っております。
これはアンケートにも実は現れておりまして、ぶっちゃけおすすめしたくないという人が実は2割ほどいるんですね。
やっぱり実際にかかるコストが大きかったり、うちのプロダクトには合わないというところで、正直な話あまりおすすめしたくない、という人もいる。そこは結局バランス感覚が大事なのかなと思います。
全体のまとめです。まず、弊社でどういったことをやっているのかという研修の話と、イベントの話をしました。それから弊社に所属するエンジニアたちの気持ちや、実際にどうやっているのかについて簡単にお話ししました。
アンケートについては、あとで公開するスライドに結果が載っているので、チラ見していただいて、もし気になることがあったらなんらか（の方法）で聞いていただけるといいと思います。なんらかって何だろう（笑）。
私からの発表は以上です。ありがとうございました。
（会場拍手）
