「自分たちは、スクラム開発をうまく実践できていないのではないか」
と思ったことがある方、少なからず多くいるではないでしょうか。
自分も何度か悩んだことがありますし、今でもたまに思います。
でもよくよく考えたら、実はそれなりにスクラム開発を実践できている場合もあります。
つまり、スクラム開発ができていない、と勘違いをしている可能性です。
また、本当に実践できていない場合ももちろんあります。
頭の整理に、この記事が役に立てば幸いです。
概要
アジャイル開発とは、
「事前にすべてを正確に予測し、計画することはできない」という前提の基で、
プロダクトを作り、成果を最大化するために、手段を体系化したものです。
アジャイル開発には、以下など様々な種類があります。
- XP（エクストリームプログラミング: Extreme Programming）
- FDD（機能駆動型開発: Feature Driven Development）
- DSDM（動的システム開発手法: Dynamic Systems Development Method）
今回は私の経験上の都合で、アジャイル開発の中でもスクラムにPickupして話を進めます。
ただスクラム以外にも当てはまる話もあるかもしれません。
この記事では、
- スクラム開発の概要
- なぜスクラム開発が実践できていないと感じてしまうのか
- スクラム開発をうまく実践できているとは
- スクラム開発が本当にできていない場合
について記載します。
もちろん、自分はスクラム開発の先導者ではないので、
様々な文献で述べられていることと、自分の解釈を述べる形式で上記について記載します。
スクラムとは何ぞ？
先にスクラムについて簡単に記載します。
スクラムとはアジャイル開発の一つで、
常に進む方向を調整しながら目的を達成できるプロダクトを作るために、
全員が一丸となって行うべき作業、会議、成果物を定めたもの。
スクラムには以下の特徴があります。
- 要求を常に順番に並べ替え、その順にプロダクトを作ることで成果を最大化する
- 固定の短い時間に区切って、作業をする
- 現在の状況や問題点を常に明らかにする
- 定期で進捗はどうか、プロダクトは正しいか、仕事の進め方に問題ないか確認
- やり方に問題があったりうまくできる方法があったりすれば、やり方を変える
- チームで最低限のルールだけを定める。ルールはチームごとで決める
スクラムの全体像について、図にすると以下のように表現できるかと思います。
※参考: SCRUM BOOT CAMP THE BOOK
スクラムでは決められていないこと
スクラムの特徴にもありますが、
- チームで最低限のルールだけを定める。ルールはチームごとで決める
スクラムで決めきれていないルールは、チームごとに決めるよう推薦されています。
ではチームで決めなければならないものは何なのか。
スクラムに関係する開発体制で、チームで決めなければならないことの一部を記載します。
- プロダクトバックログの項目の書き方・粒度
- スプリントバックログの項目の書き方・粒度
- 完了の定義
- ベロシティの粒度
- 優先順位の付け方
- コードの書き方
- テストのやり方
- ふりかえりの方法
- etc.
もちろんこれに加えて、
- プロダクトオーナーを担う人
- スクラムマスターを担う人
- プロダクトバックログの具体的な項目
- スプリントバックログの具体的な項目
- 実装内容
- テストケース・内容
- etc.
なども、もちろん決めなければなりません。
スクラムで決めきれていない、決めなきゃいけないモノは非常に多いです。
正解病とやら
スクラムで決めきれていないこと（＝正解がないこと）を自分たちで決めて実践するのが不安。
このような状態は、「正解病」に近い状態です。
正解病とは、どのような課題にも正解を求めてしまうことです。
正解を求めるあまり、正解がなければ自信をなくしたり不安になったりします。
参考: http://musubiomusu2.blogspot.com/2018/06/blog-post_16.html
これは日本人に多いもので、自分も多少正解病だと思います。
ただ、逆に正解がないもので最初から自信を持てるのは、
スーパーポジティブ人間とかだと思うので 笑
正解病の人の方が大多数なのかもしれません。
さて、スクラムでは、バックログの書き方や粒度、完了の定義など、
決め方についてはある程度方法論で提示してしますが、
正解はありませんし、短期間で決めることは難しいです。
この正解がないものに取り組んでいるので、
「自分たちは、スクラム開発をうまく実践できていないのではないか」
など不安になるのは、自然なことだと思います。
仮説思考とやら
この不安を取り除くために、一般的には仮説思考が有力です。
要はスピード＞正確性でなるべく早く仮説を持って作業を確認しながら進めることが、正確性＞スピードで最後まで答えが出ないという進め方よりも効率的に作業を進められ、ビジネスにおいては圧倒的に有利な場面が多いということです。
参考: https://scienceshift.jp/method-of-thinking-practical-second/
先に述べましたが、アジャイル開発には大前提の仮説があります。
「事前にすべてを正確に予測し、計画することはできない」
「なかなか反省点や課題が減らない、スクラムをうまく実践できないのでは」
とスクラムの中で感じるのは、アジャイルさんの想定内です。
また先に述べたように、スクラム開発には以下の特徴があります。
- 現在の状況や問題点を常に明らかにする
- 定期で進捗はどうか、プロダクトは正しいか、仕事の進め方に問題ないか確認
- やり方に問題があったりうまくできる方法があったりすれば、やり方を変える
反省点や課題がなかなか減らないなどの問題は、スクラムにおいてはあらかじ予め想定されていることです。
スクラム開発で大事なのは、問題点や反省があったときに、それを課題だと認め、改善することだと思います。
その課題発見を仮説検証で見つけることが出来れば、短いスパンで課題発見から修正まで実現することができます。
スクラム開発をうまく実践できているとは
以下ができていれば、スクラム開発をできていると考えて良いと、自分は思います。
- 反省点がありながらも、スプリント期間ごとでリリースできていること
- スプリントサイクルを回すたびに、反省した点を改善できていること
MTGなどで反省点があったり、予期せぬ事態が起きたりしても、
次のスプリントでFix出来ていれば、十分スクラム開発をうまく実践できていると思います。
スクラム開発が本当にできていない場合
以下の場合は、たしかにスクラム開発ができていない気がします。
- スクラムで決められているルールを実践できていない
- スプリント期間が毎回異なる
- デイリースクラムを週一で行う
- プロダクトバックログがない
- etc.
- 反省点を修正できない
- デイリースクラムが毎日長くなってしまうのを直せない
- 毎スプリント、リリースが遅れる
- プロダクトバックログの粒度に不満を持つメンバーが常にいる
- 作業の進捗がいつも分からない
- etc.
スクラム開発ができないのは、単純にふりかえり力がないこと
（課題を課題のままに放っておく、課題を修正できないなど）
が原因かもしれません。
以下の記事では、はっきりと人材の問題と記載しています。
それも一理あるかもしれません。
参考: https://magazine.techcareer.jp/career/skill-up/7511/
スクラム開発で失敗を防ぐ方法は、究極的にして、唯一の答えは人材レベルを上げるしかありません。
「我々は完璧にスクラム開発をできている」の不安
本当に完璧にできている場合もあると思います。
しかし、スクラムで決めきれていないルールを、
自分なりに「スクラムのルール」として定義している場合は不安です。
自分の場合、最初にスクラム開発を行っていた現場では、
スプリント計画、スプリントレビュー、ふりかえりは別々のMTGで行っていましたが、
別の現場に行った際、全て同じMTGで行っているのを見て、
「それはスクラムじゃないだろう！」と、声に出さずに思いました。
でも時間ごとに区切ってそれぞれのMTG行っていましたし、
全MTGを同じ日にやってはいけないというルールはスクラムにありません。
冷静になった時に、「スクラムのMTGはそれぞれ別のタイミングで行う」というのは
自分の中での思い込みのスクラムルールであること気付きました。
声を出さなくて良かった。笑
このように、「実は思い込みのスクラムルールだった！」
と思う機会があった人も、少なからずいるのではないでしょうか。
とある現場から別の現場に移動して再度スクラムを行う場合、
「スクラムのルール」の線引きに気をつけなければならない、といえと言えると思います。
まとめ
スクラムを実践する力って、結局ふりかえり力（反省点を理解して改善する）に尽きる、
と思います。もちろんそれって全然簡単ではないと思いますが。