はじめに

つい最近組織の偉い方と1 on 1 をさせていただく機会があり、そのとき表題の件を説明した内容をメモも兼ねて書き起こしたいと思います。
その方はしきりに「1ヶ月のウォーターフォールを何回も繰り返すのとスクラムの違いがわからない」とおっしゃっていたので、これを期に自分なりの理解を説明しようとして作ったのがきっかけです。
なるべくエンジニアではない方にもわかりやすいように抽象的な表現も使っています。組織をアジャイルにしていこうという方などの一つの参考となれば幸いです。

スクラムとウォーターフォールの違い

ウォーターフォール...
お茶の「美味しさ」「デザイン」を先に追求し、「飲み物としての安全性」はその後できる限り対応する
スクラム...
お茶の**「飲み物としての安全性」は常に担保**しつつ、「美味しさ」「デザイン」を追求する
誤解を恐れずにすごく極端な例でいうと、「味はとても美味しいし、見た目の色もラベルのデザインもめちゃめちゃキャッチーだけど、毒があります。でも毒はなるべく取り除きました。」というのがウォーターフォールで、「飲み物として暗黙的に守られている品質や安全性はいつでも担保してあります。味とか見た目とかデザインは徐々に良くしていきます。」というのがスクラムの考え方

上の例のように、技術品質を担保しつつ毎スプリントごとに「出荷可能」なプロダクトをリリースするには、Doneの定義 (Done + Undone) を守り続けなければいけない。Doneの定義を満たしていないプロダクトはリリースしてはいけない。

リリースするためには、直前に「リリーススプリント」を実施し、Undone のものを実行しなければいけない。しかし長く放置されたUndone は期限内に間に合わず炎上の原因になる。

スクラムでは定期的(各スプリントごと)にUndoneを実行する必要がある。Undoneは上図にあるように、放置すればするほど作業規模が曖昧になり、予定していたリリース日に間に合わないというリスクが大きくなる。
しかし、Undoneは後半まで放置してしまいがちである。Undone をやらずにプロダクトバックログアイテムの消化を進めていけば、進捗していると錯覚してしまうからである。もっというとそこには、**「早く進捗させないといけないという周りからの外圧」**があるのかもしれない
定期的にUndone を実行するよう、スクラムマスターはPOと開発チームを促していく
ウォーターフォールは工程の後半にUndoneに相当するもの実行するという点でスクラムとは大きくアプローチが異なる
※ 余談ですが、私も様々な要因からUndone を溜め込みまくり、リリース直前になって遅延報告するという「いきなり赤信号問題」を経験しました。特にスクラムを組んで間もないことはよく起きがちなのかなと思います。

偉い方からは一定の理解を得られたかなと思いましたが、「アジャイルで開発しても、社内の連携先がアジャイルではないのでボトルネックになってしまうことが多い。開発チームが可愛そうだ。」というフィードバックをいただきました。
確かにそれなりに大きい組織だと、システム間がスパゲッティ状態になっており「Aシステムを使いたいのに、Aシステムが連携しているBとCシステムが不安定だから今は連携しないでほしい」みたいなことがあったりします。
また、連携したいシステム先の工数のキャパシティが一杯で、作ったシステムに遷移できるよう、リンクを貼ってもらう修正作業に5ヶ月待ちという状態も発生したりしています。
こうなるとボトルネックとなりうるシステムと連携するシステムは延々と開発できない(というかリリースできない) ことになってしまいます。
今現在この課題の解決案を私は持ち合わせていません。組織をアジャイルにするためには、こういった課題にアプローチしていかないといけないんだろうなあと思う今日この頃でした。