Knowledge base func

とても参考になったがあまりにも長いので自分のメモリの小さい頭でもわかるようにまとめてみた。リファクタリングして繰り返しになっていた部分をまとめたり、超訳したりした。
また後ほど、日本の頓挫した特許庁とのシステムとものちほど比較検証してみる予定だ。

オリジナルの訳は下記から読むことができる。
37signal Getting Real

gettingreal.37signals.com/GR_jpn.php#ch07

Getting Real は、より小さく、より速くソフトウェアを構築するのにより適した方法です。またそのアプローチは多くのビジネス・クリエイティビティの現場でも採用できるものです。

■しぼりこむ / やらないことの大切さ
***やることを削る
機能を追加するな。機能を削れば戦線は絞れる。「何でもかんでも」というやり方には気を付けろ。必要だと思えるものを選び、さらにそれを半減。最も不可欠なものだけが残るまで機能を削る。もっと、は答えでない。コードも削れ。コード量が増えるにつれソフトウェアは指数関数的に複雑になっていく。ないコードより柔軟性のあるコードはない！

***持っている資源で戦え
自分でつくれ、自分のもっている資金でうごけ。無いものを戦力に加えるな。
時間やお金が予定よりかかりそうになったら優先順位を考えて絞り込め。

***チームは３人いれば十分
制限のある人的資源は何が必要かを明確にする。柔軟性がうまれる。
プロジェクトが大きくなると、ネックになるのがメンバーの増加。コミュニケーションチャンネルが増えるとコミュニケーションコストが指数関数的に嵩む。仕事がメモとミーティングに埋まってしまう。チームを小さくし、独立して動ける規模まで小さくし、コミュニケーションのリンクを減らす。

***まだ発生してもいない問題のために時間を費やすな
必要になってから増やす。決断する時は必要な情報が手に入った時。製品を作り始めたとき、持っている情報は最低限のものだけです。何か決める時は、その情報を持っている時で、その前ではありません。
すばらしいものを作り、それがとりあえず形になってから次に何をしようか考える。いきなり規模を考えたりしない。

***顧客の要望に対してまずノーと言う
顧客からの要望は聞いたら忘れる。読んで、投げて、忘れてしまえ。重要なものはいやでも浮かんで来続ける。要望に対してイエスと言うたびに子供が産まれる。あなたはその赤ちゃんを育てなければならない。一度世に出たものを顧客から奪い取ることはできない。

***皆を喜ばせようとすると、誰も喜ばない
本当に必要としている人は誰かを知り、彼らに喜んでもらえるようターゲットを絞り込む。

***ミーティングをしない
はっきりとした話の内容が決まっていないミーティングは絶対しない。ミーティングは必要最低限の人間のみで開催する。

***人は雇わない。
他の道を探す。仕事は本当に必要なものですか？それをしかなったら問題ですか？便利なツールや代わりのアプローチ方法でその問題を解決できませんか？誰かをクビにしても、すぐに代わりを雇わなければ、そのポジションに人がいなくてもどれだけ問題がないのか知ることができる。

***仕様書などの書類はつくらない
仕様書は実用的ではない。機能についての書類は書かない。アプリケーションは制作者が作り、デザイナーがデザインし、人々が使用して初めて現実する。機能スペックの記述は合意をしたという幻想。文面で納得するのは、真の同意ではない。同じ内容のものを読んでいても、そこから考えることは人それぞれ。何か機能を加えることでうるさい奴を静まらせることができる。仕様書をつくれば機能が増え過ぎる。
基本設計書は、サインされ同意されるもの。開発中アイディアが誤っていたと気付いても、そのまま進むしかない。
YahooやGoogleやAmazonを使うのにマニュアルは必要無い。マニュアル無しの製品を作ることの重要性がわかるはずです。

■つくりこむ / 形にすることの大切さ
***ビジョンは一言で
何をつくろうとしているのか一言で言いあらわせるか？

***ストーリーをつくる
新しい機能やコンセプトについて言葉で説明しないといけなくなった時には、それについての簡潔な話を書きます。技術やデザインを詳述してはいけません。
アプリケーションが必要としているストーリーを１つ書く。簡単な言葉で手早く。1枚の紙で収まらないのなら、複雑だと言う証拠。

***アイディアは実行しないと意味がない。
アイディアを現実に。実現していないものには価値はない。

