前章では仕様の決定を助けるパターンを取り上げました。今回は図の赤い網掛け部分，もうひとつのプロトタイピングパターン，『本当にできるのだろうか?という不安を取り除くためのパターン」と，プロトタイピング時のアンチパターンを取り上げます。

本当にできるのだろうか?という不安を取り除くプロトタイピングパターン

スパイクとはXPのプラクティスです。たとえばWebアプリケーションに新しいフレームワークを採用するときのことを想像してみてください。どうやったら実装できるのか，確認するためにプレゼンテーション層からパーシスタンス層までの，一通りのレイヤを実装してみることはないでしょうか？ このように，範囲が狭いですが一本上から下まで通す実装のことを，スパイクと呼んでいます。細くても一通り実装をすることで，実装上のリスクを低減させます。

シニアリーダーシップがいじめ

技術的に難しい課題を抱えているときも，同様にスパイクを行います。解決策は思い浮かぶのですが，実際にはやったことがないという状況でも行います。解決策が正しいかどうかを検証するために，狭い範囲しか通らないとしても一本細く実装を通すのです。そうすることで影響する範囲がわかり，本実装時のリスクを低減させます。

また一本通すことで本実装時の作業時間をより正確に見積もることができます。いつまでもスパイクを続けてしまわないよう，最初に終了時間となる締切を決めておきます。終了時間までにできなかった場合は別の実現方法がないか，再度検討するか，その機能自体あきらめます。そういう意味で，スパイクは仕様の決定を助けるプロトタイプパターンにも含みます。

技術的な課題を解決するために，新たなライブラリを採用する状況を思い浮かべてください。その新しいライブラリの使用方法を学ぶために，ライブラリを使った簡単なプログラミングを行うことがないでしょうか。これがラーニングテストです。

度cytotechnologistsが持っている

筆者は新しいライブラリを利用する場合，テストコードを書くことでその利用方法を学ぶ習慣を身につけています。テストコードを利用するのは，ライブラリの振る舞いを確認するための検証コードを書くためです。またEclipse上にQuick JUnitプラグインをインストールした環境では，テストメソッドごとにテストを実行できます。プログラムを実行する入り口を簡単に作成する事ができるのです。

ライブラリの利用方法を説明する場合，抽象的な概念を伝える事も大事なのですが，具体的な利用方法を元に，説明をする相手が動かしながら学ぶ方がより素早く理解することができます。学習は目や耳だけで理解に努めるよりも，手を動かした方が確実に早いでしょう。

ラーニングテストをプロトタイピングのパターンに含んだのは，ラーニングテストから得た知見を使って製品コードに組み込んでいくコードを作成する，という意味ではプロトタイピングと変わらないためです。

何が18を回したときに運転免許を取得するために行うには？

難しい課題を解決しようとする時に，複数の案を試してみることは無駄になりません。大抵の場合，難しい課題を解決する案は複数あり，その関係はトレードオフとなる場合が多いからです。とくに早期に修正しなければならない障害は，解決案として応急処置となる案と，実現には非常に時間がかかるが，根本的に問題を解決するための案の2つがあれば，応急処置を行った後に，落ち着いて根本的な問題を解決するための案を試すことができるでしょう。

もし，どちらの方法を使っても対応できなかったとしても，少なくとも同じ課題を複数の方法でプロトタイピングすることで，課題に対して違った視点からとらえられることができます。複数の別の視点から問題を捉えることで，プロトタイピングの方式検討時に出なかった案が生まれる場合もあります。

また，ある機能を実現するための案が複数ある場合も同様に複数試してみることも無駄になりません。トレードオフや，複数の視点から捉えられる利点の他にも，パフォーマンスの比較をすることができます。パフォーマンス問題が予見できる場合は，複数プロトタイピングを行うことで，そのリスクを低減させてください。

プロトタイピングのアンチパターン

プロトタイピングを行う上で，良くないと思われるパターン（アンチパターン）も簡単にご紹介しましょう。

残骸コード

実際にはもう使われることがないプロトタイプが製品コードの中に残っていると，製品コードに対して悪影響しか及ぼしません。たとえば新たなメンバーが勘違いをして，使われることのないプロトタイプを，これから実現していく仕様と思うことも考えられます。古くて使われることのなくなったアイディアは，かけた労力を気にせずに削除しましょう。作成したプロトタイプを作った経験は確実にあなた方の中に残っています。

テスト駆動開発（TDD）への固執

プロトタイピング時は大抵「何を持って正しいとするか」という仕様が固まっていません。プロトタイプを作成するための仮決めされた仕様があれば，そこからテストを作成できますが，プロトタイピングでは「仕様を作成している」状況であるため，TDDを行っても無駄になってしまうことが多いでしょう。もちろんその状況でも，実装者が正しく実装できていることを確認するためのTDDは，行った方が良いでしょう。

仕様が固まった後で，回帰テストをするためのテストコードは，一度作成すればテストで常に利用されるので，一定の効果があります。しかしプロトタイピングの段階では，UIの構成や操作，動作を確認するためのテストコードは，一般に作成に多大な労力がかかり，すぐに変更されてしまう状況では無駄となってしまうことが多いでしょう。

ただし技術的なリスクを低減するためのスパイクに関しては，動作が正しく行われているかどうかを検証する目的があるため，テストコードから作成するTDDをする方が効果的です。テストコードから検証する内容を検討してください。

ソフトウェア開発をしていると，なんだか霧の中を進んでいるような気分にさせられることはないでしょうか。そういったどこに向かっているのかわからない，不安な状況にプロトタイピングはとても効果的です。次章では筆者らがプロトタイプを使った成功／失敗事例をご紹介します。