はじめに

うちのチームでもスクラム開発が導入されました！
導入されたのはスクラムという開発手法です。

ただ導入したのはいいもののやはり上手くはいかない…
やっていくうちに慣れはするものの、「なんちゃってスクラム開発」感が残っている気がする…

なら上手くいくためにはどうすればいいかを考えはじめて、
そして「やはりスクラム開発という手段ではなく、スクラム開発の目的や理念を理解しないとだめだ」と思ったので、初心に戻り、スクラム開発について調べて整理してみました。
(色々書いたら結構長い記事になっちゃいました…)

なお、本記事は「スクラムガイド」の内容をベースとしています。

スクラム開発をするうえで気を付けておくべきこと

アジャイル開発は導入するだけではダメ！

アジャイル開発を行うと、チームが自己組織化されたり、短期間で成果物ができたり…
などといったことをメリットとしてとらえてスクラムを導入する事例などはありますが、
アジャイル開発を導入しただけではこれらのメリットは捻出できないです。
（そんなことができているのであれば、みんな苦労はしていないはず…）

あたりまえだけど、アジャイル開発にすればすべてが解決するというのは幻想であり、
アジャイル開発は決して銀の弾丸ではないのです。

アジャイル開発を実施するためには、

チームメンバ全員がアジャイル開発に関して理解する
アジャイル開発を理解したうえで、自らがアジャイルになる

ことで、まずはメンバ自身が変わる必要があるのです。
(もちろんですが、スクラム開発を導入するのであれば、スクラム開発に関しても理解する必要があります)

スクラム開発はあくまでもフレームワークである

「スクラムガイド」を見てもわかると思いますが、
スクラム開発は、最低限の枠組み(フレームワーク)しか定義されていません。
(例えばスクラムイベントに関して、目的などの記載はあるけど、どのような手法で進めるかは記載されていない)

これはチームが違ったり、開発の環境が変わるだけで適切なやり方などは変わってくるためです。
そのため、チームメンバがスクラム開発の目的を達成できるようにやり方を柔軟に変えていく必要があります。
(これが「自らがアジャイルになる」ということだと思います)

ともあれ、最初は勝手がわからないと思うので、まずはスクラムを基本通りにやってみて、
そこからチームでもっといいやり方がないかを決めていくのがベストだと思います。

どんなチームであるべきか？

スクラム開発の説明だと、「自己組織化」や「機能横断的」である必要があると書かれています。
また、個人的には「心理的安全性」であることも重要だと思っています。

自己組織化
スクラムチームは誰かに管理されておらず、自分たちで自分たちを管理している状態である必要があります。
例えば開発チームの場合、進捗管理、課題管理、改善、スプリントバックログの選択などを自分たちで適切に行っていればそれは自己組織化されていると言えます。
機能横断的
スクラムチーム外に頼らずにゴールを達成できる状態である必要があります。
例えば開発チームの場合、プロダクトを開発するための全て（設計、コーディング、試験、環境構築、ドキュメント作成など）が開発チーム内でのスキルセットのみで解決されていれば、それは機能横断的なチームであると言えます。
心理的安全性
組織の中で自分の考えや気持ちを誰に対してでも安心して発言できる状態のことです。
チームメンバが何の不安もなく意見を言い合うためには、心理的安全性が高いチームである必要があります。
例えば、メンバが能動的かつ活発に自身の意見を言い合うことができていれば、それは心理的安全なチームであると言えるでしょう。

※参考までに、Googleが「効果的なチームにおいて、最も重要なのは心理的安全性である」と示しています。
「効果的なチームとは何か」を知る

スクラム開発とは

概要

スクラム開発とは、アジャイル開発の一種であり、
チームが一丸となって開発を進め、価値のあるプロダクトを生み出すための軽量級フレームワークです。
短い開発期間（スプリント）で計画/開発/テスト/レビューを実施し、スプリントを繰り返すことでプロダクトを作成していきます。
素早く価値があるものを作るためにスクラムでは最低限の項目だけが定義されています。
定義されている項目は、大きく分けて理論/価値基準/ロール/作成物/イベントの5つに分かれます。

