見れば見るほどBasecamp社のWebアプリの作り方をまとめた本であるGetting Realの内容に従って作られてるアプリだなとGetting RealをバイブルにしてWebアプリ作成を仕事にしてきた我々としては嬉しくなってしまいます。（2007年の本なのに！）
ただ、業界内で「Getting Real良いですよね、私もすごく好きです。」という人は多いですが「え？あんたの作ってるアプリ全然Getting Real的じゃなくない？」ということがしばしばあります。
フィヨルドブートキャンプの最終課題の「自分で考えたWebサービスを作る」ではGetting Realを読んでからどういうサービスなのかを表現するエレベーターピッチを作ることになっています。
しかし「これってGetting Realに書いてあることと真逆じゃない？ホントに読んだ？」ということが頻繁にあります。
そこでわかりやすいようにWebアプリ作成に絞って（組織論などは除外）Getting Realの中から「Getting Real的なもの」と「Getting Real的でないもの」を僕の理解で抜き出してみました。
Getting Real的でないもの VS Getting Real的なもの
シンプルさ
- 「競合より多い機能」VS「競合より少ない機能」
- 「多くのコード」VS「より少ないコード」
- 「様々なケースに対応できるように作る」VS「一般的なケースにのみ対応したものを作る」
オープンさ
- 「失敗の許されない厳格な雰囲気」VS「失敗を認めやすいオープンな雰囲気」
- 「クローズドなソフトウェア」VS「オープンなソフトウェア」
機能の選択
- 「ユーザーの機能提案をなるべく採用する」VS「ユーザーの機能提案にまずNOという」
- 「ユーザーに何が必要か尋ねる」VS「ユーザーに何が要らないか尋ねる」
- 「ユーザーが柔軟に設定できるようにする」VS「サービス側で考えた一番良い設定を提供する」
段階的な開発
- 「長いリリーススケジュール」VS「短いリリーススケジュール」
- 「最初から大規模なシステムを作る」VS「システムを段階的に大きくしていく」
- 「ユーザー拡大に備えてあらかじめ人員を揃える」VS「ユーザーが増えてから人員を増やす」
- 「新たな機能を完璧にしてからリリースする」VS「新たな機能はベータ版として使ってもらって改良する」
ユーザーの声
- 「自分以外が製品のターゲット・ユーザー」VS「自分自身が製品のターゲット・ユーザー」
- 「ユーザーサポート専門のスタッフ」VS「開発者自身でやるユーザーサポート」
インターフェースデザイン
- 「何でもできるインターフェース」VS「切り詰めたインターフェース」
- 「システムを作ってからデザインを入れる」VS「インターフェースをデザインしてからシステムを入れる」
- 「アウトラインができる前にディティールに固執する」VS「動くものを自分で使ってみてから必要な部分のディティールを調整する」
- 「一貫性のあるデザイン」VS「一貫性よりもコンテクストに合わせたデザイン」
- 「デザインにダミーテキストを使う」VS「デザインに本物の言葉を使う」
- 「文言はインターフェースとは別」VS「文言はインターフェースの一部」
- 「ユーザーが使う画面と管理画面を分ける」VS「ユーザーの画面に管理機能を組み込む」
その他
- 「精巧な仕様書を書く」VS「仕様書を書かない」
- 「初期費用・長期割引・解約料金を設定する」VS「初期費用・長期割引・解約費用を設定しない」
- 「最初のアイデアを守り抜く」VS「最初のアイデアが悪ければ方向転換する」
Getting Realの良さ
Getting Realが衝撃的だったのは多くの点でそれまで良いとされていたことと逆のことを言ったからです。毒にも薬にもならない耳触りの良いあるべき論ではなく「え、そんなこと言い切っちゃって良いの？」というような割り切りと実際にそれを実行してる点に当時の僕らはシビれたわけです。
と僕らが勝手に思ってるので話が食い違うことがあるんでしょうね…。
自分の会社で作ってるサービスや使ってるサービスに対して「ここがGetting Real的」「ここがGetting Real的じゃない」など考えてみるのも楽しいかもしれません。