UX Pioneers：アラン・クーパー氏インタビュー

TA： 異なるユーザーインタフェースを用意するということですね？

AC： そうです。ウィジェット一式を用意しておいて、自分たちで組み合わせて使ってもらうのです。その日自宅に戻ってからプログラムに着手し、頭と手を同時に動かして作りました。これは基本的に、フローティングメニューのことです。そのメニューにはプッシュボタンとリストボックス、チェックボックス、ラジオボタンがあって、それらはすべて Windows のコントロールとして馴染みがあるものでした。

Windows を起動した後、上部の小さなウィジェット [en.wikipedia.org]のパレットが置かれている部分で、メニューボタンの絵をクリックし、それを下のほうにドラッグし、ウィンドウの上でドロップします。すると新しいボタンがウィンドウの中に現れます。そして画面の上部から、今度はテキストボックスをドラッグしてきてウィンドウの上でドロップし、それからボタンの上で右クリックをして、ラバーバンドをテキストボックスまでドラッグしてきて放す。するとプッシュボタンがテキストボックスとつながる。

それからプッシュボタンを押せば、テキストの一部がテキストボックスに送られます。

TA： エンドユーザーのほうがなんとか折り合いをつけて、そういった作業をうまく実行しなければならなかったのですよね？

AC： そうなのです。ワープロを趣味で操作する人など、誰もいませんでした。コンピュータはまだまだ、職場で使うためだけに購入されるものだったのです。

このアイデアは、使う人が自分自身でシェルを視覚的にプログラムできるようになるということを意味していました。当時は OS/2 [en.wikipedia.org] というOSがあって、それが主流でした。OS/2 にはシェルがあったのですが、私が作ったプログラムには、10分程度の操作で OS/2 のシェルを Windows 内に再現できる機能があったのです。

これはすごい機能でした。ドラッグ&ドロップができる Windows アプリケーションは、これが最初でした。私は、何かをドラッグしたときにそれが動いているように見えるようにもしました。Windows の画面上で、まだ誰もアニメーションを見たことがなかった時代です。

出納係であれば、画面上には、自分が日常的に実行する3つのアプリケーションに対応した3つのボタンが与えられます。

中間管理職クラスの人々には、必要な機能をすぐに起動させるためのボタンと、自分がいじっているファイルだけが、小さなディレクトリに提示されます。

アナリストであれば…、そうですね、高度なシステムを開発しているシステムアナアリストであれば、月曜日にはあるユーザーのシェルだったものが、作業を進めるうちに変わっていき、火曜日には全く別のユーザーシェルにできるといった具合です。

TA： コーディングしたことについてずっとお話をされていましたが、今ここで急に、まったく違うやり方で開発した話になりましたね。実はコアとなる要素は、「誰がそのソフトウェアを使うのか」という点にこそあるということを発見されたのでしょうか。

AC： ソフトウェアを実行する人のことについて考え始めたのは、SuperProject でクリティカルパスを扱っていたころからですので、もう少し早かったと思います。何人かに、「プロジェクト管理について、何かご存知のことはありますか？」と尋ね回っていました。

正式なメソッドはなく、ただ日常的に出会う人々に尋ねるだけでしたが、最終的にある広告代理店で業務促進担当をしていたキャシー・リーという女性と話してからは、その後たくさんの仕事を彼女に基づいて進めることになりました。

結果的には、私のプログラムが使えないものだということを発見したのが彼女でしたので、屈辱的な気分も味わいました。つらい経験でした。しかし「キャシーならどうするだろう？　ここで何をほしがるだろうか？」と自問したのは正解でした。

これが、ペルソナのアイデアの始まりの始まりでした。キャシー・リーのためにデザインするというミスは犯しましたが、キャシー・リーという人物像の要約のようなものを作り出し、私の頭の中でペルソナとしたのです。

私はプログラマーでもあったので、ユーザーと実際に話をしたくない、ユーザーと話すのは厄介だ、と思っていました。

TA： いろいろなことを考えながら、実際にはコーディングをしていたのですね。

AC： そうです。Tripod という、先ほどお話しした「シェル組み立てセット」プログラムを作ったときも同じでした。それは、バンク・オブ・アメリカで話を聞いたITマネージャのために設計したもので、その時すでに3つのレベルのユーザー（上級アナリスト、中間管理職、高卒の出納係）がいることがわかっていました。

当然、それぞれのレベルがひとつのペルソナになるのです。

TA： それでどうされたのですか？

AC： そのプログラムを売ろうと試みましたが、それは単に、世間にたくさんある製品の1つに過ぎませんでした。素晴らしいソフトウェアですが、それを使って何ができるのかをはっきり示すことが誰にもできなかったのです。その後ロータス社のような大企業も含め、ソフトウェア業界の人々何人かにそのプログラムを見せたところ、「ほおー、これはちゃんとできているソフトウェアだね。一種のシェルとして、マイクロソフトに売り込んだらどうだい？」と言われたのです。

その時点で私はまだ、電話をして「見てほしいものがある」と直接いえるほど、ビル・ゲイツ氏 [en.wikipedia.org]のことを知りませんでした。でもマイクロソフトで仕事をしていた友人は何人かいましたので、彼らに、ビル・ゲイツ氏に会わせてくれるよう頼んだわけです。そうして、ビルの側近の1人から招待を受けることができました。

