国民宿舎はらぺこ 大浴場

発熱地帯さんとこ経由、次世代ゲーム機がらみのお話。

■後藤弘茂のWeekly海外ニュース■　Xbox 360のキーパースンJ Allard氏に聞く(後編) (PC Watch)

ちなみに前編はこちら。Xbox 360 と PS3 の比較についてじっくり検討してみたい人はどうぞ。おいら的には結構どうでもいいんだけど。

●SCEのコンピュータエンターテインメントのビジョンについて

【Q】 SCEはゲームを超えた、包括的なコンピュータエンターテインメントを構築しようと言っている。素晴らしいコンピュータエンターテインメントのプラットフォームを作れば、その上で素晴らしいゲームもできるというビジョンだ。そして、革新的なアーキテクチャによって、コンピューティングパラダイムも変えて行きたいと考えている。

【Allard】 それは本気か?(笑)

私は、E3でのフォーカスはきちんとゲームに絞るべきだと思う。プレスカンファレンスでも関心が向けられたのはゲームについてだった。

しかし、我々もゲームを超えたエンターテイメントについて、無視しているわけではない。Xbox 360でのそうしたエクスペリエンス(ユーザーが得られる新しい体験)についても、簡単にだが触れている。例えば、我々は、ゲーム中に、望む音楽を何でも聴けるようにするといったイノベーションについて話をした。ミュージックプレーヤーやデジカメといったUSBツールを接続して楽しむことができるとか。フォトスライドショウを作るとか、インターネット上で友人と音声でコミュニケートするとか。

もし、技術ではなく、こうしたエクスペリエンスを、人々に届けたいなら、もっと具体的に説明する必要があると思う。Gigabit Ethernetがエンターテイメントにどう関わるのか、1,080ドットのHDTVをサポートする2つのHDMIポートがエンターテインメントにどう関わるのか。私は、久夛良木氏の、こうした設計上の決定が、どんなエクスペリエンスにつながるかには興味がある。

私の決定は、ハードウェアとソフトウェアとサービスの融合で、これはユーザーに信じられないようなエクスペリエンスを与えてくれる。我々はエクスペリエンスにフォーカスし、そのエクスペリエンスができるようなハードウェアを作る。ハードウェアを作って、あとからサービスを考えるのとは違う。

【Q】 ゲームそのものよりビジョンを前面に押し出したSCEのアプローチは、それなりに好評だった。

【Allard】 あなた方は、PS2がIEEE 1394ポートを持っているのを覚えているだろう。HDDポートもUSBポートもある。そして、彼らが'98年から'99年に、PS2について語ったことを覚えているだろうか。「コンピューティングパラダイムを変える」と非常に大きな夢を語り、広範囲なコンピュータエンターテイメントの未来を語った。インターネットブラウザだの、LCDスクリーンだの、マウスだの……。色々なことを語ったが、実際にはほとんど何も実現しなかった。

なぜ? 簡単なことだ。重要なことは、エクスペリエンス、すなわちゲームだったからだ。そこにフォーカスしない限り、意味がない。だから我々はゲームのための製品を設計する。

引用が長くなっちゃいましたが。。。

どんなものであれ、システムは要求に則って設計されるべきです。仕事の内容として、顧客との対話が可能である場合でも、最初のヒアリングの後、実際の要求の内容については設計者側でシナリオを想定してある程度推測し、その上で顧客との対話によって更にすり合わせを行う、という段取りを踏みます (まさにユースケースを定義するまでの段取りです)。パッケージ製品であったり、今回のようにゲーム機であったりと、実際の顧客との対話が不可能である (あるいは要求を確定する目的において、個別の顧客との対話にあまり意味がない) 場合、市場を観測し、ニーズがどこにあるのかを定めた上で、独自に定めたニーズとのすり合わせで要求が固まって行くのではないかと思われます。

ニーズが要求へと変換される場合、最終的には、それは細分化された網羅的なシナリオの束として (すなわち、ユースケースとして) 説明できるくらいには、具体的である必要があります (そうでなくちゃ、末端の技術者は「何を」作るために設計書を起こしたりプログラムを書いたりしているのかが分からなくなってしまう)。逆に、しっかりとしたシナリオが設計段階以前に描かれていれば、その情報はいつでも営業の為の資料やユーザー向けマニュアルなどに変換することができるので、広報などの営業活動が楽になります。

