チェンジビジョンTRICHORD開発部近藤と申します。平鍋に代わりまして，プロト タイピングの実践などを取り上げます。

チェンジビジョンにおけるプロトタイピングの実践

チェンジビジョンではプロトタイピングが盛んに行われています。たとえば12％ルールといって，週の開発時間の12％は個人のプロジェクトに時間を割り当てる制度があります。12％ルールの時間を現在携わっている製品に対して，追加したい機能のプロトタイプを作成してみたり，まったく別のコンセプトを形にするための時間として利用しています。12％ルールから生まれた実装コードが洗練され，実際に製品に組み込まれることもあれば，12％ルールから生まれたコンセプトが新しい製品として形になっています。

もちろん12％ルールの時間以外の製品開発の現場でもプロトタイピングをよく実施します。たとえば新機能を検討する場面では，UIのイメージを共有して議論を行う目的で，簡単に作成できるプロトタイプを行います。実際に動くプロトタイプを使って議論をすることで，具体的に話を進めることができるのです。

今回はチェンジビジョンにおいて，どのようなプロトタイピングを行っているか，その実践内容をパターンとしてご紹介します。パターンとしたのには理由があります。プロトタイピングは決して形式ばったものではありません。プロトタイピングが必要となった時に判断して，限られた時間の中で仕上げるものだからです。弊社は受託開発が主ではなく，製品開発をビジネスの中心に据えた会社です。しかし，弊社が行っているプロトタイピングは受託開発を主とする多くの方々の参考になるでしょう。

前章ではプロトタイピングの役割を大きく分けて2つ紹介しました。1つは不可視のものを見えるようにすることで「仕様の決定自体を助ける」こと，もう1つは「本当にできるだろうか？」という「作る側の不安を取り除く」ことです。本章でご紹介するパターンはそれぞれの場面で役立たせることができるでしょう。厳密にはプロトタイピングに当たらないものも含みますが，現場で使えるものとしてまとめました。各パターンを結ぶ矢印「→」は，プロトタイピングパターン同士の流れを示しています。

それぞれの状況において判断して使ってください。本章では青い網掛け部分，「⁠仕様の決定を助ける」パターンをご紹介します。

仕様の決定を助けるパターン

まず最初にご紹介するパターンはペーパープロトタイピングです。ペーパープロトタイピングとはその名のとおり，紙を使ったプロトタイピング手法です。やり方は簡単で，画面の構成に合わせて紙を切り，その上に画面の部品をざっくり描いていきます。定規などを使って清書したくなる気分になることもありますが，ペーパープロトタイピングをする場面では清書はご法度です。ラフに手書きで作成することで，画面全体のイメージを共有する事を目的にしてください。そして画面の部品の操作を，紙を使ってシミュレートしていきます。誰かがコンピュータ役となり，ユーザ役と対話しながら画面を動かしていくことで，構成部品を作っていったり，操作感を確認していくのは非常に有効です。

紙なので，固定したい場合はセロテープを用いるとよいでしょう。もし画面の構成に対して疑問点や，更なる検討項目があればコメントとして付箋に書いて貼っておくのもよいでしょう。紙を使ったプロトタイピングは加工が簡単なので，他にもいろいろ工夫することができます。

ホワイトボードやデジカメですが，ホワイトボードには操作手順と状況をまとめていき，デジカメで撮っておきます。ホワイトボードに操作手順などを書くのは，内容を簡単に削除したり，修正ができるからです。もちろん紙に操作手順などを書くこともできますが，ホワイトボードの方がざくっと消せるので筆者は愛用しています。ペーパープロトタイピングを行う場ではできるだけ手軽に操作を共有することに重点を置いてください。

ペーパープロトタイピングについては，詳しく書かれた書籍（※1）がありますので参考にしてください。

プロトタイピングで作成した成果物の公開を定期的に行うと，フィードバックを得る／修正する機会が一定になるため，開発にリズムが生まれます。前回のプロトタイピング検討会議で顧客から出された要望を受けて修正を繰り替えしていきます。「⁠仕様を固めていく」段階なので，仕様を固めるためにどんどん変更して，プロトタイプを元に確認していきます。

UIはユーザからすると簡単に変更できそうな部分ですが，作る我々からすると，実は変更しづらい部分ではないでしょうか。できるだけ早めにUIの仕様を固めることが，全体の仕様固めを進める上で有効です。

動作確認が容易な環境を用いてプロトタイピングを行うと，仕様を確認している会議のその場で修正することができます。動的言語であれば，変更して確認するまでの修正時間が短くなることは確かですが，動的言語でなくとも工夫次第でフィードバックまでの時間を短くすることができます。

Javaを使ったWebアプリケーションの場合，JSPを使うと，スクリプトレットが悪影響を及ぼして可読性を損なうと言われます。しかし簡単にその場で修正しながら動作を作成できる環境として，JSPを採用する事はその欠点を補う選択肢として，説得力があります。実際の製品に組み込む場合はプレゼンテーション層には既にJSP以外を採用している場合もあるでしょう。

でも大切なのは，その場でフィードバックを得られる環境でプロトタイピングを行うと言うことです。Java以外の環境でも，その場でプロトタイプを修正できれば，顧客とともに仕様を作っていくことができるので，手戻りを少なくすることができるでしょう。

以上「仕様の決定自体を助ける」パターンでした。気になったパターンがあれば，ぜひ開発の中で試してみてください。次章では「本当にできるだろうか？」という作る側の不安を取り除くパターンとアンチパターンを取り上げます。

※1）

『ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする⁠』⁠ Carolyn Snyder 著／黒須 正明 監訳／オーム社／ISBN4-274-06566-9