その人は「こちらにお越しください。あなたが作ったものを私が見てみましょう」と言いました。それで彼に会いにシアトルに行きました。その人の名前は忘れてしまったのですが、そのときカンファレンスルームには彼と私の2人しかいなくて、そこで私が自分のコンピュータを取り出してソフトウェアのデモを始めたわけです。

彼はデモを3分くらい眺めた後に椅子の背もたれに寄りかかり、「ビルがこれを見ないといけないな」とつぶやきました。

TA： いい感じですね。

AC： それからビルと会う時間を設定して、プログラムのデモをしに再びシアトルに行きました。画面上でドラッグのアニメーションを見せたとき、ゲイツ氏は私を見て「これは、いったいどうやっているんだ？」と聞き、Windows 上で動くそのようなアニメーションはかつて一度も見たことがないと話してくれました。「魔法を使っています」と私は言いました。他になんて言えばよかったのでしょう？

私がデモを続けていると、ビルはそこにいた人たちを振り返って、「僕たちこそが、こういうことをやっていないといけないんじゃないか？」と言ったのです。とても嬉しいことでした。

その部屋の中にいた1人、タンディ・トロワー氏 [gatech.edu]は「これを欲しがる人なんているのでしょうか？　これが何の役に立つのですか？」と言い、私が彼に売り口上を言おうとして息を吸ったときにビルがまた振り返り、世間の人々がこのプログラムを欲しがる理由を説明し始めたのです。それからビルは私の方を向いて、「これを購入したい。これは、人々がコンピュータを使って仕事をするやり方を変えるだろう」と言ってくれました。

TA： デモをしている人には、何よりも嬉しい言葉ですね。

AC： この上なく嬉しく思いました。そしてビルは、私と私のプログラムを Windows チームのメンバーに引き渡したのです。当時は、ひどい代物でありながらもプレゼンテーションマネージャ [en.wikipedia.org]が主流で、Windows は戦略的に価値のあるソフトウェアだと見なされていませんでした。

TA： これはいつ頃のことでしょうか？

AC： ビルに Tripod のデモをしたのは 1988 年の3月で、マイクロソフト社がまだ IBM と共生関係にあった頃です。先ほど触れたように、私のプログラムでできたことの1つは、OS/2 のプレゼンテーションマネージャを再現することでしたので、政治的な対立が発生しました。私は、マイクロソフトの人々に面と向かって説明したのです。「見てください。私は OS/2 のプレゼンテーションマネージャを今から作りますよ（カチャ、カチャ、カチャ、バーン！）」とね。

もしもあなたが OS/2 の製品管理担当者だったら、激怒するはずです。

TA： マイクロソフトは、そのプログラムを購入したわけですか？

AC： ええ、購入してくれました。ゲイツ氏の言う、これまで見た中で最高の仕様に合わせてコードを拡張し、同じプロジェクト内にいたマイクロソフトの品質監査チームに渡しました。

契約を交わしてすぐに、私たちは Tripod という名称を Ruby に変更しました。なぜなら、私はその製品をすでにロータス社や他の会社に見せてしまっていたからです。これは特に深い意味のないプロジェクト名称でした。いま現在 Ruby [ruby-lang.org] という名の言語が存在していますが、当時の Ruby は、私たちが用いていたコードネームだったのです。

1年ほど、私はその仕事に取り組みました。チームをまとめてプログラムを開発し、厳重な品質監査のサイクルを通し、マイクロソフトに提供したのです。その間に、マイクロソフトは IBM と離別しました。そして OS/2 がそれまでにやってきたことを Ruby で再現できてしまうからと、OS/2 の人々が Ruby を葬り去ったことを確認してから、マイクロソフトは OS/2 をも手放しました。

TA： Ruby に1年間を費やしたのに、それが使われないことを知ったわけですね。

AC： そうなのです。マイクロソフトは Ruby を受け入れ、私たちへの最後の支払を済ませ、感謝の意を口にしましたが、それ以後 Ruby がマイクロソフト社から公開されることはなかったのです。

TA： 重いレンガで叩かれたような感じですね。

AC： 辛かったですね。私は周囲の人々に、マイクロソフトにコアとなる技術を販売したのは自分だと話していたのに、Ruby は公開されず、社内の最高機密だったために知っている人もいないという、私の人生の中でもつらい時期でした。

私が Windows チームのメンバーに告げた言葉の1つは、自分は Tripod を捨てて、ゼロから着手するということでした。ソフトウェアを作る正しいやり方だといえるでしょう。

彼らは激怒しました。そして「何をやっているんだ？　コードを放り出す？　開発期間の締め切りに遅れてしまうぞ。君はわれわれ全員の進行を妨げることになるんだぞ」と言いました。

もちろん後になってから、間に合わなかった彼らのほうで、私のほうは予定通りに出来上がりました。なぜなら私はそのコードを捨てたからです。重要なのは、その時々の状況に応じられる知識であって、それまでのやり方ではないのです。当時のマイクロソフト、少なくとも Windows チームでは、こうした近代的プログラム技術をまだ分かっていませんでした。

Visual Basic の誕生とコンサルティングビジネスへのチャレンジ、そして 「ペルソナ」 へ