ざっくり説明をすると、
スクラムチームは、各自(各ロール)の責務を全うしながらスプリント内でプロダクトを作成していきます。
そのプロダクトを作成するにあたり必要な作業を明確にするために、スクラムチームはスクラムの作成物を管理する必要があります。
開発期間(スプリント)内には5つのスクラムイベントがあり、これらを実施することで3つのスクラムの理論を実現していきます。
そしてスクラムが成功するかどうかは、5つのスクラムの価値基準を実践できるかどうかにかかっています。

スクラムの理論(3本柱)

スクラムイベントを機能させる重要な理論です。
スクラムイベントを実施する際は、透明性/検査/適応の理論を常に意識する必要があります。
またスクラムでは経験から学んだことを適応する「経験主義」であることが期待されています。
そして、適応するためには検査が必須で、検査をするためは透明性が必須となります。
そのため、この3つの理論の一つでも不足してしまうとスクラムのイベントは機能しなくなります。
　　

透明性

プロセスや作業は、作業を実行する人とその作業結果を受け取る人に見える必要があります。
透明性によって検査が可能となるため、透明性が欠けた状態での検査は、誤解を招き、ムダなものになってしまいます。

検査

スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査される必要があります。
検査によって適応が可能となります。
スクラムイベントは、変化を起こすように設計されているため、適応のない検査は意味がないとされます。

適応

プロダクト開発のためのプロセスが上手くいかなかったり、成果物であるプロダクトが受け入れなれなかった場合は、現在適用しているプロセスやプロダクト開発のための構成要素を調整する必要があります。
スクラムチームは検査によって新しいことを学んだ瞬間にその学習した内容を適応することが期待されています。

スクラムの価値基準

スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっています。
また、これらの価値基準は、スクラムチームの作業・⾏動・振る舞いの⽅向性を⽰されています。
　　　　
スクラムチームのメンバは、スクラムのイベントや作成物を⽤いながら、これらの価値基準を実践し、学習・探索していきます。
これらの価値基準がスクラムチームや⼀緒に働く⼈たちによって具現化されていくことで、スクラムの理論である「透明性」「検査」「適応」が生きてきて、信頼関係が構築できます。

(これらの価値基準で、自分の作業に集中できたり、失敗しても許されたり、問題を伝えたら尊敬されたり、、、のような環境が構築できると思います。そしてこの環境だと自分の意見が言いやすくなり、スクラムの理論が機能していきます。最終的にそれが信頼につながるという意味だと私は解釈しています。)

確約

スクラムチームはゴールを達成し、お互いにサポートすることを確約します。
それは最終結果に対してではなく、行動や努力に対しても適用するものです。

集中

スクラムチームはゴールへ向けて進捗できるように、スプリントの作業に集中します。
なお、「将来的に重要になるかも」ってことに煩わされないようにし、目の前の最も重要なことに集中します。

公開

スクラムチームとステークホルダーは作業や課題を公開します。
また、人および人と働くことに対して心を開くことも大切です。
(仕事や進捗などの公開も重要ですが、人をロボットとしてではなく、交換可能な部品としてではなく、人として認め、心を開いてもらうことがとても重要なのです。)

尊敬

スクラムチームのメンバーはお互いに能力のある独立した個人であると尊敬します。
人や、その人の経験や、バックグラウンドのみならず、多様性やスキル/専門知識にも敬意を払います。

勇気

スクラムチームのメンバは正しいことをする勇気や困難な問題に取り組む勇気を持ちます。
「誰も使わない機能を作らない勇気」「完璧な要件や計画はないと認める勇気」「誰も完璧ではないということを認める勇気」なども当てはまります。

スクラムチーム(各ロール)

スクラムの基本単位は、スクラムチームという⼩さなチームとなります。
スクラムチームは心理的に安全であり、自己組織化されており機能横断的である必要があります。
また、スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成されます。
　　

プロダクトオーナー

スクラムチームから⽣み出されるプロダクトの価値を最⼤化することに責任を持ちます。
プロダクトの価値を最大化するために次のようなことを行います。

プロダクトゴールを明確にし、明⽰的に伝える。
プロダクトのリリース計画を策定する。
顧客やプロダクトの管理者にバックログの内容を確認し、アイテムの優先順位や実現時期を相談し、必要に応じて並び替える。
プロダクトバックログアイテムの内容を関係者が理解できるように説明する。
プロダクトバックログの内容を最新の状態に更新する。
プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
作られたプロダクトが要求（完了の定義）を満たしているかを検査（レビュー）する。

