はじめに

アプリ開発支援部でiOS開発を担当している小鍋です。アジャイルトレーニングの参加を通して学んだことを整理するため、アンチパターンで指摘されている事例を収集し自分なりの理解をまとめました。自分の理解に伸び悩みを感じるときにはアンチパターンを学ぶことが有効であることが多かったので、今回もアンチパターンを収集してみることにしました。

なぜアンチパターン？

そもそもスクラムは会議体で構成された抽象度の高いフレームワークです。そのため、実際にスクラムを現場で使おうとするとそれが正しく運用できているのかわからないことがよくあります。

そこで、海外のサイトからアンチパターンを収集してそこからわかったことをまとめ、スクラムとはなんであったのかを再確認します。また、どのようにすれば正しい方向に導いていけるのか、若手の目線で考えてみました。

アンチパターンの紹介

今回はあえて英語の記事を元にアンチパターンを収集してみました。海外は日本よりもアジャイルが推進されていて、情報も進んでいると考えたからです。ぜひご自身の現場の状況がアンチパターンになっていないかチェックしてみてください。本記事では、Googleで"scrum anti patterns"と検索してヒットした以下のページを引用しています。それぞれのチェックリストの詳細は趣旨から外れるため付録にて解説しています。

No.	カテゴリ	パターン
01	プロダクトバックログ PO	PBIの記述が詳細すぎる
02	スプリントバックログ開発者	タスクの内容が理解できない
03	スプリントバックログ開発者	スプリントバックログの異端者（単独行動）
04	スプリントバックログスプリントゴール	金メッキ（スコープストレッチ）
05	スプリントバックログ PO	POがタスクを手放せない
06	スプリント	スプリントの長さが変わってしまう
07	スプリント SM	改善のためのスプリント
08	スプリント PO	スプリントキャンセルの誤用
09	スプリント PO	スプリントキャンセルなし
10	スプリントステークホルダー	スプリントの流れの中断
11	スプリントゴール	切迫感がない
12	スプリントゴールタスクボード	チケット番号でのやりとり
13	スプリントプランニング	プランニングが詳細すぎる
14	スプリントプランニングスプリントバックログ	内職（バックログにない作業）
15	デイリースクラム	デイリースクラムが習慣化されていない
16	デイリースクラム	デイリースクラムで問題を解決する
17	デイリースクラム	デイリースクラムの方向を見失う
18	デイリースクラムコミュニケーション	ステータスの報告のみ
19	スプリントレビュー	達成してないからレビューをしない
20	スプリントレビュー	デモンストレーションなし
21	スプリントレビュー	レビューでの不満
22	スプリントレビューコミュニケーション	デモをキャンセルする
23	スプリントレビュー PO	後回しなPO
24	スプリントレビュー PO	頑固なPO
25	レトロスペクティブ	レトロスペクティブがない
26	リファインメント	バッグログの改善をする時間がない
27	キャパシティ開発者	新メンバーによるブロック
28	パフォーマンス SM	リラックスできる時間がない
29	タスクボード	Work Item Age（作業項目の経過時間）が使われていない
30	タスクボード開発者	頻繁なサポートの不足
31	タスクボード開発者	タスクを容易くとってしまう
32	タスクボード開発者	WIP Limitがない
33	タスクボード PO	マイクロマネージメント
34	タスクボードステークホルダー	ボードが更新されていない
35	コミュニケーション	過激な議論（批判の多い議論）
36	コミュニケーション	パワーポイントによるプレゼン
37	コミュニケーション PO	POが呼ばれていない
38	コミュニケーション PO	POの欠席
39	自己組織化チーム	チームが従順すぎる
40	自己組織化開発者	いいとこどり（楽しい仕事だけに集中）
41	自己組織化開発者	全員が参加していない
42	不具合開発者	技術的に余裕な姿勢

アンチパターンを俯瞰してわかったこと

経験に学ぶというアジャイルらしいスタイルが行動になっていないケースが多い

