スクラムは、リーン開発を実践するために有効なフレームワークの一つです。リーンの本質を理解した上でスクラムの基本を改めて学ぶことで、スクラムの効果を最大限に引き出すことができます。この記事では、チームで効率的に開発するためのスクラムの実践方法について解説します。リーンの詳細はこちらからスクラムとはスクラムはアジャイル開発のフレームワークの一つで、スプリントと呼ばれる短期間の反復的な開発サイクルを中心に、チームが協力してプロダクトを開発・改善する方法です。詳細はスクラムガイドを参照してください。本記事では、リーンなスクラムを理解し実践するために、重要な部分に絞って簡潔に説明します。スクラムの理論スクラムは「経験主義」と「リーン思考」に基づいています。そのため、スクラムでは、予測可能性とリスク制御に重きをおき、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採⽤しています。リーン思考に関しては、こちらをお読みください。スクラムの価値観透明性透明性によって検査が可能になります。透明性がないと、正しい現状認識が行えないため、検査が成り立ちません。検査検査によって適応が可能になります。なので、ゴールに向けた進捗状況は、頻繁かつ熱⼼に検査される必要があります。スクラムでは、 検査を⽀援するために、5つのイベントを提供しています。適応検査によって、異常（期待通りでないこと）を検知した場合、スクラムチームはできる限り早く学習し、適応することが求められます。スクラムを支えるものここでは、スクラムを支えるものとして、「スクラムチーム」と「スクラムイベント」を説明します。スクラムチームスクラムイベントスクラムチームスクラムチームは、ゴール達成に必要なすべてのスキルや専門知識を備え、これを共有・習得できるメンバーで構成されています。スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、複数の開発者で構成され、一つの目的（プロダクトゴール）に集中しています。スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを持ち、自己管理型でもあります。誰が何を、いつ、どのように行うかをスクラムチーム内で決定することが求められます。出典: https://www.scrum.org/resources/blog/equality-accountabilities-scrumよくあるアンチパターン目的が設定されていないプロダクトゴールやスプリントゴールが設定されていない、またはチームに浸透していない場合、チームは漫然とスプリントを繰り返すだけの状態に陥ります。その結果、スクラムチームは受け身になり、指示されたことをこなすだけの社内受託的なチームになってしまいます。目的達成に必要な専門家がチームいない特定の専門家のみで構成されたバックエンドチームなど、必要なスキルを持つ専門家がチームに不足している場合があります。チーム内で意思決定ができないプロダクトオーナーがチーム内に不在、または十分な時間を割けない場合、意思決定がチーム内で行えず、何かを決めたり取り組む際に、チーム外のメンバーとの調整が必要となり、時間がかかります。スクラムイベントスクラムの各イベントは、成果物を検査し、適応するための公式な機会です。これらのイベントは、必要な透明性を実現するために明確に設計されています。規定通りにイベントを運営しないと、検査と適応の機会を失うことになります。スプリントスプリントは、プロダクトゴールに対する進捗を短期間で検査し、適応を確実にするための期間です。短いスプリント期間は、予測可能性を高め、多くの学習サイクルを生み出し、コストや労力のリスクを抑えます。スプリント期間が長すぎると、逆にリスクが高まります。スプリントプランニングスプリントプランニングでは、スプリントゴールを定義し、作業の計画をたてます。デイリースクラムデイリースクラムの目的は、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることです。開発者は、スプリントゴールの進捗に焦点を当て、1日の作業計画を作成し、共有します。スプリントレビュースプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することです。スクラムチームとステークホルダーは、スプリントで達成されたことや環境の変化についてレビューを行います。レトロスペクティブスプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することです。スクラムイベントをリーン思考をベースに理解するさきほど、説明したスクラムイベントを、リーンの側面からどういう位置づけなのかを見ていきます。スプリントスプリントには以下の2つの大きな利点があります。変動を小さくすることバッチサイズを小さくすること数ヶ月先のことは見通せなくても、1〜2週間先なら見通しやすいです。見通しやすいということは予期せぬ事態が少なく、変動を小さくできることを意味します。また、短い期間を基準に考えることで、バッチサイズも小さくできます。スプリントプランニングスプリントという期間を制約条件として、その期間内で達成すべきゴールを決めます。ゴールを逆算または積み上げて計画を立て、終わらせることが可能な単位に分解します。これにより、スプリント期間中の変動を最小限に抑えることができます。Bad: スプリントがただの期間として存在しているだけ。スプリントゴールが設定されていなかったり、曖昧で達成すべきことが明確でない。また、適切な分割ができていないため、スプリントをまたぐサイズのPBIがスプリントバックログに含まれている。Good: スプリントがバッチサイズの制約条件として機能している。スプリントゴールがプロダクトゴールから逆算され、期間内に収まる計画が立てられている。スプリントをまたぐ可能性のあるバックログアイテムは、スプリントに収まるサイズに分割されています。デイリースクラム1日という期間を制約条件とし、スプリントバックログを1日以内に完了するタスクに分割することでバッチサイズを小さくします。Bad: デイリースクラムがただの相談や共有の場になっている。数日間同じチケットが作業中で、透明性が低く、スプリント終盤になって進捗が共有されることがある。Good: スプリントゴールの達成状況を1日単位で検査する場になっている。スプリントバックログアイテムが1日以内に終わるサイズに分割されており、透明性が高く、ゴールに対してアラートが出れば、直ちに適応できます。スプリントレビュープロダクトに追加された価値を検査し、異常があれば解消・改善のアクションを作成します。スプリントゴールの適切性も検査し、より良いスプリントゴール設定のために、外部環境の変化や顧客のニーズをアップデートします。Bad: ステークホルダーへのインクリメントの発表会になっている。デモや承認だけで終わり、フィードバックや議論が行われず、誤った方向に進んでいたとしても気づくことができない。Good: スプリントレビューが安全装置として機能している。ステークホルダーから成果物に対するフィードバックが行われ、プロダクトゴールに向かって適切に進んでいるかを議論します。異常があれば原因を究明し、改善のアクションを策定します。レトロスペクティブスクラムチームやプロセスの品質や効率を高めるために、組織的な学習を行い、標準化する場です。日々の検査やスプリントレビューで検知した異常の再発防止を行い、効果があった活動を共有しチームの標準プロセスに落とし込みます。Bad: 良かったことや悪かったことを話すだけの場になっている。改善のアクションが生み出されても仕組み化されず、チームの品質や効率向上に繋がらない。Good: スクラムチームの標準化を支援する場になっている。スプリント内での活動やイベントで検知した異常の原因究明と再発防止を行い、品質や効率向上への有効な活動を仕組み化します。また効果的だった活動も標準プロセスに組み込んでいく場として機能している。スクラムを効果的に実践するための6つのポイントリーン思考を理解したうえで、効果的にスクラムを実践していくための6つのポイントをあげて解説していきます。プロダクトゴールを明確にし、チームに浸透させるプロダクトゴールから逆算された、プロダクトバックログアイテムを作成するプロダクトバックログアイテムを分割し、スプリントを計画するスプリントの計画を小さく実行するスプリントを検査し、適応し、標準化するスクラムチームのボトルネックを解消するプロダクトゴールを明確にし、チームに浸透させる中長期的なゴールを明確にし、そのゴールに必要なスキルを持ったチームを構成しましょう。中長期的なゴールが不透明だと、進むべき方向について共通認識が持てず、適切な検査が行えなくなります。その結果、スクラムイベントが形骸化し、漫然とスプリントを繰り返すだけの状態に陥りがちです。これでは、ステークホルダーからの要求に応えるだけの受託開発的なチームになってしまい、品質の低下や開発チームのモチベーション低下を招きます。中長期的なゴールが明確であれば、各スプリントごとに正しい方向に進んでいるかを検査し、適応することが可能です。ゴールに向かうためにやるべきことがチーム内からボトムアップで生まれ、将来を見越した設計も行えるようになります。これにより、品質の向上や開発チームの心理的安全性の向上にも寄与します。ゴールの形式としては、プロダクトのミッションやユーザー体験設計書を定義したうえで、でプロダクトロードマップを作成します。そして、1年や四半期のゴールを設定し、それをチームの直近のゴールにすることで、実行しやすくなります。プロダクトゴールから逆算された、プロダクトバックログアイテムを作成するプロダクトゴール達成に効果的な仮説を立て、それを検証するためや顧客に届けるために必要な機能や体験を定義しましょう。プロダクトオーナーやPdMの思いつきでやることが決められているような状況だと、バックログアイテムの内容が曖昧になり、個人の解釈に差が生じ、設計や開発時に変動が大きくなり、手戻りや品質低下を招きます。見通しが悪い状況は、スクラムチームの心理的負荷にもつながります。このような状態を避けるために、基本的には、プロダクトゴールと結びつく形で、「なぜ」、「なにを目的に」、「なにを作るのか」を簡潔にドキュメント化し、チーム全体が理解できる状態を作りましょう。プロダクトバックログアイテムは、プロダクトゴール達成のための現時点での地図です。チーム内で同じ地図を見ながら会話できるようにしましょう。プロダクトバックログアイテムを分割し、スプリントを計画するプロダクトバックログアイテムを作業単位ではなく価値を保ったままスプリントに収まるサイズに小さく分割します。ここでもスプリントを制約条件として活用しましょう。小さいサイズだと認知負荷が少なく、ムダの検知や曖昧性による変動や手戻りが生じづらくなり、品質とスピードの向上に寄与します。また、適切なバッチサイズの粒度が個人でバラバラだと、バッチサイズを小さくする意識がチーム全体に働きにくいです。スプリントに収まるサイズを共通の物差しとすることで、バッチサイズを小さくする活動がスムーズに進みます。分割されたバックログアイテムを基にスプリントゴールを定義し、スプリントバックログアイテムを作りましょう。直近3スプリントのベロシティの平均などチームの目安を作ると、やりやすいです。スプリントの計画を小さく実行するスプリントバックログを作業単位に分割し、実行していきます。分割の基準は1日以内に収まるサイズです。1日以内に分割することで、デイリースクラムでの検査の精度が高まります。日々の検査で、スプリントゴールの達成確度をチーム全体で認識を揃え、異常があれば適応していきましょう。バックログアイテムを分割せずに進めると、進捗が見えづらく、透明性が低くなり、デイリースクラムがただのなにをやっているかの作業報告になりがちです。また、検査の精度を上げるために、一つのスプリントバックログアイテムを複数人で取り組むことが効果的です。リソース効率よりフロー効率を意識することで、品質とスピードを両立した形で開発が行えます。また、複数の開発が並行で行われ、WIPの状態が長くなることを避けるために、チーム内でWIPの数を制限しましょう。これは、機械的に上限数を設定し、標準化しておくと良いです。スプリントを検査し、適応し、標準化するスプリントレビューは、チーム外のメンバーが参加することもあり、スクラムイベントの中で運用することが難しいイベントです。よくあるアンチパターンとして、インクリメント発表会になってしまったり、ステークホルダーのフィードバックをスクラムチームが正しく理解できず、アクションアイテムがうまく作れないことがあります。このような状況を避けるためには、ステークホルダーとプロダクトゴールを共通言語、成果物をインターフェイスとし、同じゴールに向かう仲間として、成果物とプロダクトゴールを元に成果物を共同で検査し、異常があれば適応のためのアクションアイテムを作成する場として扱うと、効果的なイベントとして機能します。また、レトロスペクティブも形骸化しやすいイベントの一つです。前述のように、ただ良かったことや悪かったことを話すだけの場になりがちです。このような状況を避けるために、レトロスペクティブの目的をチーム全体で理解し、スプリント内で発生した異常を書き留める場所を作りましょう。レトロスペクティブでその異常が頻発しているプロセスや内容に共通項がないかを見出し、標準化につなげられるものがないかを検討しましょう。標準化や変動の減少に最も有効な手段の一つは自働化です。自働化できていないプロセスがあれば、自働化可能かを検討し、可能なものはアクションアイテムを作成しましょう。できる限り自働化に投資し、異常を検知したら再発防止を行い、標準プロセスの品質を上げるサイクルを作りましょう。スクラムチームのボトルネックを解消するプロセス内やチーム内で属人化されている領域は、潜在的なボトルネックです。ボトルネックが顕在化する前に解消することが非常に重要です。よくあるケースとして、特定の領域や技術に詳しい人がいて、その人が常に同じ担当をしている状況があります。この場合、その領域や技術に関する知識やスキルがチームに共有されず、属人化が解消されません。その間にその領域周辺に変更が必要になった場合、その担当者に負荷がかかり、チームは待機することになり、ボトルネックが顕在化します。ボトルネックが顕在化してから解消しようとしても、ビジネス的な要求が発生している状況下ではなかなか知識共有のコストを払えず、次のボトルネックを生む状態に陥ります。このような状況に陥ると、事前に共有コストを払うより、結果的に数倍以上のコストを払うことになります。品質の低下やその他の波及効果を考えると、事前に解消していた方がコストははるかに低くなります。スクラムチーム内で、スキルや知識を共有することに投資してください。ジョハリの窓でいう「秘密の窓」「盲点の窓」を「開放の窓」に持っていくように、チーム全体で取り組みましょう。そして、チーム全体で、実験や検証を通して「未知の窓」を「開放の窓」に持っていくようにしてください。出典: https://japaneseclass.jp/リーンを実践するには、プロセスを可視化し、計測することで、ボトルネックを特定し、継続的に改善し、標準の質を上げていくことが重要です。スクラムは、そ活動を継続的にうまく行うためのフレームワークです。終わりに最初から完璧なエンジニアは存在しないのと同様に、最初から完璧なチームも存在しません。常に高い目標を持ち、継続的に改善に取り組むことで、チームは成長し、より良くなります。スクラムは、チームで継続的な改善を行うのに最も適したフレームワークの一つです。もし、自社の状況に合わせた具体的なアクションがイメージしにくい場合は、お気軽にご相談ください。