TA： それからどうなりましたか？

AC： 1年半くらい経ったころでしょうか。Windows チームが言語を扱う部門に Ruby を委譲し、私が開発した部分に QuickBASIC [en.wikipedia.org] を追加しようとしているといううわさを耳にしました。

私は BASIC [en.wikipedia.org] があまり好きではありませんでした。BASIC は100行程度のプログラムを書く際には優れた言語ですが、大規模なソフトウェアを作る際には使えないものでした。私の業績が BASIC と少しでも関係があるというのが恥ずかしかった。

当時、Turbo Pascal [en.wikipedia.org] は言語の中で圧倒的な勢力を持っていました。

QuickBASIC はビルの製品ですが、Pascal [en.wikipedia.org] や C言語 [en.wikipedia.org]を勝ち負かすことができなかったため、忘れ去られた製品となっていきました。C言語はプロ向きで、Pascal は素人向きでした。

私はC言語で Ruby を開発していましたが、とても性能が良くて、自分に最適な言語でした。しかしC言語は取っ手が付いていないナイフのようなものでもありました。自分がやっていることを理解せずに使っていると、自分を傷つけてしまうことがあった。器用な人でなければ使えなかったのです。

ビルは部下たちに、私が作ったちょっとした言語を切り出して、QuickBASIC に加えるように指示をしました。つまり私の初期段階にあるビジュアルプログラミング部分を取り出し、Ｃ言語の部分を引き抜いて QuickBASIC を入れさせ、Visual Basic [en.wikipedia.org] を生み出したのです。だから私は、「Visual の部分を開発したのが私で、Basic の部分を開発したのはマイクロソフトだ」という言い方を好んでいます。

その頃、マイクロソフトは成長を続けていて、多くのメンバーが3～4ヶ月かかるプロジェクトをこなしては次のプロジェクトに取り組んでいました。私のことや私がやった開発について知る人は誰もおらず、プロジェクトとプログラムがあちこちに移動しているということだけが知られていました。何かのうわさを耳にしたのでしょう。ある人が、マイクロソフトの製品発表会に私を招待してくれました。

発表会が行われるワシントンに出向いてその製品を見たとき、私は本当に激怒しました。でも、本音を言わずに「いい出来だね」と言うようにしました。

マイクロソフトは、シェルに関する私のアイデアを採用し、そのすべてをプログラマー向けに提供したのです。Ruby は、Windows 上で実際に DLL（ダイナミックリンク・ライブラリ） [en.wikipedia.org]を使って提供されたアプリケーションとしては、まさしく最初のものでした。そのプログラムでは機能を視覚的に表現するだけでなく独立させてもいたので、サードパーティベンダーが開発システムの一部として動的に組み込める機能として、シームレスに使える部品になりました。これは当時、VBX [en.wikipedia.org] と呼ばれていたインタフェースで、私がオリジナルを発明したものです。これまでに OCX [en.wikipedia.org] や ActiveX [en.wikipedia.org] に変形されてきましたが、VBX は何千というプログラマーに好まれてきたプラットフォームとなりました。

TA： これは90年代初期のことですか？

AC： そうですね。Visual Basic 1.0 が誕生したのは、確か 1991 年のことです。

TA： あなたが立ち直った時期まで、話をスキップしましょうか。

AC： 分かりました（笑）。

ミッチェル・ウェイト [mitchwaite.com]という友人がいます。彼は Visual Basic に一目ぼれしてしまった人物で、当時、『Visual Basic How To』 [amazon.com]という初の Visual Basic 関連書籍を執筆した人物でもあります。

彼はVB上にあった「VBについて」という記述の中に私の名前を見つけ、電話をかけてきました。「Visual Basic を使っていて、クーパーという名前を見つけたんだが、それは君のことかい？」と尋ねてきました。「そう、私のことだよ」と答えると、彼は「これは驚いた。僕にその話をしてくれないといけないね」と言いました。

2人でランチを食べながら、長い長いストーリーを話しました。話の最後に彼は、あきれ顔になってこう言いました。「君こそ Visual Basic の父といえる人間なんじゃないか」。

私は「ありがとう」と言いました。彼は私の経歴をたった一言にまとめてくれたのです。それ以来、私が自分のことを「Visual Basic の父」と称するときはいつでも、ミッチェル・ウェイト氏の言葉だと説明しています。

その頃にはすでに、ソフトウェア業界の統合合併が進んでいました。私がVBの仕事を始めたころは最低でも 100 社程度のソフトウェアの発行元がありましたが、仕事を終える頃にはマイクロソフトくらいしか残っていませんでした。外部から購入したソフトウェアを発行するような企業はほとんどなくなってしまいました。企業は買収するか、再建するかだったのです。

TA： それで、90年代初期には、（やりたいことを進めるために）違うやり方を考え出す必要があったのですね。

AC： そうです。私自身はソフトウェアのコードを書く仕事をしたかったのですが、当時、ソフトウェアを作るためには大きな企業の大きなチーム力が必要でした。でも私にはそれがなかった。私はまた、大規模なソフトウェアを扱いたかったけれども、1人で作業したいとも考えていました。

