トップ » 技術記事 » TDD は新規性の高いサービス開発には適さない

TDD は新規性の高いサービス開発には適さない

タグ: TDD

どうも、あかさたです。エンジニアとしては、スピードを要求される新規性の高いサービス開発時にも「品質のために TDD(テスト駆動開発)は必要か」という思念はよぎるものです。そこで、新規性の高いサービス開発と TDD の相性について考えてみます。

はてなブックマークはテスト駆動で開発していなかったらしい

はてなブックマークの作り直しについて - naoyaのはてなダイアリーを読んでいたら、「テスト駆動開発とサービス開発は相性が悪い」という記述が出てきました。

はてなブックマークの作り直しについて - naoyaのはてなダイアリーより

自分は常々、テスト駆動開発とサービス開発は相性が悪いなと思っていました。新しい機能を作っているときや、新しいサービスを作っているときは、自分でも答えが見えていない状態で作っていることが多くあります。コードを書いているうちに少しずつ問題が解決されていって、最初は見えていなかったものが見えるようになり、答えがみえるようになる、ということが多々あります。作っては壊しを何度も繰り返すこともあります。

こうした議論はよく聞かれるものですし、感覚的には理解できるのですが、「試行錯誤を繰り返すから」という理由だけではむしろ TDD の得意な開発のような気もしてしまいます。この種の話題は定量的な判断を下すのは難しいところがあるので、定性的にもう少し納得できる理由を考えてみます。

なぜ SI 的な開発では TDD が役に立つのか

まず、新規性の高いサービス開発と TDD の相性を考える前に、なぜ SI における開発でテスト駆動開発が有効なのかという話から考えてみます。

基本的に SI は、「ユーザーは本質的な価値を持っていて、SI はその価値を引き出す」ことが目的になります。引き出す価値が存在しているのなら、問われるのは精度という意味に近い品質ですから、SI における開発では、そのシステムの品質を上げることそのものに割と直接的な価値があることになります。(「割と」と書いているのは、SIer がもう少し踏み込むことがあり得るからですが。。。)

システムのライフサイクルなどにも影響されますが、コードのメンテナビリティを確保することは品質に大きな影響を与えますから、TDD を採用することは SI における開発が生み出す価値と直接的な関係があります。

個人的な感覚では、最近の開発というか私の知っている開発ではという話になりますが、アーキテクチャメカニズムはフレームワークなどで割とよく検討されているのですが、その分詳細設計はおざなりになっている感があるので、TDD はそこをよく担保してくれていると思います。

もし、開発における価値・目標が新規性の高いサービス開発でも同じだとすれば、SI と同様 TDD で成果を上げることができるはずです。その点はどうなのでしょうか。

TDD のテストと QA の文脈で行うテスト

ここを読まれている方には、QA(Quality Assurance、品質保証)の経験のない人もいるかもしれないので、たとえば製品開発のようなお堅い品質保証でいうところのテスト工程で行われるテストを「ネタ」風味で紹介しましょう。もちろん、境界値テストのような普通のテストも行いますが、もっととんでもないテスト行うこともあります。

どの本に書かれていたかは覚えていないですし、正確な例かどうかも覚えていませんが、正確性にはさほど意味がないので記憶のまま紹介します。「日本円で動作する自動販売機のテスト」についてです。テストケースは「ウォン硬貨を入れて数発けりを入れる」という感じになります。

開発者としては青ざめるようなテストですが、必要なテストではあります。TDD で行うテストはそういうものではなく、「開発工程の一部」「仕様策定や設計工程の一部」としてとらえてください。従って網羅のさせ方も品質保証で言うところのテストで行われるような組み立て方よりは、仕様書に書くときのような書き方になります。

TDD の開発効率や試行錯誤に対する適用性

やや安易ですが、「品質にコストを払う TDD は長い目で見ればコストを抑えてくれるが、開発速度を要求されるサービス立ち上げ時にはそのコストを払うことができない」と考えることはできます。また、「試行錯誤を繰り返す場合はテストの書き直しコストがあるので、TDD は適さない」という考え方もできます。

しかし、TDD は開発効率の良い開発スタイルですし、試行錯誤するならむしろ書いたコードを細かい単位で確認できる TDD は、新規性の高いサービス開発であってもそれほど相性が悪くないようにも感じます。

TDD の開発効率が良い理由は、プログラミングのコンテキストから外れずに多くの作業をできるからです。テストを書かないと、モデルのちょっとした変更でも UI で確認することになりますから、コンテキストがエディタや IDE から UI に移ることで、開発効率は落ちてしまいます。

新規性の高いサービス開発

新規性の高いサービス開発で SI と異なる点は、そもそも開発するシステムが本質的に価値を持っているかわからないところにあります。新規性の高いサービス開発では、開発とはシステムの作り込みよりもむしろ「コンセプトや外部仕様の練り込み」に重きがおかれます。

プログラミングのコンテキストを離れて、企画的なコンテキストでより多く時間を使うためには、シンプルに「書いては UI を確認する」というスタンスが目的に対しては効率的なのです。極論、「できるだけプログラミングのコンテキストから離れたい」のが新規性の高いサービスの開発であるがために、「できるだけプログラミングで済ませてしまう」TDD とは相容れないのです。

本質的な価値を見つけることに成功したサービスは、TDD を採用するかどうかはともかくとして、品質重視の開発に切り替えることになると思われます。少なくとも、はてなブックマークはそういう道を選んでいます。タイミングをいつにするかが重要なのですが、はてなブックマークの事例を聞いていると(今テストコードを準備しているらしい)、意外とタイミングが遅くても何とかなるようです。(はてなのエンジニアなら技術力があるから元々そこそこの品質でコードを書いているから成り立っているとか、属人的な理由があるのかもしれません。)

まとめ

TDD が新規性の高いサービス開発で適用できない理由は、プログラミング以外のところに力を割くためです。はてなブックマークの事例を見る限りは、どこかで企画重視から品質重視の開発プロセスに切り替えることになりますが、切り替えるタイミングはケースバイケースでそれぞれで判断するしかなさそうです。

一つ、誤解を避けるために補足しておくと、新規サービス開発ではありません。新規性の高いサービス開発です。新規開発でも、既存のサービスを真似たサービスの開発をするなら、TDD で構わないと私は考えています。

以上、TDD と新規性の高いサービス開発に関する考察でした。次回からはまた普通の技術記事か勉強会レポートをお送りします。それでは!


執筆者紹介

あかさた

あかさた

未踏(2006年度下期)でWeb上で動作するモデリング環境 Kodougu の開発をしてました。こちらでもブログを書いています。

TrackBack URL :