デモの解剖学

Robert Hess
Microsoft Corporation

March 12, 2001
日本語版最終更新日 2001年4月9日

プログラマの中には、プログラミングという仕事をかなり楽にこなしている人もいます。デスクにゆったり腰掛け、十分に検討された仕様に基づいてコードを記述します。チームのメンバ全員で達成すべき機能が明確にされたマイルストーンは、目の前に丁寧に用意されています。開発サイクルのある時点では、「死の行進」と呼ばれる期間、つまりスケジュールが間に合わなくなる恐れが出てきて、当然のように全員が夜遅くまで、そして週末もスケジュールを守るために働かざるをえない期間に入ります。それでも、仕事の流れ自体は多くの場合はっきりしています。目標と、それを達成するためには何をする必要があるかがはっきりと分かっています。

しかし、これとはまったく異なる環境でコードを記述しているプログラマがいます。デモや、開発するソフトウェアソリューションとして提案される予定のプロトタイプのためだけに、デザインを考え、コードを開発するプログラマです。この種の開発がすべての企業で行われるわけではなく、またその必要もありません。しかし、この種の開発には、この手の作業を行う違った種類のプログラマと、この手のプログラミングを行うための違ったアプローチが、間違いなく必要になります。

ここでお話しているのは、完成した、あるいはほぼ完成したアプリケーションの機能のデモを観衆の前で行う場合についてだけではありません。ここでは、「実際の」製品の開発がまだそれほど進んでいない段階で、デモのデザインを考え、開発する場合についての話をします。このようなデモは、経営者やパートナー、そして提案しようとしているアプリケーションまたはテクノロジの「潜在的な」投資家に披露するために使用されます。

GUI または Web ベースの環境で仕事をする場合、開発サイクルのある時点では、どのように「見える」かということにすべてが大きく左右されます。また、関心を持たせ、興味を掻き立てるためにデモが必要になるとき、デモの視覚的な表現が、要点をしっかりと伝えるために重要になることが多くあります。

ホームオートメーションに接続された PC のデモを行うと仮定しましょう。デモとして開発したアプリケーションには「消灯」というボタンがあって、そのボタンを押すとライトが消えます。そう、これではまったく退屈ですね。では、デモを PocketPC を使って行うことにしましょう。画面には家の見取り図が表示され、ライトが家のどこにあるかが分かるようになっています。デモの実演者が、「ドラッグアンドドロップ」を使って、家のあちこちからいくつかライトを選び、PocketPC の画面上の仮想スイッチに選択したライトをドロップします。その後、実演者が画面上の仮想スイッチを押すと選択したライトがすべて消えます。次に、仮想スイッチをドラッグして、部屋のスイッチを表すアイコンにドロップします。続いて、実演者が実際のスイッチがある場所に歩いて行って、スイッチを入れると、先ほどのすべてのライトが再び点灯します。これなら、まだまだ単純なデモではありますが、最初のデモよりははるかに視覚的な印象を強く伝えることができます。技術的には、ほとんど変更が加えられていません。デモの進め方とデモに使う小道具に違いがあるだけです。

注意すべき重要な点は、上記のちょっとしたホームオートメーションのデモでは、そのシステムを通常使うであろう使い方をしていないことです。つまり、ライトを点けたり消したりするために、PocketPC を立ち上げ、家の見取り図を眺め、ライトを選択して画面上のボタンにドロップし、さらにそのボタンを押そうとする人間がどれほどいるでしょうか ? 実際には、ホームオートメーションを導入したばかりのごく僅かの期間であれば、そんなツールが家のライトの物理的なスイッチを「プログラム」するために使われるかもしれませんが、その後はほとんど使われなくなるでしょう。しかし、単に物理的なライトのスイッチのところに歩いて行って、スイッチを押したらライトが点き、そこで観衆に向かって「信じられないかもしれませんが、今このライトが点いたのは、このライトをこのスイッチにつないでいるホームオートメーションを使用して実行されていたのです。」と言ったとしても、デモはどれほど面白味のあるものになるのでしょう。