***まず大局を固めてから細部にこだわれ
インスピレーションの紙スケッチ、走り書きでいい。それを元に皆が見ることができるのをつくる。それを評価して実際につくる。実際につくったものがダメならやり直す。成功と満足の秘訣はディテール（詳細）にある

***繰り返し
１回目でうまくいくとは思わないこと。アプリケーションを成長させ、そこから学ぶ。その形を変え、進化させる。作り、使い、分析。これを繰り返す。

***ユーザーに選ばせない
任意の設定をユーザーにさせるのはあなたが最良の選択肢を考えるという作業をユーザーに押し付けているということ。

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

***うまくいかなかった場合のデザイン（エラー画面）
認めましょう：オンラインで物事はうまくいかない。どんなにアプリを注意深くデザインしても、どんなにテストをしても、顧客は問題につき当たるものです。それではこういった避けられない障害にどう対処すればいいでしょうか。守備的デザインをするのです。Defensive Design for the Web（「ウェブ用守備的デザイン」）

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

■さがしだす / 見つけることの大切さ
***才能をさがす
遅延したプロジェクトに人を加えると、ますます遅くなる。（ブルックスの掟）
1人で1つの仕事をこなす優秀なプログラマーは、必要以上に人やコミュニケーションを持たない。同じ仕事でも5人のプログラマーですると協力やコミュニケーションがいる。時間は余計にかかる。だから二流のプログラマーが沢山集まったところで、どれだけ時間をかけても優秀なプログラマーのクオリティ品は作り出せない。

***干渉されない時間
うまく仕事のはかどる１人の時間は、IMも電話もミーティングもシャットアウトします。メールの即時の返答もしてはいけません。外音を閉じて、自分の仕事のみに集中する。

***時間の細分化
何ヶ月も何年も先の見積もりはもはや空想。12週間のプロジェクトではなく、１週間のプロジェクトが12週続くと思うのです。30時間かかりそうなタスクではなく、より現実的な6-10時間の単位で細かく考える。

***情熱を探す
不運なことに、多くのプログラマーはプロジェクトを完遂できない。プログラムは全て決断である。とても沢山の決断は、文化的な優位、価値、理想などで決まる。オープン・ソースの参加者にはある程度の情熱がある。熱意はごまかせない。
不満だらけの優等生より幸せで熱意を持った人間を見つけましょう。1人でも仕事を任せられる様な人。

***ジェネラリストを探す
スペシャリストより早く覚えるジェネラリスト。スペシャリストを雇うつもりはありません。彼等のディテールのこだわりは半端ではなく、我々のような小さなチームには、そのような一部にとてつもない能力を発揮する専門化肌の人間は１つのことに固執し変化を見出せないので合わないのです。
小さなチームには、何足もの草鞋を履けるような人間が必要です。ものを書くことができるデザイナー、デザインの分かるプログラマー…全てのメンバーが情報を（どんな情報でも）組み立てるアイディアを持つべきです。全員整った精神が必要だし、全員が顧客とコミュニケーションできることが必要なのです。

***良い文章家を探す
採用する際には、個々の文章能力を重要視します。デザイナーでもプログラマーでもマーケティングの人間、営業の人間でもです。文章構成のスキルは高く評価します。効果的な、シンプルな文章作成と編集の力は、コードやデザインやコミュニケーションなど、様々な舞台にも応用が利きます。
良い文章家はコミュニケーションの仕方が良いのです。人に理解させるのがうまい、相手の立場を考える、不要なものを見分ける、シンプルに考える。

■具体的な手順など
新機能を追加する際には、以下のステップが必要になります：

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

評判と期待を起こすのに、ハリウッド式に１）発表・ティーザー、２）試写会・プレビュー、３）リリース

プロモサイトで人々に製品を紹介する
概要*：アプリとそのメリットの説明
ツアー*：各種機能について案内
スクリーンショットとビデオ*：実際のアプリの見た目と、どのように使うのかを見せる
マニフェスト*：製品の裏側にある哲学と考えの説明
ケース・スタディー*：何ができるのかを示すため現実での例を挙げる
評判*：顧客やレビュー、プレス等からの、証明を引用
フォーラム*：メンバーがお互いを助け合うことができる場所を提供
価格表示と登録機能*：できるだけ早く製品に人々を引き込む
ブログ*：ニュースや助言を書いたブログでサイトを新鮮に保つ

ふぅ・・・、まだなげぇ。100行ぐらいに超訳する。