解決方法は何もありませんでした。そうしたあるとき、妻が私に「あなたはいったい何がやりたいの？」と尋ねました。私は「ただソフトウェアの設計をやりたいんだ。でも開発はやりたくないんだ」と答えました。「そう、じゃぁ、そうすればいいじゃない」。これが彼女の答えでした。その言葉で私は考えさせられました。どうやればそれができるかが分からなかったのです。

それまでの私は、コンサルタントになって他人が開発するソフトウェアを扱うなんて全くつまらないことだと思っていました。世の中には「自分が作るソフトウェア」と「できの悪いソフトウェア」の2種類しかないと本気で考えていたのです。これは、プログラマーが世間に対してとる傲慢な態度の典型ですね。しかし、私は妻に言ったのです。「わかった。じゃあやってみるよ」とね。

1992 年のある日、私はボストンで開催された Windows 関連のカンファレンスでパネルディスカッションを設け、そのセッションの最後でパネリストたちに向かってこう告げたのです。「さて皆さん、私はコンサルタントなのです。いずれ私を雇うことになりますよ」。

パネリストのうちの2人が、実際に私を雇ってくれました。驚きました。1人とは短期的な契約を交わしただけですが、結果的には5～6年後に、再度私を雇ってくれました。私がチームを組んだもう1人はジョン・ジッカー氏 [sanasecurity.com]で、こちらは長期のコンサルティングを行う関係になりました。彼が自分で立ち上げて成長させて売却した3つの会社を通じて、彼を支援することになりました。

TA： これが、クーパー社 [cooper.com]の起源でしょうか？

AC： そうです。コンサルタントとして、1人でデザインコンサルティングだけを手掛けました。2年間はクライアントを相手に PowerPoint [en.wikipedia.org] のプレゼンテーションを行い、スケッチを作成していたのです。

TA： インタフェースのための構造を設計したのですね。

AC： そうです。2年間が過ぎた頃には、私はコンサルタントとして常に忙しい状態になっていました。ある日私は妻 [cooper.com]の元に行き、「今日1日、私の行動に一緒についてきてほしい。何かが形になってきている気がするんだ」と話しました。

人々に話を聞いてもらい、そして熱狂的な反響を得ている私を見た彼女は、「あなたの言う通りね。ここに何かあると思うわ！」と言ってくれました。私たちは、単に私がコンサルティングをするというだけでなく、いよいよ新しいビジネスを生み出すことに決めたのです。これが 1994 年のことでした。ウェイン・グリーンウッド氏 [elevenconsulting.com]を最初の従業員として迎え、クーパー・インタラクションデザイン社が誕生したのです。

TA： ご自身を製品化する手法を考え出さなくてはならなかったのですね。

AC： ええ。私たちは新しいオフィスを借りて、部屋の1つを「エーリングルーム（けんか部屋）」と呼ぶことにしました。なぜなら、私とウェインはその部屋に入っては互いに怒鳴り合っていたからです。プログラマーたちがよくやるように、「いや、これではだめだ！」と言い争っていました。私たちは本当に苦労して、ゼロからこういったやり方を作り上げたのです。

私は、ジョン・ジッカー氏のプロジェクトに取り組んでいました。彼も、そして彼のために仕事をする人々もみな、卓越して優秀な人々です。そして彼らには、素晴らしい製品がありました。

まだ「ビジネスインテリジェンス」という名前は考案されていませんでしたが、その製品はまさにビジネスインテリジェンス・ツールの走りといえるものでした。この製品ではデータベースの中から重要な情報を抽出し、実に洗練された情報として画面上に配置し、さらに様々なやり方でユーザーがその情報を「もみほぐす」ことができたのです。

途方もないほど説得力を持つプログラムでした。自分が欲しいどんなかたちにも変形できるような、典型的なソフトウェアツールです。私が椅子に腰をかけて、ジョンに「一体だれがこれを使うんだい？」と言うと、彼はそこらへんを軽快に歩き回るのでした。誰にでもどんな目的にも使えそうだったのです。

私は、誰が何のためにそのツールを使うのが妥当かをつかみきれずにいたので、自分がこれに打ち込むための実例を切望していました。そしてついに、「何人かのクライアントと話してみる必要があるな」と口にしました。堂々巡りに見切りをつける必要があったわけです。

ジョンは、自分のクライアントを私に何人か引き合わせてくれましたが、私とクライアントだけではどうしても話をさせてくれないので、マーケティングディレクターを連れて行きました。こうして私は外へ出て初期のクライアントに会いに行ったのです。私は科学者ではないし、調査をしているわけでもありませんが、私のほうから行って「あなたはどんなことをなさっている方ですか？　どんな問題を抱えていますか？」と尋ね、そこから話を聞き始めることにしたのです。

6～8回くらいインタビューを続けているうちに明らかなパターンが見えてきました。偶然にもそのパターンは、バンク・オブ・アメリカでITマネージャが話していたこととよく似ていました。覚えているでしょうか、彼には、分析用アルゴリズムを考えるアナリスト、それを使うアナリスト、そしてデータ収集をする技術者の3種類の従業員がいたのです。

これらのケースでは3種類のインタフェースが必要とされました。1つはツールを生み出す人々が使うもの、2つめはツールを組織化する人々が使うためのもの、3つめは単にそのツールを使う人々のためのものです。こうやって、私は最初に3人のペルソナを考案したのです。ロブ、シンディ、チャックが最初のペルソナとなりました。

