概要

スクラムってとりあえず開発フローを1スプリントに区切ってサイクル回せば良いんでしょ、と思っている人、いませんか？
形から入ることが悪いことではありませんが、目的を忘れてしまうと碌なことがありません。

この記事では、なぜスプリントがうまく回らないのかについて、私がエンジニアになってから約5年間で経験・勉強してきたことをベースに考察していきます。

もしかしたら間違った解釈や反対意見もあるかもしれないので、その時はコメントで優しく教えてください

もし今のプロジェクトでスクラムが上手く回っていない場合、その解決のヒントになれば幸いです。

前提

スクラムの定義

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである
簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである

プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに
並べる

スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える

スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調
整する。

繰り返す

スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。

引用：スクラムガイド

私自身、スクラムを理解できている訳ではありませんが、最も重要なのは以下の部分だと考えています。

スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている

こう書かれている通り、スクラムという方法論を実現するための必要最低限しか定義されていないため、その穴を埋めるのはスクラムを実践したチームの経験です。
様々なプラクティスはあれど、チームの課題に対する答えはチームの中にしか存在しないということです。

方法論
スクラムは方法論です。プラクティスとは違い、学術的に有効性が証明されています。

スクラムの効果を最大限発揮するために、さまざまな仮説 → 実践 → 改善を繰り返すことでチームが成長する、という構造になっていると考えています。いわば、チームを成長させるための強制ギプスのようなものでしょうか。
初めからうまくいくようにはできておらず、形式的にスクラムを始めたからといって、チームが成長するプロセスを踏まなければうまくいくわけがないということです。

デイリースクラムは15分と定められていますが、最初から15分に収められるわけはなく、どうやったら15分で必要な会話をすることができるか、を考えて実践することに意味があります。

なぜうまく回らないのか

ここからは、スクラムが上手く回らない例としてよく聞く問題について考察していきます。

1スプリントが短いウォーターフォールになっている

スクラムガイドにおいて、スプリントゴールを達成するために必要なスクラムイベントとされているのは以下の４つです

スプリントプランニング（1スプリント1ヶ月の場合、最大8時間）
デイリースクラム（15分）
スプリントレビュー（1スプリント1ヶ月の場合、最大4時間）
スプリントレトロスペクティブ（1スプリント1ヶ月の場合、最大3時間）

これ以外は定義されていないため、どう進めるかはチームの方針次第です。
ただ、もしスクラムを実践する目的から乖離したプロセスを踏んでしまっている場合は、上手くいかないかもしれません。

その一例が、1スプリントが短いウォーターフォールになってしまう現象です。

スクラムの目的は、スクラムの定義の一番最初に書かれていましたね。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

ここでいう複雑な問題というのは色々あると思いますが、よく言われるのは以下ような問題です

最初から全ての要件が決まっていない（顧客自身も何が欲しいか完全には分かっていない）
途中で要件が変わる（市場、競合、技術の変化など）
技術的な不確実性がある（どう作ればいいか、やってみないと分からない）

このような問題に対して、ウォーターフォールのように「最初に完璧な計画を立て、その通りに実行する」というアプローチは機能しません。なぜなら、その「完璧な計画」は、作り始める頃にはもう古くなっているからです。

よって、スプリントをウォーターフォール化するアプローチは非常にスクラムと相性が悪いと言えます。

さて、ここからはスプリントがウォーターフォール化している具体的な例を見ていきます。

PBI（プロダクトバックログアイテム）が技術レイヤーごとに分かれている

PBIの単位が、DB設計、バックエンド実装、フロントエンド実装、テストなどに分かれていると、開発フローに問題が起きます

よくある開発フロー
DB設計 → バックエンド実装 → フロントエンド実装 → テスト

このように、作業がリレー方式になってしまうという問題です。
なぜ問題なのか、それは、バトンが渡ってくるまで別レイヤーの実装者に待ちが発生してしまうからです。
スクラムでは、スプリントが開始したら、全員が価値を生み出す作業（PBI）に取り組める状態となっていることが理想です。
それなのに、PBIがレイヤーごとに分かれてしまっていては、本末転倒です。

