Asana が StackAI を買収 — すべてのヒューマンエージェントのワークフローを 1 か所で実行できるようになりました。詳しく見る
この電子書籍では、組織はどのようにアジャイルを導入すれば機敏性の高い効果的な職場を作れるのかなど、アジャイルについて深く掘り下げています。
スクラム開発 (Scrum) とはアジャイル手法のひとつです。少人数のチームに分かれ、短期間の開発サイクルをくり返し行うフレームワークです。チームのコラボレーション向上を促し、インパクトの大きな仕事の達成をサポートします。
スクラム開発のメリットは、価値観、役割、ガイドラインの設計図を明確化することにあります。これにより、チームが反復と継続的な改善に集中できるようになります。
現在の形の「スクラム開発」は、竹内弘高氏と野中郁次郎氏によって書かれた 1986 年のハーバード・ビジネス・レビューの記事 The New New Product Development Game で初めて紹介されました。竹内氏と野中氏はラグビーから「スクラム」と名付けました。「ラグビーのように、ボールがチーム内で受け渡され、チームがユニットとしてフィールドを進んでいく」ことを表しています。
1995 年に、スクラムは Ken Schwaber 氏と Jeff Sutherland 氏によって発表されたアジャイルマニフェストと SCRUM Development Process によってさらに発展しました。この時点で成文化され、現在の形が確立されています。
Schwaber 氏と Sutherland 氏のスクラムは、ウォーターフォールモデルとは対照的なアプローチです。ウォーターフォールモデルではプロジェクトを一連のフェーズに分割し、各フェーズの成果物が完成すると次のフェーズに進みます。より柔軟で反復的なアプローチを取ることで、顧客にとって最高の製品を開発できると考えました。
その後、Schwaber 氏と Sutherland 氏は定期的に更新を続けるスクラムガイドを発表しました。スクラムガイドはチームに「自分たちの仕事のテクニックがどれほど効果的であるかを確認させ、継続的に進化・改善させようとする」ものです。
この電子書籍では、ワークマネジメントとは何かを解説し、ビジネスにどう役立つかをご紹介します。
スクラム開発は「スプリント」という通常 2 週間程度の作業セッションで行われます。各スプリントの終わりまでに特定の成果物を作成します。スクラムにはさらに「デイリースタンドアップ」と「スプリントの振り返り」という 2 つの重要なイベントがあります。
スクラム開発を始める前に、「完了」とはどういう意味かについてチームで共通認識を持つことが、円滑な進行の鍵です。スプリントの初めには情報が少なくても、途中で得た情報に基づいてプロセスと要件を調整できます。
スクラム開発プロセスは、以下の 6 つのステップで進行します。
スクラムスプリントを始めるには、まずチームリーダー (スクラムマスター) が、バックログから取り組む仕事を決定します。製品バックログは一か所で文書化し、プロジェクト管理ツールで管理するのがおすすめです。
仕事を最大限効率化し、チームの生産性を上げるためには、Asana のプロジェクトマネジメント機能をお試しください。日々の業務と目標をつなげ、「誰が・何を・いつまでに行うのか」を可視化します。
スクラムスプリントを始める前に、そのスプリントでバックログのどの仕事に注力するのかを決定します。これをスプリント計画 (スプリントプランニング) と呼びます。テンプレートを活用すると効率的に進められます。
通常、1 つのスプリントは 2 週間続きます。チームの状況に合わせて、より短くても、長くてもかまいません。スプリント期間中、チームはスプリント計画セッションでまとめたバックログの内容に取り組みます。
毎日スクラムチームと 15 分間話し合います。デイリースタンドアップミーティングは、進捗状況を共有し、予想外の障害があれば優先度を調整する機会です。デイリースタンドアップ用の無料テンプレートを活用すると効果的です。
スクラムスプリントが終わったら、チームで集まってスプリントレビューを行います。スクラムチームのメンバーが「完了」した仕事を報告し、関係者の承認やチェックを受けます。
スプリントが終わったら、その感想を共有し、次回以降の改善点について話し合います。この振り返りはレトロスペクティブと呼ばれます。スクラム開発では継続的な改善に重きが置かれているため、新しいプロセスを試し、効果が少ない戦略は修正しましょう。スプリント振り返りはテンプレートを活用して効率化できます。
スクラムでは主に 3 つの役割があります。
プロダクトバックログの責任者です。ユーザーの要望を把握し、ユーザーの体験談をチームや経営陣の関係者に伝えることに重点を置きます。次に何を納品すべきかを明確にし、納品物が出荷できる状態かどうかを最終判断します。
スクラムマスターはさまざまなスクラムイベントを実行します。スクラムのプロジェクトマネージャー兼進行役として機能します。デイリースタンドアップミーティングを進行し、スプリント計画・スプリントレビュー・振り返りミーティングを開催します。
スクラムチームはスプリントに取り組むすべての人々を指します。チームメンバーは継続的な改善という目標を達成すべく、自己組織化し、協力的に動く必要があります。
Asana の製品マーケティング部門長が Asana を使ってどう製品リリースプロセスを管理しているのか、その秘訣をご紹介します。
スクラム (Scrum) においては、3 つのアーティファクトが存在します。アーティファクトとは課題解決のための道具のようなものです。
プロダクトバックログ
スプリントバックログ
製品インクリメント
それぞれについて詳しく見ていきましょう。
プロダクトバックログは、やるべき仕事のマスターリストです。プロジェクトマネージャーやプロダクトオーナーによって優先順位がつけられます。バックログに入っているからといって、すぐにチームの仕事になるわけではありません。
プロダクトバックログの内容は、スクラムスプリント中にチームが取り組める仕事の選択肢です。プロジェクトオーナーは顧客や市場、チームからの情報を基に、バックログの順位を頻繁に見直す必要があります。
スプリントバックログは、スクラムスプリント中にチームが取り組む仕事のリストです。スプリント計画セッションで選ばれた項目が含まれます。スプリント計画プロジェクトがある場合はそこに移されます。
1 回のスプリント中にバックログの内容すべてを完了できないこともあります。スプリント中に新しい項目を追加することは避けましょう。頻繁に追加が発生する場合は、スプリント計画フェーズにより時間をかけることをおすすめします。
製品インクリメントとは、スプリントの終わりに納品するものです。新製品・機能・改善・バグ修正など、チームによって内容は異なります。インクリメントはスプリントレビュー中に提示し、関係者が「完了」かどうかを判断します。
ワークマネジメントツールを活用することで、会議中に議事録をリアルタイムで記録できます。アクションアイテムをその場で作成し、担当者に割り振ることも可能です。
スクラム開発には、その適用と有効活用に役立つ 6 つのスクラムの原則があります。
スクラムでは透明性、検査力、適応力が重視されます。
透明性: チーム内で進捗や課題、リスクなどの情報が可視化されている
検査力: 作成物および進捗は適切に検査されている
適応力: 必要な場合は、柔軟かつ迅速に軌道修正を行う
この 3 つは「スクラムの 3 本柱」と呼ばれます。後述する「スクラムの価値基準」と併せて、スクラム開発手法を特徴づける要素です。
スクラム開発には役割やルールがありますが、すべてのメンバーにタスクや仕事の責任が課されます。責任を共有することで、チームはよりクリエイティブでダイナミックになります。
スクラムスプリント中や終了後に協力し合うことで、最大限の成果が得られます。
スクラムスプリントのゴールは、最高のビジネス価値を提供することです。プロセスの最初から作業に優先順位を付けることが重要です。
スクラムプロセスにはスプリント、デイリースタンドアップ、振り返りなど、時間ベースのアクティビティが多数あります。継続的な改善を実現するために、仕事の時間を明確に区切ることが鍵です。
スクラムでは、最初の製品が完璧である必要はありません。反復的な開発を繰り返すことで、顧客のニーズに対応し、価値観に基づく優先順位に従って製品を改善していけます。
スクラムを成功させるには、スクラムガイドで定義されている 5 つの価値基準に従う必要があります。
スクラムチームは 1 つのユニットです。チームメンバーはお互いを信頼し、スプリントに全力を注ぎます (コミットし)、継続的な改善に専念します。
スクラム開発中、正確な答えのない難題に遭遇することもあります。チームは難しい質問を率直に投げかける勇気と、正直に答える勇気を持つ必要があります。
どのスプリントでも、チームは製品バックログから作業します。スプリントの終わりまでに成果物を完成させるために、選んだ作業に集中することが大切です。
スクラム中、予期せぬ事態も起こります。メンバーは新しい意見や機会を受け入れ、製品やプロセスの改善に活かす姿勢が求められます。
コラボレーションはスクラム開発の重要な要素です。チームのコラボレーションを促進するには、他のメンバー、スクラムマスター、そしてスクラムプロセスを尊重する姿勢が不可欠です。
スクラム、かんばん、アジャイルという手法は、リーン方式のフレームワークという枠組みの中ですべて密接に関連しています。それぞれの特徴や考え方の違いを見てみましょう。
アジャイルは、継続的な改善を行うのに役立つプロジェクト管理の考え方 (方法論) です。アジャイルチームでは変化への対応と不確実性への対処を重視し、反復的・段階的な開発が行われます。スクラムとかんばんは、どちらもアジャイル方法論のひとつです。
スクラムを使っているのなら、それはアジャイルチームだと言えます。ただし、アジャイルはより広い概念で、方針やフレームワーク全体を指します。スクラムはスプリントやスタンドアップ、振り返りなどの具体的な手段を通じて、アジャイルを実践する方法論です。
かんばんフレームワークもアジャイルのひとつです。かんばんは、継続的なプロセスや仕事を管理する視覚的な手段として機能します。かんばんツールを使えば、仕事が完了するまでの動きを視覚化できます。
多くの場合、スクラムを使用するチームはかんばんボードで仕事を視覚化しますが、それがスクラムフレームワークの必須条件というわけではありません。
スクラム開発をウォーターフォール型開発と比べることで、それぞれの特性がより明確になります。ウォーターフォール型開発では、要件定義・設計・実装・テスト・リリースという工程を順番に進めます。スクラム開発はスプリントと呼ぶ短いサイクルを繰り返し、各サイクルの終わりに動作する成果物を届けます。
主な違いを以下の観点で整理します。
柔軟性: ウォーターフォール型は工程が固定されており、後工程での要件変更が困難です。スクラム開発はスプリントごとに優先順位を見直せるため、変化する要件に対応しやすい設計になっています。
成果物の頻度: ウォーターフォール型はプロジェクト最終段階で成果物を届けます。スクラム開発は各スプリントの終わりに製品インクリメントをリリースするため、早期からフィードバックを得られます。
リスク管理: ウォーターフォール型は終盤まで問題が表面化しにくいリスクがあります。スクラム開発はデイリースタンドアップやスプリントレビューによって問題を早期に発見し、対処できます。
適した状況: ウォーターフォール型は要件が明確で変更が少ない案件に適しています。スクラム開発は要件が変化しやすく、継続的な改善が求められる案件に向いています。
どちらの手法が優れているという話ではなく、プロジェクトの性質や組織の状況に応じて使い分けることが重要です。
スクラム開発 (Scrum) は、どんなチームにでも合うものではありませんが、製品やソフトウェアの開発チームにのみ有効な手段というわけでもありません。どんなチームもスクラムフレームワークに適応し、継続的な改善を利用して大きな成果を上げることができます。
スクラムは、コードや新機能など典型的な「製品」であれ、マーケティングキャンペーンやクリエイティブアセットなど一般的ではない形の「製品」であれ、頻繁に何かを開発・納品する必要のあるチームで最も効果的です。
スクラム開発のメリットは以下のとおりです。
機敏かつ柔軟に仕事をできるようになる
チームワークが促進され、より効果的な目標達成に役立つ
スクラムメンバーは製品バックログからタスクを引き出しているため、常に自分が何に取り組んでいるかを正確に把握できる
何を「完了」とするか、チーム全員が共通認識を持っているので、目標が何であるかも正確に理解できる
スクラムプロセスでは変更が良しとされているため、しばしばスコープクリープに苦しむことがあります。変更が多すぎる場合や顧客フィードバックがバラバラな場合、スプリントを繰り返しても意味ある結果を得られないことがあります。
解決策: 各スプリントの目的とインクリメントを明確に定義しましょう。「完了」の基準をチーム全体で明確に理解させ、必要な場合は変更管理プロセスを導入してください。
スクラムチームでは多くのミーティングが開催されます。定期的なスプリント計画・スプリントレビューに加え、毎日のスタンドアップミーティングもあります。
解決策: スタンドアップに意味が感じられないようであれば、やり方を変えましょう。記録をつけることで、チームにとって何が役立ち、何がそうでないかが見えてきます。
スクラムは、製品・エンジニアリング・ソフトウェア開発チーム以外への導入が難しい可能性があります (不可能というわけではありません)。
解決策: スクラムの導入が決まったら、プロセスがどのように役立つかを明確にしましょう。現在の問題点を特定し、役立つスクラムイベントを挙げてください。最初の数スプリント中にトレーニングセッションを開催することもチームの成功につながります。
スクラム開発はあらゆるプロジェクトに適しているわけではありません。以下の特性に当てはまる案件では、スクラムの強みが最大限に発揮されます。
要件が変化しやすい: 市場や顧客のフィードバックによって仕様が変わりやすい案件では、スプリントごとに優先順位を柔軟に調整できるスクラムが力を発揮します。
頻繁なリリースが必要: 小さな改善を継続的に提供するサービス開発や、段階的にリリースするプロダクト開発に向いています。
チームが自律的に動ける: スクラム開発は自己組織化したチームを前提とします。メンバーが主体的に動き、互いに情報を共有できる環境が整っている場合に効果的です。
複雑な問題を扱う: 正解が最初から明確でない複雑な課題に取り組む際、反復的なアプローチによって徐々に解決策を見つけることができます。
要件が最初から固定されており変更がほとんど発生しない案件
チームメンバーが複数プロジェクトを兼務しており、スプリントへの集中が難しい状況
短期間の単発プロジェクトで、スクラムのオーバーヘッド (各種ミーティングなど) が負担になるケース
スクラムの導入を検討する際は、現在のプロジェクトの特性とチームの状況を照らし合わせて判断しましょう。