たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話

ここ1年ほど、コンシューマー向けのWebサービス開発のプロジェクトに参画できました。タイミングとしては、フロント側のミニマム版の先行リリースが済んだところから、バックオフィス側を含めた当初予定の機能一式が揃うまで(いわば「Ver.1.0」といったところ)です。その後の継続的エンハンスにも引き続き携わっています。
 
このプロジェクトでは“本物”の「スクラム」を実施していました。アジャイル手法をほんとうに実践している現場の経験は初めてでした。
 
当初は本当に戸惑いました。
 
自分が“普通の”エンタープライズ・システム開発でPMを務めるようなときは、Unified Processの「アーキテクチャー・セントリック」や「リスク・ドリブン」を意識しつつ、要件たる機能セットの全体を明らかにして、スコープ管理を重視したスタイルで進めます。今回のプロジェクトでは、スクラムとして「バックログ」としてタスクが列挙されはしていますが、システムのアーキテクチャーや機能スコープの管理がされているようには思えず、「これで破綻無くゴールできるのか?」と大いに不安を感じました。
 
 
それでもスクラムマスターに質問をぶつけたり、各種参考記事を読んだりして、少しずつアジャイルというものの認識を深めていくことができました。
 
@IT、「5分で分かる、「スクラム」の基本まとめ 」:
 
そして、得られた一定の理解は次のようなものです。
 
「アジャイル」の本質は、「イテレーティブに進める」などというところには無い。本質は「メンバー個々が個々としてプロジェクトあるいはプロダクトにコミットし、メンバー個々が如何にすればプロジェクトの成功あるいはプロダクトの完成に貢献できるか、自ら強いオーナーシップをもって考える、その点にいわば賭けている」、という点にある。
 
対して、ウォーターフォールの本質は、「プロジェクトの成功あるいはプロダクトの完成を、組織として仕組みとして担保しよう」と考えている点にあると言える。
 
よく"Collaboration and Teamwork" vs. "Command and Control"などのフレーズで対比されます。「個人の力」を信じるか、「組織の力」でこその安心か。。
 
このような“文化的背景の違い”からみれば、Unified Processもほとんどウォーターフォールの一変種でしかありません。「イテレーティブ」という点では、アジャイル系方法論もUnified Processも類似に見えます。しかし、個人のパフォーマンスで駆動しようとするか、組織の仕組みで駆動しようとするか、その価値の置き方は全く異なります。
 
 
また、アジャイルとウォーターフォールでは「計画」に対する考え方が全く異なると感じました。
 
ウォーターフォールでは、スケジュールと機能スコープが示され、それに対して必要リソース(お金や人)を見積もり、Work Breakdown Structureを作成したりします。投入可能リソースによって、スケジュールやスコープを調整するものの、それで決定された「計画」は、基本的に遵守すべき事項となり、その「計画」を達成することを目的にしてプロジェクトは進みます。「計画」通りに進捗しない事象が生じた場合は、リソース配分を調整し、WBSを組み替え、新たなクリティカル・パスを構築します。
 
アジャイル(※ここでは主にスクラムでの考え方に基づきます)では、最初にリソース(主に人)を制約として捉えます。まずメンバーが具体的に決定されます。その具体的なリソース(メンバー)は一定期間にどれだけの開発パフォーマンスを出せるのか実測します。(スクラム用語で「ベロシティ」と言います。)それにより、このチームが一定期間に達成できそうな開発量の見通しを立てることができます。そして開発タスクを優先順位をつけて順次消化していきます。目標への見通しはあるものの、そこには「いつまでに何を」というかたちで管理され遵守されるべきという意味での「計画」はありません。アジャイルにおける「計画」とは優先順位を見極めることです。
 
Ryuzee.com、「ベロシティに対する誤解」:
 
PRESIDENT Online、「サービスの開発速度を高める「スクラム開発」とは リクルートテクノロジーズが進める体制づくり」:
 
 
<追記>
この度参画できたプロジェクトが「スクラム」を導入する事となったいきさつをプロダクトオーナーに伺いました。基本的にはプロダクトオーナー自身がそれを指向した、ということが一番の要因のようです。プロダクトオーナーは、このWebサービスの社内での担当さんです。エンドユーザー社内で、必ずしもアジャイル系開発プロセスが受入れられているわけではなく、スクラムで進めることを社内で通すのに、だいぶ“戦う”必要があったとのことでした。ただ、自分の担当するサービスを顧客にまさに*届ける*という点で、開発側と一体となってサービス価値を考え実現していく事のできるチームビルディングが必須だと考えた、とのことです。
 
◆以上