そもそもこのPBIの切り方は、開発フローに影響してしまう以前の根本的な問題があります。
PBIというのは、「ユーザーにとっての価値」の単位であるべきです。（例：ユーザーがログインできる）
それなのに、PBIを「DB設計をする」のような単位で切ってしまうと、それを達成してもユーザーにとっての価値とはならない（ユーザーから見れば何も変わっていない）ので、意味のないPBIとなってしまいます。

ユーザーの価値単位でPBIを切ることをvertical slice（縦切り）と言います。

「DB設計をする」というPBIを達成してユーザーに提供する試み
- → ケーキを食べたがっているユーザーに対してホールケーキの一番下のスポンジだけを薄く切って提供しようとしている状態（ケーキの横切り）
「ユーザーがログインできる」というPBIを達成して提供する試み
- → 薄くはあるものの、1ピースのケーキを提供しようとしている状態（ケーキの縦切り）

例で挙げた「ユーザーがログインできる」をPBIにしても、1スプリントで達成できそうになくて困ってしまう場合があります。
そういった状況でも、そのPBIを技術レイヤーごとに分割してはいけません。
そうではなくて、「ユーザーがログイン画面を閲覧できる」や、「ユーザーがメールアドレスを入力できる」のような、機能を減らしたPBI（さらに薄い1ピースのケーキ）に分割するべきです。

ここで勘違いして欲しくないのですが、1ピースのケーキを一人で作り上げなければならないというわけではありません。
1ピースのケーキは価値の単位なので、それを作り上げるために各領域（スポンジ、クリーム、イチゴ）の開発者が協働することは全く問題ありません。
最初からフルスタックエンジニアがいなければスクラムが回らないということはないのです。（全員が別の領域に染み出して経験を積んでいくことは大切）

ここで気になるのが、たとえ1ピースを薄くしても、スポンジから作っていかなければならないのでは？結局バトンを渡す形の開発になるのでは？というところでしょうか。

長い間ウォーターフォールの環境で働いていた方は頭を切り替える必要があります。
各領域の開発者が同時に価値生産をスタートさせるためには、計画の段階である程度の認識合わせをしておく必要があります。

例）「ユーザーがログインできる」のPBIを進める場合
DBについて：
userカラムにはid, email, password_hashが最低限必要だよね

APIについて：
ログインAPIのインプットには、email、passwordが必要そうだから、フロントエンド側からは以下のjsonを送るよ

{
  "email": "user@example.com",
  "password": "mysecretpassword123"
}

じゃあ、APIのレスポンスでアクセストークンを返すね

{
  "token": "XXXXXXXXXXXXXXXXXXXXXXXXXX"
}

このように、インプットとアウトプットの認識を計画段階で擦り合わせておくだけで、どの領域でも同時に作業を進めることができます。
後のことは各領域で考えれば作れるからです。実際に接続可能になるまではモックで作業を進めれば良いのです。
考慮もれが見つかったら、都度会話して方針を決めれば良いのです。
全員で同時に作業を進めるために、必ずコミュニケーションをとってください。

最初はお互いの領域に対する知識が少なく、苦労するかもしれません。
コミュニケーションをとりながらお互いの領域に染み出していくことで、計画時のコミュニケーションスピードは加速していくはずです。

開発者とQA担当者が分かれている

これも技術レイヤーの話に強く関連します。
開発とQAが分断されていると、同じように待ちが発生するという点で非常におすすめできないのですが、もっと具合の悪いことがあります。

開発 → QAの順番でフローが進んだ場合、QAはスプリントの後半（もしくは終盤）に行われることが多いと予想されます。
これはどういう状態かというと、QA段階になるまでバグが発見しにくいということです。
さらに、スプリント終盤に重大なバグが発見された場合はどうなるでしょうか？
修正が間に合わず、PBIを完了できないままスプリントを終えるしかなくなってしまいます。