プロダクトバックログの更新や並び替えはスクラムマスターや開発者も実施できますが、最終的な責任はプロダクトオーナーにあります。
そして、プロダクトオーナーが決めたことは尊重し、勝手に覆してはいけません。
プロダクトオーナーが決めたことを尊重することで、結果に対する責任をプロダクトオーナーが負えるようになります。

スクラムマスター

スクラムチームにスクラムのことを理解してもらい、正しく効果的に実践するように促すことに責任を持ちます。
スクラムチームにスクラムのやり方を教えたり、やり方が間違っていたら教えてあげたり、会議の司会進行を行ったりします。
それ以外にもスクラムマスターはさまざまな形でスクラムチームを⽀援していきます。
下記はスクラムマスターが開発者の支援として行うことの一例です。

スクラムチームが正しくスクラムを実施できるようにコーチする。
すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする。
スクラムチームがプロダクト作成に注力できるように支援する（ツール導入とか）。
スクラムチームの進捗を妨げる障害物（障害となる作業）を排除するように働きかける。

妨害となる障害をリスト化し、優先順位をつけたものを妨害リストと呼びます。
スクラムマスターは妨害リストのアイテムを解決することを行います。
また、プロダクトオーナーが忙しくプロダクトバックログの管理などができていない場合、スクラムマスターはプロダクトオーナーをフォローする必要があります。
下記はスクラムマスターがプロダクトオーナー支援として行うことの一例です。

プロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する。
プロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。

開発者

プロダクトに関するあらゆる側面（品質、計画、専門性）に責任を持ちます。
開発チームは、プロダクトを作るために必要な作業ができなければいけないため、特定のスキルだけではなく様々なスキルを持つ人が望まれます（機能横断的）。
※様々なスキルを習得できるように開発をしていくのもありだと思います

開発チーム内には年齢や役職の上下関係を意識してはいけません。
仕事を進める際は、開発者全員で考えて全員が合意して進めていきます。
そうすることで開発者全員が責任を持つことができます（自己組織化）。

また、開発者は常に次の結果に責任を持ちます。

スプリントの計画（スプリントバックログ）を作成する。
完成の定義を忠実に守ることにより品質を作り込む。
スプリントゴールに向けて毎⽇計画を適応させる。

スクラムの作成物

スクラムの作成物は作業や価値を表しており、重要な情報の透明性を最⼤化できるように設計されています。
各作成物には、透明性と集中を⾼める情報を提供するための「確約（コミットメント）」が含まれており、これにより進捗を測定できるようになります。
　　

プロダクトバックログ

プロダクトバックログは、プロダクト開発に必要なアイテムが優先度順に並べられた⼀覧です。
この中のアイテムを全てこなすとプロダクトが完成します。
最初から完璧なログを作成しなくてもよく、不足が見つかった際はスクラムメンバーの誰でも追加することができます。
(ただし優先度のの決定権はプロダクトオーナーのみ)

プロダクトバックログの順序はプロダクトオーナーが常に最新に保つ必要がある。
これを行うことで、スプリントプランニングのときに優先度が高いアイテムをスプリントバックログに入れることができます。

確約（コミットメント）：プロダクトゴール
プロダクトゴールは、プロダクトの将来の状態を表しており、スクラムチームはその状態を目指すためのアイテムを実施します。
プロダクトゴールはプロダクトバックログに含まれ、ゴール以外のアイテムはプロダクトゴールを達成する「何か（what）」を定義するものとなります。
プロダクトゴールは、スクラムチームの⻑期的な⽬標となります。
次の⽬標に移る前に、スクラムチームはひとつの⽬標を達成（または放棄）しなければいけません。

スプリントバックログ

スプリントバックログは、下記の3つで構成されています

スプリントゴール（なぜ）
スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）
インクリメントを届けるための実⾏可能な計画（どのように）

スプリントバックログは、開発者による、開発者のための計画です。
メンテナンスも開発者自身で行います。
スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業をリアルタイムに反映していきます。
なお、スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要となります。

