37signals logo Getting Real Overview

Buy the book

Buy Getting Real in PDF or paperback.

Job Board

Gig Board

Looking for design, copywriting, or programming help with your project? Check the Gig Board.

Getting Real



はじめにchapter1

Getting Realとは?

*ウェブ・アプリケーションをうまく作りたい? WEB2.0の最先端の考えを、あなたのプロジェクト・事業・アイディアに活かしたい?* そんなあなたに、この「Getting Real」をお届けします。 Getting Real は、より小さく、より速くソフトウェアを構築するのにより適した方法です。またそのアプローチは多くのビジネス・クリエイティビティの現場でも採用できるものです。

Getting Realの利点

Getting Realはよりよい結果をもたらします。というのも、Getting Realは、問題にさし当たった際、あなたの問題の考えに集中せず、問題自体を見るよう、現実を把握する様にリードしてくれるからです。本当に必要な実体と取り組むように仕向けてくれるのです。

Getting Realは、機能的な仕様や他の資料以上に、現実的な部分を考える方法です。機能的な仕様は実現しようとしている内容を取りまとめた、一種の虚像のようなものですが、現実は実際のウェブページにあります。そして、その現実的な部分がユーザーが真に求めているところです。Getting Realはそこにより速く導いてくれます。言い換えると、あなたは抽象的な概念ではなく、具体的なものからの判断で、ソフトウェアを作り上げることができます。

最後に、Getting Realは、ウェブ・ベースのソフトウェアに理想的な方法です。ソフトウェアを箱に詰めて、アップデートを送るまで1~2年待つ…なんて方法はもう過去のものです。インストールされたソフトウェアと異なり、ウェブのアプリケーションは日進月歩の改良が可能です。Getting Realによって、そうしたウェブ・アプリケーションの真価を最大限活用することができます。


<コラム> すばらしいソフトウェアを作るには…

素晴らしい文章は無駄がない。文章に不要な言葉が入らず、段落にも不要な文章が無い。同じように、図面も無駄な線を極力なくし、機械にも無駄なパーツをつけないものである。これにより、作り手は、詳細を全て短くし、もしくは省いて、骨組みだけの形に仕上げるのではなく、全てを伝えることができるのだ。

—From "The Elements of Style" ウィリアム ストランクJr.

肥大化はもうたくさん

古いやり方:長すぎて、官僚的で、やるべきといわれたことをこなすだけのプロセス→ありがちな結果:肥大化して、忘れられやすく、考えなしに崩されていくソフトウェア。なんてこった。

Getting Realにより省けるもの

すばらしいソフトウェアを組立てるために、大金や巨大なチーム、または長い開発サイクルは必要ありません。 そういったもののところからは、概してスピードが遅く、中身がはっきりせず、更新・修正が無いアプリケーションが生まれるものです。 現実指向の Getting Real では反対のアプローチを取ります。

この本でわかること

この本は全体的な考え方を焦点に書いています。あなたが細かなコードやCSSのトリックで泥沼にはまらないように、Getting Realのプロセスの中の主要なアイディアや哲学を中心にご紹介いたします。

この本のターゲットは?

この本を手にとって読んでいるのは、大きなアイディアに興味を持ち、取り組んでいる企業家、デザイナー、プログラマー、マーケッターといった人でしょう。

日進月歩のソフトウェアの世界では、従来のルールに限界が見えます。毎年CD-ROMでソフトウェアを配布しますか?その結果、2002年のバージョンが世の中にどれくらい残っているかわかるでしょうか?もう役に立たないものについては考えないでいいようにしましょう。ソフトウェアに必要なものは、アイデ���アをつくり、アプリケーションを作成し、修正をしていくことです。そして、それまでの反省をし、同じサイクルを繰り返すことです。

あるいはアジャイルな開発方法やビジネスの構造を確立させていないが、真剣にそうしたものを勉強したいという人も読んでいることでしょう。

あなたがこういった人にあてはまるようでしたら、この本はまさにあなたにとって読む価値のあるものです。

_注意_: この本は主にウェブ・アプリケーション構築を目的とした内容ですが、この本の多くのアイディアは、ソフトウェア開発以外にも活かすことができます。小さなチーム・組織の概念や、迅速なプロトタイピング、繰り返しの予測…といった多くのアイディアが、起業・執筆・ウェブデザイン・音楽活動といった数多くのクリエイティブな活動に役立つものでしょう。Getting Realは、決してIT分野の一部にのみ適応されるものでなく、一度理解すれば、人生の様々な場面でそのコンセプトを応用することができます。



37signalについて

何者?

37signalsは、シンプルで的を絞ったソフトウェアを開発している小さなチームです。 製品は、主にグループのプロジェクトや組織管理等に役立つものを提供しており、500,000以上の個人・中小企業のプロジェクト・タスク管理(GTD)に我々のウェブ・アプリケーションが使われています。「ウォール・ストリート・ジャーナル」のジェレミー・ワグスタッフ氏からは、「37signalsの製品は、美しくエレガントで直感的に使えるシンプルなツール。Outlookが拷問の様に見えるようだ。」との評価もいただいています。我々の製品であれば貴方を拷問にかけるようなことはありません。

我々のコンセプト

我々は、現在のソフトウェアはあまりに複雑だと思っております。あまりに多くの特徴・多くのボタン・複雑な操作方法…我々の製品は—あえて—、競合製品より機能を落としています。「仕事をよりスマートに、よりよく、自分のスタイルで行え、簡単に扱える」そう、コンセプトはそこにあります。

我々の製品

この本の出版時点で、5つの製品と1つのオープンソースのウェブ・アプリケーションがあります。

Basecamp(ベースキャンプ) プロジェクト管理用のアプリケーションです。 ガントチャート(工場などでの管理用グラフ)や、派手なグラフ、くそ重いスプレッド・シートの代わりに、Basecampでは、メッセージ・ボード、ToDoリスト、シンプルなスケジュール表、Wiki、ファイル共有といった、新たなツールを使ったプロジェクト管理が行えます。 これまで、何千何百と言う個人・企業がこの製品を高く評価しています。 Salon.comのファーハド・マンジュー氏からは、「Basecampは、ウェブにおけるソフトウェアの未来形だ」との言葉もいただいています。

Campfire(キャンプファイヤー) シンプルなビジネス用グループ・チャット・ツールです。 日本ではまだなじみが薄いですが、アメリカでは、リアルタイムのコミュニケーション・ツールであるグループ・チャットの重要性が認められ、導入している企業も増えています。 従来の1対1の迅速なインスタント・メッセージでのやり取りもよいですが、3人以上の複数になった場合使いづらくなります。Campfireはこうした多人数向けのチャットに特化したソフトウェアです。

Backpack(バックパック) 個人向けタスク管理アプリケーションです。日々複雑になる個人のタスク・プロジェクト・仕事を「シンプルな25のステップで人生を組織化」を合言葉に改善するツールです。 Backpackのシンプルなページ、ノート、ToDoリスト、ケータイ/メールへのリマインダー機能は、ミスや漏れの多かったこれまでのアナログ・タスク管理に一筋の光を与えることができるでしょう。 「ウォール・ストリート・ジャーナル」のトーマスー・ウェーバー氏からは、『タスク管理ソフトでは、一番のもの』、「ニューヨーク・タイムス・タイムス」のデヴィッド・ボーグ氏からは、『「非常にクールな」組織管理ツール』とのコメントをいただきました。

Writeboard(ライトボード) テキスト管理アプリケーション。テキストを記述、共有、改訂、複数テキストの比較できます。これまでの煩雑なワープロ(95%はオーバーキル)に代わる新しい文章作成ツールです。 「ダーリン・ファイヤーボール」のジョン・グルーバー氏からは、「Writeboardは、今まで見た中で一番わかりやすく、シンプルなウェブ・アプリケーションである」、またウェブの伝道師として知られるジェフリー・ゼードマン氏からは、「37signalsは又やった!」 とのコメントをいただきました。

Ta-da List(タダーリスト) To-Doリスト整理・オンライン管理アプリケーションです。 リストは個人用、または共用として他の人に自分のタスク・予定を知らせることもできます。タスク管理にGTDほど簡単な方法はありません。 すでに200,000以上のリストと2,000,000近いアイテムが作られています。

Ruby on Rails(ルービー・オン・レイルス) 開発者向けフルスタック・オープンソースのウェブ・フレームワークです。 Rubyを使って、実際のアプリケーションを早く・簡単に作成していくツールで、あなたが良いアイディアに専念できるよう、忙しい仕事のサポートをします。 『Ruby on Railsは、驚くべきものです。これは、例えるならばカンフー映画鑑賞です。例えるなら1ダースのワルいフレームワークが、小さな新参者を痛めつけようとしていたのが、様々な創造的な方法に反対にぶちのめされたようなものです。」と、オライリー出版のネイサン・トーキングトン氏がコメントしています。