TA： これはいつのことでしょう？

AC： 1996 年のことですね。

TA： その頃、すでに『About Face』 [amazon.com]に取り掛かっていたのですか？

AC： 『About Face』が発行されたのは 1995 年のことです。ペルソナが人物の特徴を表すツールとなる前に書かれています。

TA： 書籍の執筆は、とてつもなく大きなプロジェクトです。そしてあの本は、インタフェース関連本として最初に書かれた大掛かりなものです。その話を飛ばしてしまいましたね。

AC： あれは、1992 年～1994 年にやった仕事に基づいたものです。今振り返っても、びっくりすることばかりでした。ものすごくたくさん働き、たくさんのことを学び、そしてあの本を書いたのです。著者となって私が学んだのは、自分の能力を信じなければいけないということと、それまでの蓄積をすべて出し切って空っぽにならなければいけないということです。しまい込んでしまわずに、自分が知っていることのすべてをもって、紙の上に書き出さなければならないのです。

知っていることを心の中にしまい込んで「これこれについては、次の本を書くときまで話さないでおこう」などと思っても、読者は敏感に出し惜しみを察知して違和感を覚えます。「これが私の知っていることのすべてです」と断言し、「さらに伝えるべきことが出てきて、（知識の）貯蔵庫が再びいっぱいになるはずだ」と自信を持つべきなのです。

TA： それで、あなたの本はものすごく分厚くなってしまうのですね。その本の使い勝手が悪くなってしまうのではないかと、私は大いに心配していますが。

AC： その点は自覚しています。批判を甘んじてお受けします。もっと時間をかけることができていたら、もう少し薄い本にできたと思います。ハウツー本としてのあの本は、様々な意味でインタラクションデザインに関する議論の的になりました。「デザイン？　何のことだい？　私がちゃんとやってるよ。ちゃんとした機能がついているのに、一体何を言ってるんだ？」と言うプログラマーたちがいました。他方で、「プログラマーが作ったものを渡してくれれば、私たちがテストしてうまくいっている部分とダメな部分を報告するよ」というユーザビリティ派がいました。

私が言いたかったのは、出来上がってからテストするのでは遅すぎるということです。もっと早い時期に、先を見越したデザインをしなければなりません。私はこの考え方を本に記したかったのです。

TA： あなたはそれを公の場に向けて出版したかっただけですか？　それともビジネスの場を作りたかったのですか？　その両方ですか？

AC： 「出版したかった」というのが本音です。私には人に伝えるべき大切なことがあると分かっていました。それがビジネスにも役立つことは分かっていましたが、執筆した動機は、伝えたかったからです。

TA： 伝えたい気持ちであふれそうになっていたのですね。

AC： そう、今にも破裂してしまいそうでしたね。

TA： 1995 年にこの偉大なる書籍を執筆し、その後ペルソナのアイデアに思い至って考え始め、先ほどおっしゃった3種類のペルソナに着手されました。それは当時、あなたご自身のおっしゃるところの「ゴムのユーザー」問題にひどく悩まされていたためだったのですね。

AC： そう、典型的な「ゴムのユーザー」問題でした。

レポート・スミスという会社があって、そこでの仕事は素晴らしいものでした。そこは、ソフトウェアを作る優秀な人々がいて、優秀な管理者に経営されている、古典的なソフトウェア企業です。高度な性能を兼ね備えた素晴らしいプログラムであれば、自分たちは既にそれを持っていると考えていました。彼らには、何かがうまくいっていないということに気づく感覚はあったのですが、何が問題なのかがよく分からなかったのです。

それで私は、PowerPoint を使ってペルソナを紹介するようになりました。「これがシンディです」と語り始め、シンディが必要とするもの、シンディに必要なものを解説したのです。その途端に、自分が語っていることが相手に通じているのがよく分かりました。「ああ、僕にはシンディが "それ" をどうしたいのか、"それ" 以外のものがどんなふうに彼女の邪魔になっているかがよく分かる」と、そこに座っていたプログラマーが口にしたのです。そして私は、ここには非常に説得力を持つものがあると実感し始めました。

私には、それが SuperProject のコードを書いていたときにやったことの延長だと分かっていました。先ほど触れた、業務促進担当者のキャシー・リーを参考にしていたときの話です。私は長い散歩に出ては、「キャシーだったらこの状況をどうするだろうか？　彼女は "あの" 情報ではなく "この" 情報を必要としていることは分かっている…」などとつぶやいていたものでした。それを若干拡張したり要約しながらも、同じことをレポート・スミス社の人々と実践していることに自分で気づいていました。そこで初めて、ペルソナに名前と顔を用意したわけです。

TA： 『About Face』は、インタフェースデザインのハウツーそのものです。その後執筆なさった『The Inmates Are Running the Asylum（以下、Inmates）』では、本格的なコーディングや、プログラマーが使いやすいソフトウェアを書くことを元来苦手とする理由について述べていらっしゃいますね。

AC： 『Inmates』の背景にあったのは、インタラクションデザインのためのビジネスケース（投資対効果検討書）を作るというアイデアでした。しかし、自分自身の信用を得るためには、人に何かを好きになってもらう（ための技巧）以上のものがインタラクションデザインにあるということを少し話すべきだと思ったのです。

