さて、あなたは製品開発にスクラムを実践することを決定したものの、どこからどのように手を付けたらいいのか、または始める前に対処する必要のある重要な項目が何なのかがよく分からない、という状況だとしましょう。 新年を迎える準備をするときのように、立ち止まって、新たな取り組みにおいては、確実に、明確な目的と期待値を設定してから始める絶好の機会です。
そして、朗報です！ スクラムは、特別な機器やツールを必要とせず、簡単に始めることができます。 スクラムとは、自由な透明性、頻繁な検査、および即時の適応を確保するための単純な経験的フレームワークです。 スクラムの経験主義を可能にする３つの役割、３つのアーティファクト、および ５つのイベントについては、 『スクラム ガイド』で概説されています。
ただし難しいのは、スプリントの実行を開始する前に目的を定義する方法を知らなければならないことです。 スクラムはフレームワークであるため、これを行う方法や、開始する前に考慮すべきことは規定されていません。 大丈夫です。 当社では、数多くのスクラムチームが実践を開始する支援をしてきましたので、開始する前に知っておく必要のある事項に関するガイダンスを次に示します。
１ 戦略的安定性の確保
スクラムを使い始める前の最初のステップは、 製品のビジョンを明確に定義することです。 プロダクトオーナー、顧客、主要なステークホルダー、および開発チームは、次のような最終製品の大まかなスケッチを定義するために協力する必要があります。
- ターゲット顧客は誰ですか？
- 解決するべき課題は何ですか？
- あなたの製品はそれを解決するために何をしますか？
- それを解決するためのあなたのアイデアは、代替案と比較してどのように異なり、価値がありますか？
- あなたの提案するソリューションやアイデアは、組織全体の戦略や目的とどのように一致していますか？
目的を定義するときは、通常は少ないほど良いということを覚えて、ビジョンステートメントをシンプルで理解しやすいものにしてください。 製品のビジョンを説明するために何ページも要する場合、最終的な目的地が何であるかを本当に知らない可能性があります。 2〜3文で説明できれば（エレベーターピッチのように）、あなたの取り組みは、チーム全体で理解できるものであるということになるでしょう。
何かをする前にすべてを知る必要はありません。 プロジェクトまたは製品ライフサイクルの開始時には、製品またはプロジェクトについてほとんど知りません。 まず第一に、それを受け入れてください。 簡潔なビジョンステートメントと 全体的で消化しやすい製品ロードマップから始めて、製品ビジョンをどのように達成するかを視覚化することは、開始するために必要な基礎です。 あなたのビジョンはあなたの道しるべ、または目的地です。 あなたが望む目的地にたどり着く方法（戦略）は、実験を通じてさまざまな方法（戦術）で達成できます。
２ たくさんの実験をする心づもりで
あなたのアイデアは、たくさんの仮定に基づいています。 仮定（つまり仮説）をテストするために、実験を継続的に実行する必要があることを知っておいてください。 実験はリリースとスプリント内で行われます。 スプリントレビューのステークホルダーや、各リリースのエンドユーザーからのフィードバックを集めることは、 スプリントとリリースの目標で行われた仮定を検証するために使用するデータになります。
製品ロードマップがあれば、プロダクトバックログを最初に削減できます。 当然、着手する前の段階では、プロダクトバックログはまだ高度なディテールです。 心配しないでください、あなたのチームのプロダクトオーナーが、優先順位の大まかな考えを持っていれば、それで十分です。 最優先機能は、この段階でプロダクトバックログ内にあるする必要があります。
プロダクトオーナーが優先順位を決定する際に使用する必要がある 2 つの主なファクターは、価値（ビジネス価値または顧客価値）とリスクです。 価値は当たり前だと思うでしょう。しかし、なぜリスクの高いプロダクトバックログ項目を優先して最初に実装する必要があるのか疑問に思う場合は、最初に次のようなことが行われていると考えてください：
- 製品のライフサイクルで再び使用できる最もシンプルなシステムがある
- 「離陸」を成功させるために残っている長い長い滑走路がある
- 仮定を検証し、既知のリスクを軽減するために、自由に使えるリソースが最も多くある
- 最もリスクの高い項目が何らかの理由で何らかのタイプの障害を引き起こす場合、少なくとも、迅速、早期、安価に失敗することができる
覚えておいてください：実現不可能なことはしない １つのスプリント分のプロダクトバックログ項目のみで、実験を開始して仮定を検証し、顧客に価値を提供し、貴重なフィードバックの収集を開始できます。 ノードストロームがエンドカスタマーと直接これを行った方法をご覧ください 。
３ プロダクトオーナーが成功の鍵
多くの場合、プロダクトオーナーの役割が誤解されているか、次の少なくとも下記の１つの方法で導入が不十分であるために、製品が失敗することがあります。
- プロダクトオーナーが、毎日スクラム チームと連絡を取れない
- 組織が、顧客、ステークホルダー、および開発チームとの協働に専念する人を当てていない
- プロダクトオーナーが、クライアントや開発組織から、毎日厳しいビジネス上の意思決定を行う権限を与えられていない
- ２人以上のユーザーがプロダクトオーナーの役割を果たそうとしているため、優先順位と方向性について混乱が生じている
- プロダクトオーナーの役割を担う人物が、顧客やユーザーから切り離されている（例：ＩＴ部門出身、業界に不慣れ、プロダクトオーナーシップのテクニック精通していないなど）
- プロダクトオーナーが、優先順位の決定が下される理由について、ステークホルダーや開発チームにオープンでない
- プロダクトオーナーが、顧客のニーズを満たすために特定されたソリューションを技術的に実装する方法を開発チームに指示する
プロダクトオーナーが、製品に関する厳しいビジネス上の決定を下せるようにすることで、プロダクトオーナーへの信頼が築かれます。 経営陣とスポンサーは、プロダクトオーナーを信頼し、それに応じて意思決定を委任する必要があります。 各スプリントレビューに関与するすべてのステークホルダー（経営陣、スーパーバイザー、スポンサーなどを含む）は、月に複数回、製品の開発に影響を与える機会があります。 ステークホルダーは、権限を与えられたプロダクトオーナーを日常的に管理し続ける必要性を感じる必要はありません。 プロダクトオーナーが、ステークホルダーたちに、あらゆる意思決定についてアプローチしなければならないとなったら、スクラムチーム、顧客、組織は、プロダクトオーナーに対する信頼をすぐに失います。 また、このような遅延および分散化された変更管理では、顧客のニーズや市場の状況の変化に効果的に対応することはできません。
さらに、プロダクトオーナーをスクラムチームと同じ場所に配置することもお勧めします。 プロダクトオーナーは、過重労働になったり、複数の製品や多様な責任を負ったりしてはなりません。 プロダクトオーナーへのアクセスの欠如は、上記のプロダクトオーナーの導入が不十分である主な要因です。
プロダクトオーナーは、優れたコミュニケーションスキルと交渉スキルを持ち、スクラムチームだけでなく、より広範な製品チーム（つまり、スクラムチームとステークホルダー）と効果的に関わり、先見の明があり、実行者である必要があります。 これらの資質と適切なエンパワーメントにより、プロダクトオーナーはスクラムチームを成功に導くために必要なものになります。
新年にご自身の製品を成功させるための準備を整えたい場合は、 弊社がご提供する講座に参加する か、 コーチングのアドバイザーにご連絡ください。
