掲載媒体 WEB+DB PRESS Vol.60

2010年12月22日発売の WEB+DB PRESS Vol.60 へ寄稿した文章を(技術評論社さんの好意もあり)少し訂正して公開します。ブログエントリとしては長大な3万字なので、電子書籍BCCKS版(無料)もご利用ください。iPad版は読みやすかったです。

関連情報:アジャイルUXDの記事を執筆(ポンパレを7週間で開発したプロセス事例) (2011年1月17日)

誌面の制約(9頁)から、かなり圧縮した文章になってしまいました。ぶっちゃけると力みすぎで、決して読みやすくはない文章ですし、状況への憤りみたいなのもあって攻撃的な部分がありますし(笑)、ゼロベースの理論と実践もさらに先へ進んでしまっているわけですが、誰かの役に立つかもしれませんので公開することにしました。

なお、人物の肩書きは初稿執筆当時のものです。

はじめに

ゼロベースは「新規事業としてのウェブサイト開発プロジェクト」を何十件も受託してきました。その過程では「いかにして新規事業を成功させるか」を考え、工夫してきました。その現時点の成果として、一般的には「アジャイルUXD(※)」と呼ばれる方法を獲得しました。その概要を本稿で紹介します。

※UXD: User Experience Design(ユーザーエクスペリエンスデザイン)

本稿の構成は次のようになっています。まず「新規事業としてのウェブサイト開発プロジェクト」において大事なポイントを確認した上で、原理・原則を述べ、最後に具体的な事例を取り上げて解説します。

