事業を伸ばすリーンとスクラム
本記事の目的
スクラムはリーン開発を実践していくために、有用なフレームワークの一つです。
リーンの本質を理解した上で、スクラムを基本を再理解し、スクラムというフレームワークの効用を向上できると考えています。
チームで効率的に開発することはスキルです。近道や銀の弾丸はなく、先人の知恵や理論を理解し、実践を通して、習得していく必要があります。
現段階でイメージできない部分もああると思います。しかし、プログラミングを始めたばかりの頃、今のようにスムーズにコードを書ける日が来るとは想像もしていなかったと思います。それと同じように、日々の努力と経験を積むことで、チーム全体としての開発力が向上していきます。
そのための基本的な知識と、具体的な実践方法をこの記事でお伝えします。
課題
スクラム開発を行っているが、以下のような課題を直面している企業は、とても多く見てきました。
プロダクト開発がなかなか進まない
チーム内で並行で取り組んでいる開発が多く、認知負荷やスイッチングコストが大きい
スクラムに取り組んでいるが、スクラムイベントをこなしているだけになっている
リーンとは
ここでいうリーンとは、トヨタ生産方式を原点とし、Accelerate等のリーンをソフトウェア開発に適用したものをベースに説明しています。
リーンの重要な考え方
リーンの重要な考え方は大きく4つあります。
バッチサイズを小さくする
「State of DevOps」等の統計データから、デプロイメントの頻度がテクノロジーや組織のパフォーマンスの予測要因ということがわかっており、デプロイを頻度高く行えるチームはパフォーマンスが高いです。
また、バッチサイズを小さくするということは、必要なものを必要なときに必要な量だけ作るというバイアスとして働きます。これにより、無駄な開発を削減し、効率的な開発を行うことが可能となります。
WIP制限（仕掛り制限）
作業が多すぎる場合、管理者は同時に複数のタスクを掛け持つようにメンバー配分しがちですが、この掛け持ちがタスク完了に時間がかかってしまう原因となります。また複数のタスクを同時に取り込むことにより同時リリースを引き起こし、リリース時のリスクが増加します。
こういうことを防ぐためには、WIPの数を制限し、複数のタスクをかけ持たない制約を設けることが重要です。
自働化
自動化を分かりやすく定義すると、異常検知とプロセスの標準化です。
標準的なプロセスを定義し、異常を検知するとプロセスを停止させ、その場で異常の原因を特定し、再発防止を行うことで、標準プロセスの品質を向上していく取り組みです。
これは、自動テスト、CI/CD等につながり、DevOpsの原則やSREの考え方に通じます。
変動を小さくする
品質のムラを無くすためには、作り方のムラをなくし、標準化していくことが重要です。標準化していくことは自動化につながりますし、自働化を進めることが標準化につながります。
また、キングマンの法則という待ち行列理論に関する変動と待ち時間の関係を現したものがあります。その法則から、変動が大きくなると待ち時間が増加し、変動を小さくすることで待ち時間が減少することがわかっています。変動が小さくなると、システムが時間あたりに処理できる量が増えるといえます。
この4つの考え方は相互に密接に関わりあっており、この4つの概念を取り入れることで、高品質で効率的な開発を行うことができ、開発現場の「ムリ・ムダ・ムラ」を取り除きます。
大きな変更やリリースの問題
また、リーンで繰り返しでてくる「小さなバッチサイズ」は、品質にも大きく影響します。大きな変更やリリースは、以下にあげる、「3つの困難さ」が相互に関わり合い、変更失敗率の増加と品質の低下をもたらします。
変更把握の困難さ
把握すべき量が増えるので、認知負荷が高まります。その結果、影響範囲を正確に把握するのが難しくなり、不具合が混入していても難しくなります。また、コードレビューのコストも高まるので、レビュー自体の品質も低下し、コードの品質低下につながります。
テストの困難さ
テストの範囲も広がり、全体の品質を確保するのが難しくなります。また、変更が密に結合していると複雑になり、問題や原因特定にも時間がかかります。結果として、変更の失敗や品質の低下を招きます。
デプロイの困難さ
大規模リリースでは、新しいバージョンの導入に伴う予期しない問題やバグが発生するリスクが高まり、問題が発生した場合、ロールバックするのが難しく、ダウンタイムが増加するリスクが高まります。また、大規模リリースの準備や実施には多くのリソース（人員、時間、費用など）が集中的に必要となり、他の重要な開発等の品質低下や遅延のリスクがあります。
スクラムとは
概要
スクラムは、アジャイル開発のフレームワークの一つで、スプリントと呼ばれる、短期間の反復的な開発サイクルを中心に、チームが協力してプロダクトを開発・改善する方法です。
詳細は、スクラムガイドを参照してください。
本記事では、本記事を理解し、実践するのに、重要な部分に絞って簡潔に説明します。
スクラムの理論
ベースとなる考え方
スクラムはアジャイル開発のフレームワークの一つで、短期間の反復的な開発サイクル「スプリント」を中心に、チームが協力してプロダクトを開発・改善する方法です。詳細はスクラムガイドを参照してください。本記事では、スクラムを理解し実践するのに重要な部分に絞って簡潔に説明します。
スクラムの理論
ベースとなる考え方
スクラムは「経験主義」と「リーン思考」に基づいています。予測可能性とリスク制御に重きを置き、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用しています。
スクラムの価値観
透明性: 透明性が検査を可能にします。透明性のない検査は誤解を招き、無駄になります。
検査: ゴールに向けた進捗状況は頻繁かつ熱心に検査されなければなりません。スクラムでは、検査を支援するために5つのイベントを提供しています。
適応: 異常を検知した場合、スクラムチームはできる限り早く学習し、適応することが重要です。
スクラムを支えるフレームワーク
スクラムチーム
スクラムチームは、ゴール達成に必要なすべてのスキルや専門知識を持つ人々で構成されます。スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、複数の開発者で構成され、機能横断型で自己管理型です。
よくあるアンチパターン
目的が設定されていない: プロダクトゴールやスプリントゴールが設定されていない場合、チームは漫然とスプリントを繰り返すだけの受け身な状態になります。
専門家がチームにいない: 必要なスキルを持つメンバーがチームにいない場合、プロダクトの進捗が遅れます。
チーム内で意思決定ができない: プロダクトオーナーが十分な時間を使えない場合、意思決定に時間がかかり、効率が低下します。
スクラムイベント
スプリント
スプリントは短期間で進捗を検査し適応を行うため、予測可能性が高まります。期間が長すぎると、リスクが増します。
スプリントプランニング
スプリントプランニングでは、スプリントゴールを定義し、作業の計画を立てます。
デイリースクラム
スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させます。
スプリントレビュー
スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することです。
レトロスペクティブ
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することです。
リーン思考をベースに理解する
スプリント
スプリントの利点は、変動を小さくし、バッチサイズを小さくすることです。
スプリントプランニング
スプリントという期間を制約条件とし、その期間内で達成すべきゴールを決めます。
デイリースクラムの実践
Bad: ただの相談や共有の場になっている。
Good: スプリントゴールの達成状況を1日単位で検査する場になっている。
スプリントレビューの実践
Bad: ステークホルダーへのインクリメントの発表会になっている。
Good: スプリントレビューが安全装置として機能している。
レトロスペクティブの実践
Bad: 良かったことや悪かったことを話すだけの場になっている。
Good: スクラムチームの標準化を支援する場になっている。
スクラムチームのボトルネックを解消する
プロセス内やチーム内で属人化されている領域は、潜在的なボトルネックといえます。事前に解消していくことが重要です。
終わりに
最初から完璧なチームは存在しません。高い目標を持ち、正しい方法で取り組むことでチームは成長します。自社に合わせた具体的なアクションがイメージしにくい場合は、「Hi-Outcome」にご相談ください。リーン開発の推進から開発効率の向上、事業成長への貢献まで、幅広く対応しております。
開発にお悩みの方がいましたら、是非お気軽にお問い合わせください。
開発スピード向上サービス: https://corp.hi-outcome.com/
開発の予測精度向上サービス: https://corp.hi-outcome.com/inspectionAppendix
リーンを支える理論
リトルの法則
制約条件理論
キングマンの法則
詳しくはこちら
https://corp.hi-outcome.com/magazine/lean_core_concept