37signalsといえば、BasecampやBackpack、最近リリースしたTa-da Listなどの、シンプルで使いやすいサービスと、Ruby on Railsで、今WEB上で一番注目されているといっていいグループ。その37signalsのJason Fried氏の講演のPodcatingがIT Conversationsで公開されています。

さすがにノリに乗っていると言う感じで、歯切れのいい公演。特に、小さなグループで、最大の成果を出すための方法論を、自分達で確立している雰囲気があります。すべての開発に、37signalsメソッドが使えるかどうかは別として、参考になる点が多々。力説しているポイントとしてはこんなところ。

• 変化が必要な時に、すぐに変えられる仕組みと体制
• 制約は重要
• ユーザーインターフェースからつくる
• より少ない機能で競争する
• ブログで話題になる、ユニークな機能

かなり面白かったので、聞きながらザーッと書き出してみたのが以下。「より少ない機能で競争する」という視点が新鮮。プライベートで何かを作るときなどには、すごく重要なことかも。とても分かりやすい英語なので、ぜひ必聴お奨めします。

IT Conversations: Jason Fried - Basecamp

正しい人を雇い、一緒に働く

• スキルがあるのがまず最初
• いつもポジティブで、やっていることがエキサイティングと思える人
• 新しい技術を探して、早く学ぶことができる人
• 問題が起きた時に、解決策をみつけられる＝信頼できる
• 一番重要なのは「文章がうまいこと」。プログラマーでもデザインナーでも、文章がうまくなくてはいけない。最近はメールやIMなど、ほとんどのコミュニケーションは「書く」ことでなされる。
• カリスマ的な人が必要と言う訳ではない。グルのような人と働くのが、他のメンバーにとって快適とは限らない。

制約は重要

• 足りないからといって、すぐに人や資金を増やすな
• リソースが足りない時は、「重要なことを明確にする」こと
• 開発する目的でなにが重要かを明確にする
• 邪魔されずに、作業に集中する時間を大事にする
• コミュニケーションの時間を決めて、なるべく少ない時間で正確かつ簡潔にコミュニケーションする
• Basecampは一人のプログラマーと２人のデザイナーでつくった
• グループが小さければ、誰が何に責任をもっているかが明確になる

より少ない機能で競争する

• 機能の多さを優位性にしない
• できるだけシンプルにする
• 機能が少なければ、はやく進化させることができる。開発もテストも時間がかからない
• 小さなソフトウェアであれば、ハードウェアも少なくてすむ
• ユーザーサポートの手間も少なくなる
• マネージできる範囲にとどめる
• 使う人が、「自分の問題をかたづけるために必要な機能」だけに絞る
• 少ない機能から始める方が、多き機能からはじめるより遥かにいい
• ユーザビリティー・テストなどの、特殊な状況ではなく、実際にユーザーが使っている様子を観察して、ユーザーの使い勝手を改善する物だけ実装する
• 最初にリリースする時に、ユーザーが実現したい目的が達成できる必要がある
• ”ベータ”という形で始めるのはよくない
• 最初にスタートした時をVesion 1として、継続的に変化させるべき
• 機能の追加要望にたいしては、デフォルトNoで応えるべき
• 本当に要望が多い場合のみ、必要かどうか検討を始める
• 管理機能は最小限でいい
• 製品はディテール部分が非常に重要
• 開発する時間があまったら、新しい機能を追加するのではなく、既に作った機能のブラッシュアップに時間をつかう
• 新しい事をするより、今もっているものをよくすることを重視

変化しつづけることが重要

• 変化し続ける事が何より重要。そのためにシンプルで、小さな規模を保つ
• 何かを決断するときも、つねに変わることを前提にする
• 一度決めた事が変えられないなら、それは間違った決断だと考える
• 変化させられないプロダクトは、間違ったプロダクト
• WEBアプリケーションなので、なおさら常に変化させられるように
• 何か間違をおこして、問題になったらそれを正直にユーザーにすべてオープンにする
• Flickrもユーザーインターフェースが頻繁にかわるが、「いい変化」であれば全然問題ない
• 一度に、大きく変化するのではなく、継続的にすこしずづ変えていく

実際のユーザ−体験を第一に考える

• リアルさが重要。設計書などのドキュメントも書かない。ユーザーが実際に使うユーザーインターフェースから作り始める
• ユースケースなどを書きたい場合は、紙に簡単にメモする程度。時間をかけない。
• 実際にユーザーが目にしないもの（ドキュメントとか）には時間をかけない
• ドキュメントは政治的なものだ。皆が合意したような気がするだけ。
• ユーザーインターフェースのデザインが、プロダクト開発をドライブする
• ユーザーが体験する、実際の経験が一番重要
• ユーザーも、サービスを使って慣れながら、新しい機能や使い方を学習していく
• 何度も繰り返しながら、インターフェースをブラッシュアップしていく
• ユーザーインターフェースは、できるかぎりシンプルにすること
• エキスパート・ユーザーとは、複雑な操作をできる人ではなく、どうやったら何ができるかを把握している人。だからエキスパート・ユーザーにとっても、操作はシンプルであるほうが望ましい。メニューの位置などを変えるのはバッドアイデア
• 日本の工場みたいにJust in Timeシステムで、必要なときに必要なものを調達できるようにする。
• ユーザーからのクレームや意見をよくチェックするべき。ユーザーから不満が多い部分は、自分でも不満に思うはずなので、サービスをなおすためのモチベーションになる

ブログで話題になる、ユニークな機能

• 一つでも、似た他のサービスに無い優れた機能があると、それを試してみたい人が沢山、サービスを使ってくれる可能性がある
• BaseCampで利用したYellow Fadeという、Javascriptの小さなテクニックが非常に有名になって、プロダクトの知名度が向上する事もある
• ブログを立ち上げて、サービスの内容や、作る過程などを公開すると、サービスへ興味を持ってもらえる。Yellow Fadeテクニックなど、他のブログでも話題になると、最終的にプロダクトへのリンクがはられて、大きなトラフィックをもたらす