このようなデモやプロトタイプを開発するには、少しばかり違った種類のプログラマと、違った種類の考え方が必要になります。多くの場合、このような開発は、デモの脚本の作成から始まります。デモの脚本は、観衆の興味を惹くにはどのように見せるかという考えを簡単に表現するものになります。おそらく、Adobe Photoshop や Microsoft PowerPoint® などを使っていくつかのスクリーンショットでイメージを作りあげることになるでしょう。その結果、作業のきっかけができ、デモで伝える必要がある全体的な構想をチームのほかのメンバーが把握しやすくなります。次に、コンポーネントと機能を組み合わせることができるように、元になる技術基盤を少しばかり記述します。その後、デモで使うビジュアルインターフェイスをできるだけ視覚的な興味を惹くように構築します。

多くの開発者に理解してほしいことは、この開発プロセスのより困難な問題の 1 つが作業を進める上できちんと定義された技術的な仕様が用意されることはめったにないということです。デモの開発者は、何年も問題なく動くような、安定した、十分に構成されたインフラストラクチャの構築に取り組んでいるわけではありません。彼らは、デモができる限り本物らしく見えるように実際のコードをいくつかつなぎ合わせて、見かけだけ立派なプログラムを作成することに取り組んでいるのです。

また、こういったデモのスケジュールは非常に厳しい場合が多いものです。よくあることですが、開催をほんの数週間後に控えたイベントで披露するためのデモのシナリオを考え出さなくてはならなかったりします。そこで、実装を担当するチームは、この締め切りに間に合わせるために速やかに作業を割り振ります。しかし、そうこうしているうちに、マネージャーがやってきて、その会社の副社長にデモの説明をしたらかなり興味を持ったようで、副社長が来週そのデモを見たがっていると知らせてきたりします。さらに、その日の午後にまたマネージャーがやってきて、明日 CEO とスタッフが打ち合わせをすることになっていて、CEO はデモを見て、開発予定のほかのテクノロジに合わせてそのデモのテクノロジをどのように位置付けるか計画したがっていると言ってきたりするのです。2 週間の仕事のはずが、突然たった 24 時間で終わらせる仕事になってしまうのです。なんて多忙で刺激的な人生なんでしょう。

しかし、おそらく開発者が対処しなければならないもっとも厄介なことは、一瞬にしてデモ全体が変更される、あるいは完全に無駄になる可能性があることでしょう。デモはその性質上迅速かつ動的である必要があります。デモの基本となる脚本やシナリオは、その日その日で頻繁に変更されます。しかも大幅に変更されることが多いのです。開発者が、あたふたとなんとかまとめ上げた構想を具体的な形にしようと作業を進めている間にも、経営者はこれらのデモをもっと説得力のあるものにするにはどうしたらよいか、さらには開発を計画している基盤テクノロジをどう表現するのが適切かをブレーンストーミングしていたりするのですから。

さて、これらのハードルをすべて超えられたとしましょう。チームが実際に基盤テクノロジの一部をきちんと取り入れ、かなり面白いデモを作り上げたとします。このプロセスの間中、自分のことをまるで、クリンゴン人との戦いの最中、転送装置のパワーを徐々に落とし、Dilithium 結晶を使ってくぐりぬけ、宇宙船をワープから通常の飛行状態に戻したスタートレックの機関部主任スコットさながらだと思います。しかしそんな気分に浸れるのも、ほんの束の間です。これから、デモを経営陣に披露し、プロジェクトを遂行する上で必要になる人員と資金を投入すべきかどうかが判断されるという本当の試練を迎えるのですから。

デモが滞りなく進んだとしましょう。用意したデモのシナリオ自体が十分に観衆の心をつかむことができるものであるだけでなく、その場で必要になるかもしれない機能や、尋ねられることが予想される質問に対する準備ももちろんしてあり、質問にあがった状況ではどのように対処すべきかをデモで見せられるようにもしてあったとします。これなら、数週間、あるいは数ヶ月にわたる過酷な長時間労働と数え切れないデザイン変更に対する、完璧な結果と呼べるかもしれません。

しかし、このような場合、しばしばデモがあまりに「完璧すぎる」ことが問題になります。見かけ上実によく機能し、提案しているテクノロジがうまく表現されているので、デモを見ている側はこのテクノロジの開発は完成間近であるかのように思ってしまうのです。開発にたったの 3 週間しかかからなくて、それで 80 % は完成しているように見えるプログラムを完成させるために、なぜ 2 年もかけて 4 度もの人員と予算の配分が必要になるのか、デモを見ている人達には理解してもらえないのです。

人生には実に不公平なこともあるものです。

Robert Hess は、MSDN Show (英語) を担当しています。