本記事の目的

スクラムはリーン開発を実践していくために、有用なフレームワークの一つです。
リーンの本質を理解した上で、スクラムを基本を再理解し、スクラムというフレームワークの効用を向上できると考えています。
チームで効率的に開発することはスキルです。近道や銀の弾丸はなく、先人の知恵や理論を理解し、実践を通して、習得していく必要があります。
現段階でイメージできない部分もああると思います。しかし、プログラミングを始めたばかりの頃、今のようにスムーズにコードを書ける日が来るとは想像もしていなかったと思います。それと同じように、日々の努力と経験を積むことで、チーム全体としての開発力が向上していきます。
そのための基本的な知識と、具体的な実践方法をこの記事でお伝えします。

課題

スクラム開発を行っているが、以下のような課題を直面している企業は、とても多く見てきました。

• プロダクト開発がなかなか進まない

• チーム内で並行で取り組んでいる開発が多く、認知負荷やスイッチングコストが大きい

• スクラムに取り組んでいるが、スクラムイベントをこなしているだけになっている

リーンとは

ここでいうリーンとは、トヨタ生産方式を原点とし、Accelerate等のリーンをソフトウェア開発に適用したものをベースに説明しています。

リーンの重要な考え方

リーンの重要な考え方は大きく4つあります。

バッチサイズを小さくする

「State of DevOps」等の統計データから、デプロイメントの頻度がテクノロジーや組織のパフォーマンスの予測要因ということがわかっており、デプロイを頻度高く行えるチームはパフォーマンスが高いです。
また、バッチサイズを小さくするということは、必要なものを必要なときに必要な量だけ作るというバイアスとして働きます。これにより、無駄な開発を削減し、効率的な開発を行うことが可能となります。

WIP制限（仕掛り制限）

作業が多すぎる場合、管理者は同時に複数のタスクを掛け持つようにメンバー配分しがちですが、この掛け持ちがタスク完了に時間がかかってしまう原因となります。また複数のタスクを同時に取り込むことにより同時リリースを引き起こし、リリース時のリスクが増加します。
こういうことを防ぐためには、WIPの数を制限し、複数のタスクをかけ持たない制約を設けることが重要です。

自働化

自動化を分かりやすく定義すると、異常検知とプロセスの標準化です。
標準的なプロセスを定義し、異常を検知するとプロセスを停止させ、その場で異常の原因を特定し、再発防止を行うことで、標準プロセスの品質を向上していく取り組みです。
これは、自動テスト、CI/CD等につながり、DevOpsの原則やSREの考え方に通じます。

変動を小さくする

品質のムラを無くすためには、作り方のムラをなくし、標準化していくことが重要です。標準化していくことは自動化につながりますし、自働化を進めることが標準化につながります。
また、キングマンの法則という待ち行列理論に関する変動と待ち時間の関係を現したものがあります。その法則から、変動が大きくなると待ち時間が増加し、変動を小さくすることで待ち時間が減少することがわかっています。変動が小さくなると、システムが時間あたりに処理できる量が増えるといえます。

この4つの考え方は相互に密接に関わりあっており、この4つの概念を取り入れることで、高品質で効率的な開発を行うことができ、開発現場の「ムリ・ムダ・ムラ」を取り除きます。

大きな変更やリリースの問題

また、リーンで繰り返しでてくる「小さなバッチサイズ」は、品質にも大きく影響します。大きな変更やリリースは、以下にあげる、「3つの困難さ」が相互に関わり合い、変更失敗率の増加と品質の低下をもたらします。

変更把握の困難さ

把握すべき量が増えるので、認知負荷が高まります。その結果、影響範囲を正確に把握するのが難しくなり、不具合が混入していても難しくなります。また、コードレビューのコストも高まるので、レビュー自体の品質も低下し、コードの品質低下につながります。

テストの困難さ

テストの範囲も広がり、全体の品質を確保するのが難しくなります。また、変更が密に結合していると複雑になり、問題や原因特定にも時間がかかります。結果として、変更の失敗や品質の低下を招きます。

デプロイの困難さ

大規模リリースでは、新しいバージョンの導入に伴う予期しない問題やバグが発生するリスクが高まり、問題が発生した場合、ロールバックするのが難しく、ダウンタイムが増加するリスクが高まります。また、大規模リリースの準備や実施には多くのリソース（人員、時間、費用など）が集中的に必要となり、他の重要な開発等の品質低下や遅延のリスクがあります。

スクラムとは

概要