スクラムにおいて、プロダクト品質に責任を持つのは開発者です。
QAチームという外部のチームではありません。
開発チームとQAチームが分かれているメリットは正直ないと思った方が良いでしょう。

スクラムでは、プロジェクトを始める際にまずDoD（Definition of Done：完成の定義）を決めると思います。
これは、製品が完成されている（リリース可能な品質である）ことの基準を決めるということです。

ここで間違えて欲しくないのは、完成の定義は、常に守り続けている状態でなければならないということです。
最後に達成すれば良いというものではありません。
何故なら、インクリメントするごとに常にリリース可能な状態である必要があるからです。

食品工場で例えれば、最後に検品して基準をクリアしていれば良いのではなく、あらかじめ滅菌室を作って最初から菌が入り込まない仕組みを作っておきましょうということです。
最後に全ての缶詰を開けて検品するわけにはいかないので、もしかすると漏れがあるのに気づいていないだけかもしれません。
そうならないように、あらかじめ品質が損なわれる可能性を排除するための基準を設けて、常にその状態をキープしながら製品を作る必要があります。

この基準を作るのはスクラムチームで、品質を担保する責任は開発者にあります。
だから、開発者自身が常に品質を担保する体制を整える必要があるのです。そこに外部のチームを入れる必要はありません。
開発者自身が常にQAを行えている状態で開発を進めてください。

代表的なソリューションとして、CI環境を構築する、セキュリティ監視・ログ監視ツールを入れる、などがあります。

個人的に品質を担保する上で大切だと思っていることは、自動テストを書くことです。
さらにいえば、テストファーストで開発することです。

これであれば、例えばDoDにて、テストカバレッジを80%以上にキープするという項目があった時、先に書いたテストが通るようにコーディングすることで、理論上カバレッジは100%担保できるからです。（現実的には100%は難しいかもしれないが、80%は担保できる）

テストの重要性については過去に記事を書いているので、詳しく知りたい方はぜひご一読ください。

ここで何を言いたかったかというと、品質の担保はQAチームに任せず自分たちでテストを書くなりして担保してくださいということです。
もちろん導入コスト、学習コストはかかりますが、長期的に見て最初のコストなど比べ物にならないほどの生産性が生まれます。

テストを書くことでプロダクションコードをアグレッシブに変更、リファクタリングできるようになり、テストしやすい綺麗なコードを書くことができるようになっていきます。
デグレチェックが常に可能になるため、品質が担保されるようになります。コンフリクト解消後の事故も確実に減っていきます。

スプリントの最後に全てのマージ作業が発生している

これも技術レイヤーの話に関連しますし、QAの話にも強く関連します。
ウォーターフォールでありがちなのが、タスクが全て完了するまでmainブランチにコードがマージされないという事象です。

スクラムでは、どれだけ早く価値を届けるかを考えていかなければなりません。そのためには価値単位を細かくし、早くフィードバックを受け取る必要があります。
何故早いことにこだわるのか、それは変化に適応するためです。

書いたコード（仕様）は、その時点ですでに古いものに変わっています。
であれば、できるだけ細かく繰り返しフィードバックを受け取ることで常に情報を更新し続け、変化に順応していく必要があります。
フィードバックを受けるまでのリードタイムが長ければ（= 作業量が多ければ）、それがもう古いと判断され、変更することになった場合大きな手戻りとなってしまいます。

だからこそ、インクリメントは細かく出していく必要があります。
タスクが全て完了するまでmainブランチにコードがマージされないという事象は、フィードバックを受けるまでのリードタイムが長いということに他なりません。

正直にいえば、スクラム開発とGitflow（長期ブランチ戦略）は相性が悪いと考えています。
スクラムをガチでやるならば、トランクベース開発（mainに直push or 短期ブランチ戦略）を目指したいところです。

