「アジャイルを導入してみたけれど、思ったほど効果が出ない」「現場が疲弊している」。
アジャイル開発を導入する企業が増加する一方で、実践者の多くが悩みを抱えているといいます。
そう語るのは、SHIFTアジャイルエバンジェリストの渡会 健。約20年にわたりウォーターフォールのプロジェクトマネージャーを務めたのち、アジャイルの道へ進んだエキスパートです。
双方のよさを知り尽くした渡会は、「形だけの手法を模倣し、本来の目的を見失った『なんちゃってアジャイル』が蔓延している」と警鐘を鳴らします。
本記事は、渡会が2025年12月10日に登壇したプロジェクトマネジメントDAY 2025 アンコールでの講演内容をもとに、ウォーターフォールとアジャイルの本質的な違いを改めて整理します。
そのうえで、真のアジャイルの力を引き出し、日々の仕事を劇的に推進する最大のエンジン「ビジネスと開発の協働」について紐解きます。
-
AIアジャイル開発部 アジャイルエバンジェリスト 渡会 健
2025年、株式会社SHIFTに入社し、Customer Quality Agileを掲げて日々活動中。キャリア前半をPM畑で過ごした後、2008年に40代でアジャイルに出会ってからは、10年程受託開発で20件近くの実践を積み、その後コーチやコンサルとして50件以上の支援を行うなど、17年で70案件以上の多種多様な実践経験をもつ。マネジメント（≠PM）の力を信じ、その経験を活かしながら、一般社団法人PMI日本支部アジャイル研究会代表、独立行政法人情報処理推進機構（IPA）アジャイルWG構成員等を歴任し、マネジメント視点と現場視点の両軸からアジャイル領域に貢献。 PMI日本フォーラム2025 優秀講演第6位（52講演中）。
目次
なぜいま、日本で「なんちゃってアジャイル」が横行しているのか
多くの現場が抱える悩みや違和感。その正体は、表面的な部分だけを模倣した「なんちゃってアジャイル」です。朝会やふりかえりは実施していても、一番重要な“魂”が抜け落ちているケースが後を絶ちません。
なぜこのような事態に陥るのでしょうか。その背景には、日本企業に根強く残るウォーターフォール文化からの脱却のむずかしさがあります。
アジャイルを表面的に理解したまま導入し、困ったときには無意識に従来のウォーターフォール的な発想に戻り、安易なハイブリッド開発にして失敗するケースが非常に多いのです。
さらに大きな原因として「アジャイルを導入すること」自体が目的化してしまっていることが挙げられます。最近では、経営層のトップダウンでアジャイル推進部門がつくられたものの、現場は何をしていいかわからず疲弊していく「やらされアジャイル」も増えています。
アジャイルの真の目的は、お客様の価値を最大化することです。すなわち「価値あるものを素早く提供し、さらにその価値を高めていくこと」。
決して開発者が楽をするための仕組みでも、計画を立てなくていい口実でもありません。しかし、経営層からの「アジャイルでやれ」という指示により、現場は手法を守ることだけに意識が向いてしまうのです。
私自身も、そんな失敗をしたことがあります。アジャイルをはじめたばかりのころ、「何でもアジャイルでやれば成功する」と勘違いしていた私は、「既存システムを安く早く移行してほしい」という要望にアジャイルを適用してしまいました。
新しいバージョンにマイグレーションするだけ、つまり不確実性が低いのでウォーターフォールでよかったのです。結果的に不要な変更を加えて予算オーバーになり、お客様からお叱りを受けました。お客様が求めている“価値”を見失っていたんです。
いまさら聞けない、アジャイルとウォーターフォールの本質的な違い
アジャイルとウォーターフォールは、決して敵対するものではありません。欧米ではアジャイルが主流だというのは幻想です。
グローバルのPMI（プロジェクトマネジメント協会）のレポートを見ても、実はウォーターフォール単体を採用している企業の方が割合としては多いのです。ただ、アジャイル単体とハイブリッドを足しあわせるとウォーターフォールを超える、というのが実態です。
彼らはプロジェクトの特性や目的にあわせて、双方の手法を柔軟に使い分けているのです。
しかし、両者の特性を正しく理解しないまま「仕様決定まではウォーターフォールで行い、製造からアジャイルで行う」といった安易なハイブリッド開発に手を出すと危険です。
例えば、アジャイルの「仕様変更を受け入れる」という特性を曲解し、無計画に仕様変更を連発すれば、容易にデスマーチへと陥りかねません。
ここで一度、ウォーターフォールとアジャイルの違いを整理しておきましょう。
ウォーターフォールは、明確なゴールが見えている“予測型”のアプローチです。ゴールまでの道筋を正確に予測し、計画通りに一直線に進むため、要件が固まっている場合にはもっとも効率的です。
一方アジャイルは、ゴールが霞んで見えない状況下で威力を発揮する“探索型”のアプローチです。未知の山に登るように、まずは麓まで行き、その時点の天候や体力、道の状況を確認してから次のルートを決めます。
一歩ずつ手探りで進むアジャイルは決して「無計画でよい」ということではありません。状況の変化に合わせて小さな「計画を立てつづける」アプローチなのです。
品質の守り方にも違いがあります。ウォーターフォールは「不具合は入り込むもの」を前提とし、最後のテスト工程で一気にバグを抽出します。いってみれば「まずは大きな部屋を作ってから、あとでそこを一生懸命掃除する」ようなイメージです。
一方、アジャイルは「無菌状態を保ちつづける」という思想です。小さくつくった機能に自動テストを組み込み、完全に動くことを担保してから次の開発に進みます。風船を無菌状態のまま少しずつ膨らませていくように、常にリリース可能な品質を維持しつづけます。
形だけの手法から脱却する「アジャイルマニフェスト」の真意
形だけの手法から抜け出すためには、「アジャイルソフトウェア開発宣言（アジャイルマニフェスト）」の真意を理解する必要があります。
しかしアジャイル研究会の調査によれば、アジャイルを実践している人の約半数がその存在を知らない。
また、知っていたとしても「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」という一文を、「ドキュメントや計画は一切不要だ」と誤解している人が少なくありません。
マニフェストには明確に「右記の事柄（プロセスやドキュメント）に価値があることを認めながらも、左記の事柄（対話やソフトウェア）により価値をおく」と記されています。
つまり、計画やツールを軽視しているわけではないのです。アジャイルでも、数週間単位の「スプリント」ごとに綿密な計画を立てつづけます。ただ、それ以上に人間同士の対話や、実際に動くものを通して価値を検証することを重要視しているのです。
個人的にもう一つ気をつけてほしいのが、アジャイルやスクラムは決して完成形ではないということです。マニフェストの序文にも「より良い開発方法を見つけ出そうとしている」と明確に記されています。
基本をしっかりやることは当然ですが、スクラムの枠を一歩も出ないことが正義ではありません。基本を理解したうえで、自分たちなりのやり方を「守破離」で模索していく姿勢こそが重要なのです。
また、マニフェストには「自分たちがアジャイルを実践できているかどうか」を測る12の原則が記されています。今回は、そのうち特に重要な4つの原則を紹介します。
1つ目が、「お客様満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」というもの。前半の失敗談でも触れたとおり、アジャイルの真の目的はお客様の「価値創造」にあります。そのために小さな成果を素早く積み重ねていくのです。
2つ目が、「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」です。アジャイルでは、変化を「お客様がより大きな価値を発見した証拠」と捉えます。手戻りではなく、プロダクトを改善するための機会なのです。
しかし、これは「お客様のいいなりになる」ことではありません。ビジネス側が変更を求めた場合、開発側はプロフェッショナルとしてシステムへの影響やリスクを明確に提示する必要があります。
そのうえで、本当に競争力に寄与する変更であれば、歓迎して取り入れるのが正しい姿勢です。
3つ目は、「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」です。
チーム内の特定のメンバーがプロダクトを生み出すのではなく、プログラムの構造やビジネスの進め方など、どんな議題であっても全員で知恵を出しあって進めようという意味が含まれています。
スクラムマスターのなかには、「いいチームをつくること＝開発者のいいなりになること」と誤解している人が少なくありません。
開発者の味方をするスクラムマスターは一見かっこよく見えますが、単に開発者を庇っているだけでお客様の事業を前に進めていないのであれば、何の価値も生んでいないのと同じです。
当然のことながらお客様の事業を前に進めるためにいいチームが必要なのであって、チームが強くなればビジネス価値が自然と生まれてくるわけではないのです。
4つ目が、「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」というもの。
アジャイルを成功に導く最大のエンジンは、「ふりかえり」です。これは単に製品の反省会ではなく、製品をつくり出すチーム自身をバージョンアップさせるための時間です。
スプリントごとにやり方を改善していくことで、チームの生産性は時間の経過とともに加速度的に向上していきます。忙しいからといってふりかえりをやめてしまうと、チームの成長もそこで止まってしまうのです。
組織アジャイルの真の成功の鍵は「ビジネスと開発の協働」
プロジェクト単体だけでなく、企業全体がアジャイルになっていくために、私は「組織を幸せにする組織アジャイル 5つの原則（ソシアジャ五良核）」という概念を独立行政法人情報処理推進機構 （IPA）アジャイルWGメンバーとして提唱しています。
これは「方向性」「協働」「敬意」「成長」「事業」という5つの原則をまわすことで、アジリティの高い組織をつくるというものです。なかでも、基盤となる「方向性の統一」と「協働」が成功の鍵を握ります。
アジャイルにおいてもっとも避けるべきは「発注者から開発者への丸投げ」です。ビジネス側と開発側という対立構造のままでは、真のアジャイルは実現しません。
例えば、プロダクトオーナー（PO）には、即断即決の覚悟が求められます。「社内にもち帰って確認します」と回答を保留してしまえば、アジャイルのスピード感は死んでしまいます。ビジネス側と開発側がともに考え、ともに決断する当事者意識が不可欠です。
このような背景から、アジャイルは決して楽な道ではありません。ビジネス側はつねに決断を迫られ、開発側は技術だけでなくビジネス価値にまで踏み込んで考える必要があります。
しかし、壁を越えて協働できるようになると、仕事は劇的に楽しくなります。私がなぜ20年近くもこの仕事をつづけているのか。それはやっぱり、「アジャイルで働く」って本当に楽しいからなんですね。
開発者は自分がつくったものが直接ビジネスに貢献している実感を得られ、ビジネス側は毎週のようにプロダクトが成長していく過程を味わうことができます。この「ともに価値を創り出す喜び」こそが、アジャイルの本質的な魅力なのです。
ビジネス側と開発側が従来の壁を打ち破り、互いに敬意をもって協働し、ともに成長しつづける。これこそが、変化に強く、真の力を引き出せる組織へと進化していくための道となるでしょう。
＼＼動画もぜひご視聴ください／／
（※本記事の内容および対象者の所属は、イベント開催当時のものです）
