Getting Real

• chapter 1 はじめに
• chapter 2 導入に向けて
• chapter 3 ムダを省く
• chapter 4 優先順位
• chapter 5 機能選択
• chapter 6 プロセス
• chapter 7 組織
• chapter 8 メンバーを加える
• chapter 9 インターフェース
• chapter 10 コード
• chapter 11 言葉
• chapter 12 価格と登録
• chapter 13 プロモーション
• chapter 14 サポート
• chapter 15 リリース後
• chapter 16 さいごに

---

はじめにchapter1

Getting Realとは？

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

• Getting Real はチャートやグラフ、ボックス、矢印、図式、ワイヤーフレームといったものを使わず、ソフトウェアを構築します。
• Getting Real はスリムです。より小さく、より少ないソフトウェア、より少ない機能、そしてペーパーワークは減らし、本当に必要でないものを除き、すべての面においてスリムです。(あなたが不可欠であると考えることの大部分は実際にそうではないのです)。
• Getting Real はスリムでありながら、実に柔軟性に富んでいます。
• Getting Real はユーザーインターフェース、つまり実際の画面から始めます。ユーザーが実際に使用する部分から始め、そこから逆にシステムへと構築をおこなっていきます。こうすることでソフトウェア全体を変にいじらなくても、きちんとしたインターフェースはできるのです。
• Getting Real は繰り返しながら作り上げる方法であり、変更のコストを抑える方法でもあります。Getting Real はつまるところ構築し、修正を行い、改善を重ねていく方法です。ウェブベースのソフトウェア開発に、これこそうってつけの方法です。
• Getting Real は顧客が本当に必要とするものを提供し、不必要なものは取り除きます。

Getting Realの利点

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

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

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

肥大化はもうたくさん

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

Getting Realにより省けるもの

• 何ヶ月もしくは何年もかかる長いスケジュール
• 当てにならない機能的スペック
• 収拾のつかない議論
• ダラダラ続くスタッフ・ミーティング
• ムダに多い人員
• 無意味なバージョン・ナンバー
• パーフェクトな将来計画
• やたらと多いソフトウェア設定の選択肢
• サポートのアウトソーシング
• 非現実的なユーザー・テスト
• 無駄な事務作業
• 「トップダウン型」の上下関係

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

この本でわかること

• 自身の哲学を持つ重要性
• なぜ小さな規模がよいのか
• どのようにスリムな構築をおこなうか
• どのようにアイディアを現実にすばやく実現させるか
• どのようにプロジェクト・チームを編成するか
• なぜ徹底してデザインをしないといけないか
• なぜ書くことがとても重要なのか
• なぜ競争を回避するべきなのか
• どのようにアプリケーションをプロモーションし、話題を広げるか
• うまくいくサポートの秘密
• 立ち上げ後、その勢いを保つ方法
• …その他多数。

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

この本のターゲットは？

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

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

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

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

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

---

37signalについて

何者？

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

我々のコンセプト

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

我々の製品

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

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

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

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

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

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

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

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

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ロバート・スコブル氏の談。「彼らには支援攻撃をしてくれる上司がいます。そして彼らは、一度に少しだけかじり取ってきて、それを実行し、フィードバックに対応をするのです。」

---

出発点chapter 2

シンプルに構築する

無駄に争わない

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

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

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

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

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

• 「より少ない」特徴・機能
• 「より少ない」オプション・設定
• 「より少ない」スタッフ数・チーム構造
• 「より少ない」ミーティングと曖昧なアイディア
• 「より少ない」約束

---

問題を見つける

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

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

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

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

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

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

---

自分たちでやっていく

資金のかき集めは必要？

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

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

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

限界から創造は生まれる

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

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

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

---

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

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

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

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

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

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

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

• 優先順位

  何が本当に重要かを把握します。今回のメイン・リリースに何を優先すべきか？この規制で、ぐずぐずせずに、はっきりした決断を下さなければならなくなります。

• 現実性

  見通しを立てることは重要です。もし、時間や予算・範囲を定めようとすると、高いクオリティで製品を出すことができないかもしれません。もちろん、「何か」を出すことはできますが、その「何か」は果たして本当に世に送り出したいものですか？

