トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

製品開発の失敗率を下げるために意識すべきこと

こんにちは、iOSエンジニアの高です。 みなさん、製品開発してますか?うまくいってますか?

開発しているとうまくいくこともあれば、残念ながら失敗してしまうこともあると思います。 開発自体がうまく進まないこともありますし、開発は順調なんだけれど、リリースしてみると誰も使ってくれないみたいなこともありますよね。

今日は、プロダクトマネージャの教科書であるINSPIREDから、こういった失敗をいかに防ぐか、という内容を紹介したいと思います。 個人的に本書で一番大事なんじゃないかと思えた部分です。

それは、PART Ⅰ CHAPTER6にある「製品開発が失敗する根本的原因」です。 結構序盤にあるのですが、かなり大事なことが書かれています。 これを初めて読んだ時、

うわっ、分かる!あるある!

と、首がもげるくらいうなずきながら読んでいました。

僕たちが製品を開発する目的は何でしょう。 アプリを作ること?サービスをリリースすること?
もちろんそれは大事なことです。しかし、それだけではありません。

アプリであっても、サービスであっても、それを通してユーザーの課題を解決することが本当の目的であるはずです。

ありがちな開発プロセス

ほとんどの企業で行われている開発プロセスがこちらです。

f:id:y_koh:20201209155558j:plain

上から順番に見ていきましょう。

まず、アイデアがあります。これは経営幹部、オーナー、顧客などからもたらされることが多いです。 そのアイデアをロードマップに落とすのですが、リソースは限られているので他製品との優先順位付けが必要になります。 そこでビジネスケースを作ることになります。

このビジネスケースには、

  • その製品がどのくらいの利益を上げるのか
  • 提供にどれくらいの時間と費用がかかるのか

が記されることになります。

これにより、優先順位を付けやすくなりますし、何よりステークホルダーが納得しやすくなります。優先順位が付けられると、ロードマップが作成されます。四半期とか、1年間で作られることが多いですね。

ロードマップが完成すると、次に、デザイナーやエンジニアに何を作るのかを伝えるために、要求事項をまとめます。 これはユーザーストーリーだったり、機能仕様書だったりと形は様々です。それをもとにデザイナーがデザインをし、最終的にエンジニアに要求仕様書とUI/UX仕様が届きます。

エンジニアはここからなるべく早く出荷できるように心血を注ぎます。 そして、QAチームからゴーサインが出ると晴れてリリースとなり、実際の顧客に届きます。

長々と説明してきましたが、まぁよくある開発プロセスですよね。 このプロセスですが、流れとしてはとても綺麗で何の問題もない様に見えます。 効率的に進めていこうとすると、だいたいこの流れで進めていくことが多いと思います。

あれ?ちょっと待ってください。

ではこれの何が問題だというのでしょう。

実は今説明した開発の流れは、ウォーターフォールプロセスそのものなんです。 昨今、市場の流れが早く、製品開発はLEANだのアジャイルだと素早さを求められることが常となっています。なのに、開発プロセスはウォーターフォールのままである。ということに著者は警笛を鳴らしています。

もちろん、作るものが決まっていてそれがリリースする時になっても変わらないのであればウォーターフォールは有用なことはあります。何よりプロセスとして分かりやすいです。 しかし、今日、そのようなケースはかなり稀になってきているのではないでしょうか。

この手法の10の大きな問題点

では具体的に、このプロセスの何が問題なのか、もう少し深掘ってみましょう。 問題点として、10のリストが挙げられています。 どれ一つをとっても開発チームを失敗させる理由になり得るものです。

  1. ウォーターフォールプロセスは販売主導の製品やステークホルダー主導の製品につながる。これでは、開発チームへの権限移譲が行われず、ただの傭兵になってしまう。
  2. ロードマップを考えるためのビジネスケースは実にばかげている。なぜなら、どれだけの利益を得られるかは、ソリューションの出来にすべてがかかっているから。
  3. ロードマップ主導で進めると、そこには2つの不都合な真実がある。1. 少なくとも私たちのアイデアの半分はうまくいかない。2. 可能性が証明されたアイデアでさえ、ビジネス上必要な価値を持つところまで実装を進めるには、いくつかのイテレーションが必要(タイムトゥマネー)
  4. プロダクトマネジメントの役割が要求仕様をドキュメント化することになり、プロジェクトマネジメントの1形態と変わらない
  5. プロセスの中でデザインの真の価値を取り入れるのが遅すぎる。遅すぎる参画は、ガラクタにペンキを塗る様なもの
  6. 一番タイミングを失しているのは、エンジニアの仕事を導入するのが遅すぎる点。製品開発の小さな秘密は、エンジニアはいつも最も優れたイノベーションの源であるということ
  7. アジャイル開発の投入が遅すぎる。開発段階で取り入れてもアジャイルの価値の20%ほどしか享受できない
  8. プロセス全体が非常にプロジェクト中心になっている。プロジェクト自体がアウトプット(出力)になってしまうが、本来、製品はアウトカム(成果)である。最終的には何かがリリースされるが、それは目的に合致したものではない
  9. 最大の欠点は、全てのリスクが最後に来る点。顧客実証が行われるのが遅すぎること
  10. 最後に一番大きな損失は、組織がその代わりに選択できたはずであり、選択すべきだったことの機会損失である

いかがでしょうか。 太字にしている部分は個人的に特に刺さった部分です。 本当は全て太字にしたいくらい、、本当に大切なことが書かれています。

特にアウトプット(出力)とアウトカム(成果)の話はこの中で一番意識したい部分です。

「最終的には何かがリリースされるが、それは目的に合致したものではない。」とあります。

リリースしたのに目的に合致していない?頑張って作ったのに?

これは、

  • プロジェクトをやり遂げたこと
    • これはあくまで何かをしたというアウトプット(出力)
  • 実際に顧客に必要とされている製品
    • これがアウトカム(成果)

だということです。

アウトプット自体に価値は無いんですよね。

目的がブレてしまわないために

僕が好きな開発プロセスでデザインスプリント - Wikipediaがあります。 デザインスプリントではこの様に目的のブレが起きてしまわないように、最初に、中長期目標と、何が達成されたらその目標が達成と言えるか、というスプリントクエスチョンを決めます。 これをデザインスプリントの期間中、必ず見えるところに貼り出して、常に全員でこれを見ながら進めることになります。

これは、「だからデザインスプリントが良いんだよ」という話ではなくて、それくらいしないと目的はブレてしまうということなんですね。ブレるほうが自然なんです。だからブレない仕組みを導入している、ということになります。

まとめ

僕たちは開発はもちろんですが、顧客の課題を解決できる製品を、素早く実現し、そして提供することが価値となります。
そのためには、今行っている活動を全て意味のある活動に変えていかなければなりません。
アウトプット(出力)では無くアウトカム(成果)を意識して取り組むきっかけになればと思います。

さいごに

トレタは今色んな新しいことを始めているところです。 興味がある人はぜひ遊びに来てください。

仲間も募集しております!

© Toreta, Inc.

Powered by Hatena Blog