プロジェクトスコープを決める際に考える２つのこと

はじめに

プロダクトマネージャーの仕事のうち、最も実力が試されるイベントの一つとして、「プロジェクトの計画」が挙げられます。ここで言う「プロジェクト」とは、日々数字を見て改善するグロース的なプロダクト開発とは違い、ある程度大きな投資（Investment）をしてある程度大きな成果（Return）を得ようとする、中長期に渡って進めるプロダクト開発のことを言います。アジャイルとかウォータフォールとかの開発手法の違いではありません。

プロジェクト計画の中で重要なことの１つが、プロジェクトスコープの策定です。この決め方次第でプロジェクトの成否は決まってしまうと言っても過言ではないと思います。というわけでスコープの決め方についてのポイントをまとめていきます。

余談

いきなり余談ですが、こちらの記事にもあるようにプロダクトマネージャーとプロジェクトマネージャーは担うべき役割が違います。

https://aboutproduct.jp/media/career/86/より引用

もし組織が充実していて、プロダクトマネージャーとプロジェクトマネージャーを担う人が完全に分かれているのであれば、上記の図にように役割分担しても問題ないでしょう。実際に自分はリクルート時代にプロジェクトマネージャーとして大きなプロジェクトをリードしていたことがありましたが、その際は別のプロダクトマネージャーが方針を決めて結果に責任を持っていました。

しかし、きれいに分担できるほど恵まれた組織は多くはありませんし、完全に分担してしまうと目的が異なる２人のコミュニケーションコストがそれなりに高くなるデメリットもあります。つまりプロダクトマネージャーがプロジェクトマネージャーの責務も担うケースは多々あるのです。こちらの記事にもあるように、プロジェクトマネジメントはプロダクトマネージャーにとっても必要なスキルの一つと言えます。

時々「プロダクトマネジメントとプロジェクトマネジメントは完全に異なるものだ」のように二項対立的な主張を見かけるので、必ずしもそうではないよということを余談として書かせていただきました。

スコープの決め方

では本題に入ります。

スコープはQCDSのバランスを見ながら決めます。QCDSとは品質(Quality)、予算(Cost)、納期(Delivery)、スコープ（Scope）の頭文字をとった言葉で、インセプションデッキのトレードオフ・スライダーでも登場します。

QCDSの全てMAXに満たせれば何も悩む必要はないのですが、資源（人・時間・金）は有限です。何かを満たすには何かを諦めなければいけません。

しかし一般的に、QCDSの定義に着手する前から予算（C）と納期（D）がある程度決まっていることが多いです。余程ビッグプロジェクトではない限り投入できる予算の上限は決まってますし、この変化の激しいご時世では「じっくり時間をかけておk」とはなりません。また同様に品質（Q）も業界やフェーズ、プロジェクトの特性などからほぼ自動的に決まってしまいます。

一方でスコープ（S）はこの時点では各案件の解像度が粗く、とりあえずやりたいことを列挙しているだけの状況が多いです。よってプロジェクト目的に直結しない内容も含んでしまっていることが多いです。俗にいう「ついでに案件」ですね。つまり調整の余地が少ないQCDに比べ、Sは調整する余地が多分に残っています。この調整（主に削減）をしないで突き進むと、見事にデスマーチプロジェクトの誕生となります。

ではどうやってスコープを選ぶのか。

凄まじく単純に考えると、各案件の価値（重要度）の高い方から順番に並べていって、それぞれの工数の見積もりを足し合わせて、それがCとDを満たせないボリュームになったらそこで打ち止めにする方法が考えられます。

例えばQCD目標を満たす上で許容できる最大のストーリーポイントが"10"と見立てられた場合、案件1~3までがスコープになります。

このプロジェクト単体を担うプロジェクトマネージャーであれば、このスコープ選定方法で問題ないかもしれませんが、長期的なプロダクトの成長を考えなければいけないプロダクトマネージャーはこれでは不十分です。残りの案件4,5を開発する次のプロジェクトのことも考える必要があります。

よって、以下の２点に注意してスコープ選定を見直すことが求められます。

1.まとめてやると効率の良いものはないか

例えば案件1を「請求業務効率の改善」とします。この案件を分解すると

• 請求機能の開発
• 請求オペレーションの見直し
• データ連携仕様の見直しと開発

というタスクが出てきます。

そして案件4を「分析機能の改善」とします。この案件を分解すると

• 分析機能の開発
• データソースの追加

というタスクが出てきます。

ここで「データ連携」に関する共通のタスクが出てきました。案件4の実施可能性が高いのであれば、また案件3と4の重要度にそれほど大きな差がないのであれば、案件4をスコープに入れるか、案件4の方式検討だけでもスコープに入れることを検討するべきです。逆に案件4を一切考慮せずに案件1を進めてしまうと、後のプロジェクトで手戻りが起こり、そちらのスコープが跳ね上がるリスクがあります。

これはシステム的な要素に限らず、営業戦略やオペレーションフローの見直しなども含まれます。作業効率の観点で２回考えるよりも１回でまとめて考えたほうが良いタスクがないかどうかを見極めます。

もちろんまとめることによってコストや工数が膨れ上がり、その結果QCD目標を満たせなくなるのであれば、スコープに含めるべきではありません。ここのバランスを取るのが難しいのですが、考えずにスコープに入れないのと、考えた上でスコープに入れないと決断するのでは大きく意味が違います。

2.まとめてやると価値の相乗効果が生まれるものはないか

例えばこのプロジェクトが大規模な販促キャンペーンとセットで行う類のものだった場合、アプリケーションのリファクタリング案件よりも、目立つ機能追加案件の方がキャンペーンの効果を最大化できます。仮にその機能自体が持つユーザー価値がそれほど大きくないとしても、別のPR的な価値を持つことになります。例えばtoBプロダクトにおいて、データが集まってない中で作る分析機能はほとんど意味がないですが、それっぽい分析機能があるというだけでユーザーが食いつくかもしれません。もちろんリファクタリングしないと障害が起こる可能性が極めて高い状況だとその限りではありませんが。

タイミングによって価値の大きさが変わる案件を見極めて、先にやるべきか後回しにして良いのか検討するべきです。

この２つの考え方でスコープ選定を行います。

そしてこれを行うためには、各案件の解像度をどれだけ上げられるかが勝負です。ビジネス構造やマーケット状況、オペレーションフローやアーキテクチャなど、様々な情報を詳細に把握した上で決める必要があります。ここがプロダクトマネージャーとしての腕の見せ所です。

お詫び

ここまで読んだ方のなかに「普通のことしか書いてないじゃん」と思われた方もいるかもしれません。

私もです(´･ω･`)

書き始める前はもっと数式を使ったりしてフレームワーク的なスコープ選定方法を編み出せると思っていたし、実際はこんなに単純なものではなくもっと言いたいポイントがあるのですが、まとめていくうちにどんどん普遍的な内容になってしまいました…

まあでも普通なんですけど、大事なことなんですよね。各案件の解像度を上げずにスコープ選定をして、途中で大炎上したプロジェクトを多く見てきました。そんな悲劇を少しでも生み出さないようにするために、記事として公開することにしました。

もし他に良いノウハウがあれば教えてください。