アプリのリリースに必要な「引き算担当」について - @hitoshi annex on hatena
今年みた記事の中でトップ5に入るほどの良記事。特に小さな組織でアプリやサービスの企画・開発をやるときはこの役割を担うといっても相当難しいポジション。その後のスピード感とかいろいろなところに影響するしね
よんだ。
これね。もうね。すごく大事。
いろいろなサービスやアプリの企画が上がっては消え、作っては棄てを繰り返しているわけですが、その中の要因の一つもこのあたりの話。
「削る」というと、わかる人にはわかるのですが、面倒なのは当然チーム全体でこの辺の重要性を理解できない人がいる場合。
「あった方がいい」とかいう意見は大抵どうでもよくて、そこで「はぜその機能が必要なのか」という事を問いつつ、同時に、それを全員でシミュレーションできるかという事がすごく大事。
大抵の機能は、想定するシナリオでは使われないし、最初からあることにが利点ではなく欠点にしかならない。
「削る」という言葉だとネガティブに感じる人は、「明確化する」と置き換えるといいかもしれない。
そのアプリやサービスのファンクションはなんなのか？
基本的には、複数または単一の機能が提供する唯一の機能がそのアプリやサービスの肝であって、それ以外の付帯機能は、あればあるほどそのアプリやサービスのピントがぼける。
包丁は明確に「切る」という役割に徹しているので、使う人は誰しも「包丁は切るもの」と理解し、教えることなく「切る」という目的で使う。
それが、ナイフもついているし、栓抜きもついているし、ドライバーやルーペもついている十徳ツールを渡したらどうだろうか。
受け手はその十徳ツールの何をメインの機能と認識するだろうか。
おそらくは、ある局面では便利かもしれないが、物を切るという日常使いでは使わないし、ドライバーとしても機能性は落ちるだろう。
アプリやサービスも同じで、付帯機能が多いというのは、言い換えると目玉の機能のピントがぼけやすいという事。
そのアプリがユーザーが期待する機能をただ一つしかもっていないとして、そのことは利用者にとってマイナスの印象を与えるだろうか？
いや、そんなことはない。
ユーザーは、使い方の分からない機能であったり、実装が不十分な機能であったりに触れたときに不満を感じる。
リリース計画を遅らせない事であったり、リリース時点の品質であったり、リリース時にユーザーに提供するエクスペリエンスであったりは、常に開発者のぶれない考え方にゆだねられているわけで、そのことを忘れてはいけない。
「削る」のではなく、「明確化」すると考えてほしい。
あと、ユーザーはリリースされてからの機能追加や改善にも大いに期待している。
自分が利用する側の人間であった場合のことを考えてほしい。
開発が終了し、リリースされたものが、リリース後なんらの機能の追加も改善もなかったらどうだろうか。
ユーザーの心理としては、徐々に機能は整備されれば全く問題はない。
（当然、肝の部分は実装が十分されており、機能として成立していることが前提）
むしろスピード感や臨場感を出す意味でも、リリース後、じっくりと付帯機能は充足させればよい。
というかね、リリースしてみなさい。
ユーザーの興味ははっきりしてくるし、場合によっては、自分たちの予想とは違う方向に流れることもある。
リリースしてまずは反応を見ることはすごく重要で、その先の事は、正直リリースしてからしかわからない。
企画段階や開発段階で「これうれねぇなぁ」と思っているならリリースはやめているわけで、たいていの場合「いける！」と思っているのだから、まずは出してしまえばいい。
リリースしてからも十分に時間はあるのだから。
という事はこの３年ぐらい本当に身にしみていることです。
もう泣きそう。
