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テクニックなど、他のブログでも話題になると、最終的にプロダクトへのリンクがはられて、大きなトラフィックをもたらす