articlesスクラムとは何かスクラムはチームの共同作業をサポートするフレームワークです。同じように、スクラムはチームが経験を通じて能力を高め、問題に取り組みながら自己管理し、過去の成功と失敗を振り返って継続的に改善することをサポートします。スクラムは、ソフトウェア開発チームで活用されることが多いものの、その原則や知識はあらゆる種類のチームワークの役に立ちます。アジャイル型プロジェクト管理フレームワークとみなされることの多いスクラムでは、複数のチームが作業を構造化し、管理できるよう、一連のミーティング、ツール、役割について記述します。言葉を引用しながら説明します。アトラシアンのお客様がこれらの基本事項から逸脱して自社独自のニーズに適応させた事例をいくつかご紹介します。ヒントやコツをご紹介します。記事スプリントスプリントとは、スクラムチームが一定量の作業を完了させる際の、短く区切られた期間を指します。記事スプリント計画スプリント計画とは、次回のスプリントで提供できるものとその達成方法を定義する、スクラムのイベントです。つのセレモニーを分かりやすく説明しますスプリント計画、毎日のスタンドアップ、イテレーションレビュー、ふりかえりなどのアジャイルの優れたセレモニーの促進方法をご覧ください。究極の行動リストアジャイルまたはスクラムにおけるプロダクトバックログとは?プロダクトバックログの管理と優先順位付けに関するベストプラクティスを学びましょう。努力を示す方法をご覧ください。記事アジャイルチームのスタンドアップスタンドアップがアジャイルプログラムの健全性に貢献する仕組みや、チームのためのコツとヒントをご覧ください。記事スクラムマスターとは?スクラムマスターとは何であって何ではないのか、またスクラムマスターという役割がアジャイルチームの他のメンバーをどのようにサポートし、協力するのか、説明します。過去に学び、将来に活かす振り返りを行うことで、チームのパフォーマンスは次第に向上していきます。アジャイルのコミュニティの発言を参考に、自分自身で振り返りミーティングを行う時の方法を学びましょう。関連するアクティビティと責任を紹介します。行う方法を説明するステップバイステップのガイドです。このチュートリアルを試す[続き]フレームワークスクラムの軸となる継続的な改善が、アジャイルの中核的な原則であることから、スクラムとアジャイルはよく同一視されます。実際は、スクラムは任務を達成するフレームワークを指し、アジャイルは考え方を表す用語です。するには、顧客への価値の提供についてチーム全体で考え方を変える取り組みが必要なため、本当の意味ではアジャイルには移行できません。それでもスクラムのようなフレームワークを使えば、アジャイル型の思考を始め、日々のコミュニケーションや業務にアジャイル型の原則が根付くよう練習を積むことができます。スクラムフレームワークでは、経験則に基づいて効率的に近似解を模索する方法を採り、変動要素に合わせて学習と調整を続けます。チームはプロジェクトに着手した段階ではすべてを理解していなくても、経験を通じて次第に練度を高めていきます。プロセスに優先順位の付け直しを組み込み、短いリリースサイクルを繰り返す形で、チームが変化の激しい条件とユーザー要件にスムーズになじみ、学習と改善を続けていけるように、スクラムは構造化されています。スクラムは構造化されていますが、適度に柔軟性を保ったフレームワークです。実行時には各組織のニーズに合わせ、柔軟に調整できます。スクラムチームが成功するために必要な作業方法を具体的に説く理論はたくさんあります。熱意を中心に据えるべきだということです。それ以外の部分は、お客様次第です。つのアーティファクトを理解しましょう。アーティファクトとは、問題を解決するツールなど私たちの製作物を指します。定義に応じたインクリメントです。時間をかけて再考と投資を繰り返します。プロダクトバックログは、プロダクト所有者やプロダクトマネージャーによって管理される、達成すべき作業のマスターリストです。プログラムが動的にまとめられます。ノウハウの蓄積や市場の変化を受けて、項目の関連性が薄れたり、問題がほかの方法で解決されたりするため、プロダクト所有者はこまめに検討を繰り返し、優先順位を付け直しながらプロダクトバックログを維持します。スプリントバックログは、開発チームが現在のスプリントサイクルで実装する対象として選んだ項目、ユーザーストーリー、バグ修正のリストです。チームがそのスプリント中に取り組む項目をプロダクトバックログから選び出します。スプリントバックログは柔軟に扱うことができ、スプリントの途中でも変更できます。スプリントで作成された利用可能な最終製品です。デモでは、チームがスプリントで完了したものを示します。定義、つまりマイルストーン、スプリント目標、フルバージョン、リリース済みエピックなどと呼ばれることが多いため、あまり耳にすることのない用語かもしれません。定義しているか、スプリントの目標をあなたがどう定義しているかによります。あるチームは各スプリントの最後に顧客に向けて何かをリリースすることに決めます。一方でこのような考え方がほぼ成り立たないタイプのチームもあります。サーバーベース型の製品に取り組んでいて、顧客へのリリースは四半期ごとが精いっぱいとしたら、どうでしょうか。定義は、一度にリリースする予定のより大きなバージョンの一部の完了となるでしょう。当然ながらソフトウェアのリリースに時間がかかるほど、守るべきソフトウェア納期を達成できないリスクが高まります。ご承知のとおり、アーティファクトにさえたくさんのバリエーションがあるため、担当チームはその中から取捨選択して定義できます。このため、アーティファクトの継続的な管理方法にまでも、常に改善できる柔軟性を残しておくことが大切です。定義によってチームに過度のストレスを与えており、考え直して定義を選び直す必要があるかもしれません。ヒント製品がアジャイルであるのと同程度に、フレームワークもアジャイルである必要があります。進行状況を確認するために時間を十分に取り、必要に応じて調整し、一貫性を守るという理由のためだけに何かを強制することがないようにしましょう。セレモニーではチームによる差異がもっとも顕著に出ます。このようなセレモニーをすべて実施するのは面倒で同じことの繰り返しだと捉えるチームもあれば、必要な確認の機会と見なすチームもあります。回分はすべてのセレモニーを実施し、様子を見るようお勧めします。その後、簡単なふりかえりを実施し、調節の必要な箇所があるかを検討します。以下はスクラムチームが参加する可能性のある主なセレモニーの一覧です。別名「バックロググルーミング」。このイベントの責任者はプロダクト所有者であり、その主な職務は製品をそのビジョンへと方向付けることと、市場と顧客を常に把握することです。そのためにユーザーや開発チームからのフィードバックを常にこのリストに反映して優先順位を決める際に役に立てると同時に、リストを整理していつでも作業できるようにします。健全なバックログの維持方法について詳しくはこちらをご覧ください。このミーティング中に開発チーム全員で計画されます。スクラムマスターが統率するこのミーティングでチームはスプリントの目標を決めます。決定後、プロダクトバックログから具体的な使用ストーリーをスプリントに追加します。ストーリーは必ず最終目標に沿ったものを選び、スクラムチームはスプリント中での導入可能性について合意します。各スクラムメンバーは計画ミーティングの終了時に、スプリントで達成可能な事柄とインクリメントの提供方法を明確に理解している必要があります。スプリントとはスクラムチームが協力してインクリメントを完了する実際の期間を指します。か月がスコープや有用なインクリメントの提供に最適であると考えるチームもあります。氏は、作業が複雑で不明事項が多いほど、スプリントは短い方が望ましいと助言していますが、最終的にはチームの判断に委ねられます。うまくいかない場合は恐れずに変更した方が賢明です。スプリント中、プロダクト所有者と開発チームは必要に応じてスコープについて再度協議します。これはスクラムの実証的な性質の核心となる部分です。計画からふりかえりまで、すべてのイベントはスプリント中に発生します。スプリントの期間が定着したら、開発期間を通してその間隔を守り、チームが過去の経験から学び、学んだものをその後のスプリントに適用しやすくします。同じ場所で開催されるごく短時間の手軽なミーティングです。分以内に抑えるチームが多いものの、必ずそうしなければならないわけではありません。簡潔さに重点を置くために「デイリースタンドアップ」と呼ばれることもあります。時間の計画を立てることにあります。スタンドアップはスプリントの目標達成や障害に関する懸念を発表する機会となります。つの質問に答える形で進行します。障害となるものはあるか?残念ながら、このミーティングがメンバーにとって昨日と翌日のカレンダーの内容を読み上げる場に化しているケースを目にします。スタンドアップの趣旨は、雑多な議論はデイリーミーティングに回して、チームがその日の作業に集中できることにあります。単なるカレンダーの予定を読み上げる場と化しているのなら、躊躇なく創造的な場となるように刷新を図ってください。スプリントの終了時に、チームはインクリメントのデモを見たり点検したりする非公式セッションのために集合します。しているバックログアイテムを共有します。インクリメントのリリースの決定権はプロダクト所有者にありますが、リリースされるケースがほとんどです。このレビューミーティングはプロダクト所有者が現在のスプリントに基づきプロダクトバックログを修正する機会でもあります。した修正は次のスプリント計画セッションに反映されます。時間程度になるように配慮します。ふりかえりでは、スプリント、プロジェクト、人材、関係、ツール、特定のセレモニーに関して効果的だったことと、効果的でなかったことをチームが協議し、文書にまとめます。ふりかえりの目標は、失敗したことより、効果的だったことおよび次回改善が必要なことにチームの意識を集中させる場を設けることにあります。スペシャリスト、運用エンジニアが含まれます。スクラムのプロダクト所有者プロダクト所有者はその製品の舵取り役です。ビジネス、顧客、市場の要件を把握した後、それに応じてエンジニアリングチームが行う作業の優先順位を決めることが主な仕事です。有能なプロダクト所有者は以下のことを行います。プロダクトバックログの作成と管理を行う。業務部門およびチームと緊密に連携し、全員がプロダクトバックログの作業項目を理解できるよう徹底する。次にデリバリーする機能に関して明確なガイダンスをチームに与える。デリバリー頻度が高くなりやすいプロダクトのリリース時期を決定する。プロダクト所有者は常にプロダクトマネージャーと同義であるとは限らないことに注意してください。プロダクト所有者の仕事は、開発チームがビジネスにとって最大の価値を確実に生み出せるようにすることです。人であることも重要です。複数のプロダクト所有者から異なる指示を受けると、開発チームは混乱します。スクラムマスタースクラムマスターは、チーム内のスクラムの推進者です。スクラムプロセスでチーム、プロダクト所有者、組織を指導し、それぞれの取り組み方を微調整する方法を探します。有能なスクラムマスターは、チームが行っている作業を深く理解し、チームが透明性とデリバリーフローを最適化できるよう支援します。スケジュールを決定します。スクラム開発チームスクラムチームは作業の完了者です。持続可能な開発方法の推進者でもあります。人のメンバーで構成されています。基準にする方法があります。チームメンバーは、さまざまなスキルを持ち、相互にクロストレーニングするため、作業のデリバリーで障害になる人はいません。強力なスクラムチームは、自己組織化して「私たち」という明確な姿勢でプロジェクトに取り組みます。チームのすべてのメンバーは相互に助け合い、スプリントが無事に完了するようにします。スクラムチームは各スプリントの計画を推進します。チームは過去のベロシティを参考にして、そのイテレーションで完了できる作業量を予測します。イテレーションの長さを固定しておくと、開発チームは見積もりとデリバリープロセスに関して重要なフィードバックを得ることができます。この結果、予測精度が次第に高まります。スクラム、カンバン、アジャイルスクラムは特に人気の高いアジャイル型フレームワークで、スクラムとアジャイルはよく混同されています。ほかにも、カンバンのように幅広く採用されているほかのフレームワークもあります。名前で呼ばれていますが、実質的にはバックログを使うカンバンです。スクラムとカンバンはどちらも、スクラムボードやカンバンボードといった視覚化手法を使って作業の進捗を追跡します。どちらも効率性を重視し、複雑なタスクを比較的小さく管理しやすい作業に分割するやり方が特長ですが、目標へのアプローチが異なります。スクラムでは比較的短い一定期間のイテレーションに重点をおきます。スプリントの期間が決定すると、そのスプリントサイクル中に実装できるプロダクトバックログやストーリーを決定できます。その後、これらの機能を実装する時間を逆算します。カンバンはスクラムほど構造化されていません。制限を除くと、解釈の自由度がかなり大きくなっています。これに対し、スクラムではスプリントレビュー、ふりかえり、デイリースクラムなど、実装の一部として厳守すべき概念がいくつか決まっています。部門横断型の取り組みを非常に重視しているため、スクラムチームは外部のメンバーに依存しなくても、目標を達成できます。部門横断型チームをまとめるには、やや複雑で工夫が必要です。このようにカンバンは、比較的簡単に採用できる一方、スクラムでは開発チームの機能や思考プロセスをがらりとシフトすることになる場合もあります。スクラムが必要な理由スクラムのフレームワーク自体はシンプルです。ルール、アーティファクト、イベント、役割はスムーズに理解できます。ゆるやかな規範を提供するスクラムのアプローチでは、開発プロセスから解釈のぶれを排除しつつ、企業ごとに独自の特徴を盛り込める余地があります。複雑なタスクを管理しやすいユーザーストーリーに整理すると、難しいプロジェクトもスムーズに遂行できます。役割や計画済みイベントを明確に区分化すると、開発サイクル全体を通して透明性や集団的な責任を維持できるようになります。迅速なリリースを重ねていくと、短期間の進捗がよく見えるため、チームのモチベーションを維持でき、ユーザーの満足度が上がります。スクラムを使いこなせるようになるには時として時間がかかり、典型的なウォーターフォールモデルに依存してきた開発チームでは、その傾向が特に強く表れます。多数の細分化したイテレーション、デイリースクラムミーティング、スプリントレビュー、スクラムマスターの特定といった考え方は、慣れていないチームには難しい文化的転換が必要となることもあります。初期の学習曲線の苦労より、長期的なメリットの方が重要です。大小さまざまな業界で複雑なハードウェア製品、ソフトウェア製品の開発を成功に導いてきたスクラムは、御社でもぜひご採用いただきたい優秀なフレームワークです。empathy.チュートリアル準備はできましたか?このチュートリアルをお試しください。行う方法を説明するステップバイステップのガイドです。このチュートリアルを読む次の記事カンバンアジャイルソフトウェア開発におけるカンバン方式と、アジャイルチームにもたらすメリットを紹介します。この記事を読む次の記事Sprintsアジャイルのトピックアジャイルプロジェクト管理スクラムカンバンデザインソフトウェア開発プロダクトマネジメントチーム大規模アジャイルDevOpsアジャイルに関する記事やチュートリアルをさらに読むには、サインアップしてください。