はじめに

スクラム開発における「プロダクト」と「プロジェクト」の違いに関して、初めて学ぶ際に取っていたノートがあります。それをもとに、関連する用語と共にこの資料をまとめました。

注意: 本資料に記載されている情報は二次情報となります。したがって、全ての表現や定義が一般的に広く受け入れられているものとは限りません。資料の内容は参考程度に留め、必要に応じて原資料や第一次情報を確認することをお勧めします。

プロダクトとプロジェクト

プロダクト (Product):

日本語で「製品」「商品」「制作物」と解釈されることが多い。
製品の企画、製造、マーケティング、販売などの一連の流れを指す。
特定の顧客の要求やニーズを満たすために作られる成果物やサービス。特にソフトウェア開発の文脈では、アプリケーション、ウェブサイト、モバイルアプリなどの製品自体を指すことが一般的である。

プロジェクト (Project):

ある一定の目的をもって行われる計画や業務。
期限内での製品開発や納期までの業務を指す。
一定の開始と終了が定められ、特定の目的を達成するために行われる活動やタスクの集合。プロジェクトは特定の成果物やサービスを生み出すための一時的な取り組みとして捉えられる。

プロダクトマネジメント vs プロジェクトマネジメント

プロダクトマネジメント

特徴

製品のライフサイクル全体を管理する。
ユーザーのニーズや市場の動向に基づいて製品の方向性を決定する。

利点

柔軟性: 市場の変化やユーザーのフィードバックに応じて製品の方向性を迅速に変えることができる。
継続的な改善: 継続的なフィードバックの収集と分析により、製品を常に最適化していくことができる。
戦略的な視点: 長期的なビジョンと戦略を持ち、製品のポジショニングや市場での競争力を強化する。

欠点

複雑性: 多岐にわたるステークホルダーの要望や市場の変化を考慮するため、製品の方向性を決定するのが難しい場合がある。
リソースの競合: 複数の機能や改善点の中から優先すべきものを選定する際に、リソースの制約が生じることがある。

プロジェクトマネジメント

特徴

定められた目標や予算、期限内でのタスクの達成を目指す。
プロジェクトのスタートから完了までの流れを管理する。

利点

明確な目標: 期限や予算、目標が明確に設定されるため、チームの方向性がはっきりする。
計画性: タスクの進行状況やリソースの使用状況を明確に把握し、予測しやすい。
リスク管理: プロジェクトの初期段階でリスクを特定し、それに対する対策を計画的に進めることができる。

欠点

柔軟性の欠如: 一度プロジェクトが始まると、変更が難しい場合がある。
完了主義: プロジェクトが完了した後、継続的な改善やサポートが十分に行われないことがある。

スクラム開発を掛け合わせることで生まれるメリット

迅速なフィードバックループの確立
スクラム開発の短期的なスプリントを採用することで、プロダクトマネージャーは市場やエンドユーザーからのフィードバックを迅速に受け取り、製品の方向性を適切に調整できます。
プロジェクトの進捗の可視性
スクラムのデイリースクラムやスプリントレビューを通じて、プロジェクトマネージャーはプロジェクトの進捗状況を定期的に確認し、必要な調整を行うことができます。
柔軟な変更の取り込み
スクラムは変更を歓迎する方法論です。そのため、プロダクトやプロジェクトの要件が変わった場合でも、迅速にそれを取り込むことができます。
リスクの早期発見と対応
スクラムの反復的なアプローチにより、プロジェクトの初期段階でのリスクの発見と対応が可能となり、大きな問題になる前に解消することができます。
強化されたチームのコラボレーション
スクラムのセレモニーやアーティファクトを使用することで、プロダクトオーナー、開発チーム、ステークホルダーとのコミュニケーションが強化され、共通の目標に向かって協力する文化が醸成されます。
明確なプロダクトの優先順位
プロダクトバックログを通じて、プロダクトの要件や機能の優先順位を明確にすることができ、リソースを効果的に配分することができます。
継続的な改善
スプリントレトロスペクティブを実施することで、チームは過去のスプリントの成果を評価し、次のスプリントでの改善点を議論することができます。

用語説明

