実装優先時の考慮点 その１ - プロトタイピングとスパイクソリューション -

ソフトウェア開発を成功させるには、リスクを常に考慮しないといけません。その中でも、新しい環境やアーキテクチャ、ユーザビリティなどのリスクは、ある程度実装してみないとわかりません。

そこで、そのような場合は古くからプロトタイピング（リンク先はWikipedia）が行われてきました。プロトタイピングには捨ててしまう前提で作る「ラピッドプロトタイピング」と実物を徐々に作り上げるプロセスとしての「進化的プロトタイピング」があります。

XPJUG関西の代表やアジャイルラジオで有名な西さんが「WFできないとアジャイルできない」という言葉をつぶやかれていました。

「WFできないとアジャイルできない」という言葉を今更ながら噛みしめている。いきなりプログラム組むとか、異常系の設計しないとか、テストしないとか、アジャイル以前の問題が多い。

— 西　丈善 (@takepu) 2013, 11月 2

エクストリームプログラミング（XP）の調査作業である スパイクソリューション でのソフトウェア開発は調査用の「ラピッドプロトタイピング」ですし、アジャイル開発の繰り返し開発はマイルストーンまでの期間を固定した「進化的プロトタイピング」と似ています。プロトタイピングの注意点もアジャイル開発でもきっと役に立つと思います。

ラピッドプロトタイピング

使い捨てを前提にプロトタイプを作る場合は以下のような目的があるでしょう。

• 技術的な確認
• 性能評価
• 生産性（見積もり）の基準作り
• ユーザビリティの確認、など

ここで注意しないといけないのは、プログラムが動くようになると、捨てるはずで作ったのに、できたつもりになりがちな事です。いわば「やっつけ」で作ったのですから、そのまま流用すると、コードの品質が悪く、アーキテクチャや仕様の検討が不十分で、仕様漏れが生じ易くなります。

後からテストコードを書けば、品質の問題はある程度回避できるかも知れません。しかし、その後の開発では、できている部分に知らず知らず引きずられてしまいがちです。

使い捨ての前提で作り出したのですから、最初から作り直す方が良いでしょう。もし、どうしても正式なコードとして用いるなら、テストコードを用意するだけでなく、「 ほんまか（それで良いか）？」「なんでや（どうしてか）？」とコードを見直した方が良いでしょう。

XPのスパイクソリューション

XPは進化型プロトタイピングのようなものです。繰り返し開発する実開発と調査用のプロトタイプを区別できるように「スパイクソリューション」という言葉を使って、明確に分けるようになったのでしょう。XPエクストリームプログラミング導入編の訳注にこうあります。

スパイクソリューション（spike solution）：大まかな解決。スパイク（大きな釘）を問題の中心に打ち込み、解決を試みるイメージ。精巧ではないが、本当にうまくいくかを大まかに解決する。従来、プロトタイプと言われていたものに近い。

また、アート・オブ・アジャイル デベロップメントではスパイクソリューションの見出しに「私達はもっと情報が必要なとき、小さな独立した実験をする」とされ、「スパイクで書いたコードを捨ててしまうべきでしょうか」との質問に以下のように書かれています。

誰も後で参照する事がないのであれば、捨ててしまおう。スパイクソリューションの目的は、問題の解決方法を知るために、情報を得て実際にやってみることであって、問題を解決するためのコードを作り出す事ではないということを思い出そう。

ラピッドプロトタイピングやスパイクソリューションは、使い捨て前提と割り切ったプロトタイプです。きちんと割り切ることが成功の秘訣なのでしょう。

進化的プロトタイピング

捨ててしまう前提ではなく、段階的に作るプロセスは進化的プロトタイピングと呼ばれます。この場合も、初期のプロトタイプは以下のような目的を持たせると良いでしょう。

• やり方（コーディング基準やプロセス）を決める
• 共通部分のうち必須部分から
• 横展開するベース開発
• 横展開の元ネタ、など

このようにたたき台として作り、それを全体に広げるやり方が向いています。その際には以下のような点に注意すると良いでしょう。

• 作業が効率化する順番に組み立てる
• リスクが低減する順番に組み立てる
• テストコードを必ず用意する

進化的プロトタイピングでは、アーキテクチャを考慮して基本的な作りから始める事を検討すると良いでしょう。見通しが悪いままにとりあえず作っていると、アーキテクチャや仕様の検討が不十分になり、仕様漏れが生じ易くなるからです。 しかし、必要以上に決定しすぎても、プロトタイピングの良さがなくなり、手戻りが増える場合があるので、注意してください。

まとめ

ウォーターフォール型プロセスをベースに標準プロセスが決められている場合でも、プロトタイピングが許されている場合も多くあります。ウォーターフォール型プロセスの欠点は広く知られているからです。

その一方で、闇雲に実装してしまう事や、評価用のプロトタイプをそのまま正式コードにしてしまう事は、常に警戒して注意深く利用されています。

アジャイル開発の長所はたくさんあります。「温故知新」と言われるように、過去の技術のノウハウをふりかえる事で、バランスの取れたより良い未来が見えてくるかもしれません。

「実装優先時の考慮点 その２ - 継続的統合とテスト自動化 -」に続く