「それだとウォーターフォールになっちゃうのでやめましょう」と言わない

スケジュールを詳細化しようとしたり、トップダウン的に要件が降ってきたときのリアクションとして、標題のようなことを耳にすることがある。

言いたいことはよくわかる。しかしこれは、みんなの嫌われ者」であるウォーターフォールを引き合いに出し、思考停止気味に相手を説得（あるいは拒絶）しようとしているように思える。
言われたことを「やりたくない」と思ったとき、ウォーターフォールを便利なストローマンとして持ち出して終わるのではなく、もっとそのやりたくなさや懸念点を細かく言語化して良い議論をしよう、という提案をしたい。

私とウォーターフォールの付き合い

私は金融系社内SEとして、ガチのウォーターフォール開発を7年ほどやってきた。
その経験からはっきり言えるが、現代のソフトウェア開発においてウォーターフォールはとても機能しない。
ウォーターフォールは「事前にしっかり検討すれば多くの物事は予測できる」という思想が根底にあるため、前工程をしっかりやることで後工程に必要な作業内容や工数を正しく見積もろうとする。だから、プロジェクト途中に機能追加が必要になったときは「要件定義工程の見落とし」として扱われる。

この思想は、マクロにもミクロにもうまくいかない。
マクロ視点では、そもそも「どんなシステムを作るべきか」という問いへの答えを最初の1回で当てられるわけがない。作って試し、ユーザーの反応を見て初めて正解だったか失敗だったかわかるからだ。これを事前に予知することは、人智をもってしては不可能だろう。
ミクロ視点では、仮に必要な機能が本当に完璧に事前に予測できたとして、それの実装にかかる時間を性格には予測できない。みなさんにも「今日中にPR出せると思います」と言っておきながらで出せなかったことが一度はあるのではないか。今日1日の作業でさえ、正確に時間を見積もることは難しい。

なぜ「それだとウォーターフォールになっちゃうからやめましょう」をやめたいのか

私のウォーターフォールについての愛憎というか憎を明確にしたところで、「それだとウォーターフォールになっちゃうからやめましょう」の良くないところについて話したい。

それぐらいでウォーターフォールにはならない

ちょっと揚げ足取り的だが、多少それっぽいことをやったところでウォーターフォールにはならない。前述のとおりウォーターフォールというのは単に順序だてて進めることを指すのではなく、「前工程をちゃんとやれば後工程の工数が予測できる」という思想ありきで進むものだ。
逆にいえば、この思想を持っていないプロジェクト進行はウォーターフォールではない。スケジュールを詳細化したとしても、「そのスケジュールは状況に応じて変動しうる」という前提がステークホルダーに共有されていれば、そのプロジェクトはウォーターフォールになることはない。不確実性を受け入れ、柔軟性をもちながらプロジェクトを進めることができる。
「ウォーターフォールではガントチャートを作る」が真でも、「ガントチャートを作ればウォーターフォールになる」は真ではないのだ。本当のウォーターフォールを経験していない人ほど、ここに誤解があるように思う。

「ウォーターフォールっぽいこと」が求められるのはなぜか

では、なぜアジャイルな開発であっても「ウォーターフォールっぽいこと（詳細な計画作りや報告）」が求められる局面があるのか。
身も蓋もないが、リーダーやマネージャーといった「スケジュールに対して責任がある人」からすれば、どうしてもそういった情報が欲しいからだ。特にプロジェクト規模が大きくなればなるほどその傾向は強まる。

これは、開発者が「偉い人」を完全に信用させられていれば、あまり求められないかもしれない。ベロシティ実績に基づいた予測が正確で、やると言ったことを必ずやり遂げるチームだという信頼があれば、小うるさい管理は不要だろう。
しかし、多くのチームはそういった状態に至れていないのではないか。スプリントに積んだチケットが未完了のまま終わることが状態化していたり、安易にリリースしてはバグが出て結局余計な時間をかけたり、遅延が大きくなってからようやく報告したりしているのではないだろうか。

そんな状況では、いわゆる「偉い人」は安心できない。大きいプロジェクトであれば社内外にリリースをコミットしていることがある。そんなとき「開発者が自律してスプリントを回しています」だけだと安心できない。リーダーやマネージャーは偉い人への報告義務があり、偉い人には更に偉い人への報告義務がある。「今どれだけのタスクが残っていて、それぞれいつ着手予定で、どれぐらい時間がかかる見込みなのか」を知りたいのが人情だろう。そして、マネージャー観点でリスクがあるなら、裏で人員補強の交渉を始めたり、関係各所に進捗が芳しくないことを匂わせて期待値を調整したりしなければならない。そのときに必要なのは「わかりやすい表」や「説得力のある見積もり材料」である。開発者にはそれを出してほしいと言っているのだ。

またトップダウン的な要件に対しても不満の声を聞くことがあるが、これも会社員としてはある程度しかたないと考えている。
多くの会社では、開発者の評価に担当プロダクトの売り上げなどは入っていないのではないだろうか。そしてプロダクトマネージャーとか企画とか呼ばれるポジションの人がそのあたりの責任を負っているのではないだろうか。であれば、あくまでプロダクトの舵を取るのはそういった責任を負う人である。彼らがやるべきと考えることに開発者は協力すべきだし、逆に彼らは、どんなに開発者がやりたいと思うアイデアでもそれに価値を感じなければ採用すべきでない。
もちろん開発者からの視点が刺さることも多々あるだろうから意見はフラットに検討してほしいが、結果的にそのアイデアを採用しなかったとしても不満に思うのはお門違いだろう。腹を痛めない人の声を聞き入れる義理はないのだ。

おわりに

いろいろ書いたが、結局のところ「それだとウォーターフォールになる」という言葉は思考停止をもたらすからやめたい、ということだ。
マネージャーが詳細な計画を求めているときも、企画サイドがトップダウンな要件を出してきたときも、彼らは別に開発を硬直化させたいわけではない。彼ら自身の責任を果たそうとしているだけで、同じ会社の仲間だ。

だからこそ我々開発者は「それはウォーターフォールだ」と拒絶するのではなく、まずは相手の立場や責任に共感を示し、そのうえでソフトウェア開発の専門家として、現実的にどれぐらいの幅が許容できるかとか、より良い実装はこうであるとか、建設的な議論をしたいと思う。