スクラムは、アジャイル開発のフレームワークの一つで、スプリントと呼ばれる、短期間の反復的な開発サイクルを中心に、チームが協力してプロダクトを開発・改善する方法です。
詳細は、スクラムガイドを参照してください。
本記事では、本記事を理解し、実践するのに、重要な部分に絞って簡潔に説明します。

スクラムの理論

ベースとなる考え方

スクラムは「経験主義」と「リーン思考」に基づいています。そのため、スクラムでは、予測可能性とリスク制御に重きをおき、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採⽤しています。

スクラムの価値観

• 透明性

  • 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものになります。

• 検査

  • ゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。スクラムでは、 検査を⽀援するために、5つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がなく、また検査がなければ適応ができません。

• 適応

  • 検査によって、異常（期待通りでないこと）を検知した場合、スクラムチームはできる限り早く、学習し、適応することが重要です。

スクラムの理論を支えるフレームワーク

スクラムチーム

スクラムを構成するのは、ゴール達成に必要なすべてのスキルや専⾨知識をチーム全体として備え、またはそれを共有、習得できる人たちです。
スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成されます。これは、⼀度にひとつの⽬的（プロダクトゴール）に 集中している専⾨家が集まった単位です。スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えています。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定できる必要があります。

よくあるアンチパターン

• 目的が設定されていない

  • プロダクトゴールやスプリントゴールが設定されていない、もしくはチームに浸透ができていない場合は、漫然とどこに向かっているがわからないがスプリントを繰り返しているという状態に陥いり、スクラムチームは言われたことをやるというような受け身な社内受託的なチームになります。

• 目的達成に必要な専門家がチームいない

  • バックエンドチームなど言う形で、特定の専門家のみ集まっている等

  • チーム内で意思決定ができない

    • プロダクトオーナーがチーム内にいない、もしくは十分な時間を使えておらず、意思決定をチーム内で行えずに、なにかを決めたり、取り組むのに、チーム外のメンバーとの調整が必要となり、時間がかかる

スクラムイベント

スクラムにおけるそれぞれのイベントは、 スクラムの作成物の検査と適応をするためのオフィシャルな機会です。これらのイベントは、必要な透明性を実現するために明確に設計されています。規定通りにイベントを運営しなければ、検査と適応の機会が失われます。

スプリント
スプリントによって、プロダクトゴールに対する進捗の検査と適応が短い期間ごとに確実になり、予測可能性が⾼まります。スプリントの期間が⻑すぎると、その逆のことが起きるリスクが高まります。品質とのバランスを考えながら、スプリントの期間を短くすれば、より多くの学習サイクルを⽣み出し、コストや労⼒のリスクを短い時間枠に収めることができます。

スプリントプランニング
スプリントプランニングでは、スプリントゴールを定義し、作業の計画をたてます。

デイリースクラム
スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることが目的です。開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1⽇の作業の実⾏可能な計画を作成し、共有します。

スプリントレビュー
スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することです。 スクラムチームとステークホルダーは、スプリントで何が達成され、⾃分たちの環境で何が変化したかについてレビュー行います。

レトロスペクティブ
スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することです。

スクラムイベントをリーン思考をベースに理解する

スプリント

スプリントという単位を持ち、イテレーティブに価値を積み上げていくことの利点は大きく2つあります。

• 変動を小さくすること

• バッチサイズを小さくすること

数ヶ月先にどうなっているか、なにをしているかを見通すことは困難ですが、1週間先や2週間先であれば見通しやすいと思います。見通せるということは、予期せぬことが少ないということであり、すなわち変動を小さく、少なくできるということです。
また、1週間や2週間でできることをベースに物事を考えることで、バッチサイズを小さくすることにも繋がります。

スプリントプランニング

スプリントという期間を制約条件とし、その期間内で達成すべきゴールを決めます。
そのゴールをどうやったら達成できるのかを逆算もしくは積み上げで、計画を立てます。
終わらせることが可能な単位にものごとを分解し、計画を立てます。 
スプリントプランニングは、スプリントという短い期間に対して計画を行うことで、その期間における変動を限りなく0に近づけるための機会です。

Bad
スプリントがただの期間として存在してるだけ。
スプリントゴールが設定されていなかったり、曖昧で、今スプリントで達成すべきことが明確でない。また、スプリントバックログも開発者の手が空かないようにという観点から積まれている。スプリントをまたぐようなサイズのバックログアイテムがそのままスプリントバックログに積まれており、スプリントが制約条件として機能していない。前スプリントで終わらなかったバックログアイテムが今スプリントにスライドするということが常態化している。
Good
スプリントがバッチサイズの制約条件として機能している。
スプリントゴールがプロダクトゴールから逆算され、今スプリントでどんな価値を積み上げることがプロダクトゴールに寄与するかという観点から設定されている。また、スプリントゴールとスプリントバックログがスプリントの期間内に収まることを意識して、計画が行われている。スプリントをまたぐ可能性があるようなバックログアイテムは、スプリントに収まるサイズに分割されている。

