「アジャイルは全体スケジュールにコミットできない」という誤解

connpass.com

に参加してきた。
なりゆきで「1.全体スケジュールにコミットできない」の議論に参加した。 

 

前提として僕の立ち位置をいうと、
アジャイル経験は3年ほど。
・熱心なアジャイル信者ではない
アジャイルという言葉は誤解が多いので使いたくない
・効果的なプラクティスやツールがあるなら、状況に応じて何でも使えばいいと思っている

 

はじめに結論を書いてしまうとこんな感じ。

「全体スケジュールにコミットできない」というのはアジャイル固有の課題ではなく、全てのシステム開発に当てはまる難しさである。
提示されたコンテキストではあたかもWFはコミットできているように錯覚してしまいそうになるが、実はそうではない。
ゴール、予算、リソース、期間が固定された無理なプロジェクトはどんなやり方をしても失敗する。

 

コミット(commit【自動】約束する、誓約する)とは

「WFは計画にコミットしている」と言う場合、その「コミット」は意思または契約のことを指している。

 

意思としてのコミット

コミットを意思と捉えるならアジャイル開発をしていても計画を達成しようという意思を持ってプロジェクトを進めるからコミットしていると言える。

 

計画へのアプローチ

WFとアジャイルでは計画へのアプローチが違う。
WFでは計画に合わせて調達を行い期間内に終わるようにプロジェクトを進める。
アジャイルでは計画は不正確であるという前提に立ち、細かく計測しながら計画の精度を上げていくことプロセスに組み込む。

前提の違い

このアプローチの違いはそれぞれが想定している前提の違いの反映でもある。
WFでは原則として固定された要件があり、条件に応じて調達を行うという前提にしている。
アジャイルでは要件は常に変化し、適切なメンバーを適時増員できるという仮定は現実的で無いという前提に立っている。


契約と責任

WFでは固定されたゴール、予算、リソース、期間で完成させるとコミットする為、顧客は安心して依頼でき、失敗に対しては受託業者が責任を取る契約にする。
この受託業者が責任を取る契約を「コミットしている」と言う場合、顧客が望む条件に同意できてビジネス上の価値があるなら、アジャイルでもそういう契約にしてもいいはず。
アジャイルはこの構造の問題意識からスタートしているのでそうしない。ただそれは「アジャイルだから」ではなく「ビジネスに問題があるから」で、あるはず。

 

アジャイルの難しさ

アジャイルでやっていて、特定のプラクティスを重視するあまりビジネス判断を間違えてしまうとすれば、それは変化に適応できていなくてアジャイルに失敗している。
そこには「様々なプラクティスを組み合わせて変化に適応する」という、アジャイルのアプローチの本質的な難しさはあると思う。
変化が歓迎されない環境でプラクティスだけ導入しようとしているといったねじれもあるのかもしれない。
今回の議論に参加して、アジャイル導入の成否は組織の文化とメンバーの経験に大きく依存するという実感を多くの人が持っていると感じた。
この点については改めて考えをまとめてみたいと思ってる。