動くのに使われないPoCを防ぐ – プロダクトマネジメントに学ぶ4つのリスク

「動くものはできたのに、なぜか使われない…」そういったPoCを経験したことはないでしょうか？苦労して作ったプロダクトが使われなかったときほど、ガッカリすることはありませんよね。

この記事では、PoC案件で提案するときのチェックポイントを、プロダクトマネジメントの考え方を参考に紹介します。

---

顧客の声をそのまま実装することの落とし穴

SIerとして顧客から要件をもらうとき、つい「どう実現するか」に意識が向いてしまいますよね。ですが、顧客は業務のプロであっても、プロダクト開発のプロとは限りません。「こういうシステムがほしい」という声は、本当に解決したい課題の一側面でしかないことが多いです。

言われたものをそのまま作るだけでは、「動くけど使われない」プロダクトになりかねない、自分はそう感じています。

顧客の声の裏にある「本当に実現したいこと」に寄り添いながら、より良い価値を一緒に作っていく。それが私たちが掲げるCo-Creation Sherpa（共創の伴走者）としてのあり方だと思っています。

PoCで考えるべき4つのリスク

それでは、プロダクト開発のプロとして提供できるものとは何でしょう？ここで、プロダクトマネジメントの考え方が役立ちます。

プロダクトマネジメントの名著INSPIREDの著者であるマーティ・ケーガンは、自身のブログで「4つのリスク」を提唱しています。

1. 価値：顧客・ユーザーが本当に欲しいと思うか？使ってくれるか？
2. ユーザビリティ：ユーザーが使い方を理解して、迷わず使えるか？
3. （技術的な）実現可能性：エンジニアが時間・スキルの観点で実現できるか？
4. 事業実現性：販売・マーケティング・財務・法務など、自社ビジネスの各側面で問題ないか？

これはプロダクト開発の話ですが、PoC提案でも同じ視点が使えます。PoCは「本番開発に進む前に、リスクを早期に検証する」プロセスなので、どのリスクを検証すべきかを意識することが大事です。

まず最初に確認すべきリスク：作る価値があるか？

PoCに取り組むとき、つい「これは技術的に実現できるか？」という実現可能性の検証から始めがちです。顧客からの依頼も「（課題やニーズは、顧客の中に暗黙的になっている前提で）こういうシステムを作りたい」という形で届くことが多く、開発側としても実現可能性に意識が向くのは自然なことだと思います。

ただ、4つのリスクで言えば、最初に確認すべきは、「1. 価値」です。

いくらユーザビリティを高めて・実現可能性を検証しても、そもそも「使いたい」と思われないものであれば、意味がありません。多大な開発コストを払ってプロダクトが完成して初めて「あれ、使われない…」と気づく、という事態を防ぐために、価値リスクを最初に潰しておくことが大事です。

ケーススタディ：在庫管理ダッシュボードのPoC

具体的なイメージをつかむために、よくある依頼を例に考えてみましょう。

想定シナリオは「マネージャーのために、在庫データを可視化するダッシュボードを作ってほしい」という依頼です。4つのリスクの観点から、それぞれ何を確認すべきか見ていきます。

リスク	確認ポイント	検証方法	検証の完了基準
1. 価値	マネージャは、本当にダッシュボードを見て意思決定するか？「あれば便利そう」で終わらないか？	「過去1ヶ月でどんな意思決定をしたか」「このダッシュボードがあれば何が変わるか」をヒアリングする	現在の手段の非効率を具体的に言え、かつその非効率によって実際に困った経験（判断の遅れ・ミスなど）を挙げられる[1]
2. ユーザビリティ	迷わず使えるか？忙しいマネージャーでも、学習コストなしに使えるUIになっているか？	「在庫切れリスクの高い商品を探してください」などのタスクを与え、動くプロトタイプ上の操作を観察する	説明なしで5分以内に目的の操作ができる
3. 実現可能性	必要なデータが実際に取れるか？データ品質・既存システムとの連携は？	サンプルデータの取得を試みる、既存システムのAPI・DB仕様を確認する	必要なデータ項目が全て取得でき、更新頻度・データ品質が要件を満たすことを確認できる
4. 事業実現性	どのデータを誰が見られるべきか、データガバナンスと不整合はないか？	データ項目一覧を情報システム部門・法務に見せてヒアリングする	アクセス権限設計が承認され、法務・情シスからGoサインが出る

1. 逆に言えば、困ったエピソードが出てこない場合は、実はそこまで困っていないか、慣れによって非効率に気づいていないかのどちらかと考えられます。前者なら「実は価値がないかもしれない」というリスクが高い状態です。後者なら「今のやり方にどのくらい時間がかかっているか、どれだけミスが出ているか」を見える化してみると、潜在的に大きな価値があるのかを判断する材料となるでしょう。↩︎

補足：PoCの定義にとらわれすぎない

ここまで「PoCで4つのリスクを検証しよう」という話をしてきました。実は、PoCという言葉はもともと技術的な実現可能性（Proof of Concept）を指すことが多いです。つまり、狭義のPoCは3番目のリスクの検証、ということになります。最近では、価値を検証するPoV（Proof of Value）や、ビジネス観点の実現性を検証するPoB（Proof of Business）という言葉が使われることもあります。

ただ、言葉の定義にとらわれすぎる必要はないと思っています。顧客と一緒に作るプロダクトを成功させるためには、4つのリスクを認識すること、現在検証すべきはどのリスクかを見極めることが大切です。

---

この記事では、PoC案件で提案するときのチェックポイントとなる4つのリスクを、プロダクトマネジメントの考え方を参考に紹介しました。

次にPoC案件に関わる機会があれば、「どのリスクを検証しているか」を意識しながら提案してみるのはどうでしょうか。顧客との会話や提案の質が、少し変わるかもしれませんね。