インタラクションデザインにれっきとした過程があることを示さなければ、ただ「とにかくみんなで仲良くやっていきましょうよ」と人に呼びかけているようで、なんだか底が浅いように思えたのです。

TA： ある意味では、これ以上にうまく話題になる方法はなかったでしょうね。

AC： （笑）

TA： ここに、その分厚い本があります。ほとんどの方、少なくても実践主義の読者には、第9、10、11章が話題になるでしょうね。当時ユーザーインタフェース分野で活動されていた人には、第1部はとても面白いけれども「釈迦に説法」といえる内容だったでしょうね。

AC： そうですね。

TA： そうして、ペルソナという発想が人々を圧倒したのですね。

「ツールとしてのペルソナ」の確立

AC： ええ、その通りでした。私も驚きました。ペルソナが有用で強力なものだということが私には分かっていましたし、自分がやる仕事ではいつも使っていましたし、自分たちの仕事の基礎になっているということも認識していました。しかし、当時はまだ自覚に欠けていました。世間の人々の考え方を変えるほどのものであるということを、十分に理解していなかったのです。

ペルソナは自分が開発したツールの1つであって、他の人はまた別のツールを開発するものだと思っていたのですから。

TA： それが、Goal-Directed Design ™ [cooper.com]（ゴールダイレクテッドデザイン：目標駆動型デザイン）という方法論の部分だったのでしょうか？

AC： ええ。その頃までには、「ゴールディレクション」というアイデアをはっきり描いていました。たくさんのツールを考案していたのですが、タスクではなくゴールに焦点を当てるというアイデアもその中の1つでした。しかし、タスクとは機能であり、機能とはコードの集合ですから、プログラマーであればタスクに注目するものなのです。

たくさんの機能がありながら一貫性のない大きなソフトが出回っている理由は、プログラムには機能が絶対に必要ですが、一貫性はなくても済んでしまうからです。ソフトウェアは、その内部の構築方法を忠実に反映するものなのです。

ユーザーの視点からプログラムをとらえてみると、機能ごとに組織化する必要があるとは限りません。機能毎に組織化すべきかどうかの観点を持つには、ペルソナを通して考えてみると良いのです。全てのつじつまが合って見えてきます。

とても嬉しく思ったこともあります。『Inmates』の第9章ではペルソナについて、10章ではシナリオについて、11章ではゴールについて、とても具体的に書いていますが、それは私がただ大口をたたいているだけではないということを伝えたかったのです。それは、執筆時に自分自身に言い聞かせたことでした。

この本は、実践者のためのハウツー本とは全く考えていませんでした。ビジネス界で仕事をする人々に対し、ユーザー中心デザインを適用すべき理由を示すだけでなく、もしそれを実践したら、極めて洗練されていて実用的なやり方を適用することになると示そうとしていました。

ペルソナをきちんと理解して、利用し始めてくれた読者がいることを知って、本当に大きな驚きと喜びを覚えました。

TA： 読者がペルソナを作り始めたのですね。

AC： そうです。たくさんの人がペルソナを作り出していました。ただ、ペルソナを活用したり理解したりできない人もいました。多くの人々が、私がペルソナについて解説したことを誤解してしまいました。私が明白にしたいのは、ペルソナは、正確であることよりも具体的であることの方が大切だという点です。

私は「ペルソナがないよりも間違ったペルソナがあるほうが良い」と言っていますが、多くの人はそれを見て、気まぐれにペルソナを作ることを私が擁護していると考えてしまい、批判的になりました。でも私はそんなことは言っていません。

私が伝えたいのは…、かつてマイクロソフトのメンバーにも言ったことなのですが、Microsoft Word を使う人が4千万人いて、そのみんなが Word を苦手と感じているということです。典型的な1人を代表として抽出して、その人のためにソフトウェアを設計したらどうなるでしょうか？　その人をソフトウェアに夢中にさせてみるのです。その1人が真に代表的な人物だとすれば、そのソフトウェアに夢中になることができる似たような人々が1千万人はいるはずだということなのです。

結果的には、1千万人の新しい熱狂的なユーザーと、感想が以前と変わらない3千万人のユーザーが存在することになり、これでも大幅な改善だと言えるでしょう。

TA： 現在私は、ペルソナのためにデザインするという説明を人にするときに、「1人のために考えたならば、最低限でもその1人については、隅々までつじつまが合うようになるはずだ」と話すようにしています。もしも1人のためにデザインしなければ、その製品は最初の画面でユーザーを才能あふれるコンピュータエンジニアとみなし、2番目の画面では88歳のお年寄りとみなすかもしれません。もし高齢者の女性のためにソフトウェアを開発しているときに、NFL のプロフットボール選手のペルソナを使っていたとしても、筋の通ったものを生み出す可能性は高いでしょう。

AC： 「フォルクスワーゲン [en.wikipedia.org]はみんなの車であってみんなの車でない」という言葉の中にそのアイデアがありますね。実際には、フォルクスワーゲンは "人々の自動車" という意味であり、あらゆる人々のために設計されたものです。ただ、成功につながったのは、あらゆる人々のために作られていないからなのです。全く違うのです。

