結局スクラムとは何なのか

はじめに

こんにちは。PharmaXでエンジニアリングマネージャーをしている古家(@enzerubank)です。

弊社では開発手法としてスクラムを採用しているのですが、新しいメンバーに説明する時に改めてスクラムとは何なのかを言語化しておく必要があるなと思い、まとめてみました。

スクラムガイドの定義

スクラムとはアジャイルを実践するための手法の一つであり、公式のドキュメントであるスクラムガイドには以下のように定義されています。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織
が価値を⽣み出すための軽量級フレームワークである。

複雑な問題に適応することで、チームや組織が価値を生み出すための軽量フレームワークとのことですが、これだけだとよくわからないですね。

スクラムが生まれるまでの背景

1980年後半頃までは元々製造業や建築業で生まれたウォーターフォール型開発が定番で、「不確実性」は計画の段階で限りなくゼロにできるという思想の手法でした。

これは決まったことを分業して効率的に進める上では有効ですが、変化の激しいソフトウェアの開発においては、うまくいきませんでした。

その結果としてアジャイルが生まれ、経験的プロセス、つまりは決まったことを決まったとおりにやっていくのではなく、経験から学習し、組織を強くしていく方法論へ進化していきました。

アジャイルは「不確実性をゼロにできるような銀の弾丸はない」という前提のもと、

• 細かいイテレーションを区切ったものづくり
• プロダクトの評価を細かい期間で行い、軌道修正を行う
• 事前に用意するドキュメントよりも、今動いているコードを信頼する

などのリアルタイムで進んでいる開発・プロセス・チーム状態に目を向け続けて、常に経験から学習し、軌道修正を行っていこうという思想の開発手法です。

つまりは、「開発手法、進め方に銀の弾丸はない」という前提の元、より良い結果を出すために自分たちに合ったプラクティスを学習していくことこそが重要といえます。

「自分たちに合ったプラクティスを学んでいく」この目的さえ叶えられるならどんなアジャイル手法を使ってもよいのですが、そのための方法として一番難易度が低いアジャイル開発手法がスクラムです。

「自分たちに合ったプラクティスを学習していくために必要なプラクティス集」といえるほど、必要な最低限のパーツはスクラムが用意してくれているので、まずはスクラムの型通りに進めるだけでも学習していくことはできます。

学習とは何か？

スクラムは「自分たちに合ったプラクティスを学習していくために必要なプラクティス集」ということはわかりましたが、そもそも学習とは何なのだろうかということが気になりました。

以前の記事でも取り上げた「学習する組織」では、以下のように定義されています。

「学習」というのは、知識を増やすという意味ではなく、人生で本当に望んでいる結果を出す能力を伸ばすという意味。それは生涯つづく生成的学習である。

つまり、「本当に望んでいる結果を出すために必要な能力を明確にし、伸ばすこと」が学習であると言えるので、スクラムチームにおいて本当に望んでいる結果は何なのか？を明確にすることが重要です。

スクラムチームが本当に望むべき結果は何か？

プロダクト開発でスクラムに取り組む場合、一番望むべき結果は「プロダクトビジョンの実現」です。
プロダクトビジョンの関係性はこの記事の図がわかりやすかったです。

企業ビジョンとビジネス戦略があり、それに紐づいてプロダクトのビジョン・戦略に落ちてきています。

スクラムガイド2020で追加されたプロダクトゴールは、プロダクトビジョンの具体的な踏み石です。実際にはスクラムチームはプロダクトゴールの達成を日々目指していくことになります。プロダクトゴールは、以下の条件を満たしている必要があります。

• ステークホルダーとスクラムチームで共有
• 1度に目指すものは一つ
• スプリントごとに近づいているかを検査
  • 主にスプリントレビューで検査
• 計測できなければならない

プロダクトゴールについては以下の資料が詳しいです。
https://www.docswell.com/s/nagasawa/5MLNJK-rsgt2022-product-goal

学習を進める前にリーダーがまずはチームを作る

スクラム云々の前にまずはチームビルディングを行い、チームを形成しましょう。
そもそもチームとは「ある目的を達成するために集まった集団」のことです。

最初のチーム形成をサボると開発は始まったものの、「何のために何でこのメンバーが集められたのかよくわからん」状態に陥り、とてもチームとは言えない状態のまま目先の改善だけスクラムでやっているという状況になっていってしまいます。

チームビルディングでやることは、以前の記事で紹介したGRPIモデルを参考にすると良いです。以下の4つの事項を上から順に決めていきます。

• Goal（目標）
• Role（役割）
• Process（手順）
• Interaction（関係性）

目標については前述した具体的なプロダクトゴールを設定します。次の役割についてはスクラムチームのメンバーの選定・各々のメンバーの役割・責任を明確にします。これにより透明性が担保されるので、タスクの分担が明確になり、各々の得意分野も認識でき、スクラムの価値観である尊敬のあるコミュニケーションをとりやすくなります。

目標と役割が明確になったら、スクラムの基本的なルールとプロセスを全員が理解していることも不可欠です。スクラムミーティングやスプリントレビューなどのイベントを通じて、継続的な学習と改善を図ることが求められます。

最後の関係性を作る活動を通じて、メンバー間の絆を深めることで強固なチームの形成に繋がります。

上記のチームビルディング活動は時間がかかるので1ヶ月くらいはそのための時間を見積もってスケジューリングをしておくと良さそうです。

まとめ

• スクラムは「自分たちに合ったプラクティスを学習していくために必要なプラクティス集」
• 学習とは「本当に望んでいる結果を出すために必要な能力を明確にし、伸ばすこと」
• スクラムチームが本当に望むべき結果は「プロダクトビジョンの実現」
• 学習を進める前にリーダーがまずはGRPIモデルでチームを作る

今回はスクラムを導入する前に抑えておくべき、結局スクラムとは何なのかについてまとめてみました。
プロダクトビジョンを実現するために、必要な能力を学習していくために必要なプラクティス集がスクラムであることがわかったかと思います。

では実際に学習を進めるために次はどんな手順（プロセス）でやっていくべきなのか？という話になります。経験主義でマネジメントしていくために3つの柱と5つの価値基準を機能させることに注視しながら、スクラムイベントを運営し、必要な能力を学習していく必要があるのですが、長くなるのでまた別の記事にしたいと思います。

スクラムについて悩んでいるエンジニア・EMの方の参考に少しでもなれば幸いです。