スクラムは問題を可視化するフレームワーク

Posted at 2018-12-04

はじめに

ここ数年でアジャイル開発への期待が高まっています。
その中でもフレームワークとしてやることが明確なスクラム開発に人気があります。

しかしスクラムはその本質を理解しないと失敗するケースが多く、
かくいう私も一番最初に取り組んだスクラム開発ではうまくいきませんでした。

今はCSM、CSPOの取得とスクラムの実践を通して理解が進んだので、
自分のなかの「スクラムとはなんなのか」をまとめてみました。
事前にスクラムガイドを読んでいると理解がしやすいと思います。

スクラム自体は問題解決をしません。
スクラムは問題を見えるようにするものです。
スクラムのチームもツールもイベントもすべて問題の可視化のために貢献します。
継続的に問題を可視化できる仕組みを保つことによって問題が小さなうちに直していくのです。

ウォーターフォール（以下WF）との一番の違いはここだと思っています。
設計時に埋め込んだバグが実装やテストの時に見つかることはよくある話です。
以下はエンタープライズ系のシステム開発における工程ごとのバグの埋め込み比率です。

上流で埋め込んだバグに気づけないまま下流に行けば行くほど、改修コストは増大します。
システムが大きければ大きいほど埋め込むバグの数は増え、後にかかるコストも増大します。

スクラムでは1～4週間周期でその期間内に収まる規模の機能を順次リリースします。
小さな単位でリリースをするので改修コストは当然抑えられます。
この1回リリースする期間の単位をスプリントと呼びます。

スクラムには先程説明したスプリントを含め以下のイベントがあります：

イベント名を見ると解るかもしれませんが、PDCAサイクルを回すための仕組みが整っています。

スプリントプランニングで計画(PLAN)し、
スプリントで実行(DO)に移し、
スプリントレビューで検査(CHECK)し、
スプリントレトロスペクティブでカイゼン行動(ACTION)を決めます。
こうしてスプリント単位でチームが抱える問題を洗い出し改善していくのです。

これもWFに対する大きなメリットです。
WFにおけるプロダクトや工程の単位は大きすぎてPDCAを回しづらいです。
プロダクト・工程が変わると前回のACTIONを活かすのが難しいことは想像に難くありません。

小さなデイリーベースの問題はデイリースクラムにてチームで共有し、対処します。
フィードバックを受ける機会を明確に定義することで、問題の可視化を促します。

スクラムチームには以下の役割があります。

それぞれの役割が持つ責任は異なります。

プロダクトオーナーはプロダクトの価値を最大化すること。
開発チームはプロダクトバックログの見積もりとそのリリースにコミットすること。
スクラムマスターはチームがスクラムプロセスを守ること。

チームはお互いの問題に気づき共有しあえるような信頼できる関係が必要です。
そのため、スクラムではチームを固定することを推奨しています。
固定されたチームで長期間働き関係を構築するのです。
当然役割ごとの上下関係もあってはなりません。

WFのようにマネージャーが管理するのではなく、
チームの一人一人が責任を果たすために自発的に動くことが求められます。
難しいことですが、自己組織化した暁にはチームの問題解決能力は高いものになっているはずです。

スクラムで利用するツールも問題可視化に役立ちます。

重要なのはPBLもSBLもBDCもチームの目が届く場所にあることです。
これらのツールを見ることで以下のような事がわかります：

問題があることがわかれば、レトロスペクティブまで待たずともカイゼンは可能です。
問題を検査しすぐに対応しましょう。

動くプロダクトが常にあるのであれば、プロダクト自体も良いツールです。
ステークホルダーに触れてもらうことで早い段階で問題をフィードバックしてもらえます。

人はドキュメントを渡されると真面目に読み込んで細かい指摘をならべますが、
実際のソフトウェアを渡されるとマジになって本当に欲しいものについて真剣に考えるそうです。

これもスプリントレビューにて動くソフトウェアを見せる大きなポイントの一つです。

以上のようにスクラムはプロセス、チーム、ツールを明確に定義することで、
問題の可視化を実現し結果アジリティを高めるフレームワークとして構成されています。

スクラムガイドにもある通り、「理解は容易、習得は困難」なのですが、
問題が可視化しカイゼンしていくプロセスは参加している身としてとても楽しいです。
この記事が「習得」の一助になれば幸いです。