ウォーターフォールとアジャイルの違いはコンテクストのスイッチングコストで説明できる、気がした

ウォーターフォールとアジャイルの違い、そしてそれに順ずる利点と欠点についてずっとぼんやり考えていました。具体的には、「アジャイルは素早いウォーターフォールの繰り返しと何が違うのか？」という問いに対する根本的な解です。これはコンテクスト、つまり物事に対する考え方や見方のスイッチングコストに対するアプローチの違いとして、導き出せるのではないかと思うようになりました。

コンテクストスイッチングコスト

全ての物事には必ずいくつかの工程やサイクルがあり、それぞれに異なったコンテクストが存在します。システム開発で言えば、要件定義、設計、開発、テスト、デプロイ、運用などになるでしょうか。それぞれは必要な、または自然的な収束によって適用されるコンテクストは異なります。「チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ」を参考にさせていただくと、大きくはルーチンの業務、複雑な業務、イノベーションの業務に分けられますでしょうか。そしてその不確実性、アプローチや失敗の扱われ方もまたコンテクストによって大きく異なります。例えば要件定義は、世の中にない製品を作ったり、顧客満足度を圧倒的に変えたりという視点であり、不確実性は高く、アプローチも試行錯誤的、失敗は称賛される傾向にあります。一方で運用は、安定的に製品やサービスを稼働させ続けたり、間違いなく操作を加えたりする視点です。不確実性は低く、アプローチも生産管理や安全管理的、失敗は非難される傾向にあると言えるでしょう。

アプローチの違い

ウォーターフォールではその期間設定や不可逆性から、工程を分離可能だとする立場にあります。しかしその場合、工程が切り替わるということは、今までのコンテクストを変えることであり、結果として考慮不足として手戻りしたり、工程ごとに担当を分けたとすれば、組織対立としてそのスイッチングコストが表出したりするでしょう。

アジャイルではプロジェクトに関して記すドキュメント"インセプションデッキ"という中で、「ご近所さんを探せ」という項目があります。このトピックはなんとなく軽視されがちな印象ですが、コンテクストの異なるチームや職種、ステークホルダーをそのプロジェクトの開始時に網羅しようという試みではないでしょうか。また、「何を諦めるのかをはっきりさせる」という項目では、品質やスコープといったトレードオフとなり得る観点を調整し、そのプロジェクトにおけるコンテクストを定義するという試みもあり、そのスイッチングコストを抑制するような機構が備わっているのではないかと感じます。もしかすると、もっと乱暴に言ってしまえば、スプリントという短期間で実行と振り返りを繰り返すリズムやダイナミクスによって、人々が偏ったコンテクストを認知する前にやってしまえ、ということなのかもしれませんが。

終わりに

コンテクストのスイッチングコストという観点で見れば、実際のところ、プロジェクトの運営方法はあまり関係がないのかもしれません。工程やサイクル、職能や製品特性といったそれぞれのコンテクストを常に収集し、その視座をプロジェクトや物事に投入するということが大事なのではないでしょうか。