確約（コミットメント）：スプリントゴール
スプリントゴールはスプリント内で達成したい目標であり、スプリントプランニングで作成してスプリントバックログに追加します。
注意点としては、タスクを完了させることがスプリントゴールの完了条件ではないということ。
そのため、スプリントゴールを達成するために必要となるタスクに対しては柔軟性をもたらす必要があります。
スプリントゴールによって、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すことができます。
開発者がスプリントで作業するときにはスプリントゴールを念頭に置き、作業が予想と異なることが判明した場合はスプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整していきます。

インクリメント

インクリメントはプロダクトゴールに向けた具体的な踏み⽯であり、過去の全てのインクリメントが含まれます。
インクリメントは全てが連携して機能することを保証するために、徹底的に検証する必要があります。
また、価値を提供するにはインクリメントをまとめたものを利⽤できるようにしておかなければいけません。
スプリント終了前にインクリメントを顧客にデリバリーする可能性もあるが、インクリメントは完了の定義を満たしていればリリース可能である。
スプリントレビューをリリースするための関⾨と⾒なすべきではないです。

確約（コミットメント）：完了の定義
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述です。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣します。
完成の定義により、作業の完了基準が全員の共通認識となり、透明性が⽣み出されます。

プロダクトバックログアイテムが完成の定義を満たしていない場合、それはレビューの対象にならず、リリースすることもできません。
そのようなアイテムはプロダクトバックログに戻し、次回のスプリントプランニングでやるかやらないかを決めます。
完了の定義はスクラムチームで管理し、プロダクトに適した完成の定義を作成する。

スクラムイベント

スクラムは、スプリントと呼ばれる期間を設定して、開発を行っていきます。
スプリントの期間は1か月以内の決まった長さとし、その中で5つのスクラムイベントを実施します。
（スプリント期間はスクラムチームで決めます）
　　　　

スクラムのイベントは下記図のような流れで実施していきます。

デイリースクラムは毎日実施し、それ以外のイベントはスプリント内に1回実施します。
また、スクラムイベントには制限時間が設けられており、この長さはスプリントの長さに依存します。この制限時間やスプリント期間のことをタイムボックスと言います。

スプリント期間	1週間	2週間	4週間
プロダクトバックログリファインメント	4時間以内	8時間以内	16時間以内
スプリントプランニング	2時間以内	4時間以内	8時間以内
デイリースクラム	15分以内	15分以内	15分以内
スプリントレビュー	1時間以内	2時間以内	4時間以内
スプリントレトロスペクティブ	1時間以内	1.5時間以内	3時間以内

スプリントを2週間と決めたのであれば、1日でも多かったり少なかったりしてはいけません。
この期間を守らないと、スクラムチームが一定期間内にどれくらいのプロダクトを生み出すことができるか(ベロシティ)を計測できなくなってしまいます。
また、開発者にはプロダクトを生み出すための時間を確保してあげる必要があります。
そのためにも、無駄な会議（スクラムの理論/価値基準に関係がない会議）をなくしたり、スクラムイベントを最低限の時間で実施してあげる必要があります。
これらのためにタイムボックスは必ず守らなければいけません。

プロダクトバックログリファインメント

【必須参加者：スクラムチーム全員】
プロダクトバックログアイテム(PBI)に対して詳細な説明をし、大きいければ分割し、見積もりおよび並び替えをすることが目的となります。
PBIに対して、下記の作業を実施する。

大きいPBIの分割
各PBIを詳細化し、着手可能にする
PBIを見積もる（プランニングポーカー）

プロダクトバックログの責任者はプロダクトオーナーですが、詳細・見積もり・優先順位付けは開発チームも協力して決めていくことになります。
ただ、プロダクトオーナーは情報の分散や伝達ロスを発生させないためにも必ずイベントに出席する必要があります。
また、スクラムはチームを方式検討/テストなど役割分担することを禁止しているはずなので、チームの一部ではなく、チーム全員がイベントに参加する必要があります。

スプリントプランニング

