スクラムは簡単だけど難しい？

「スクラムは理解することは簡単だが、実践することは難しい」とよく言われます。事実、スクラムガイド^注1は20ページにも満たないボリュームで、フレームワークとしてはシンプルで理解することはそこまで難しくないかと思います。では、なぜ実践することは難しいと言われているのでしょうか。
実践が難しい要因はたくさんありますが、ここではよく聞く代表的な例を2つ挙げます。
1つめはマインドの変革が必要だということです。アジャイル・スクラム特有の考え方を表面上は理解できても、それを真に理解するには今まで持っていた考え方を変えることが必要な場合があります。とくに長くキャリアを積んで今までのやり方で成功体験を多く積み重ねてきたベテランエンジニアは注意が必要かもしれません。プロジェクトマネージャーを長く経験してきた方がスクラムマスターをやるとうまくいかないことが多い、という話もあります。今まで指示型で行動していたものを支援型に変える必要があるからです。
2つめは周りの環境がアジャイルに適していないことです。たとえばアジャイル案件のための予算を取るために綿密な計画が必要だったり、計画を変更することにステークホルダが強い拒絶感を持ったり……自分が変わるだけでは難しい環境面の制約もあるかもしれません^注2。
上記のような要因を解決せずにアジャイルを進めてしまって、期待していた成果が出ていないチームも多いと聞きます。

あるスクラムチームのアンチパターン

では、架空のスクラムチーム（下記のような設定）がスクラムを実践する中で直面するさまざまな課題を通して、アジャイルやスクラムのアンチパターンを見ていきましょう。

顧客は組織として初めてスクラムを適用します。期待（おもに顧客によるもの）と不安（おもにベンダーによるもの）が入り混じりながらプロジェクトは始まります。

アジャイルは魔法じゃない〜アジャイルに対する誤った期待〜

さて、スプリントはまだ始まっていませんが、チームを立ち上げるために開発者の教育や事前準備をスクラムマスター中心に行っています。
初期スプリントバックログの作成もあらかた終わりが見えてきました。スクラムチームでスプリントバックログの初期見積もりを行っているところに、あるステークホルダが様子を見に来ました。

ステークホルダ「最初のリリースはいつごろになりそう？アジャイルだから今までのプロジェクトより早いんでしょ？」
スクラムマスター「そうですね……（確かにアジャイルは速いと聞くからな）」

もう少し話を聞いてみないとわかりませんが、このステークホルダはスクラムについて誤解している可能性があります。
スクラムは優先順位の高いものからインクリメンタルに開発するため、システムすべてが完成していなくてもリリースすることが可能になります。そのため一部の機能をすばやくリリースすることは可能になりますが、開発そのものが速くなるわけではありません。

◆　◆　◆

なんとか第1弾リリースまでのスプリントバックログについては見積もりができたようです。

プロダクトオーナー「リリースまでにバックログがいっぱいあって、あまり余裕がなさそうだね。でも、途中で追加の要望が絶対に来ると思うから、頑張って対応しよう。変更を受け付けないのはアジャイルとは呼べないもんね」
スクラムマスター「そうですね……（確かにアジャイル開発宣言にそういう記述があったしな）」

アジャイル開発宣言^注3には「計画に従うことよりも変化への対応を」との記載がありますが、一方でアジャイル宣言の背後にある原則^注4には次の記載があります。

アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

ここでプロダクトオーナーが言っている「一時的に頑張る（稼働を上げる）」というのは「持続可能な開発」とは呼べません。上記の原則を守りながら、アジャイルが変更を受け付けることができるのはスコープ（やるべきことの範囲）の調整をするからです。
追加のバックログがある場合はリリースまでのスコープを調整する（優先順位の低いバックログをリリース対象から外す）か、スケジュールの再検討をする必要があります。
一般的にはスケジュールの再検討よりもスコープ調整を実施することが多いと思います。
ほかにも「アジャイルは魔法のようなプロセスで、早い・安い・うまい」といったような誤解をされていることがあるかもしれません。これらの誤解は早めに解いて、組織全体でアジャイルを実践していくことが大切です。

デイリースクラムはさっさと終わらせればよい？

