スクラム

スクラムが置いている前提は、要求も市場も途中で変わる、というものです。最初に全工程を固めて一直線に進めるやり方に対して、スクラムは短い区切りごとに動くものを作り、都度確かめて方向を直していきます。この「作って、見て、直す」の反復を回すために、役割・イベント・成果物という三つの要素が用意されています。

役割は三つです。プロダクトオーナーは何を作るかの優先順位に責任を持ち、開発者はどう作るかを担い、スクラムマスターは進め方が健全に回るよう支援します。イベントは、スプリントを軸に、スプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブが並びます。成果物は、プロダクトバックログ・スプリントバックログ・インクリメント（各スプリントで完成した動くもの）です。

プロジェクトマネージャー（PM）がここで注意したいのは、スクラムには従来型の「管理者が全体を指揮する」という中心的な役割がそのままの形では存在しない点です。PMの仕事は消えるわけではなく、優先順位の調整・関係者との合意・リスクの可視化といった要素が、上の三つの役割やイベントに分散して埋め込まれると考えると整理しやすくなります。

スクラムの実務は、一定の長さ（多くは1〜4週間で、期間はチームで固定します）のスプリントを繰り返す形で進みます。順番に見ていきます。

• スプリントプランニング
  スプリントの入り口で、今回何を達成するか（スプリントゴール）と、そのために着手する項目を決めます。プロダクトオーナーが優先順位を示し、開発者が実際に入る量を見積もって選び取ります。
• デイリースクラム
  開発者が毎日短時間で集まり、ゴールに向けた進みと障害を確認し、その日の計画を調整します。報告会ではなく、開発者自身のための同期の場という位置づけです。
• スプリントレビュー
  スプリントの終わりに、完成したインクリメントを関係者に見せ、フィードバックを受けます。プロダクトバックログの見直しにつなげる場でもあります。
• スプリントレトロスペクティブ
  チーム自身の進め方を振り返り、次のスプリントで試す改善を一つか二つ決めます。人ではなくプロセスに目を向けるのが基本です。

これらを支えるのがプロダクトバックログです。作りたいものを優先順位順に並べた一覧で、プロダクトオーナーが手入れ（リファインメント）を続けます。上位の項目ほど細かく、下位は粗いままにしておき、必要になったら詳しくしていきます。この「常に並び替えられる一覧」が、変化への対応力の土台になっています。

スクラムは形をなぞるだけでは機能しにくく、いくつか典型的な崩れ方があります。導入を検討するときは、先に知っておくと避けやすくなります。

• デイリースクラムが進捗報告会になる
  開発者が互いに調整する場のはずが、管理者へ状況を報告する場に変わってしまうことがあります。そうなると自律性が下がり、集まる意味が薄れていきます。
• プロダクトオーナーが優先順位を決めきれない
  関係者の要望を並べただけでバックログの順位が定まらないと、開発者は何から着手すべきか判断できません。決める人と決める基準をはっきりさせる必要があります。
• 「完成の定義」が曖昧なままインクリメントを積む
  どこまでやれば完成かの共通認識（Definition of Done）がないと、後工程に手戻りが積み上がります。テストやレビューを含めて何をもって終わりとするか、先に合わせておきます。
• レトロスペクティブが形だけになる
  振り返って改善案を出しても実行に移されないと、同じ問題が繰り返されます。改善を一つに絞り、次のスプリントで実際に試すところまでつなげます。

共通するのは、イベントの形だけを入れて、その背景にある「検査と適応」の考え方が抜けてしまう構図です。導入初期は、スクラムマスターがこの崩れを見つけて手当てする役割を担います。

比較するときは、軸を「計画の固め方」と「役割の置き方」に絞ると見通しがよくなります。

まずアジャイルとの関係です。アジャイルは価値観や原則を示す考え方の総称で、スクラムはそれを具体的な役割・イベント・成果物に落とし込んだ実装の一つです。アジャイルの下にスクラムやカンバンなどが並ぶ、という入れ子で捉えると混乱しにくくなります。カンバンは、決まった長さの反復を必ずしも置かず、作業の流れと同時進行の量（WIP）の管理に重心があります。反復で区切るスクラムと、流れで管理するカンバンという対比です。

従来型（ウォーターフォール）との違いは、計画の固め方に表れます。ウォーターフォールは要件定義・基本設計・実装・テストと工程を順に進め、前工程を固めてから次へ移ります。スクラムは全体を一度に固めず、優先順位の高いものから作って確かめる点が異なります。どちらが優れているという話ではなく、要求の変わりやすさや、途中で確かめられる環境があるかによって向き不向きが分かれると考えられます。要件が安定し、順序性の強い案件では従来型が噛み合う場面もあります。

プロジェクトマネージャーがスクラムを理解しておく意味は、進め方の選択肢を一つ増やせる点にあります。従来型の計画管理に加えて、変化を前提とした反復型の運び方を知っていると、案件の性質に応じて進め方を選ぶ、あるいは組み合わせる判断ができるようになります。近年はアジャイルでの開発を前提とする現場も増えており、用語や役割を正しく扱えることが実務の前提になりつつあります。

キャリアの観点では、スクラムそのものの資格や経験を積むだけでなく、優先順位の合意形成・関係者との調整・完成の定義づくりといった、フレームワークの背景にある力を言語化できると強みになります。スクラムマスター的な支援型の動きと、従来型の計画・統制の動きは、どちらも進行を担う力として説明でき、職域の幅を示す材料になると考えられます。

スクラムマスターとプロジェクトマネージャーは同じですか。

同じではありません。プロジェクトマネージャーは範囲・進捗・関係者調整に広く責任を持つことが多い一方、スクラムマスターはチームがスクラムを健全に回せるよう支援し、障害を取り除く役割に集中します。指示して管理するより、場を整える立場に近いと考えられます。

スクラムはどんなプロジェクトに向いていますか。

要求が変わりやすく、途中で動くものを見せて確かめられる案件と相性がよいとされます。逆に、要件が安定して工程の順序性が強い案件では、従来型の進め方が噛み合う場合もあります。フレームワークを先に決めるより、対象の性質から選ぶのが現実的です。

スプリントの長さはどう決めればよいですか。

多くは1〜4週間の範囲で、チームがひとつに固定して運用します。短いほど早く軌道修正でき、長いほどまとまった成果を出しやすい傾向があります。フィードバックを得られる間隔と、完成の定義を満たせる作業量の両面から、無理のない長さを選ぶとよいでしょう。