デイリースクラム

1日という期間を制約条件とし、スプリントバックログを1日以内に完了するタスクに分割することでバッチサイズを小さくします。

Bad
デイリースクラムがただの相談や共有の場になっている
開発者が取り組んでいるバックログを報告する場になっている。数日同じチケットが作業中という状態が続き、それ以上の詳細が他のチームメンバーからはわからない、透明性の低い状態になっている。スプリント終盤になって、スプリント内にバックログアイテムが完了しない可能性がチームに共有される。スプリントの検査が機能しておらず、同様に適応も困難になっている。
Good
スプリントゴールの達成状況を1日単位で検査する場になっている
スプリントバックログアイテムが1日以内に終わるサイズのタスクに分割されており、バックログアイテムの完了までのアクションと現在の状態がチーム全体が理解できる状態になっており、透明性が高い状態が保てている。その結果、スプリントを適切に検査でき、ゴール達成に懸念が出るようなことがあれば直ちに検知でき、それに対してすぐ適応できる。

スプリントレビュー

インクリメントを検査し、プロダクトに足された価値に異常（期待したものではない、意図通りではない）がないかを検知する。異常があれば、解消、改善するためのアクションを作成する。また、スプリントゴール自体が適切だったかも検査し、今後より良いスプリントゴール設定できるように、外部環境の変化や顧客ニーズに対する理解をアップデートし、向上する。
Bad
ステークホルダーへのインクリメントの発表会になっている
ただのステークホルダーに対するインクリメントの発表会になっており、デモを見せるだけ、もしくは承認だけしか行われない。その結果、インクリメントがプロダクトゴールに向かって進んでいるかのFBが行われず、誤った方向に進んでいたりムダな開発をしていることに気づく機会として活用されない。
Good
スプリントレビューが安全装置として機能している
プロダクトへの価値追加に無駄がなく、誤った方向に進んでいかないための、安全装置的な役割を果たしている。スクラムチームがステークホルダーにインクリメントを簡潔に共有され、ステークホルダーがインクリメントに対してFBを行い、プロダクトゴールに向かって適切に進んでいるかを議論する。異常があれば、原因を究明し、改善のアクションを策定する。

レトロスペクティブ

スクラムチームの品質や効率を高めるために、組織的な学習を行い、標準化していくための場。具体的には、日々の検査やスプリントレビューでの検査で検知した異常の再発防止を行うこと。また、効果があった活動を共有し、チームの標準に落とし込むこと。
Bad
良かったことや悪かったことを話すだけの場になっている
レトロスペクティブの目的が曖昧で、チームメンバーが良かったことや悪かったことを共有するだけの場になっている。改善のアクションが生み出されても、仕組み化されず、標準化といえる状態ならず、スクラムチーム自体の品質や効率向上には至っていない。
Good
スクラムチームの標準化を支援する場になっている
スプリント内でのスクラムチームの活動やスクラムイベントの検査で検知した異常の原因究明と再発防止を行っていること。また、品質や効率向上への有効な活動があれば、仕組み化を図るためのアクションを作成する。スクラムチームの品質や効率を高めるための標準化するための機会となっている。

リーンを意識して、スクラムを正しく実践する

プロダクトゴールを明確にし、浸透させる

中長期的なゴールを明確にし、そのゴールに必要なスキルを持ったチームを構成しましょう。
中長期的なゴールが不透明だと、どこに進むのが正しいか共通認識を持てないので、適切な検査が行えなく、スクラムイベントが形骸化しやすくなります。その結果、漫然とスプリントをただ繰り返したら、ステークホルダーから要求されたことを作るだけというような社内受託に近い状態に近づいていきます。品質の低下や、開発チームのモチベーション低下を招きます。
中長期的なゴールが明確だと、スプリントごとに正しい方向に進んでいそうか検査し、適応することが可能ですし、ゴールに向かうためにやるべきことがチーム内からボトムアップで生み出されてきます。また、将来を見越した設計等も行えるので、品質向上や開発チームの心理的安全性の向上にも寄与します。ゴールの形式としては、プロダクトのミッション、ビジョンの定義や、PRDやユーザ体験設計書などの形式で記述するなどの方法があります。