これを言うと大概異端扱いされるのですが、もちろん大前提としてトランクベース開発を問題なく回すには、色々な要素が必要です。例えば、強固な自動テスト、高速なCI/CD、ペアプロやモブプロの文化、シンプルに技術力も必要です。
適切な運用ができず、品質を担保できない状態でトランクベース開発をしてしまったら大崩壊します。
ですので、現実問題トランクベース開発ができるチームというのは非常に少ないと思われます。

トランクベース開発
メインブランチ（トランク）に対して、開発者全員が頻繁に小さな変更を直接マージしていく開発手法です。
長期間存在するフィーチャーブランチを作らず、常にメインブランチを中心に開発を進めます。

小規模チームの場合:

メインブランチに直push

大規模チームの場合:

短命のフィーチャーブランチを作成（寿命は1日以内）
コードレビュー後、すぐにメインブランチにマージ
ブランチを長期化しないことが重要

トランクベース開発ではデグレチェックのため、自分がpushする前に必ずpullし、テストがpassすることを確認します。
大規模チームは人数が多いため、自分がpush前のテストを実行している間に誰かがpushしてしまい、またpullしてテストし直さなければならないという事象が多発してきます。
pushの椅子取りゲームが頻発すると、コードを書く時間より「他人の変更を取り込んでリトライする待ち時間」の方が長くなってしまうため、短命なブランチを切るというのが現実的な落とし所となってきます。

トランクベース開発において、機能開発の途中なのにmainブランチにコードがマージされてリリースされてしまうのではないか？という疑問が出るかもしれません。
これに関しては半分正解です。
実際に開発中のコードも本番へ乗ることになりますが、ユーザーからは見えないよう、フィーチャーフラグ（フィーチャートグル）を使って制御するのが一般的です。

フィーチャーフラグについては以下の記事を読むと理解が深まると思います。

前述しましたが、アジャイルでは細かくインクリメントさせていく必要があるので、細かい単位でコミット、PRを出していく必要があります。
短期ブランチで進める場合は、SBI（スプリントバックログアイテム）の単位でブランチを切るのが良さそうです。SBIの単位は1〜3時間くらいで終えられる作業量（コード量でいうと数行〜数十行）のイメージです。

この場合たくさんPRが出されることになるので、そこそこの頻度で誰かがレビューする必要があります。
レビューは開発より優先して取り組まなければなりません。なぜならば、マージをしなければインクリメントされないからです。
開発を優先させてしまうとレビューが溜まっていき、どんどんコードが腐っていくことになります。この優先順位を間違えないでください。

ただ、レビューのために都度作業を止めてレビューしてを繰り返すとスイッチングコストがかかってきてしまいます。
それを回避するために、例えば日替わりでレビュー担当者を決めるなどの解決策がありますが、特におすすめなのはペアプロです。

ペアプロによって何が起こるかというと、ダブルチェックしながらコーディングを進めるのでコードレビューする必要がなくなり、レビュー待ちの時間+修正の時間+再レビュー待ちの時間が不要になるのです。（PR作る必要もない）

ペアプロは2人で一つのタスクに取り組むため生産性が1/2になると誤解されがちですが、上記のようなフロー効率を考えればむしろ生産性は高まると言えます。

リソース効率とフロー効率について知らない方は、以下のBlogを読んでみることをお勧めします。

リソース効率・フロー効率について
これを簡単に説明すると、リソース効率は稼働率重視、フロー効率は生産性重視の考え方です。
ウォーターフォールでは基本リソース効率の考え方になることが多いのですが、これは労働者の管理のしやすさから用いられます。（管理者目線）
例えば以下のような項目が挙げられます。

