ビジネスモデル仮説を検証し機能を定めた後にすべきこと―スクラムを活用した事業開発

第15回:スクラムボード編

 顧客の課題を中心とするビジネスモデルの仮説をテスト/検証し(前々回)、その課題を解決するためのプロダクトの機能を洗い出したら(前回)、次はプロダクト開発(MVP:最小実用プロダクト含む)のフェーズに入ります。今回は、アジャイル開発方法論であるスクラムのTipsをご紹介していきましょう。

[公開日]

[著] 白井 和康

[タグ] ビジネスモデル 企業戦略 シナリオプランニング

  • ブックマーク
  • このエントリーをはてなブックマークに追加

ソフトウェア開発手法を事業に適用する―スクラムチームを組む

 スクラムとは、プロダクト開発サイクルの長期化、機能要件と実装のミスマッチといった従来のソフトウェア開発に関する課題を解決することを目的とする新しい方法論であり、そのルーツはトヨタのリーンマニュファクチャリングにあります。スクラムは、Webサービスをはじめとするソフトウェア開発に適していますが、物理的なプロダクトや人的サービス開発などにも適用されつつあります。ガントチャートを活用したウォーターフォール型の開発に依存している大企業にとっては、小さくスタートすることが可能な新規事業の実験プロジェクトで試してみるのが良いでしょう。

 スクラムチームの理想的な人数は3~9人であり、プロダクトオーナーとスクラムマスターと呼ばれる2人の個人がこのチームに加わります(図1)。

スクラムチーム図1. スクラムチーム

プロダクトオーナー

 プロダクトオーナーは、プロジェクトの財務上の健全性を含むプロダクト開発全体にわたる責務を負っている人物です。具体的には、プロダクトバックログの管理、開発すべき機能や要件の優先付け、作業の承認や却下などの役割を果たします。

スクラムマスター

 スクラムマスターは、プロジェクト全体をファシリテートする役割をもつ人物です。具体的には、後述の各種スクラムイベントの進行役、プロジェクトの進捗を阻む障害の解決に向けての支援、スクラムプロセス全体のガイドなどの役割を果たします。プロダクトオーナーとスクラムマスターの役割は全く異なる、同一の人物が兼任することはありません。

バックナンバー