あるサービスのリニューアルが最終調整に入っている。今回はこれまでの開発に比べてさらに明確に、「この人が使えなければ意味が無い」というベンチマークを定めて開発を行っている。
もっと具体的に言うと、総務のid:snishiyamaとid:mucccuが迷わずに使えるようになるまでは出しちゃだめ、という合格ラインを決めて開発をしている。
そんなの普通やるだろうと言われるかも知れないが、これまではそこまで明確にラインを設けてはいなかった。サービスの開発が終わった後に、ユーザービリティテストとして何人かに使ってもらって手直し的に改善を加える事はあっても、開発の初期段階から「この人が使えるように作る」という事を決め、開発途中の段階で頻繁にテストをして方向修正を加えるような事は少なかった。
しかし、ここが明確に決まっていると、「この作りで彼女はちゃんと迷わずに使えるだろうか」とより具体的に考えながらインターフェースを作る事になるし、少し作ってはちゃんと使えるかどうか検証して前に進むので後戻りも少なくなる。プログラムのテストファーストな開発スタイルに似ているが、テストがプログラムではなく人間であるというわけだ。
振り返ってみると自分がサービスを作る時には、必ず一定量進んだところで近くにいるid:reikonやid:nmyなどに使ってもらって、その様子を観察している。そこで使えなければだめだこりゃと思って作り直すという事を繰り返してきた。別にテスト稼働開発をしようとかそういう事ではなくて、作ったら使ってもらいたくて仕方が無いから近くの人に使ってもらうし、それで使ってもらえなければ悲しいから一生懸命直す、というただそれだけのことが出発点なのだが、無意識にそういうテストを繰り返してきたのだなと思う。
プログラムと違って「使いやすさ」というものはなかなか数値化できないし、テストケースとして記述するのも難しいから、より総合的に評価するには人間の行動を観察するしかない。開発の初期段階で頻繁にテストをするためには、近くにベンチマークとなる人が1人で良いから居る必要があるし、周りにいる人から問題が見つからなくなったら数名から10名程度のさらに多くの人に使ってもらうユーザビリティテストが有効だし、サービスが大規模になれば、多くのユーザーの傾向（例えばアクセスログを解析して何%の人が迷わずに次に進めたか、といった指標）が必要になるだろう。
インターフェースにも、プログラムのようなテスト稼働開発は有効だと思う。何か新しいものを作ろうと思うなら、こうした使い安さのテストをできる環境をきちんと整えなくてはいけないと思う。
