プロジェクト計画は紙の上では見栄え良く見えるかもしれませんが、実際にプロジェクトが動き出すとすべて変わる可能性があります。予期しない問題が発生したり、優先順位の変更が生じたり、さらにはチームが対応できるよりも早い速度で顧客ニーズが進化することもあるでしょう。従来のプロジェクト管理では多くの場合、このような中断は障害として扱われ、チームは古い計画に固執するか、土壇場での修正を急ピッチで行うことを強いられます。その結果、納期遅延が生じ、ステークホルダーが不満を募らせ、ビジネス目標に沿っていない最終成果物が生み出されてしまいます。これを防ぐには、品質や生産性を犠牲にすることなく、不確実性を乗り切る方法が組織に求められます。
成功を収めているチームは、変化に対処するだけでなく、変化を活用して優位性を高めています。厳格なワークフローに固執するのではなく、短い集中的なサイクルで運用し、実際のフィードバックに基づいてアプローチを継続的に改善していきます。コラボレーション、透明性、効率性を重視して、すべての取り組みが確実に有意義な進捗へとつながるようにします。このマインドセットは付随的に生まれるものではなく、予測不可能な環境でもチームの成功を促進するように構造化されたフレームワークに組み込まれています。このフレームワークが、スクラムと呼ばれるものです。
スクラムは、1990 年代半ばにプロジェクト管理手法における非効率性への対応として生まれました。この用語自体は、ラグビーに由来しており、ラグビーでの「スクラム」は、選手が連携して形成する構造的な陣形を指します。この比喩は、プロジェクトの複雑さに直面してもチームが継続的に改善できるようにする、協調的で反復的なアプローチという、スクラムの本質を捉えています。
スクラムの基本概念は 1995 年のオブジェクト指向プログラミング、システム、言語、アプリケーション (OOPSLA) に関する会議で、Ken Schwaber 氏と Jeff Sutherland 氏によって正式に紹介されました。二人は、ハーバードビジネスレビュー誌に以前掲載された記事に触発され、特に製品開発においてパフォーマンスの高いチームが、リレー形式の連続的なプロセスに従うのではなく、ラグビーチームのように連携し、一体となって前進していたことに着目しました。
Schwaber 氏と Sutherland 氏は後に、そのアイデアを「スクラムガイド」として正式に体系化しました。以来、スクラムは最も広く使用されているアジャイルフレームワークの 1 つへと進化しました。このアプローチは実質的にあらゆる業界で使用されていますが、特にアプリケーション開発、情報技術 (IT)、マーケティング、製品管理において効果を発揮します。
指針となる原則がなければ、スクラムは一連のルールに過ぎません。そのためスクラムは、チームがどのようにやり取りし、意思決定を行い、業務に取り組むかを形作る中核的価値観を基盤にして構築されています。これらの価値観によって、コラボレーションと説明責任の文化を生み出し、すべてのチームメンバーが共通の考え方で業務を遂行できるようにしています。
コミットメント
スクラムでは、チームメンバーがスプリント目標の達成と質の高い業務の遂行に専念する事が求められます。 このコミットメントにより、結果に対する責任とオーナーシップが促進されます。
勇気
チームは、仮定に疑問を持ち、変化を受け入れ、障害に正面から取り組む勇気を持つことが必要です。また、安心して懸念を表明したり、改善を提案したりすることができる環境も不可欠です。
- 集中
スクラムでは、効率を最大化し、各スプリントがプロジェクトを前進させるように、優先度の高い限られたタスクに取り組むことを重視しています。
- オープン性
スクラムでは透明性が不可欠です。チームメンバーは、進捗状況、課題、インサイトをオープンに共有することで、確実に継続的改善が行われるようにする必要があります。
- 敬意
コラボレーションは、相互の尊重に基づいて育まれます。スクラムチームは、各メンバーの専門知識と貢献を認め合うことで、支援的な職場環境を醸成できます。
柔軟性のない計画と予測的な制御に依存する従来のプロジェクト管理手法とは異なり、スクラムはアジャイルプロジェクト管理のためのアプローチです。このアプローチは、チームがリアルタイムのインサイトを基にして、情報に基づいた意思決定を行える動的な環境を創出するための、3 つのコア原則に基づいて構築されています。以下にこれらの原則を示しています。
透明性により、関係者全員が進行中の作業を明確に把握できるようになります。透明性の主な要素には以下が含まれます。
優先順位を概説する、適切に管理された製品バックログ。
デイリースクラム (「デイリースタンドアップ」とも呼ばれる) やスプリントレビューでの、オープンで率直なコミュニケーション。
完了した作業が必要な基準を満たしていることを保証する「完了の定義」(DoD)。
頻繁な検査により、チームは進捗状況を評価し、潜在的な障害を特定できます。スクラムには、以下を通じた定期的な検査が組み込まれています。
スプリントレビュー：チームが完了した作業を共有し、フィードバックを受けます。
スプリントレトロスペクティブ：チームが上手くいったことと改善が必要なことを分析します。
デイリースクラムミーティング：進捗状況を追跡し、計画を調整します。
スクラムでは、チームがフィードバックと新しいインサイトに基づいてアプローチを調整することが奨励されています。適応は次の状況で発生します。
ビジネスニーズの変化や顧客からのフィードバックにより、優先順位が変化した場合。
チームが、将来のパフォーマンス向上のためにレトロスペクティブでプロセスの改善を図った場合。
事業達成目標との整合性を確保するため、スプリント中に調整が行われた場合。
従来の階層構造とは異なり、スクラムでは自己組織化と集団的責任を重視します。そのため、スクラム手法内のそれぞれの役割が、ステークホルダーへの価値提供において重要な役割を担います。スクラム内の主な機能と、それぞれに関連する責任範囲を以下に示しています。
プロダクトオーナーはビジネス上の利害関係者を代表し、最も価値の高い作業が優先されるようにします。以下のような責任を負います。
製品バックログの管理と優先順位付けを行います。
ステークホルダーとのコミュニケーションを通じて、業務とビジネス目標の整合性を確保します。
各スプリントがユーザーに最大限の価値を提供するようにします。
スクラムマスターは、スクラムプロセスを促進し障害を排除する責任を担う、チームを支えながら導くリーダーです。以下のような責任を負います。
スクラムの原則とベストプラクティスについてチームをコーチングします。
進捗を妨げる障害を取り除きます。
スクラムイベントを促進し、生産的な議論が行われるようにします。
開発チームは、有効な作業単位を担当する専門家 (開発者、テスター、設計者など) で構成されています。主に次の責任を負います。
スプリントタスクの完了方法を自己組織化して決定します。
プロダクトオーナーやステークホルダーと緊密に連携を取ります。
アジャイルワークフローを継続的に調整して改善します。
プロダクトオーナーは、プロダクトバックログ内のタスクと機能のリストを管理し、優先順位を付けます。これは、実行する必要があるすべての作業の中央リポジトリとして機能し、チームには集中すべきタスクの包括的で整理されたリストを提供します。バックログはプロジェクトの進行に応じて進化し、優先順位の変更に基づいてアイテムが新規追加、調整、削除されます。適切なバックログ管理が行われなければ、チームは次にすべきことについての明確な方向性を見失う可能性があります。
スプリント計画立案は各スプリントの開始点を示し、反復サイクル時のチームの作業の基盤を整えます。チームは、今後のスプリントで完了するバックログアイテムを選択し、そのスプリントの目標を定義します。スプリント計画立案には、スクラムチーム全体が関与します。スクラムチームは、指定された時間制限内に達成できることと、達成する必要があることをチーム全体として決定します。
スプリント
スプリントは、チームが選定したタスクに取り組む時間枠 (通常は 2～4 週間) を指します。これはスクラムにおける主要な作業単位であり、段階的に価値を提供することに集中するための構造化された期間を示します。各スプリントは予測可能なサイクルに従っているため、チームは必要に応じて柔軟性を維持しながら効果的に計画を立てることができます。スプリントが適切に実行されると、プロダクトインクリメント (出荷可能な状態の製品) が生み出されます。
デイリースクラムは、稼働日に毎日開催される簡単なミーティングで、チームメンバーがその日の進捗状況、課題、計画について話し合うための場です。この会議は 15 分までに制限され、構造化された形式で行われます。この形式では、通常チームメンバーは、次の 3 つの重要な質問に対する答えを報告します。
- 昨日何を行ったか
- 今日は何をするか
- 進行の障害となるものがあるか
定期的なスタンドアップミーティングは、チームが問題点を共有し、小さな課題が大きな障害に発展するのを防ぐために、毎日継続的に行われる進捗確認の場です。
スプリントレビューは、建設的なフィードバックを得ることを目的として、完成した作業を発表する場です。このイベントは、スクラムチームが製品を紹介し、さまざまなステークホルダーから貴重な情報を収集する機会を提供します。スプリントレビューでは、チームは主要な機能、変更、改善点を取り上げながら、完了した作業を順を追って説明します。顧客やビジネスリーダーを含むステークホルダーは、各自のニーズに基づいて質問したり、インサイトを提供したり、改善を提案したりできます。このイベントで収集されたフィードバックを活用して、次の反復を形作っていきます。
スプリントのレトロスペクティブ
製品に焦点を当てたスプリントレビューとは異なり、スプリントのレトロスペクティブでは、チームのプロセス、コラボレーション、全体的な効率性を評価することに注力します。上手くいった点、改善できる点、今後のスプリントを強化するために実行できる具体的なステップを特定することを目標としています。
バックログは、機能、タスク、要件の動的な優先順位付けのリストで、プロダクトオーナーが管理します。このバックログは、チームの優先事項の信頼できる唯一の情報源として機能する、すべてのスクラム作業の基盤となります。プロダクトバックログアイテム (PBI) と呼ばれるバックログ内の項目は、新機能やバグ修正から技術的な改善や調査タスクまで、多岐にわたります。プロダクトオーナーは、バックログを継続的に改善し、アイテムが明確に定義され、価値に基づいて順序付けられていることを確実にする責任を負います。
スプリント内で完了するように選択され、プロダクトバックログのサブセットとなっているスプリントバックログは、チームが提供することをコミットした作業を表すものです。スプリントの目標を達成するために必要な特定のタスクが含まれています。長期的な項目を含む可能性のある広範なプロダクトバックログとは異なり、スプリントバックログでは焦点を絞り込み、時間に制約を設けます。スプリント全体を通して、新しい情報の出現に伴ってバックログは進化する可能性がありますが、最重要とする目標は変わりません。
最後に、インクリメントは、スプリントから得られる使用可能な製品としての成果物です。インクリメントは、完了したタスクの集合を指しますが、それだけではありません。これは、DoD を満たす機能的で出荷可能な製品の状態でもあります。各インクリメントは以前の反復に基づいて構築され、製品を徐々に強化し、常に作業を進展させます。
それぞれの手法は、独自のニーズや業界によって形成された独自の歴史を持ち、発展を遂げてきました。
スクラムは、1990 年代にラグビーのチームベースの連携に着想を得て生まれました。Ken Schwaber 氏と Jeff Sutherland 氏によって取り入れられたものです。
アジャイルは、2001 年にアジャイルマニフェストとして発表されました。これはフレームワークというよりは、指針です。スクラム、カンバン、エクストリームプログラミング (XP) など、複数の方法論を包含しています。
カンバンは、1940 年代にトヨタ生産方式で開発され、当初はリーン生産方式のツールであったものが、後にソフトウェア開発にも取り入れられました。
この 3 つはいずれも効率性と適応性を重視していますが、その指針となる原則は異なります。
スクラムは、厳格な役割定義と継続的な検査と適応により、時間制限のある短い反復サイクルで作業を完了させていくことに重点を置いています。
アジャイルは、柔軟性、コラボレーション、反復的なデリバリを支持しますが、特定の構造を規定するものではありません。アジャイルの原則は、アジャイルフレームワーク (スクラムなど) によってさまざまな方法で実装されます。
カンバンでは、継続的デリバリとワークフローの最適化が重視され、固定長のサイクルで作業するのではなく、対応中の作業 (WIP) を制限することでボトルネックを軽減します。
各アプローチには、タスクをどのように管理し完了するかを定義する固有の作業方法があります。
スクラムでは、時間枠を定めたスプリント、事前定義された役割、構造化されたイベントを使用します。
アジャイルは、厳格なルールを持たない柔軟なアプローチです。チームはプロジェクトのニーズに基づいて手法を適応させることができます。
カンバンでは、視覚的なボードを使用して進行中の作業を追跡し、WIP の制限を通じてフローを管理して、サイクルを固定することなくタスクを流動的に進めることができます。
スクラムは 3 つのフレームワークの中で特定の役割を定義する唯一のフレームワークですが、アジャイルとカンバンではより流動的にそれに対応します。
- スクラムでは、優先順位、プロセス、実行を管理するために、プロダクトオーナー、スクラムマスター、開発チームの 3 つの主要な役割が必要です。
- アジャイルは、特定の役割を義務付けるのではなく、プロジェクトのニーズに合ったコラボレーションと自己組織化チームを奨励します。
- カンバンには正式な役割はありません。チームは自ら組織化しますが、進捗状況を監督するためのサービスデリバリマネージャーやフローマネージャーを指名する場合もあります。
各手法では、固有のパフォーマンスインジケーターを使用して、進捗状況を異なる方法で測定します。
- スクラムでは、ベロシティ (スプリントごとに完了した作業)、バーンダウンチャート (時間の経過に伴う残りの作業)、スプリント目標を使用して、進捗状況を追跡します。
- アジャイルでは、決まった測定基準ではなく、顧客満足度、適応性、サイクルタイムに重点を置き、必要に応じて測定を適応させます。
- カンバンの場合は、リードタイム (要求から完了までの時間)、サイクルタイム (タスクに費やされた時間)、WIP の制限に基づいて、ワークフローを最適化していきます。
前述のように、スクラムは柔軟性と反復的な進捗を優先します。これにより、チームが目標に集中できるようにすると同時に、変化するニーズに合わせて迅速かつ簡単に調整できるようにする、構造化されたアプローチが構築されます。このバランスが、プロジェクト管理を最適化し、次のようなメリットをもたらします。
スクラムには多くのメリットがありますが、常に順調に進むとは限りません。スクラムを効果的に実装するには、強力なチームコラボレーションとコミットメントに裏打ちされたマインドセットの転換が必要です。スクラムに慣れていないチームは、その早いペースと自己組織化の期待に適応するのに苦労する可能性があります。スクラムベースのアプローチを完全に導入する前に、以下に挙げる潜在的な障害を考慮してください。
スクラムは、集中したコラボレーション作業を促進します。しかし実際には、多くのチームメンバーが同時に複数のプロジェクトに割り当てられています。注力するものが分散されている状態では、効率が低下し、スクラムプロセスに完全に関与することが困難になります。個人が複数の業務に対応していると、日々のスクラムに参加したり、スプリントに十分に貢献したり、明確な優先順位を維持したりするのに苦労する可能性があります。この課題を軽減するために、組織はコンテキストの切り替えを最小限に抑え、チームメンバーを可能な限り 1 つのスクラムチームにアサインするように努める必要があります。マルチタスクが避けられない場合は、個々のメンバーに過度な負担をかけるリスクを生じさせることなく生産性を維持するために、明確な作業負荷管理と優先順位付けの戦略が不可欠です。
スクラムスプリントは、一定の期間内に作業を完了させなければならない仕組みになっています。スプリント内で達成できる量をチームが正確に見積もることが難しい場合があり、サイクル終了時に未完了のタスクや急ぎの作業が発生する可能性があります。この問題が生じる場合は、チームは過去のデータやベロシティの追跡を使用して見積もりの手法を改良し、スプリント計画立案を改善できるようにしてください。
スクラムの反復的な性質は、その最大のメリットの一つです。とはいえ、反復性は、問題が迅速に特定されて解決されることが前提とされています。チームがその能力を欠いていると、障害が積み重なり、進捗が遅延したり脱線したりする可能性があります。強力なスクラムマスターは、問題解決の促進において中心的な役割を担いますが、チームメンバーも懸念を表明し、解決策を見つけるために協力することに積極的である必要があります。継続的な学習とナレッジ共有の文化を奨励することで、チームは問題解決の取り組みにおいてよりアジャイルになることができます。
スクラムは、作業の集団的オーナーシップを育むように設計されていますが、多くの組織における業績評価は、依然として個人の成果に基づいています。この乖離は、メンバーがチームの成果よりも個人の成功に注力する可能性を生じさせ、チーム内に緊張を生む恐れがあります。スクラムを導入する組織は、チームの貢献、責任の共有、コラボレーションの成功を重視するように、評価方法を変更することを検討する必要があります。
上記に挙げた課題は困難に思えるかもしれませんが、スクラム実装の成功を妨げるものではありません。次のベストプラクティスは、最も気乗りしないチームでも成功を収めるのに役立つものです。
スクラムはチームワークで成功しますが、真のコラボレーションは、単に他の人と一緒に仕事をすることだけにとどまりません。ピアツーピアのコラボレーションを促進するとは、チームメンバーが積極的かつ簡単に知識を共有し、互いにサポートし合い、問題を共同で解決できる環境を育むことを意味します。これは、ペアプログラミングや部門横断型トレーニングを通じて実現できます。さらに、デイリースクラムとスプリントのレトロスペクティブにおけるオープンな議論によって促進されます。
スクラムは、固定長スプリントに依存することで、安定した予測可能な作業ペースを維持します。当然ながら、このような時間枠が過度に厳格なものに感じられ、スプリントの期限を延長して、余裕を持たせたいと考えることもあるでしょう。しかし、柔軟性はスクラムの大きなメリットである一方、スプリントの期間を常に調整すると、一貫性がなくなり、進捗のトラッキングが妨げられる可能性があります。迅速な対応と持続可能な開発のバランスを取るためには、チームは推奨される期間 (通常 2 週間) に従う必要があります。短いスプリントでは、有意義な作業を完了するのに十分な時間が確保できない可能性がありますが、スプリントが長くなると、切迫感が低下し、フィードバックが遅れる可能性が生じます
適切に構造化されたスクラムボードは、チームのワークフローを可視化することで、メンバーが進捗状況を追跡して障害を特定し、確立された目標に向けて取り組むのに役立ちます。物理的なものかデジタルなものかにかかわらず、スクラムボードは製品バックログ、スプリントバックログ、現在の作業ステータスを明確に表示する必要があります。仮想スクラムボードは、リモートでのコラボレーションと自動トラッキングを可能にすることで、柔軟性を高めます。
スクラムイベントには、全員を集めてプロジェクトについて話し合う機会がいくつかありますが、ミーティングを開くこと自体が目的となってはなりません。各ミーティングは、スプリントの成功に直接貢献する明確な目的を果たす必要があります。チームは、簡潔で実行可能、かつ目標に沿った内容の議論に維持するよう注力する必要があります。ミーティングがスプリント目標に向けた有意義な進展をもたらさない場合は、再構築が必要となる可能性があります。
ServiceNow は、ServiceNow AI Platform を通じて包括的なアプリケーションスイートとソリューションを提供し、チームがワークフローの計画、追跡、自動化のためにスクラムを効果的に実装できるようにします。ServiceNow 戦略的ポートフォリオ管理 (SPM) は、アジャイルのイニシアチブをビジネス目標に合わせるために必要なすべてのものを提供します。リアルタイムデータ、自動化、AI を活用した高度なインサイトを活用することで、SPM は業務の優先順位付け、依存関係の管理、継続的な価値提供の推進を支援します。
ServiceNow Agile Development のスクラムプログラムでは、共通の成果に向けて取り組む複数チームのコラボレーションをさらに簡素化できます。スクラムプログラム計画ボードは、組織が作業の割り当て、進捗状況の追跡、部門間の依存関係の管理を行える一元化されたインターフェイスを提供し、これにより複雑なアジャイル環境でもシームレスな連携が確保されます。チームは、バックログの優先順位付けと作業負荷の配分を完全に可視化しながら、同期された、または多様なスプリントのペースで運用できます。
ServiceNow の戦略的ポートフォリオ管理 (SPM) が目標設定のアプローチをどのように改善できるか、ぜひご確認ください。今すぐデモをご覧いただけます。