【必須参加者：スクラムチーム全員】
スクラムチーム全員で、スプリントで実⾏する作業の計画を⽴てることが目的となります。
スプリントプランニングは第一部と第二部に分かれています。
第一部では、今回のスプリントでどのプロダクトバックログアイテムを実施するのかを検討します。この際、プロダクトオーナーは参加者に対してプロダクトバックログアイテムの内容を伝える必要があります。開発者は第二部で作業計画を立てるために、プロダクトバックログアイテムの透明性を意識するとよいでしょう。
第二部では、第一部で選択したプロダクトバックログアイテムを完了させるために必要な作業を洗い出し、各作業の時間を見積もります。
（個々の作業は1日以下の単位にするのが良いでしょう）
ここで見積もった結果、今回のスプリントで完了するのが難しいと判明した際は、プロダクトオーナーと相談し、プロダクトバックログの調整をしましょう。

デイリースクラム

【必須参加者：スクラムマスター、開発者】
計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることが目的となります。
このイベントは毎日開催します。
目的を達成するためであれば、どんなことを話してもよいし、やり方も自由ですが、特に話す内容が決まっていないのであれば、「前回のデイリースクラムからやったこと」「次回のデイリースクラムまでにやること」「困っていること」の3点について話すとよいでしょう。
※スクラムマスターが開発者と兼任の場合は、スクラムマスターも作業内容を共有する必要があるので注意。

スプリントレビュー

【必須参加者：スクラムチーム全員、ステークホルダー】
スプリントの成果を検査し、今後の適応を決定することが目的となります。
スクラムチームは、主要なステークホルダーに作業の結果をデモ形式で提⽰し、プロダクトゴールに対する進捗について話し合います。
(デモ形式で見せるのは、実際に作成したものが完了の定義を満たしているかを判断できるようにするためです)

このイベントで得られた情報に基づいて、スクラムチームは次にやるべきことを調整していきます。
また、このイベントで得られた情報は、課題や改善案を検討する材料としても使えるのでレトロスペクティブのときに話し合ったりすると良いでしょう。

スプリントレトロスペクティブ

【必須参加者：スクラムチーム全員】
品質と効果を⾼める⽅法を計画することが目的となります。
個人および共同作業、プロセスやツール、完了の定義などに関して今回のスプリントがどのように進んだかを検査します。
スプリント内で上手くいったことは継続し、上手くいかなかったことに関しては
話し合います。具多的には、「どのような問題が発⽣し、そしてどのように解決しようとしたか、もしくは解決できなかったか」などを話し合います。
そしてその問題の改善案を模索します。
⼤きな問題である場合は、できるだけ早く対処したほうがよく、次のスプリントのスプリントバックログに追加するのも良いでしょう。

なお、このイベントではプライベートで感じている問題を話しても良いです。
例えば、「在宅で集中できない」という問題があったらオフィスに出社できるようにフォローしたり、「子供の夜泣きがひどくて寝られない」という問題があれば、朝の会議の時間をずらしたり、、、などといったように業務改善につながったりします。（この辺のフォロー作業に関してはスクラムマスターが頑張る！）

またレトロスペクティブでは悪いことに目が行きがちですが、どんな些細なことでもよかったことを共有できると良いでしょう。
悪いことの共有だけだと、レトロスペクティブ自体が億劫なイベントとなってしまったり、チームの空気が悪くなるし…

おわりに

ここまで色々と書いてきましたが、
これらの内容は、「スクラム開発の経験だったり」「スクラム開発の導入支援の経験だったり」「スクラム開発にして自己学習したり」で得た知見ですので、納得できない部分も多々あると思います。
その辺も考慮して、自分たちのスクラムチームに役立てていただければ幸いです。

余談ですが「スクラムは楽しいものです」という話をどこかで聞いたことがあります。
その話を聞いた時、私は下記のようなステップを踏むことでスクラムが楽しくなっていくのかなと思ったりしました。

スクラムの価値基準を実施でき、心理的安全なチームとなる。
心理的安全なことで活発なコミュニケーションを取れるようになり、スクラムイベントが活性化していく。
スクラムイベント内では、スクラムの3本柱を実現するような話ができ、スクラム開発が機能していく。

その中でも肝となるのは「活発なコミュニケーション」で、それを行うためには心理的安全である必要があるのかなと考えています。心理的安全性を高めるためには、他人を褒めたり、失敗を認めたりなどといったように自身のマインドを変えていく必要があります。
冒頭でも書きましたが、まずはメンバ自身が変わる必要があることをお忘れなきように…

初心に戻ってスクラム開発のおさらい