スマホアプリでも業務アプリでも同じようなことがあると思うんだけども、僕が携わってるのはツール的なWebサービスなので限定しておく。あとこれは個人的な体験から生まれた思考です。
ツール的に使われるWebサービスを作っていて、機能が十分に足りてなくて、何か追加するならこれ、という選択肢がいくつもある場合にはやはり全部一気に取り掛かることはできない。なんでかっていうと、一応言葉にしておくと、欲しい機能は無限に溢れ出てくるように見えるが、実装に使えるコストはそれに比べてかなり限定されているからだ。
金があればいいかと言われると、機能というのは人が多かれ少なかれ取り組んで出来るものだし、人を雇うには金が必要だが、金があれば必要な人が確保できるかというとそうではない。誰でもいいというわけではなく、ある程度プロジェクトの分野の知識がなければ、余計に時間を浪費する。また人が多くても、束ねるのも労力が必要で、小回りも効かなくなる。そこまで来ると小さい開発チームに分割していくのが業界的にも良いとされているが、マネジメントをオーバーヘッドと考えると、コストに対する効率が悪くなるように見えるかもしれない。なお、僕は直接成果物に触ってプロジェクトにコミットする職能ですが、マネジメントをやる人も必要なものだと感じる派閥です。
また、Webサービス開発においていい感じにチームを割れた経験は僕にはなく、少数精鋭で各個撃破が一番良いと思っている。しかし少数精鋭の効率の良いチームを作って回していくのも困難な話なのだ。
さて、各個撃破するということは、実装する機能に優先順位をつける行為に直結する。だとすれば、どういう基準で優先順位を付けるか。これにもいろいろな考え方がある。
まず、使われる機能であること。これは最優先事項である。使われない機能を実装することほど無意味なことはない。
そんなことは当たり前の話で、しないだろうと、皆さんは思うかもしれないが、サービス開発において、使われない機能を実装してしまうのは往々にしてありうる。
SNSや問い合わせなどで「この機能が欲しい」「この機能があればあなたサービスに乗り換える」という要望を受けることがある。これ自体は大変ありがたい。けれども、お客さんはその機能が実装されたからといって、その機能を使う義務はない。また、望み通りのものが実装される保証はない。いくら言葉で説明しても、頭の中のニュアンスまでそっくり他人に移植出来るわけではないからだ。
なので字面をそのままそっくり受けとるのは、僕は危険だと思っている。でも要望自体は捨ててはいけない。その言葉の裏に隠れたニーズを汲み取るが重要だ。でもこれは推測でしかなく、不確実性も高い。
では、実際に使われる機能を実装するにはどうすればいいか。これはチキンエッグ的結末で恐縮なんだけども、やってみてこれは望みのものでしたか、と聞くしかないと僕は思う。
要望する人がチーム内や会社内の人間であったり、開発費用を負担してくれるような協業パートナーであれば、まだ容易い。パワポでこんなのどうですか、と持っていって説明すれば、だいたい擦り合わせることができる。
ただ、相手が不特定多数の一般ユーザさんだと途端に難しくなる。直接言葉を届けられる相手以外だと、まだ世の中にないものを伝えるのは難しい。また限定的な機能でリリースしたり、モックを作るのも手ではあるが、お客さんは完成品が欲しいのであって、試作品を見たいわけではないので、これもまた上手く伝わるか自信がない。
僕は過去にゲームアプリ開発の現場にいたことがあり、以下のような体験をしたことがある。ゲーム開発では、本開発に入る前にモックやパワポの段階で面白いか、や、売れるか、を見て進退を決めるのだけども、試作の段階だとエフェクトや綺麗な絵や音が入っていないことが大半である。でも見たいのはゲーム性の部分なので本来は必要がない部分であるし、鍛えられた人であれば想像で補える。ただ、訓練されてない人は、きれいな表現を面白さの根源と勘違いしてしまって、判断を誤ることがある。きれいな表現は面白さを増幅するが、0に何掛けても0なので、0かどうかを判断しなければならない場で、掛ける側を見てしまうと事故が発生してしまう。
Webサービス開発でも同様のことはあり、経験を積んで試作品と完成品の差分を覚えて我々は試作品から完成品を想像できるようになる。ただ、世の中の大半の人はそうではないので、試作品を不特定多数の人に晒すのはかなり勇気がいることだと僕は思う。それが完成品と勘違いされるのが最もダメージがでかいからだ。
僕が思う、一般のお客さんがサービスに要望を出してそれを通すにはどうすればいいかを考えてみる。
それは、そのサービスを現時点で使っていること、さらにそれを周囲に公言していることが大事だと考える。サービスを使用している時点で利害関係者だ。もちろんまだ見ぬ未来にやってくるお客さんのために何か作るのも、サービスの拡大発展には必要である。しかし、これは博打で、使われない機能を作ってしまうリスクが高くなる。また、すでに使用しているユーザーであれば機能実装後にフィードバックを得て、作ったものがニーズからズレてるかズレてないかを判定できる。新しいユーザーというのは、新しく機能が実装されたからサービスを使い始めようというのではなく、大半が他人が使ってるから自分も使おうとなる。観察しているとそういう傾向だ。なので、すでにサービス自体を使っていて、フィードバックを得やすく、周囲に公言している人の意見を重要視したくなる。また、サービスと一蓮托生の人ほどとことん考えられたユースケースを提案してくるだろうというメタな推測もある。
ただ、これもある視点ではリスクをはらんでいる。今いる人にとってな大事な機能が、将来のユーザにとって障害になることもある。僕はこれをゲームアプリで学んだし、ゲームはそれがライフサイクルに組み込まれているものの、Webサービスはそうはいかんやろとも思う。
よくデザインや機能がリニューアルして既存のユーザから使いにくくなったと不評を受けるサービスがあるけれども、我々作る側は、上記のことを自分の中の天秤にかけて判断し、それから実際の綱渡りをしていると感じる。一歩バランスを崩せば真っ逆さまである。
サービス運用というのは、走ってる車の部品を走りながら取り替える行為をずっと続けるようなもの、と会社の人が言っていたのを思い出す。それは動いているプログラムを壊さないように機能を付け足す観点だと思うけれども、機能自体を付け足して、それ自体は完璧に動くが、サービス全体で見たサイクルが壊れることもしばしばある。
でも、これだから物を作るのって楽しいんですよね。