成熟していないチームはデイリースクラムが長引くことも多いかもしれません。
デイリースクラムは問題を発見・共有することが重要で、問題を解決する場ではありません。デイリースクラムが長引くチームは問題の解決に時間をかけ過ぎていないか注意する必要があります。しかし、デイリースクラムが早く終わることは良いことと言えるのでしょうか。

◆　◆　◆

スプリントが無事に始まり、開発チームはいつものようにデイリースクラムを実施しています。

開発チーム「では昨日やったことと、今日やることを各自教えてください」
開発チーム「昨日やったことは××で、今日は△△をやります」
スクラムマスター「問題はありますか？」
開発チーム「とくにないです」
スクラムマスター「（進捗は芳しくないけれど、本当に問題はないのだろうか……？）」

このデイリースクラムは機能しているのでしょうか？デイリースクラムはスプリントゴールを達成するために再計画を行う場です。透明性のもとに検査を実施し、適応することを目的とします。
デイリースクラムが早く終わるチームは本来の目的を達成していないまま形式的にデイリースクラムを実施している可能性があるため、情報共有の際は各自が注意を払う必要があります。

スクラムをやっているからにはタイムボックスは絶対に守ってみせる！

スクラムの重要な概念にタイムボックスがあります。スクラムのすべてのアクティビティはタイムボックスで構成されています。たとえばタスクの集まりであるスプリントバックログにおいて、タスクごとに時間単位で見積もりを行い、タイムボックスを設けているチームは多いでしょう。
みなさんはタイムボックスを守れていますか？
「いや、なかなかできていない」という方もいるかと思います。どうせ守れないからといってタイムボックスに対する意識が希薄になってしまうことは良くありませんが、タイムボックスを厳格に守るというのは成熟したチームでもなかなか難しいと思います。見積もりの精度が原因の場合もあるでしょうし、実際に作業に着手してみたら想定していなかったことが起きてしまうといったこともよくあります。
ではタイムボックスはどう扱うのが良いのでしょうか。

〜開発中〜
開発チーム「（スプリント計画会議で見積もった時間には全然間に合わないな……フタを開けてみたらいろいろ調べなきゃいけないことがわかったから、これはしょうがないよね）」
〜デイリースクラム〜
開発チーム「昨日やったことは××ですが、まだ終わっていないので今日も引き続き実施します」
スクラムマスター「（大丈夫かな……この進捗のままだとスプリントゴールに到達しないのでは……）」

タイムボックスは気づきのきっかけであり、意識するところから始めることが大切です。スプリント計画会議で設定したタイムボックスどおりに進んだらスプリントゴールは達成できるでしょう。逆にそのタイムボックスが守れない場合は、それが積み重なるとスプリントゴールが達成できないリスクが上がります。
タイムボックスが守れないと気づいたときは再計画が必要なタイミングかもしれません。タイムボックスを超えているということは当初の計画からずれている、すなわち問題が発生している可能性があります。そのため、1人で抱え込まずチームとタイムボックスの超過を共有し、必要に応じて再計画を実施するなどの対策を検討してみましょう。これは遅くともデイリースクラムで共有されるべきですが、デイリースクラムまで待たずとも、日々の開発の中でコミュニケーションを取りながら、問題はいち早くチームに共有しましょう。

計画なんかいいから早く作ろうよ！計画はなくてもいい？

アジャイル開発宣言には「計画に従うことよりも変化への対応を」とあります。果たしてアジャイル開発には計画は不要でしょうか。

◆　◆　◆

第1弾リリースの目途も立ち、スクラムマスターがプロダクトオーナーに第2弾のリリーススケジュールの可視化を促しています。プロダクトオーナーは多忙でプロダクトバックログを書く時間がなかなか取れていないようです。

スクラムマスター「プロダクトバックログを記述して見積もりを実施して、リリースまでのスケジュールを可視化しませんか？」
プロダクトオーナー「綿密な計画よりも、これから起きるであろう変化に対応することが大事では？このタイミングで計画を立てても無駄になる可能性が高いのでは？」
スクラムマスター「確かに一理ありますね……」