遠い未来のことはわからない前提で行動できていないことがよく指摘されていました。しかしながら、アジャイルは「予測できないことは無理に予測しない」というだけで、直近に起こるできごとはしっかりと予測する必要があることです。このようなメリハリもスクラムでは要求されているのだと思います。

スプリントをただのタイムボックスとみなしてはいけない

キャンセル可能で検査可能なスプリントを「設計」することがキモになってくるのだと思います。スプリントゴールをインクリメントという形をとってユーザー目線で描かなければいけないのも、キャンセル可能にするための施策のうちの一つと言えるのではないでしょうか。

開発者の一つ一つの行動がプロダクトの成功に直接的に関係していることがわかる

まず、ボードの更新作業を怠らないことで、ステークホルダーからの信頼を獲得することができるようになります。まさにアジャイル開発は不確実性を許容する今までにない新しい取り組みで、ステークホルダーに信用してもらうことがスムーズなプロジェクト進行には必要不可欠です。また、POに正確なビジネス判断材料を提供することができます。スクラムチームで何か行動を起こすとき、どのような影響があるかを常に考えられると、問題提起や改善策の提案に繋げられるのだと思います。開発者は管理されているという意識をなくし、スクラムの運用に積極的に働きかけることが求められています。

スクラムはコミュニケーションを大事にしている

多くのアンチパターンはコミュニケーションの問題が検知ができていないことを指摘しているようにみえます。SMはコミュニケーションの問題をどうやって検知するか常に検討する必要がありそうです。また、コミュニケーションから生まれるよい結果を重要視しているようにも見えます。

スプリントゴールは他職種をつなぐ共通目標である

最後に見えてきたのは、「スプリントゴール」はチームにとって最もわかりやすい共通の目標だということです。チームは、ビジネス目標の達成や成果物の創出、チームのマネージメントといった、本来は異なる目標を持つ職種が集まってできています。スプリントという過程そのものが、新たにチームで課せられた共通目標だといえるのではないでしょうか。自分の職種にとって都合の良い動きをしないような仕組みづくりがスプリントにあったのだと改めて再認識できました。

若手エンジニアがスクラムに貢献できること

若手エンジニアは質問をするチャンスが比較的多いとされています。積極的にスクラムとは何なのか質問するようにしましょう。その質問によって、漠然とスクラムを理解している可能性や、スクラムに対する共通認識が持てていない可能性を指摘できるかもしれません。

スクラムは先進的だから楽しいというイメージにとらわれないようにしましょう。覚えることが非常に多く、スクラムイベントの意味などをしっかりと理解して自分がその一員であることを自覚する必要があります。自分がスクラムチームの一員として動けているのかを常に自問自答する必要があります。逆に言えば、どう動けばよいかわからなければスクラムについて調べると自然と解決するような気がしています。

主体性を求められることから、自分でとにかく行動するのが良いと勘違いしてしまいます。自分もそのような経験がありましたが、あくまでもチームメンバーのうちの一人にすぎず、チームのためにどう動けばいいかという目線で考える必要があるということを頭に入れておいてほしいと思います。

積極的にコミュニケーションをとりましょう。スクラムをはじめとするアジャイル開発は前提として積極的なコミュニケーションが求められます。ベテランの方はどうしても一人で完結してしまうことが多い気がしています。一人では何もできない若手だからこそ、積極的にコミュニケーションをしてチームの活性化に貢献することができるのではないでしょうか。

終わりに

アジャイルトレーニングでは、初めにアジャイルソフトウェア開発宣言の内容を深く掘り下げて学習しました。初めは、当たり前のことなのになぜここに時間を費やしているのだろうと疑問に思いながら受講していました。アンチパターンを通じてその意味がようやくわかったように思います。

スクラムをはじめとしたアジャイル開発のやり方はゴールではなく、あくまでも習慣の一つにすぎません。「そこからどうしていけばアジリティの高い開発ができるのか」をチーム全員で考えていくことがアジャイル開発のスタートなのだと、はじめて理解することができました。今後アジャイルについて勉強するときは、アジャイルソフトウェア開発宣言に照らし合わせながら勉強しようと考えています。