人件費の「見える化」しやすさ
エンジニアの給与は固定費として明確に見えるので、「高い給料を払っているのに手が空いている＝無駄」という発想になりやすい
稼働率100%を目指すのは、コストに対するリターンを最大化しようという意図からくる
製造業の生産管理モデルの影響
工場の機械稼働率を上げれば生産量が増えるという考え方がそのままソフトウェア開発に持ち込まれている
これは「作れば売れる」時代の発想で、知識労働には当てはまらないことが多い
進捗の可視化の難しさ
マネージャーからすると「何かやっている」ことが見えると安心できる
逆に「考えている」「待っている」は不安を生む
個人評価への紐付け
「あの人は忙しそう＝頑張っている」という評価につながりやすい

逆にフロー効率は生産性を重視するため、ある程度の稼働率を犠牲にしていち早く価値を届けることを目的としています。（顧客目線）
稼働率を犠牲にするというのは、主に以下のようなことを指します。

同じタスクを複数人で進める
一つのタスクを、ペアプロやモブプロで進める
WIP制限（仕掛り中タスクの制限）
「手が空いたから新しいタスクを始める」をやめる
代わりに、既存タスクの完了を手伝う（レビューする、ペアで入るなど）
意図的に余裕を持たせる
全員が100%稼働だと、誰かに依頼したい時に「待ち」が発生する
70-80%くらいの稼働率にすることで、レビューや相談に即座に対応できる
残りの20-30%は、ペアプロやレビュー、ボトルネックの解消の時間として使う

話を戻しますが、もし今までシニアエンジニアにコードレビューを任せており、自分たちで相互チェックする自信がない、相互レビューを許可してもらえない場合はどうするべきでしょうか。
それであってもペアプロやモブプロは行うべきです。行えるようにフロー効率の話を携えて交渉するべきです。
もちろん、コード品質への不安が残るので最終チェックは一旦シニアエンジニアに任せる必要があるかもしれません。
ただ、それにかまけてペアプロの機会が失われると、チームが成長できない悪循環に陥ります。

コードレビューでは、コーディングの結果しか見てもらえません。コーディングの過程でフィードバックを得られなければ学びの機会は減ってしまいます。いつまで経ってもシニアエンジニアのチェックが必要なままです。

ペアプロを行えば、お互いにフィードバックを送り合うことができ、チームが成長していきます。シニアエンジニアにも積極的にペアプロを頼むと良いでしょう。
そうすればいずれチームが成長し、シニアエンジニアがいなくてもお互いのチェックで品質を担保できるようになっていくはずです。（自分達がシニアに成長していくはず）

最初は何事も痛みを伴いますが、勇気を持ってチームの成長のためにペアプロを導入することを強くお勧めします。

ただ、ペアプロは疲れます。
1日中ペアプロするのは体力的に難しいですし、ペアプロに向かない作業（単純作業、調査タスク、一人で集中したい作業など）までペアプロする必要もありません。
例えば午前中は1人で集中するタスクに取り組み、午後はペアプロしながらタスクを進めるなど、チームに合う形で調整すると良いかもしれません。曜日で分けたり、モブプロ（3人以上でプログラミングする）をやってみるのも良いと思います。

1人でタスクをする場合も、ごく小さいSBI単位でPRを出し、相互レビューし、すぐにマージすることを忘れないでください。
小さい単位であれば、数は多くなりますがレビューにさほど時間はかかりませんし、コンフリクトも軽微で済みます。
コンフリクトは悪ではありません。むしろ健全です。小さなコンフリクトは、同じ場所で作業した人と少し会話すればすぐに解消できるはずです。

コードをスプリントの最後まで熟成させるから、コンフリクトの解消コストが膨大になるのです。
コンフリクトを解消できないままスプリントが終了したり、デグレが発生してしまったりすれば、そのスプリントのインクリメントはゼロになってしまいます。
スプリントの最後に一気にマージ作業をするというのは非常に危険かつ非効率な上に、それが終わるまで何もインクリメントされないということに他ならないのでやめてください。

承認プロセスがチーム外に存在する

大きな企業ほどありがちなのが、何か新しいライブラリやツールを入れたいとなったとき、複雑な承認プロセス（長いリードタイム）を経て使用の可否が決まるといったフローです。
これは、早く価値を届けたいスクラムチームにとって大きな足枷となります。

