はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

改めてスクラムの目的を考える

スクラムは少ないルールで構成されているため「理解が容易」と言われていると同時に「習得は困難」といわれています。「習得が困難」といわれる理由はスクラムが決定的な方法論ではなく、常に変化に適応していくためのフレームワークだからではないでしょうか。スクラムガイドで定義されている「やり方」をマネするだけではなく、結果から問題に気づき、「やり方」を変え続ける必要があります。ときにはスクラムという既存の型から抜け出し、新たな型を見つけることも必要です。守破離と呼ばれたりもしますね。

プロジェクトやメンバー構成によって取り入れるプラクティスや進め方が変わりますし、状況によっても変わります。馴染みの店に入って「いつもの!」って頼むわけにはいかないのです。そんなわけで、唯一の解をスクラムに求めていると理解は困難だと思います。

そこで、一度「やり方」から離れて、スクラムが大切にしていること、各ロールやイベントや作成物の目的。「本質」の部分に注目することでスクラムの理解が深まると考えたのが本記事です。

僕もスクラムに関して色々な書籍を読んだり、何度もスクラムガイドを読んだり、実践したりしながら習得しようとしています。色々なところから得た知識を色々な視点でまとめてみることで理解を深めたいと思っています。今回もスクラムガイドを読みながら「本質」と向き合ってみます。
スクラムガイド2017

スクラムは「複雑で変化の激しい問題に対して可能な限り価値の高いプロダクトを生産的かつ創造的に届ける」ためのフレームワーク

f:id:iucstscui:20201007001852p:plain
まずはスクラムの得意領域とそのアプローチ方法について整理していきます。スクラム複雑で変化の激しい問題に対応するためのフレームワークです。問題分類で有名なクネビンフレームワークの「複雑」にあたる領域が得意領域です。スクラムを利用すれば正解が分からない問題に対して可能な限り価値の高いプロダクトを生産的かつ創造的に届けることができます

その「複雑」にアプローチする方法が経験主義となります。未来を予知することはできない、今までの経験から正解を探していきましょうという考え方です。「ちょっと試して違う」、「少し変えて試して違う」、「また少し変えて試して手ごたえがあったぞ」と今分かっている情報から最善の意思決定をして行動する。その結果を観察して次の行動を決める。を繰り返します。OODA(ウーダ)・ループに近いですね。

経験主義でアプローチと言われても簡単ではありません。そこで登場するのがスクラムの3本柱と呼ばれる「透明性」「検査」「適応」です。

  • 透明性:プロダクトに関わる人々の共通理解を図る
  • 検査:好ましくない変化を検知する
  • 適応:プロセスやプロダクトを調整する

スクラムチームはこの3本柱をスクラムイベント、作成物によって太く高くすることで経験的プロセスを確かなものにしていきます。スクラムイベント、作成物は3本柱のためにあります。

柔軟性、創造性、生産性を最適化するためのスクラムチームと3つのロール

f:id:iucstscui:20201010223848p:plain
スクラムイベント、作成物を進めていくスクラムチームを整理していきます。改めて、スクラムは複雑で変化の激しい問題に対して可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのフレームワークです。それを実現するためにスクラムチームは柔軟性・創造性・生産性が最適化するように設計されています。

各ロールの目的は下記になります。

  • プロダクトオーナー:プロダクトの価値を最大化するために機能とその機能の作る順番を決定する
  • 開発チーム:プロダクトを開発する
  • スクラムマスター:スクラムチームの作る価値を最大化する

ロールごとに目的が明確になっているからこそ、迷いなく集中して開発できます。「ユーザーのことを理解しなきゃ」「機能を完成しなきゃ」「検査が弱くなっているからチームに伝えなきゃ」と色々なことをマルチタスクで進めようとすると混乱が生じ、問題が起こるでしょう。

開発はこの3つのロールで協力しながら進めていきます。プロダクトオーナーはユーザーに価値のある仕様を考え開発チームが納得できる方法で説明をし、開発チームは納得できるまで仕様について質問し最適な方法で開発する。スクラムマスターは透明性が向上するようにティーチングやコーチングで全員をフォローします。ロールは分かれていますが、別々に作業するのではなく協力しあって進めていきます

3つのロールに分けることでマルチタスクを減らして生産性を最適化、異なるロール同士で対話することで創造性を引き出します。さらに自己組織化されたチームなので、やるべきことを自分たちで選択します。その選んだ内容は機能横断的なチームによって助け合いながら開発し柔軟性をもたらします。

ただ、ロールを分けることで対立が起きやすくなり、信頼関係にヒビがはいる悪い面もあるため、スクラムの価値基準である「確約・勇気・集中・公開・尊敬の価値基準」が重要とされています。そちらは以前まとめています。スクラムの価値基準をもっと知る - はんなりと、ゆるやかに

透明性、検査、適応を実現するためのスクラムイベント

f:id:iucstscui:20201010223859p:plain
それぞれのイベントで対象となる部分は異なりますが、すべては透明性、検査、適応のためにイベントがあります。

  • スプリント:インクリメントを完成させ、プロダクトの透明性を高める
  • スプリントプランニング:スプリントで何を届けるのか決めて、どう作るのか決めて透明性を高める
  • デイリースクラム:スプリント中の進捗の透明性を高め、課題がないか検査し見つかった場合は適応し、チームのコラボレーションやパフォーマンスを最適化する
  • スプリントレビュー:完成したインクリメントからフィードバックや協力を引き出す
  • スプリントレトロスペクティブ:人・関係・プロセス・ツールの観点から検査し、改善計画を立て適応する

同じペースでリズムよく作り続けることが目的ではなくて、作ったインクリメントから次に作るものを変化させていくことが目的です。見えるものを作る→検査→適応→見えるものを作る→検査→適応→・・・を繰り返して変化に対応していきます。

スプリントではスプリントバックログと別にスプリントゴールを決めます。これはスプリント中の柔軟性を高めるためです。スプリントバックログを開発してもスプリントゴールが達成できないことが分かればプロダクトオーナーと相談して調整します。

透明性や検査、適応の機会を提供するための作成物

f:id:iucstscui:20201010225831p:plain
経験主義において作成物は次の計画を立てるために重要な要素です。特にインクリメントはプロダクトバックログ、スプリントバックログを変化させるための要素です。アジャイルマニフェストの「包括的なドキュメントよりも動くソフトウェア」を体現するものです。今動くもの、市場、フィードバックの声などから適切に変化させていくのです。

  • インクリメント:スプリント終了時の経験主義を支援する
  • プロダクトバックログ:プロダクトに対する変更要求を透明化する
  • スプリントバックログ:スプリントゴールを達成するのに必要な作業を透明化する

スクラムガイドに書かれていますが、スクラムは透明性に依存しています。その透明性を維持するために作成物が重要になり、「完成(Done)の定義」は透明性を保つ重要な要素です。作業の完了についてメンバーが共通の理解を持ち、透明性を確保するために完成(Done)の定義を運用しましょう。

まとめ

f:id:iucstscui:20201010225842p:plain
スクラムは経験主義をベースとした「複雑で変化の激しい問題に対して可能な限り価値の高いプロダクトを生産的かつ創造的に届ける」ためのフレームワークです。「透明性」「検査」「適応」の3本柱をスクラムチーム、スクラムイベント、作成物で高めて開発を進めます。スクラムを導入するとき「デイリースクラム」や「ふりかえり」から始めるチームもあると思います。そんなときこそ、やり方をマネするだけでなく、何のためにそのプラクティスがあるのか把握することが重要です。改めてスクラムの目的を考えることが大切です。