株式会社Odd-e Japanの開発エンジニアである金井 大輝は、ソフトウェア開発の「テスト技術」において、No.1を目指しています。
金井は「テスト」＝最終チェックといった通念を覆すべく、従来の通念の逆を行く方法にたどり着きました。
彼の大きな挫折経験を通しながら、テスト技術の本質に迫ります。
株式会社Odd-e Japan（以下、Odd-e）では、エンジニアは全員TDD（テスト駆動開発という開発スタイル）で開発を進めています。
“呼吸をするようにテストを書く”ーーそれが、彼らの今の姿です。
TDDとは、製品のプログラムを書く前に、仕様をテストコードで定義し、そのテストが通るように製品のプログラムを書いていくーーつまり、答えを先につくり、その答えにたどり着くための方法を書いていくという、通常の概念とはまったく逆の発想から来る開発手法です。
開発者の金井は、ソフトウェア開発における「テストの意義」についてこう説明します。
理想を実現させるためには、リファクタリング（再構成）と再テストを繰り返して“誰でも読みやすく、変更しやすいきれいなコード”を保つ必要があります。
金井は、「つい汎用的につくってしまう」「臭いものにはふたをする」「自分がつくったものは正しい（正しい結果が返ってくるテスト作成）」この3つが、人のよくある習性だといいます。
こうした“人の習性”に対して、テスト駆動開発にはどういった利点、意義があるのでしょうか。
テストファースト x 自動テストでいつでもリファクタリングOKな環境は非常に有効です。“キレイなコード”であり続けるためには、小さく物をつくる必要があります。テストを最初に書くということは、『なぜこれが必要なのか』や『成果物のゴール』を意識することにつながり、“つくりすぎ”を防ぐことができます。さらに、つくったテストをシステムで自動検知できるようにすれば、リファクタリングも強気にできます。その結果、事なかれ主義にならず、よりよいコードを追求できるんです。
そんな金井はもともと、前職で20名前後のメンバーを束ねるリードエンジニアでした。
当時の私は今とは全然考え方が違ったんです。考えられるだけの汎用性や共通化を考慮し、詳細な設計通りに開発し、最後にまとめてテストを行なう。これを考え実行できる人が、“イケてるエンジニア”なのだと思っていました。
ウォーターフォール開発環境下でまい進してきた金井が、TDDに魅せられたのには理由があります。
彼の大きな大きな“失敗”が、彼に根付いていた観念を180度変えたのです。
それは、金井が管理会計のシステム開発を行なった時のこと。
当時、プロジェクト開始初週からスケジュールとの乖離がはじまっていました。
設計思想もなく各々がバラバラに動き、チームとして運用できていない状況でした。
このままだと納期に間に合わないのは確実だと思った金井は、自ら手を挙げプロジェクトをリードすることを決意。
当時の金井は自信満々で、とにかく綿密に設計した内容をただ伝えれば必ず成功すると、心から思っていました。
ところがプロジェクト後半になるにつれ、彼が満を持して書いた設計は、つくり込んだ汎用クラスがうまく噛み合わない、デザインパターンが足枷になるなど様々な原因が重なり、要求した内容通りにはいきませんでした。
結局1カ月の延期と、3割の機能削減でリリースしましたが、納期重視のプロジェクトであったため、“自動テストを書かない”という負債を受け入れる選択もしました。そのため、リファクタリングがしづらい状況を前提として、今後の開発をしていかなければなりません。自分たちの首を自分たちで絞めるような状況でした。
達成感もなく、途方もない追加対応に追われていた金井とチームメンバーはさらに追い打ちをかけられます。
「半年後、製品をクローズする」と製品責任者から発表があったのです。
抽象度が高いシステムであったので複雑性が増し、メンバーの認識を合わせることが難しく、手が止まってしまうこともしばしばありました。今考えるとすごくもったいないことをしていました。なぜなら時間をかけて幅広く製品を用意しても、お客様には結局お使いいただけなかったんですから。
誰のための、何のためのシステムだったのか。
強烈な後悔と自責の念にかられながらも、金井はこの闇のような問いに向き合いました。
「もう絶対に不要な機能はつくりたくない。どうしたらユーザが求めているコア機能にもっと時間を使うことができるのだろうか？」
このことをきっかけに、チームやプロダクトをより効率的、効果的につくる手法や考え方ーースクラムやアジャイルを真剣に勉強しはじめたのです。
これまでも、スクラムやアジャイルは触れたことはあったものの「しっかりと理解しようとはしていなかった」という金井。
「アジャイル」という考え方やチーム開発手法「スクラム」に加え、実現するための技術もセットで知見が深いことに魅力を感じ、Odd-eに入社します。
その後、すぐにCSD（Certified Scrum Developer）を受けることを志願しました。
CSDとは、スクラムの理論やコンセプトをエンジニアとして実践できるという国際認定資格が取得できるトレーニングです。
1週間という限られた時間で、小規模なアプリケーション開発をOdd-eのアジャイルコーチのサポートを受けながら実践。
スクラムの基本プラクティス（概念やルール等）のほか、テスト駆動開発（TDD）、受け入れテスト駆動開発（ATDD）、リファクタリングなど、多くの技術的な手法を学ぶとともに、手法を使ってレガシーコードを改善する方法も学ぶことができます。
何よりもアジャイル開発手法のXP（Extreme Programming）からのアイデアである創発的設計（進化的設計）の考え方や、その考え方を実現するためのTDDという一連のプロセスとして学べたことが大きかったです。
「創発的設計」とは一言でいうと、「初期の設計よりもリファクタリングによる再設計を重視する」考え方。
一方、TDDは「最小の単位でしかプログラムを書かないこと」を重要とする手法。
小さな単位で開発・テストをすることで、ステークホルダーや顧客に対して“目に見える成果”としてつくることができ、こまめにフィードバックをもらえるというスタイルに出会った金井は、ここで一気に夢中になります。
そのテストの最小の単位とはーー
たとえば足し算をする関数をつくる場合、最初に書くテストケースは『1+1を指定したら2が出力されること』となります。このテストが通る最小単位のコードは『ただ2を返す』関数です。具体的に書くと以下のような実装です。
function plus(x, y) {return 2}
これが最小単位の実装です。このように、最小単位のテストコードを積み上げていきます。すごく小さな単位に、私も学びはじめた当初すごく驚きました（笑）。
テストコードを初めに書いたり、テストコードを自動化させることに対して多くの人がメリットを感じていなかったり、テストがないコーディングよりコストがかかると思う人が依然多い現状があります。
長期的視点にたてば開発スピードが平準化でき、テストコード自体が“実行可能な仕様書（メンテナンスが保証されている仕様書）”になることで、メンバーの変更に左右されない強固なシステムができます。テストファーストの考え方が当たり前になれば、“なぜつくるのかを強く意識するエンジニア”と“技術的負債が少ないシステム”が当たり前になる。そんな世の中にしていきたい。そのためにもまずは自分のチーム、組織から。そして共感してくださる他企業の仲間たちとも、研さんを積んでいきたいです。
金井は、そう明るく語ります。
各種トレーニングについては
以下のリンク先よりお申し込みください。
“テスト”と聞くと、計画したものをすべてつくり終えた後で、意図通りに動くかどうかを確認するためのもの、と考える人が多いのではないでしょうか。しかしこれからの時代は、製品にかかわる人の意図や顧客のニーズが変わっていく時代。テストのとらえ方として“意図通りに動くか”という視点だけでなく、“いかに変化に対応しやすい状況をつくるか”がとても大切だと思ったんです。