プロジェクトマネージャーが行う「問題定義」とは

プロジェクトは一般的に問題定義、優先順位決定、実行の3ステージで進めていきます。
その中でも今回は「問題提議」について着目し、その必要性や大まかな流れについて解説していきます。

プロジェクトマネージャーにも問題定義が必要なわけ

同じPMと略されがちなポジションにプロジェクトマネージャーとプロダクトマネージャがあります。一般的にプロジェクトマネージャーの仕事は品質やスケジュールと言ったプロジェクトの実現を管理する事であり、プロダクトマネージャーの仕事は顧客に届ける価値が最大化するようプロダクトを管理する事なため、この2つは区別されがちです。
しかし、その本質には「良い物を作る」という共通の目標があり2つの違いは優先度の違いに過ぎないのではないでしょうか？

多くの場合、プロジェクトにおける「問題定義」はプロダクトの価値を追求するプロダクトマネージャーに必要なスキルとして述べられます。では、プロジェクトマネージャーには問題定義が必要ないのでしょうか？
プロジェクトマネージャーは限られた期間でプロジェクトを成功させる事が最大の目標です。解決すべき問題は複数の詳細な問題が関わり合っている事が多く、その全てを解決しようとしていてはとても時間が足りません。そのために最も優先すべき問題は何か見抜くスキルが求められ、プロジェクトマネージャーにも問題定義が必要となってくるわけです。

それでは実際どのように問題定義をしていけば良いのか、セブンデックスのプロジェクトマネージャーが行っている流れを元に説明していきます。

問題定義と解決プロセス

問題定義では問題を分解し原因の仮説を立て、定量データと定性データに照らし合わせる事で仮説の妥当性を検証し解決すべき詳細な問題へと絞っていきます。

仮説を立てる

まずファネル分析やKPIツリー/ロジックツリーで物事を構造的に分解する事で、俯瞰して問題を捉えていきます。そうする事により、分解した項目が起こる原因は何かと仮説を立てる事が出来るようになります。

ロジックツリーの作り方については以下の記事で詳しく説明していますので是非ご覧ください。

定量データから行動を把握する

構造的に分解した樹形図などに対し、実際のデータを当てはめていく事で仮説の検証を行っていきます。
複数の原因が見えてきた際には、制作期間などを考慮しこの数値が上がる事で一番インパクトが大きいものはどれかと原因を絞っていきます。

例えばECサイトにおいて「売り上げをあげたい」という問題があった場合、「カートに商品は入れるが結局購入してくれない人が多いからではないか」という仮説を立てたとします。実際にカゴ落ち率のデータと照らし合わせ、業界平均の70%に対して83%と高い値を示していれば平均より13%も高いから改善の余地があると判断する事ができます。

定性データから気持ちを把握する

原因が見えてきたらなぜユーザーがそのような行動をとってしまっているのか考えていきます。
定量的なデータからはユーザーの行動しか分からないため、定性データと組み合わせる事で推定していきます。実際にプロダクトがある状態ではユーザビリティテストなど手法が有効です。

先ほどの例で考えた場合、ユーザビリティテストを行い商品をカゴから外したタイミングの気持ちについてインタビューをしたり、操作で戸惑った場面はなぜ戸惑ったのかなどを聞いて原因を突き止めていきます。

詳細な問題が見えてくるまで繰り返す

データと照らし合わせ仮説が間違っている事が分かれば、仮説を立て直し問題定義を繰り返していきます。取り組むべき詳細な問題が明らかになってはじめて具体的な施策を考えていく事ができます。

また、そもそもデータが無い場合はデータを収集する所から始める必要があります。
この際に気をつけないといけないのは、仮説を立ててからデータを収集しないと意味がないという事です。取り敢えずデータを収集しようと始めると、実際には仮説の推定に使えないデータしか集まらなかったという事になってしまうからです。

具体的な手法

KPIツリー

企業が最終的に達成したい目標であるKGI(重要目標達成指標)を、1つ1つのKPIに分解していきます。KPIを設定することで追うべき指標を明確な数値データで表す事ができるようになります。

KPIツリーの作り方については以下の記事で詳しく説明していますので是非ご覧ください。

ファネル分析

離脱率に焦点を当てた分析で、コンバージョン(webサイトにおける最終的な成果)に至るまでのプロセスを段階的に分解し各段階での離脱率を把握していきます。
ファネルとは漏斗のことで、コンバージョンを一番下に設定したとき段階を踏む事にユーザーは絞られていく様子が似ている事からついています。その中から極端に減少している箇所を見つける事で、問題の原因を探っていきます。

ユーザビリティテスト

ユーザーに対して実際にプロダクトを触ってもらい、設定した課題をこなしてもらう事で使いやすさの評価を行います。

ユーザビリティテストの進め方と、使いやすさの評価の軸となるユーザービリティについては、以下の記事で詳しく説明していますので是非ご覧ください。

ヒューリスティック評価

ユーザビリティテストは時間や費用がかかるといった問題からヒューリスティックス評価を用いる場合もあります。
ヒューリスティック評価はHCD(人間中心設計)の専門家がユーザビリティ10原則などのガイドラインを参考に、経験則を元に分析・評価を行います。HCDの資格を持った専門家がいないといけない事や、分析者の経験に依存するという点には注意が必要です。

ヒューリスティック評価については以下の記事で詳しく説明していますので是非ご覧ください。

まとめ

今回はプロジェクトマネージャーが行う問題定義について解説してきました。
プロジェクトマネージャーとプロダクトマネージャーも「良いものを作る」という共通の目標を持っており、その違いはそれぞれの担う最終的な目標による優先度の違いに過ぎません。プロジェクトマネージャーは施策を考える際、「実現可能性」「スピード」「インパクト」の考慮が大切であり、そのためにはどの詳細な問題を解決する事が最も効率が良いか見極めが大切です。
限られた期間でプロジェクトを成功に導く必要があるプロジェクトマネージャーにこそ問題定義が必要であると言えるのではないでしょうか。

この記事をシェア

UXUIデザイン支援資料

セブンデックスのUXUIデザインプロセスと実績詳細が解説されている資料を無料でダウンロードできます。