プロジェクトで生まれる不安を軽くするためのプロトタイピング

プロジェクトの中で一番不安に思っている人は誰でしょうか?

「あー，やばい。もう24時だ。でも今日までにやるはずだった障害修正がまだまだ終わりそうにない。早いこと終わらせないとお客さまに怒られるどころか，会社が訴えられかねない。でもまだ日が登るまで時間がある。頑張ろう」という毎日が続いている疲弊した開発者も，相当毎日に不安を感じていると思います。が，それよりも不安なのは，開発を依頼した，その時のお客さまです。「本当にできるのだろうか，この人たちに。これだけ高いお金をかけるのだから，できて当然だよね。いやいや，自分たちの考えているものよりも素晴らしいものができるに違いない。彼らはプロなのだから」と過度に期待をしている場合もあるでしょう。しかし，その気持ちの根っこは「不安」です。

私たち開発者の立場からしてみれば，依頼されている作業がなんとなくできるかどうかくらいは，経験から判断することができます。だから，その不安もコントロールすることができるはずです（もし開発者が「無理」と思っているようなプロジェクトは，ほぼ間違いなく失敗してしまうでしょうから，営業に対してNGを上げるでしょう。あ，営業が無理やり受注してきた。そうですか。体を壊さなくてすむよう，あんまり無理しないように調整してくださいね)。

それでは「自分がまったく経験のない作業を依頼する立場」を想像してみてください。たとえば「自分の家を建てる」。世間に家を建てる事を請け負う会社はたくさんあり，家を建てたこともある大工さんはたくさんいるでしょう。しかし，不法建築や手抜き工事が問題として取り沙汰されたのは記憶に新しいと思います。もちろん世の中のほとんどの会社，大工さんは手抜き工事や不法建築はしないように努めます。が，依頼した彼らを不安に思う気持ちは想像できたのではないでしょうか。お客さまの感覚はそれに近いのです。

もちろん製品開発をしているような筆者の現場は，最初に「お客さまありき」ではありません。なので，筆者の現場には「発注者」という立場の人はいないと思われる方もいらっしゃるでしょう。でも「本当にそうでしょうか？」筆者のような製品開発の現場でも，予算があり，予算に責任を持つボスがいるのです。ボスからしてみれば，「コンセプトはいいけれども，本当に彼らがこれを形にすることができるのだろうか」と不安に思うことでしょう。

それを解決する手段のひとつがプロトタイプです。形のないものをベースに話を進めることは，お互いの頭の中の想像にすぎません。それを徐々に形作っていくことがプロトタイピングなのです。いくら「デザインモック」や「設計書」を作成しても，それは「絵に描いた餅」です。到底食べることはできません。プロトタイピングを進めていけば，最初は「餅のようなもの」だったものが，繰り返し作り直していくことで「餅」に近づけることができるのです。

「形のない，よくわからないモノ」から「ハリボテでもそれっぽいもの」を作ることでお客さまと開発者の間で共通の認識をもって議論ができます。議論を深めることでお客さま自身が求めているものを認識し，さらに両者間で信頼関係を築くことができるのです。口先だけ，頭の中だけの話として捉えられないでしょう。その一例をご紹介しましょう。

形にすることで生まれた対話

先日とあるカンファレンスに参加してきました。カンファレンスなので，技術動向の調査という目的ももちろんあったのですが，今回はビジネス上の交渉が参加の主目的でした。今回の交渉では，「自分たちは，この製品を使ってこういうものを作りたい」という事を示すためのプロトタイプを作成していました。そのプロトタイプを，セッションでスピーカーをしている方に見せてまわっていました。スピーカーの方には，プロトタイプを作成する時に抱えていた問題を，セッションに関連する話題に合わせて質問してまわったのです。

もちろん，相手にとってはいい迷惑ではあったと思います。しかし，自分たちは何者であるのか，認識してもらうためにはとても効果があったようです。その後望んだビジネスの交渉の現場に，そのスピーカーの方が現れ，私たちがどういったものを作っているのか，スピーカーの方からも説明がありました。もちろん交渉がスムーズに進んだ事はいうまでもありません。

この例はお客さまの不安を低減させると言うよりも，自分たちの不安を低減するのに有効な手段となりました。製品を作っている開発者にとって，自分たちの出している製品に反応がないことが一番不安なのです。

最後に，プロトタイピングにおいて，よく聞く疑問や起きうる失敗についてふれます。

プロトタイピングはデザインモックで十分ではないのか?

よくWebシステムの開発現場では，デザインを確認する目的でデザインモックを作成し，それを。これもプロトタイプの一種であることは間違いないのですが，画面が実際に動くことで生まれる仕様／要望はあります。実際に開発が始まり，動く「モノ」ができてきたときに感じる「違和感」は，静的なデザインモックからは決して生まれません。それは動かしてみたときの「操作感」や「使用感」は動かしてみなければ感じられないからです。 開発が始まった後に生まれたそれらの要望は，開発見積に含まれていませんから，なかなか仕様として取り入れられません。本来，ソフトウェアは「動くモノ」です。プロトタイピングもできれば動くものを作成することで，操作感や使用感も確認できます。ここまでして初めて本当にお客さまが求めているものかどうか確認できます。

第2章でご紹介したペーパープロトタイピングでは「操作感」までは確認できますが，「使用感」は紙なので確認できません。「使用感」が重要になる場合は，作成したペーパープロトを元にコンピュータ上でプロトタイプを作成しましょう。

スパイクは，機能的な実現で安心すると足をすくわれる

スパイクをする場合は，終了条件についてはある程度時間をかけて検討をしましょう。機能要求の実現ができることはもちろん大切ですが，スパイクは技術的なリスクを削減するために行われるものです。技術的なリスクの中には，たとえばパフォーマンスのような非機能要件も含まれるでしょう。スパイクをした結果，非機能要件を満たせないことは，技術的なリスクが高いため，非常に起きやすいです。実装後に検証する方法も含め，よく検討してください。

プロトタイピングはさまざまな場面で使えます。成果物もそのまま製品コードまで育てていくこともできますし，不要と判断されて捨てられる場合も，作成時に得た経験は今後の製品作りに役立てることができるでしょう。『達人プログラマー』 ※1から引用しますが，

プロトタイプとは，すなわち経験学習です。その価値は生成されたコード中にあるのではなく，学習した教訓にあるのです。

とあります。

「プロトタイプの真の目的は学びにある」のです。

※1 ）

『達人プログラマー システム開発の職人から名匠への道』（Andrew Hunt，David Thomas 著／村上雅章 訳／ピアソン・エデュケーション／ISBN4-89471-274-1）p.54より