付録

アンチパターンの解説を付録にて行います。

(01) PBIの記述が詳細すぎる

仮にPBIが詳細に記述されていたとしても、今後のビジネスゴールの変更によって無駄になることがあります。またINVEST原則のNegotiableにもある通り、開発チームに考える余地を残すためにもPBIの記述が詳細になりすぎないようにする必要があります。

(02) タスクの内容が理解できない

チームメンバーがどのように働けばいいかイメージができていません。自走的な組織づくりに関係しているので改善が必要です。

(03) スプリントバックログの異端者（単独行動）

開発者がチームメンバーへの相談なしに勝手にスプリントバックログへ追加するのはよくありません。重大なバグが発覚したりしたら開発者同士の承認と補償の検討が必要です。

(04) 金メッキ（スコープストレッチ）

不必要なワークをスプリントバックログに加えてスコープを増やすのはよくありません。開発者とPOはプロダクトビジョンをはじめとした共通理解を生み出すことで信頼レベルを向上させることができるからです。仮にそのような問題が発生した場合は、POと開発者が積極的にコミュニケーションをとれるような施策を考える必要があります。

(05) POがタスクを手放せない

スプリントバックログに移ってからタスクを手放すことができないことがよくあります。要求のスコープを増やしてしまったり、受け入れ基準を変更したりしないようにしてください。スプリントバックログに移ってからは開発者の責任となります。もし変更したい場合のやり方は話し合って合意をとってください。

(06) スプリントの長さが変わってしまう

スプリントゴールを達成するために期限を伸ばすのではなく、達成できなかった問題の対処に尽力するべきです。（年末年始があるからスプリントが短くなるなどは許容されます。）

(07) 改善のためのスプリント

強化やバグ改善のためのスプリントを作られる状況はそもそもおかしいです。スプリントの目標は出荷可能な価値のあるインクリメントを提供することなので、バグや問題があるものなどはスプリントとして成立しないからです。このようなことが起きた場合は、機能横断的なチームになっていない、または期限に間に合わせるために品質を落として手抜きをした可能性もあるのでSMが調整していく必要があります。

(08) スプリントキャンセルの誤用

まず、開発者への相談なしにスプリントを止めるのはよくありません。何かしらのアイデアを持っているかもしれないからです。また、誤用が発生している時点でチームの協調性に問題がある可能性があります。

(09) スプリントキャンセルなし

ビジネスゴールがもはや達成できない時でもスプリントをキャンセルしないのはよくありません。例えば、経営陣などの判断でスプリントゴールが達成できなくなった場合は、キャンセルを検討する必要があります。

(10) スプリントの流れの中断

SMは、ステークホルダーにスプリントの流れを中断させてはいけません。

(11) 切迫感がない

スプリントの最後に価値を提供しないことが許容される場合は色々な問題があります。例えば、スプリントが単なるタイムボックスではないことがあまり理解されてない可能性が挙げられます。

(12) チケット番号でのやりとり

チケットをこなすだけの仕事になってる可能性が高いです。スプリントゴールを必ず記載してメンバーに意識させることが必要です。

(13) プランニングが詳細すぎる

プランニングで細かく決めすぎるのは時間の無駄になります。見積もりが大きすぎたり小さすぎたりするのは想定しておく必要があります。不確実な部分はあまり詰めず開発に専念した方がいいです。（但し、リスクがある場合は事前にスパイクなどで潰しておく必要があります。）

(14) 内職（バックログにない作業）

開発者がボードにないようなバグの修正やエラー修正、報告書の作成などをやってはいけません。POはROIや価値提供に責任を持っています。そのため、合意のない作業をすることがあってはなりません。スプリントプランニング時になぜこの取り組みについて言及できなかったのかを確認したほうがよいです。チーム内の対立がある可能性があるからです。

(15) デイリースクラムが習慣化されていない

デイリースクラムは同じ方法で同じ場所で起こらないといけません。あくまでも検知が目的だからです。

(16) デイリースクラムで問題を解決する

デイリースクラムの時点で問題を解決しようとしてはいけません。デイリースクラムは毎回同じことをする必要があるからです。

(17) デイリースクラムの方向を見失う

デイリースクラムはあくまでもプロジェクトがまだ軌道に載っているかを報告するためにあります。

(18) ステータスの報告のみ

デイリースクラムはあくまでもコミュニケーションの場であることを意識する必要があります。POやSMへ共有することを意識するとよいかもしれません。

(19) 達成してないからレビューをしない

結果が達成されたかされていないかに関わらず、レビューは行わなければなりません。「終わってないのでレビューはやりません」という状況はよくあるので注意が必要です。

(20) デモンストレーションなし

改善すべき点がないと信じて、やろうとしない傾向があります。

(21) レビューでの不満

レビューの目的が「なにがなくて、なにが達成できてないか」を伝えるものになってしまっているのはよくありません。あくまでも改善するという意識で挑んでください。

(22) デモをキャンセルする

開発のためには時間がもっと必要だと考えてキャンセルする傾向にあります。コミュニケーションや経験主義を放棄した考え方になっている可能性があります。

(23) 後回しなPO

バックログの受け入れをスプリントの終わりまでやらないのはよくありません。アイテムが終了したタイミングですぐに受け入れをチェックすることで、スプリントゴールの到達を確実にするべきです。

(24) 頑固なPO

受け入れ基準に合わせすぎて頑固になってしまうのはよくありません。「受け入れ基準が達成できなかった」という問題が明らかになっただけです。これを現実として認識するべきです。

(25) レトロスペクティブがない

なにも改善することがないからレトロスペクティブをやらないという状態はよくありません。常に改善することがあるはずなので、それを旅のように探していくのがアジャイルです。

(26) バックログの改善をする時間がない

バックログのクオリティは常に高くする必要があります。アジャイルの利点を享受するためには必要です。5~10%くらいはバックログの改善に当てるべきです。

(27) 新メンバーによるブロック

新メンバーが来ることで生じる作業などを考慮してキャパシティを調整する必要があります。

(28) リラックスできる時間がない

開発者は20%くらいの余裕を持っておくべきです。そうでない場合、パフォーマンスが下がり、共有や協調、緊急タスクへの取り組みがなくなるリスクがあります。また、これを達成するためにはSMの積極的な支援が必要です。

(29) Work Item Ageが使われていない

Work Item Ageとは作業開始からの経過日数のことをいいます。何らかの理由でブロックされている作業を検知するために使います。

(30) 頻繁なサポートの不足

サポートが必要であると表明なしに２日以上かかっている場合はサポートしなければなりません。動いていないタスクをタスクボードに赤い印でマークするのはこのようなサポートのためにあります。（Work Item Age）

(31) タスクを容易くとってしまう

実際はそんなに簡単にはとれないということが多いはずです。直近のスケジュールはきちんと把握して、休暇や健康面など色々な問題を考慮しておくべきです。

(32) WIP Limitがない

WIP(Work In Progress)の数の制限を作ることで、開発者がマルチタスクになりすぎるのを防ぐことができます。フロー理論に基づき、開発者が集中できる状態を作ることが重要です。

(33) マイクロマネージメント

POが開発者にタスクを割り当てる状況を作ってはいけません。開発者のなかでうまく自己組織化させるためにSMがいます。

(34) ボードが更新されていない

ボードのチケットが更新されていないと、結果的に開発者が集中できなくなり、モチベーションが下がり、プロジェクトの進行において間違った情報を提供することになります。タスクボードはステークホルダーを含むスクラムチームのコミュニケーションの一部であることを忘れてはいけません。ステークホルダーの信頼を勝ち取るために更新し続けなければ、ステークホルダーがスクラム以外の方法で対策を講じてくる可能性があるからです。