• 柔軟性

  変化の能力は大切です。全てが固定されると、変更するのは難しくなります。柔軟性の要素を入れることにより、あなたの製品作成の経験に基づいたオプションが現れます。柔軟性は、歓迎すべき要素です。

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

---

ライバルを持つ

ケンカを売る

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

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

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

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

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

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

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

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

---

仕事を楽しむ

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

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

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

---

ムダを省くchapter 3

「より小さな」規模

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

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

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

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

• 長い契約
• 多すぎるスタッフ
• 不変な決定
• ミーティングのためのミーティング
• 煩雑なプロセス
• （物理的・精神的に）たまっているもろもろ
• オープンにしないソフトウェア・ハードウェア・テクノロジー
• オープンにしないデータ・フォーマット
• 過去に定められた未来
• 長いロード・マップ
• 会社での処世術

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

• その場の考え
• チーム・メンバーで複数のタスクをこなす（人員削減）
• 規則を無視せず把握する
• より少ないソフトウェア・より少ないコード
• より少ない機能・特徴
• 小さなサイズのチーム
• シンプルさ
• 切り詰めたインターフェース
• オープン・ソースの製品
• データ・フォーマットのオープン化
• 失敗も認めやすいオープンな雰囲気

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

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

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

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

---

変化のコストをおさえる

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

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

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

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

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

---

三銃士

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

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

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

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

---

制限を受け入れる

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

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

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

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

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

• 運営するデザイン会社
• 既存のクライアントの仕事
• ７時間の時差（プログラマーのデヴィッドはデンマーク、そして他のメンバーは米国）
• 小さなチーム
• 自分たちだけでの資金調達

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

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

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

---

ありのままで

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

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

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

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

---

優先順位chapter 4

あなたのアイディアとは

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

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

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

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

• 「Basecamp」：プロジェクト管理はコミュニケーション
• 「Backpack」：人生の未処理事項を集めよう
• 「Campfire」：IMより使いやすいグループ・チャット
• 「Ta-da List」：ポスト・イットへの挑戦
• 「Writeboard」:「Word」よりシンプルなもの

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

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

---

まずは大局から

大局からディテール（詳細）へ

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

• オブジェクト間のスペース
• 完璧なタイプ・リーディング
• 完璧な配色
• 完璧な文章
• ７行のコードより４行のコード
• 90%か89%か
• 760ピクセルか750ピクセルか
• 月5000円か月4000円か

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

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

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

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

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

---

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

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

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

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

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

とにかく進めよう

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

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

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

---

顧客を選ぶ

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

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

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

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

---

規模は後で

いきなり規模を考えない

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

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

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

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

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

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

---

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

ソフトウェアに意見を

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

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

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

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

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

---

機能選択 chapter 5

中途半端でない半分

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

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

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

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

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

---

大した問題でないから

必需品だけ

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

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

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

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

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

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

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

---

ノーから始める

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

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

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

イエスマンになるな

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

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

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

---

隠れたコスト

新機能の値段は？

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

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

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

• 1. ノーと言う
• 2. その価値を証明させる
• 3. まだノーだったら止める；その必要を感じたら続ける
• 4. スクリーン/ UIをスケッチする
• 5. スクリーン/ UIをデザインする
• 6. コード化
• 7-15. テスト＆改良、テスト＆改良、テスト＆改良、テスト＆改良…
• 16. ヘルプのテキストを修正/チェックする
• 17. 製品ツアーの修正（必要であれば）
• 18. マーケティング用コピーの修正（必要であれば）
• 19. サービス規約の修正（必要であれば）
• 20. ルール違反がないかチェック
• 21. 価格構成に影響が出るかチェック
• 22. 公開
• 23. 見守る

---

扱いきれるか？

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

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

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

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

---

人による解決

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

わさび抜きで

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

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

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

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

---

プロセスchapter 6

ソフトを動かす競争

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

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

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

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

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

---

反省（リンス）と繰り返し

繰り返し

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

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

繰り返しは解放に

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

---

アイディアを現実に

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

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

インスピレーション

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

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

紙スケッチ

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

HTMLを作る

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

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

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

コードにする

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

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

---

環境設定は避ける

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

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

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

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

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

押せば引く

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

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

---

「できた！」

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

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

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

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

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

---

現場テスト

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

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

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

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

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