「問題を早期に発見するため」という観点でのScrumの説明

Scrum は非常に色々な側面をもっていて色々な語られ方もしますが、今回は自分がスクラムマスターとしてお仕事させていただいている中で一番大事にしている「問題を早期に発見するためのフレームワーク」という観点で紹介してみたいと思います。

＊＊＊

Scrumとは？

一言で「問題を早期に発見するためのフレームワーク」と言ってみます。

もちろん他の説明の仕方もありますが今回はここに絞ります。 わたしの中で Scrum が一番大事にしているのはココかな？というお気持ちです。

アジャイルとかScrumとか言って勘違いされそうなことなのですが「速くなる・生産性が上がる」とか「より価値あるプロダクトになる」みたいなことは Scrum の結果必ず得られるものではないです。 Scrum はあくまで「問題を発見」するためのフレームワークです。

ここで誤解のないように言いますが…… Scrum の目的には価値の高いプロダクトを作ることが含まれますし生産的な開発も目的としてあります。ただ Scrum という手法の中で「どうやって価値を高めるか？」「生産性を上げるか？」という具体的なやり方には触れません。それはそういう問題のほとんどがドメイン特有の問題であってベストプラクティスを語ることができないからです。何か提言してみてもいいかもしれませんが、それはひょっとすると別のドメインでは価値や生産性を "下げる" バッドプラクティスになってしまうかもしれないので Scrum では触れていないのだと思います。逆に触れてもいい普遍的なものは Scrum の中で語られている気がします。

もう1つ補足で…… 手法を変えたからって急に価値や生産性が上がったり開発速度が上がるなんてことはありえません。ウォーターフォールでも Scrum でもやるべきことの総和に違いはなく、要件定義も設計も必要ですしコーディングもテストも必要です。手法を変えるだけで作業の総和や人のスキルが急に変わるなんて普通に考えてあり得ないです。過度な期待はやめましょう！！

「問題を発見する」だけのフレームワークであったとしても落胆しないでください！ 結果的に「価値向上」や「生産性向上」とか「チームビルディング」とかの効果がでる可能性は高いのでご安心ください。

なぜかというと。「問題を発見する（問題に気づいてしまう）」ことで（善意ある開発者であれば）必然的に改善を繰り返していくことになりプロダクトの価値は自然に上がります。（問題に気付かなければ良くしようがありません）

そして問題発見が早ければ早いほど手戻り少なく改修が可能です。（リリース直前で見つかったバグなおすのは超大変です）

チームビルディングについては 、発見した問題を遠慮なく言い合えるには心理的安全性がベースになるからで、発見した問題を包み隠さず言えるために作り上げなければいけないものだから作るのです。（怒られるの嫌だな…ではせっかく気付いた問題も闇に葬られてしまいます）

わたし自身が Scrum で大事だと思っていることをベースに Scrum とは何か？ を少し違った視点で説明してみました。