37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」
37signalsといえば、BasecampやBackpack、最近リリースしたTa-da Listなどの、シンプルで使いやすいサービスと、Ruby on Railsで、今WEB上で一番注目されているといっていいグループ。その37signalsのJason Fried氏の講演のPodcatingがIT Conversationsで公開されています。
さすがにノリに乗っていると言う感じで、歯切れのいい公演。特に、小さなグループで、最大の成果を出すための方法論を、自分達で確立している雰囲気があります。すべての開発に、37signalsメソッドが使えるかどうかは別として、参考になる点が多々。力説しているポイントとしてはこんなところ。
- 変化が必要な時に、すぐに変えられる仕組みと体制
- 制約は重要
- ユーザーインターフェースからつくる
- より少ない機能で競争する
- ブログで話題になる、ユニークな機能
かなり面白かったので、聞きながらザーッと書き出してみたのが以下。「より少ない機能で競争する」という視点が新鮮。プライベートで何かを作るときなどには、すごく重要なことかも。とても分かりやすい英語なので、ぜひ必聴お奨めします。
IT Conversations: Jason Fried - Basecamp
正しい人を雇い、一緒に働く
- スキルがあるのがまず最初
- いつもポジティブで、やっていることがエキサイティングと思える人
- 新しい技術を探して、早く学ぶことができる人
- 問題が起きた時に、解決策をみつけられる=信頼できる
- 一番重要なのは「文章がうまいこと」。プログラマーでもデザインナーでも、文章がうまくなくてはいけない。最近はメールやIMなど、ほとんどのコミュニケーションは「書く」ことでなされる。
- カリスマ的な人が必要と言う訳ではない。グルのような人と働くのが、他のメンバーにとって快適とは限らない。
制約は重要
- 足りないからといって、すぐに人や資金を増やすな
- リソースが足りない時は、「重要なことを明確にする」こと
- 開発する目的でなにが重要かを明確にする
- 邪魔されずに、作業に集中する時間を大事にする
- コミュニケーションの時間を決めて、なるべく少ない時間で正確かつ簡潔にコミュニケーションする
- Basecampは一人のプログラマーと2人のデザイナーでつくった
- グループが小さければ、誰が何に責任をもっているかが明確になる
より少ない機能で競争する
- 機能の多さを優位性にしない
- できるだけシンプルにする
- 機能が少なければ、はやく進化させることができる。開発もテストも時間がかからない
- 小さなソフトウェアであれば、ハードウェアも少なくてすむ
- ユーザーサポートの手間も少なくなる
- マネージできる範囲にとどめる
- 使う人が、「自分の問題をかたづけるために必要な機能」だけに絞る
- 少ない機能から始める方が、多き機能からはじめるより遥かにいい
- ユーザビリティー・テストなどの、特殊な状況ではなく、実際にユーザーが使っている様子を観察して、ユーザーの使い勝手を改善する物だけ実装する
- 最初にリリースする時に、ユーザーが実現したい目的が達成できる必要がある
- ”ベータ”という形で始めるのはよくない
- 最初にスタートした時をVesion 1として、継続的に変化させるべき
- 機能の追加要望にたいしては、デフォルトNoで応えるべき
- 本当に要望が多い場合のみ、必要かどうか検討を始める
- 管理機能は最小限でいい
- 製品はディテール部分が非常に重要
- 開発する時間があまったら、新しい機能を追加するのではなく、既に作った機能のブラッシュアップに時間をつかう
- 新しい事をするより、今もっているものをよくすることを重視
変化しつづけることが重要
- 変化し続ける事が何より重要。そのためにシンプルで、小さな規模を保つ
- 何かを決断するときも、つねに変わることを前提にする
- 一度決めた事が変えられないなら、それは間違った決断だと考える
- 変化させられないプロダクトは、間違ったプロダクト
- WEBアプリケーションなので、なおさら常に変化させられるように
- 何か間違をおこして、問題になったらそれを正直にユーザーにすべてオープンにする
- Flickrもユーザーインターフェースが頻繁にかわるが、「いい変化」であれば全然問題ない
- 一度に、大きく変化するのではなく、継続的にすこしずづ変えていく
実際のユーザ−体験を第一に考える
- リアルさが重要。設計書などのドキュメントも書かない。ユーザーが実際に使うユーザーインターフェースから作り始める
- ユースケースなどを書きたい場合は、紙に簡単にメモする程度。時間をかけない。
- 実際にユーザーが目にしないもの(ドキュメントとか)には時間をかけない
- ドキュメントは政治的なものだ。皆が合意したような気がするだけ。
- ユーザーインターフェースのデザインが、プロダクト開発をドライブする
- ユーザーが体験する、実際の経験が一番重要
- ユーザーも、サービスを使って慣れながら、新しい機能や使い方を学習していく
- 何度も繰り返しながら、インターフェースをブラッシュアップしていく
- ユーザーインターフェースは、できるかぎりシンプルにすること
- エキスパート・ユーザーとは、複雑な操作をできる人ではなく、どうやったら何ができるかを把握している人。だからエキスパート・ユーザーにとっても、操作はシンプルであるほうが望ましい。メニューの位置などを変えるのはバッドアイデア
- 日本の工場みたいにJust in Timeシステムで、必要なときに必要なものを調達できるようにする。
- ユーザーからのクレームや意見をよくチェックするべき。ユーザーから不満が多い部分は、自分でも不満に思うはずなので、サービスをなおすためのモチベーションになる
ブログで話題になる、ユニークな機能
- 一つでも、似た他のサービスに無い優れた機能があると、それを試してみたい人が沢山、サービスを使ってくれる可能性がある
- BaseCampで利用したYellow Fadeという、Javascriptの小さなテクニックが非常に有名になって、プロダクトの知名度が向上する事もある
- ブログを立ち上げて、サービスの内容や、作る過程などを公開すると、サービスへ興味を持ってもらえる。Yellow Fadeテクニックなど、他のブログでも話題になると、最終的にプロダクトへのリンクがはられて、大きなトラフィックをもたらす