アジャイル開発宣言をよく見ると「計画に従うことよりも」という記載がされているだけで、計画を立てることには言及していません。
アジャイルでも計画は大切です。計画がないと計画からどれだけ外れているか検査できません。検査ができないと次はこう改善しよう、といった適応もできません。検査と適応は変化へ対応するために大切なことです。また、アジャイルであろうとなかろうとプロダクトにはリリーススケジュールは付きものです。
ではアジャイルではどのようにリリース計画を立てるべきでしょうか。スクラムでは直近のバックログは詳細化しますが、未来のバックログは粗く作成します。粗いバックログに対してストーリーポイントを用いてすばやく見積もります。
リファインメントを継続的に実施してバックログを見積もりましょう。そうすればベロシティ^注5をもとにリリースの予測がつきます。スクラムではリリース計画を立てるための大きなコストは不要です。

〜スプリントプランニング〜
開発チーム「これはやってみないとわからないから計画しようがないね。見積もり時間は適当に入れておこう」
スクラムマスター「そうだね、しょうがない……のかな？」

スプリント計画でどこまで計画するかはバランスが重要です（これは経験的プロセス制御で学習していきます）が、果たしてどこまで計画するべきでしょうか。
わからないものをわからないままスプリントを開始するとゴールに到達できないリスクが上がります。スパイク（バックログを明確にするための技術的な調査など）を追加することも1つの手段ですが、小さなスパイクはスプリント計画会議で行っていくことも1つの手段です。ときには計画会議の場で一部コーディングをして開発チームで共通理解を持つことも、スプリントゴール到達の確実性を上げるには良いことです。
よく言われることですが、1つのタスクが1日の作業時間を超える見積もりは不確実性が高いとされます。1時間や2時間ぐらいに収まる程度に各タスクが細分化されていればリスクは十分に下げられるでしょう。

スプリント中に開発が終わらない！増員する？スプリント期間を延ばす？

みなさんのスクラムチームは毎スプリント、ゴールを達成できているでしょうか。とくにスプリント初期の段階ではUNDONEが出てしまうチームも多いのではないでしょうか。

〜スプリントレビュー〜
開発チーム「このバックログはUNDONEです」
プロダクトオーナー「最近UNDONE多いよね。もう少し人増やしたほうが良かったりする？」
スクラムマスター「ありがたいお申し出ですが、考えさせてください……」
〜レトロスペクティブ〜
開発チーム「スプリント期間がもう少しあれば終わったはずなんだけど……スプリント期間を途中で変更することはアリですか？」
スクラムマスター「あまりよくないと思うな……」

スプリント期間中に開発が終わらない場合に、「もう少しスプリント期間が長ければ」「もう少し開発人数が多ければ開発が終わったのでは」と考えることもあるかもしれません。果たしてスプリント期間を延ばす、開発要員を増員するといった対策は有効なのでしょうか。
スプリント期間を延ばしたら、延ばした分だけ開発量は増えるでしょう。その場合に以前と同じように計画をしていてはやはり時間が足りなくなり、同様の結果になってしまうのではないでしょうか？加えて、一般的に計画は期間が長ければ長いほど不確実性が高まりやすいため難易度が上がります。
開発要員の増員も一般的には失敗するケースが多いようです。「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」とブルックスの法則^注6で言われています。
アジャイルは従来型の開発とは異なり、コスト（要員数）とスケジュールを固定してスコープを調整することが一般的です。各パラメータを可変にするか、固定にするかを三角形で表現したものが図1の「鉄の三角形」です。

図1 鉄の三角形

スプリント中に開発が終わらない要因はいくつかあると思いますが、まずは無理のある計画をしていないか見直してみましょう。見積もりの精度はどうでしたか？計画できていないタスク（差し込みタスクや計画会議で洗い出しきれなかったタスク）はありませんでしたか？もしくはプロダクトオーナーがスコープを決めてしまっている（またはスコープへのプレッシャーが強くそれに近い状況の）チームはよくない状況です。これはスクラムマスターを中心に改善を図りましょう。
もちろん最初はうまくいかないことが多いです。改善を繰り返しながら計画の精度を上げていきましょう。

開発の進捗が悪いのはスキル不足のせい？
もしかして原因はバックログの受け入れ条件かも……？

スプリントのゴールを達成できない原因にはいくつかあると思います。技術的なスキルが不足していることが原因の場合もあるでしょう。しかしほかに原因があることも多いです。たとえばバックログの受け入れ条件（図2）などです。

図2 受け入れ条件の例