理想はスクラムチーム内にある程度の承認権限を持った人が存在することですが、いない場合はどうすれば良いのでしょうか？

会社やチームによって状況が違うので、共通したウルトラC案はないのですが、例として以下のようなアプローチが考えられます。

承認者をスプリントレビューに巻き込む
定期的に顔を出してもらい、意思決定のリードタイムを短くする
「次のスプリントレビューで判断もらえますか？」と事前に握っておく
事前承認・包括承認を取り付ける
「このカテゴリのライブラリは事前承認済み」というホワイトリストを作ってもらう
毎回個別承認ではなく、ある程度の裁量をチームに委譲してもらう交渉をする
承認プロセス自体を可視化して改善提案する
承認待ちによる遅延を具体的に数値化（「平均2週間待ち」「この四半期で累計XX日のブロック」など）して、経営層やマネジメントに改善を働きかける（これはスクラムマスターやPOの役割）
承認が必要なものを早めにバックログに入れる
リファインメントの段階で「これは承認が必要」と識別し、スプリントに入れる前に承認を取り始める
スプリントプランニングでそのアイテムを選択する条件として「承認完了」を含める
技術選定の自由度が高い領域を見つける
影響範囲が小さいものはチーム判断でOKというラインを明確にしてもらう

チーム内に承認権限をもらえるよう交渉する場合は、正しい選択ができることを証明する必要があります。どのような基準に基づいて使用可否を判断するのかを明確に説明できなければ交渉の余地はないでしょう。
セキュリティリスクや持続性のリスクなどを調べる術も身につけていく必要があります。
この辺りは、どうやって納得してもらうかをそれぞれのチームで考えて交渉していくしかありません。

承認プロセスについては、セキュリティだけに限定した話ではありません。
コードレビューについても当てはまるケースがあります。
マージ作業のセクションでも触れましたが、スクラムチーム外のシニアエンジニア（EMなど）が最終的にレビューして承認しないとマージできないという状況も、承認プロセスが外部にある状態です。
こう言った状況でも、前述した通り相互レビューやペアプロの文化を作り、上長の承認を得なくても認められるようにチームを成長させていかなければなりません。

スクラムチームは、チームで自己完結できることを目指す必要があります。
なぜなら、外部に依存している部分が増えるほど時間をコントロールしにくくなるからです。待ちが発生すればそれだけインクリメントまでのリードタイムが減ってしまいます。
そうならないように、チームで自己完結させるための能力を身につけるアクションをとらなければなりません。環境やルールのせいにして腐ってはダメなのです。
現状外部に依存しなければ進められないことがあるのならば、それを自分たちができるようになるためのNext Actionを決めてスプリントを回してみてください。

まとめ

さて、ここまで具体例を挙げて問題点を考察してきました。
ここまでの考察で伝えたかったことは、以下になります。

スクラムはチームを成長させるための強制ギプス
- スクラムをうまく回すためには、チームの成長が必須
PBIは「ユーザーにとっての価値」の単位で切る（vertical slice）
- 技術レイヤーごとに分けると待ちが発生し、ウォーターフォール化する
品質の担保は開発者自身の責任
- 外部のQAチームに依存せず、自動テストやCI/CDで常にリリース可能な状態を保つ
コードは小さく、頻繁にマージする
- スプリントの最後にまとめてマージするのではなく、最大でも1日以内にマージする
ペアプロ・モブプロでレビュー待ちを解消する
- リソース効率ではなくフロー効率で考えれば、生産性は向上する
チームで自己完結できる状態を目指す
- 外部への依存が多いほどリードタイムが伸び、変化への適応が遅れる

そして、忘れてはいけないのが、スクラムをする目的です

複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出す

最後に

スクラムは形式ではなく、チームが成長するための仕組みです。
うまくいかないと感じたら、それは改善のチャンスです。
諦めずチームを成長させ、生み出せる価値を増やしていきましょう！
応援しています！！！