みんなを「象徴する」人物のためにデザインされたものであり、その人物とは、大きい高級車を買えない人のことだったのです。同様に成功しているのが、ポルシェ 911 [en.wikipedia.org] で、こちらは非常に小さな目標市場のためにデザインされたものです。

ポルシェ 911 は "非常に" 小さな目標市場中の小さな目標市場のためのものです。他方、フォルクスワーゲンは "非常に" 大きな目標市場を代表する非常に小さな目標市場のためにデザインされたのです。

フォルクスワーゲンとポルシェ 911 に関して興味深いのは、両方とも、長い時間をかけて証明されてきた企業であり、ブランドであるということです。初めて紹介されてから今日まで50～60年も生産され、世界的に認知されて続けている自動車であり、彼らが標準となって、様々な変形を生み出してきたのです。

TA： 両者とも問題を解決していて、その解決方法が適切だったからですね？

AC： そう。両者ともたった1人のユーザーに注目したから解決できたのです。これこそペルソナの力です。1人のユーザーを満足させることで、世界規模のブランドを確立したということです。

TA： 私自身、ペルソナが持つ重要な秘訣は、組織の中にレーザー光線のように明確な焦点を当てて働きかけることにあると考えたいのです。製品は、その焦点に付随するものだと。

AC： それはまさに、私が正確性よりも具体性に価値をおいて説明していることそのものです。もしジェーン・ジョンソンのための製品開発に着手するなら、ジェーン・ジョンソンというペルソナを作り、そのペルソナのためにソフトウェアを設計し、ジェーンを満足させます。そうしたならば…最終的に、ジェーンが間違ったペルソナだったとしても、それも１種の成功といえるのです。

そのペルソナが、意図したものとは異なる市場に関係してきますが、それも1つの成功です。数学的思考のプログラマーに、たった1人の人間に焦点を当てて考えさせるのは本当に難しいのですが、非常に良いことなのです。

プログラマーに、インタラクションデザイナーにもなってもらえば問題を解決できるはずだと考える人々がたくさんいます。

しかし私は、それは全くの誤解だと思っています。優秀なプログラマーをつかまえ、その人にプログラミング以外のことをしてもらう理由はどこにあるのでしょう。インタラクションデザインは、インタラクションデザイナーにやってもらうべきです。

TA： そしてまた、プログラマーとインタラクションデザイナーが話し合うときに発生する問題を解決する必要もあるのですよね。

AC： その通り、これは極めて重要なことです。図らずもペルソナは、彼らのコミュニケーションをとるためにも最高の道具なのです。例えばあなたがプログラマーに、「私はこのウィンドウをもっと小さくするべきだと思いますよ」と言っても、プログラマーが思い浮かべるのは「フン、こいつはもっと小さくしたいと思っているが、私は大きいほうがいいと思うし、頭がいいのはこっちだ」といったことでしょう。こうやって、突然2者が対立する状態となり、プログラマーがあなたに勝負を譲ることはまずあり得ません。

TA： 結局、製品をコーディングするプログラマーが勝つということですね。

AC： そうです。十中八九、実際に扱っている人間が勝つのです。

だからあなたは、プログラマーのところに行って「私はこのウィンドウをもっと小さくするべきだと思う」という代わりに「ジェーン・ジョンソンだったら、このウィンドウはもっと小さいほうを好むと思いますよ。理由はこれこれです」と話すべきなのです。

そうすれば、もはやあなたとプログラマーのプライドのぶつかりあいではなくなりますし、プログラマー側も「そうか、ジェーン・ジョンソンがそう望むんだね。オッケー、分かったよ」と言えるようになるのです。

ペルソナは、分極化を避け、競合するエネルギーを外在化させることによってコミュニケーションを促す最高の道具です。これがペルソナのもつ大きな強みの1つなのです。

TA： おっしゃる通りですね。コンサルタントは、家庭内の競争場面に似たような状況に陥った企業へ、心理学者として入っていると思います。

AC： ええ。

いま、そしてこれから

TA： ビジネスが進展して確固たるものになってきて、今まさに『About Face 3』 [amazon.com]が公開されたところですね。

AC： この金曜日に第一刷を手にしたところですよ。

TA： さて、あなたは会社の運営に成功し、確固としたプロセスが動いていて、素晴らしいクライアントも得て、そして素晴らしく活発な頭脳の "管理人" ですね。今はどんなことをしていますか？

AC： たぶん、まだまだやるべきことがあるだろうと思います。

ソフトウェアを構築する手法について、たくさんの洞察を持ち始めているところです。これは、世界中の大企業、中小企業、ソフトウェア企業、製品製造企業、サービス企業など何百ものクライアントと何千もの契約を持つコンサルタントとなったことによるおまけです。

実にはっきりしたパターンが見え始めているのではないでしょうか。私は、自分たちが経験してきた問題はソフトウェアのデザインに起因するものではなく、ユーザビリティの問題でもなかったと認識し始めています。私自身が繰り返し何度も見てきた問題は、ソフトウェアの構造の中にあったのです。

15年前、プログラマーは青写真なしでソフトウェアを開発していたものです。しかしこの15年の間に私たちは、優れたデザインでありながらコミュニケーションもとりやすく、性能が高く、効率性の面でも優れているような、極めて高品質な青写真を描く方法を学んできました。

