製品開発とプロジェクト管理の世界では、MoSCoW の優先順位付け方法が多くのチームにとって頼りになるフレームワークになっています。シンプルで直感的で、バックログ管理の混乱を明確にすることが期待できます。しかし、この一般的なアプローチが実際に私たちを失敗に導くとしたらどうなるでしょうか?
MoSCoW の優先順位付けは、表面的には強力であるように見えます。製品バックログを整理するための 4 つのきちんとしたバケットが提供されます。
- 必需品
- あるべき
- あったかもしれない
- ありません
バックログ項目をこれらのバケットのいずれかに分類するたびに、明確さと進歩の満足のいく感覚を得ることができます。しかし、これはまさに、製品開発の過程で本当に重要なことを見失ってしまう危険がある瞬間です。
MoSCoW の中心的な問題は、フレームワーク自体ではなく、それが通常どのように適用されるかにあります。数人の経験豊富な実践者がディスカッションで指摘したように、チームは、望ましい結果から始めるのではなく、機能から製品範囲をリバースエンジニアリングするという罠に陥ることがよくあります。
あるプロダクト リーダーは、「製品の動作方法から、これから構築する範囲をリバース エンジニアリングすることはできません。」と述べています。この洞察は、MoSCoW がしばしばその約束を果たせない理由の核心に迫っています。
製品開発を成功させるには、特徴や機能から始めるのではなく、次の 3 つの基本的な質問から始める必要があります。
- ユーザーの理解: 私たちの製品のユーザーは誰ですか?彼らの目標は何で、何を達成しようとしているのでしょうか?彼らのやるべき仕事は何でしょうか?
- 価値創造: 私たちの製品はこれらのユーザーにどのように価値を与え、彼らの目標達成に役立つのでしょうか?
- 価値の獲得: ユーザーにとって、それをビジネス価値として捉えることができるほどの十分な価値を生み出したのはいつですか?
これらの質問により、私たちは製品がどのように機能するかの詳細に迷うのではなく、製品によって何が可能になるかを考えるようになります。
さまざまな製品リーダーや実務者との議論を通じて、MoSCoW に関するいくつかの重要な問題が明らかになりました。
あるプロジェクト マネージャーは、「最終的には必須のことが 20 個になる可能性がありますが、それでも優先順位を付ける必要があります。」と述べています。すべてが必須になると、フレームワークはその有用性を失います。
あるビジネスアナリストは、「ユーザーの目標アンカーや、私たち（またはユーザー）がどのようにユーザーのパフォーマンスを向上させたいかという指標を持たずに優先順位を付けることは、芝居がかったものである」と指摘しました。 MoSCoW は、重要なコンテキストを取り除いて複雑な意思決定を過度に単純化する可能性があります。
何人かの実務者は、MoSCoW がユーザーのニーズとビジネスの成果を真に理解するという困難な作業を実際に回避しながら、適切な優先順位付けが行われているという錯覚を引き起こす可能性があると述べました。
その限界にもかかわらず、一部の専門家は MoSCoW の特定の使用例を擁護しました。
- 固定タイムラインプロジェクト: 期限が厳しいプロジェクトでは、MoSCoW は重要な機能を迅速に特定するのに役立ちます。
- MVP 計画: 最小限の実行可能な製品を定義する大企業の場合、これは議論の出発点として機能します。
- ステークホルダーとのコミュニケーション: 新しい製品所有者や関係者に優先順位の概念を説明するのに役立ちます。
議論からいくつかの代替案が浮上しました。
実践者の中には、よりシンプルな「今、次、後で」の分類を好む人もいます。これにより、柔軟性が維持され、「必須」カテゴリーが過負荷になる傾向が軽減されます。
この手法は、チームが優先順位を決定しながら結果に集中し続けるのに役立ちます。
問題点分析と発生頻度を組み合わせることで、より微妙な優先順位付けの洞察が得られます。
製品開発を成功させる鍵は、MoSCoW と他の優先順位付けフレームワークのどちらを選択するかということではありません。それは、結果に絶え間なく焦点を当て続けることです。あるコメント投稿者は次のように鋭く指摘しています。機能は結果を提供するためにのみ存在します。」
- ユーザー調査から始めましょう: ユーザーにどのような機能が欲しいかを尋ねるのではなく、現在のワークフロー、課題、目標を理解します。
- 成功指標の定義: ユーザーの行動の変化と組織の戦略に結び付く明確な指標を確立します。
- 柔軟性を維持する: 達成しようとしている成果に焦点を当てながら、範囲を柔軟に保ちます。
- フォースランキング: 優先順位付けが必要な場合は、難しい決定を明確にするために、バケットではなく強制ランキングを使用することを検討してください。
MoSCoW の優先順位付けは特定の状況では役立ちますが、機能優先の考え方を奨励することでチームを誤った方向に導くことがよくあります。より良い製品開発への道は、望ましい結果を明確に理解することから始まり、それらの結果を達成する方法について柔軟性を維持します。
覚えておいてください: ユーザーは機能バケットを気にしません。彼らは目標を達成することに関心を持っています。そこから始めて、機能が後を追っていきます。
#MoSCoW #の優先順位付けの問題 #ウマルナシル著 #アジャイルインサイダー #年 #月