[特集:ユーザー視点向上チェックシート 1/2］ Twitter・Unity・Movable Typeに聞く、利用者が離れるNG開発パターン

2012/02/10公開

「ソフトウエアの開発にはユーザー視点が欠かせない」

日々、開発に勤しむソフトウエアエンジニアであれば、そんなことは百も承知だろう。しかし「ユーザー視点」の重要性を踏まえつつ作ったはずのソフトウエアが、やれユーザビリティーが悪いだの、テクノロジー・オリエンテッドだのといった理由で普及せずに終わってしまうことも少なくない。

なぜ、ユーザー視点が大事なことは重々理解していても、それがユーザビリティーにつながるとは限らないのか？

多くのソフトウエアエンジニアを悩ますこの疑問を解消すべく、Twitter、Unity、Movable Type（以下、MT）といった、何万人～何億万人規模のユーザーから支持を集めるグローバルな大規模プラットフォームを手掛ける3人のスゴ腕エンジニアに取材。

彼らが考える、ユーザー視点向上のための秘訣を聞いたところ、3人に共通する、5つの「ユーザー視点向上に必要なチェックポイント」が浮かび上がってきた。

それをまとめたのが以下のチェックシートだ。

なぜ、これら5つのチェックポイントを押さえておくことが、「ユーザー視点」の向上につながるのか。3人のコメントを交えながら、一つずつその理由をひもといていこう。

まずは基本。「ユーザー視点について知りたいなら、ユーザーの意見を汲むべし」という意見。

ユーザーの不満や意見を真摯に受け止めたいなら、開発者がユーザーとつながることができる「オープンな場」を設けておくことが望ましいと3人は話す。

Twitterの場合、サービス自体が人と人をつなぐオープンな場なので、
日々ものすごい数の声がエンドユーザーから寄せられています。

いただいた意見が基になってサービス改善につながることも多いですね。

Twitter APIを使う開発者向けには専用のポータルサイトを用意しています。
また昨年から日本国内でも開発者コミュニティー支援に力を入れており、
日本語で情報交換ができる専用アカウント@twj_devと
開発者向けメーリングリストTDT-jaを設けました。

また、われわれが開発したコンポーネントやツールを、
オープンソースとして公開する場としてGitHubを利用しており、
Twitterのバックエンドにすら開発者からの
フィードバックを取り込むことのできる仕組みを用意しています。

あと、ユーザーから情報を得ようとする時、気を付けているのは
「情報をもらいっぱなしになっていないか？」ということです。

情報を一方的に得るだけでは、
そのうち流れは停滞してしまいますが、
サービスの提供者と利用者が交流できる場を準備しておけば、
情報の流れは自然とインタラクティブになります。
このことも、われわれがオープンな場を用意する、大きな理由の一つです。




（山本裕介氏）

直接的なユーザーがエンジニアであるUnityの場合、コミュニティーを通してゲーム開発者とつながっておくことは、Twitter以上に重要な命題だ。

「The Unity Community」や
「Unity Asset Store」といったサービスを運営することで、
ホビイストからプロまで、さまざまな立場のゲーム開発者同士が、
自分が作ったアセットを販売したり、Q&Aやフォーラム、
Wikiを利用してノウハウを共有したりできる仕組みを提供しています。

ただ場所を用意するだけではなく、これらのサービスの中で、
多数のUnityのエンジニアがさまざまな発信をしているのが特徴です。

ほかにも、FacebookなどのSNSを利用した情報共有や、
Web経由でのほしい機能の投票サイト制作、
『The Global Game Jam』などの国際的なイベントの参加者に対する
期間限定のプロライセンス無償供与など、あらゆる取り組みを行なっています。

われわれが参加者としてゲーム開発を行うこともありますし、
Unity側からも積極的に開発者にかかわろうとしていますね。




（大前広樹氏）

加えて金子氏は、ユーザーとのコミュニケーションを「オープンな場」で行うことには、別のメリットもあると話す。

Movable Typeは「オープン」であることが特徴です。
2007年にオープンソース化し、
2010年にはソースコード管理をGitHubに移行しました。

プロジェクト管理用のFogBugzは、誰でも登録して、
機能要望やバグ報告ができます。

このように、ただユーザーと議論をするだけでなく、
開発の過程をオープンにすることで、
開発者とユーザーが同じ土俵で
情報を共有できている雰囲気を作ることができるんです。

これが結果的に、サービスの提供者と利用者の
連帯感強化に一役買っていると思いますね。




（金子順氏）

［チェック項目①］と反する内容に、あれ？と思う人も多いだろう。それもそのはず。第一のチェックポイントでは、「ユーザーからの声を汲み取ることが重要」だとしていた。

にもかかわらず、なぜユーザーニーズを真に受けてはいけないのか？大前氏は、持論でもある「8：2の法則」を引き合いに出してこう説明する。

ニーズというのは拮抗するものですから、
すべての人が満足するツールというものは存在しません。

これは、フロム・ソフトウェア時代に
複数チームが使う開発環境を整備していた時にも感じたことですが、
「すべての人を満足させる」ものづくりは
中途半端なプロダクトを生む元凶になるんです。

「誰に向けて作っているのか」の定義が
あやふやになっていくんだから当然です。
それこそユーザビリティーを語る以前の問題ですよね？

また、そもそもモノとして優れていなければ
誰にも受け入れられず、誰も喜ばないものができ上がります。

そのため、Unityのようなゲーム開発エンジンの場合、
ユーザー側にわれわれが提案するワークフローを
ある程度受け入れてもらうことを前提に開発されています。

「ゲームとはこう作られるべきだ」、「だからこう使ってほしい」という、
作り手側の"ゴーマニズム"が込められているんです。

その上で、開発環境自体に強力な機能拡張の方法を用意し、
ユーザー自身の手で必要な機能を追加できるようにしています。
Unityが提供する環境がどれだけ進化しても、
ユーザーにとっての100％には絶対にならないことを知っているからです。

より具体的に言えば、全体の約8割は
作り手のゴーマニズムと汎用性を前提に完ぺきに仕上げて提供し、
枝葉末節の残り2割は無理に作り込まないのが良いと思っています。
これを僕は「8：2の法則」と呼んでいます。

全体の2割を、ユーザー自身が手を入れられる余地として
｢未完｣の状態にしておくことで、製品もぐっとシンプルになり、
Unityのゴーマニズムをさまざまなニーズを持つユーザーが
うまく使いこなせるようになるわけです。




（大前広樹氏）

この大前氏のコメントに呼応するように、サービスの提供者は、ユーザーニーズに応えるのではなく、ユーザーニーズを越えなければならないと主張するのは金子氏だ。

ユーザーからの要望をそのまま形にすることはできますが、
その結果、思わぬほかの部分に悪影響が出てしまう可能性もあります。

われわれの仕事は、非常に細かい要望に対して
直接答えを出すことではありません。

表面上は見えてこない、ニーズの奥にある
非言語的な本質を包括するような解決策を導き出すことなんです。

多くのユーザーの支持を集める優れたサービスというのは、
ユーザーの意見を反映したサービスというよりはむしろ、
ユーザーニーズを"越えた"サービスなのではないでしょうか。




（金子順氏）