Inspired日本語版

How To Create Products Customers Love

第25章 迅速な対応

第25章 迅速な対応
開発を始めたら最後まで手を抜かない、そしてリリースサイクル全体を守る

他の章では、製品の発売にこぎ着けることを成功と勘違いしてしまうという落とし穴のことや、製品やサービスの発売後も手を抜かないことがいかに重要かについて議論してきた。第25章では、この発売直後という製品開発プロジェクトの重大な局面で何をするべきかについて、詳しく見ていこう。

多くの会社では、製品が発売されたとたん、製品の開発・発売のために集結していたメンバーは、たちまちいなくなってしまう。次の製品開発プロジェクトにまわされるためだ。これは、まったくもって嘆かわしいことである。というのは、発売直後というこの時期こそが、問題に気づいて修正するには最善の機会だからだ。私は、これを、プロダクトマネジメントと製品開発プロセスにおける不手際であると考えている。この不手際は、発売直後という重大な時期を逃さないように、プロジェクトをほんの少し延長するだけで解消することができる。製品開発プロセスの中で、この時期ほど ROI (return on investment、すなわち、投資収益率) を改善できる局面は他にないだろう。だから、経営陣を説得してプロジェクトを延長するようにもっていくことは、難しいことではない。

私は、すべての製品開発チームに、製品発売後の数日から 1週間程度を予定に入れておくことを勧めている。私は、この段階を「迅速な対応」と呼んでいる。いったん製品が発売されると、いろいろなことがわかってくるので、それらにいち早く対応するのだ、ということを強調したいからだ。

このアプローチは、一般消費者向けインターネットサービスから始まった。というのも、この分野では、すばやい対応をすることが決定的に重要な意味を持つからだ。私は、プラットフォーム、インフラ、企業向け製品といった分野でも、同じことが言えると思っている。

たとえ、私が主張しているように、エンジニアリングが始まる前の早い段階で、プロトタイプの検証や妥当性の検証を全部やったとしても、また、優れた品質保証チームがいて製品の信頼性が確保できるとしても、製品が発売されてからでないと特定しづらい問題があることを想定しておく必要がある。通常のアプローチだと、ユーザーがどう反応するのか、問題があるのかどうか、といったことが判明するのを待って、一定のサイクルで修正のための追加リリースをすることになるが、これだと時間も費用もかかり過ぎる。

肝心なのは、問題があるかどうかではなく、問題にどれだけすばやく対処できるか、なのである。

製品開発の成果を測るには、ビジネス上の明確な基準がいくつか必要で、また、それらの基準について優先順位を決めておく必要もある。ページビューはどのぐらいか? 登録ユーザー数は? サイトの閲覧時間は? サイト訪問者がメンバー登録する割合は? 購読者数は? 広告収入は? 何が適切な基準の組合せであるかは、製品とそのビジネス上の目標次第である。ただ、いずれにせよ、注意を払うべきことは何かと何を追い求めているのかを、認識しておく必要がある。さらに、どんな結果が出れば成功と認められ、どんな結果になれば問題があると判断されるのかを、把握しておく必要がある。

一般消費者向けインターネットサービスの場合、その製品やサービスが人々にどう使われているかを理解することは、かつてないほどに楽になった。今では、簡単にサイト解析用のツールを設定しておいて、ユーザーの行動を追跡することができる。サイト解析のツールとしては、多くの製品がある。たとえば、Google Analytics (www.google.com/analytics) のようなアプリケーションを使えば、手間暇かけることなく、ユーザーがサービスをどのように使っているのかについて、多くのことを知ることができる。

企業向けソフトウェアの場合、プロダクトマネージャー、エンジニア、デザイナーなどの製品開発チームのメンバーを顧客企業のオフィスに送り込み、そこでユーザーがソフトウェアをインストールして、実際に使い始めるところに立ち会わせるのがいいと思う。製品開発メンバーが、顧客のオフィスに張り付いて、顧客が製品やサービスを使いこなせるようになってリファレンスカスタマー (訳注:第15章参照) となってくれるぐらいまでサポートすることの意義を理解してくれるようになると、各段に早く製品やサービスの問題を発見して解決できるようになる。そのスピードには、目を見張るばかりだ。

問題がはっきりしたら、製品開発チーム (プロダクトマネージャー、インタラクションデザイナー、主任エンジニア、顧客サービス、マーケティング担当者など) は、少なくとも 1日 1回は顔を合わせて、問題に優先順位をつけて、最善の対応策は何かを議論する必要がある。その結果、ホットフィックス (ウェブサイト上で緊急に配布される修正モジュール) を発行することになるかもしれないし、あるいは、問題の領域に関する説明を追加情報として提供することになるかもしれない。製品開発チームが製品やサービスの修正をやれる態勢になっていて、その上で、問題を特定していち早く対応することがどれほど決定的な意味を持つかを理解していれば、ごく短い時間で、製品やサービスの有効性を大きく改善することができるのだ。

サイト解析は、ユーザーを理解し、ユーザーがサービスをどう思っているかを理解する手法であるけれど、唯一のツールというわけではない。アンケート、電子メールでの意見交換、ウェブ上の掲示板、フィールドテストなど、他にも使える手法はある。でも、サイト解析のデータは、リアルタイムに近い情報を提供してくれるので、私の場合は、自分が関与しているすべてのサイトについて、ほとんど毎日のようにサイト解析に目を通している。私がよく見ているのは、サイトを閲覧する人はどこから来るのか、彼らはどんなページやアクティビティが好きなのか、そのサイトでどのぐらいの時間を過ごすのか、閲覧したページ数はどうか、どのくらいの頻度でこのサイトに戻ってきてくれるのか、といったようなことである。サイト解析以外にも、顧客サービス、販売担当者、ビジネスパートナーたちもまた、すばやい対応をするヒントを与えてくれる格好の情報源となる。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。