はじめに

スクラム開発について体系的に学習を行った。
スクラム開発についてまとめられた記事はたくさんあるので、
ここでは筆者が学習時に印象に残ったことなどをつらつらと書いていきます。

参考

最新のスクラム公式ガイド（2020/11/30現在）
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

SCRUM BOOT CAMP THE BOOK【増補改訂版】スクラムチームではじめるアジャイル開発
https://www.amazon.co.jp/SCRUM-BOOT-CAMP-BOOK-E3-80-90-E5-A2-97-E8-A3-9C-E6-94-B9-E8-A8-82-E7-89-88-E3-80-91-E3-82-B9-E3-82/dp/4798163686/ref=dp_ob_title_bk

スクラム開発とは

アジャイル開発手法の一つであり、スクラムチームという10人以下のチームを組み、スプリントという決められた期間に決められたルールに沿って、プロダクトとチームの改良を行っていく開発フレームワーク

実際に勉強してみて思ったこと

やること自体はとてもシンプル（PDCAサイクルのよう）

実際にスクラム開発を体系的に学んでみると「思ったよりもとてもシンプルだな・・・」という印象を受けました。
一つのスプリントの中で、プロダクトバックログという作業リストの中から実現可能なものをスプリントプランニングにて選定し、デイリースクラムで各作業の状況の確認をし、スプリントレビューにて成果物を確認し、レトロスペクティブにて振り返りを行う・・・やることとしてはこれの繰り返しとなっています。
これは、PDCAサイクルに似ていると感じ、システム開発以外のシーンでも、このスクラムというフレームワークは応用ができそうな印象を受けました。

引用元：https://www.fujitsu.com/jp/group/fst/about/resources/featurestories/about-agile-02.html

「柔軟に対応」するための「厳格」なルール

スクラム開発（というかアジャイル開発）のメリットといえば、仕様の変更などに柔軟に対応できる点にあるのですが、スクラム開発自体のルールについては厳格であると感じました。具体的には

スプリントの期間は1ヶ月以内で決定を行い、決定した期間を延長することはできない（1週間で決めたけど今週だけ２週間で・・・はだめ）
デイリースクラムは15分で実施し、延長してはならない
スクラムイベントの省略はできない（今週はレトロスペクティブはやらない・・・はだめ）

などがある。

これらのルールは、一見厳格であると感じましたが、なぜこういったルールが定義されているかを考えると、それは「柔軟に対応」する為であることに気付きます。

例えば仮にスプリントのイベントの中からデイリースクラムをなくした場合、プランニングにて設定したスプリントゴールにむけて順調に進捗しているかが分からず、スプリントレビュー時に「実はこれこれで詰まってしまってできてません」といった状況になりかねません。
きちんとデイリースクラムを行っていれば、作業に詰まってしまっている開発メンバーを検知することができ、協力や対応を行うことができる。そのためにもデイリースクラムは必ず実施する必要があるのです。

また、１週間で決めていたスプリントを「今週のスプリントは1週間じゃ終わらなさそうだから2週間にしようか」という特例を許してしまうと、スプリントのゴールまでの期間が不透明になってしまい、開発リズムの乱れや、咄嗟のリスクへの対応が十分に行えなくなってしまうことにつながります。
上記のことから、「柔軟に対応」することは「厳格」なルールの元で初めて成り立つ物であるのだと感じました。

「チームで開発する」が体現されている

スクラム開発での開発チームの特徴として「自己組織化」があります。これは、開発の進め方をチームで決めて、チームで責任を持って開発を行うことで、チームの主体性向上、およびチームの開発能力の向上を促進することができます。

引用元：http://agile.blog.jp/agile_scrum/14970332.html

また、スクラム開発における開発チームは「機能横断的」なチームであるので「自分はフロントエンドエンジニアだからサーバサイドの実装はやらない」などの、肩書や専門分野に囚われなず、どのメンバーも複数のことができることが望まれます。

この「機能横断的」なチームを実現することで、チーム全体のレベルアップ、および、どんな作業でもメンバー全員が責任を持って作業を行うようになると思われるため、先述した「自己組織化」へとつながるのではないかと感じました。

これは、開発以外でも同じことが言えると思います。
私は趣味でアイスホッケーというチームスポーツをやっているのですが、個々の能力は高いが「自分はフォワードだから守備はやらない」や「自分はシュートは苦手だからパスだけ出そう」という思考を持った選手が集まったチームよりも、個々の能力は平均的だが、全員で攻め、全員で守り、苦手なプレーでも状況に応じて実行するチームの方が、好成績を残している印象があります。

引用元：http://shabonyu.com/pyeongchang2018_icehockey/

まとめ

スクラム開発の学習を通して感じたこととしてまとめると
「チームが最大のパフォーマンスを発揮し、チーム、プロダクトが成長するための仕組み」
です。
また、ここで言う「チームの成長」と「プロダクトの成長」はイコールであり、チームが大きく成長すると、同じだけプロダクトも成長すると考えています。

今回は、スクラムマスターやプロダクトオーナーなどのロールや、実務のケースに照らし合わせた事象などについて記載しなかったので、次回以降追記していく。