Microsoft 側は恐らくその辺の段取りがある程度徹底されているのだと思います。だからこそ、上記のような発言が得られるのでしょうし、そこに「ディベロッパーとしての」自信が垣間見られるような気がします。

SCE 側の段取りの取り方は、今のおいらが関わっている仕事に似ています (苦笑)。今、おいらは、取引先の会社が既にある程度設計してしまった出来合いの「要求仕様」を元に、ユーザー向けマニュアルの作成を行っています。取引先の会社は、そのシステムが利用されるシチュエーションについてある程度理解していて、現場とのやり取りを交えてこの「要求仕様」を作成しました。「要求仕様」とはいえ、その内容は UI の設計にまで踏み込んでおり、具体的なメニュー、ダイアログや、出力として得られるファイルのデータに至るまで、しっかりと記述がなされています。しかし、肝心の「要求」の部分について、ユーザーが実際にそれらの機能をどのように使うのかという部分がほとんど説明されておらず、システム全体のビジネスにおける立ち位置程度のことしか記述されていません。

そのため、要求仕様の中に出てくる専門用語 (あるいはその現場でしか使われていない造語なのかもしれません) の意味がわからず、マニュアル上でどのように説明するべきか良く分からなかったりすることもしばしばあります。しかし、今回の仕事については、基本的に、我々開発者は現場で行われる実際の業務内容については関知していなくても良いということになっているらしく、不明な用語についてもその意味を知っている必要はない、という風に言われ、しかもその態度が無駄に徹底されているために、用語についての説明を求めることができない、ということにされちゃっているらしいのです (なんじゃそりゃ)。

んで、ある日、とある二つの機能の相互関係について、マニュアル上でどこまで言及してよいかを確認するため、要求仕様について把握している社員の方に尋ねてみたところ、確かに相互関係を狙ってこれらの機能が設けられているのは確かなんだけど、マニュアル上ではあまりそのことについてはっきり書かないで欲しい、と言われてしまいました。もちろん、そのような機能の組み合わせの内、片方の機能が、未来バージョンにおいて単独で機能変更されるということはこれまでもあったことですが、その際にはその都度マニュアルの記述も修正すればよいことでした。しかし、今回に至っては、とりあえずこしらえてみた機能を取引先や現場で試用してみた上で、そこからそれらを実際にどう使って行くのかを決めていく、というスタンスを取るから、固定の目的をあまりはっきり書かれてしまうと、実際の運用段階に入ったときにその内容がかけ離れたものになってしまうかもしれない。だからそういう部分は無難にぼやかして書いて欲しい、などというのです。

これには、さすがのおいらも頭がくらくらしてきてしまいました。何を作らせようとしているのかが自分たちでも良く分かっていない取引先に、言いなりにだけなって振り回されている開発チーム。こんなんで、本当に仕事が成功するのでしょうか?

目的を後回しにして機能ありきでは、物事はうまくいきません。なぜなら、無駄が多くなってしまうからです。引用した文の中で J Allard 氏も、PS2 の、結局使われなかった各種インターフェースについて指摘しています。「宝の持ち腐れ」とはよく言いますが、その言い方は卑怯です。だって、それらははじめから、多くのユーザーにとっては、宝でも何でもなかったからです。宝にしたいのであれば、やんわりと「夢」をぼやかして語るのではなく、具体的にシナリオを提案しなければなりません。そして、そのシナリオを提案することができるに足るだけのサプライも必要です。SCE は PSP の無線 LAN 機能に対しても有効なサプライが行われていません。だから、ユーザーにしてみれば、SCE は PSP の無線 LAN 機能で何をさせたいのかが、発売から半年近くたった今になっても分からなかったりするのです。

SCE が「要求を定義する」という作業に親しみがないためにこのような段取りを繰り返し踏んでいるのだとしたら、きっと中で働いている開発者の方々も、効率の悪い仕事振りに相当苦労していらっしゃるのではないでしょうか? SCE のソフトウェア開発能力が今ひとつだと言われるのも頷けるような気がします。

もっとも、ユースケースを通じて「要求を定義する」作業に対して、その重要性を全社的に見出している会社というのは、そもそも少ないのではないかと思います (特に日本国内では)。この辺、各社の実態などに関する生の声とかが窺えたりすると、面白いんですけどね。