はじめにchapter1
*ウェブ・アプリケーションをうまく作りたい？ 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によって、そうしたウェブ・アプリケーションの真価を最大限活用することができます。
すばらしいソフトウェアを作るには…
素晴らしい文章は無駄がない。文章に不要な言葉が入らず、段落にも不要な文章が無い。同じように、図面も無駄な線を極力なくし、機械にも無駄なパーツをつけないものである。これにより、作り手は、詳細を全て短くし、もしくは省いて、骨組みだけの形に仕上げるのではなく、全てを伝えることができるのだ。
—From "The Elements of Style" ウィリアム ストランクJr.
肥大化はもうたくさん
古いやり方：長すぎて、官僚的で、やるべきといわれたことをこなすだけのプロセス→ありがちな結果：肥大化して、忘れられやすく、考えなしに崩されていくソフトウェア。なんてこった。
Getting Realにより省けるもの
- 何ヶ月もしくは何年もかかる長いスケジュール
- 当てにならない機能的スペック
- 収拾のつかない議論
- ダラダラ続くスタッフ・ミーティング
- ムダに多い人員
- 無意味なバージョン・ナンバー
- パーフェクトな将来計画
- やたらと多いソフトウェア設定の選択肢
- サポートのアウトソーシング
- 非現実的なユーザー・テスト
- 無駄な事務作業
- 「トップダウン型」の上下関係
すばらしいソフトウェアを組立てるために、大金や巨大なチーム、または長い開発サイクルは必要ありません。 そういったもののところからは、概してスピードが遅く、中身がはっきりせず、更新・修正が無いアプリケーションが生まれるものです。 現実指向の Getting Real では反対のアプローチを取ります。
この本でわかること
- 自身の哲学を持つ重要性
- なぜ小さな規模がよいのか
- どのようにスリムな構築をおこなうか
- どのようにアイディアを現実にすばやく実現させるか
- どのようにプロジェクト・チームを編成するか
- なぜ徹底してデザインをしないといけないか
- なぜ書くことがとても重要なのか
- なぜ競争を回避するべきなのか
- どのようにアプリケーションをプロモーションし、話題を広げるか
- うまくいくサポートの秘密
- 立ち上げ後、その勢いを保つ方法
- …その他多数。
この本は全体的な考え方を焦点に書いています。あなたが細かなコードやCSSのトリックで泥沼にはまらないように、Getting Realのプロセスの中の主要なアイディアや哲学を中心にご紹介いたします。
この本のターゲットは？
この本を手にとって読んでいるのは、大きなアイディアに興味を持ち、取り組んでいる企業家、デザイナー、プログラマー、マーケッターといった人でしょう。
日進月歩のソフトウェアの世界では、従来のルールに限界が見えます。毎年CD-ROMでソフトウェアを配布しますか？その結果、２００２年のバージョンが世の中にどれくらい残っているかわかるでしょうか？もう役に立たないものについては考えないでいいようにしましょう。ソフトウェアに必要なものは、アイディアをつくり、アプリケーションを作成し、修正をしていくことです。そして、それまでの反省をし、同じサイクルを繰り返すことです。
あるいはアジャイルな開発方法やビジネスの構造を確立させていないが、真剣にそうしたものを勉強したいという人も読んでいることでしょう。
あなたがこういった人にあてはまるようでしたら、この本はまさにあなたにとって読む価値のあるものです。
_注意_: この本は主にウェブ・アプリケーション構築を目的とした内容ですが、この本の多くのアイディアは、ソフトウェア開発以外にも活かすことができます。小さなチーム・組織の概念や、迅速なプロトタイピング、繰り返しの予測…といった多くのアイディアが、起業・執筆・ウェブデザイン・音楽活動といった数多くのクリエイティブな活動に役立つものでしょう。Getting Realは、決してIT分野の一部にのみ適応されるものでなく、一度理解すれば、人生の様々な場面でそのコンセプトを応用することができます。
何者？
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は元々、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"導入例
大企業では、プロセスとミーティングは当たり前のことです。何が顧客にとって「よい」ものなのかという共通のゴールに向かって、プラン立案と細かな議論が何ヶ月もかかります。
そうした状況で、小さくまとまったソフトウェアはよいアプローチですが、ウェブの利用によって我々が想像以上の利点が転がります。導入してください！それが正しいことだったのかどうか、ユーザーの意見を聞きましょう。ほら、あなたがやりたいことがその日のうちに、立ち上げられ実行されるのです！ユーザーの声に勝るものはありません。くどいミーティングと議論を重ねる以上によい結果が得られるでしょう。物は試しです。
言うは易し、行うは難し - これに尽きる。
計画の数ヶ月は必要ない
スペックを記述する数ヶ月は必要ありません。スペックは基礎の部分で、詳細な部分は開発段階で見つけ、改善されるべきだという姿勢です。開発のスタート前に未解決の問題を全て解決しようとせず、全ての詳細を洗い出そうとしなくても大丈夫です。
少ない機能、しかし質の高い機能で。
多くの機能を携えた完全リニューアルでの壮大なアプローチは必要ありません。ユーザーが消化できる小規模が一番です。
小さなバグがあれば、徐々にバグ修正を行うのです。ユーザーのフィードバックが早いほど、結果はよくなります。アイディアは、紙の上ではよくても、実際にはそうでないこともあります。根本的な問題の原因が解ればすぐ対処しましょう。
一度、プロセスを迅速化し、ユーザーのフィードバックに対応すると、ユーザーとの関係が構築されます。思い出してください、ゴールはユーザーが自分たちの行いたいことを行えるというところです。