〜スプリント中〜
開発チーム「このバックログの受け入れ条件ってよく読むとあいまいだよね。たとえばこの場合はどうしたら良いんだろう？」
開発チーム「プロダクトオーナーに聞いてみようよ」
プロダクトオーナー「この場合は、えーっと、ちょっと待って。確認するからあとで回答するよ」
〜スプリントレビュー〜
プロダクトオーナー「この場合はどうやって表示されるの？」
開発チーム「このような表示になります」
プロダクトオーナー「うーん、それよりはこういった表示がいいんだけどなー」
開発チーム「（バックログの受け入れ条件どおりに作ったんだけどな。そんなこと書いてないじゃん）」

プロダクトバックログの出来はチームのアウトプットに大きく影響します。スプリントが始まったあとに受け入れ条件の確認をする必要がある場合はスムーズな開発を阻害します。またバックログの解釈に齟齬が多いと手戻りが発生する可能性があります。
もちろん最初はなかなかうまくいきません。バックログの書き方も日々改善していくことが大切です。

ベロシティが上がっているから生産性は高い！ホントですか？

ベロシティの増減に一喜一憂していませんか？
ベロシティが上がることは悪いことではありません。顧客からベロシティに対するプレッシャーがあるチームもあるかもしれません。そのようなチームはベロシティが下がることに敏感になっているかもしれません。

開発チーム「前のスプリントはたくさんの成果が出せたけど、今回はちょっと残念だったね」
開発チーム「でも平均するとベロシティは悪くないからリリースは何とかなりそうだね」
スクラムマスター「（本当だろうか……？なんとなく心配だな……）」

ベロシティは、高いことよりも安定していることが重要です。ばらつきがあるベロシティ（図3）は、次のスプリントで前のスプリントと同等のベロシティが出せるかは予測しにくいため、たとえばリリース間近の場合には不安を抱えながら進めることになってしまうかもしれません。対して、安定しているベロシティは予測可能性を高めます（図4）。

図3 ベロシティグラフの悪い例

図4 ベロシティグラフの良い例

ベロシティを上げるよりはベロシティを安定させることを目指しましょう。スプリント計画会議でリスクを取り去れておらず開発が計画どおりに進まない、バックログのサイズが大き過ぎて次のスプリントに持ち越してしまう、外部からのベロシティへのプレッシャーが強く無理な残業をしている、などベロシティが安定しないことにはさまざまな理由があるかと思います。
最初からベロシティを安定させることは難しいですが、徐々にベロシティを安定させていきましょう。

スクラムマスター「だいぶベロシティも高い位置で安定してきましたね」
プロダクトオーナー「そうだね、このチームの生産性は高いね！」

ところでこのプロダクトオーナーが言っている「生産性」とはなんでしょうか？ベロシティで測れるものでしょうか？
ベロシティとは開発チームがどれだけのストーリーポイントを消化できるかの指標です。たとえば価値が低いバックログをたくさん消化してもベロシティが高いことになりますが、それは果たして生産性が高いと言えるのでしょうか。
価値が高い順番にバックログは並んでいますか？価値をもたらすためにもっと効率的な実現方法（低いストーリーポイントで実現できる方法）はありませんか？
低いコストで高い価値を生み出すチームは生産性が高いと言えます。

最後に

いくつかのアンチパターンを見てきましたが、ここで挙げたのはあくまで一例で、スクラムを実践しているとこれ以外にもいくつもの課題に直面することでしょう。最初から正解にたどり着くことは難しいかもしれません（そもそも正解はない可能性さえあります）が、試行錯誤をしながら、少しずつでも日々成長していくことが大切です。
スクラムガイドはシンプルな記載ですが必要なことはすべて書かれているため、成長の過程で読み返してみると新しい発見があるかもしれません。
このアンチパターンでのスクラムチームは未熟な点が多く、とくにスクラムマスターは頼りないところがあったかと思います。
スクラムチームがスクラムのプロセスに対して頼りにするのはスクラムマスターです。スクラムマスターは本稿で紹介したアンチパターンを念頭に置きつつ、プロダクトオーナーやスクラムチームを正しい方向に導いていきましょう。

アジャイルコラム記事一覧

https://www.intellilink.co.jp/column/agile-devops.aspx