エンジニアのスキルを伸ばす“テスト駆動開発”を学んでみよう

2014年7月30日(水)
吉谷 愛
  1. [高梨] こちらを見てください。
  1. [古谷] あれ?これって、ウォーターフォールのことですか?
  2. [高梨] はい。そのため、「作りたいものが予め明確に決まっていない」場合、このやり方だと、よほど運が強く予見力のあるリーダーがいない限り、あらかた出来上がってしまったとおもっていたのに、中盤以降で仕様変更が頻発し、デスマーチまっしぐらになってしまう可能性があります。また、「作りたいものは予め決まっている」ようでも、フタを開けるとそうではないプロジェクトがとても多い。古谷さんもご存じのように、ウォーターフォールでも大半の開発は途中で仕様変更が入ります。もちろんそれが想定の範囲のブレならいいのですが、大きく設計を変更しなければならないようだと、手戻りが大きすぎて破綻します。結果、現場でコードのコピペなど力技でごまかして「想定の範囲内」に見せてしまうケースって、実はかなり多いと思うんですよね。本来保守のことを考えると、設計を見直すべきなのですが、その時間がなくて、ごまかしが横行しているのが現実ではないでしょうか。
  3. [古谷] 確かにそんな感じですね…。そういえば、仕様変更に伴っての大幅な設計変更が発生するのを防ぐために、開発側がお客様に「仕様凍結」と言って、仕様変更を受け付けないようにしてしまうことをよく聞きます。自分が1プログラマの時は、そういう動きをしてくれるリーダーに感謝していましたが、結局出来上がったのはお客様が本来求めていないシステムになるのであれば、本末転倒ですよね。
  4. [高梨] そう、要は、本当はビックバン型の設計に向いていないものまで、ビックバン型でやってしまっているということが悲劇の温床なのです。例えば「既存システムを新システムに置き換える」ようなプロジェクトは仕様が決まっていて、一見ビックバン型に向いていそうですが、経験上色々な関係者の新システムへの期待が絡んで、実は非常に混沌としていることが多いんですよね…。
    すみません、ちょっと話が長くなりました。ではいよいよ、ご質問にあったインクリメンタル設計についてご説明します。こちらをご覧ください。
  1. [古谷] これは…、まさにアジャイルですね。
  2. [高梨] そうですね。インクリメンタルな設計の場合、まさにインクリメントしていく感じで、最低限必要な機能から「少しずつ」開発を進め、その過程で設計自体も「少しずつ」進化させていきます。
  3. [古谷] ありがとうございます。まだTDDとインクリメンタルな設計が結びついてはいませんが、「インクリメンタルな設計」自体のイメージはなんとなくわきました。
  4. [高梨] では、具体的にどれくらい少しずつやるか、さっそく実践して感覚をつかんでいきましょうか?
  5. [古谷] えっ!?私まだTDDについてこれ以上のこと何にも知らないですけど!!
  6. [高梨] それでは、まずざっくりTDDの流れについて説明していきましょう。こちらを見てください。
  1. [古谷] 三角形になっていますが、まずはどこからスタートですか?
  2. [高梨] Red(失敗)の「失敗するテストケースを書く」からです。TDDの場合、Red(失敗)とGreen(成功)を繰り返し、Refactor(改造)の工程を経て再度Red(失敗)に移ります。まあでも百聞は一見に如かずですから、やってみましょう。今回はRuby言語での開発を想定して、簡単にTDDのツールのご紹介をします。
  3. [古谷] えー!?展開早くないですかー!?あ、あと、私あまりRuby詳しくないですけど!
  4. [高梨] 安心してください、最初はそんなに高いRuby言語の知識がなくても大丈夫です。TDDだけでなくRubyの知識もついて一石二鳥ですよ。
  5. [古谷] は、はい…。
  6. [高梨] それでは、こちらがRubyの場合に一般的に使われているTDDのツールです。
  1. [古谷] あ、「なんちゃらUnit」は、他の言語でもよく目にしますね。
  2. [高梨] そうです、あれと同じイメージでOKです。今回はこの中のminitestを使用します。Ruby1.9.3から標準で提供されていますので、Rubyをインストールしていたら、何もしなくてそのまま使えます。さっ、では、いよいよ実戦に入りましょう!今回の課題はこちらです。
  1. [古谷] ん?TDDってインクリメンタルな設計を促すから「作りたいものが決まっていない、わからない」場合に向いているんですよね?ボウリングの点数計算なら、既に決まっているじゃないですか?
  2. [高梨] その通りですが、ボウリングの点数計算は結構複雑ですので、いきなり最初から完璧な設計をおこすのはなかなか難しいでしょう。また、ルール自体は馴染みのあるものなので、演習課題として採用してみました。
  3. [古谷] なるほど!でもすみません、実は私の平均スコアは80弱なので、正直ストライクのボーナスルールなんかはよくわかってないです…。
  4. [高梨] そ、そうでしたか。では簡単にボウリングのルールの説明をしましょう。
フロイデ株式会社 代表取締役

「最新のアーキテクチャを追及し続ける技術者集団」を目指す、フロイデ株式会社代表取締役社長。現在は、自身のCOBOLからRailsまでの非常に幅広い開発経験や、学生や未経験社員への技術指導経験を糧に、技術講師としてソフトウエアエンジニアの育成に注力している。2013年06月より、初心者向けの「はじめようRuby on Rails開発!」シリーズを考案。“技術者の立場にたった、技術者の心に火をつける”熱い講義をモットーとしている。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています