エンジニアの生産性を上げるにはWHATよりもWHYを伝えること

ソフトウェアをエンジニアと共創していくときにどうしたら彼らの生産性をあげることができるのか？という質問をいただくことがあります。

そのときの端的な答えは、「WHATではなくWHYから伝えること」だと答えます。

完璧な要件が固まってから相談するというアンチパターン

多くのエンジニアではない新人プロダクトマネージャが陥りがちがアンチパターンがあります。

それは、エンジニアに気を遣ってできるかぎり作業時間を確保するために要件をギリギリまで詰めた状況になるまで話を持っていかず、なんとか「何を作るのか(WHAT)」が固まったタイミングではじめてエンジニアに共有するというパターンです。

また、それをジュニアなエンジニアだとそれを望むこともあります。なまにえの状態の仕様を持って来られても、またひっくり返ってしまうかもしれないから、「ちゃんと決まってから持ってきてください」とか言ってしまいます。

こうして、ちゃんときまったWHATが出来上がってからHOWの開発を進めようすると、現状のシステムとのミスマッチや開発に時間のかかる箇所などがあっても、それらすべてを開発しようとしても、効率化できる余地は少なくなってしまいます。

結果、思ったよりも時間がかかってしまって、エンジニアの技術力が低いのではないかという不信を招いてしまったり、もっと簡単にできるかもしれない仕様にしないプロダクトマネージャに対して、能力が低いのだと考えてしまったりと、両者に決定的な溝をつくってしまうこともあります。

また、予想以上に納期がかかってしまうときに、それを無理やり短期化を実現するために想像以上に品質を犠牲にしてしまうこともあります。

しかし、WHY（なぜ、その機能が必要か）という一段抽象的な目的を理解できていると、別のWHATが浮かぶ可能性があります。そちらのほうが適切な速度でマーケットインできる可能性があり、そうすればもしかしたら生産性が高いと感じられるかもしれません。

ケーススタディ：本当に試したかったこと

以前、あるPMの方に相談された例をお話しします。

とある自社サービスにToC向けの決済機能を実装する話があった際に、自社のエンジニアに相談したところ、「そのサービスに決済機能を実装するには、既存サービスとの繋ぎ込みや、セキュリティなども考えた上でのテストも含めると半年以上かかる」と言われたそうです。

PMは「半年だとかかりすぎだ」と考え、もっと生産性をあげることができないだろうかと考えたそうです。できる限り、エンジニアの時間も確保できる様にしているのに、どうしてだろうと。

そのときに、蔑ろになっていたのは「なぜ、その機能をつけたかったのか」ということです。それを聞いてみると、あるTo B向けの商材が実際にTo C向けに売れるのかどうかをテストマーケティングしたかったそうです。その商材は買い切りで、サブスクリプションなどではなかったそうです。

それを聞いてみると、別の実装方式が浮かびます。

たとえば、デジタルコンテンツも販売できるようなECカートサービスとランディングページを利用する様な方法です。販売したコンテンツにアクセスリンクを渡しておき、そのリンクがあれば決済済みとみなすような実装であればどんなシステムでも比較的手軽に実装できます。

もし、販売効果がよければしっかりとした実装をすれば良いですし、販売効果が悪ければその機能を取り除くことも簡単です。

もちろん、完璧にインテグレーションされた決済方式の方が、コンバージョンレートが高いことは間違いないと思います。しかし、需要のある商材であるかどうかを検証したかったのであれば、十分な機能になります。

このような提案は優れたエンジニアならできたほうがいいというのは、そうかもしれませんが、WHYの部分がブラックボックスになり過ぎていると、ほかのWHATの提案は的外れになりがちです。

また、いろいろなところで共有しているのだからきっと理解しているだろうというのもすこし傲慢な考え方です。何かを伝えるときはしっかりとWHYとWHAT、そしてどんなアウトカムを実現したいのかをしっかりと構造立てて伝えることが重要です。

エンジニアの生産性を上げる方法として気を遣ってあまり情報共有しないというのは、アンチパーンだと覚えてもらえればありがいです。