Personal tools
You are here: Home Members Getting Real
Document Actions

Getting Real

by YAMADA Masaki last modified 2006-07-06 00:55

Getting Real - The smarter, faster, easier way to build a successful web application by 37 signals, 2006, https://gettingreal.37signals.com/, pp.171

Ruby on Railsの開発者 37 signals による, 彼らなりのアジャイル. この本は本屋では売っていなくて, https://gettingreal.37signals.com/ からPDFで買う ($19). つまり書くところから売るところまで全部自前で, 中抜き. 1冊売れるごとに著者の懐に2,000円入るというのは, 普通の本ではあり得ない (普通はたぶんその1/10程度でしょう). Ruby on Railsの知名度があってこそ, とは言え, 彼ららしい「クールな」ビジネス・モデルだ. ちなみにそのPDFもロックは一切かかっていない代わりに, 「この本は<買った人の名前>さん専用です」というフッタが全ページに入る.

内容は約14のカテゴリに分けて, 約90個のプラクティス, 原則, エピソードが列挙されている. 文章はちょっとくだけていて, かっこつけているので, 僕には分からないところも多いのだが, 少しだけ日本語で解説してみよう.


まず「getting real」じゃないのは

  • 数ヶ月から数年にわたるタイム・ライン
  • 「絵に描いた餅」な仕様
  • スケーラビリティに関する議論
  • だらけたミーティング
  • 10人ものメンバの「必要性」
  • 意味のないバージョン番号
  • 完全な将来を予測する本当のロードマップ
  • 果てしない環境設定のオプション
  • サポート業務のアウトソーシング
  • 非現実的なユーザ・テスト
  • 無駄な物書き
  • 上意下達

この本を読めば

  • 自分なりの哲学を持つことの重要性
  • 小さくあることの良さ
  • どうやったら作らずにすませられるか
  • どうやったら素早くアイデアを現実化できるか
  • チームの作り方
  • 裏返し設計が必要な訳
  • 書くのが難しいのはなぜか
  • 競争に巻き込まれないようにするべし
  • アプリケーションを宣伝し, キーワードを広めるには
  • サポートを成功させる秘訣
  • 始めてからも勢いを持続させるには

などが分かる.

各章の表題は次のようになっている.

スタート・ライン

作りすぎない -> 競争に巻き込まれない

自分自身のためにソフトウェアをつくりなさい

自己資本でやりなさい -> 外部資金は窮余の策, 制約が創造性を生み出す

時間と予算を固定して, スコープを変える

敵を作れ

つまらないものにしてはいけない

リーンであれ

体重を減らす

変更コストを下げる

三銃士 (最初のバージョンは3人で作る)

制約万歳 - 限界こそが創造性あふれる答えへと導いてくれる

自分自身であれ

優先度

あなたのアプリケーションの本質は何か? (ひとことで)

細かいことは後回し

問題は起こるべくして起こる - それまでは問題に関わり合うな

「正しい顧客」を見つける

スケーリングは後で

頑固なソフトウェアを作ろう

機能の選択

重要な半分から作る

本質だけを見る

「ノー」から始める

どんな機能にも隠れたコストがある

できたものは自分でコントロールできる範囲内か?

できるだけ汎用的な概念に基づいたソフトウェアを作り, その使い方はユーザに任せよう

機能要求は忘れろ

「何が必要か」ではなく「何は要らないか」

プロセス

ソフトウェアを動かすための競争

すすぎを繰り返す

アイデアから実装へ

  1. ブレインストーミング
  2. 紙にスケッチ
  3. HTMLで画面作り
  4. コード化

「環境設定...」はなしにしよう

「できた」ってのが大事

現実世界でテストする

時間軸を縮める - 週や月ではなく時間で

組織

団結

一人の時間

ミーティング中毒

小さな勝利を見つけ, 祝おう

人材

雇用はできるだけしない, するとしても後で

人を雇うなら小さなプロジェクトにテスト参加してもらおう

不言実行

専門家よりは多才な人 (素早く学べる人) を

熱狂している振りはできない

良いライターを雇うと良い

インタフェース設計

まずインタフェース

中心地点 (エピセンター) 設計 - ページの中心から設計を始める

三つの状態 (通常/初期/エラー) を設計する

最初の画面が重要

守りに入る - まずいことが起きることを考えて設計する

一貫性よりもコンテキストが優先

インタフェース設計に著作権がある

一つのインタフェース

コード

コード量を減らす

チームがハッピーであるようにツールを選び, 環境を作る

コードは語る

コードに支払い, 設計に請求する

外の世界とつなげる

言葉

「機能仕様」は機能しない

「死んだ」ドキュメントは作るな

話の流れをかいつまんで

現実の言葉を使う

自分の製品に魂を吹き込む

価格と契約

無料サンプル

始めるのも止めるのも簡単に

金を稼ぐために小賢しいことはしない

ユーザへの衝撃はできるだけ優しく

宣伝

ハリウッド流 ティーザー -> プレビュー -> ローンチ

強力なプロモーション・サイト

ブログの流れに乗る

お誘いは早めに

教育を用いた宣伝

餌を撒きましょう

ログを見てみる

売り続ける

名前で引っかける

サポート

顧客の痛みを感じる

トレーニングやマニュアルを不要に

すぐに答える

愛は厳しい - 顧客にノーも必要

フォーラムを使う

失敗も公開する

本番後

本番開始後30日以内にアップデート

本番後もblogに投稿し続ける

「ベータ」はない

バグにも優先度がある

「おきまりの反応」はやり過ごす

競争相手の声に耳を傾ける

巨大化怪獣に気をつけろ

流れに乗る

以上.

これだけが正解じゃないと思うけれど, その背後にある考え方, 合理性は多くの場面で有効だろう.


Powered by Plone, the Open Source Content Management System

This site conforms to the following standards: