ウォーターフォール開発とアジャイル開発の宗教論争

2つの開発手法が対立しがちな原因の一つに、お互いの開発手法の理解不足があげられる。
例えば、アジャイル開発でよく耳にするキーワード「価値」についてふれてみよう。

「顧客価値を最大化する」「ユーザーストーリーの粒度は、一つのユーザー体験やユーザーに届ける価値の粒度で作成する」などという言葉をよく聞く。

ここでいう「価値」は、ウォーターフォール開発でいう「機能」の概念と大きく異なるため、アジャイルへの理解を深めるうえで一つの躓きやすいポイントになっていると考えられる。

アジャイル開発に慣れている人にとって、価値はアジャイル開発の重要な概念である。ここが理解されないと、チームとしていっしょにやっていくことがむずかしいと感じるに違いない。しかし、「価値」はウォーターフォール開発に存在しない概念ではない。例えば、投資対効果(ROI)で表現されるものが価値に値することになるだろう。

それぞれ同じ意味合いでも表現や用語が異なるだけであり、相互理解が足りないだけだ。こうした例のほかにも、お互い不毛対立をしているケースをあげてみよう。

アジャイルソフトウェア開発宣言にある「ドキュメントよりも顧客との対話を」というフレーズは、よく「アジャイルはドキュメントを作成しない」という文脈で捉えられがちだ。

当然のことながら、アジャイルではドキュメントを作成しないというのは真実ではない。ナレッジの共有やチーム間での記録を残しておくために、必要なドキュメントは必ず作成する。
テーブル定義やAPI設計なども、どのような形式であれ記録は残す。必ずしもドキュメントとしての体裁は整ったものではなく、ホワイトボードの写真かもしれないし、Swaggerのようなそのまま動作検証可能なツールを代用することもあるだろう。

しかし、ウォーターフォール開発に限らず、ソフトウェア開発で必要なドキュメントは作成するのだ。
そこを「アジャイルではドキュメントをつくらない」と誤解してしまっては、アジャイル開発への移行に恐怖と違和感しか残らないだろう。

また、アジャイル開発はスペシャリストにしかできないというのも、大きな誤解だ。
アジャイル開発のチームであっても初心者はいる。
ただ、知見を共有するスキームがあって、各自が経験やスキルを日々高めているだけだ。

ウォーターフォール開発では、ほかの工程の担当者の実務に注意を払うことはないかもしれないが、アジャイルチームでは分業スタイルをとらないため、各自がある程度のスキルをもつ必要があり、足りない場合にはそのためのナレッジ共有のスキームを用意するのが通例である。

最初から特別な人たちを用意するわけではなく、経験を積んでもらい、成長を促す点は開発手法に依存するものではないだろう。

アジャイル開発においては、プロジェクトマネージャーをおかない代わりに、開発チームが自身でプロジェクトマネジメントをする。

ところが、ウォーターフォール開発からアジャイル開発に移行した初期段階においては、プロジェクトマネージャーがいないことを、プロジェクトマネジメントを行う人が不在であると勘違いする場合がある。
それだけではなく、プロジェクトマネジメントの責任？をプロダクトオーナーに負わせてしまうことがあるのだ。
そうすると、プロダクトオーナーはプロダクトの方向性の決定だけでなく、開発チームのマネジメント、WBSの策定など、本来ないはずのさまざまな責務まで負わされることになる。

ウォーターフォール開発では主にプロジェクトマネージャーがWBSを作成し、開発チームのメンバーは個々のタスクをこなしていくことが多い。
このような状況では、開発チームのメンバーがプロダクト全体を俯瞰してみたり、価値を考えたりする必要がない。
計画に従ってタスクの成果物を期限までに作成し、積み上げればよいからだ。

したがって、計画を策定しプロダクト全体を見通す人と作業する人が完全に分業になることも少なくない。
つくるものが決まっていれば当然このやり方は成り立つだろう。

しかし、何がエンドユーザーに受け入れられるかわからない状況で素早く試行錯誤をしなければならないとき、綿密な計画を立てることはできない。
このとき、プロダクトオーナーがプロジェクトマネージャーのように最初から緻密な計画を策定しようとするならどうなるだろうか。
初動に時間がかかってしまうにもかかわらず、何度も計画の変更を余儀なくされる。時間の無駄になってしまう。

そのうえ、計画がタスクに分解され、自分にアサインされるのを開発チームのメンバーが待っていたらどうなるだろうか。
タスク分解がプロダクトオーナーに集中すれば、たちまちボトルネックとなる。
開発チームのメンバーがプロダクトの方向性を理解していないと、タスクの成果物は精度の悪いものになる。
これでは、プロダクト開発のスピードは急激に落ちてしまう。

「3人のレンガ職人」というイソップ物語の寓話をご存じだろうか。

中世のとあるヨーロッパの町。旅人がある町を歩いていると、汗をたらたらと流しながら、重たいレンガを運んでは積み、運んでは積みを繰り返している3人のレンガ職人に出会いました。
そこで旅人は「何をしているのですか？」と尋ねました。すると、その3人のレンガ職人は次のように答えました。

1人目は、 「そんなこと見ればわかるだろう。親方の命令で“レンガ”を積んでいるんだよ。暑くて大変だからもういい加減こりごりだよ」と答えました。
2人目は、「レンガを積んで“壁”をつくっているんだ。この仕事は大変だけど、金(カネ)がよいからやっているのさ」と。
3人目は、「レンガを積んで、後世に残る“大聖堂”を造っているんだ。こんな仕事に就けてとても光栄だよ」と。
(引用元：https://www.central-engineering.jp/recruit/blog/laseek_20190418)

レンガを積むという行為を、単に親方の命令でレンガを積んでいると捉えるのか、大聖堂をつくっていると捉えるのかで、その人が自分の作業の目的をどう捉えているかがよくわかる寓話である。

レンガを積んでいると答えた人は、いま自分がしている作業が将来何の役に立つかを理解していない。
目的がわからない作業は改善も効率化もできないし、指示されたこと以外のことをやるモチベーションは上がらない。

一方で、大聖堂をつくっていると答えた人は、自分の仕事が大聖堂という大きな目的につながっていることを意識している。大聖堂の基礎になることがわかれば、どんな色調で、どんな形状のレンガが適しているかも自分の頭で考えることができるだろう。

ソフトウェア開発でも同じことがいえる、レンガを積む単なる作業のように、細分化されたタスクをただこなすようでは作業の目的を理解できない。作業を改善することもできなければ、モチベーションも上がらない。

あなたのプロダクトは業界のなかでどのような立ち位置だろうか。
業界のなかで唯一無二だろうか。競合製品と差別化ポイントはどこだろうか。これらの質問に、開発チームは回答できるだろうか。

あなたのチームのなかで出てきた、そのときは素晴らしく見えたアイデアに飛びついてはいないだろうか。
そのときは素晴らしく見えても、よく世の中を見渡すとすでに同様あるいはそれ以上の顧客価値を提供しているプロダクトがあるかもしれない。

すでにあるものを開発するためにコストをかけてしまってはもったいない。
すでにあるものは活用して、付加価値を探す活動に時間をつかおう。
また付加価値を高めるために、エンドユーザーのフィードバックをとり入れれば、必ず受け入れられるプロダクトになると思ってはいないだろうか。

いろいろな人の声や、一見気に入ったアイデアを盛り込んでいくと、プロダクトの方向性はどんどん見えなくなっていく。
プロダクトの方向性に基づいて、プロダクトに盛り込むバックログを正しく優先順位づけすることこそが要である。
決してアジャイル開発に取り組めば売れるプロダクトができるというものではない。

このように、ウォーターフォール開発の慣例でアジャイル開発を捉えてしまうと、正しい理解が妨げられ、拒否反応につながってしまいかねないのである。

逆もまたしかりで、アジャイル開発に普段から親しんでいる人は、ウォーターフォール開発のネガティブな側面に目が行きがちである。あるいは、アジャイル開発しか知らない、という人も徐々に増えている。

ウォーターフォール開発への誤解は、ますます蔓延してしまうかもしれない。いくつか例をあげよう。

「ウォーターフォール開発では機能は考えるが顧客価値は考えない」という誤解がある。

ウォーターフォール開発だろうがアジャイル開発だろうが、ソフトウェア開発においてはその投資対効果(ROI)を必ず考える。それなしに予算を執行する組織はないだろう。儲かる見込みのないプロダクトに投資をしたい組織はない。

ただ、ウォーターフォール開発では分業が進んでいるために、組織長やプロジェクトマネージャーなどのレイヤーまでがROIを理解していればよく、開発チームにそういった指標やプロダクトの目指す方向性、目的などが共有されていないというのが実情である。

アジャイル開発ではインセプションデッキなどで開発チームに方向性を共有する活動があるので、その点は異質に見えるだろう。アジャイル開発では、全体の目指すべきゴールだけではなく、タスクに落とし込んでいく段階でも顧客価値に注意を払う。

すなわち、1つのユーザーストーリーが「ユーザーの行動を変える」ような粒度で作成される。
ユーザーストーリーは、実際の開発がはじまると着手可能なサイズのタスクに分解され処理される。

この点はウォーターフォール開発にはない点だ。ウォーターフォール開発では、機能分割したものがすべて詰みあがれば効果が達成できると考えるので、タスクひとつひとつがどういう効果をもつのかは考えないからである。

しかし、プロジェクトのなかで誰がROIに興味をもって取り組むかが異なるだけで、顧客価値を考えないわけではないのだ。

また、「ウォーターフォール開発では仕様変更を許容しない」という誤解もある。

ウォーターフォール開発では、はじめの計画から変更がある場合、その変更をとり入れて計画を修正することがある。
ただ、こうしてしまうと作業スコープがブレやすく、いわゆる炎上の一因になりやすいため、別の開発計画に切り出して対応することもある。

いずれの場合も、ステークホルダーからの要望を受け入れてプロダクトを改善しているので、仕様変更をまったく受け入れないという理解は実態とは異なるだろう。

アジャイル開発の場合も、1つのスプリントの間でタスクがころころ変わっては開発チームが混乱するため、スプリント計画で決めたものは合意なく追加変更をしない。
両者で異なるのは時間軸であり、ウォーターフォール開発ではとり入れた要望がリリースされるまでに数か月から数年単位かかるのに対し、アジャイル開発では最短数日から数週間であるということだけである。

ともに目指しているところは、エンドユーザーの要望に寄り添ったプロダクトをリリースすることである。

本コラムでは、ウォーターフォール開発とアジャイル開発は相容れないものなのだろうかという観点から考察をした。
ソフトウェア開発である以上、必要なアウトプットが大きく変わることはないので、基本的な成果物ややり方が変わるものではない。

両者は抽象度やタスクの分解の仕方に違いがあり、その点が理解されていないことが不幸な誤解を生んでいる。
しかし、目指しているものが同じだからこそ、時代の流れとともにまた計画を重視するフェーズがくる可能性があるかもしれない。

いまの段階では、人間は大規模なソフトウェア開発を計画するのに十分なほど、未来を予見することはできない。
そのような状況では、変化に素早く順応していくスキームをもつアジャイル開発が主流になることは間違いないだろう。

しかしながら、今後未来の予測可能性が高まり、顧客価値を予知できるとすれば、つくるものがはっきりしていることになる。
そうなると、計画を立てて、その計画から外れないようにマネジメントしていくほうがよいだろう、という見方に変わっていくこともあり得るかもしれない。もしそうなったら、いまの潮流とは逆に、ウォーターフォール開発への移行が進むことになるのかもしれない。

そう考えると、ウォーターフォール開発とアジャイル開発の誤解を単なる「宗教論争」で終わらせてしまうのはもったいないと思う。
自分たちの置かれた状況に適した開発手法を選択できるよう、お互い正しい理解をしていきたいものである。