プロダクトマネジメント、要件定義が難しい大きな理由のひとつは、われわれが「未来を予測できない」ことだ。よかれと思って作ったものが、ユーザーの期待と外れたものになってしまうかもしれないし、外部環境の変化によって想定どおり使われないかもしれない。
それを知って知らでか、プロダクトオーナーやステークホルダーはとかく本当に使われるかわからないものを要求しがちだ。IMPACT MAPPINGでは、「よくある問題」として以下のものを挙げている。
- スコープクリープ(SCOPE CREEP)
- スコープの増大、やり過ぎ、過剰な品質など
- 誤ったソリューション(WRONG SOLUTION)
- ビジネス目標に向かっていない過剰で複雑なソリューション
- 「誰かの好み」で追加した機能(PET FEATURES)
- 全体の目標に貢献しない、誰かの好みで追加された機能
- 誤った仮説(WRONG ASSUMPTIONS)
- 明確でない、検証できない仮説に基づく要件
- 場当たり的な優先順位付け(AD-HOC PRIORITISATION)
- ビジネス価値に基づかない優先順位
よくある問題は「よくある」ものなのだから、誰もが犯す難しい課題であるのは確かなんだけど、根本的な心理に「ないよりあった方がいい」という思いがあるんじゃないかな。ここでは、そんな「あるといいかも」が完全に間違っていることを論じたいと思う。
良い要件ってなに?
良い要件、良い機能ってなんだろう。まずは単純に、達成するビジネス価値の大小で並べてみよう。
より良い
|
| ビジネス目標に対して効果抜群(たくさん使われて、みんなハッピー)
|
| ビジネス目標に対して効果いまひとつ(期待ほど使ってくれない)
|
| ビジネス目標に対して効果ゼロ(誰も使ってくれない)
|
より悪い
もちろん、上にある方が良くて、下にある方が悪い。でも、これだと「悪い」とまでは言い切れない。
では、損益分岐点はどこだろう。この機能を作ったことで儲けが出たもの、損を出したものはどこだろう。
お得 (+)
| ビジネス目標に対して効果抜群(たくさん使われて、みんなハッピー)
|
±0 ビジネス目標に対して効果いまひとつ(期待ほど使ってくれない)
|
| ビジネス目標に対して効果ゼロ(誰も使ってくれない)
大損(-)
効果ゼロな機能は、プラスマイナスゼロではなく、マイナスになってるところに注目してほしい。
使われない機能が大損な3つの理由
ビジネス目標に対して効果がなかった機能はなぜプラスマイナスゼロではなくてマイナスなのか。それには3つの理由がある。
開発にかかったお金がムダ
これはわかりやすく、一般にROIのInvestmentといえばこれ。その機能を開発するには少なくともエンジニアの人件費がかかったはずで、まるまるムダ。
開発に使った時間の機会損失
その機能を開発するのにかかった時間は、ほかの機能を開発するのに使えたはずの時間だ。効果のなかった機能の開発に使った時間の分だけほかの機能のリリースが遅れたわけで、そのリリースの遅れた機能が得られるはずだった利益は失われている。優先順位付けが重要なのはこのためだ。
複雑さが生み続ける未来のコスト
今回、言いたかったのがまさにこれだ。非エンジニアが意識するのが難しいのもこれだ。詳しく説明したい。
複雑になると増えるコスト
たとえば、建築物でたとえると、いまのシステムがこんなだとしよう。
これに機能追加をどんどんしていくと、こんな立派なものになると期待するかもしれない。
想像してみてほしい。次の要件が「壁を白く塗り直して」だとどうなるだろう。最初の家であればできた費用の何倍ものお金がハ◯ルの城ではかかる。後から付けられたたくさんの建築物によって、塗る壁の面積は増え、また構造が複雑になったことで手間も増えた。これだけ複雑だと、塗り残しができたりと不具合も出るだろう。それらは、最初の家のようにシンプルであれば必要なかったものだ。
損切りしよう
「でも使ってくれるかどうか、わかんないじゃない」と思うかもしれない。そのとおりだ。未来のことは誰にもわからない。ただ、「わからない」ところではあなたはギャンブルをしていることを認識しないといけない。よりビジネス風に言えばあなたはリスクを負っている。
「あるといいかも」な機能をたくさん使ってもらえたなら、あなたはギャンブルに勝ったのだ。ラッキー。
もし使ってもらえなかったのであれば、あなたはギャンブルに負けたのだ。ギャンブルに負けたときにすべきことはただ一つ。「損切り」だ。
効果が出ているか(使われているか)を継続的にモニタリングしよう。使われなかった残念な機能を切り捨てて、システムをシンプルな状態に戻そう。
さもなければ、ハ◯ルの城はいづれ増えすぎた自重で動かなくなり、誰もメンテナンスできない遺物となるだろう。