---

スクラムフレームワークとは？きっと驚かれるはずです！

スクラムとは何でしょうか。複雑にしすぎずに言えば、次のように定義できます。

ソフトウェアを含む、価値あるプロダクトを開発・提供するための、軽量で反復的なフレームワークです。

ソフトウェア開発で広く使われますが、他の業界でも使われています。

IT業界では、2000年代初頭にアジャイル開発とともに生まれた言葉だと思われがちですが、それは誤りです！

スクラムという比喩は、1986年の一月に、Harvard Business Reviewのプロダクト開発に関する論文に登場しました。著者の竹内弘高と野中郁次郎が用いたのは、次の論文です。 「The New New Product Development Game」。 そうです、Newが二つあります。「The New New Product Development Game」を読んで、始まりを確かめてみてください！

あらゆるソフトウェア開発に使えます。社内外の顧客向けのプロダクトやサービスとして、パッケージ全体や、大きなシステムの一部を開発・提供できます。

軽量な進め方で、生産性を高め、無駄と重複する活動を減らすことに集中します。

一般的な指針と、少数のルール、役割、作成物、イベントを定めます。ただし、これらの構成要素（スクラムフレームワークの主な構成要素）は、固有の目的を持つ、成功のために欠かせない重要なものです。

主な構成要素は、次のとおりです。

• チーム内の三つの責任： プロダクトオーナー、スクラムマスター、開発者。
• 五つのスクラムイベント： スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ。 スクラムのグルーミング（バックログの詳細化） は、各イベントを支える継続的な活動であり、第六の正式なイベントではありません。
• プロダクトバックログ（スクラムバックログ／スクラムプロダクトバックログ）： 既知の要件をすべて管理し、優先順位を付ける作成物です。
• スプリント： 提供可能なソフトウェアやサービスのインクリメントを開発する、活動のサイクルです。
• スプリントバックログ： ゴール、選んだアイテム、それらを届ける開発者の計画を含む作成物です。
• インクリメント： 完成の定義を満たす、利用可能なプロダクトの改善です。

自己組織化と、条件を付けず協力することが重要な要素です。 従来の意味でのプロジェクトマネージャーは不要です。その責任を、オーナー、マスター、開発者へ分担します。

開発者は、計画と実行の進め方の主体であり、他の二つの役割が自己管理を支えます。例えば、オーナーと話してアイテムを選び、使えるインクリメントの提供を計画します。

もう一つの中心は、「検査と適応」による継続的改善です。 作成物と実践を継続的に監視・検査・評価して、適応と最適化を行います。品質、効率、顧客満足を最大化し、無駄と全体のリスクを最小限にします。

特に開始時には、要件がすべてわからず、変わりやすいという現実を受け入れます。

まだ気づいていない未知は、どのプロジェクトにもあります。少ない場合も多い場合もあります。 実行しながらでなければ発見・対処できない、その未知を受け入れる助けになります。

実装前に仕事を詳細化し、早く選びそうな高優先度のものほど細かくします。詳細化やプランニングを通じて行います。変化を受け入れ、最適化を続け、誤りから学ぶことが、開発全体の一部になります。

透明性と直接的な意思疎通も、重要な礎です。 オーナーはチームと緊密に協力して要件を特定・優先します。ストーリーで書き、バックログに記録できます。改善に必要な既知の仕事を捉え、学びに応じて変化します。

チームは、通常二〜四週間、必ず一か月以下のスプリントで届けられると考えるストーリーを、自ら選べます。目標を自分たちで約束し、意見を聞いてもらえることで参加意識が高まります。自然な流れと計画への参加が、意欲と成果を高めます。

マスターは、チームのために、チームと共に奉仕するリーダーとして働く、重要な役割です。

マスターは、円滑に働くための訓練を受けた進行役です。中断や架空の優先事項から守る交渉役にも、行き詰まる前に既知・予想される障害を除く伝達役にもなります。責任のほんの一部です。各役割の仕事は、後ほど詳しく扱います。

基本の形では、独立性が高い一つのチームによる、新規開発や既存システムの開発に最も適しています。

ただし、実践者の工夫はそこにとどまりません。「チーフスクラムプロダクトオーナー」や「拡張スクラム」などの組織上の追加で、複数チームや地理的に分散した構成にも使えます。これも後で学びます。

引き続き、学びを楽しんでください！