37signalsのGetting Realをshin_no_sukeに奨められて、じっくり読みました。
今後のビープラウドにとって、参考になることが山ほどあったので、まとめておきます。（文が汚くてすみませんが）
・デザインからはじめる
インターフェースが製品である。顧客からみえているのはインターフェースである。
アプリの改修は一番重い。デザインなら捨てることもできる
・チームは小さくはじめる（三銃士）
最初のバージョンは小さく、タイトで構わない。そこからアイディアに翼があるかどうかを知ることができる。
小さな人数で構築することにより、綺麗で、シンプルな基礎を手に入れることができる。
・最初の資金のかき集めは不要。自分たちの手持ちから
→外部の資金を出す人は、自分の手元に早く短い期間でお金が戻ることを期待する。製品もその思惑に左右されることが多い。そして、さっさと撤退しにくい
・スリムなアプリケーションにする
機能追加にはまずノーをいう。｢less(より少なく)｣
→本当に必要な機能は、何度も要望があがってくる
→一つの機能をつくるということは、一人の子供をもらうようなもの
｢より少ない｣特徴、機能、オプション・設定、スタッフ数、チーム構造、ミーティングと曖昧なアイディア、約束
より少ないソフトウェアは、管理が簡単、コードベースを削減する、メンテナンスが楽、変更コストを低下させる、バグ数が減る、サポート量が低下する
ムダがないほど変化しやすい。変化のコストを抑えることができる
・ユーザ設定による選択より、完璧なデフォルト値
・開発者には、干渉されない時間を１日にかならず半分つくること
レム睡眠になるには時間がかかるように、集中するには、段階があり、時間がかかる
・個々に分けない
多くの企業が、デザイン、開発、コピーライト、サポート、マーケティングを個々に隔てすぎている
それには、利点があるが、木を見て森をみずになる。可能な限りこれらを１つのチームにする。 全体を見渡すことにより、質の高い議論ができるチームにする。人を雇うときは、開発中、様々な帽子を被ることができる多才な人を雇うこと。結果的に良い製品ができあがる。
・人材は少なく雇い、スピードを上げたい場合に、あとで少しずつ足す。
最初に100人の最高の人材を選んでも、教育、研修、個人と個人の対立、コミュニケーションの喪失になやまされることになる。
・人材を雇うとき
言葉より行動をみる
スペシャリストよりゼネラリスト
小さなチームには、何足もの草鞋を履ける人間が必要。
一つのことに固執する人より、変化できる人
不満だらけの優等生より、普通だけの幸せな人
熱意のある人、１人でも仕事を任せられる人、作る物に熱中できる人、自分たちの列車にわくわくして乗ってくれる人
・ツールは、チームの刺激や情熱を維持し続けられるツールを選ぶ
正しい選択をすると、利用可能なだけではなく、楽しく刺激的に作ることができる。毎日のちょっとしたことを楽しくすることができる。結果、開発者たちは、良い製品を生み出すことになる。
・製品のプロモーション方法
広告よりも安価で効果があるのはブログである
・ユーザサポート
ユーザサポートへの問い合わせには最優先事項で取り組む
他にもあげてない項目ありますが、このへんで。おすすめです。是非ご一読を。
今年の目標：１００エントリーまであと４１。
