プロダクトができるまで

プロダクト。サービスそのものでも、その中における一つの機能でも、まずアイデアがあり、開発され、そしてリリースされる。

では、このアイデアの源泉はなんだろうか?

そこには解決したい課題がある。その課題を解決するのがアイデアであり、そのアイデアを具現化するための手段が開発だ。では、課題が見つかり、そこを解決するアイデアが見つければもう開発を始めるべきだろうか?

これは、そうではない。

今度は、その「解決したい課題」、ジョブを抱えているターゲットを想定する必要がある。極端な話、そのアイデアを思いついた人しか保有していない課題だとしたらどうだろう?個人的にプログラムを書いて解決することはもちろん意味があるが(今後、同じ課題を抱えた人が現れるかもしれないし)、プロダクトというビジネス面での使命を背負ったものとしては、ターゲットにはある程度のボリュームが求められる。(市場規模、というとしっくりくるだろうか)

ターゲットを想定したところ、どうやらプロダクト化する価値がありそうだ。次に考えるのは、「どうやってそのターゲットに届けるか」だ。

つい「いいものを作れば自ずと使ってくれるだろう」と考えがちだが、まず認知度がなければ触れてももらえない。そして認知度のあるプロダクトの新機能なら大丈夫かというと、これもユーザーが気づく形になっていればただのオブジェになってしまう。

そしてもう一つ忘れてはならない観点がある。競合の存在だ。

どのように差別化するのか、どう棲み分けるか。自分たちが先行しているのか、すでに先行プロダクトがある市場に飛び込んでいくのか。

このように、プロダクトを開発するには考えるべきこと、立てるべき仮説がたくさんある。

僕たちの失敗

皆さん、プロダクト開発はうまくいっているだろうか。
もちろんうまくいっているケースもあるだろうが、うまくいっていないケースもある。そして人間は悪かったことを記憶しやすい生き物なので、こういう質問をすると「いやー、うまくいっていないです」と返って来ることが多い。どういうときにうまくいかないのだろうか。

その解決方法ではうまく課題が解決しない
ターゲットが狭い
ターゲットに届かない
開発が難航する

他にもあるかもしれないが、このように様々な理由によりプロダクト開発は失敗する。
じゃあ、失敗させてしまうプロダクトサイドは、エンジニアサイドは能力が低いのか?そんなことはない。実はここの失敗のメカニズムには「気遣い」が作用している。

プロダクトサイドの気遣い

エンジニアの方々、こんな経験はないだろうか。プロダクトサイドから「○○の機能がほしいんだけど、できますか?」と質問されること。

このとき、エンジニアに伝わるのは「解決方法」だけである。
何を解決したくて、その解決方法である機能を開発したがっているのか伝わらない。この状況では、当然ターゲットやチャネルも不明だ。

そしてこの状況でエンジニアが取りうるパターンは大別して2つ。

「できらぁ!!」と力強く引き受けるか

「できません」と突き放すか。「できるか」という問いには、こう答えてしまうだろう。

では、なぜプロダクトサイドは解決方法のみ伝えてくるのだろうか。

やることを決めるのは自分たちの責任だと考えている
検討段階からエンジニアに時間を取らせることは申しわけないと思っている
解決方法も考えずにエンジニアのところへ話をもっていくと仕事をしていないような気になる

私の観測範囲だが、こういった理由で「解決策まで頑張って考え、その解決策だけエンジニアに伝える」というケースが少なからずあるようだ。

気遣いゆえに「解決方法」のみを伝える。
しかしその解決方法はエンジニアからすると突飛な案だったり、既存システムとの連続性がない機能だったりして戸惑いが生まれる。そこで「できるできない」の押し問答だったりが始まってしまうわけだ。

エンジニアサイドの気遣い

エンジニアサイドのほうでも「課題、ターゲット、チャネルは何だろう」と考えるのではないだろうか。これは果たして必要なものか、ビジネスとして成立するのか、疑問に思うだろう。それでもそこをあきらかにせず開発がスタートしてしまうのは、その疑問をプロダクトサイドにぶつけず「まあ、ちゃんと考えてくれてるみたいだから」と妙な腹落ちをさせてしまうからだ。

言ってしまうと、プロダクトサイドとて完璧ではない。アイデアが先行して出てきて、課題があやふやだったりターゲットが定まっていなかったり、チャネルが想定できていなかったり。

こんな経験はないだろうか。

要望を受けて開発したが結局使われなかった
開発している中で機能が二転三転した
リリースしたがあまり使われなかった

完成した機能のうち2/3は使われない、という調査結果があるくらいだ。

こうして、互いの気遣いが本来議論しなければいけないところでの議論の手を止め、僕たちは失敗する。

我々はどうすればよいのか

プロダクトサイドの方、「エンジニアが頼んだものを作ることができない」と思ってしまっていないだろうか。

エンジニアサイドの方、「プロダクトサイドがよくわからない機能ばかり要求してくる」と思ってしまっていないだろうか。

そもそも同じプロダクトを作っている中で線引してしまうこと自体が微妙ではある。そこを打開するため、スクラム開発ではプロダクトオーナーのような役割が存在している。

しかし、企業によって事情は様々である。機能横断チームを作るということのハードルが高い場合は当然あるだろう。

では、機能横断チームでないと上記問題は回避できないのか?そんなことはない。

プロダクトサイドは、アイデアの背景にあるもの、課題・解決方法・ターゲット・チャネルを明らかにする段階からエンジニアサイドを巻き込めばいいのだ。
ターゲット、チャネルについてはプロダクトサイドが得意分野だろう。
しかし「課題を実現可能な方法で解決する」手段を見つけるのは、エンジニアが得意だ。
また、「課題」から共有しておくことで自分ごと化される。

エンジニアサイドは、疑問に思ったことは聞くようにするのだ。
仮に「○○の機能、できますか?」と問われても、まず1クッション。「その機能でやりたいことはなんですか?」「解決したいことはなんですか?」「どれくらいの人が課題と捉えていますか?」そういった質問を投げかけ、輪郭をはっきりさせていこう。
もしプロダクトサイドでもあやふやな部分であるならば、こういった問いかけで精度が高まることになる。よいプロダクトを作る、という観点では歓迎されるべき行動だ。
なにより、エンジニア自身も「なぜやるのか」を考えぬくことで、そのプロダクト開発をやり抜く覚悟ができるはずだ。

というわけで、我々はどうすればよいのか、はシンプルに「必要なコミュニケーションを取ろう」だ。「相手は忙しいし」「プロフェッショナルだし」と気を遣ったりせず、よいプロダクトをつくるために必要なことはなんでもやろう。そして共創していくのだ。