この記事は前回のつづきで、「Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application」という本を紹介する。
著者は37signals社という、BasecampやRuby on Railsを開発した有名な会社。
無料で日本語訳版が読めるのでぜひ。
前回は次のような教訓について紹介した：
- 自分が欲しいと思ったものを作れ
- 「より少ない」ことは良いこと
- 機能要望は忘れろ
引き続き同著にて個人的に重要だと思った気付きを紹介していく。
※引用項は、特に断りのない限り同著からのものとする。
リーダーを追従するな
You must tell a different story and persuade listeners that your story is more important than the story they currently believe.
現在正しいと信じられているストーリーとは異なるものを語れ。そして聴衆にあなたのストーリーのほうが大事だと説得するんだ。
競合を持つことは、あなたの方向性を照らす道標になる。
その道標とは、異なるストーリーだ。
例えば、もし競合がスピードを謳っていたら、あなたは価格を謳え。健康を謳っていたら、利便性を謳う。
同じストーリーで戦うのは消耗戦になるだけだ。
陥りがちな間違いは、競合の機能の多さに対抗して更に機能を付けようとすることだ。
人と違うことをしよう。
「オプション設定」を避けろ
Preferences are also evil because they create more software. More options require more code. And there’s all the extra testing and designing you need to do too.
プリファレンスはソフトウェアを複雑にする有害なものだ。さらなるオプションはさらなるコードを必要とする。そして追加のテストやデザインなど多くのことをしなければならなくなる。
オプション設定を少なくすることで不満も上がるだろう。
でもだからといって気にする必要は無い。
なぜなら、いつでも機能の振る舞いは調整できるからだ。
必要最低限の機能で無駄のないシンプルな設計を保っていれば、そんな変更は造作も無いこと。
自分ではどれが一番よいか判断出来ないからといって、なんでも安易にオプションにしてしまうのも注意。
多すぎるオプションは、結局ユーザに見つけられること無く埋もれることになるだろう。
「白紙の状態」を軽視するな
白紙の状態（The blank slate）とは、ユーザがまだ何も入力していない状態や、表示する情報が(まだ)無い画面のこと。例えば検索結果がゼロ件だったりサインアップした直後の状態など。
Ignoring the blank slate stage is one of the biggest mistakes you can make. The blank slate is your app’s first impression and you never get a second…well, you know.
白紙の状態を無視することは大きなミスになりうる。白紙の状態はあなたのアプリの第一印象でありそれは二度と来ない…まぁ知ってるよね。
開発しているとその大半の時間は何かしらの情報が入った状態のアプリを見て触っている。そして白紙の状態はほんの数度確認する程度だ。だからサインアップ直後などの白紙の状態は軽視されがち。
これは自分でもすごく心当たりがあるし、実際に軽視してしまっていた。
ではこの「白紙の状態」をどう取り扱えばユーザにとって好印象だろうか？例えば…
- クイックチュートリアルを入れたりヘルプへの誘導に使う
- 情報が入れられた後の状態のスクリーンショットを掲示して、ユーザに利用イメージを膨らませる
- 使いはじめのステップや、最終的にどうなればいいかを説明する
- 閲覧者が最初に思う疑問点にあらかじめ答える。このページは何？自分は今何をしている？この画面は情報を入れたらどうなる？など
- ユーザ感情を想像して補助することでフラストレーションや恐怖・混乱を減らす
などが考えられる。
幸せな人は生産的である
A happy programmer is a productive programmer.
We optimize for happiness and you should too.
幸せなプログラマーは生産的なプログラマーだ。僕らは幸福に向けて仕事を最適化している。あなたもそうすべきだ。
Don’t just pick tools and practices based on industry standards or performance metrics.
ツールや慣例を業界標準やパフォーマンス基準で選ぶのはやめよう
使いたいツールがあるけど会社や取引先の都合で使えなくて不満。そんな声はいたるところで聞く。そしてモチベーションは下がる一方だ。
果たしてこれはプログラマーやデザイナーのわがままと言って一蹴していい話なのだろうか？
暗い顔をしていつもため息をついている人よりも、いつも楽しそうにしていて快活な人の方が生産的なのは科学的な実験でも証明されている。(データの見えざる手 ウエアラブルセンサが明かす人間・組織・社会の法則)
この話は、自分たちが何のために仕事をしているのかを見つめなおさせるものだ。
仕事は人を幸せにするためだとしたら、自分はその対象ではないのか？
いつも笑顔な人に人は集まるように、仕事を心から楽しんでいる人に顧客も集まるのではないだろうか。
自分を幸せに出来ない人は、他人を幸せにするのも難しいだろう。
まとめ
ものづくりは本当に奥が深い。
自分は主に一人で作っているけど、だからといって全く独りではないのだと実感させられることが多々ある。
ユーザさんに助けてもらい、そしてサービスでお返しをする。
結局は人と人との助け合いなのだな。
これはその助け合いを加速するための本だ。無駄と言う名の摩擦係数を減らす方法論集とも言える。
というわけで語りきれないけどこの辺で終わりにする。
[amazonjs asin=”0578012812″ locale=”JP” title=”Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application”]
