「コードカバレッジ100％を強制します」
エムティーアイ上席執行役員CTOの古賀和幸氏は3年ほど前、こう宣言した。コードカバレッジとは、ソースコードに対してテストが実施された割合を示す数字である。
コンテンツ配信事業を手掛けるMTIは、ヘルスケア分野のサービスを提供するシステムの開発にあたり、「テスト駆動開発（TDD）」という手法を採用している。古賀氏が冒頭の宣言をしたのはTDDの導入と同時であった。
TDDはまず先に、テストのためのコードを書き、その後に実際のソースコードを書く。あらかじめ作っておいたテストコードですぐにソースコードをテストできる。つまり、プログラム開発のプロセスに単体テストを組み込んだ開発手法と言える。ソースコードの実装段階でバグを発見できるため、結合テストや本番リリース後に発生する不具合を減らすことができる。
古賀氏の要請は、テストコードでソースコードを100％テストすることであった。どちらかのコードの出来が悪いと、テストコードでテストされていない部分が残るソースコードが作成されてしまう。これではTDDの効果が出ない。
コードカバレッジが100％を満たさないときは、開発したエンジニアに理由を説明させるようにした。このルールを適用した当初、開発効率が大幅に悪化した。それでも、古賀氏はルールを緩めることはしなかった。
古賀氏がTDDの採用に踏み切ったのは、コードの品質を維持しつつ、しかもユーザーが新しいサービスや機能を必要とするタイミングで、それらの機能やサービスをリリースできるようにするためだった。
MTIのようにコンシューマー向けにサービスを提供するビジネスでは、迅速なサービス展開が求められる。ところが、それまでのやり方では何とかタイミングを逃さずにリリースできていたものの、リリース後のバグが多かった。
バグが多い原因は2つあった。1つは、リリース前に十分なテストを実施していなかったこと。以前からテストツールを使った単体テストを実行していたが、それは強制ではなかった。
2つ目の原因は、要件定義書の内容と最終的なソースコードの内容が異なっていたこと。機能要件を定義した後に発生した新たな要件を、ソースコードの実装工程で積極的に取り込んでいったためだ。この結果、既存のソースコードを改修・追加した際の影響範囲を把握しづらくなった。
TDD導入後にいったん下がった開発効率は次第に改善していった。コードカバレッジ100％を達成できなければサービスインできないという状況を作り出すことで、現場のエンジニアの技術力が上がり、テストしやすいソースコードが作成されるようになったからだ。
結果的に、他のエンジニアが見ても読みやすいソースコードとなり、テストコードも機能要件の定義書として活用できるほど分りやすい内容になっていった。
MTIはTDDの採用に当たって継続的インテグレーションツール「Jenkins」を使い、ソースコードの保存と同時に単体テストが自動的に実行される仕組みを構築した。
同じ仕組みを使って古賀氏が次に目指すのは、受け入れテストの自動化である。Webアプリの画面操作を自動化する「Selenium」といったツールを使って実現する考えだ。
「提供すべき機能やサービスは増えていく一方。だが開発要員のリソースは限られている。短期間に対応するためにも自動化は避けられない」と古賀氏は話す。古賀氏の挑戦はまだまだ続く。
日経SYSTEMS