プロダクトバックログアイテムを作る

プロダクトゴール達成に効果的な仮説を作りましょう。それを検証するためや、検証されたものを顧客に届けるために必要な機能や体験を定義しましょう。
プロダクトオーナーやPdMの思いつきで、やることが決められており、プロダクトバックログアイテムが十分に作成されていない。もしくは、アイテムに曖昧な内容しか記載されておらず、個人の解釈余地が大きい状態だと、設計時や開発時の変動が大きくなり、手戻りや品質低下を招きます。また、見通しが悪い状況は、スクラムチームの心理的負荷につながります。
そのような状態を避けるためには、機能PRDような形式で、「なぜ」、「なにを目的に」、「なにを作る」のかを簡潔にドキュメント化し、チーム全体が理解できる状態を作りましょう。プロダクトバックログアイテムは、プロダクトゴール達成のための現時点でわかっている地図です。チーム内で同じ地図を見ながら会話できるようにしましょう。

プロダクトバックログアイテムを分割し、スプリントを計画する

作成したプロダクトバックログを、作業単位ではなく、価値がある状態を保ったままスプリントに収まるサイズ以下に小さくするもしくは分割しましょう。ここでもスプリントの期間を制約条件として活用しましょう。
バッチサイズの大小がチームで共通の物差しを持てていないと、バッチサイズを小さくしようというバイアスがチーム全体では働かず、プロダクトバックログが大きいまま放置されることが多いです。
スプリントに収まるバッチサイズというのが、チーム内に共通の物差しになっていると、バッチサイズを小さくするための議論がスムーズに進みます。また、スプリントに収まるようなサイズだと認知しやすいので、無駄の検知や、曖昧性による変動が生じづらく、品質とスピードの向上に寄与します。
分割されたバックログアイテム等をもとに、スプリントゴールを定義し、スプリントバックログアイテムを作りましょう。ここで作成されたスプリントバックログアイテムは、スプリント内に完了するように作成してください。
スプリントバックログ全体サイズは、直近の3スプリントのベロシティの平均程度のストーリーポイントを積むというように、標準化されており、変動が小さいため、振り返り時の検査が行いやすい。

スプリントの計画を実行する

スプリントバックログを作業単位に分割し、実行していきます。分割の基準は、1日以内に収まるサイズとなります。その作業をデイリースクラムで検査することによって、検査の精度が高まります。日々の検査で、スプリントゴールの達成確度をチーム全体で認識を揃えていきましょう。
作業単位を分割せずに行われた場合、デイリースクラムがただの作業報告や個人の相談の場になってしまうことが多いです。また、アイテムに関連するタスクを一人ひとりが行う状態になっていると、共有も行われずらく、客観視しにくいため進捗に対する検査も効果的に行えません。そのため、異常の検知にも時間がかかるし、検知後も属人化により、チームとして採れる選択肢が少なく、適応することが難しいというような状態に陥ります。。
このような状況を避け、検査の精度をあげるために、一つのスプリントバックログアイテムを複数人で取り組むと効果的です。
精度高く検査を行い、達成確度が下がるような事象があれば、異常とみなし、チームの手を止め、達成確度を上げるように即座に適応しましょう。
また、複数の開発が並行で行われ、WIPの状態が長くなることを避けるために、チーム内でWIPの数を制限しましょう。これは、機械的に上限数をチームで持っておき、標準化しておくとよいです。

スプリントを振り返る

スプリントレビューは、ステークホルダーが参加することもあり、きちんと運用することが難易度が高いイベントです。よくあるアンチパターンとしては、ステークホルダーへのインクリメント発表会になってしまう。ステークホルダーのFBをスクラムチームが正しく理解できず、うまくアクションアイテムが作れない。などがあります。
そういった状況を避けるためには、ステークホルダーとプロダクトゴールとインクリメントを共通言語として、共同で検査を行い、異常があれば適応のためのアクションアイテムを作成する場にしてください。

レトロスペクティブも油断すると、形骸化しやすいイベントの一つで、前述のように、ただ起きた良いこと、良くないことを話すだけの場になりがちです。
そうならないためにも、レトロスペクティブの目的に対する理解をチーム全体で深めてレトロスペクティブに取り組むこと、スプリント内で発生した異常を書き貯める場所を作り、レトロスペクティブで、その異常が頻発しているプロセスや内容に共通項がないか等を見出す等を視野や視座を変えながら、標準化につなげられるものがないか検討しましょう。
標準化や変動の減少に最も有効なものの一つは、自動化なので、自動化できていないプロセスがあれば、自動化可能化検討し、可能なものはアクションアイテムを作成してください。
できる限り自動化に投資し、異常検知したら再発防止を行い、標準プロセスの品質を上げるというサイクルを作ってください。

