「アジャイルで始めたのに、いつの間にかウォーターフォールになっていた」——方法論の”形骸化”を防ぎ、選んだ手法を現場に”生きたまま”運用し続けるための実践技法

＜目次＞

「アジャイルをやっています」と言いながら、実態はウォーターフォールだった

「うちはアジャイルで開発しています」と言いながら、スプリントの成果物は毎回上司の承認待ちになり、振り返りは形式的に行われ、要件は最初にほぼ確定している——そんなプロジェクトに出会ったことはないだろうか。

逆もある。「ウォーターフォールで進めています」と言いながら、要件定義フェーズが終わったあとも仕様が次々と変わり、スコープはあいまいなまま、設計と実装が並走している。

これは「どちらの手法が正しいか」という話ではない。選んだ手法が現場で”形骸化”しているという問題だ。方法論を選ぶことと、それを運用し続けることは、まったく別のスキルである。

本記事では、アジャイルとウォーターフォールという選択の話ではなく、「選んだ手法をどう”生きたまま”維持するか」という、より実践的な問いに答えていく。

アジャイルを導入したチームが最初に失うのは、多くの場合「なぜそれをやるのか」という理由だ。スプリントレビューは行われるが、それはデモを見せるための場になり、フィードバックを次の開発に反映する回路が失われる。スタンドアップミーティングは毎日行われるが、進捗報告の場に成り下がる。

ウォーターフォールも同様だ。フェーズゲートは設けられているが、品質基準のない「儀式的な承認」になっていないか。レビューは実施されるが、指摘が次工程に持ち越されていないか。

アジャイルを導入しても、マネジメント層が「最終成果物の全体像を早く見たい」という圧力をかけ続ければ、チームは自然と上流での仕様確定を迫られる。ウォーターフォールで進めていても、現場の担当者が「小さく試してみたい」と動けば、計画外の実験が積み重なる。

方法論は組織の力学に負ける。これを前提に設計しなければ、手法の維持は絵に描いた餅になる。

プロジェクトの途中で状況が変わることはある。当初はアジャイルが適していたが、規制対応が必要になりドキュメント管理が厳格化した。あるいは、ウォーターフォールで進めていたが、要件の不確実性が高まりイテレーティブなアプローチが必要になった。

こうした局面で「手法を意識的に移行する」という判断を行うPMは少ない。気づけば「なんとなく混在している状態」になり、どちらの手法のメリットも享受できないまま進んでしまう。

プロジェクト開始時に、選んだ手法の各プラクティスについて「これは何のためにやるのか」を一言で書いたカードをチーム全員で作成する。たとえばアジャイルなら：

このカードを定期的に見直す習慣をつけることで、「目的なき儀式」への劣化を防ぐことができる。

スプリントごと、あるいは月次で「自分たちは手法の本質を実践できているか」を簡単にチェックする仕組みを設ける。以下のような問いを5段階で評価するだけでよい。

スコアが低い項目があれば、「なぜそうなっているか」をチームで議論する。これは手法の改善であると同時に、チームの認識合わせにもなる。

プロジェクト開始時に「こういう状況になったら手法を見直す」というトリガー条件を定義しておく。

たとえば：

「気づいたら変わっていた」ではなく、「意図的に判断した」という記録を残すことで、後からの検証も可能になる。

「アジャイルかウォーターフォールか」という議論は、多くの記事が扱ってきた。しかしPMが本当に問うべきは、「選んだ手法を、今日も正しく運用できているか」という問いだ。

方法論は選んだ瞬間が終わりではなく、始まりに過ぎない。現場の力学に抗い、目的を失わず、状況に応じて意識的に調整し続けること——それが、方法論を”生きたまま”運用するPMの仕事である。

あなたのプロジェクトで採用している手法は、今日も本来の目的を果たしているだろうか。その問いを、明日の朝一番に自分に投げかけてみてほしい。