プログラマーの前にその青写真を置いたときに私が気づいたのは、プログラマーにはそれが通じないということでした。それは、彼らが出来の悪い連中だからではありません。それどころか、大変頭がいいのです。主な原因は組織的なことです。企業はソフトウェアの作り方を知ってはいますが、ソフトウェアを計画的に作るという習慣は持ち合わせていません。

企業とはむしろ、計画を持たずにソフトウェアを作るのに最適な組織であって、明日何が起こるかわからないからこそ今やることに基づく処理が全てなのです。計画があれば、明日どうなるかが分かるようになりますので、そこで違う意思決定を行うことができます。

私にはこれが組織上の、そして経営上の問題であるということが分かってきましたので、クライアントに話をしてみました。しかし大変悔しいことに、私の言葉に聞く耳を持ってくれるクライアントはいませんでした。

TA： もちろん、そうでしょうね。

AC： これが技術的な問題でなかったからです。

TA： これは脅威でしょうね。やっていることが組織的に間違っていると指摘されるわけですから。

AC： そうなのです。でも、私にはこれが大きなチャンスに思えます。私自身が事業家ではなく発明家として考えるからですけれどもね。まだ存在しないものが見えてくると、私にはそれが派手なライト（ネオンライト）をピカピカさせてチャンスだと叫んでいるように思えるのです。ところが、おおかたの事業家たちはまだ存在していないものごとに気づいても、そこで考えるのはただひたすらリスクのことだけです。

このように警鐘を鳴らし続けて何年か経ったところで、私には、次の2つうち1つだけが真実だということがようやく分かってきました。私の考えが全くの間違いであるか、もしくは、この新しいソフトウェア開発パラダイムに基づいて私がソフトウェア企業を立ち上げる機会であるかのどちらかです。

私は、思い切ってソフトウェア企業を立ち上げることに決めました。ソフトウェア製品の開発に復帰するときが来たと思っているのです。

TA： それが、次にやってくることなのですね？

AC： いいえ、これは4年前に終えたことです。新しい会社を作り、私自身でもソフトウェアをいくつか設計しました。私がすべてを設計したわけではありません。というのも、チームを組んで適切に設計するということがその作業の一部だからです。そして私は、このプロジェクトのためにベンチャーファンドを得ようとしていろいろ動き回りました。しかし結局工面することはできませんでした。新しいプロセスに資金を供給する人がいないのです。

投資家が事業家のようになってしまっているため、私は資金を工面することができませんでした。彼らはビジネスとしての観点から見るのです。リスクを伴う可能性は受け入れられても、着想の飛躍は受け入れられないのです。

その時点で「よし、鉄道模型を組み立てる時がきたのだ」と自覚しました。それが今やっていることです。鉄道模型を組み立てています。

TA： 列車の話に戻りましたね。

AC： そうなのです。私はいまニッケルプレート鉄道会社 [nkphts.org]の一部の再建に取り組んでいます。この鉄道は、1949 年にはオハイオ州のリマからインディアナ州のフランクフォートまで走っていたものです。

この夏はミッドウエストまで足を伸ばし、昔の鉄道路線の跡をたどって写真を撮り、歴史研究の団体に入って調査しようと思っています。インディアナポリスで情報収集をして、自宅に戻ってから列車模型に取り組み続けるつもりです。

TA： 物語が一周しました。インタビューを完結させる頃合のようですね。

本日は本当にありがとうございます。素晴らしい冒険と旅をご一緒できて幸せです。

プロフィール

アラン・クーパー氏略歴
アラン・クーパー氏は、テクノロジーとユーザーとの間に渡る架け橋として、大きな影響を与えてきた人物。『The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity』 [amazon.com]（邦訳：『コンピュータは、むずかしすぎて使えない!』）、『About Face』 [amazon.com]（邦訳：『ユーザーインターフェイスデザイン―Windows95時代のソフトウェアデザインを考える』）、その後継である『About Face 2.0』 [amazon.com]（邦訳未刊）、『About Face 3』 [amazon.com]（邦訳：『About Face 3 インタラクションデザインの極意』）の著者であり、米サンフランシスコにてインタラクションデザインとユーザーエクスペリエンス関連のコンサルティングを行う Cooper 社の創設者でもある。

タマラ・アドリン氏略歴
本記事のインタビュアー兼原著者。米 Adlin 社創設者、プレジデント。米 Fell Swoop 社共同設立者。エクスペリエンスストラテジスト。Amazon.com および Amazon Service でカスタマーエクスペリエンス・スペシャリストとして活躍。カスタマーエクスペリエンス・デザインチームの立ち上げにも関与した。その後自身のコンサルティングファームである Adlin Inc.を設立。数多くの企業で、顧客の真の思考や行動に焦点を当てたカスタマーエクスペリエンス・コンサルティング手法を用いてチームを牽引した経験を持つ。2008 年に Fell Swoop を設立。
『The Persona Lifecycle : Keeping People in Mind Throughout Product Design』 [amazon.com] （邦訳：『ペルソナ戦略―マーケティング、製品開発、デザインを顧客志向にする』）共著者。

| 個人情報の取り扱いについて | 参加規約 | 特定商取引法に基づく表示 | 広告掲載について | 会社概要 |

Copyright © DESIGN IT!, LLC. 2009 All Rights Reserved.