スクラムチームのボトルネックを解消する

プロセス内やチーム内で属人化されている領域は、潜在的なボトルネックといえます。
ボトルネックが顕在化する前に解消していくことはとても重要です。
よくあるケースとして、特定領域や技術に詳しい人がいて、その領域や技術に関しては、常に同一の人が担当している状況があります。その場合は、その特定領域や技術に関する知識やスキルがチームに共有されることはなく、その属人化が解消されない状況が続きます。その間に、その領域周辺に変更を行いたいニーズが増加したり、その人が体調不良等でパフォーマンスが低下する等が発生すると、ボトルネックが顕在化します。
ボトルネックが顕在化してから解消しようとしても、共有コストを支払うことはできず、ボトルネックが次のボトルネックを生む状態に陥ります。そういった状況に陥ると、事前に共有コストより数倍以上のコストを払うことになりますし、その間に品質低下を招く可能性が高く、波及効果も考えると、事前に解消していたケースと比較すると機会費用が数十倍に達してしまう場合もあります。
ですので、スクラムチーム内で、スキルや知識を共有することに投資してください。
ジョハリの窓でいう、「秘密の窓」、「盲点の窓」を「開放の窓」に持っていくようにチーム全体で投資しましょう。そして、チーム全体で「未知の窓」を実験を通じて、「開放の窓」にもっていくようにしてください。スクラムが掲げている「経験主義」をより進められるようにチーム全体で協力して取り組みましょう。

リーンは、プロセスを可視化し、計測することで、ボトルネックを特定し、継続的に改善し、標準の質を上げていくことが重要です。
スクラムイベントはその活動を継続的にうまく行うためのフレームワークです。

終わりに

最初から完璧なエンジニアは存在しないのと同様に、最初から完璧なチームも存在しません。
常に高い目標を持ち、正しい方法で取り組むことで、チームは成長し、より良くなります。
もし、自社の状況に合わせた具体的なアクションがイメージしにくい場合は、お気軽にご相談ください。
私たち「Hi-Outcome」は、開発チームの規模が10-100名の企業を中心に、開発支援を行っています。
支援内容は、リーン開発の推進から、開発効率の向上、事業成長への貢献まで、幅広く対応しております。

開発にお悩みの方がいましたら、是非お気軽にお問い合わせください。
開発スピード向上サービス: https://corp.hi-outcome.com/
開発の予測精度向上サービス: https://corp.hi-outcome.com/inspectionAppendix

リーンを支える理論

リトルの法則

λはスループット（一定時間内にどれだけのアイテムを完成させるか）を表す。λ = 10個/week
Wは、サイクルタイム（ワークフローを通過するのに費やす経過時間）を指し、W＝1/1日
Lは、仕掛品数（あるいは、一度に何件の商品がシステムに滞留しているか）を表します。
以下はリトルの法則の式L = λ * Wである。 
WIP = スループット * サイクルタイム。
この式に基づけば、店内にいる顧客の平均数はL＝x×x＝x人と計算できる。
WIP = スループット * サイクルタイム。
リトルの法則が教えてくれるのは、平均WIPが増加すると、2つの重要な指標、平均サイクルタイムと平均スループットのどちらか（または両方）が変化するということです。

制約条件理論 (Theory of Constraints; TOC)

制約条件理論は、システムの性能を最大化するためには、最も制約の強い部分、すなわち「ボトルネック」に焦点を当てるべきだという考え方です。
リーンの観点からは、全体のプロセスの中で、このボトルネックを特定し、それを解消することで全体の流れをスムーズにすることが重要です。制約条件理論は、無駄を排除し、価値の流れを最適化するための手法として利用します。

キングマンの法則

キングマンの法則は、キュー理論における待ち時間に関する法則で、待ち時間の関係を表す式です。システムやプロセスの利用率と変動が待ち時間にどのように影響するかを示しています。
具体的には、システムやプロセスの利用率が上昇すると、変動がもたらす待ち時間の増加は非線形になり、急激に増加します。
キングマンの法則が教えてくれるのは、変動が増加すると待ち時間も増加するため、変動を最小化することで、プロセス全体の効率を向上させることができるということです。
プロセスを可視化し、変動が起きやすいポイントを特定し、対処することが重要です。