プロダクトの観点
最終更新
役に立ちましたか？
初期の段階で大事なのは、これから作るもののビジネス価値やプロダクトビジョンを明確にすることです。 そしてこのビジョンは、これから作るものの責任を負っている人が誰なのかが明らかでないと決まりません。 つまり人の観点に依存していると言えます。
なお、この時点では詳細な要求に踏み込まず、全体像を把握することが最優先です。
また開発以前の話としてビジネスモデルの整理をしないといけないこともあります。 ビジネスモデルの整理には、例えばビジネスモデルキャンバスやリーンキャンバス、ユーザーインタビューなどのツールが利用可能です。 実際の開発には多額のコストがかかります。 アイデアやビジネスモデルの検討が不十分で見切り発車してしまうと、多くの時間とお金をかけたあとにニーズがないことが分かった場合に大きな損害になってしまいます。 もちろん必ずプロダクトが当たるという保証などできませんが、あまい見通しだけで進めるのは無謀です（逆に半年も1年も検討だけしていても意味はありません）。
作るものの特性が分からないとどんな開発の仕方をするかは決まりません。 つまり開発手法はこの時点ではスクラム一択ではありません。 では、どのようにして開発の手法を選択すればよいでしょうか。
問題の性質を分類するフレームワークの1つにスノーデン氏が作成したクネビンフレームワークがあります（上図）。 このフレームワークでは問題は5つの領域のいずれかに属するものと考えています。
1つ目の明白な領域とは、正解が存在し変化の少ない領域を指します。 この領域では状況を理解・分類して、過去から蓄積したベストプラクティスに基づいて進めていくのが良いでしょう。 つまり過去の成功例をそのまま当てはめて進めれば良いので、ウォーターフォール型の開発と親和性が高いとも言えます。
2つ目の込み入った領域とは、正解が1つではないものの、比較的予測しやすい領域を指します。 状況を専門家が分析して理解し、取り得る手を検討して進めていきます。 専門家の分析によって問題がわかれば、それを踏まえて過去の経験などの中からうまくやる方法を探して、それをグッドプラクティスとして活用していきます。 つまり最初に分析を行い詳細が明らかになれば、そこに対してウォーターフォールが適用可能になります。
3つ目の複雑な領域とは、問題を把握するために試行錯誤（探索）を行い、それによって状況を把握し、そのあとに次の対応を考えていく領域のことです。 この場合、うまくやる方法は最初からは分からず後からわかることになります。 つまり計画主導型のやり方では対応が難しく、アジャイル開発が向いている領域となります。
4つ目のカオスな領域とは、革新的なことが求められる領域で正しい答えもわからないので、まず行動してから理解していくしかない領域のことです。 この領域では既存の知識が役に立たないこともあります。 つまり計画を事前に十分にたてることはできません。
これから解決しようとしている問題が明白な領域や込み入った領域であれば、従来のウォーターフォール型の開発が効率的でしょう。 一方で複雑な領域とカオスな領域ではアジャイル開発が適しています。 問題にあった開発手法を選択する必要があるのです。
対象プロダクトの特性を踏まえてスクラムがよいのであれば、その合意をステークホルダーから取りましょう。 必要に応じて関係者にはアジャイル開発やスクラムの価値観、従来型との違いを説明して理解してもらう必要があります。 アジャイル開発では、従来のプロジェクトマネジメントとは考え方が大きく異なるので、合意が取れていないと後で従来型とのギャップに苦しむことになります。 また、従来の報告の仕方とは異なる可能性が高いので、どのような報告が必要かを確認し、あわないものは交渉してやめるといった準備も必要です。
よくあるギャップには次のようなものがあります。
スクラムチームは変化に対応してスコープを柔軟に変更しながらプロダクトを作ると考えているが、ステークホルダーは最初に洗い出したスコープをすべて作ると考えている
スクラムチームはフィードバックを選別して意味のあるものだけを取り入れればよいと考えているが、ステークホルダーはすべてのフィードバックを取り入れるべきだと考えている
スクラムチームは開発チームの稼働できる時間（キャパシティ）や期間を固定して、その範囲で全力を尽くすと考えているが、ステークホルダーは人や労働時間を増やしても構わないと考えている
スクラムチームは必ずしもすべてのバグを修正しなければいけないとは考えていないが、ステークホルダーはすべてのバグは重大度に関係なく修正しなければいけないと考えている
スクラムチームはドキュメントは必要な分だけを作ればよいと考えているが、ステークホルダーはウォーターフォールで作るようなドキュメントをすべて作らなければいけないと考えている
これらはどちらかが悪いという話ではありません。 いままでやってきたやり方にも、そのコンテキストでの合理性があって結果が出ていたのですから、一概に否定するものでもありません。 あくまで考え方の違いです。 ただし、ギャップを解消しないままで進めてしまうと、いずれも後になって問題を引き起こすので、開始前に期待値をすり合わせておきましょう。
プロダクトのビジョンが明らかになり、アジャイル開発が向いているということになれば、それにあわせた要求の整理を進めましょう。 このタイミングで大事なのは、まずは全体像を見ることです。 細部に入りすぎるときりがないのでユーザーストーリーマッピング（下図）のようなツールを使って全体の把握に務めます。 見える化することによって共通理解を形成するのが目的です。
多くの場合、初期に洗い出したプロダクトバックログ項目をすべて開発することはありません。 さまざまなことが明らかになっていくにつれて、不要な項目は削除され、新たな項目が追加されていきます。 したがって、初期の段階ですべてが揃っている必要はありません。 ただし、優先順位が高い項目は洗い出しておかないと、そもそも開発自体を始められません。 ユーザーストーリーマッピングなどを使って抽出したプロダクトバックログ項目の候補を着手する順番に並び替えましょう。 このときプロダクトバックログの上位の項目ほど具体的にしておきます。 下位の項目はやらない可能性も高いので詳細化しすぎないようにします。
そうして項目が洗い出せたら、それぞれの項目をラフに見積もっておきましょう。 ストーリーポイントを使っても構いませんし、Tシャツサイズ（S / M / L / XLなど）を使っても構いません。 この時点の見積りはあくまで全体の把握のためなので、あまり時間をかけずに済ませましょう。 並べ終わった上位の項目は、スプリント1に向けて受け入れ基準を用意することになりますが、これについては別途解説します。