スクラムマスター (Scrum Master)
- スクラムチームの進行役で、障害を取り除く役割を持ちます。チームがスクラムの原則・実践・規則に従って作業を進められるようサポートします。
スプリント (Sprint)
- スクラム開発での1サイクルのこと。通常、2週間から4週間の期間で、その間に完成させるべき機能やタスクが定義されます。
バックログ (Backlog)
- 製品の要件や機能、改善点などの一覧。これを基にスプリントのタスクが選定されます。
バーンダウンチャート (Burndown Chart)
- スプリントの進行状況をグラフで表したもの。タスクの残量と経過時間をプロットして、プロジェクトの進捗を視覚的に捉えるためのツールです。
ステークホルダー (Stakeholder)
- プロジェクトや製品に関心や影響を持つ人々。顧客、開発チーム、経営層、利害関係者などが含まれます。
ユーザーストーリー (User Story)
- 製品の要件や機能を、エンドユーザーの視点から記述したもの。具体的なユーザーがどのような目的やニーズで機能を使用するかを示す形式で記載します。
プロダクトオーナー (Product Owner)
- スクラムチームにおける役割の一つで、製品のバックログの内容や優先順位を管理し、ステークホルダーとのコミュニケーションを担当します。
ベロシティ (Velocity)
- スクラムチームが過去のスプリントでどれだけの仕事量を終えたかを示す指標。通常、ユーザーストーリーのポイントやタスクの単位で測定されます。ベロシティをもとに、次回のスプリントでどれくらいの仕事量を終わらせることができるかを予測するために使用されます。

スクラム開発を導入するのが適していないケースやシチュエーション

高度に予測可能で変更が少ないプロジェクト：
もしプロジェクトの要求が非常に安定しており、変更の可能性がほとんどない場合、スクラムのような反復的・増分的なアプローチは過度であるかもしれません。
組織文化のミスマッチ：
組織がトップダウンの意思決定文化を強く持っている場合や、失敗を許容しない文化がある場合、スクラムの導入は抵抗を感じる可能性が高いです。
完全なコントロールが求められる場合：
特定の規制や標準に従わなければならないプロジェクト（例：航空宇宙、医療機器）で、全てのプロセスや成果物についての完全なコントロールと文書化が求められる場合、スクラムの柔軟性はハンディキャップになることがあります。
チームのコミットメントが難しい場合：
チームメンバーが複数のプロジェクトに関与している場合や、頻繁に変わる場合、スクラムの定期的なコミットメントが難しくなる可能性があります。
リモートワークの制約：
すべてのチームメンバーがリモートで作業する場合、特にタイムゾーンの違いが大きい場合、デイリースクラムやスプリントレビューなどのイベントの調整が難しくなることがあります。
教育やトレーニングの不足：
スクラムの価値や原則を理解していないチームや組織では、スクラムを正しく実践するのは難しいです。
ショートタームなプロジェクト：
非常に短期間で完了するプロジェクトでは、スクラムの導入やセットアップのコストが恩恵に見合わないことがあります。

これまでに目を通した上で価値と原則を読む

スクラムの5つの価値：

コミットメント (Commitment)
チームは、スプリントの目的やスプリントバックログのタスクに対して約束をします。
勇気 (Courage)
チームは問題を正面から取り組む勇気を持ち、変更や適応を恐れずに前に進むことが求められます。
集中 (Focus)
スプリントの間、チームは選択されたタスクに集中し、その達成を目指します。
開放性 (Openness)
チームは進行中の作業や挑戦について透明性を持ち、ステークホルダーや他のチームメンバーと情報を共有します。
尊重 (Respect)
チームメンバーは互いの意見や能力を尊重し、コラボレーションを奨励します。

スクラムの原則：

反復的・増分的なアプローチ
ソフトウェアは反復的に、小さな部分（インクリメント）で開発され、各スプリントの終わりに利用可能な製品を提供することを目指します。
変更の受容
市場やステークホルダーのニーズに応じて、要件の変更を迅速に取り入れることができるようにします。
日常的なコミュニケーション
チームメンバー、プロダクトオーナー、スクラムマスターは日常的にコミュニケーションを取り合い、課題や進捗を共有します。
自己組織化されたチーム
チームは自らの仕事を組織し、どのタスクをどのように進めるかを自分たちで決定します。
製品の価値の最大化
プロダクトオーナーはバックログを管理し、最も価値のある機能やタスクを優先的に開発するようにします。
インスペクト＆アダプト
チームは定期的に自らの作業を振り返り（レトロスペクティブ）、改善のためのアクションを決定し、そのアクションを実施することで、継続的に改善を図ります。

このように、スクラムはチームの協働、反復的なアプローチ、継続的な改善を重視するフレームワークです。