取り上げる事例は、株式会社リクルートが運営するウェブサイト「ポンパレ (http://ponpare.jp/)」の開発プロジェクトです。

なお受託開発の経験にもとづくため「委託者」「受託者」という言葉を用いていますが、その関係性を「プロダクトオーナー」「開発部門」と読み替えれば、大筋では自社開発(内製)にも通用すると思います。

新規事業としてのウェブサイト開発プロジェクト

本節のポイント:ビジネスの「勝ちパターン」が見えないとき、試行錯誤が大事です。そのためには開発プロセスもウォーターフォールよりアジャイルが適しています。

まずは開発プロジェクトではなく、ビジネスの話をします。あらゆる開発プロジェクトは、その成果物が何らかのビジネスのために使われることを前提に行われます。したがって、ビジネス全体のプロセスと、開発プロセスは、分かちがたく結びついています。

創発的戦略プロセスと意図的戦略プロセス

新規事業の立ち上げは、「必勝戦略」いわゆる「勝ちパターン」の獲得プロセス、あるいは学習プロセスといえます。まだ始めたばかりのビジネスでは、「必勝戦略」が分からない。それを見つけるためにさまざまな試行錯誤をします。何がうまくいき、何がうまくいかないのか…それを知るための試行錯誤です。どんな製品を、どんな価格体系で、どんな宣伝をして、どんなふうに売れば売れるのか。無料のウェブサイトでも、利用してもらうことや会員登録してもらうことを「販売」とみなせば、「必勝戦略」の模索が必要だということに同意いただけると思います。

経営学者のクリステンセン教授は、次のように区別しました。試行錯誤を通じて「必勝戦略」を明らかにするプロセスを「創発的戦略プロセス」と名付け、それに対して、すでに「必勝戦略」が明らかな場合に「いかに遂行するか」を中心に考えることを「意図的戦略プロセス」と名付けました。

将来を予見することが難しく、何が正しい戦略かはっきりしないような状況では、創発的プロセス主導で戦略を策定することが望ましい。この状況は、初期段階にある企業にほぼ必ずあてはまる。(略)他方、必勝戦略が明らかになれば、今度は意図的戦略プロセス主導で戦略を策定しなくてはならない。このような状況では、戦略を効果的に実行することが、成否を分けることが多いからだ。

クリステンセン『イノベーションへの解』pp.260-261

新規事業でウォーターフォールを採用することの問題点

ウェブ事業における創発的戦略プロセスは、ウェブサイト(システム)の頻繁な要件変更を要請します。ここに「ウォーターフォール開発プロセス」の問題があります。

註:本稿において「ウォーターフォール」という語は、その原典であるロイス博士の論文における意味ではなく、通俗的な理解としての「ウォーターフォール」を意味しています。

ウォーターフォール開発プロセスは頻繁な要件変更を許容しません。そのことが、新規事業にとっての足かせになります。もちろん、すでに「必勝戦略」が明らかなら(意図的戦略プロセスに従って)ウォーターフォール開発プロセスで構いません。しかし、新規事業において「必勝戦略」が事前に明らかであることは稀です。したがって、新規事業においてはウォーターフォール開発プロセスに替わる方法が必要です。

アジャイル

一部のウェブ・スタートアップ(ベンチャー)企業では、昔から「アジャイル」が実践されてきました。例えば「永遠のベータ版」「毎日リリース」といった実践です。前述のように「必勝戦略」が明らかでない新規事業において、このような実践は事業の成功確率を上げる上で有効です。

しかし、受託開発においては、あまり実践されていないようです。新規事業における受託開発プロジェクトの成功確率(ひいては新規事業の成功確率)を上げるためには、受託開発においてもアジャイル開発プロセスの導入が必要です。

戦略プロセスと開発プロセスは結びついていますから、新規事業というアジャイルなビジネスには、ウォーターフォールよりもアジャイルな開発プロセスのほうが有効です。

ユーザーエクスペリエンスデザイン

本節のポイント:ユーザーエクスペリエンスとは利用者の主観的な体験です。それをデザインする行為こそ、製品設計の根幹です。それゆえ「デザイン」を軸に開発プロセスを考えることが大事です。

ウェブサイトが成功するもしないも、かなりの部分がユーザーエクスペリエンス(利用者体験)の善し悪しにかかっています。初めて訪問したウェブサイトが分かりにくければ、数秒で退出してしまうでしょう。会員登録プロセスがストレスフルなら、会員登録を中断してしまうでしょう。使い始めても満足いく結果が得られなければ、使うのをやめてしまうでしょう。これらすべてが主観的な「体験」(エクスペリエンス)の問題です。

デザインの重要性

ユーザーエクスペリエンスの善し悪しが事業の成功を左右するなら、ユーザーエクスペリエンスデザインの善し悪しが事業の成功を左右するということです。デザインの不在はプロジェクトの成功確率を著しく下げます。デザインは技術に先立って重要です。製品開発においてエンジニアリングではなくデザインを中心に置くことが大事です。

ところが、多くのウェブサイト開発プロジェクトで「デザイン」が軽視されています。エンジニア主導で(要件定義を含む)ウェブサイト開発が行われています。

「Visual Basicの父」として知られるアラン・クーパーは、そのようなエンジニア優位・デザイン軽視の状況を批判する本のタイトルに “The Inmates Are Running the Asylum” とつけました(邦題『コンピュータは、むずかしすぎて使えない!』)。原題は「被収容者が運営する精神病院」という酷い言葉です。開発プロジェクトや企業が、「デザイン」不在のままソフトウェア・エンジニアに振り回される様を皮肉った言葉です。

ハイテク産業は、気がつかないうちにプログラマやエンジニアに支配権を与えてしまったので、かれらの使いにくいエンジニアリング文化が支配するようになってしまった。

見た目にはどうだろうと、ハイテク産業を支配しているのは企業重役なんかではない。舞台を仕切っているのはエンジニアたちだ。シリコンチップからのメリットを享受しようとあわてるあまり、われわれは責任を放棄してしまった。いまや、病人たちが精神病院を運営している状態なのだ。

クーパー『コンピュータは、むずかしすぎて使えない!』pp.26

「デザイン」についての誤解

ここで足りないのが「デザイン」です。「デザイン」へのよくある誤解は、デザイナーの仕事が表層(surface)の調整だというものです。つまり、エンジニアが実装した機能の見た目を整える、装飾だと。そして、そういう意味での「デザイン」は、すでに行われているではないか、デザインは軽視されてなどいない、と。

それは違います。デザインとは「ユーザーエクスペリエンス」を形作る行為です。表層・見た目の問題ではありません。利用者の主観的な「体験」に焦点を当てたデザインプロセスなしに、「デザイン」をしているとは言えない。

「ユーザーエクスペリエンス」とは、文字通り「体験」ですから、利用者にとっての主観・意味です。「ユーザーエクスペリエンスデザイン」とは、利用者の体験をデザインする行為です。「デザイン」とは人工物に意味を与える活動であり、「『製品に対する利用者の理解』についてのデザイナーの理解」という「二次的理解」をもとに行われます。つまり、「自分はターゲットユーザーではない」という前提に立ち、ユーザーの「体験」を想像(二次的理解)してデザインする必要がある。

デザインにおいて失敗を避けるために、デザイナーには技能・技術・訓練の体系があります。設計における理解が「二次的」(他者の理解についての、設計者の理解)だという前提で、高い精度で利用者の主観的体験を理解したうえで、よりよい体験をデザイン(設計)するために、デザイナーは様々に工夫します。

ですから、要件・仕様を決めるという「デザイン行為」が、そのスキルを持たない人によってなされるのは、望ましくありません。アラン・クーパーが警鐘を鳴らしたように、要件・仕様は、利用者にとっての製品の意味を形作るものであり、デザインの対象です。

アジャイルUXD

一般的な「ユーザーエクスペリエンスデザイン」はウォーターフォール的なプロセスで実施されます。従って、「アジャイル」とは相容れない。「アジャイルにユーザーエクスペリエンスデザインする」ためには工夫が必要です。そのように工夫した方法は一般的に「アジャイルUXD」と呼ばれています。

本稿で紹介するゼロベース流「ウェブならではのアジャイルUXD」は、アジャイルとユーザーエクスペリエンスデザインの融合を目指して作り上げてきた方法です。

経験主義

本節のポイント:予想ではなく、現実・事実に立脚して設計・計画しよう。「取り返しのつかない大失敗」を避けるために、「取り返しのつく小失敗」を繰り返そう。

アジャイルとユーザーエクスペリエンスデザインを融合させる上で、筆者らが立脚する思想は「経験主義」です。

経験主義【ケイケンシュギ】

1 「経験論」に同じ。

2 理論よりも自己の経験のほうを重視し、もっぱらそれによって物事を判断しようとする態度。

デジタル大辞泉

英語empiricismなどの訳で,合理論(理性主義)の対。抽象的・一般的原理ではなく,個別的・具体的な経験を認識の基礎とする立場。感覚論,現象論,実証主義を主要思潮として含み,思想史上,イギリス経験論,プラグマティズム,論理実証主義などが代表的。

百科事典マイペディア

人間の想像(予想)能力には限界があります。それゆえ、「計画」「設計」などの営みは、すべて人間能力の限界との戦いです。能力を超えて「計画しすぎてしまう」「設計しすぎてしまう」と、望まざる結果になりがちです。

「ウェブサイトをリリースしてみたら、利用者の行動が事前の想定と全く違った」といった失敗が、よく見受けられます。これが想像力の限界を超えた結果です。「わかったつもり」の害です。

失敗という概念は設計プロセスの中心となるもので、失敗を避けようと考慮することではじめて、設計の成功が成しとげられる。

ペトロスキー『橋はなぜ落ちたのか』pp.7

設計と失敗

では、新規事業において、「失敗を避ける」ことを開発プロセスの中心に置くと、どのような実践が推奨されるでしょうか。それは、作る前に考えすぎることなく、まず現物を作ってから考えること。なるべく早く、少しずつ、実際に動くものを作ること。実験すること。実験の結果が芳しくなくても「失敗」ではなく「学習」と捉えること。短期間に何度も「学習」を繰り返すことです。

大事なのは「分からない」ことは「分からない」と認めることです。現実の前に謙虚になること。それを忘れて、本当は「いやな感じ」に気付いているのに「まあ大丈夫だろう」とやり過ごしたところで失敗が生じます。あらゆる願望は現実の前に無力です。現実・事実に立脚し、意志を持って実践することでしか、「取り返しのつかない大失敗」は避けられない。

不都合を生じる可能性があるものは、いずれ必ず不都合を生じる。

マーフィーの法則

失敗と学習

「取り返しのつかない大失敗」は、いつ起こるのでしょうか。それが失敗だと気付かずにどんどん進んでしまったときです。

ペトロスキーの意味する「失敗」とは「取り返しのつかない大失敗」のことです。それは避けなければなりません。一方で、「取り返しの着く小失敗」は、むしろ学習のために不可欠です。

失敗を避けるために、徹底して現実・事実に立脚し、実験を通じて学習すること。これが経験主義の設計思想です。

失敗ではない。うまくいかない方法を一万通り発見しただけだ。

トーマス・エジソン

プロトタイピングと「永遠のベータ版」

本節のポイント:製品を頻繁にリリースし、利用者に学び、改善する。このサイクルを高速に回そう。

ユーザーエクスペリエンスデザインにおける失敗を避けるための実験・学習」とは、利用者の実際の行動を、現物によって確かめることです。この行為を、人間中心デザイン(※)においては「プロトタイピング」と呼ばれます。

※人間中心デザインまたは人間中心設計(HCD: Human-Centered Design)のプロセスはISO 13407:1999 Human-centred design processes for interactive systemsとして国際規格化されました。なおdesignの訳語としては「デザイン」「設計」の双方が用いられます。

人間中心デザインの「プロトタイピング」は開発フェーズにおいて行われるのが通常です。それに対し、ウェブにおいては「永遠のベータ版(※)」という考え方があります。プロダクトをリリースしたうえで、その利用者行動を解析し、設計にフィードバックし、すぐに修正する。ウェブにおいては、一日に何回、修正版をリリースしてもいい。この「ウェブならでは」の特性を活かした設計・プロトタイピングの考え方が「永遠のベータ版」です。

※Tim O’reillyが「Web2.0のデザイン・パターン」として述べた “Perpetual Beta” のこと。

このように、設計プロセス全体において「実験」を中心に置きます。もちろん開発フェーズでのプロトタイピングだけでも役立ちますが、実際にリリースしたのち(モニターという仮の利用者ではなく)現実の利用者の行動をもとに改善していくほうが、より現実に立脚しており、経験主義的です。

このような設計プロセスでは「バージョン」の境界が曖昧です。実装して、テストして、最終的な承認を得た変更から順次リリースしていく。リリース計画は大規模なリニューアルには存在しますが、日々の小さな改善を長期にわたって計画することはありません。日々の小さな改善は、わざわざバージョンごとのリリース計画として区切らなくても、小さな粒度の要件単位で順次開発・テスト・リリースしていけばいい。ここでいう「小さな粒度」とは、課題管理システム(※)に登録する「課題」を意味します。例えば「複数アイテムを同時購入できるようにする」などが1つの課題です。この「課題」単位で開発・テスト・リリースしていけばいい、という考え方です。

※ゼロベースでは課題管理システムとして株式会社ヌーラボの”Backlog”を採用しています。その他、Trac、Redmineなどがあります。

現物主義

「現物」のウェブサイトをもとにユーザーエクスペリエンスの仮説検証を高速に繰り返すためには、「Webサーバ」と「HTML」に立脚してプロセスを設計することになります。結局のところ、HTTPのUser AgentにとってはWebサーバとHTMLが重要なのです。サイトストラクチャ(サイトマップ)、ワイヤフレーム、デザインカンプなどの中間成果物は必要最小限にして、なるべく「現物」としてのHTMLを中心に、ワークフローを組み立てます。

アジャイルUXDのプロセス

個々の開発プロジェクトにおいてプロセスを設計する際には、「最終的に必要な最小限のものは何か」と考え、そこからの逆算でプロセスを設計します。タスクの優先順位も、進め方も、プロジェクトによりけりです。ただし、抽象的なレベルでの、プロセスの「ひな形」はあります。その全体像を、図3をもとに説明します。

図1 ウォーターフォールUXD:

図1 ウォーターフォールUXD

図2 ウェブならではのアジャイルUXD:

図2 ウェブならではのアジャイルUXD

図3 ユーザーエクスペリエンスの構造:

図3 ユーザーエクスペリエンスの構造

(出典 Jesse James Garret, 『ウェブ戦略としての「ユーザーエクスペリエンス」』, 毎日コミュニケーションズ, 2005, pp.38)

戦略(strategy)

まずは委託側と受託側で戦略コンセプトをしっかり共有します。何をしようとしているのか。利用者にどんな体験を提供しようとしているのか。ここをしっかり共有する。と同時に、決まっていないこと、分からないことがあれば、うやむやにせず(決める、のではなく)「決まっていないまま」「分からないまま」にしておく。経験主義的に、仮説のままにしておく。

スコープ(scope)

次にスコープ(要件のリスト)を共同で検討して決めます。これは週1〜2回の定例会議などの場において。スコープが決まったら、以降のプロセスは前述のように要件(課題)単位で平行して進めます。まとめて処理したほうが効率よい要件もあれば、依存関係のある要件もあるでしょう。要件の優先順位を、(委託側も含む)チーム全員のタスクの優先順位にする必要があります。各メンバーのパフォーマンスを最大化するようなタスクの割り振りがディレクタの役目です。

構造(structure)・骨格(skeleton)

要件を実際に設計する際には、まず構造(structure)レベルでUIフロー(図4)を考えます。これをもとに、(ワイヤフレームなどの設計書は作らず)骨格(skeleton)レベルの「HTMLモック」を組みます。CSSで最低限のレイアウト指定をした、いわば「ワイヤフレーム」的なものがHTMLモックです(図5,図6)。このHTMLモックはディレクタ兼IA(インフォメーション・アーキテクト)からデザイナーへの作業指示書でもあります。

図4 UIフロー図(一例):

図4 UIフロー図(一例)

図5 HTMLモック(画面表示):

図5 HTMLモック(画面表示)

図6 HTMLモック(ソース):

図6 HTMLモック(ソース)

表層(surface)

HTMLモックをもとにCSSや画像などを作成して「HTMLテンプレート」にします。HTMLテンプレートは、いわゆる静的HTMLとしての完成版であり、最終的なアプリケーションの画面出力とほぼ同等の表層(surface)を規定するものです。それをエンジニアがシステムに組み込んで、(Model-View-Controllerアーキテクチャでいうところの)「ビュー」として実装すれば、アプリケーションとして動作する状態になります。

エンジニアとデザイナーの並行作業

エンジニアがモデルやコントローラの設計・実装に着手するためには、とりあえずHTMLモックがあれば大丈夫です。そこに入出力要素(データ項目)とユースケースが書かれているからです。

つまりHTMLモックをもとに、エンジニアの設計・実装作業と、デザイナーのHTMLテンプレート制作作業は並行作業できます。最後に、デザイナーが仕上げたHTMLテンプレートを、エンジニアがシステムの「ビュー」として組み込む。これによってシステムが出来上がります。

ここで重要なのは、デザインカンプを作ってからHTMLコーディングするのではなく、デザインカンプは作らないということです。また、ワイヤフレームから直接にHTMLモックを作るということです。

このワークフローは速い。新規作成する画面だけでなく、既存画面の修正についても。ボタンのサイズを変えるたびにデザインカンプから作り直すのか、あるいは直接CSSを編集して済ますのか。デザインカンプは中間成果物であり、それ自体にはビジネス上の価値がないわけで、どちらが合理的かは明らかでしょう。

デザイナーに必要なスキル

このようなエンジニアとの共同作業をするために、デザイナーには(例えば)「SubversionでERBを編集するスキル」「gitでSmartyを編集するスキル」が必要です。

まず、デザイナーには「システムのビューとして組み込まれたHTMLテンプレート」(ERB, Smarty, JSP, ASPなど)を直接編集するスキルが必要です。修正のたびに、エンジニアに「組み込み依頼」をするような無駄は少ない方が良いからです。非常に複雑な表示制御ロジックなど、やむを得ない場合はともかく。

また、そのためにはバージョン管理システム(Subversionやgitなど)を使うスキルも必要です。

したがって、端的に言えば「SubversionでERBを編集するスキル」がアジャイルUXDチームにおけるデザイナーの基本スキルです。

テストとリリース

実装されたアプリケーションをテストし、ステージング環境で委託者に確認してもらい、承認を得られたら、リリースします。確認のポイントは「要件が満足されたか否か」です。

中間成果物

この一連のプロセスのなかで、ワイヤフレームやデザインカンプなどの中間成果物を、なるべく作らないようにします。なぜかというと、それらは現物主義に反して「Webサーバに組み込めないもの」です。なるべく無駄なものは作らない。

確認のための中間成果物を作るとき、作る時間だけでなく、確認する時間も発生します。中間成果物をもとにした確認作業は、トータルで多くの人の時間を奪うことになります。

もちろん中間成果物を作ることが有効な場面もあります。それは設計上のリスクが高い箇所についての決定をするときです。その場合も、委託者・受託者だけで検討するよりは、モニター(※)を用いてテスト(プロトタイピング)したほうがよいでしょう。そのようなテストのためにワイヤフレームやデザインカンプを作るのは有効です。

※モニター:依頼されて意見を述べる人のこと。「画面」のことではありません。ペルソナ/シナリオ法にもとづくユーザビリティテストが望ましいです。

中間成果物を作る目的は「合意形成」や「委託者の言質を取ること」かもしれませんが(それを否定はしませんが)、それよりも第一義的には「現物をもとに利用者の反応をテストし、デザインに活かすため」です。合意や言質をもとに実現した結果が失敗ならば、何のためにやっているのかわかりません。誰のために、何のための仕事をしているのかという基本に立ち返れば、何を重視すべきかは自ずと見えてくるはずです。

リリース前のテスト(プロトタイピング)は「本当に必要かどうか」を検討する必要があります。「永遠のベータ版」の考え方で「迷ったらリリースして利用者の反応を見る」という方法をとることはできないだろうか、と。例えば、複数のデザイン案をA/Bテストにかける方法によって、予測ではなく事実に即した改善ができます。

なお、設計が複雑なとき、委託者と受託者の認識をあわせるために多くの中間成果物が必要になりますが、それは設計が複雑すぎることを示唆しているのかもしれません。そういう「匂い」に敏感になるのも大事なことです。

信頼とコミュニケーション

本節のポイント:委託者の信頼を得て、委託者の意図をしっかりと把握して開発できれば、開発スピードは上がる。

委託者から信頼を得ていれば、中間成果物での確認の多くは不要になります。中間成果物で確認しなければならない項目はわずかになります。

事前にスコープをしっかり確認しておいて、実装後の現物をステージング環境で確認する。これは委託者にとっても手間が少ない進め方です。

受託側としては手戻りが心配かもしれません。手戻りをなくす「言質を取る」ために中間成果物を作って確認しようとする。これを省くためには、委託側もアジャイルなプロセスにコミットする必要があります。

「委託側がアジャイルになる」とは「要件と成果物の100%の一致」を求めないということです。「スコープ(要件)を決める時点での期待」と「実際の開発成果」が100%一致する必要はない。なぜなら、そもそも「必勝戦略」を模索中(まだ獲得していない)なのだから、あまり細かいことを気にしても意味がないのです。

新規事業の不確実性の前には、どうせ「やってみなければ分からない」ことが多い。だから細かなことを気にしても仕方ないのです。細かい修正をやり直させる暇があったら、そのままリリースして利用者の反応を見たほうがいい。それが経験主義です。

また、細かい修正をせず、どんどん次の開発に移れば、チーム全員のパフォーマンスも上がります。どんどん仮説にもとづきリリースして、問題があったものについては検証して修正する。必要な「手戻り」は恐れないのが経験主義的な態度です。もちろん無駄な「手戻り」は避けるべきで、「良い手戻り」と「悪い手戻り」の見極めが大事になります。

※細かいことを気にしても仕方ないのは、新規事業立ち上げ初期です。徐々に細かいことも気にする必要がでてきます。それは創発的戦略プロセスから意図的戦略プロセスへの移行と連動します。

タスクベースの計画

本節のポイント:完全な計画を立てようとせず、変化に対応しやすい計画プロセスを考えよう。

プロジェクトの完璧な計画は、進行中の変更を許しません。ですから「計画しすぎない」ことによって、変化に対応します。それにより、急な戦略変更・要件変更にも対応しやすくなります。

ウォーターフォールのプロジェクト管理では一般的に WBS (Work Breakdown Structure) を用います。最終成果物を細分化した表です。これをもとに工数を見積り、スケジュールを立てるわけですが、これは明らかに「意図的」であって「創発的」ではありません。つまり、プロジェクトを開始する前から、プロジェクト全体を完璧に計画しようとするわけですが、これはまったく新規事業には向いていない。「何をすれば新規事業が成功するか」が事前に分かっていることはありません。

では、どうすればいいのでしょうか。なるべく「計画」を立てないことです。とはいえ、当然ながら「無計画」もありえません。「戦略」と「スコープ」を押さえたうえで、直近のタスクの優先順位だけ、しっかり決める。チームの各メンバーは、最も重要な作業から一つずつ片づけていく。いわゆる GTD (Getting Things Done) の発想です。

つまりWBS的な成果物ベースのプロジェクト管理から、GTD的なタスクベースのプロジェクト管理へ発想を転換するということです。要点は「チーム全員のパフォーマンスを最大化すること」であり、そのために各自がどのようなタスクの優先順位で作業すべきかを決める。

もちろん、成果物ベースでないからといって、最終的なプロジェクトの落とし所を見失ってはいけません。常に落とし所を念頭にプロジェクトを進める。マイルストーンやリリース計画といった中期的な計画は必要です。

このようなプロジェクト・マネジメントには経験が必要です。したがって十分な経験を持つディレクタを任用する必要があります。

コンパクトなチーム体制

本節のポイント:個人でウェブサイトを作るときのようなスピードをチームで実現するために、コンパクトな体制と、お互いへの信頼に基づくチームワークが必要。

アジャイルさ(アジリティ)の面では、個人でウェブサイトを作るときのような意思決定スピード、開発スピード、学習(試行錯誤・仮説検証)スピードが理想的です。とはいえ、個人ではユーザーエクスペリエンスデザインがおろそかになりがちです。一人ですべてをこなすのは難しい。

両者の良い点を併せ持つ体制を考えると、必然的にコンパクトなチーム体制がよいです。初期開発プロジェクト体制の典型例は以下のようになります。

委託側はプロジェクト・マネジャ1名のみ。別途プロダクト・オーナーがいる場合も、プロジェクト・マネジャに大幅に権限委譲されることで、機敏な現場判断ができることが望ましいです。何事もプロダクト・オーナーの決裁が必要となると、スピードに深刻な影響が出ます。いわば「毎回の会議で新たに出た課題について決定がなされる」か「毎回の会議で新たに出た課題について次回まで持ち越される」かの違いです。

受託側はディレクタ1人、デザイナー1人、エンジニア1人の3名体制。ディレクタは経験豊富なデザイナー出身のIA(インフォメーション・アーキテクト)で、常に落とし所を見失わずに設計とプロジェクト・マネジメントができる人物。デザイナーは「ウェブならでは」のアジャイルな開発プロセスに対応できる人物。エンジニアはデザイナーの仕事を理解し、ユーザーエクスペリエンスデザインのプロセスに適応できる人物。

このようなディレクタ、デザイナー、エンジニアの開発チームが、アジャイルUXDにとって望ましい体制の一例です。ポイントは、お互いの専門領域を理解・尊重しあっていること。デザイナーとエンジニアの対立など、もってのほかです。

アジャイルなガバナンス

初期開発プロジェクトが完了し、リリース後の継続開発フェーズに移り、事業が軌道に乗ってくると人数が増えていきます。そのなかでも、いかにアジリティ(機動性)を保ち続けるか。これは現場のチームワークだけでなく、それを可能にするガバナンスの問題(経営課題)として解決していく必要があります。

冒頭に述べた「意図的戦略」と「創発的戦略」の違いを経営者なり事業責任者なり(つまりプロジェクトの「オーナー」や「スポンサー」)が理解する必要があります。合目的的な効率性よりも、創造的な探索性や、失敗からの学習が重要であるということを理解しなければなりません。マネジメント層の理解が無いところでは、現場がアジャイル開発に向けて孤軍奮闘することになりますが、非常な困難に直面することになります。

「創発的戦略」から「意図的戦略」への滑らかな移行は、プロジェクトのガバナンス(責任と権限の配置関係)に関わる問題です。したがって、マネジメント層のコミットメントが必要なのです。

開発事例:ポンパレ

実践例を紹介します。株式会社リクルートが運営するウェブサイト「ポンパレ(http://ponpare.jp/)」の開発プロジェクトです。ゼロベース株式会社が受託して、開発期間1ヶ月半程で初期開発を行い、2010年7月21日にリリースしたプロジェクトです。リリース後も継続的・漸進的に開発されています。

なお、本プロジェクトは新規事業として企画されました。その背景に、2010年5月頃から日本国内で盛り上がってきた「グルーポンレース」があります。これは先行者「グルーポン」に代表される「フラッシュ・マーケティング」という新しいビジネスモデルを、いち早く日本で成功させようと多くの企業が参入している状態を表した言葉です。とくにベンチャー企業が先行していました。リクルート社としても、それら競合企業に遅れを取らず、速やかに参入することが目標でした。

プロジェクト開始

サービス開始予定日まで1ヶ月半程の時間しかありませんでした。これは極端な短納期案件で、ウォーターフォールではまず納期に間に合いません。従って、最初から現物主義的なプロセスが採用されることになりました。つまり、なるべく余計な資料は作らず、とにかく納期優先のプロセスにすることが決まりました。短納期だからアジャイルを導入しやすかった、と言えるでしょう。

初期開発の体制は、委託側2〜3人(開発担当、編集担当、運用担当)、受託側3人(ディレクタ、デザイナー、エンジニア)+1人(企画フェーズのみプランナー)でした。 短納期のプロジェクトでは、開始にあたってWebサーバの調達スケジュールを確認しておく必要があります。もちろんドメイン名の取得、ネームサーバの設定、SSLサーバ証明書の取得とインストールなども含みます。

ここでボトルネックになるタスクが「サービス名の決定」です。従って、まずはサービス開始予定日から逆算した「サービス名の決定日」を決める必要があります。サービス名が決まらなければ、ドメイン名も決まらない。ロゴも作れないから、デザインのトーン&マナーも決まらない。といった具合に、「サービス名の決定」がクリティカル・パス上にあります。

ポンパレでも、スケジュール全体が後ろ倒しにならないために、いちばん最初に「サービス名の決定日」を確認しました。

もう一つのクリティカルなタスクが「決済機能の開発」でした。決済会社は決まっていたので、サービスプランを選定して申し込む作業がクリティカルでした。従って、早期にエンジニアに検討してもらい、サービスプランを決定しました。また、開発に必要な技術資料も早々に入手するよう手配しました。

以上のように、まず最初にクリティカルなタスクを確認した上で、企画フェーズを進めることにしました。

企画フェーズ

企画フェーズにおいては、どのような利用者を想定し、クライアントとユーザーそれぞれに対して「どのような価値を届けるか」について議論しました。ペルソナとシナリオも軽く検討しました。この作業を軽くとどめ、仮説のまま次に進むのがアジャイルなUXDです。「ペルソナ/シナリオを完成させてから、次のフェーズに進む」はウォーターフォール発想です。

ポンパレはチケットを売るサイトなので、「どのようなチケット(商材)を出すか」の検討が中心になりましたが、やはり「やってみなければ分からない」ので、リリース直後に様々な商材を出して、利用者の反応を見る方針になりました。まさに創発的戦略策定プロセスです。

設計・開発フェーズ

「グルーポンレース」に先行していた競合他社のサイトを参考にすることで、初期開発においては設計にかかる時間を節約することにしました。とはいえ、ポンパレ独自の(表層(surface)レベルの)デザインは必要です。そのために「世界観を表現した一枚のデザインカンプ」によって、モニターにグループ・インタビューを実施しました。ここで使ったのは「毎日のチケットを表示する画面」で、ソーシャルウェブからの流入においてランディング・ページ(着地ページ)になる重要な画面です。このデザインカンプを用いてモニターからフィードバックを得たうえで、その後のデザインを進めました。

なお、初期開発のスコープは企画フェーズで決まっていました。それをもとに構造レベルの設計資料(図4 UIフロー図)と、各制作担当者とやりとりするための、ざっくりとしたワイヤフレームを作りました。基本的にはHTMLという現物を中心としたプロセスで、設計・実装・テストしました。

結果として、初期リリースを納期に間に合わせることができました。

初期リリース後

初期リリース後すぐに継続開発に入りました。そこからは、フェーズ単位の開発プロジェクトではなく、定常業務(ランニング)の保守開発的な形態での開発でした。課題管理システム(Backlog)に登録した課題に優先順位をつけて、翌週のリリース日までに何を実装するか、といったコミュニケーションを毎週の定例会議で行うといった具合に。

一方で、モバイル版、スマートフォン版、PC版の2次開発といったプロジェクトも同時に発生しました。

定常業務的な保守開発と、有期的なプロジェクトとが平行で走っており、しかも担当しているのは同じメンバーでした。このような状況下では、各メンバーのパフォーマンスを最大化するために「タスクベースの優先順位づけ」が有効です。

コラム:委託者としての心がけ

委託者としての心がけを、ポンパレ開発プロジェクトマネジャである株式会社リクルートカスタマーアクションプラットフォーム室の大宮氏に聞きました。

  • 戦略レベルでゴールイメージを共有しておくのが大事。その前提で、「こういう状態にしたい」と伝える。基本的に手段は問わない。自由・裁量を与えたほうが、ディレクタやデザイナーのやる気が出るはずなので。成果物の確認段階でも、あまり細かいことは言わずに、リリースしてから考える。どうせ正解は分からないし、スピードを重視したい。
  • 「あれはだめ、これはだめ」といった決まりごとを増やさない(例:責任分解点、仕様凍結、手戻り云々)。信頼を前提に、最低限の「OBゾーン」だけ決めておき、あとは自由にプレイできるようにする。委託者と受託者がお互いを縛りあって身動きのとれない状態にしない。
  • 限られたパワーを最適に配分するために、何をやらないかを決める。言い換えると、やらなくていいことを決める。それを決める上では戦略上の優先順位を押さえている必要がある。つまりプロジェクト・マネジャとして、プロダクト・オーナーと戦略レベルでの認識を合わせておく必要がある。

おわりに

本稿執筆にあたっては、受託開発のディレクタとして経験豊富なゼロベース米谷氏へのインタビューとディスカッションを通じて、ゼロベースとしてのベスト・プラクティスを抽出、言語化することを試みました。また、リクルート大宮氏はポンパレの事例を通じて委託者としての心がけを語ってくださいました。本稿は両名のご協力で成り立っています。この場を借りて謝意を表します。

本稿で紹介した「ウェブならではのアジャイルUXD」という方法は、チームメンバー個々人の能力が十分に高いことを前提にしています。従って、実践の敷居は高いかもしれません。とはいえ、能力の低いメンバーが一人いれば成立しない、というものでもありません。ぜひ実践のヒントにして頂き、そこで得た知見を筆者と共有して頂ければ幸いです。

参考文献

  • クレイトン・クリステンセン, マイケル・レイナー, 玉田俊平太監修, 櫻井祐子訳, 『イノベーションへの解 利益ある成長に向けて』, 翔泳社, 2003.
  • アラン・クーパー, 山形浩生訳, 『コンピュータは、むずかしすぎて使えない!』, 翔泳社, 2000.
  • Jesse James Garret, 『ウェブ戦略としての「ユーザーエクスペリエンス」』, 毎日コミュニケーションズ, 2005
  • ヘンリー・ペトロスキー, 『橋はなぜ落ちたのか』, 朝日新聞社, 2001.

謝辞

以下の方々に初出(WEB+DB PRESS Vol.60)時の原稿(上のものとは異なる誌面掲載版のこと)をレビューして頂きました。おかげで初稿よりも良い文章になったと思います。感謝します。

  • 原田 直貴 さま
  • 中村 剛 さま
  • 北村 和佳子 さま
  • 倉貫 義人 さま

関連情報

この文章を書くにあたり、構想段階から執筆中までTwitterでツイートしていたところ、多くの方々にご意見を頂き、大変参考になりました。感謝します。