バッドプラクティスからミニウォーターフォールを考える
七色メガネ▼ はじめに
こんにち WaWaWa Wasuremono. Belong で Engineering Manager をしている七色メガネです。
台風が熱をも払ったのか暑さもいよいよ落ち着きを取り戻しつつある今日この頃、皆様今年のコミケは楽しめましたか。(?)
余談ですが人生の目的を探す類の本で一番参考になったのは澁澤龍彦兄貴の「人生に目的はない。人間なんて油虫のように食って寝て寿命がきたら死ぬだけだ」です。 天命やミッションなんて自分が作り上げる幻でしかないんです。そう考えると人生もちょっと楽になりますね。
ということで今日はプロジェクトマネジメントにおける「ミニウォーターフォール」という概念について解説したいと思います。 ご興味あればお付き合いくださいませ。
▼ 言葉の意味
まず前提となる言葉の意味を押さえておきましょう。ウォーターフォールとアジャイルについてです。
- ウォーターフォール ... 「要件定義」から「運用」までの一連の工程を、上流から下流まで順番に進める方法。基本的に各工程は後戻りしない。
- アジャイル ... システム開発のプロセスのうち、「設計」「開発」「テスト」「リリース」の小さな開発サイクルを何度も繰り返す方法。徐々にプロダクトを洗練させていく。
大体ですが、こんなところでしょう。
これらの言葉を聞いたことが無いよという方はこのページの閲覧者には一人もいないはずです。なぜならそんな人はこのページを開かないから。
※ 画像参考: https://cortechne.jp/dev_method
▼ ミニウォーターフォールのをバッドプラクティスから眺める
では本題、ミニウォーターフォールとは何かを考えてみましょう。
意味するところは言葉の通り「小さなウォーターフォール」なのですが、往々にしてこの語はネガティブな意味を持ちます。
なぜネガティブな意味を持つかといえば、「アジャイルを目指して、辿り着けなかったものたちの成れはて」的なコンテクストで使われることが多いためです。
それはなぜか。いくつか意見をさらってみましょう。
まずは Ryuzee さんのブログ (https://www.ryuzee.com/contents/blog/13276) から。
画像参考: https://www.ryuzee.com/contents/blog/13276
スプリントの最初の数日で複数のプロダクトバックログアイテムをまとめて設計し、次にそれをまとめて開発をし、最後にまとめてテストをするやり方です。
これはまさにミニウォーターフォールと言えます。
( 同ブログから引用 )
よくない例としてミニウォーターフォールのサンプルを挙げてくれています。指摘しているポイントを抜粋すると、
- 開発の流れとして、まとめて設計 ~ まとめてテスト、というフェーズ構成になっている。
- アジャイル的に Sprint で開発フェーズを区切っているものの、実際は開発工程別で分断されている。
- 前の開発工程が終わらないと次の工程に入れないことがある。
などです。特に工程で区切るという、という属性がウォーターフォールの特徴をアジャイルに持ち込んでしまう、という指摘は納得感があります。 それによってテストが後半に固まってしまう結果、不足の事態の発覚が遅れ開発後期になって大事故になるというウォーターフォールあるあるは、 このパターンのアジャイルでも笑えない話になりそうですね。
では他の人の意見はどうでしょうか。 英語ですが、ミニウォーターフォールに触れる次のブログ (https://agilevelocity.com/sprint-may-mini-waterfall/) を見つけました。
※ 画像参考: https://agilevelocity.com/sprint-may-mini-waterfall/
Your Sprint May Be A Mini Waterfall If….The Team Is Working In Silos
(中略)
While it feels efficient at an individual level it makes for a long feedback loop and a greater risk of carrying work over to the next Sprint. It has the same Risk Iceberg that a waterfall release does where we compress QA at the end. ( 同ブログから引用 )
ここでの指摘としては、
- 1 人の開発者が 1 つのユーザーストーリーを担当しているとき、チーム内でサイロ化が起きており、ウォーターフォールになりかけている。
- 出力が 1 人の開発力に依存するためフィードバックループが長くなり、スプリント内で作業が終わらない可能性が高くなる。
- QA が後半に圧縮されているのでウォーターフォールと同じでスケジュールの後半にリスクが固まる。
というものがあります。パラレルに開発が進行しているという点では綺麗な進行だなと思いますが、これも駄目なんですね。
サイロという言葉は一般に「開発部」「運用部」のようなもっと大きな枠組を指すことが多い気がしますが、
ここでは チーム内であっても個々に作業が行われることを持ってサイロとしていますね。
また先ほどの指摘と同じように、ウォーターフォールの特徴を「リスクが後半に集まること」と認識しているあたり、問題認識は海を隔てても変わらんのだなと思わされますね。
Developer と QA が別れているかどうかは、チーム文化やビジネス規模によるでしょうか。
最後にもう一つだけ見て見ましょう。 マイクロソフトの牛尾さんという方のブログ (https://simplearchitect.hatenablog.com/entry/2016/09/24/113117) から。
※ 画像参考: https://simplearchitect.hatenablog.com/entry/2016/09/24/113117
筆者さんの言葉を借りると、
先ほどのテスト駆動開発だって、そもそも実装の前にテストであり、実装をした後にリファクタリングで「設計」変更を行う。 進化型設計とは、常に設計をしているような状態だ。実際に実装してから、ユーザさんに見せると、「あーイメージが違うよ」となるかもしれない。 それは要件を確認している行為だろう。つまりアジャイルの開発では、要件、分析、設計、実装、テストはいったり来たりする感じで開発されるので、シーケンシャルに流れるものではない。 だから、もしそうなっていたら、ミニウォータフォールと呼ばれるバッドプラクティスに陥っている可能性が高い ( 同ブログから引用 )
うーん、素敵な言語化ですね。そもそもアジャイルのモチベーションの一つは「まだ完全に定義できない未知の何かを作る」であって、そのための過程が 事前予測的にシーケンシャルに並べられるはずもないんですよね。設計したから終わり、テストしたから終わり、ではアジャイルの精神が既に損なわれてしまっている、と。
しかしシーケンシャルであればあるほど、予測可能性は上がるんですよね。アジャイルって難しい。
▼ ミニウォーターフォールのまとめ
ということで 3 者の考えるミニウォーターフォール像を眺めてきました。まとめると、
- ミニウォーターフォールとは、
- 開発工程がはっきりと分割されていてかつ不可逆的にフェーズが流れてしまうような属性をもつアジャイル。
- 個人が独立して活動しており、チーム内でサイロ化が起きているようなアジャイル。
- 要求、設計、実装、テストとシーケンシャルにフェーズが進行するようなアジャイル。
というところでしょうか。個々の述べていることは分かりますし同意できるのですが、全て常に踏まないようにするとなるとちょっと難易度が高そうですねえ。
ちなみに 3 者の方はそれぞれ自身の考える望ましいアジャイルの在り方も一緒に記載してくれていたので、こちらも眺めて見ましょう。
少しずつ理想は異なりますが、ミニウォーターフォールに陥らないために大事だと考えているところに通底しているものがある気がします。
抜粋して整理するとしたら、
- アジャイルがミニウォーターフォールに陥らないために必要なことは、
- 作業を工程別でまとめて一括進行するのではなく、進められるものから少しずつ順次進行していく。
- チケット ( ユーザーストーリー ) にはチームで取り組む。
- 最後にテストを固めない。
- 常に最良を目指した設計を行い、シーケンシャルな開発進行に囚われない。
あたりでしょうか。
▼ リソース効率とフロー効率という観点から
ミニウォーターフォールの絵とそうではない絵を見比べると、前者では複数のトピックがパラレルに進行し、後者では比較的少ないトピックのみが進行していますね。
( 最後の牛尾さんのブログだけはちょっと違いますが )
コンセプトとして「同時に多くを並行する」のか「１つずつ終わらせる」のかという違いは、 別の言葉にすると「リソース効率を求める」か「フロー効率を求めるか」という風にも言い換えることができます。ついでにこれらの概念についても確認してみましょう。
リソース効率とは、「リソース (人員) の稼働効率を最大化する」ことを第一に考える方法で、フロー効率とは「一連の作業フローの進行効率を最大化する」ことを第一に考える方法です。
パンをたくさん焼くぞ！ というプロジェクトにチームが立ち向かう時、「全員の手が空かないように、捏ね・成型・焼成に作業分担していこう！」
という作戦を取ったらこれはリソース効率重視です。各メンバーの作業は無駄がなくなり最終的な生産数も期待できますがパラレルに作業進行するため、最初のパンが焼き上がるのはだいぶ遅くなります。
対して「焼けたパンをすぐに提供できるように、1 つ 1 つ協力して作っていこう！」という作戦を取ったらこれはフロー効率重視です。必要な仕事にフォーカスして作業するので 最初のパンが焼き上がるのは早くなりますがパラレルに作業進行しているわけではないので、手空きのメンバーが出たり最終的に出来上がるパンの個数は少なかったりします。
※ 画像参考: https://www.slideshare.net/i2key/xpjug
どちらが良いかはケースバイケースですが、ことミニウォーターフォールというバッドプラクティスの観点から考えると、アジャイルは基本的にフロー効率を志向するべきだと言えそうですね。
▼ ミニウォーターフォールは悪なのか？
最後にミニウォーターフォールの是非を考えて、この記事を終えることにしましょう。
先に引いた意見の論旨の通り、ミニウォーターフォールがアジャイルにおける最適解である、ということはなさそうです。
が、常にミニウォーターフォールが悪である、という断定を下すにはちょっとを待ったをかけたいなというのが IMO です。
そもそもウォーターフォール自体は悪ではありません。大規模開発や基幹システム開発など、
慎重な進行を必要とするプロジェクトにおいてはアジャイルよりもウォーターフォールの方が優れた選択肢になります。
そんなウォーターフォールの要素が嫌われるのは、それが部分的にアジャイルの理念に混入した場合です。
迅速なフィードバックループを回して開発をする世界観に別スタイルのコンセプトが混入することが忌避されているのです。
しかし立ち止まって考えたいのですが、そもそもアジャイルとウォーターフォールは混ぜてはいけないのでしょうか？
PMBOK においてはアジャイルとウォーターフォールを合わせて使用することは禁じられていません。どころか、ハイブリッド型のプロジェクト進行として推奨さえしています。
もちろん無制限にというわけではないです。このハイブリッド型の運用は、「テーラリング」という理念に支えられています。
テーラリングとは、
プロジェクトをマネジメントするために、プロセス、インプット、ツール、技法、アウトプット、およびライフサイクル・フェーズの適切な組み合わせを決めること
と PMBOK 6 版において定義されています。
一例として、 PMI 発行の アジャイル実務ガイド (https://www.amazon.co.jp/Agile-Practice-Project-Management-Institute/dp/1628254238) では以下のような図でハイブリッドアプローチにおけるウォーターフォールとアジャイルの混在を肯定しています。
プロジェクトマネジメントにおける課題は「どうやってアジャイルを実現するか」ではなく、「どうすれば最も成功できるか」です。 その視点に立てば「ミニウォーターフォールであるから駄目だ」という発想は浅慮である、とは言うことができると思います。
もちろん、「ミニウォーターフォールであることでフィードバックループが遅くなっているから改善の余地がある」という課題特定は有用です。 そういった意味ではミニウォーターフォールはアジャイルで解決しようとしている問題を解決できなくしてしまうことが多いので基本的には忌避して良いと思います。 しかしミニウォーターフォールにすることによって得られるものもあるはずです。 例えば「アジャイルなのに予測可能性が高い」だとか「初級者が多いが安定して成果物を出力できる」だとか。
「今私たちはミニウォーターフォールに陥っているのではないか？」「アジャイルの本質を見失っていないか？」などの自己批判を行うと同時に、 「私たちには本当はウォーターフォールの方があっているのではないか？」「今ミニウォーターフォールで享受している恩恵はないのか？」など、自分たちのプロジェクト特性を抑えた上で批判する目もまた、 持っておきたいですね。
ということでまとめると、
- 「アジャイルかどうか」という観点に立てば、「ミニウォーターフォール」は悪である。
- 「最良のゴールを目指す」という観点に立てば、「ミニウォーターフォール」が悪であるかは分からない。
というのが IMO です。
▼ 終わりに
どこで見たのか忘れましたし内容もうろ覚えですが、誰かの言葉で「最善の選択などはない。最悪ではない選択があるだけだ」というようなものがあったのを思い出しました。 選択に際しての環境変数なんて可視のものも不可視のものもあって、全部を加味しての最善の選択など人間にはできません。 ただ見える範囲で、少なくとも最悪ではないと思われるものを選ぶぐらいの能力はあります。
プロジェクト方法論にしたって今やっていることが最善かどうかなんて誰にも分かりませんが、少なくとも最悪ではないより良い未来を志向して継続改善することを忘れないでいたいですね。
ではでは、さようなら。
弊社 Belong では一緒にサービスを育てる仲間を募集しています。 もし弊社に興味を持っていただけたら https://entrancebook.belonginc.dev/ をご覧いただけたら幸いです。