製品・そして弊社の詳細については下記ウェブサイトまで:

  • 37signals.com


  • Getting Realは本当に使えるの?

    Getting Realについて、いくつかの疑問や不満を受け取っております。本文に入る前にいくつかそれらについてお答えしましょう。

    「このテクニックは私たちに向いていない」

    Getting Realは元々、37signalsの組織にジャストフィットしたシステムとして開発されていますが、決して全ての組織・全てのプロジェクトに適用されるものではありません。もしあなたが、武器システム・核コントロールのプラント、何百万人の顧客向けの銀行システムといった、生活やファイナンスの重要なシステムを構築する場合は、我々の放任主義的な姿勢に尻込みするでしょう。しかし思い切ってやってみましょう。それから必要な対策を講じればいいのです。

    またGettig Realは、全て適用するか否か、というものでもありません。たとえあなたがGetting Realを完全に受け入れられないとしても、そのいくつかのアイディアを手にすることができるはずです。

    「本当にオリジナルなアイディア?」

    我々は、決してこれらの技術を発明したとは言っておりません。我々のコンセプトの多くは、昔からまわりにあるようなものです。我々の述べている内容が、昔どこかのブログで読んだようなもの、または20年前の本で読んだようなものだと思っても、怒らないでください。反対に大いに有りうることです。これらの技術は、全て37signalsオリジナルのものではありません。我々が仕事をどのように改善し、成功に導いたかという点です。

    「あまりに白黒はっきりしすぎた話じゃないか?」

    我々のトーンがえらそうに聞こえるのなら、申し訳ありませんがもう少し我慢して下さい。我々は、お茶を濁すような表現よりはっきりとした表現のほうがよいと思っております。それが、生意気で横柄に見えるなら、それでもかまいません。「それはケース・バイ・ケース」とあいまいにするよりも、多少挑発的でもその方がよいということです。 もちろん、我々のルールを拡張したり崩したりする必要がある場合があるでしょう。そしていくつかの戦略が使えなくなることもあるでしょう。そ���あたりのご判断とご想像はお任せいたします。

    「うちの会社の中では使えないよ」

    御社はGetting Realではカバーできないほどの大企業ということでしょうか?アメリカの大企業マイクロソフトでもGetting Realを採用していますし、グーグルでさえいくつかの原理を応用しています。

    御社が大きなチーム・長期スケジュールで通常動くことになっていても、Getting Real導入の余地はまだあります。まずは、大きな単位を小さな単位に分解することです。あまりに多くの人が関わる場合、実際には何もできないことが多いのです。小さければ小さいほど、迅速でよりよい業務が遂行されるのです。

    加えて、Getting Realはある種の売り込みも必要でしょう。Getting Realの本を見せてあげてください。彼らに短い時間でより小さなチームを作れる結果を見せてください。

    Getting Realは新しいコンセプトをテストする低リスク・低投資の方法であることを彼らに説明してください。その証拠に、大きな母艦から小さなプロジェクトを切り取れるかどうかやって見てください。結果で証明してみては?

    もしくは、大胆に行きたいのなら、ステルス機のようにこっそりと進みましょう。レーダーに引っかからないように真の結果を出しましょう。これが、「Start.com」のチームがマイクロソフトでGetting Realを導入したアプローチ方です。「私は、Start.comのチームワークを見ていました。彼らはいちいち上に許可を得ようとしません。」とマイクロソフトのTEロバート・スコブル氏の談。「彼らには支援攻撃をしてくれる上司がいます。そして彼らは、一度に少しだけかじり取ってきて、それを実行し、フィードバックに対応をするのです。」

    マイクロソフトの"Start.com"導入例

    大企業では、プロセスとミーティングは当たり前のことです。何が顧客にとって「よい」ものなのかという共通のゴールに向かって、プラン立案と細かな議論が何ヶ月もかかります。

    そうした状況で、小さくまとまったソフトウェアはよいアプローチですが、ウェブの利用によって我々が想像以上の利点が転がります。導入してください!それが正しいことだったのかどうか、ユーザーの意見を聞きましょう。ほら、あなたがやりたいことがその日のうちに、立ち上げられ実行されるのです!ユーザーの声に勝るものはありません。くどいミーティングと議論を重ねる以上によい結果が得られるでしょう。物は試しです。

    言うは易し、行うは難し - これに尽きる。

    計画の数ヶ月は必要ない
    スペックを記述する数ヶ月は必要ありません。スペックは基礎の部分で、詳細な部分は開発段階で見つけ、改善されるべきだという姿勢です。開発のスタート前に未解決の問題を全て解決しようとせず、全ての詳細を洗い出そうとしなくても大丈夫です。

    少ない機能、しかし質の高い機能で。
    多くの機能を携えた完全リニューアルでの壮大なアプローチは必要ありません。ユーザーが消化できる小規模が一番です。

    小さなバグがあれば、徐々にバグ修正を行うのです。ユーザーのフィードバックが早いほど、結果はよくなります。アイディアは、紙の上ではよくても、実際にはそうでないこともあります。根本的な問題の原因が解ればすぐ対処しましょう。

    一度、プロセスを迅速化し、ユーザーのフィードバックに対応すると、ユーザーとの関係が構築されます。思い出してください、ゴールはユーザーが自分たちの行いたいことを行えるというところです。

    —サナズ。アハーリ, 「スタート・ドット・コム」 「マイクロソフト」プログラム・マネージャー,


    出発点chapter 2

    シンプルに構築する

    無駄に争わない

    従来の常識では、競争相手に勝つためには、相手の1枚上を行かなければならないと言われています。相手の製品に売りのポイントが4あるなら、こちらは5(または10、15…)の売りのポイントをつけないといけない。相手がx円費やしたのなら、こちらはxx円費やさないといけない。相手が20持っているのなら、こちらは30持たなければならない。

    こうした機能追加型の冷戦的発想は無駄です。こうしたやり方は、製品を作るうえでもコストがかかり、防御的で、妄想の入ったものです。防御的企業は、先を見据えたアイディアを生み出しません。後ろしか見なくなるのです。彼らは決してイニシアティブをとることはなく、いつも誰かのマネをするだけです。

    もし、そうした猿マネ企業を作りたいのであれば、この本は必要ないでしょう。

    では、これからのやり方とは?答えは「less(より少なく)」です。競争相手よりもより少ないことを行って、相手に勝つのです。簡単な問題に取り掛かり、難しくてややこしい問題は、他の皆に残しましょう。1つ機能を追加するのではなく、1つ機能を減らしてみてください。機能を上げようとするのではなく、無駄を省くだけでいいのです。

    この本を通じて、私たちはこの「より少ない」の概念を紹介しています。その前に、初めての方向けに、何が「より少ない」のか説明しておきましょう。



    問題を見つける

    自分でソフトウェアを構築する

    ソフトウェア構築に一番よい方法は、自分自身の問題を解決しようとするところからです。あなた自身がソフトウェアの完璧なターゲットとなることで、何が大切で何がそうでないかわかるでしょう。そこから、常識の壁を突き破る製品のスタートがきれるでしょう。

    ここでキーになるのは、あなたは一人ではないということです。つまり、あなたが問題に当たっても、同じ問題にぶち当たっているあなたのような人が何百何千といるかもしれないということです。そこはあなたのマーケット。簡単じゃないですか?

    弊社製品であるBasecampは、1つの問題から生まれました。デザインに携わる会社として、我々は、プロジェクトをクライアントと簡単にコミュニケーションする方法が必要でした。我々は、手動でアップデートできそうなクライアントのネットワークを使ってその方法を始めました。しかし、毎回HTML更新だと、アップデートの必要な作業はスムーズにいきません。これらのプロジェクト・サイトは、リアルタイムでうまくいかなかったため、結局やめることになりました。仕事をスムーズにするはずのアイディアが結果的に逆効果となり、クライアントにも迷惑をかけてしまったこともありました。

    そこで、我々は他の道を模索し始めました。しかし、我々のまわりにあるツールは、_必要としているものでない_、もしくは_必要ない機能だらけ_…例えば広告や、厳しいアクセス・コントロール、チャート、グラフなど… 結局自分たちで作るのがいいのだろう、という結論にいたりました。

    あなたが自身の問題を解決するとき、あなたが本気になるツールを作ります。やる気・情熱はキーワードです。情熱とはつまり、あなたが本当に使いたい、本当によくしていきたい、と思うことです。そして、同様に他の人にも情熱を与える方法になります。

    かゆいところに手が届く

    新しいアプリケーションのデザイナー・開発者として、我々は毎日小さな決断を幾度と無く繰りかえします。緑なのか青なのか?1つか2つか?静的なのか動的なのか?止めるか修復するか?などなど これらの決断をどうすればよいか?もし重要な決断ならば人を尋ねるかもしれないが、残りは自分で予想しなければならない。こうした自分の決断や予想がアプリケーションの一部となります。

    開発者として、私は���ういうことはイヤです。ソフトウェアに私が刻むこうした小さなレベルの時限爆弾がストレスになるのです。「かゆいところに手が届く」オープンソースの開発者の場合、こうしたストレスに悩みません。彼らは自身がすでにユーザーのため、自分たちの決定の90%に正確な答えを見出すことができるからです。そして、会社でコード打ちのしんどい仕事をしながらも、家に帰りオープンソースのプロジェクトに参加できるのです。そうしてリラックスするのです。

    —デーブ・トーマス, 「プラグマティック・プログラマー」

    必要は発明の母

    Campaign Monitorsのソフトウェアは、正に必要から生まれました。長年、我々はEメールのマーケティングの質について、いろいろと悩んでいました。あるツールはxとyができるが、zはできない。また別のツールは、yとzができるが、xはできない。どれもどこかが合わず、我々は満足に欠けていた。

    我々は、スケジュールに時間をつくり、理想のEメール・マーケティングのツールを作ることにした。我々はあえて皆が使っているようなツールではなく、我々と我々の顧客がより便利になるようなツールを作ることに決めた。

    その後、今までのものに問題を感じていたのは我々の他にも沢山いることがわかった。我々は、デザイン会社が使え、口コミが広がるよう、ソフトウェアに少々修正を加えた。すると6ヵ月後もたたないうちに、何千ものデザイナーが自社、クライアント用のEメール・ニュースレター送信用にCampain Monitorsを使うようになった。

    —デイビッド・グレイナー、「Campaign Monitor」創始者

    注意を払う必要

    本を書くときには、「面白いお話」以上のものが頭にある必要があります。物語を伝えようという意思が求められているのです。いくらかの努力が求められるでしょう。もし、あなたが二年間、三年間、あるいは生涯にわたって時間をつぎ込むなら、そういった事に気を使う必要があるのです。

    —マルコム・グラドウェル、文章家(The Tipping Pointの著者。A Few Thin Slices of Malcolm Gladwell参照)


    自分たちでやっていく

    資金のかき集めは必要?

    多くの立ち上げの際の最優先事項は、投資家からの資金集めです。しかし覚えておいてください、外部から資金を頼る場合、彼らの声に応えることも必要です。期待は高まります。投資家は自分たちのお金が_早く_返ってきてほしいと願います。悲しいことに、こうした彼らの声が、製品の質の生命線になることもあるのです。

    最近では、お金をうまく回すのにそう多くは要しません。ハードウェアは安価で、インフラ部分のソフトウェアの多くがオープンソースで無料です。そして何より情熱・気持ちは、お金には変えられないものです。

    だから、自分の手の中にあるお金でできることを始めましょう。よく考えて、何が根本的な部分で、何がいらないのか決めましょう。10人集めてやることよりも、3人集まれば何ができるかを考えましょう。100万円かけず、1万円あれば何ができるかを考えましょう。6ヶ月かけず、3ヶ月で何ができるかを考えましょう。仕事をやりながらも、本当に作りたいアプリケーションを自由時間で作るには、どうすればよいでしょうか?

    限界から創造は生まれる

    限りある資源でプロジェクトを始めた場合、より早い段階により厳しい限界の壁にぶち当たるでしょう。そしてそれがチャンスです。限界はイノベーションに転化します。

    限界によって、あなたはより早い段階でアイディアを出すことになります。これがもう1つの利点です。スタートから1~2ヵ月後、あなたはそのアイディアでうまくやっていけるかどうかが分かるはずです。もし、いけそうならば、外からお金を集めなくとも、自分で続けていくことができます。ただアイディアがいまひとつなら、振り出しにもどりましょう。少なくとも数ヵ月後(数年後)ではなく今、方向転換ができ、簡単に手を引くことができます。投資家がいったん加わると、見限ったプロジェクトもなかなか手が引けなくなります。

    もし、目先の利益のためにソフトウェアを作ると、作品自体にそれは現れます。すぐリターンが戻ってくることなど、そうそうないのが真実です。なので、あなた、そしてあなたのクライアントが長い間受け入れられる質の高いツールを作ることが重要です。

    2つの道

    [ジェイク・ウォーカーは投資家からの資金で会社「Disclive」を興した。そして、自分たちの資金でもう1つの会社「The Show」)を。ここで、彼は彼の興した2つの会社について、その違いを述べている。]

    問題の根本は全て、資金繰りそのものではなく、その金についてくるもろもろのものにありました。期待は高いことです。人々は給料を取り始め、製品を作って売る、また投資家に金を還元する方法を探ることがモチベーションとなります。必要上、1つ目の会社の場合、我々の目的は会社を大きく見せることでした。

    では後者の会社の方はどうだったか。我々はより少ないコストでも時間をかければ、はるかにすばらしい製品を作れるのではないかと気づきました。そして、我々は人々がスピード以上に質を求めているだろうと賭け、そこに我々の少ない金を賭けてみることにしました。そして会社は未だ小規模です(この姿勢は今後も続けていくでしょう)。そして、その最初のプロジェクト以来、我々は自分たちで資金をやりくりしてきました。すこしの売主からのクリエイティブな条件だけで、我々は自分たちの活動を自分たちの資金でやってくることができました。そして、会社を大きくして儲けを出そうという方向ではなく、成長のための成長、そしてそこから財務的に利益ができるような形が出来上がればという方向に向かい始めました。

    "Signal vs. Noise"からのコメント


    時間と予算を定め、範囲は柔軟に

    時間通り、予算どおりに始める

    時間通り、予算どおりにはじめる簡単な方法を1つ紹介しましょう。一度決めたらそれらの数字をいじらないこと。問題に当たっても、そこでさらに時間やお金をかけるようせず、範囲を縮小します。

    このように進むたとえ話があります。決められた目的で時間通り、予算どおりにスタートすることができます。このようなことはほとんど起きません。質が落ちるだけです。

    もし、決められた時間と予算の中で、すべてをうまくできなくても、絶対に時間とお金の枠を広げてはいけません。代わりに、範囲を縮小。付け足しは後からでも間に合います。今という時を大切に。

    計画よりも小さなものでスタートするとしても、穴だらけの安物を作るよりもすばらしい結果がでるはずです。これは、現実感のない時間や、予算、範囲の枠にぶち当たるからです。そんな魔法はマジシャンのフーディーニに譲りましょう。あなたがするのは、現実の世界でのビジネス、実現できる製品をつくることなのです。

    時間の予算を固定し、柔軟な範囲を保つことでどんなことがおこるでしょう。以下を見てみましょう:

    我々のアドバ���スは、「範囲をあえて小さくする」ということです。それは、たとえ完璧に出来上がっていない製品でも、悪質な製品よりはよいでしょう(後の章で詳しく説明します)。

    1,2,3…

    プロジェクトがどのように予定より1年遅れてしまうのか?一日ごとに。

    —フレッド・ブルックスソフトウェア・エンジニア、コンピュータ研究者


    ライバルを持つ

    ケンカを売る

    あなたのアプリケーションがどうあるべきか考える上で、最適であろう方法の1つに「何がいらないか」を知ることです。あなたのアプリケーションでの邪魔者を理解することで、どの方向へ行くべきかの道しるべが見えるでしょう。

    我々がプロジェクト管理ソフトウェアの構築を決めたとき、真っ先に意識したのがMicrosoft Projectでした。このゴリラのようなソフトウェアを恐れるのではなく、モチベーションに使おうと我々は考えました。そのため、我々は、"BaseCamp"のソフトウェアを完全に逆のプロジェクトとして考えることにしました。

    プロジェクト管理の主軸は、チャートでもグラフでもレポートでも統計でもなく、*コミュニケーション*ということです。それはプロジェクト・マネージャーが高座にふんぞりかえり、一方的に計画案を伝えるものではなく、メンバー全員がプロジェクトの仕事を同じ土俵、同じレベルの責任で行うこと、ということです。

    我々の敵は、プロジェクト管理における独裁者とその鞭です。我々は、プロジェクト管理に民主化を起こしたかったのです。(クライアントも含めた)メンバー全員が等しく参加できるプロジェクトをです。プロジェクトは、皆が共同の所有権を取るときに初めて、よい結果になるのです。

    "WriteBoard"の時も、我々は競合相手がちょうどドーンと目立つ特徴に力を入れていたことを知っていました。そこで、我々は逆に「ジミ」の視点に力を入れようと決めました。我々は人々がどうでもいいような特徴にハマってしまわないように、シンプルにアイディアを共有できるようなアプリケーションを開発しました。不要なものは取り除く。そして、スタートからわずか3ヶ月で、WriteBoardのサービス利用者は100,000を越えました。

    "Backpack"のプロジェクトの際は、我々の敵は、ガチガチの構造と鉄則でした。ユーザーは、自分たちの情報を自分たちのやり方で、自由に整理することができるはずです。

    敵を想定することのメリットの1つは、非常にはっきりとしたマーケティング上のメッセージを持てることです。人は衝突によって火がつくものです。そして、人は他と比べることで、商品を理解するのです。ライバルあるがこそ、あなたは人々に彼等が聴きたい話をできるのです。彼らはあなたの商品についてより早くよりよく理解するだけでなく、味方にもついてくれるでしょう。そして、それが人々の注意を惹き、心に火をつける確実な方法なのです。

    もう1つ大切なのが、逆にあまりに競争を意識しすぎるとかえってよい結果にならないことも覚えておきましょう。他社の製品を分析しすぎるがあまり、自分たちの考えが狭まってしまうことはよくあることです。周りを見回した上で、あなた自身の視点と自身の考えを持って進みましょう。

    先駆者の猿真似をしない

    マーケティングの人間(人間全てに当てはまることでもあるが…)は、その道の先駆者についていくよう教育されます。人間、何が競争のメイン・ポイントかを理解し、例えば、その道のパイオニア企業が安さをウリにしてきたら、うちはよりリーズナブルな値段で勝負する、彼らがスピードを武器にしてきたら、うちはより迅速に…といったように、同じ土俵で競争に勝とうとするのは自然な流れでしょう。しかし、問題は、顧客が一度誰からの話を聞いて、彼らのウソを信じてしまった場合、異なる商品・新たな商品の紹介を受けるときに、彼らは今まで自分の考えが全て否定されたように感じます。悲しいかな、人は自分の間違いを指摘されるのを嫌がります。

    そのため、あなたは全然違う話をして、あなたの話が彼らが今信じている話よりも重要であると聞く手を説得させることが必要になります。競合相手が迅速なサービスの話をしてきたなら、あなたは価格の安さで勝負すべきです。そして彼らが製品の健康の部分をプッシュしてきたなら、あなたは商品の便利な部分で勝負すべきです。「うちの方が安い」といった、同じ土俵の上での優越の話をするのではなく、競合他社がまだ話をしていない、異なった支店からのアプローチが重要なのです。

    セス・ゴーディン, 「マーケティングは「嘘」を語れ!(ダイヤモンド社)」作者・企業家

    何が根本の問題か

    トラブルに足を突っ込む一番手っ取り早い方法は、競合他社がなにをやっているのか見ることです。これは、特に我々のサービス「BlinkList」で身をもって体験しました。 我々がサービスを始めたとき、すでに10のソーシャル・ブックマークのサービスがありました。詳細な特徴比較をオンラインで出す人も出始めました。

    しかし、こんな目先の競争で頭がいっぱいの状況では道を誤りかねません。そこで、私たちは常に大きなビジョンを持ち、常に自分たちに問いかけてきました。「何が私たちが解決すべき問題なのか、その問題をどう解決していくのか?」と。

    —マイケル・レイニング、「MindValley」「Blinklist」共同創始者


    仕事を楽しむ

    あなたの情熱と渇望が光り輝く

    アプリケーション構築はイヤイヤ行ってはいいものはできません。プロセスを楽しむためにも管理できる小さな規模のままでやりましょう。

    もしあなたのアプリケーションに面白みが無いとしたら、何か問題があります。もしあなたが単に金のために仕事をしているのであれば、それは形に表れます。同様に、あなたが自分のアプリケーションに情熱や思い入れがあると、それらは完成品の中に現れます。人々は、文脈を読むことができるのです。

    情熱の有無

    意味がものすごく主観的で、本当に意味不明なこともあるデザインでは、情熱の存在がよりはっきりと浮かび上がります。これは製品のデザインに興味を持っても、ドン引きしても本当のことでしょう。どちらの場合でも、それを作った手からあふれる情熱を感じ取ることができるはずです。

    熱意はもちろん簡単に表れますが、愛情の無さも同様に消すことができません。自分たちの手で行う仕事に本物の情熱を取り込まずにプロジェクトを進めれば、それがどれだけ入念に、魅力的にデザインされても、隠せないほどの割れ目が見えてしまいます。

    —コイ・ヴィン、「Subtraction.com」

    パン屋さん

    今のアメリカのビジネスは正に、アイディアを広げ、それを金儲けにつなげ、それが金になって、ビジネス展開できる間は売る、と集約されます。全てを吸い上げてしまう発想です。私のアイディアはこうです。パンを楽しく焼きましょう。パンを売りましょう。人々がそれを気に入ってくれたら、もっと売りましょう。あなたがよい食べ物を作って、人々が幸せになる。そんなベーカリーを続けていきましょう。

    —イアン・マッケイ、「Fugazi」メンバー、「Dischord Records」共同経営者
    ("Salon.com People | Ian MacKaye"より)


    ムダを省くchapter 3

    「より小さな」規模

    ムダがないほど変化しやすい

    物事が大きければ大きいほど、その方向を変えるのに莫大なエネルギーが必要になります。物理の世界だけでなく、これはビジネスの世界にも言えることです。

    それがウェブ・テクノロジーの話になると、変化はより簡単に、より安価に行えます���もし変化のスピードについていけなくなると、自分たちの仕事をよそに持っていかれる心配があります。そこが、我々が小さな規模を提案する理由なのです。

    規模が大きくなる要素は...

    逆に、規模を小さくする要素はというと…

    小さな規模で、あなたは迅速に舵を変えることができます。周りに敏感に反応し、進化するのです。よいアイディアを採用し、悪いものは落とすことができます。顧客の声に耳を傾け、返事することができます。新しい技術を後回しにせず、今取り入れることができるのです。航空母艦ではなく、高速船で行きましょう。そしてそれを満足に思うことです。

    例えば、より少ないソフトウェアをより少ない機能で提供しているムダのない小規模の会社を想像してみましょう。一方、多くの機能を揃えた多くのソフトウェアを販売している大企業も想像してみましょう。そして、例えばAjaxのような新しい技術、新しいコンセプトのものが登場するとどうなるでしょう。どちらがより迅速に製品に導入可能ですか?後者の大規模な商品展開と1年越しのスケジュールで動く大企業と、「今、我々が注目すべきことに注目しよう」という小規模でより有機的な組織、どちらだと思います?

    勿論小規模の企業のほうが、市場の本当のニーズに敏感に反応できる環境にあるのは明らかです。小さな会社が方向転換した後でも、大規模の会社は舵を変えるかどうか議論し続けたり、いつ戻ってくるかわからない上部からのレスポンスを待つ…ということになるでしょう。大企業がどう歩いていこうとしている最中、小規模の会社は、その2歩も3歩も前に出ることができるのです。

    スピーディーな小さな規模のビジネスは、ビジネスモデル、製品、特色、マーケットのメッセージといったもの全てを素早く変えることができます。間違いがあっても素早く修正できるのです。その他、優先順位や製品の組み合わせ、注目点なども変えることができます。そして最も重要なのが、自分たちの気持ち自体も変えることができるのです.



    変化のコストをおさえる

    変化の障害を取り除き、柔軟に

    変革は貴方にとって最良の友です。とはいっても、変化にコストがかかるほど、あなたがそれを成し遂げづらくなります。そして、競争相手がより早い段階で変化の行動をおこせば、あなたは非常に不利な立場に置かれます。あまりに高価な変革、それは死を意味します。

    ここに前述のムダを省いたメソッドが真価を発揮します。10セントで変化を成し遂げる能力は、小さなチームが元来備えているもので、大きな組織では無理なことです。大きい奴が小さい奴等を妬む状況です。巨大組織の大きなチームが何週間もかかる変化が、ムダのない小さな組織では、わずか1日で可能です。この長所に値段は付けられません。低コストで迅速な変化が隠し兵器なのです。

    覚えておいてください:小さな規模だからできる迅速なスピードは、世界中の全ての金やマーケティング、人間を駆使しても買うことはできません。

    そしてウェブのテクノロジーにおいては、変革は簡単で安くなければいけません。もし変化のスピードについていけなくなると、仕事をよそに持っていかれてしまうでしょう。そこが、我々が小さな規模を提案する理由なのです。

    創発性

    創発性は、迅速性を形作る原則の1つで、その偶然性は真のマジックに一番近いものです。創発的事態はあらかじめ予期できません。というのも、それは単にシステムの残りの動作から起る結果なのです。「創発性(Emergence)」は元々17世紀のラテン語を語源とし、「思いもしなかった出来事」という意味です。予期はできませんが、創発的に起きたことをプラスの方向へ持っていく環境を作ることは可能です。

    創発性の典型的な例が、鳥の群れの行動です。コンピューターのシミュレーションは最小3つのルールを(「互いに衝突しないような」ラインに沿って)使用するのですが、群れが空を優雅に飛び回るように、突然障害の周りで非常に複雑な行動をとりはじめます。こうした複雑な行動(障害に同じように反応するような)は、ルールで定められません。それは、システムの動作から現れるのです。

    鳥のシミュレーションのように、簡単なルールは複雑な行動につながります。複雑なルールは、ちょうど多くの国の税法のように愚かな行動につながるのです。

    不幸なことに、多くのソフトウェア開発では、不測の事態への機会を取り除いています。非常にきつく縛り付ける…といった効率な対処の仕方では、せっかくの相互作用や相互関係のチャンスの範囲を狭めてしまいます。それが突発性の源だと言うのに…鳥の群れの様に、よく設計されたシステムにより、興味深い行動を作り出す相互作用や相互関係は無視してはいけないものです。

    物事を縛り付けると、予期せぬ出来事への解決するクリエイティブな余地は少なくなります。要望が熟考されたのか深く考えられずに効率化したのか、またはエンドユーザーがシステムを触る前に複雑なナビゲーションやワークフローのシナリオがあったかどうかに関わらず、結果は同じです:予期せぬ出来事を利用したレベルの高いシステムではなく、とても複雑で愚かなシステムになるのです。

    小さく、シンプルに、予期せぬことも受け入れる。

    —アンドリュー・ハント、「The Pragmatic Programmers」


    三銃士

    バージョン1.0は3人のチームで

    アプリケーションの最初のバージョンは3人だけで始めます。それがあなたに十分な人手を与えつつも、能率的にアジャイルであり続けるのを許してくれる魔法の数字です。開発者とデザイナーとスウィーパー(二つの世界の間を歩き回ることができる人)で。

    少人数だけでアプリケーションを構築するのは明らかに挑戦です。しかし正しいチームを持っていたとしたら、それは挑戦するのに値するものです。 能力のある人には際限のないリソースは必要ありません。その人たちは抑制がある中で働くことを生きがいにし、問題を解決するために創造性を活かします。人手が足りないということはプロセスの初期においてトレードオフをしなくてはいけないことを意味していますが、問題はありません。それはあなたにプライオリティーを後ではなく先に考え出させるようにします。そしてあなたは定期的に仲間の心配をすること無くコミュニケーションができるようになります。

    もしあなたが3人でバージョン1.0を構築することができなければ、他の人たちが必要か、最初のバージョンの規模を縮小しなければいけないかのどちらかです。覚えておいてください、最初のバージョンは小さく、タイトでも構わないのです。あなたのアイディアに翼があるかどうかはすぐに分かります。そうしたら、構築を行うのに綺麗な、シンプルな基礎を手にできます。

    メトカーフの法則とプロジェクトチーム

    チームは可能な限り小さく保ちなさい。メトカーフの法則、『コミュニケーションシステムの価値はそのシステムのユーザー数の約二乗で増加する』はプロジェクトチームにおいてもそうです。 チームの効率性はチーム内のメンバーの数の約二乗に反比例します。私は1.0の製品のリリー���には3名が最適だと考え始めています・・・あなたがチームに加えようとした人々の数を減らすことから始めなさい。それからさらに何人か減らします。

    —マーク ヘッドランド, 企業家 オ'ライリー

    コミニュケーションの流れ

    コミニュケーションは小さなチームにおいては大きなチームよりもっと簡単に行き渡ります。もしあなたがプロジェクトにおける唯一の人だとしたら、コミニュケーションは単純です。唯一のコミニュケーションの経路はあなたと顧客の間にあります。プロジェクトに関わる人の数が増えるにつれ、コミニュケーションの経路も増えます。それは人の数が増えるに従って、加算されていくのではありません。人の数の二乗に比例して倍に増えていきます。

    —スティーブ・マッコネル、「Construx Software Builders Inc.」チーフ・ソフトウェア・エンジニア
    ("Less is More: Jumpstarting Productivity with Small Teams"より)


    制限を受け入れる

    制限をクリエイティブな解決策に

    世の中にあるものは決して十分ではありません。時間もお金も人も、満たないものです。

    そのことを悲観してはいけません。

    こうした制限に嘆いたり怒ったりしてもしかたありません。受け入れましょう。「なすがまま」も1つの考え方です。制限を受けることで、インノベーションが導かれ、また自らの戦略にはっきりと焦点が定まるのです。制限を取り除くのではなく、どのように武器にするのかを考えましょう。

    弊社37signalsの「Basecamp」ケースでも、多くの制限がありました。例えば下記のものです:

    我々は、「十分じゃない」とぼやいていました。そこで、考えたことが我々の器を小さいままにすることでした。小さな器では入れられる量も決まっています。我々は大きなタスクを細かな単位に分解し、1度に1つずつ取り組みました。徐々に段階を経て、自分たちの今行っていることを最優先したのです。

    それにより、クリエイティブな解決策を思いつかなければなりませんでした。ソフトウェアを普段以上に小さな規模にすることにより、変化にかかるコストを減らしました。ソフトウェアは、人々に自分たちの問題を自分たちの方法で解決するのに十分な特徴を導入し、彼等に任せました。メンバーを隔てる時差と距離の問題から、我々はコミュニケーションをより効率よく行うことができました。人とのミーティングの代わりに、ポイントを素早く伝えなければならないEメールやIMがコミュニケーションの手段となりました。

    制限はしばしば隠し武器になるのです。ベンチャーキャピタルや長いリリース・サイクル、外からの即戦力…そういったものは忘れて、あなたの持っているもので仕事に専念しましょう。

    闘いという病気

    「ゆっくりと優雅に」なんていうと響きはいいが、「機能・特徴を蝕む病気」と言った方がいいだろう。ちょうど、植物の菌のようにむしばんでいき、時間が経てば経つほど製品の真の効用・効果が見えなくなってしまうのです。この病気の特効薬はもちろん「期限の制限」です。これにより、導入への時間がかかるほど、機能・特徴は除かれてくことになります。しばしば最も効果のある機能・特徴が導入まで一番長くかかるケースもあります。したがって、病気の期限の組み合わせにより我々が知っていて好んで使うソフトウェアが誕生します。しかしそんなソフトウェアは、使えない機能だらけですが…

    —ジェフ・ラスキン、作家(「Why Software Is the Way It Is」より)


    ありのままで

    大企業とは違う、人の心を考えた親しみある方法で

    多くの小さな企業は自分たちを大きく見せようと振舞う間違いをする。自分たちの小さな規模を弱点として思っている様です。小さなことは大きな武器なのです。特にコミュニケーションの部分では。

    大企業では行動を起こすのにも、やたらと書類が必要だったり、上司の上司の上司に許可をもらう…なんてことが起こります。小さな会社にはそういったものはありません。もっと自由に行動できるのです。小さな会社は元来より顧客に近い位置にいるのです。 それは、顧客とダイレクトに、個人個人にアプローチできる方法でコミュニケーションができるということです。もし小さな組織なら、小難しい専門用語を使わずにもっと身近な言葉で話ができるのです。あなたのサイトや製品は、企業の心のこもっていない売り文句ではなく、血の通った人間のメッセージを届けることができるのです。小さい規模では、顧客と対等な立場でコミュニケーションができるということなのです。決して上から下へのベクトルではありません。

    外とのコミュニケーションだけではなく、組織内部のコミュニケーションにも、この小さな組織はよいこともあります。申請やら何やらの書類に振り回されず、やたらと複雑なプロセスやあちらこちらでの承認のサインも必要なくなります。どの過程でもメンバー全員がオープンに正直に話せます。アイディアに束縛のない流れは、小さな規模の大きな利点の1つです。

    堂々と正直に

    もしかすると消費者は、企業の従業員数や製品の数、つまり企業の規模を誇張するとだまされてしまうと思うかもしれませんが、賢い人(つまりあなたが本当にターゲットとしたい人)は、いつも真実を知ります。あきれる話ですが、私も過去にこうした自分を大きく見せようとしていた1人です。しかし、そのようなことをしても、ビジネスが意味あるものになり、自分たちのサービスを本当に必要としていた顧客との関係が続き、深い信頼関係が生まれたかというと、全然そんなことはありませんでした。結局、会社の実際の規模が小さくとも恥じることでなく、素直に言えばよいのです。

    —コイ・ヴィン、「Subtraction.com」

    いつでも

    どんなビジネスであれ、よいカスタマーサービスは、どんなクライアントも望む最大の要望です。我々もそれを望むのに、顧客は違うとでも?非常に初期の頃から、我々はあらゆる方法でコンタクトする顧客や、彼らの持っている質問に簡単に、オープンに対応しました。ウェブサイトでは、携帯電話へのフリーダイヤルのリストを載せ、名刺にも携帯電話番号を書いていました。我々が力を入れたのは、顧客がいつどんな問題を抱えてもコンタクトできるようにしたことです。顧客からはこの高いレベルの信頼が評価され、このサービスへのクレームはありません。

    —エドワード・ニッテル、「KennelSource」営業・マーケティング部長


    優先順位chapter 4

    あなたのアイディアとは

    あなたのアプリケーションのポイント

    あなたの作るアプリケーションの視点をはっきりさせましょう。「そのアプリケーションは何ですか?」「それはどんなことができるのですか?」どんなものでも、設計する前、コーディングを始める前に、その製品の目的_-ビジョン-_を知る必要があります。 大きな視点で考えましょう。それは何のために存在しているのか?他の似たようなものと何が違うのか?

    このビジョンは、あなたの判断基準となり、プロジェクトを遂行させる上でのはっきりとした道しるべとなります。いつでも問題に当たったときは、こう尋ねて下さい。_「今、自分はビジョンに沿って行動できているのか?」_

    ビジョンは簡潔に。アイディアを一文で説明できれば���分です。 例えば、我々の製品のビジョンは下の通りです:

    例えば「Basecamp」のケースでは、ビジョンは「プロジェクト管理はコミュニケーション」でした。我々は、プロジェクトにおける効果的なコミュニケーションが責任や連帯感、投資、勢いを結びつけるものだと感じていました。そうしたコミュニケーションによりメンバー全員が共通のゴールに向かっていけます。我々は、「Basecamp」がこのことを達成できるのなら、すべてのことに応用できるのではないかと考えていました。

    このビジョンにより、我々は「Basecamp」を可能な限りオープンで透明性の高いものにしました。会社内の範囲だけでなく、我々はクライアントとのコミュニケーションにもアクセスを広げました。我々は、全てのメンバーの参加の垣根を低くし、サポートするよう考えました。ビジョンは、なぜ我々がチャートや、グラフ、テーブルやレポート、統計、スプレッドシートといったものを省き、代わりにメッセージやコメント、ToDoリスト、ファイルの共有といったコミュニケーション機能を重視したのか、という部分です。ビジョンついて大きな視点での決定をしましょう。そうすれば、これからの小さな判断がはるかに簡単になります。

    ホワイトボード哲学

    アンディー・ハントと私は、一度デビットカード取引ツールを作りました。主なリクエストは、同じ取引でユーザーのアカウントに二重計上されない様しなければならないところです。つまり、どんな失敗があっても、エラーは重複取引を行わないで、むしろ、取引がないことにするべきだということです。

    そのため、我々は共有のホワイトボードに大きく書きました:「エラーの発生はユーザーのため」

    それは、半ダースほどの他のモットーに加えられ、それらは、複雑なものを作り上げる際の微妙な決定を下すガイドとなりました。同時にこれらのルールにより、我々のアプリケーションには強固な内部の調和と外部には安定性がもたらされました。

    —デイブ・トーマス、「The Pragmatic Programmers」

    マントラを作れ

    組織には道しるべが必要だ。大きな枠組みが必要だ。社員は、毎日いつ起きて、なぜ働くのかを知っている必要がある。この道しるべは、簡潔な・耳に残るようなものであるべきだ。そして次のような要素を含めるべきだ。「なぜあなたは存在しているのか?」「あなたのモチベーションの源は何ですか?」 私は、これをスローガン(mantra)と呼びます。あなたの存在意義を問う3~4語の言葉です。

    ガイ・カワサキ、作家(「Make Mantra」より)


    まずは大局から

    大局からディテール(詳細)へ

    我々がこだわる細かな要素

    成功と満足の秘訣はディテール(詳細)にある

    だからといって、ディテールに固執さえすれば物事が成功するわけではない。ディテールにこだわりすぎるあまり、停滞・意見の不一致、度重なるミーティング、そして進行の遅れを巻き起こすことになる。そうしたことでモラルが低下し、成功のチャンスを逃す可能性も出てくる。

    1日の内で1つのデザインやコード要素にこだわりすぎて、ものすごい時間をかけた経験はありますか?今日のタスクが当初の予定に達しなかったという経験はありますか?こうしたことは、大まかなアウトラインが出来上がっていないうちにディテールに固執してしまうことで起きます。完璧主義者になる時間は後に回すこと。

    1週目から見出しのフォントの大きさを気にしなくても大丈夫。2週目から緑の完璧なシェードを作る必要はありません。3週目から「送信」ボタンを3ピクセル右に動かすか否か悩まなくても大丈夫。まずは、今やっていることを一通りやりきる。使ってみて、動作を確認する。調整して完璧にするのはその後で充分です。

    ディテールは自分が作ったものを実際に使ったときに現れます。どこがうまくいかないのか、何が足りないのか。あなたが躓けばどこを補修しなければいけないかわかります。その時が、細部に注意を払う時で、それより前ではありません。。

    ディテールに潜む悪魔

    いくつかの絵画クラスで私は本当に「とりあえずディテールから入る」という態度をやめました。(中略)絵画をディテールから入ってしまうと、うまくいかなくなるのです。絵画のポイントを無視することになるのです。

    まずアプローチするべきところは、場面全体のプロポーションを正しくとるところです。そして、場面で一番大きなものからスタートし、一番小さなものまでスケッチします。この段階では、スケッチは大まかにしておきましょう。その次に、3Dにするために影をつけましょう。ただ、トーンは3パターン(薄い・中ぐらい・濃い)だけでよいです。こうすることで、全体的なスケッチができます。そして、それぞれのトーンをさらに細かく3パターンの影をつけていきましょう。ボリュームが出るまでこれを何回か続けます。

    大きな部分から小さな部分へ。これは常に鉄則です。

    —パトリック・ラフルール、「Creation Objet Inc.」 (「Signal vs. Noise」より)


    問題は、起こったときに対処する

    まだ発生してもいない問題のために時間を費やすな

    ユーザーが10万人に達するのに2年かかると予想されるのに、今日10万人のユーザーを想定する必要があるのだろうか?

    今は3人のプログラマーがいれば事足りるのに、8人を雇う必要があるだろうか?

    今は2台のサーバーでまかなえているのに、12台を準備する意味があるのだろうか?

    とにかく進めよう

    起こってもいない問題の解決方法を考えるために、人は時間を費やしがちです。そんなことに意味があるか! 私達がBasecampを開始したときは、顧客に請求書を送る手はずすら整っていませんでした。しかし1ヶ月サイクルで請求を行うことになっていたので、(サービスが開始してから)30日間の猶予があることはわかっていました。もっと緊急な問題を解決するためにサービス開始までの時間を費やし、私達が請求書の問題に取り組み始めたのはサービス開始後でした。 請求書の発行はうまくいきました(それにこのおかげで、シンプルな解決策をとることができたわけです)。

    やらなくていい時にまで、苦労する必要はありませんし、作りすぎてはいけません。ハードもソフトも、必要になってから増やします。1週間や2週間ゆっくりしたって、別に世界の終りではないでしょう。素直に顧客に説明すればいいのです。生みの苦しみ(growing pains)を味わっている最中だとしてもです。喜ばれはしないだろうが、あなたの率直さは評価してもらえます。

    重要なこと:すぐに決断する時は必要な情報が手に入った時。そうすれば今の緊急事態に専念できます。



    顧客を選ぶ

    アプリケーションのコア市場を見つけ、ターゲットを絞り込む

    顧客がいつも正しいとは限りません。重要なのは、あなたが自らのアプリケーションに合った顧客、合わない顧客を選び出さなければならないということです。幸いなことに、インターネットのおかげで以前に比べてアプリケーションに合った顧客を見つけやすくなりました。

    皆を喜ばせようとすると、誰も喜ばない

    ���Basecamp」を作ったとき、我々はデザイン会社にマーケティングの焦点を合わせました。この様にマーケットを絞り込むことにより、製品を広めてくれるような、本当に製品を愛してくれる顧客にアプローチできるだろうと考えたわけです。あなたの作ったアプリケーションを本当に必要としている人は誰かを知り、彼らに喜んでもらえるように。

    今まで最高の呼びかけ

    「Campaign Monitor」でウェブデザイン市場をはっきりとターゲットにする、これは、これまで我々が行った一番素晴らしい呼びかけだった。そのことにより、どの機能が本当に役に立つか、より重要か、そしてどの機能がいらないかという判断が容易になったのだ。小さな規模の人々をターゲットにして、よりはっきりとしたニーズを汲み取るだけでなく、そうしたターゲットの人々は概して似たようなニーズを持っているため、やりやすい利点もある。「Campaign Monitor」の機能の中でも、ターゲットであるウェブ・デザイナー以外には何の役にも立たない機能が備わっている。

    またコア市場に焦点を絞ることにより、ソフトウェアの普及がより容易になる。顧客を絞り込むことにより、彼らの興味あるオンラインのサイト・オフラインでの場所等に広告を出したり、製品に関するコミュニティを形成することもできる。

    —デヴィッド・グレイナー、「Campaign Monitor」創始者


    規模は後で

    いきなり規模を考えない

    「何百万ものユーザーができたら、私のアプリケーションをどうするか?」

    あなたは、こんな心配をしていますか?取らぬ狸の皮算用。システムに耐えられないほどの膨大な数のユーザーが出てきたときはその時!そんな問題ができるなんて、大したもの。実際、ウェブ・アプリケーションのほとんどが、そのような莫大なユーザーをかかえる段階に達しないのです。たとえそのようなユーザー数の問題が起こり始めても、ゼロか100かの問題ではありません。徐々に調整しながら、その問題に取りかかればよいのです。そして、ソフトの立ち上げ後にリアルな世界のデータ・ベンチマークを多く集める。そうすれば、ターゲットにすべきエリアが理解できるはずです。

    例えば「Basecamp」では、1年目は1つのサーバーで行っていました。それだけ簡単なセットアップだったので、実装にわずか1週間だけでした。スタートから15ものボックスのクラスターを使って、その大きな規模のことで悩むことはありません。

    こうしたスタートで何か問題があったでしょうか?いくつかはありました。しかし、我々が恐れた短いスローダウンのような問題のほとんどは、実際の顧客との取引のレベルでは問題外。ユーザーとの信頼関係を築き、状況に逆らわないでいる以上、彼らは理解してくれます。今から思えば、「完璧な準備」を行うために何ヶ月もスタートを遅らせなかったのは、まったく幸いでした。

    まず始めに、何か具体的な製品を作ることを優先します。拡張やサーバーのファームをあれこれやるのは後回し。すばらしいアプリケーションを作り、それがとりあえず形になってから次に何をしようか考える。そうでなければ、起らないことを心配して、エネルギーや時間、お金を無駄に使うことになります。

    信じる信じないはおいておいて、考えるべき問題は規模そのものではなく、規模を段階に応じて大きくしていくことにあります。第1の問題なくして、第2の問題があるわけないのです。

    どうせ再検討は必要なんだから

    事実、誰もが規模を大きくする上で問題に突き当たる。サービスを0から何百万人のユーザーを抱えるという規模にスケールするには、デザインや構造を根本から見直さなければならないのだ。

    —デアー・オバサンジョ、「マイクロソフト」 (「Scaling Up and Startups」より)


    確固たる意思を持ったソフトウェア

    ソフトウェアに意見を

    ソフトウェアは人為的な調整はいらないと唱える人もいます。彼らが言うには、開発者が機能の制限をかけたり、機能のリクエストを無視したりするのはよくない、と。彼らの言うソフトウェアは、可能な限り柔軟なのです。

    我々は、そうした意見は馬鹿げていると思っています。最高のソフトウェアにはビジョンがあります。最高のソフトウェアには独自の視点があります。ソフトウェアを使うとき、彼らは単に機能そのものを求めていません。彼らは、アプローチを求めているのです。彼らはビジョンを求めているのです。まずビジョンを打ちたて、そのビジョンに基づいたソフトウェアを作るのです。

    そして、このことも覚えておきましょう。あなたのビジョン・価値観に合わない人がいても、周りを見渡せば、他に多くのビジョンがあり、又そういった人達に合ったものあるはずです。あなたが幸せにできない人を追いかける必要はありません。

    ちょうどよい例があるので紹介しましょう。オリジナルのWikiデザインです。ワード・カニンガムと友人達は、過去にドキュメントを共有するのに不可欠だとされた多くの機能をあえて取り除きました。その人その人がオフラインでいちいちドキュメントを作って、人に渡す…という発想から離れ、管理者という概念の多くを取り除いたのです。これにより自己の管理者としての立場にとらわれず、またそれによる時間のロスをカットすることができたのです。カニンガムらは、誰が書いたのか、いつ書いたのかは重要ではないとし、そこから今までにないシステムが生まれたのです。この決定により、コミュニティーの共有の概念が発達し、今日のWikipedia(ウェブ百科事典)の大きな源となったのです。

    我々のアプリケーションは同じような方向性を持っています。それらは決して万人のための万能のものを目指しているのではありません。ポリシーがあり、パートナーとなる顧客へアプローチを行いたいのです。求めているのは、我々のビジョンを共有できる人たちなのです。我々のバスに乗るか、乗らないか、なのです。



    機能選択 chapter 5

    中途半端でない半分

    不完全な製品でなく、半分の製品を作る

    ウェブアプリ開発に対して「何でもかんでも」というやり方には気を付けましょう。舞い込んでくる立派なアイディアをちりばめようものなら、不完全バージョンの中途半端な製品に終わるだけ。本当にしなければならないことは、しっかりした半分の製品を作ることです。

    本当に必要なものにこだわります。良いアイディアはとりあえず並べ、*自分達の製品に必要だと思えるものを選び、そしてそれを半減*。最も不可欠なものだけが残るまで機能を削るのです。そしてそれを繰り返します。

    Basecampでは、連絡機能の部分だけから始めました。私達はそれがBasecampの肝心な部分だと分かっていたので、マイルストーンやTODOリストなど他の項目については当面無視することにしました。このことで、勘ではなく現実世界での利用方法に基づいて以降の決定ができるようになりました。

    スリムで洗練されたアプリから始め、それに牽引力を与えます。そうすれば、自分達でつくり上げた強固な基礎に機能を追加していくことができるようになるのです。



    大した問題でないから

    必需品だけ

    「どうしてコレをしないのか、どうしてアレをしないのか」という質問に対して私達のお気に入りの答えはこうです:「だってどうでもいいんだから。」この答えは何が製品をすばらしくするかを明確に示しています。何が重要なことのかを見極め、それ以外は忘れればいいのです。

    わたしたちがCampfireを世に送り出した時には、初めてこの製品を試した人々から次のような質問をいくつも受けました:

    「どうして時刻表示は5分おきだけなの?どうしてチャットの発言ごとに時刻表示しないの?」
    答え:大した問題でないからです。チャットを秒単位あるいは分単位で追う必要がありますか?95%の場合、その���ベルは必要ないでしょう。5分単位以上に詳しく特定するのは大した問題ではないのですから、このタイムスタンプで十分なのです。

    「どうしてチャットで文字を太字やイタリック体にしたり色付けしたりできないの?」
    答え:大した問題でないからです。もし何かを強調したいなら、頼りあるCaps Lockキーを使ったり、*や’で単語や句を囲めばいいでしょう。こういった解決方法は、ソフトウェアにも技術サポートにも処理能力にも学習曲線にもお世話になりませんよ。それにシンプルなテキストベースのチャットでは、そんな書式こそどうでもいいでしょう。

    「どうしてその時の部屋全員の数を表示しないの?」
    答え:大した問題でないからです。全員の名前はリスト表示されているのですから、誰がいるかは分かりますね。それにしても12人いるのと16人いるのとで何か違いがあるのでしょうか?もしそれでユーザーの行動に違いがないなら、それはどうでもいいことです。

    こういった質問にある機能はあったほうがいいでしょうか?もちろん。ただ必要でしょうか?なければいけない?いいえ。だからこういったものを横に置いているのです。最も優れたデザイナーや最も優れたプログラマーは、スキル、指の速さで一番な人々でなく、フォトショップでロックンロールできるからでもなく、最上の環境を見極められるからでもありません。彼等は、何が問題でないのかを決められる人々なのです。このことが本当の利益を生み出す源泉なのです。

    あなたが費やしたほとんどの時間は重要でないことに費やされています。そんな仕事から抜け出して、こういうのは重要ではないんだと考えるようになれれば、あなたは想像もしたことがないような生産力を手にするでしょう。



    ノーから始める

    実装する機能はタフなやつだけにする

    不完全な製品をつくるのではなく、半分の製品をつくる秘訣は、ノーと言うこと。

    あなたが機能に対してイエスと言うたびに、子供をもらうことになるのです。あなたはその赤ちゃんを全ての出来事(デザイン、実装、テストなど)へ通さなければいけません。そして一度その機能が世に出たらそのまま。リリースされた機能を顧客から奪い取ると、彼らがどのくらい怒るのかお分かりですか?

    イエスマンになるな

    各機能を実装してもらうには?機能自身がその証となるように、そしてそれが選ばれてきたものだということをわかるようにします。映画の『ファイトクラブ』のようなものです。 玄関で3日待っても良いと思われるような機能を考えることに徹すべきです。

    それがあなたがノーから始める理由です。私たち宛にやってくる — または私たちから出た — 全ての新しい機能はノーによってチェックされます。私たちは話は聞きますが、動きません。最初の反応は、「後でね」。もしも機能のためのリクエストがカムバックし続けたとしたら、そのときが、もっと掘り下げて考えてみなければいけないと分かる時です。そのときになってようやく本気でその機能を考え始めます。

    では、あなたが人々の機能のアイディアを導入しないと不平を言う人には何を言えばいいのでしょうか?そもそも彼らがなぜそのアプリケーションを気に入ったのかを気づかせます。「私たちがノーと言ったからあなたはこのアプリケーションを気に入っているのです。あなたはこれが他の100の事をしないから、気に入っているのです。あなたはこれがいつも全員を喜ばせようとしていないから気に入っているのです。」

    『僕たちには1000のアイディアはいらない』

    スティーヴ・ジョブスが何人かの独立系レコード会社の人にiTunes Music Storeのちょっとしたプレゼンテーションを行いました。その日の私のお気に入りの台詞は、彼らが手を上げて「それはxはできるの?」、「あなたはyを追加する予定ですか?」と尋ねたときのこと。ついにジョブスは言いました、「待ってくれ、待ってくれ — 手を下ろしてくれ。いいかい。君たちがiTunesに入れることができる1000のクールなアイディアを持っているるのは分かっている。もちろん僕たちもだ。でも、僕たちには100のアイディアはいらない。 それはみっともないよ。イノベーションは全てのこと̆に対してイエスと言うことじゃない。それは最も重大な機能を除いて、全てにノーと言うことだよ。

    —-デリク・シバース, 社長兼プログラマー, CD Baby そして HostBaby
    (from Say NO by default)


    隠れたコスト

    新機能の値段は?

    たとえ機能がノーのステージを通ったとしても、そこにかかった隠されたコストははっきりさせます。

    ここで、機能ループ(機能がさらに別の機能を呼ぶ形)に用心。"Basecamp"のソフトウェアでミーティングのタブの追加のリクエストがありました。一見簡単そうなことですが、そこに落とし穴があります。「場所」「時間」「部屋」「人」「Eメール招待」「カレンダー共有」「Q&A」といった異なるアイテムが必要になります。それ以外にも、プロモーションのスクリーンショット、ツアーページ、ヘルプページ、サービス規約などなどの多くのものを変えなくてはなりません。単純なアイディアが雪崩のように頭痛の原因に変わってしまいます。

    新機能を追加する際には、以下のステップが必要になります:



    扱いきれるか?

    コントロールできるものを作る

    もし、あなたが会員制プログラムを立ち上げるのなら、会計や支払いのシステムはありますか?毎月請求書を用意したり、サインしたり、メールを送ったりするのなら、代わりに会費制にし毎月クレジットカードで会費を支払ってもらう方が良いでしょう。

    グーグルがやってるからといって、1GBの無料スペースを提供できますか?おそらく、100MB程度の小スペースや、支払いアカウントのスペースを作るぐらいが現実的でしょう。

    ボトム・ライン:自分たちがコントロールできる規模の製品やサービスを提供する。約束するのは簡単ですが、それらを守り続けるのは難しい。何であれ自分たちのやっていることが組織面でも、戦略面でも、そして機能面でも持続可能であることを確かにするべきです。



    人による解決

    ソフトウェアは一般的な使用のためにつくり、ユーザーが自分でそれぞれの目的を達成できる生み出す様促す

    ルールを人々に押し付けてはいけません。みなが自分達自身の解決策を見つけられるよう、ソフトウェアは一般的なものにするのです。ユーザーが自分の目的を達成するのに不足のないソフトウェアがあればよく、それ以上は不必要です。

    我々がTa-daリストを作ったときには、意図的にいろいろな要素を省きました。他の人にTODOを割り当てることはできないし、期限を付けることもできない、TODOアイテムをカテゴリ分けできない、などなど。

    人々が工夫をこらすようにすることで、私達はツールを常に整った状態に保てました。人々は自分達自身の問題についてどのように解決すればいいかを考え出しました。日付をTODOアイテムに付け足したい時はただ(期限:2006年4月7日)と付け加えるだけです。カテゴリーを加えたい時は、アイテムの前に[本]を付ければすみました。それが理想的か?ノー。しかし、限りなく柔軟か?イエス。

    もしソフトウェアをこのようなケースにきちんと���処できるように作ろうと始めると、他のケースに対してはほとんど使い道のないものを作ることになります。

    脇道にそれるのは、根本の問題についてやれるだけのことをしてからです。人々はあなたの作った一般的なフレームワーク内で、自分達の解決策とルールに気づくのです。



    機能のリクエストは忘れる

    何が大切なのかは顧客に思い出させてもらう

    顧客はこの世にあるもの全てを望むものです。この人たちは機能リクエストをもって殺到してくるに違いありません。わたしたちの製品フォーラムをのぞいてみてください;圧倒的に、機能リクエストのカテゴリーが他のカテゴリーを凌いでいます。

    そこで耳にするのは「このちょっとした追加機能」のことだったり、「難しいことじゃない」「こんなの追加するの簡単だろ」「組み込むのなんてたった数秒しかかからないさ」「もしこれを付け加えてくれるなら倍の料金を払おうじゃないか」などです。

    もちろんリクエストすることを責めるわけではありません。わたしたちはそれを奨励しますし、正直なところを聞かせてほしいと思っています。わたしたちの製品に追加することのほとんど全ては、顧客のリクエストが発端だったものです。しかし、さっき言いましたように、最初の答えはノーでないといけないのです。そういったリクエスが次々と舞い込んできたらどうします?それをどこに置いておきます?それをどう管理します?そんなことしないでしょう。内容を読んで、投げ捨ててしまうだけです。

    そう、読んで、投げて、忘れてしまえばいいのです。罰当たりに聞こえるかもしれませんが、重要なものはいやでも浮かんで来続けるものです。そういったリクエストだけが覚えておくべきものです。そういったのが本当に重要なものなのです。やってきたリクエスト一つ一つを追いかけてどうにかしようと悩むことはありません。顧客に覚えてもらいます。もし本当に思い出すに値することであれば、顧客の方から気づかせに来ます。忘れられなくなるまで。

    この結論に私達がどうやって辿り着いたかというと、Basecampを最初に立ち上げた時のことです。BasecampのTODOリストについての主だったリクエストを追って、あるリクエストが誰か他の人物から繰り返されていたら、優先順マークを付けて(IIやIIIやIIIIのように)リストを更新するということをしました。わたしたちは、いつの日かこのリストをレビューして一番リクエストの多かったものから下に片付けていくことになるのだろうと考えました。

    しかし、実際にはそのリストを二度と見ることはありませんでした。私達には次に何をすべきなのかが分かっていたのです。なぜなら顧客が何回も何回も同じリクエストをするために絶えず催促してきていたからです。リストも大量の分析も必要ありません。全てはリアルタイムに起きているのです。毎日催促された日にはあなたも何が重要かを忘れることはできませんよ。

    そしてもう一つ。x人の人が何かをリクエストしてきたからといって、それを取り入れなければということはありません。時にはただノーと言って、製品についてのあなたのビジョンを保つことの方が良いこともあります。



    わさび抜きで

    何がいらないのかをたずねる

    ほとんどのソフトウェア調査・研究内容は、人々が何を製品に望むかということを中心にしています。「どんな機能がないと思いますか?」「もし何か一つだけ加えられるとすれば、何にしますか?」「何があればあなたにとってもっと便利でしょう?」

    このコインのもう半面はどうでしょう?人々が望まないものをたずねてはどうでしょう?「もし何か一つ取り除くことだできるとすれば、何にしますか?」「使わないものはなんですか?」「一番邪魔をしているのはなんですか?」

    もっと、は答えでありません。顧客へできる一番の親切は時として何かを省くことです。

    イノベーションはノーと言うことから生まれる

    [イノベーション]は1000の事にノーと言うことで、間違った道にのったりやりすぎることがないよう確かめることから生まれる。我々はいつだって参入できる新しいマーケットについて考えている。しかし実はノーというだけでいいのだ。そうすれば本当に重要なことについて集中できるようになる。

    —スティーブ・ジョブス, CEO, アップル (The Seed of Apple's Innovationから)


    プロセスchapter 6

    ソフトを動かす競争

    実現させ、素早く作動開始

    ソフトウェアを動かすことは、弾みをつけ、チームをまとめ上げ、うまくいかない考えを流し去るのに一番良い方法です。それは1日目から最優先事項とすべきことです。

    もしソフトウェアをより早く動かす助けになるのであれば、より小さく作ったり、ディテールを省いたり、プロセスをショートカットしたりしても大丈夫です。一度そこに至れば、プロセスをどうするかより正確な見通しが得られます。道筋やワイヤーフレーム、そしてHTML記述でさえ、所詮は近似的なものにすぎません。ソフトウェアを動かすことで、本当の動きがわかります。

    現実にソフトウェアを動かすことにより、真の理解や納得に近づくことができるのです。頭の中の下書きやパラグラフを元に激しく議論していた経験はありませんか?そんなことは結局現実の結果の前では大したことではありません。自分では些細なことと思っていたことが、実は非常に重要だった…そんなことがわかることもあるのです。

    実態のある現実ものでないと本当の反応はわかりません。それが真実を見出す道なのです。

    リアルが合意を導く

    様々な人たちが集まって何かをうまく話し合おうとするとき、実物大の模型を作ると、意見がバラバラにならず、意見の交換がスムーズになる。もちろん、頭の中のスケッチだけの話やアイディアのない話だと、お互いの意思の疎通がすれ違う可能性が高くなる。しかし、実在するものを使うと、意見がうまくまとまる可能性が高まるのだ。

    —クリストファー・アレクサンダー、建築家
    (「Contrasting Concepts of Harmony in Architecture」より)

    できるだけ早く動かす

    私は今まで大きなプロジェクトから小さなプロジェクトまで経験してきたが、長期計画でありながら計画段階から開発を行わないプロジェクトで、スケジュール・コストといった面で成功に至った例を見たことがない。貴重な時間を割いて作った機能が、後々になって不必要・実行不可能になってしまうことほど、面白いが単純すぎてアホらしいことはないだろう。

    これは、全ての開発段階に当てはまる。「実際に現実で始めてみる」は共通のスローガンである。これは例えば新規プロジェクトだけではなく、すでにアプリケーションが作られた後の小さな規模のバージョンアップの段階でも同じく使えるのだ。

    主要なコンポーネントが使えるのであれば、開発者はアプリケーションの一部でどのように動く(または動かない)のか知りたくなり、普通すぐに試したくなるだろう。たとえ、開発が完璧でなく、一部のみができあがっている状態であっても、早い段階での現実でのスタートにより明確なインターフェイスや、本当に必要な機能がわかるだろう。

    —マット・ヘイマー、「Kinja」開発者・製品マネージャー


    反省(リンス)と繰り返し

    繰り返し

    1回目でうまくいくとは思わないこと。アプリケーションを成長させ、そこから学びます。その形を変え、進化させます。ウェブベースのソフトウェアでは、完璧に固執する必要はありません。スクリーンを作り、使い、分析し、そして繰り返す。

    全てを前倒しに行う発想とは逆で、繰り返しのプロセスにより徐々に様々な決定ができるようになります。その上、完璧を求めて時間をかけることが無いため、動���の良いアプリケーションをより早く動かすことができるのです。その結果、どこに注目すべきかと言うことについて、本当のフィードバック・本当の道しるべがわかります。

    繰り返しは解放に

    いずれ後でもう一度やる必要があるなら、1回目から完璧を目指す必要はありません。再度問題に取り組むことがわかっていれば、色々なアイディアが役に立つかかどうか見極めがつくまで溜めておくことができます。

    多分あなたは私より賢い

    多分あなたは私より_はるかに_賢い

    それは絶対可能だ。事実それはありえるのだ。しかし、あなたが多くの人、そして私にも似ているのなら、見えないもの・感じられないもの・触れられないものをイメージすることが難しいだろう。

    人間は環境へ非常にスムーズに適応できる動物である。虎が部屋に入ってきたらどうパニックするか知っているし、壊滅的な洪水の後でもどう掃除するか知っている。だが不運なことに、我々は、未来の計画や、選択肢の判断、優先順位付けなどが下手である。

    おそらく、あなたはそういったことを頭の中で思い描くことのできる数少ない人の1人だろう。そうしたことは重要ではないのだ。

    Web 2.0、その世界では、人々がウェブをすでに使っていて、賢い開発者がこうした人間の弱点を踏まえた上でのソフトウェア設計ができる環境が整っているのだ。どのように?ユーザーの意見を取り入れる時間的余裕だ。

    前文章から、なぜこのように開発をすべきか、また、プロモーション・スタートをどうするか分かるはずだ。

    ポリシーをつくる。部分部分がうまく動くことを確認する。それから運営を開始し修正する。我々皆より賢い人間はいないのだ。

    セス・ゴーディン、作家・企業家


    アイディアを現実に

    ひらめきを下書きに、HTMLにコーディングに

    これが、アイディアを現実にする(Get Real)プロセスです:

    インスピレーション

    まずは、アイディアを思いつくところからです。このプロダクトは何のためにあるのでしょうか?「Basecamp」の場合、きっかけは我々自身のニーズでした。我々はプロジェクトを常にリニューアルしていきたかったし、クライアントにも参加してもらいたかったのです。プロジェクトは里程標があります。簡単に過去のものを見れるよう、アーカイブを集めたかったのです。我々は、プロジェクト全体を見渡せる鳥瞰図、大局観が欲しかったのです。そうした考えなどが、我々の行動指針となったのです。

    この段階では、あまりディテールにこだわってはいけません。本質的な大きな視点での問題として捉えます。そのアプリケーションは何が必要なのか?それがいつ役に立つのか、どのように知るのか?いったい何を作ろうとしているのか?これは、ピクセル単位のような小さなアイディアではなく、高レベルでのアイディアです。この段階では、ディテールに関するものは、意味をなしません。

    紙スケッチ

    スケッチは素早く、殴り書きで、お手軽でできるもの;それ以上は必要ありません。書きましょう。走り書きでいいんです。四角や丸や直線なんかのシンプルなものでいいんです。アイディアを頭から紙に写します。目的は、頭の中のコンセプトをラフなインターフェースのデザインに変えるところです。ここはまだ実験段階です。正しい・間違いといったことはないのです。

    HTMLを作る

    先ほどのスケッチの特徴(または、セクションやフロー)を元にHTMLを記述してみます。実際に形にすることで、皆がスクリーン上で見ることができるのです。

    「Basecamp」では、我々はまず、「メッセージを書く」スクリーンを作り、次に「メッセージを編集する」スクリーン…徐々に開発を進めていきました。

    まだプログラミング・コードに手を出してはいけません。あくまでHTMLとCSSの、現実に近い模型を作るのです。完成品にするのは後の段階です。

    コードにする

    実験的に作ったものがうまくいって、必要な機能を満たしたのなら、実際にプログラミング・コードを記述していきます。

    先にも少し話しましたが、プロセス全体で常にどんな事態にも柔軟に対応し、何度も繰り返すことを忘れてはいけません。ある段階でのできあがったものがダメだったら、もう一度やり直します。このサイクルを何度も繰り返すのは自然なことなのです。



    環境設定は避ける

    細かな詳細の決定は、ユーザーのために

    あなたは厳しい決断を迫られています:「1つのページにどれくらいメッセージを入れますか?」これに対し、あなたの答えは:「皆が25、50、100選べるような設定にしよう」でしょうか。最も簡単な出口ですね。ただ決めるだけです。

    任意設定は、難しい決断を避ける方法

    あなたの経験から最良の選択肢を考えるのではなく、ユーザーの手に委ね様としているのです。ユーザーのためにしている様にも受け取れますが、彼等に任せることで彼等の仕事を増やしているのです。あまりに細かすぎる設定画面を見ると頭が痛くなり、喜ばれないでしょう。ユーザーに、あれもこれも詳細を考えさせるのはよくありません。_重要な決定は、ユーザーにではなく自分で責任をとりましょう。_

    また、任意設定は多くのソフトウェアを作ることにつながり要注意です。多くのオプションは当然、作るのに労力を要します。その上追加のテストやデザインなども考えないといけません。また、今まで見たこともない変更やインターフェイスに合うかもしれません。そうしたものは、知らないバグにつながることになります。例えば、レイアウトやテーブルの崩れ、変な構成などなど…

    押せば引く

    ユーザーのために、シンプルな決断をする。それが、我々が「Basecamp」で行ったことです。ページあたりのメッセージ数は25。「Overview」のページでは、最後の25のアイテムが表示されます。メッセージは新しいもの順に並んでいます。最近の5プロジェクトはダッシュボードに表示されます。オプションは設けていません。それが我々のやりかたです。

    そう、あなたは間違ったアプローチをするかもしれません。でも、いいじゃないですか。もし道を誤ったら、人が苦情を言うことで、誤りを伝えてくれます。そのとき修正すればいいことです。「Getting Real」は、今すぐにでも変化できる事。

    任意設定はコストがかかる

    任意設定にはコストがかかることを理解しているだろうか?もちろん、任意設定は、大きな利点があるものがあり、重要なインタフェースの特徴となる場合もある。しかし、金がかかるため、その価値をよく考えなければならない。多くのユーザーや開発者はこのことを分かっていないため、任意設定に大金をつぎ込むが、その価値は低い…というケースに陥るのだ。もし中途半端に任意設定機能を付けずすばらしいデフォルトを作ることに首尾一貫した態度で臨むなら、UIは、自然と正しい方向に向かうだろう。

    —ハヴォック・ペニングトン、「Red Hat」 テクニカル・リーダー(「Free software and good user interfaces」より)


    「できた!」

    決定は一時的;ユーザーの反応と修正が大切

    できた(Done)。それは魔法の言葉と考え始めてください。「できた」というのは、何かが成し遂げられたという意味。決定はすでに行われこれから進むことができる。「できた!」は発展の可能性があるということです。

    しかし待ってください。もし、間違った方向に進んだまま、プロジェクトに区切りをつけてしまったら、どうしようか?それはそれでOK。これは、脳外科手術ではなく、ウェブ・アプリケーションです。 これまで言ったとおり、プロセスの中で何度も機能やアイディアを練り直したらいいのです。どんなに周到な計画があっても、完璧に物事が進むことはありえないのです。なので、「分析麻痺」にはならないでください。それが、スピードを落とし、モチベーションを下げる要因ですから。

    そのかわ���、前進することに重きを起きます。テンポよく決定をしていきます。すばやく、シンプルにユーザーに新たな機能・アイディアを投げかけ、反応を見て考察し、うまくいかなかったら、新たな方向へ進んでみましょう。

    恐れないで。その決定は一時的なものですから。失敗は起こるもの、できるだけ早く修正すれば、たいしたことではない。トライして、勢いをつけ前へ進み続けましょう。

    とりあえずやってみる

    机上の空論に夢中になっている人の話を聞くのはおかしい。(彼等は、最もシンプルなアイディアを言うことに満足しているのだ)

    私に言わせれば、アイディアは実行しないと意味がない。そう、乗数にしかすぎない。実行することで価値は何百万倍にもなるのだ。

    説明:

    • ひどいアイディア = -1
    • イマイチのアイディア = 1
    • まぁまぁのアイディア = 5
    • 良いアイディア = 10
    • 素晴らしいアイディア = 15
    • 最高のアイディア = 20
    • 実行しない = $1
    • ほとんど実行しない = $1000
    • まぁまぁ実行した = $10,000
    • 結構実行した = $100,000
    • かなり実行した = $1,000,000
    • 最も実行した = $10,000,000

    ビジネスを行うには、この2つの掛け算が必要になる。

    最高のアイディアでも、実行が伴わなければ、$20の価値しかない。最高のアイディアを最もよく実行に移せば、その価値は$20,000,000になる。

    私が人のアイディアを聞きたくない理由が分かっただろうか。実現していないものには、何の興味も持てないのだ。

    —デレック・シヴァーズ、「CD Baby」「HostBaby」社長・プログラマー


    現場テスト

    アプリケーションの実用性を検証

    あなたのアプリケーションが実際に使えるかどうかは、実際に現場で使う/使ってもらう以外に分からないものです。現実のデータを取り、リアルな反応をうかがう。そうした情報が改善の源となるのです。

    形式ばったユーザビリティのテストでは駄目。研究室での設定は現実を反映していません。あなたが研究者の立場で物事を見ると、何が機能するかがわかるかもしれませんが、人々は実験という枠の中では現実と同じように行動しないのです。誰かに見られると、人はミスをしないように気をつけます。_そうしたミス・マイナスポイントこそが改善の上で大切なのですが…_

    代わりに、現在ある機能・サービスに新たな機能・サービスをベータ版として追加してみます。すでにリリースされたもののそばで、ユーザーにベータ版を試してもらいましょう。これにより、新たな機能に対する人々のリアルなデータ・ワークフローがわかります。それにより、リアルな結果が出るのです。

    さらに言うと、リリースされているバージョンとベータ・バージョンは区分けしません。ベータ版を隔離してしまうと、試してくれる人が少なくなるのです。現行のバージョンにいくつかのベータ版の機能を含めることで、充分な結果が得られるでしょう。

    ベータ本

    開発者がコードのリリースをためらうのは、言わば出版社や作家が本の出版をためらうようなものだ。一度本が紙の形で世に出ると、内容を変えるのは難しくなる(本当はそうではないが、昔の技術との考え方や問題のイメージが残っているため、そう感じられるのだ)。だから、出版社は出版前に本を「完璧に」仕上げようと、多くの労力(それと金)を費やすのだ。

    そう、正にウィン・ウィンだった。私は(紙の)本をさらに発展させることができ、コミュニティは望むものにより早く近づけたのだから。そして、あなたが競争の中にいるのなら、何かをより早く形に出すことは、人々の関心を競争相手ではなく自分たちにむけることになるのだ。

    —デイブ・トーマス、「The Pragmatic Programmers」

    素早く実行

    • 1.やる価値がある、またそう思うのなら:
    • 2.素早く行う。_完璧に仕上げようとしなくてもいい。まずはやってみる。_
    • 3.セーブして、アップロード。出版。
    • 4.人々がそれをどう思うか見てみる。
      • 私は基本的に新しい機能の追加には慎重だが、一度やる価値があると思い「やるぞ!」と思えば、その数時間後にはウェブにアップされている。失敗してもとりあえずやるのだ。フィードバックをもらえることで、その後につながるのだから。

        —デレック・シヴァーズ、「CD Baby」「HostBaby」社長・プログラマー


    時間の縮小

    細分化

    何ヶ月も何年も先の見積もりはもはや空想です。現実には、遠く先のことなど知る由もないのですから。

    さぁ時間を縮めましょう。大きな時間を小さな時間の単位に分けるのです。12週間のプロジェクトではなく、1週間のプロジェクトが12週続くと思うのです。30時間かかりそうなタスクではなく、より現実的な6-10時間の単位で細かく考えるのです。そして徐々にステップを上がっていきます。

    同じ理論が他の問題にも使えます。問題が大きすぎて、抱えきれなくなった経験はありませんか?細分化しましょう。消化できる大きさにまで小さく小さく問題を切り刻むのです。

    小規模タスクとスケジュール

    ソフトウェアの開発者は、特別な楽天家の才がある:プログラムのタスクを前に、「楽勝じゃん!時間はかからないよ」と思うのである。

    例えば、プログラマーに3週間の大きな仕事を与えよう。すると、2.5週間ぐずぐずし、1週間で仕事をやりあげる。遅れたスケジュールにより予定内の作業の完了はおそらく難しくなる。タスクが想像以上にややこしくなるからである。さらに、誰が3週間前に同意したことを覚えているだろうか?

    プログラマーに午後にできるような小さな特定のモジュールのコード作業を与えてみよう。作業ははかどり、次の作業にスムーズにつなげることができるのだ。

    小規模タスクやスケジュールはより管理しやすく、余計な誤解を減らし、気が変わったり、やり直したりすることも安易になるのだ。スケジュールを細かく区切ることにより、やる気が続き、仕事を終わらせた喜びを感じる機会が増え、「まだこんなに時間がある。とりあえずiTuneのライブラリーの整理をしよう」などと思うことは減るのだ。

    —ジーナ・トラパーニ、w「Lifehacker」 "the productivity and software guide"ウェブ開発者・編集者

    真のファクター

    これから、あなたが答え様にも答えられない質問を受けた場合(締め切りのこと、プロジェクトの最終的なコストのこと、あるいはグランドキャニオンを浸せるミルクの量)、部屋から空気を抜かすような答えを:「私にはわからない」。

    あなたの信頼をダメにするどころか、反対にあなたは物事を慎重に考える人という結果になるだろう。自分をスマートに見せるため、余計なことは口走らない方が良い。質問を協力的な会話と捉えることで、現実に対処ができるようになるのだ。正確な見積もり時間(とその根拠)の必要性を学ぶことで、真のフ���クターに元付く共同作業を行うことができる。

    —マーリン・マン、「43folders.com」クリエイター・編集者

    取り組むべきは、目の前の問題から

    私の記憶内で、最近のウェブで最も気に入ったことが、「nofollow(フォローしない)」属性のリリースだった。それまで誰も話さなかったことである。野蛮人どもが文法の本質を議論するような場がなかった様だ。シンプルなアイディアを20行のxmlに含めるようなrfcがなかったため、私はどのように使うかわかるために読み上げなければならなかったのに、フォーマットするのがバージョン3なのか3.3なのか分からなくなり、使うのを止めたのだ。

    それはシンプルで効果的で、オプションを求めていた人へのオプションだった。そして、仕様や違いを気にしないウェブ人口を考える際にさらに重要になる。

    時々次の20の問題を解決しようとするより、今直面している問題を考えることがより有益で思慮深いことだ。それは、スパムに対する小さな勝利(スパムに対する勝利は全て小さなものだ)ではなく、ウェブ開発者が目指すシンプルで迅速な結果をもたらす勝利だったのだ。

    —アンドレ・トレス、「Federated Media Publishing」 プログラマー・エンジニアVP


    組織chapter 7

    一致団結

    個々に分けず

    多くの企業が、デザイン・開発・コピーライト・サポート・マーケティングといったものを個々に隔てすぎています。専門家には利点もありますが、自分たちの小さな世界しか見えずに、アプリケーションの作成にも木を見て森を見ずといったような状態におちいる恐れもあります。

    可能な限り、チームをまとめ、プロセスの最初から最後まで見渡した質の高い議論を設けます。チェックとバランスのシステムを準備すれば、「ロスト・イン・トランスレーション(訳が無意味になる)」な様なことになりません。コピーライターとデザイナーを一緒に仕事させ、サポートへの問い合わせが開発者に見えるようにします。

    人を雇うときは、開発中様々な帽子をかぶることができるような多才な人を雇います。結果的により満足度の高い製品ができあがるでしょう。



    1人の時間

    干渉されない時間

    37signalsのメンバーは、4都市・8つのタイムゾーンにまで広がっています。ユタ州プロボからデンマークのコペンハーゲンまで、我々5人に8時間の時差があるのです。こうした時差の良い点が、1人の時間が持てることです。

    1日の中で我々が共に仕事を行うコアタイムは4~5時間しかありません。それ以外の時間は、デンマークのデヴィッドが働いている間にアメリカのメンバーが寝ていたり、その逆…ということです。これにより、一日の半分ぐらいを皆と共にし、残りの時間が1人の時間になるのです。

    私達が最も仕事をする時間帯は分かりますか?1人の時間です。驚くべきではなく、これは多くの人が同意してくれることです。あえて朝早く出勤したり夜遅くまで残ったりした方が仕事がはかどるという話もよく聞きます。_余計なことを考えずに集中できる時間です_

    人に気を使わなくてもいい時、余計なことに悩まなくてもいい時、それが集中モードの入口です。集中モードに入ると、頭がさえわたり、物事が普段よりはるかにスムーズに運びます。それが、様々なタスクにあたふたしなくてもいい時です。質問されたり、何かを調べたり、メール送信や電話…といったことに仕事を遮られない時間なのです。1人の集中した時間は、本当に物事が進みます。

    そのモードに入るには時間が必要ですから、妨害は害敵です。それはちょうどレム睡眠のようなものです。レム睡眠には一気に到達できず、睡眠が深まるにつれて徐々に起ってくるのです。せっかくの睡眠も突然の音で一気に目が覚めてしまうことはよくあります。レム睡眠は、真の睡眠マジックが起こるところなのです。1人の時間は、真の開発マジックが起こるところなのです。

    仕事のルールを作りましょう:1日の半分を1人の時間にしましょう。例えば、朝10時から午後2時までは、(昼休憩のとき以外は)他の人に話しかけてはいけない。また、1日の前半または後半を1人の時間にするといった具合です。せっかくの仕事がはかどる時間を邪魔されないように、この時間はある程度とります。

    うまく仕事のはかどる1人の時間は、我々のコミュニケーション依存症にも効きます。1人の時間では、IMも電話もミーティングもシャットアウトします。メールの即時の返答もしてはいけません。外音を閉じて、自分の仕事のみに集中するのです。

    モードに入る

    ナレッジ・ワーカー(knowledge worker)が最高の仕事を行うにはある種の「フロー」があることはよく知られている。それは、仕事に完全に集中し、外の環境を完全に遮断した「集中状態」ともしても知られている。完全に集中することで、時間に追われる感覚から抜け出し、素晴らしいものを作り出すことができるのだ。問題は外からの音、電話、昼食の外出、スタバでの5分休憩、同僚から話・質問・相談(これが大きいのだが)…そんなものは集中の妨げになる。もし同僚の質問に答えるのに1分使ってしまったら、元の集中状態に戻るのに1時間半かかり、せっかくいい形で進んでいた仕事も暗礁にのりあげる深刻な事態になるのだ。

    —ジョエル・スポルスキー、「Fog Creek Software」ソフトウェア開発者
    ("Where do These People Get Their (Unoriginal) Ideas?"より)


    毒性ミーティング

    ミーティングをしない

    ミーティングは本当に必要ですか?ミーティングはコンセプトがはっきりとしていない時に起るものです。ミーティングに頼る前に、メールやIM、「Campfire」のソフト等を使って、議論しやすいようにコンセプトをはっきりとしておきます。目指すところは、脱ミーティング。ミーティングの時間を減らせば、その分もっと現実的な仕事ができます。

    ミーティング以上に生産性を妨げるものはありません。これにはいくつか理由があります:

    どうしても出席しなければならないミーティングの場合(本当にしなければいけない時)、次のようなシンプルなルールを守ります:

    ミーティングはできるだけしない

    ミーティングがあまりに多すぎる。意味のない、新しいものが生み出されないようなミーティングは拒否するに越したことはない。助言や承認、同意が欲しいあるいは必要な、重要なビジネスの問題の直結したミーティングのみあるべきだ。そんなミーティングでも、メンバーと関係者をこぞって呼びたくなるが、それは避けるべきだ。_必要以上に皆の時間を無駄にさせてはいけない。_

    —リサ・ヘーンバーグ、作家("Don't Let Meetings Rule!"より)

    小さく分ける

    プロジェクトが大きくなると、ネックになるのがメンバーの増加である。その最も興味深い理由の1つが、コミュニケーションチャンネルの数の増加だ。お互いの話が可能なのは2人の場合だけ。コミュニケーションの道が1つだけだからである。しかし、これが3人になると道は3つ。4人だと6つ…事実上リンクは指数関数的だ。1日仕事をするはずが、メモとミーティングに埋まってしまうことになる。

    解決策ははっきりしている:チームを小さくし、独立して動ける規模まで小さくし、コミュニケーションのリンクを減らすのだ。

    同じ様に、プログラムも小さな単位に分ける。問題の多くは多くの要素の混在(大きな変更、機能同士のデータ接続エラー、ハードウェアの共有…)から起こるため、要素同士の依存を取り除く、_または最小限にする_様プログラムを分ける方法を考えるのだ。

    ガンスル・グループ (「Keep It Small」より)


    小さな成功を見つけ祝う

    今日何かを生み出す

    ソフトウェア開発で一番大切なことは、情熱である。情熱は己の内にあります。もし今の自分の仕事に情熱を感じなければ、本来得るはずのチャンスさえ逃すことになり、結果はひどいものになるだろう。

    長いリリースサイクルではモチベーションも上がりません。達成と次の達成の間が長すぎるため祝うことが少なくなります。逆に達成の喜びを随所で感じられる様なら、大きなモチベーションの源となります。長いリリースサイクルのままだと、モチベーションは下がり、それは製品の質の低下にもつながります。

    そのため、もし、何ヶ月ものリリースサイクルを要する製品に取り掛かっているのなら、1日、1週間(あるいは2週間)で小さな達成の喜びを味わえるようにしましょう。「この4時間で自分は何ができるだろう」そう自分に問いただし、やってみることです。次のようなことが見るけられるはず:

    4時間で小さな達成を感じられたのなら、それはきっと喜びにつながるはず。そこから、士気が上がり、やる気も増え、チームが一体となって正しい方向へ進んでいくのです。



    メンバーを加えるchapter 8

    少なく雇い、後で

    早く実現したいのなら、少しずつ足す

    組織を大きくするのに、早いも_そして遅いも_ありません。たとえ最高の人材を100人選べる立場であっても、一度に全員を雇うのは賢い選択とはいえません。そんなに多くの人を1つの組織文化に組み込むことなんてできるわけ無いのです。教育と研修で頭を悩まされる毎日、個人と個人の対立、コミュニケーションの喪失、バラバラの方向性…あげるとキリがありません。

    だから人は雇わない。本気です。人を雇わないのです。他の道を探しましょう。今、肩にのしかかっている仕事は本当に必要なものですか?それをしかなったら問題ですか?便利なツールや代わりのアプローチ方法でその問題を解決できませんか?

    GEのCEOジャック・ウェルチは、誰かをクビにしても、すぐに代わりの人間を雇わなかった。そのポジションに人がいなくてもどれだけ問題がないのか知りたかったのだ。この理論をテストするために人をクビにするのは酷ですが、ジャックの言わんとしていることは考えるべきです。必要な人間の数は、あなたが思っているよりずっと少ないものなのです。

    もし、ほかに方法がないなら、そのとき初めて人の雇用も検討します。しかし、誰を雇い、どのように仕事に加え、そのことから来るストレスはどの程度のものか、リアルに考えなければなりません。

    ブルックスの掟

    遅いソフトウェアプロジェクトに人を加えると、ますます遅くなる。

    —フレッド・ブルックス

    プログラムとモーツァルトのレクイエム

    1人で1つの仕事をこなす優秀なプログラマーは、必要以上に人やコミュニケーションを持たない。一方、同じ仕事を5人のプログラマーでするときは、協力やコミュニケーションがいる。それで時間がかかるのだ。所詮二流のプログラマーが沢山集まったところで、どれだけ時間をかけても優秀なプログラマーのクオリティ品は作り出せないのだ。アントニオ・サリエリが5人集まってもモーツァルトのレクイエムを作り出すことはできないだろう。絶対に。おそらく100年かかっても。

    —ジョエル・スポルスキー、「Fog Creek Software」ソフトウェア開発者 ("Hitting the High Notes"より)


    「タイヤを蹴る」

    まずは現場でテストを

    人を雇うとき見るポートフォーリオや履歴書、以前手̄がけたコード実例、前職等は実際に現場で(一時的にでも)働いてもらうのとはかなり違う。可能ならいつでも、新たな仲間となるかもしれない人材を「テスト・ドライブ」してみましょう。

    誰を雇う前でもそうですが、まずは小さなプロジェクトを与えてみます。どのようにプロジェクトに取り組み、どのようにコミュニケーションを行い、どのように働くのか…誰かと共にいくつかの画面をデザインし、コードを作っていく過程からわかることは、貴重な体験です。そこに良い雰囲気があるか否かは、きっとすぐ分かるはずです。

    スケジュール的に悠長なことを言ってられない場合もありますが、たとえ20時間や40時間だけでも、無いよりはマシです。自分たちの組織に合っていてもそうでなくても、それははっきり分かるはず。もし結果が悪いものであっても、始めに現場でテストしておくことで、お互いに多くのトラブルを防ぐことができるのです。

    スタートは小さく

    まずは、小さな課題から試みることだ。いきなり、仕事全てを任せてはいけない。テストプロジェクト1つや2つを新しい「バーチャルアシスタント(雇うかもしれない人)」に与え、自分達とどの様な相性なのか見てみるのだ。はじめ、ポテンシャルの問題を色眼鏡で見るのは簡単すぎる。これはテスト・ランだとの前提で。

    —スザン・ファルター・バーンズ、作家、クリエイティビティ・エキスパート
    ("How To Find And Keep The Perfect VA"より)


    言葉より行動

    未来のスタッフ雇用は彼等のオープンソースへの寄与から

    技術職の雇用の典型的な方法は、_専門分野や履歴書などに基づいたもの_だが、色々な意味で欠陥があります。学校の専門分野や成績で何がわかるのでしょうか?履歴書や推薦書を信じられるのですか?

    オープンソースは、テクニカル・スタッフを雇う上で非常に役立つものです。オープンソースを使えば、仕事ぶりや成果を長期間で、よい結果も悪い結果もチェックすることができます。

    それは、言葉ではなく行動で人を選べるということです。本当に大切なことに基づいた決定ができるのです:

    プログラマーに関しては、我々はオープンソースでの関わりでよく素性を知ったもののみを採用します。それ以外の採用は無責任だと考えますから。ジャミスを採用したときも、Rubyコミュニティでの彼の活躍、参加を見てのものでした。彼のプロジェクトでの業績(上記のもの全てで)は抜群でした。他の付随的な要素に関しては調べる必要はありませんでした。我々は本当に重要なものを知っていたからです。それはもちろん、彼の仕事の質。

    オープンソースの仕事に焦点が移ってしまい、普段の仕事に熱が入らなくならないかと心配することはありません。古いことわざにこんなものがあります:『何かを欲すれば、一番忙しい人間に尋ねよ』。ジャミスとデイビッドは、Railプロジェクトの最も中心的なメンバーであり、37signalsの技術も支えています。プログラムを愛し、仕事をこなす人間は、間違いなくチームに一番欲すべき人間です。

    オープンソースへの情熱

    新しく人を雇うときに一番重視したいのはその人の持つ情熱である。その情熱を最も理解できるのは、他ならぬオープン・ソースへのフォーカスである。

    —ヤーコ・レイン、ソフトウェア開発者
    ("Reduce the risk, hire from open source"より)


    経験豊かな人を

    スペシャリストより早く覚えるジェネラリスト

    我々はスペシャリストを雇うつもりはありません。彼等のディテールのこだわりは半端ではありません。我々のような小さなチームには、そのような一部にとてつもない能力を発揮する専門化肌の人間は合わないのです。

    小さなチームには、何足もの草鞋を履けるような人間が必要です。ものを書くことができるデザイナー、デザインの分かるプログラマー…全てのメンバーが情報を(どんな情報でも)組み立てるアイディアを持つべきです。全員整った精神が必要だし、全員が顧客とコミュニケーションできることが必要なのです。

    そして、メンバー全員にいつでも道から外れられる気持ちが必要です。小さなチームはしばしばその方向を変え、素早く軌道修正することがあります。そんな軌道修正にも応じて、学習できる人間が必要になるのです。1つのことに固執し変化を見出せない人間は我々のチームには合わないのです。



    熱意はごまかせない

    不満だらけの優等生より幸せで普通を

    熱意。それはごまかすことのできないものである。人を雇うとき、その世界で噂になっている人間や、高い技術で知られている有名な人がいいだろう…なんてことは考えないで。結局彼らはプリマドンナなことが多いのだから。普通だけど幸せな社員の方が、ブツブツ不満をもらす専門家より良いということです。

    熱意を持った人間を見つけましょう。1人でも仕事を任せられる様な人。大きな変化に疎い企業で悩み、新たな環境に身を投じようとしている人。自分達の作るものに熱中できる人。あなたが嫌いなものを同様に嫌っている人。あなたの列車にワクワクして乗ってくれる人。

    質問を聞けばもう1点

    応募者がプロジェクトにどれだけ多くの質問をするか…これは大きな指標になる。情熱を持ったプログラマーは、問題を可能な限り理解しようとし、その解決策・改善策を考えようとする中で多くの質問をするはずである。質問をはっきりさせることにより、プロジェクトが何千もの異なる方法を導入できる可能性も理解でき、あなたがそのアプリケーションをどのようにしたいのか、釈然とするはずだ。詳細を詳しく掘り下げることで、その人が現場の雰囲気にマッチするか分かるのだ。

    —エリック・スティーヴンズ、”BuildV1.com”


    文章家

    良い文章家を雇う

    採用する際には、個々の文章能力を重要視します。それは、デザイナーでもプログラマーでもマーケティングの人間、営業の人間でもです。文章構成のスキルは高く評価します。効果的な、シンプルな文章作成と編集の力は、コードやデザインやコミュニケーションなど、様々な舞台にも応用が利きます。

    というのも、良い文章家の真髄は言葉部分だけではないからです。彼等はコミュニケーションの仕方が良いのです。人に理解させるのがうまい、相手の立場を考える、不要なものを見分ける、シンプルに考える…それらがあなた達にも必要なものです。

    整理された精神

    情報を整理する、筋の通った議論をする、他人の理解を助ける(作るのではない)、といった物事を整理する能力が良い文章家に備わっている。そうした文章家は、コード・個人のコミュニケーション、(長距離の共同プロジェクトでの)メールやIM、そしてプロフェッショナルリズムや、信頼と言った難しいコンセプトにも応用される。

    —ダスティン・J・ミッチェル、ディヴェロパー("Signal vs. Noise"より)

    明白な文章は明白な思考につながる

    はっきりした文章により思考がはっきりする。自分の理解度が初めて分かるのはそれを言葉で表す時だ。文章構成は、自らのキャラクターの一部でもある。あなたのために書くのではなく、読者のためにしてみて。

    —マイケル・A・コヴィングトン、ジョージア大学コンピューター科学部教授
    ("How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily"より)


    インターフェース・デザイン chapter 9

    初めにインターフェース

    プログラミングを始める前にインターフェースをデザイン

    あまりに多くのアプリがプログラムファーストという考えで始められています。これは悪い考え方です。プログラミングはアプリ構築の上で最もヘビーな要素で、変えようとすれば最もコストがかかり、最も大変なものです。ですから、デザインから始めてみます。

    デザインは比較的軽いものです。紙にスケッチするのはコストがかからず、変えるのも容易です。htmlデザインであっても、まだ比較的シンプルに修正(あるいは捨てること)が可能です。プログラミングはそうはいきません。デザインで始める事によって柔軟でいつづけることができます。プログラミングで始めると、閉じ込められ追加コストを義務付けられるだけです。

    デザインで始める別の理由は、*インターフェースが製品だ*ということです。人々が見ているものこそあなたの製品なのです。最後の段階になってとりあえずインターフェースをかぶせたとしても、隙間は見え見えです。

    インターフェースから手をつけることで、最初の段階からアプリがどのように見え、どのように感じられるかが分かります。インターフェースはアプリをつくるプロセスを通じて絶えず改訂されていきます。感じは当たっているか?使いやすいか?目の前の問題を解決してるか?この様な疑問の答えが本当に分かるのは実際にスクリーンを目の前にしてからです。最初にデザインをすることで柔軟でいられ、それらの答えを割合早い段階で見つけることができるのです。

    オレンジ色のペンがBlinksaleのきっかけだった

    市販の請求処理ソフトウェアに自分がいらいらしているのに気付いた途端、私はどうすれば自分の請求処理方法がうまくいくようになるかを考えようと決めた。私はオレンジ色のペンを取り出した。その晩手元にあったのはそのペンだけで、数時間のうちに75%のユーザーインタフェースが描いてしまった。私はアイロンをかけていた妻のレイチェルにそれを見せ、「どう思う?」と聞いたところ、彼女はにっこりして「やらなきゃ。本当に。」と言った。

    それから2週間にわたって、私はそのデザインを洗練させ、最初のバージョンのほぼ全てのページについて静的htmlの見本をつくりあげた。これが後にBlinksaleになる。その構造のアウトラインはオレンジ色のペンのスケッチのみで作られた。そしてそれをそのままhtmlデザインにするのは、実際には自分達が何をしようとしているか分からなくなった時も、このプロジェクトが"本当に"できあがっていくことに楽しみを覚えさせ続けるのに役立った。

    htmlの見本ができてすぐ、開発者のスコットのとこへBlinksaleのアイディアを持って行った。ユーザーインターフェースのほとんどが事前にあったことは、いくつものレベルで非常に役立った。一つ目には、スコットにリアルなビジョンと興奮を与えられたこと。自分達がしようとしている事は、ただの概念でなく、現実のもの。二つ目には、デザインを動くアプリケーションにするのに必要とされるスコットの労力と時間を的確に測ることができたこと。金を借りないでプロジェクトをしようという時には、必要な予算の見定めは早ければ早いほどいい。ユーザーインターフェースデザインは初期のプロジェクト範囲でのベンチマークとなった。最終的には、開発へと歩みを進めてゆく時に、ユーザーインターフェースのデザインはそのアプリケーションがどういうものかを思い出させてくれるガイ̌ド役となってくれた。新しい機能を追加したい気になっても「よし、追加しよう」と簡単に言えない。デザインに立ち戻って、その新しい機能の居場所があるか、ないなら追加してはいけないものなのだ。

    —ジョシュ ウィリアムス, Blinksaleの創設者


    中核デザイン

    ページの中心部分から始め、外側へ組み立てていく

    中核デザインはページの本質—これを震源・中核と呼びます—に焦点をあて、そして外側へと組み立てていきます。始めの段階では、ナビゲーション/タブやフッター、色、サイドバー、ロゴなどの端のものは無視するということです。そのかわり、中心部から始め、コンテンツの最も重要な部分からデザインします。

    どんなページでも絶対に無ければいけないものが中核です。例えば、もしブログの記事を表示するページを設計しようとする時には、ブログの記事自体が中核になります。サイドバーにあるカテゴリーでもなく、一番上にあるヘッダーでもなく、実際のブログの記事部分なのです。ブログ記事部分なしでは、そのページはブログになりません。

    その部分を完了した時に始めて、そのページで次に重要な部分について考え始めることができます。そして次に重要な部分の後で、三番目の部分やその他の部分に移れます。これが中核デザインです。

    中核デザインでは従来の「フレームを組んで、それからコンテンツを中に」というモデルを避けます。この従来のプロセスでは、ページの外見が作られ、そしてナビが付けられ、マーケティングの"代物"が入れられ、最後にコアとなる機能やそのページの本当の目的となるものが、空いている場所であればどこにでも流し込まれます。これは最優先である事項を選択する方法とは逆のプロセスで、最優先事項は最後まで持ち越されてしまいます。

    中核デザインはこのプロセスをひっくり返し、プロジェクト開始時に本当に問題とすべきことに焦点を当てます。まず本質、他のものはその次です。それは顧客にとって親切で焦点があって使いやすいスクリーンという結果になります。さらに、このデザインによって、デザイナーとディベロッパーとの間での会話が、そのページの全ての面で足並みが揃うのを待つことなく、すぐに始められるのです。



    3つの状態の解決

    正常、ブランク、エラー状態によってデザイン

    それぞれのスクリーンは、次の3つの考えられる状態に備える必要があります:

    正常状態は注意していなくてもできます。一番時間をかけられるのはこの画面でしょう。しかし他の2つの状態について時間をかけることを忘れてはいけません。(以下の小論でこのことについてより述べます。)



    ブランク スレート

    配慮ある初体験で期待を持たせる

    ブランク画面を無視してしまうことは、最も大きな間違いの一つです。ブランク状態はアプリの第一印象を与えるもので、次のチャンスは無い...わかりますね?

    問題なのは、ユーザーインターフェース(UI)をデザインする時には普通データが多くあるということ。デザイナーはテンプレートをデータで埋め尽くします。全てのリスト、全ての記事、全てのフィールド、全てのものがデータでゴチャゴチャ。そうすると、スクリーンはすばらしく見え、ちゃんと動く。

    しかし、アプリの普通の状態はデータの無い状態なのです。サインアップしたら、ブランク状態から始めます。ウェブログで特にそうである様に、アプリはそこにあるデータ次第なのです。記事、リンク、コメント、時間、サイドバーにある情報、その他のデータ。人々がそういったデータを入力するまで、全体の見た目や感触というのは形作られないのです。

    残念ながら、顧客はそのアプリケーションが価値のあるものかどうかを、ブランク画面で決めてしまいます。この画面は、情報量、デザイン、コンテンツでは最小のものしかありませんが、アプリケーションの全体的な使いやすさの判断材料となっています。適切なブランク画面をデザインできなかった時、何も無いため、ユーザーは何が欠けているのか分からず。

    それなのに多くのデザイナーやディヴェロパーはこの段階を省きます。この人たちがアプリを開発したり使ったりする時には、テスト目的のため自分たちで入れたデータでいっぱいになっているので、ブランク画面をデザインするのに多くの時間を割くことをやり損ないます。ブランク画面に出くわすことすらないのです。確かに、この人たちも新しいユーザーとして何度かログインするでしょう。しかし大半の時間は、データで満たされたアプリの中を泳ぎまわっているのです。

    わかりやすいブランク画面には何を含むべきか?

    第一印象は決定的です。もし配慮のあるブランク画面をデザインできなかったとしたら、アプリケーションやサービスについてマイナスの(そして誤った)印象を生み出すことになるでしょう。

    2回目のチャンスはない

    Mac OS X のUIで、スティーブ・ジョブスによって大いに影響を受けたと思われる一面は、セットアップと初回起動時の体験だ。ジョブスは第一印象の重大性を鋭く見抜いていると思う。ジョブスは初回起動時の体験に注意を向けて考えていると思う。それはユーザーがMacで体験する全てのことの1000分の1のことにすぎないかもしれない。しかしそれは最も重要な1000分の1なのだ。なぜならそれが最初の1000分の1であり、ユーザーの期待と第一印象を決めるのだから。

    ジョン・グルーバー, 作家・ウェブディヴェロパー (Interview with John Gruberから)


    守備的

    うまくいかなかった場合のデザイン

    認めましょう:オンラインで物事はうまくいかない。どんなにアプリを注意深くデザインしても、どんなにテストをしても、顧客は問題につき当たるものです。それではこういった避けられない障害にどう対処すればいいでしょうか。守備的デザインをするのです。

    守備的デザインは事故を起こさない運転のようなものです。運転手は常にツルツルした道や危険なドライバー、その他危険なシナリオに対して警戒を解いてはいけないように、サイトを作る人たちはサイトを訪れた人たちに混乱やフラストレーションを起こす問題箇所がないかを常に探索しなければいけません。良いサイト防護は顧客の体験を生むことも変えることもできるのです。

    守備的デザインについて全て語ろうとすれば、一冊の本ができてしまう位です。すでにそんな本があります。_Defensive Design for the Web(「ウェブ用守備的デザイン」)_というタイトルのその本は、エラー画面や他の重大なポイントについて改善をどう行うかを学びたい人にとって良い情報源になります。

    覚えて置くこと:アプリは90%は非常に良く動くでしょう。しかし顧客が望む時に対応してあげなければ、彼等は見捨てられたと思い、忘れることはない。



    一貫性よりも状況

    ここで意味あることはどこでも意味あるとは限らない

    アクションの箇所はボタンであるべきか、リンクであるべきか。それはそのアクション次第です。カレンダーはリスト形式であるべきか、グリッド形式であるべきか。それはカレンダーがどこで表示され、時間区切りがどれだけの長さかによります。全てのページにトップレベルのナビゲーションが必要でしょうか。全てのページの同一で詳細なフッターが必要でしょうか。答えは「時と場合により」です。

    一貫性より状況が重要なのはこのためです。もしそのデザインがより目的について意味を持つのであれば、一貫性がないのも構いません。ユーザーには重要なことを伝えましょう。必要なことを必要な時にしてあげ、望まないことは省きます。一貫性があることよりも状況を把握している方が良いのです。

    理にかなった不一致

    一貫性は必ずしも必要では無い。長い間、UIやユーザーエクスペリエンス(UX)の学生はインターフェースでの一貫性はインターフェースデザインの鉄則だと教えられてきた。それはおそらくソフトウェアでは有効だったかもしれないが、ウェブでは当てはまらない。ウェブで問題なのは、それぞれのページでいかにユーザーが早く簡単にプロセスの次のステップに進めるか、ということだ。

    Creative Goodではそのことを「理にかなった不一致」と呼んでいる:プロセスの上の各ページで、ユーザーがプロセスのその時点で本当に必要としていることが与えられるようにすること。サイトの他のページと一致させるためだけに不必要なナビ要素を付けるのは馬鹿げている。

    —マーク・ハースト、Creative Good の創設者でGoovite.comの制作者(The Page Paradigmから)


    コピーライトもインターフェースデザイン

    全ての文字に意味がある

    コピーライトはインターフェースデザインです。優れたインターフェースが書かれます。全てのピクセル、全てのアイコン、全ての書体が問題になると考えれば、全ての文字が重要であると確信することになります。インターフェースを書いている時、常にそのインターフェースを読むことになる人の立場に身をおきます。人々に何を知ってもらう必要があるのか。どうやって簡潔かつ明白に説明をすればいいか?

    OKあるいは保存、更新、新規、作成といったラベルをボタンに表示すること、それがコピーライトです。3つの文あるいは5つの文を書く?一般的な例あるいは詳細な内容で説明を書く?コンテンツが新しい、更新された、最近更新された、変更された、ということを表示する?「新しいメッセージ:5」と表示するか、「5つのメッセージが新しくあります」と表示するか?あるいは「5」と表示するか、「five」と表示する?あるいは「メッセージ」という言葉を使うのか「ポスト」という言葉を使うのか。こういったこと全てに意味があるのです。

    聴衆と同じ言語を使わなければいけません。作っているのがWebアプリだからといって、専門用語ばかりで良いわけないはず。顧客のことを考え、顧客にとってボタンや文言がどう理解されるのかを考えましょう。多くの人が理解できない省略形の単語や言葉を使用してはいけません。仲間内でしか通じない言葉も使ってはなりません。エンジニアが他のエンジニアに対して話しているような言葉ではいけないのです。短く思いやりのある言葉を使い、必要なことを必要なだけ伝えます。

    良い文章は良いデザインです。言葉がデザインに関係ないことはほとんどありません。アイコンとネーミング、入力欄と入力例、ボタンとラベル、プロセスで段階的な説明、返金ポリシーを明確に説明。これらは全てインターフェースデザインなのです。



    インターフェースはひとつだけ

    通常の画面に管理機能を組み込む

    管理画面 — 設定やメンバーなどを管理するのに使われる画面 — は、どうしようもない代物になりがちです。なぜなら開発時間の大半は一般ユーザーの目に見えるインターフェースの方に時間が割かれるからです。

    どうしようもない管理画面症候群にならない様、管理機能を扱う画面を別に作らないことです。こういった機能(例えば、編集、追加、削除)を通常のアプリケーション画面に組み込みます。

    もし2種類のインターフェース(ひとつは一般ユーザー、もう一方は管理者のための)をメンテナンスするとなると、両方共満足にはいかないでしょう。結局同じ税金を2回払う義務を負わされるだけです。同じことをさせられることになり、それは杜撰さを誘うことになります。気にかける画面が少なくなるほど、画面は良くなるものです。

    隔てのないインターフェース

    アプリケーションは全てだ。アプリケーションの管理領域からどんなことでも直接変更したり追加したり調整したりすることが可能になっている。こうすると、顧客が何を見ているのかが我々にも見える様になり、顧客の抱える問題や疑問をくぐり抜ける手助けをするのに役立つ。それに顧客は、異なるタスクをするために別のインターフェースにログインすることを気にする必要はない。1分間クライアントのアポイントメントを処理して、その次の1分間で新しい従業員を追加することがあるだろう。そんな時違うアプリケーション間をわざわざジャンプしたいとは思わない。だから一貫したインターフェースを維持するのだ。

    —エドワード・ニッテル、 KennelSourceの販売・マーケティング責任者


    コードchapter 10

    より少ないソフトウェア

    コードをできるだけシンプルにする

    コードが2倍になれば、その分だけソフトウェアが複雑になると考えているかもしれません。しかし、実際は、コード量が増えるにつれソフトウェアは指数関数的に複雑になっていきます。ちょっとした機能追加、機能修正、相互依存性、プリファレンス設定などが連鎖的に影響を及ぼしていくのです。危険を顧みずにコードを追加し続けてしまうと、気づかないうちに、恐怖の混乱(Big Ball of Mud:アンチパターンのひとつ;スパゲッティーコード)を作り上げてしまいます。

    この複雑さと闘うには、より少ないソフトウェアだけです。より少ないソフトウェアとは、より少ない機能、より少ないコード、最小限の無駄のことを指します。

    その鍵となるのは、多くのソフトウェアを必要とする難解な問題を、より少ないソフトウェアで済むようなシンプルな問題に変えることです。まったく同じ問題を解決することにはならないかもしれませんが、それで���分なのです。元の問題の80%を20%の力で解決できれば上出来です。その5倍の力で元の問題を解決することをしても必ずしも値しないものです。

    より少ないソフトウェアとは、(占い用の)水晶球を片付けることです。未来の問題を予言しようとするのではなく、目の前の問題のみを扱うです。なぜ?明日への不安は起こらないことが多いのです。幻の問題を解決しようとし、身動きがとれなくなるなんて馬鹿げてます。

    我々は最初からより少ないソフトウェアの概念を中心に製品を設計しました。可能な限り、困難な問題を切り刻んで、簡単な問題にしました。簡単な問題に対する解決法は、実装が簡単なだけでなく、サポートしたり、理解したり、使ったりすることも簡単なのだと。我々が競合と違うのは、この点です。より多くのことをする製品を作ろうとするのではなく、より少ないことをする製品を作るのです。

    どの機能を採用するか否かは、より少ないソフトウェアに関係します。困難な機能要求に「ノー」と言うことを恐れないこと。もし絶対に不可欠でないのであれば、取り除いて、時間・労力・混乱を節約するようにしましょう。

    スピードを落とします。いきなりアイデアに取り掛かるのではなく、一週間、初期の混乱が消えるまで待ちましょう。アイデアを漬けておくことで、脳もより簡単な解決法を見つけられるものです。

    プログラマーが提案できるようにします。
    この様な言葉を聞きたいのなら:「あなたのいう方法では12時間かかるでしょう。1時間でできる方法があります。XはできないけれどYはできます」。ソフトウェアに意見を。プログラマーがベストだと思う方法で取り組んでもらうようにします。

    ソフトウェアを書かなくていい方法を探すことも重要です。画面の文面を変更するときに、ソフトウェアのモデルを変えずにできないでしょうか?例えば、サーバー側で画像処理をするのではなく、決まったサイズの画像をアップロードしてもらうよう提案してみることはできるでしょうか?

    アプリケーションのすべての機能について、あなた自身で確かめてみてください:多くのソフトウェアを必要とせず、その機能を追加できる方法があるか?コードは必要な時にだけ書きます。アプリケーションは無駄がなくなり、健康になるのです。

    ないコードより柔軟性のあるコードはない!

    よいソフトウェア設計の「秘密」とは、コードに何を入れるかではない。コードに何を「入れないか」である!ハードスポットとソフトスポットを見極めることで、スペースを空けることであり、設計を詰め込むことではない。

    —ブラッド・アプルトン、 ソフトウェア エンジニア
    (from There is No CODE that is more flexible than NO Code!)

    複雑さはソフトウェアのサイズに対してスケールしない

    ソフトウェア・エンジニアリングにおいて最も重要なルールは、あまり知られていない。複雑さはソフトウェアの大きさに対して線形に増加しないのである。2000行のプログラムは、1000行のプログラムの2倍以上の開発時間が必要になる。

    The Ganssle Group (Keep It Smallより)


    幸せへの最大化

    チームの刺激や情熱を維持し続けられるツールを選ぶ

    幸せなプログラマーは、生産的なプログラマーです。これが幸せを最大化にする理由であり、あなたがやらなければならないことでもあります。業界標準であったり、パフォーマンス指標に基づいていたりするという理由でツールを選んではいけません。見えないものを見るのです:情熱、プライド、職人気質はありますか?その環境で一日8時間、本当に幸せに働くことができますか?

    これはプログラミング言語を選ぶときにも重要なことです。一般にはそう思われていませんが、言語は皆同じく作成されたものではありません。どんな言語でもアプリケーションを作ることはできますが、正しい選択によって、利用可能なだけでなく、楽しく、刺激的に作ることができます。毎日の作業のちょっとしたことを、楽しいものにするというわけです。

    幸せには連鎖的な効果があります。幸せなプログラマーは間違いません。幸せなプログラマーはシンプルな可読性の高いコードを書きます。さらに、綺麗な、表現力のある、可読性の高い、エレガントなアプローチを採用します。彼等は楽しみます。

    我々のプログラミングの幸せはRubyのなかにあり、フレームワークRailsを使って、その幸せを他の開発者に届けました。RubyもRailsも、人間と人間の幸せを最大化するというミッションステートメントを共有しています。我々はこの2つを組み合わせて使ってもらいたいと思っています。

    まとめると、チームは自分たちの愛しているツールを使って仕事をしなければなりません。ここではプログラミング言語について述べましたが、この考えはアプリケーション、プラットフォームなど、あらゆるものの真理を包含しています。人々を刺激するツールを選びましょう。結果として、エキサイトメントとモチベーションを創造し、より良い製品を生み出すことになります。

    あなたが欲しいエンジニア

    Ruby on Railsでアプリケーションを構築する最大の理由は、エレガントで、生産的で、美しく設計されているからだ。Railsは、そういったことを気にするエンジニアを惹きつける。あなたのチームに必要なのは、こういったエンジニアだ。あなたがマーケットで勝つために必要な、美しく、エレガントで、生産的なソフトウェアを彼らが作り出すからだ。

    —チャールス・ジョリー, Managing Director at Nisus Software (Signal vs. Noiseより)


    コードは語る

    コードの声を聞く

    コードの声に耳を傾けましょう。提案してくれるかもしれません。なにか痛烈な一言を残してくれるかもしれません。落とし穴を教えてくれるかもしれません。新しい方法を教えてくれるかもしれません。コードとの対話で、よりスマートなソフトウェアのモデルが見えてくるでしょう。

    新しい機能を作るのに、何週間と、何千行のコードは必要ですか?そんな時コードはもっと良い方法を、と教えてくれているのです。10時間もかかる複雑な方法ではなく、1時間もあればできるシンプルなコードがあるでしょうか?そんな時も、コードはきっと教えてくれます。コードの声を聞くのです。

    コードはコストもかからず手軽な修正も教えてくれます。簡単な道が現れたら注目しましょう。確かに簡単に作れる機能は、あなたが最初に思いついたものとは違うかもしれませんが、それが十分機能して、他の何かをする時間が増えれば、頂き物です。

    耳を傾ける

    デザインのことは心配しなくてもいい、コードの声を聞いていれば、自と良いデザインは浮かび上がる。技術屋に聞いてみろ。奴らが何かを変えるのが難しいと不満を言うのなら、その言葉を真剣に受け止め、修正の時間を設けるのだ。

    —マーティン・ファウラー、『ThoughtWorks』主任研究員 ("Is Design Dead?"より)

    コードを取り除こうとしたプログラマーが払われたら…

    もし、プログラマーが新しくコードを打ち込まず、コードを取り除こうとし払われたら…ソフトウェアはより良くなるはずだ。

    ニコラス・ネグロポンテ、マサチューセッツ工科大学 メディア技術科教授
    ("And, the rest of the (AIGA Conference) story"より)


    運営の負債

    コードやデザインの「請求書」

    金の話と言えば、たいてい借金や請求書。コードやデザインの分野でも「借金」はあります。

    機能は果たすが細かいところでは疑問の残るいまいちのコード、それはファイナンスで言う負債です。まあまあのできだが、真にすばらしくはない…というデザインも、結局「借金」になってしまうもの。

    たまにそうするのも悪くはないでしょう。実際に、できるだけ早くGetting Real(現実化する)するには、こうしたテクニックが役立ちます。しかしその内、そうしたものを負債として考え、そうしたコードを清算したり、まあまあのレベル止まりのページのデザインを再び考え直すことは必須です。

    収入の一部を税金として置いておくのと同様、コードやデザインの「負債」を常に清算します。でなければ、元金以上に利子(何かあったときの修理)に時間とお金を割くことになります。



    扉を開ける

    RSSやAPIなどで、データを世界に

    顧客を縛りつけてはいけません。欲しい時に欲しい方法で情報を手に入れられる環境を作ります。そのためには、*データを内にとどめておかず、外に出してしまうのです*。RSSフィードで情報にアクセスできるようにします。別の開発者がツールにプラスアルファしてくれる様APIを公開するのです。そうすれば、顧客はより便利になった製品の可能性を広げます。

    RSSフィードはブログやニュースの最新情報をチェックするのによい方法だと思われています。フィードには思っている以上のパワーがあります。フィードにはまた、顧客がいちいちログインしなくても最新の更新や変化に対応できる方法でもあります。"Basecamp"のフィードをRSSリーダーに登録しておけば、サイトをチェックしなくても、プロジェクトのメッセージやToDoリスト、 重要なお知らせ等をチェックできるのです。

    APIを用いると、開発者が製品を自分のアプリケーションの取り込み、そのアプリケーションの価値が上がります。例えば、『Backpack』の提供したAPIを使って、Chipt ProductionsはMac OS X用 ダッシュボード ウィジェットを作りました。ウィジェットにより、リマインダーや、アイテム・リストなどをデスクトップから追加・編集できるようになりました。顧客の中には、こうしたウェジェットが『Backpack』の普及のキー・ポイントだったという声さえありました。

    こうしたブーメラン効果を狙ってデータを公開している企業をいくつか挙げてみましょう:

    ウィジェットが違いを導く

    37signalsがBackpackのリリース、私の第一印象は…「え?」

    Chipt Productionsが、MacのTiger向けに『Backpack』のウィジェットを発表した頃。それは、ダウンロードせずに試せる部分が画期的だった(ダウンロードせずにはいられなかった)。私は、再び『Backpack』の動向に注目した。結果?全く違ったものだった。

    アイディアがどのようであれ、私は、すぐにウィジェットを使い、タイプしサブミットする - 終わり。Eメールが届き、私の興味をそそるものがあれば、ウィジェットを使い、タイプしサブミットする。ウィジェットは私が使うどのMacでも使える実のブレイン・ダンプである。また、全てウェブ・ベースなので、バージョンや同期の問題もない。どこに行くのか、どのように後でアクセスするのか…といったことを考えなくても、コンテンツをすぐに打ち込むことができるのだ。

    —トッド・ドミネー、『Dominey Design』創始者
    ("Trying on Backpack"より)


    言葉chapter 11

    ファンクショナル・スペックは決して実用的ではない

    機能の書類は書かない

    こうした機能の仕様を書いた書類は、結局ほとんど完成製品と関係がない。その理由は:

    機能スペックはファンタジー

    現実を反映しない。アプリケーションは制作者が作り、デザイナーがデザインし、人々が使用して初めて現実するのです。機能スペックはただの紙に書かれた言葉にすぎないのです。

    機能スペックは妥協を呼ぶ

    皆が関わって幸せになるためにあり、不愉快なぼやけたものは役に立たないものです。厳しい選択、コストのギリギリの調整、そうしたものがすばらしいアプリケーションに必要なのですが、そうした環境ができないのです。

    機能スペックは納得の幻想

    スペック文面で納得するのは、真の同意ではない。同じ内容のものを読んでいても、そこから考えることは人それぞれです。そしてこんなことが後になって起こるのは避けられません:『待ってくれ、私が思っていたのと違う』『は?それは我々が説明したことではない』『違います。我々は皆それに同意しましたし、あなたもそれにサインしたじゃありませんか。』そうでしょう?

    機能スペックにより、最小の情報で重要な決断を迫られる

    製品を作り始めたとき、持っている情報は最低限のものだけです。作れば作るほど、使えば使うほど、その製品を知るのです。何か決める時は、その情報を持っている時で、その前ではありません。

    機能スペックにより、機能が増え過ぎる

    性能うんぬんの世界では、後ろ髪を引かれることはありません。何かを書き起こしたり、何かもう1点ポイントを追加するコストもありません。何か機能を加えることでうるさい奴を静まらせることもできます。そうしてデザインはポイントのために作られ、人のためではなくなってしまうのです。こうしてトップ画面に30ものタブがあるようなやりすぎサイトを作ってしまうのです。

    機能スペックは進化も変化も改善もさせてくれない

    機能は、サインされ同意されるものです。開発中アイディアが誤っていたと気付いても、そのまま進むしかないのです。スペックは始めたものが変わるという現実は分かりません。

    スペックの代わりに何を考えますか?現実に即した代わりの短い書類を作ります。アプリケーションが必要としているストーリーを1つ書いてみましょう。簡単な言葉で手早く。1枚の紙で収まらないのなら、複雑だと言う証拠です。このプロセスは1日以上かからないはず。

    それからインターフェースを作ります。インターフェースは機能スペックに代わるものです。簡単な紙のスケッチを描いて、htmlにコード化してみます。新たな障害を引き起こすテキストと違って、インターフェースのデザインは、皆が理解し納得できるようなものです。

    皆が同じ画面を使えば、混乱は避けられます。皆が見て、使い、クリックし、体感できるインターフェイスを作り、ややこしいコードに悩むのは後回し。可能な限り顧客の経験を考慮します。

    縛るスペックは忘れます。それらにより、プロセスの初期段階から、重要な決定を強いられることになります。スペックから抜け出し、よりローコストで、変化に対応できる様に。

    使用不可能なスペック

    「スペック」は役立たずと言っても過言ではない。私は役に立つ正確なスペックを見たことが無い。

    私はこれまでスペックに基づいて行われたくだらない仕事を多く見てきた。そういうソフトウェア開���は最悪の方法だ。現実ではなく理論に基づき築き上げられたものだからだ。

    —リナス・トーヴァルズ、Linuxクリエイター ("Linux: Linus On" Specificationsより)

    妨害者と戦え

    デザインを考え始める前から、あれやこれやと要求する文章を突きつける人たちを私は「妨害者」と呼んだ。彼等は、進行を遅らせ、デザインやアイディアの改善にも役立たずだ。

    我々の最高の仕事は、サイトの改善、試作品(統計)の迅速な制作、デザインを多少変更し試作品に現実のデータを付加する、こうしたことへのいくつかのコンセプトに基づいている。プロトタイプを立ち上げると、我々はそこから実際のプロジェクトを行い、よい結果を得てきた。

    —マーク・ガラガー、企業向けインターネット開発者("Signal vs. Noise"より)


    死んだ書類は要らない

    不要なペーパーワークにさよなら

    機能スペックから離れるのは良い出発点ですが、そこで終わってはいけません。過剰なペーパーワークもやめます。書類が現実の何かにならないのなら、作らないのです。

    作り、書かない。何かを説明する場合は、実際に試作品や模型を作るほうが紙より説得力があるものです。実際のインターフェイスや試作品は、いずれ現実のプロジェクトになるものです。一方紙切れはゴミ箱行きでしかありません。

    1つ例をあげましょう。もしワイヤーフレームが書かれていて、実際のデザインに直接ならないのであれば、わざわざ書く必要はないのです。もしワイヤーフレームが実際のデザインにつながっていくのであれば、作ります。

    アプリケーションから逸脱した書類は無用です。そこからは何も進展しません。あなたがすること全ては進化の道を辿り実現化しなければいけません。書類が現実に生まれ変わらなければ、死んだも同然です。

    そんなものは誰も読まない

    問題の議論、質問、ユーザーテストは全て開発中されていたのに、ページ数が多いばかりのスペックやビジネス書類が見もされず、開発チームのゴミ箱へ直行したことがこれまでどれほどあっただろうか。私が共に仕事をしてきた開発者でも長々としたEメールや、コード記述のマニュアル紙に大変な時間を割いていたが、そうした文章も結局は読まれない。

    ウェブ・アプリケーションは、決してお定まりのマニュアルどおりに動くものではない。ソフトウェア開発は、メンバーの相互理解、とっさの判断、予期できない問題…といった要素が必ず付きまとう変化の連続である。これらは紙ではどうしようもなく、してはいけない。

    そんなものを作るのに時間を割いてはいけない。どうせ誰も読まないのだから。自身で成長するような製品を考えているのなら、自分の思っているようなマニュアルとは最終的には異なることを肝に銘じておくべきだ。

    —ジーナ・トラパーニ、「Lifehacker, the productivity and software guide」 ウェブ開発者・編集者


    簡潔なストーリー

    説明でなく、ストーリーを書く

    新しい機能やコンセプトについて言葉で説明しないといけなくなった時には、それについての簡潔な話を書きます。技術やデザインを詳述してはいけません。普段の会話の様に、人間的に伝えます。

    論文である必要はありません。起きることのフローがあれば良いのです。もし開発中の画面を添えて文中にちょっとした話を交ぜられたら、なお良いでしょう。

    詳細に時間を取られないで体験にこだわります。手段でなく計略について考えます。一度アプリのある部分について作り始めれば、その部分の手段はそれなりに上手くいくものです。欲しいのは今進行している、会話を始めることも正しい軌道にのることもできる、ストーリーだけです。



    本物の言葉を使う

    ダミーでなく本物の言葉を導入

    ダミーテキスト(アタリ)はデザイナーの頼れる友人です。ダミーテキストはデザインが中身を与えられるとどの様に見えるのかを人々が理解するのに役立ちます。しかしダミーテキストは同時に危険でもあるのです。

    ダミーテキストはテキストの見られ方を変えてしまいます。テキストコンテンツは本来誰かが書き、あるいは読む有用な情報であるべきです。しかしダミーテキストによってビジュアルデザインの一要素—テキストのかたどる形—へと貶めらてしまうのです。ダミーテキストを使うということは、実際の言葉が入れられた時に表れる当然の変化が見えないことです。それはサイトのフォームの使い勝手が分からないでいるのと同じことです。ダミーテキストはあなたと現実の間にあるベールなのです。

    フィールドがどれくらいの長さであるべきかを知るためには実際のテキストが必要です。テーブルがどれだけ広がったり縮まったりするかを知るためには実際のテキストが必要です。アプリが実際どのように見えるかを知るためには実際のテキストが必要です。

    できるだけ早く実際の言葉や意味のある言葉を用います。サイトやアプリケーションでデータを入力する必要がある時は、本当のデータを入れます。テキストは実際にタイプし、他のところからコピーしません。名前であれば、実際の名前をタイプ。市町村であれば実際の市町村をタイプ。パスワードであれば、そしてそれが2回入力を要求されるなら、2回タイプします。

    もちろん、がらくたデータ("asdsadklja" "123usadfjasld" "snaxn2q9e7") でフォームの作成やフィールドの入力を手早くすることは簡単です。しかしそれは実際のものではありません。それは顧客が実際にするであろうこととは違います。顧客が長い道のりを行かないといけない時にあなただけが近道をするのは本当に賢いことでしょうか?でたらめなテキストを高速入力しても、そのフォームを入力することがどういうことなのかを実感することはできないのです。

    顧客がするようにすれば、顧客のことをより良く理解することができます。顧客をより理解し、顧客の感じることを感じれば、より良いインターでフェースをつくることができるでしょう。

    意味のないゴミの様な言葉

    内容がこう「かもしれない」と想像しないことで、デザインの思考はなくなる。「ただの文字の集まり」になってしまうため意味がぼやけるのだ。そうした「ただの文字」は、実際に読まれるものとして認識されないために、間違いなく文字としての価値をなくす。そうした意味のない言葉が実際の内容に置き換えられることにより機会をなくすのだ。意味のない文字を並べるため文章が本当に小さなものになってしまう。それなら真っ白なスペースにしておくほうがまだ良い。

    —トム・スミス、デザイナー・開発者("I hate Lorem Ipsum and Lorem Ipsum Users"より)


    製品の擬人化

    製品の個性は?

    製品を人と考えましょう。その製品にはどのような人になってもらいたいでしょうか。礼儀正しい?厳格な?寛大?厳しい?面白い?無表情な?シリアスな?だらしない?偏屈に見える方、それとも信頼できると思われる方がいいでしょうか?知ったかぶりがいいですか?それともは謙虚だったり感じのいい風に見える方がいいでしょうか?

    一度決めたら、それらの個性を製品を作っている間常に心にとめておきます。コピーライティングやインターフェース、製品機能の指針として利用しましょう。何かを変える時には、その変更がアプリの個性に合っているかを自問してください。

    製品は声を持っています。そしてそれは顧客に24時間話しかけているのです。



    価格と登録chapter 12

    無料サンプル

    何かを無料で

    外は騒がしい世界。そんな騒音の中であなたの製品を知ってもらうためにも、無料サンプルを忘れず。

    優秀な企業は、タダのお試しグッズが顧客を釣り上げるのに格好の餌だということを知っています。例えばアップル。iPodのニーズを高めるためにiTunesという無料ソフトウェアを提供しています。オフラインの世界では、小売直販店が同じようなことをしています。スターバックスは、新規顧客を獲得するのに無料の飲み物5つを提供する、と計算しているそうです。そこをケチってはいけません。

    我々も、『Writeboard』と『Ta-da list』は完全に無料アプリケーションです。我々のほかのアプリケーションを使ってもらうための伏線という位置づけです。同様に、アプリケーションの無料バージョンも順次提供しています。

    我々は、製品、インターフェース、そしてその有用性を体感してもらいたいのです。一度気に入ってもらえたのなら、有料プラン(さらに多くのプロジェクトやページ、そしてSSLでのアップロードのような追加機能)に切り替わってもらう可能性は高いわけです。

    噛み切れるサイズ

    噛み切れるサイズを作る:ユーザーが消化できるサイズに細かく分け、小さくして提供すれば客は釣れるもの。少なくとも1プロジェクト・1サービスを消化できるサイズにし、安価で、シンプルで、面白いものにするのだ。

    —ベン・マッコネル / ジャッキー・ヒューバ、『Church of the Customer Blog』著者
    (What is customer evangelism?より)

    あなたのヒットシングルをプレゼント

    あなたの歌の内一曲を(アルバムの中から)選んで、世界中に無料で視聴できるようにする。そう、映画の予告編のように。ヒットシングルをラジオで流す様に。その歌を聴いた人があなたの音楽を買いたくなる。

    曲の著作権はこの際目を瞑りましょう。人々が曲を聴いて、コピーして、共有する。もし世界中でその曲を聴いてもらえたら、お金を払う人がさらに増えるのと信じて。

    —デレック・シヴァース、「CD Baby」「HostBaby」代表・プログラマー ("Free Promo Track"より)


    やるも止めるも簡単に

    サインアップもキャンセルもストレス無し

    あなたのアプリケーションを使い始める時、*そして止める時も*、できるだけ簡単にできるようにします。

    もし、私があなたのアプリケーションを使いたいユーザーなら、そのアプリケーションは、ストレスや考え込みを防ぐプロセスでなければいけないのです。大きな分かりやすい登録ボタン、それがマーケティングサイトの各々に置かれている、そんな状況です。どれだけ簡単なのか:「たった1分で登録完了!」

    ユーザーがためしにデモ・体験版を使う場合にもクレジットカードのような個人情報の入力がいらない自由な選択があるべきです。競争会社の中には、体験版を使うのに電話認証やアポイント、特別なパスワードを求めるところもあります。一体何?我々の向かう所は、皆がアプリケーションをいつでも自由に試してもらえる環境です。

    利用登録のフォームはできるだけ短く。必要のない項目、やたらと長いフォームは厳禁です。

    同様に登録解除・脱退の時にも当てはまります。人々をいつまでもあなたの製品の中に閉じ込めておくことは望まないはず。例えば、人が我々の"Basecamp"の使用をやめるときは我々も残念に思いますが、決して脱退のアクションを妨げたり、複雑にしたりしません。アカウントのページには「アカウント削除」をはっきりと載せています。Eメールを送ったり、特別なフォームや埋めたり、質問に答えたりする煩わしさはないのです。

    同時に、人々がサービスを止めると決めたときに中のデータを取り出せる配慮も必要です。我々は、全てのメッセージやコメントをxmlフォーマットでいつでもエクスポート(抽出)できるようにしています。システムはともかく、作ったデータは本人の物。それを好きな様にするのは当然でしょう。

    これは重要なことです:人々が自分たちの情報をコントロールできるようにすることで信頼が生まれるのです。例えるならば、データの島への橋渡しです。ユーザーがほかに更に良い提供物を見つけたのなら、何の障害もなくそのサービスへ移れるようにしてあげます。それは正しいことであり、またそういう善意が大切なのです。

    簡単に止められる様に

    ユーザーの意思に逆らって彼等を押さえ込まないことです。もしユーザーが止めたいと思った時は、サイトに書き込んだコンテンツを無料で取り出せるようにすべきです。止めたいユーザーは無理に引き止めずに止めさせてあげましょう。そして、自分たちのサービスの向上に集中をしましょう。戻って来たいからで、閉じ込められたため留まっているのでは無く。

    —チャーリー・オドネル、『Union Square Ventures』アナリスト
    ("10 Steps to a Hugely Successful Web 2.0 Company"より)


    トリックは子供騙し

    長期契約や初期費用は無用

    誰でも長期契約を結んだり、解約料金や初期費用を取られたりするは嫌なものです。できるだけ避けます。私たちのサービスの料金体系は毎月請求となっています。契約書というものも特別締結するわけではありませんし、いつでも解約料金なしで解約をすることができます。もちろん初期費用なんてもらいません。

    金儲け目的でトリックをするのではなく、正直に儲けます。



    やわらかい弾丸

    悪いニゥースは前向きな話から

    物価上昇の様な悪いニュースを伝えなければならない時には?多くの前向きな話をできるだけ早めに伝え、悪く受け取らせないことです。また、「祖父時代」(grandfather period/clause:米語、前のルールがしばらくの間続く・続かせること)を考えます。そうすることで、現在の顧客がある時期まで以前のルールで続けることができ、しばらくの間更新されたルールに従わなくても良いのです。そうしたことが、あなたの血となり骨となる顧客のために、そして彼等が邪魔者と見られず、価値のある者と思われていると確信させるためにも必要となるでしょう。



    プロモーションchapter 13

    ハリウッド式リリース

    発表から試写会、リリースへ

    もしアプリが森の中でリリースされ、そこに人がいなかったとしても、評判を呼ぶでしょうか?ここで言いたいのは、あらかじめ宣伝をしないでアプリをリリースしても、人々は知ってくれないということです。

    評判と期待を起こすのに、ハリウッド式に1)発表・ティーザー、2)試写会・プレビュー、3)リリースといきましょう。

    発表

    リリースの数ヶ月前に手がかりをぽつぽつと落とし始めます。何に取り組んでいるのかを人々に知ってもらうのです。ロゴを掲示したり、開発についてブログをつけたり。あいまいなまま、種を植えましょう。そして興味を持ってくれた人たちからのメールを受け付けるようなサイトを立ち上げます。

    この段階で、達人や内部の人々を誘惑することも始めるべきです。最先端にいるのはこういう人たちで、流行を作り出す人たちです。この人たちの見栄と時代を先取る立場に訴えかけます。未公開の特別試写会が見れると宣伝します。もしBoing BoingやSlashdot、Diggのようなサイトがアプリについてリンクすれば、多くのアクセスと追従してくる人を得ることになります。そして、Googleでのランキングも上がります。

    試写会

    リリースの数週間前には、機能のプレビューを始めましょう。舞台裏の世界へ人々を招待し、製品のテーマを説明します。Basecampの時は、スクリーンショットを見せ、リマインダーやマイルストーンなどの機能を呼び物としました。

    また、そのアプリの裏側にあるアイディアや理念を人々に伝えます。Backpackの時には、リリースの前にマニフェストを掲げました。これによって人々はBackpackについて考えたり話し合ったりするようになったのです。

    一部の人に対してはアプリを先に使い始められる"ゴールドチケット"を渡すのも良いでしょう。先駆者であることで得られる特別な心地よさをその人たちが感じている間、あなたはベータテスターがいるという利益が得られます。

    また一方では、人々がサインアップするよう促します。リリースした時にキャンペーンを仕掛けるためのメールアドレスリストを得るためです。アプリをリリースする時には、牽引力を得るのに大変役立つことになる数千のメールアドレスを得るのです。

    リリース

    さあリリースです。人々は実際に"映画館"へ行ってアプリを見られるます。サインアップした人にメールを送ります。宣伝サイトも立ち上げます。できるかぎり福音を広げましょう。自分たちへリンクしてくれるブログを味方にします。どれだけの人がサインアップしたか、なにが更新/調整されてきたか、などの進展をブログへ掲示しましょう。勢いのある内、地道な努力をしているところを示すのです。

    公開への道のり

    「Blinksale」の実質的な見込みができてから、我々はメーリングリストを立ち上げた。それは我々のプロジェクトについて情報を受け取りたいという人たちのためのものであり、彼等にはティーザーを出した。もし、メーリングリストのグループと話ができるのなら、そこはスタートに最適な場所になる。

    次に、我々は許可を取り、製品についてより多くの人に話し合ってもらおうと試みた。『Blinksale』公開の半年前頃、インボイスをオンラインで簡単に送る方法をあらかじめ載せたページを立ち上げた。このページは、疑問等に関する情報を提供したが、内密の情報にまでは触れる必要はなかった。目立つ様、ページ中、ニュースレターの送信フォームをEメールだけで(あくまでシンプルに)、興味深い者が製品公開時に知らされるようになっていた。

    我々は、製品に興味を持ってくれる友人や同僚に製品を広めた。彼らはブログらホームページで我々のメーリングリストを口コミで広めてくれる。数日後、我々のメーリングリストは、何千もの登録者がついた。彼らは非常に重要な人たちである。彼等は、我々の製品についての質問をしてくれたり、公開の時を知りたいという人たちなのだ。

    最終的に、公開の約2週間前に我々は数えるほどの友人や同僚・専門家らに『Blinksale』ベータテストへ招待した。これにより、使ってもらい利益が出るだけではなく、公開時に製品を口コミで広げてくれる人に試してもらえる。重要なのは、我々は誰にも強要をしていないところだ。我々は単に製品を見てもらい、公開時に製品について話し合ってくれる人たちを探しただけだ。最後に、もしこの様な方法を用いるのなら、あなたの製品は送付できることを知っておかなければならない。さもなくば、雨も降らせない雲になってしまうのだ。

    公開日が来たら、我々はメーリングリストにメールを送り、ブロッガーの友人達に知らせ、テストユーザーたちにその感想を広めてもらおうと心がけた。そして、うれしいことに我々の努力は実を結んだ。公開後すぐに、何万ものユーザーが我々のサイトを訪問し、何千ものユーザーが登録してくれたのだ。

    —ジョシュ・ウィリアムス、『Blinksale』創始者


    パワフルなプロモサイト

    プロモサイトで人々に製品を紹介

    一番のプロモーションツールは優れた製品です。この製品は便利だと思ってくれている人がいれば、評判がきっと生まれます。

    それでも、優れたプロモーションサイトは必要です。このサイトには何があればいいでしょうか?候補をあげましょう:



    ブログの波に乗る

    ブログは広告よりも効果的(安くすむ)

    広告は高くつきます。さらに様々なタイプの広告の効果を評価することは、広告自体よりも高価になってしまいます。従来の広告のルートに乗る時間や資金がないのであれば、代わりにブログによるプロモーションについて考えてみましょう。

    ブログは、宣伝だけでなく役に立つアドバイスやヒント、コツ、リンク等を提供します。私たちのSignal vs. Noiseというブログは、役立ち参考にもなり興味を引く例やコツを毎日ポストすることで、1週間にユニーク数で数千の読者を得ています。

    私たちの最初の製品であるBasecampのプロモーションも、そのブログから始めました。ブログにBasecampという言葉を載せると、それは広がり始めました。ジェイソン・コットキーや、Boing Boingの執筆陣、ジム・コウダル、その他いろいろな有名ブログの人々が、認知度を上げてうまく事が進むことに一役買ってくれました。

    Ta-da Listsもブログベースのマーケティングの力を示す良い例です。ブログではひとつのポストだけ書いてTa-daをリリースしたところ、数週間後には200以上のブログで言及され、12000人以上がサインアップしてTa-daアカウントを持つようになっていました。Backpackはさらに速く広まりました。リリース後24時間で、10000以上のサインアップがありました。



    早めに勧誘する

    できるかぎり早い評判とサインアップを手に入れる

    既に触れたことですが、もう一度繰り返す価値があります:なるべく速くサイトを立ち上げ、メールの受付を始めましょう。ドメイン名を選びロゴを飾り、そしてアプリの機能について1つか2つの説明、少なくともなんとなく分かる手掛かりを載せます。そしてメールアドレスを登録してもらいましょう。これでリリースの知らせを準備して待ってくれる人達を獲得する道筋ができました。



    教えることでプロモーションする

    世界と知識を分かち合う

    クイズ番組Jeopardyの司会者アレックス・トレベックは、教諭が出場者として登場すると、よく教職を「崇高な職業」と評します。そのとおりです。知識を他の人々と共有することには間違いなく素晴らしく実りあることです。そしてあなたの講義内容が自分たちのアプリについての時、2つのことに役立ちます:*あなたたちを支持してくれるコミュニティに何かを還元できることであり、同時にプロモーション面でも良い露出になるのです。*

    プロモーションのテクニックとして、教育はより多くの人目の中であなたたちの名前、そして製品の名前を知ってもらえる柔らかな方法の一つです。「この商品を買いましょう」と強引に売る方法でなく、価値あるサービスを提供することで関心を集めることになります。これによって従来のマーケティング手法には手が出せない好意的な評判を生むことができます。教えてあげた人たちが伝道師になってくれるのです。

    教えには色々な方法があります。人々が他の人と共有したいと思うようなヒントやコツをサイトに載せる。カンファレンスでスピーチをし、それが終わった後も参加者と挨拶を交わすために会場に残る。好奇心の強いファンがより多くを知り、あなたとも直接話せるワークショップを開く。メディア向けに会談をする。役立つ情報を共有する記事を書く。そして本も書く。;)

    私たちの経験から例をあげると、イエロー・フェイド・テクニックがあります。これはページ上で変更した箇所をうっすらと目立たせる方法です。これをブログに書いたところ、あちこちに飛び火してもう何千ものアクセスがありました(今でも多くのアクセスがあります)。

    この記事は教育の面でもプロモーションの面でも功を奏しました。一つの知恵を知ってもらうことができましたし、わたしたちの製品について知りえなかった多くの人も製品を知ることになりました。

    別の例として、Ruby on Railsの開発中にこのフレームワークをオープンソースにすることを決めました。これは結局賢明な処置となりました。我々はコミュニティにお返しをし、友好を深め、我々のチームについて知ってもらい、有益なフィードバック等を世界中から受けました。さらにプログラマー達がパッチや協力を送ってきてくれるようになりました。

    教えることはすべて良い因縁につながります。将来に投資することですから。他の人を助けることで、健全なプロモーション効果を得ることでもあります。そしてちょっとした崇高さに浸ることができます。あなたが知っていることで世間が聞きたいことは何でしょう?

    社会に還す

    我々のブログの記事とヒントの部分は、我々のサイトで一番人気がある。Eメール・マーケティングについての知識は、顧客に製品以上のものを提供した。もし彼らが自身の顧客によりよいサービスを提供したのなら、更なるビジネスの可能性を広げる。そしてそれが我々に更なるビジネスを創造させる。皆ウィン・ウィンである。

    我々の知識の自由な共有により、またその分野でのエキスパートとしてのポジションが確立し、既存顧客との関係強化にもつながる。彼等は我々の仕事の質へのこだわりを知っている。最終的に、読者を結び付けてくれる検索エンジンやブログのトラフィック増に結びついていくのだ。彼等は、我々がそんな記事を書かなかったら、ソフトウェアの存在自体を知らないままだったユーザー達である。

    —デイビッド・グレイナー、『Campaign Monitor』創始者


    機能を餌に

    飢えているから与える

    新しい/興味深い機能はアプリケーションについての評判を生み出すのにもってこいの方法です。特別興味を持ってくれている人たちは”機能食”を噛み砕くのが大好きで、砕いたものをコミュニティに戻してくれます。ちょっと不愉快な例えですが、要点は分かっていただけたと思います。

    例として、新しい開発プラットフォームのRuby on Railsを利用したことで、Basecampへの多数の関心をディベロッパーコミュニティの中に生むことができました。

    私たちのアプリケーションの中で使ったAjaxのテクニックは多くの評判を呼び、さらにBusiness 2.0誌ではGoogleやYahoo、Microsoft、Amazonと並んで37signalsが「Ajaxの立役者」と評されました。

    別の例では、RSSがビジネスで始めて使われたケースの一つとして、BasecampのRSSサポートにブロガーが注目したことがあります。

    iCalの導入も一見したところ重要でない機能のようですが、これによってBasecampに言及したことがなかったMac関連サイトからも非常に多くの評判を受けました。

    少数チームは新しいアイディアをソフトウェアに導入する上で有利です。大きな会社では官僚的な邪魔に対処しなければならないのに、少数チームは新しいアイディアを素早く実装してそれを使ってもらうための関心を集めることができるのです。

    流行の技術の七光に便乗するのは評判を呼ぶのに効果的でコストのかからない方法です。とはいっても、いくらかの注目を集めたいがためにあまり得体の知れない最新技術を導入しようとしてはいけません。何か新しかったり注目に値することを生かしているなら、それを押し進めて特別興味を持つグループに対して目立つようにします。



    ログを見る

    評判の追跡のためにログを調べる

    誰があなたの話をしているかを知らないといけません。ログをチェックして評判がどこからやってくるのかを見つけ出しましょう。誰がリンクしてきているのか?誰が文句を言って陰口をたたいているのか?TechnoratiやBlogdex、Feedster、Del.icio.us、Daypopに載っているブログでどれがあなた達のことを言っていたか?

    見つけ出したら自分たちの存在感を感じさせましょう。ブログにコメントをする。リンクしているポストについて礼をのべる。特別優待リストに入りませんか、そうすれば機能のリーリースや更新などについて最初に知ることができますよ、と勧誘してみる。好意的な評価を集め、自分たちのサイトのページに「評判」を作りましょう。第三者の賞賛は多くの人にとって信頼がちなので、推薦状はアプリのプロモーションに優れた方法です。

    コメントが好意的でない場合でも注意して見ましょう。耳を傾けて、批判には思いやりをもって対処します。「フィードバックをありがとうございます。どうしてこの方法にしたかというと...」とか「良い点を指摘してくださいました。現在わたしたちはそれについて取り組んでいるところです。」という様にです。批判を懐柔して、製品には人間的な顔を持たせることができます。ブログに思慮あるコメントをすることで反対派が消散し、批判者が伝道師になることだってあるんですから。



    アップグレードをアプリの中で進める

    アプリケーション内でアップグレードを促進

    販売サイトで製品を売り込むことは常識です。しかし売り手はここで立ち止まっていてはいけません。もし数段階の価格設定がある(またはアプリのフリーバージョンがある)のであれば、忘れずに製品内でアップグレードの声掛けを行いましょう。

    アップグレードすれば制限が徐々に外されて行くことを伝えます。Basecampの場合、フリーアカウントではファイルのアップロードができません。誰かがファイルのアップロードをしようとした時、その人を立ち去らせません。その人になぜアップロード機能が利用できないのかを説明し、有料バージョンにアップグレードする様すすめ、なぜその方が有利か説明します。この方法は、現在のプランの機能を使い切っている既存の顧客に対しても、より上級レベルのアカウントへアップグレードする様すすめる時に使えます。

    既存の顧客はセールスにとって最も有望な人たちです。既に製品を知って使っていてくれている人々と繰り返し取引をしようとすることをためらってはいけません。



    釣針名前

    アプリには覚えやすい名前を付ける

    多くの人が思い込んでいる大きな間違いの一つは、アプリの名前が機能を一言で説明しなければいけないということです。機能の目的を鮮やかに描き出すような名前を付けることに頭を悩ます必要はありません:ありきたりで忘れられやすい名前になるだけです。Basecampは、プロジェクト・マネジメント・センターやプロジェクトエクスプレスなんてものよりも良いネーミングです。コラボエディトよりWriteboardの方が良いでしょう。

    複数ユーザーに意見を求めたり、ネーミングプロセスを委員会的にしすぎないことです。名前は短く、キャッチーで覚えやすいものを選ぶ:それで良いのです。

    また希望したドメイン名を取得できないことを心配する必要もありません。数文字を付け足せば、独創的かつ製品名に近いドメインを見付けられるでしょう(例:backpackit.com、campfirenow.com)。

    容易に

    ハイテク産業が気づくべきところは、覚えやすくてはっきりしたネーミングこそ産業のためにもなる、ということではなかろうか?製品が何であろうと、売り上げがあがるはずだ。横柄なエンジニア等はハイテク産業のコミュニティに入っていない消費者を追い払う癖があるが、名前一つで雰囲気を改良することができる。テクノロジーも速くそれに追いつくだろう。新製品は容易に説明でき、容易に使え、容易に買える。それは企業にとっても容易に売れる秘訣だ。

    —デイビッド・ポーグ、『ニューヨーク・タイムス』コラムニスト ("What's in a Product Name?"より)


    サポートchapter 14

    同情

    サポートと開発の軋轢

    レストランでは、厨房とホールスタッフの仕事は根本的に異なります。お互いの仕事を理解し合い、思いやりを持つことが大切です。料理学校やレストランでもシェフやコックが厨房を離れ、ウェイター・ウェイトレスのような顧客と直接コンタクトを取れる場に出ることで最前線のリアルな様子を見ることができるのです。

    ソフトウェア開発者の多くもその様な違いがあります。デザイナーやプログラマーは言わば厨房、サポートスタッフが顧客と直接接するホールスタッフです。残念なことに、ソフトウェアのシェフ達は顧客の生の声を聞くことがないのです。顧客に耳を傾けることは製品の強み・弱みを知る最良の方法であるに関わらず。

    解決法は顧客と開発&デザインチームの壁を取り除くところからです。*サポートサービスをコールセンターや外の業者に投げてしまうのはいけません。*自分でやりましょう。あなた、そしてあなたのチーム全体が顧客の声を知る必要があります。顧客の悩み事や不便と感じることを知る必要があるのです。不満や批判に耳を傾け、顧客の気持ちに同情する必要があります。

    37signalsでは、サポートサービスのEメールは、実際にその製品を作っている人間が直接返答します。何故?第一にそれが顧客にとってより良いサポートだからです。ソフトウェア開発の脳からの直接の返答ほど確かなものはありません。また、その製品を使っている人、そして彼等がつまづいているトラブルが何か、を直接知ることができます。顧客がイライラしているなら、我々もイライラします。我々は「お気持ち察します」と言いますし、実際そうです。

    顧客の抱えるトラブルを統計分析に頼ることも可能ですし、その方が簡単です。しかし、統計は生の声とは異なります。顧客のリアルな声との軋轢を極力取り除くことが必要です。

    最前線こそアクションある場所です。そこに行き、あなたのシェフはウェイターの仕事をする。顧客のメールを読み、イライラの不満に耳を傾け、彼等の提案を聞き、彼等から学ぶのです。

    仲介業者のカット

    "Campaign Monitor"の開発のほぼ全てにおいて、サポートとマーケティングは、2人で行っていた。開発チームの拡大を余儀なくされる中でも、サポート・サービスを開発チームから分けなかった。全てのリクエストに1つ1つ答えることにより、顧客と気持ちを共にし、顧客の視点で物事を考えたのだ。

    顧客が何を必要としているのかでは無く*何故それを必要としているのか*、それを理解することが重要である。しばしばこうした状況はデザインをどの様にするか考える上で大きな影響を与える。仲介を無くす。顧客の間近で彼等の声を聞けば、顧客の望むものを提供するのは簡単だ。

    私は、このことについて、多くの人と議論してきた。そして第一の返答はこうである:「サポートは下級職員を雇えば?」。顧客の立場に入らなくてはいけない。もし、あなたが自分好みのステーキが欲しいなら、バス・ボーイと話すよりシェフと話した方が良いだろう。

    —デイビッド・グレイナー、『Campaign Monitor』創始者


    練習無し

    事前のヘルプ・FAQで、脱マニュアル・脱トレーニング

    YahooやGoogleやAmazonを使うのにマニュアルは必要無い。そう考えるとマニュアル無しの製品を作ることの重要性がわかるはずです。練習無しのツールを目指しましょう。

    ではどの様に?そうですね、この本のテーマに戻りますが、何事もシンプルに行うところからです。アプリケーションが複雑でなければ、ユーザーは使い方で頭を悩まさないはずです。その後、サポートを考える上での重要なステップは、あらかじめ混乱しそうな部分にヘルプやよくある質問を書いておくということです。

    例えば、我々は"Basecamp"でロゴのアップロード方法をあらかじめ画面でサポートしていましたが、中にはブラウザのキャッシュの問題で古いロゴのままになっているユーザーもいました。そこで、「ロゴ送信」エリアを考え直し、新しいロゴが見えるようにブラウザのリロードを促すFAQのリンクを作りました。このFAQを作るまでに毎日この問題について5件ペースでメールが届いていましたが、今はゼロです。



    返答は素早く

    サポートの即答はタスクの最優先事項

    顧客の質問への迅速な回答は重要です。顧客は回答を何日も待つことがあります。ひどい時には全く返答無し。そのため、競合他社との差別化を考えた際にも適切な返答を迅速に行います。我々のサービスでも、営業時間内ではサポートに届いたメールの90%を90分以内、_ケースによっては30分以内_に回答しています。そうしたことが顧客との長期的な友好関係を築くのです。

    完璧な答えでなくても、とりあえずは何か即答で返答しましょう。率直な、正直な回答を迅速にします。すぐに改善できない様な問題であっても、「あなたのご意見確かに頂戴いたしました。ご意見を参考に今後の改善に努めています。」という様な趣旨の文章を迅速に送るべきです。それが、後々ネガティヴな状況に陥るのを防ぐ最良の方法なのです。

    迅速な対応とその率直な回答を顧客は評価し、怒りの姿勢が誠実な態度に変わる場合もあります。

    「多く」の援軍

    わずか開発者3人の小さなチームが革新的な製品を創り、大きなライバルたちを打ち負かした…その秘訣は何か?多くの『援軍』がいたからである。

    開発のスタートから、あなたの顧客は最高の援軍となり、長い目で見た成功に必要な存在となる。ユーザーのコミュニティには最大限の敬意を払うべきだ。小さなチームで大きな巨象たちに立ち向かう方法は、顧客の1人1人に注意を払うことである。

    始めにバグを指摘してくれる、開発者が気付かないようなニーズを要望してくれるのは顧客です。そして、口コミ塔としてあなたのメッセージを広めてくれるのも彼等なのです。

    これは、製品は始めから完璧でなければならないという意味ではない。その全く逆で、リリースをできるだけ早い段階で、頻繁に行うことが重要である。ユーザーがバグを発見した時には、彼等の行動に感謝の言葉を送ろう。

    顧客は、完璧な製品やニーズを完全に満たす特徴全てを期待はしていない。しかし彼等の声に耳を傾け、彼等の意見の反映しようとする姿を期待しているため、そのような態度を見せるべきだ。これは、大企業の多くが実践していない。だからこそ、コミュニティを早い段階から発達させるべきである。

    "Blinklist"のサービスでは、全てのユーザーのEメールは(我々が寝ていない限り)通常1時間以内に返信している。また、我々はオンラインの掲示板を設置し、各々の書き込みにきっちりとコメントしている。

    同時に重要なのが、開発者全員が顧客のフィードバックを受け、オンラインの掲示板の話し合いに積極的に参加していることである。この方法で、ゆっくりであるが確実に、活発な重要な"BlinkList"のコミュニティを作り上げているのだ。

    —マイケル・レイニング、『Blinklist』共同創始者


    タフな愛

    顧客に「ノー」と言う勇気

    機能へのリクエストに関しては顧客は常に正しいとは限りません。顧客のリクエストにいちいち反応して機能を付け足し続ければ、誰も欲しいと思わない製品が出来上がるのです。

    もし、我々が顧客のリクエストに従っていたら、"Basecamp"のアプリケーションは、すばらしいタイマー機能、すばらしい支払い機能、すばらしいミーティングのスケジュール機能、すばらしいカレンダー機能、すばらしいタスクシステム機能、すばらしい即席メッセージ・チャット機能、すばらしいWiki機能、その他にも想像できないすばらしい機能がついたかもしれません。

    しかし、顧客が結局一番に求めたのは"Basecamp"をシンプルにするということでした。

    他の例を挙げましょう。不満の声もあったものの、我々の製品はInternet Explorer5をサポートしないことに決めました。それはマーケットの7%を見捨てるということでした。しかし、我々は残りの93%を重要と考えました。 IE5のバグ修正とテストに時間をかける価値はなかったのです。その時間を他の人のために製品の向上として費やした方が良いと思ったのです。.

    ソフトウェア開発会社として、フィルターとして働かなければならないのです。皆が求める全ての提案が正しいとは限りません。我々は顧客の全てのリクエストを考慮しますが、いつも正しいとは考えてはいません。時々人々の提案や要求にノーと言わなければいけない時もあるのです。

    また、開発会社として自分達の製品を愛することも重要です。そして、自分の納得できないことが製品にあればあるほど、その製品を愛せなくなるでしょう。必要ではないと思う顧客のリクエストには応じない、というのも正当な理由の一つです。



    実りある掲示板

    掲示板やチャットをユーザーの相互同士のヘルプの場に

    掲示板やウェブ・ベースのグループ・チャットは、顧客が質問し、他の人の知恵を借りる絶好の場です。間の人間(あなた)を取り除くことで、コミュニケーションのオープンな場を設け、あなた自身も時間を節約できます。

    製品の掲示板では、ノウハウやトリック、機能のリクエスト、経験談…様々なものが書き込まれます。もちろん掲示板は開発者側がサポートを行う場でもありますが、主にユーザーが助け合い、製品の経験を共有するものです。

    あなたも驚くほど人々は他の人を助けたいと思うものです。



    ヘマを公表する

    悪いニュースも公表

    何か悪いことが起きたならば、公表しましょう。誰も気付かなかったとしても、です。/p>

    例えば我々の"Basecamp"、ある夜半の二、三時間だけダウンしました。ユーザーの99%は知らなかったでしょうが、我々は"Basecamp"のブログに「おもいがけないダウン」と公開しました。我々は顧客がそのことを知るべきだと思ったのです。

    ここで、なにか問題があった時の我々の謝罪のサンプルを公開しましょう:「今朝起きたサーバーのダウンにつきまして心よりお詫び申し上げます。データベースに問題がお起き、ユーザーの一部が接続できない形となってしまいました。すでに問題部分は修復し、今後このようなことがない様改善に努めております。今回のサーバーダウンにつきまして、大変申し訳ございませんでした。」

    率直に、正直に、隠し事なき様極力努めましょう。臭いものに蓋は言語道断です。博識なユーザーは最高の顧客です。意外かもしれませんが、あなたの起こした大失敗も顧客にはそこまで深刻に映らないケースが多いのです。あなたが正直であるのなら、顧客は決してあなたを見捨てることはないのです。

    良いニュースと悪いニュースでは、発表の仕方が異なります。悪いニュースは一度に全て隠さずに公表しましょう。逆に良いニュースはじわりじわりと発表しましょう。そうすることで、良いヴァイブスが続くのです。

    素早く、率直に、正直に

    I聞きなれないことかもしれないが、会社にとって一番の武器が悪いニュースを報告することである。これは、先を見越して、会社が弱気な立場、守りの姿勢になるのを防ぐ効果があるのだ。

    —グレッグ・シャーウィン、「CNET」アプリケーション技術部副部長 / エミリー・アヴィラ、「Calypso Communication」代表 ("A Primer for Crisis PR"より)


    リリース後chapter 15

    1ヶ月のチューンアップ

    30日後のアップデート

    素早いアップデートは、流れを作ります。顧客の声を聞いている姿勢と思われるのです。それにより、更なる技能が身につき、新たな波を引き起こします。更に、製品の評価が高まり、口コミやブログでの紹介の機械が生まれるのです。

    素早いアップデートにより最も重要なコンポーネントに焦点が当てられます。追加機能に頭を使うのではなく、コアの機能を完璧にするところから始めるのです。製品と現実の世界の摩擦が起こり、顧客からのフィードバックを受けて、どの部分を次に注目すべきか分かるでしょう。

    こうした小さな積み重ねが、"Backpack"の製品を形作っていったのです。まずベースの製品をリリースした後、数週間後に新たな機能を搭載しました。"Backpack Mobile"は、携帯とタグに焦点を当てました。というのもこれらの機能は顧客が一番欲しいと我々に伝えてきたものだったからです。



    絶え間ない変化と持続

    開発者ブログで製品は生き続ける

    開発・改良の様子はブログで書き続けましょう。製品は生き物なのです。そうした細やかなブログが言わば小さなアップデートにもなるのです(最低週1回;できればそれ以上が望ましい)。

    以下のものを入れましょう:

    ブログは製品が生きている証だけでなく、あなたの会社を親しみある様演出してくれます。個人個人への親しみあるトーンも続けましょう。小さなチームは、時々、自分達を大きく見せて、超プロフェッショナル集団に見せる必要がある、と思い込みがちです。それはビジネス版ナポレオン・コンプレックスです。自分たちの小さな姿を見せても良いじゃないですか。見栄を張らずに顧客と友人のように話せるのですから。

    生きている!

    開発ブログを頻繁に更新することで、ウェブ・アプリケーションの開発が続いていることを伝えることができる。それが愛されている証でもあり、空家ではないことを伝えることにもなるのだ。開発ブログを見捨てると、それは同時に製品の死をも意味し、担当者が運転席で眠っている、と言っている様なものである。

    製品ブログの何よりの重要点は、ユーザーとの会話、そして情報のオープンな共有である。あなたの会社の哲学を伝えてみる良い機会だ。 オープンなリンクと競合製品との議論、新しい機能へのヒント、フィードバックのためのコメントなど…多くの要素がブログにはあるのだ。

    ユーザーと話をし、話を聞くことが生きた製品である。頻繁に開発ブログをアップデートすることにより、コミュニティやあなたのブランドのロイヤリティを明瞭にする。また、無料広報のおまけもある。

    Lifehacker誌の編集者として、私は多くのウェブ・アプリケーションのブログを読んでいるが、特に好きなのが、_Google、Flickr、Yahoo、del.icio.us、そして37signalsの開発ブログである。これらのブログは、ただ一方的にプレス・リリースをし、ユーザーやファンとの会話を行わないウェブ・アプリケーションよりもはるかに素晴らしいものを作っていると私は思うし、それを他の人達にも伝えたくなる。

    —ジーナ・トラパーニ、web developer and editor of "Lifehacker - the productivity and software guide"ウェブ開発者・編集者,


    ベータではない、ベターに

    「ベータ版」をスケープゴートにしない

    最近感じるのが、ずっとベータ版のままにしているものが圧倒的に多いということです。でもそれは言い訳です。果てしないベータ版は、製品を完成する意志がない、と言っているのと同様です。「使ってもいいけれど、完璧でないから、何かあっても責任は取りませんよ」、こんな感じです。

    ベータ版は顧客に責任を転嫁します。自分達のリリースに自信が無いのなら、どの様に世間が認めてくれるのですか?個人レベルでのベータ版は良しですが、一般公開のベータとなれば話は別です。人々の利用に十分ではないのなら、提供しない方がましです。

    決して製品を完璧にするまで公開してはいけないと言っているわけではありません。そんなことはあり得ません。重要なのは、リリースした以上、責任を持たなければならないということです。その部分をはっきりしてからリリースしましょう。さもなくば、言い訳ばかりしているだけです。

    ベータ版には意味が無い

    この様な問題の原因はGoogle等の企業にある。今となっては、開発者達によりユーザーは、「ベーター版」が本当は何も意味しないことを知っているのだ。

    —メアリー・ホッダー、情報分析家・総合デザイナー ("The Definition of Beta")より

    いつも

    私だけ思うことではなく、我々はいつもベータに入り浸っている?

    —ジム・コーダル、『Coudal Partners』創始者


    バグは全て同等ではない

    バグに重要度ランクを(中には無視するものも)

    製品にバグが見つかったからといって、パニックすることはありません。全てのソフトウェアにはバグがあるものです。

    全てのバグをすぐに直そうとする必要はありません。多くのバグは煩わしいものの、製品を破壊するほどのものではありません。煩わしさは少しの我慢で何とかできます。「良くないような」エラーや、不細工なミス程度のものなら、とりあえずは退けておくことができます。しかし、バグがデータベースに危害を与えるようなレベルであれば、直ちに修理にかかりましょう。

    バグに修復にも優先順位をつけましょう。どれくらいのユーザーへの影響がありますか?このバグはすぐにでも取り掛からないといけないのか、それとも待つことができるのでしょうか?非常に多くのユーザーに非常に大きな衝撃を与える様今何ができるでしょうか?現状のバグ修正以上に、新機能の追加が寄り重要な場合もあります。

    また、バグという言葉を恐れる様な環境を作ってはいけません。先ほど言いましたが、バグは起こります。いちいち犯人探しをしても仕方がありません。オープンな議論が無く、バグに蓋をして隠してしまうような環境は最悪です。

    そして、我々が以前の項で話した、正直と率直さの重要性をもう一度思い出してください。もしバグについてクレームが来たのなら、正面から向き合ってください。問題を分析し、対処していることを伝えるのです。すぐに直せなくても、どうしてそうなったのか話し、そしてより多くの人々に影響を与える製品の部分にポイントを当て説明しましょう。正直であることが一番の姿です。



    嵐を乗り切る

    波は去る

    何か事を起こす時、そこには必ず波が起こります。新しい機能の追加・方針の変更・何かの削除…そうしたことを行うと、反射的にリアクションが(時には否定的な方向で)現れるでしょう。

    こうした混乱や物事の急激な変化のため、パニックに陥ったり、すぐに何か別のものを変えねばいけない、と思うのは避けましょう。情熱というものは始めは勢い良く燃えます。しかし、こうした24~48時間の時間をしのげば、物事は落ち着くものです。多くの人間は、そのことを深く考えず、使うべきものを使う(場合によっては取り除いたもの無しで試す)前に、反応するものです。なので、ドンと座って構えて、時がすぎるまで行動を起こさない方が良いのです。そうすれば、もっと賢明に反応できます。

    また、否定的な反応こそうるさいもので、肯定的な意見以上に真摯なのです。実際、多くの人に変化を受け入れてもらった時でさえ、否定的な声ばかり聞こえてくるかもしれません。異論を呼びそうな、だが必要な事項から目を離すような馬鹿なことは行わないでください。



    遅れを取らない

    競合相手のニュースフィードに登録

    自らの製品・競合他社の両方のニュースフィード・メールマガジンに登録します(敵を知ることは戦術の第1歩です)。『PubSub』や『Technorati』、『Feedster』等で最新の情報を入手するのです(キーワードは企業名や製品名で)。RSSを使えば、そうした情報が常に最新の状態で手元に届くので便利です。



    巨大化の恐怖

    成熟と複雑化は異なる話

    物事が進むにつれ、あれこれやりたい衝動に駆られるかもしれませんが、恐れないでください。物事が進めば、それだけそんな気持ちも大きくなります。とはいえ、その気持ちの赴くままに進んではいけません。物事が成熟するのに、決して複雑になる必要があるということではないのです。

    宇宙でもどこでも書ける万能ペンになる必要はありません。鉛筆で十分な時もあるでしょう。スイス軍の十得ナイフである必要はありません。スクリュードライバー1本で十分です。5000メートルでも使えるダイビング用腕時計を作る必要はありません。顧客が地上にいて時間さえ分かれば良いのなら、そんな高機能はいらないでしょう?

    とりあえず製品を大きくすれば良い、機能を増やせば良いというものではありません。ややこしくなる第1歩です。

    新しいことは改良されることと同等ではありません。時には製品をそのままにしておくことも大切なのです。

    ここが、従来のインストール型ソフトウェアとウェブ・ベースのソフトウェアとの大きな境界線になります。Adobe・Intuit・Microsoftといった企業の従来のソフトウェアは毎年新バージョンの購入が必要になります。常に新しいバージョンを売り続けなければならないため、何か新しい機能を否が応でもつけなければなりません。そうして製品の肥大化・複雑化が起こります。

    登録型のウェブ・ベースのソフトウェアは、月額のサービス利用料を払うスタイルです。決して機能を追加追加追加して毎年追加購入してもらうものでは無いため、真に価値のあるサービスを提供できるのです。



    流れに乗る

    翻意は悪いことではない

    ウェブ・アプリケーションの美学の一つに、その流動性があります。包み込み、公開後、次のリリースまで何年も待つ…なんてことはしません。常に修正・変化を行うことができるのです。あなたのオリジナルのアイディアは最良のものではないかもしれないという事実を受け止めるのです。

    次世代写真サービス『Flickr』を例に挙げてみましょう。その前身は驚くことなかれ、『The Game Neverending』という多人数オンラインゲームだったのです。クリエイター達はゲームそのもの以上に、ゲームの写真の共有機能に注目したのです(結局ゲーム部分は棚上げされることに)。間違いを認め、道を改め様とする気持ちが大切なのです。

    サーファーになるのです。大海を見つめて、ビッグ・ウェーブのポイントを見極め、調整するのです。



    最後にchapter 16

    さあ、出発しよう!

    やった!

    これまでの長い話、お疲れ様でした。あなたは自身のアプリケーションでGetting Realを行うことができるはずです。最小のリソースですばらしいソフトウェアを作る時は今までなかったはず。良いアイディア、情熱、時間、技能を持ってすれば、限界は果てしなく広がるのです。

    最後にいくつか:

    実行

    皆、本を読み、アイディアを思い浮かべ、ウェブ・デザイナーの素質を持ち(もしくは知人にそういう人がいる)、ブログを書くことができ、共に仕事をする仲間を雇うことができます。

    そうした中で成否の差を分かつのは、実行力です。成功は他でもなくどれほどの実行力があるかによるのです。

    ソフトウェアでは、それは多くの要素をきちんと行うということです。良い文章は書けても、その中の約束を守れなければ意味がありません。コードが欠陥だと、キレイなインターフェイス・デザインなんてものはできません。どんなに良い製品ができても、それを伝えるプロモーションの部分が欠ければ、誰も使ってくれず、せっかくの製品の価値が台無しになります。こうした各要素を結びつける総合力が重要になるのです。

    キー・ポイントはバランスです。どこかの方向に偏ってしまうことは、失敗へつながります。常に弱みを探し、克服しようとする姿勢が重要です。

    人々

    成功したウェブアプリケーションを構築する上で私たちが最も重要だと考えている構成要素を再び強調しておきます。それは携わっている人たちです。方針、中心部分のデザイン、より少ないソフトウェア、これら他の全ての素敵なアイディアは、実装するのに適した人たちが取り組んでいなければ、全く関係無いものです。

    あなたには、自分達がしていることに夢中になる人が必要です。自分たちの技術に関心を持っている人 — そして実際に、それを技術として考えている人。金銭的な報酬があるか否かに関係無く自分達の仕事に誇りを持っている人。95%の人が違いに気付かなかったとしても細部を気にする人。何かすごいものを作りたくて、それ以下では妥協しない人。 他の人を必要とする人。オーケー、最後のは余計ですが、ちょっとしたストライサンド風を入れてみたかっただけです。いずれにせよ、こういった人たちを見付けた時には、彼らを手放さないことです。結局、あなたのチームにいる人達はあなたのプロジェクトと会社を作り上げるか、破壊するかなのです。

    ソフトウェアだけに限らず

    Getting Realのコンセプトはウェブアプリケーションを構築することだけに適用されるのでは無いことを指摘しておきたいと思います。ここに含まれているアイディアを一度理解すると、それがそこら中で当てはまるのに気が付くでしょう。幾つか例を挙げると:

    確かにGetting Realは偉大なソフトウェアを作ることに関して書かれたものです。しかしそこで留めなければいけない理由はありません。これらのアイディアを使って、あなたの人生の異なった局面で適用してみてください。いくつかの素敵な結果に巡り会えるかもしれません。

    報告

    Getting Realに関するあなたのメッセージをお待ちしております。下記のメールアドレスまで、ぜひEメールをお寄せください。 gettingreal [a] 37signals.com jp_getting_real [a] inter7.jp(日本語)

    また、ぜひ我々37signalsのブログ"Signal vs. Noise"へお越しください。Getting Real以外にも、ユーザビリティやデザインを始めとした我々のスタッフの厳選した記事を公開しております。

    お読みいただきありがとうございました。あなたの成功と活躍をお祈り申し上げます!



    37signalsの各サービス



    翻訳について

    日本語版翻訳に関し、下記のボランティアの方々のご協力をいただきました。この場を借りてお礼申し上げます。 (敬称略)Eitan.Komata、Kado Masanorisaxi黒沢 健二美谷 広海Yuka Young(訳・編集)

    本家の英語版は、こちらのページから