アジャイルは時代遅れ？今も現場で使われる理由と弱みを補う方法を解説

「アジャイルは時代遅れだ」「日本では合わない」という声を聞き、自社の進め方を見直すべきか判断に迷っている方は多いのではないでしょうか。

私はSIerで大規模な開発プロジェクトのPMを長く担当した後、スクラムを採用した案件でスクラムマスターを務めた経験があります。

ウォーターフォールとアジャイルの両方を実務で経験した立場から言うと、アジャイルが時代遅れというよりも、誤解や前提条件のずれで「機能していないように見える」現場が増えているのが実情です。

本記事では、アジャイルが時代遅れと言われる理由、機能しにくいケース、日本特有の普及阻害要因、ウォーターフォールとの使い分けについて解説します。また、今でも現場で採用され続けている理由や再設計のポイントも紹介するため、アジャイルに対する理解を深めたい方は、ぜひ参考にしてください。

執筆者:和田匠真

IT業界で20年以上の実務経験を持つプロジェクトマネージャー。プログラマー・SEを経てPMとなり、大手企業のシステム提案からデリバリーまで一貫して従事。PMP/認定スクラムマスター(CSM)保有。ウォーターフォール/アジャイル双方の現場経験をもとに、プロジェクト管理に関する記事を執筆。

アジャイルが時代遅れと言われる理由

 

アジャイルが時代遅れと言われる背景には、手法そのものが古くなったというより、誤解や形骸化、関係者の負担感によって本来の価値が伝わりにくくなっている構造があります。3つの理由に整理します。

なお、アジャイルは2001年に発表された、アジャイルソフトウェア開発宣言を原点とする考え方で、4つの価値と12の原則を土台にしています。20年以上経った現在も、この宣言は更新されておらず、現役の指針として参照されています。

当社が2025年2月に実施したシステムエンジニア1,093名への調査において、アジャイル開発の導入率は23.2%でした。 ハイブリッド開発を含めると約半数の組織が何らかの形でアジャイルを取り入れており、衰退している手法ではないことがわかります。

ここからは、アジャイルが時代遅れと言われる理由について詳しく解説します。

アジャイルに対する誤解が広まっているため

最も多い誤解が、「アジャイルは設計しない」「ドキュメントを書かない」「とにかく早く作る」という表面的な理解です。アジャイルソフトウェア開発宣言は「包括的なドキュメントよりも動くソフトウェアを」と述べていますが、これは「ドキュメントがゼロでよい」という意味ではありません。

「動くソフトウェアにより価値を置く」という相対的な比重を示したものです。

誤解されたまま導入が進むと、設計が浅いまま実装に入る、必要なドキュメントが残らない、レビュー観点が曖昧になる、といった問題が発生します。結果として「アジャイルでは品質が担保できない」「現場が混乱する」という評価につながり、手法そのものが時代遅れと判断されてしまいます。

継続的な関与の負担で「合わない」と感じられるため

アジャイルは関係者の継続的な関与、頻繁な対話、短いサイクルでの意思決定を前提とします。プロダクトオーナーは日々の判断に巻き込まれ、開発チームは2〜4週間ごとにレビューを受け、利害関係者も定期的に確認の場に参加します。

この前提が、従来のウォーターフォール案件と大きく異なるため、関係者の負担感が「疲れる」「合わない」という感覚につながりやすいのです。

私が担当したスクラム案件でも、バックログリファインメント(バックログ整備の会議)が当初は毎回全員参加・長時間で実施され、「会議が増えただけ」という声がメンバーから上がりました。

次のスプリントで扱う上位項目だけを対象にし、必要な人だけが短く継続的に整える運用に変えてから、ようやく現場の負担感が落ち着きました。手法自体ではなく、運用の重さが「アジャイルは合わない」という印象を生んでしまうケースは多くあります。

形骸化した導入事例が目立つため

「アジャイルをやっている」と表向きには言うものの、実際にはスクラムイベントを実施しているだけで、価値の学習や改善が起きていない現場が少なくありません。いわゆる「セレモニーだけアジャイル」「なんちゃってアジャイル」の状態です。

私の担当案件でも、デイリースクラムが進捗報告会になり、レトロスペクティブが「コミュニケーションを増やす」「確認を徹底する」といった抽象的な改善案で終わる時期がありました。これでは、次のスプリントで何が変わるのかが不明確で、同じ課題が繰り返されます。実体験から言えるのは、レトロスペクティブでは改善項目を1〜2個に絞るのが重要だということです。 その後、担当・期限・確認方法を決め、次回の振り返りの最初に「前回のアクションが機能したか 」を確認する運用に変えると、改善のサイクルが回り始めます。

形骸化した実例が広がると、「アジャイルは機能しない」「結局古い手法だ」という印象が強まり、手法全体への批判につながります。

アジャイルが機能しにくいケース

アジャイルが時代遅れと評価される背景には、手法と前提条件のミスマッチもあります。以下の3つのケースでは、アジャイルの利点が出にくくなります。

要件を早期に固定したい場合

契約上、要件を先に確定させて見積もりを行い、スコープを動かさない前提で進める案件では、アジャイルの「変化への対応」という強みが活きません。変更を歓迎する設計の手法を、変更を許さない契約構造の中で運用しても、ねじれが生じるだけです。

たとえば、官公庁の入札案件や、要件凍結を前提とした受託開発では、アジャイルを導入しても実態はウォーターフォールに近い運用になります。この場合、無理にアジャイルと名乗るより、ハイブリッド型や段階的アプローチを検討する方が現実的です。

継続的な対話が難しい場合

アジャイルは、事業側や利用者が継続的に関与することを前提に設計されています。そのため、プロダクトオーナーが意思決定権を持って常駐し、利害関係者がスプリントレビューに参加する体制が必要です。

私が担当した案件では、代理POや窓口担当だけが前に立ち、優先順位や仕様の最終判断が遅れる場面が頻発しました。スプリント中に質問が滞留し、開発が確認待ちで止まる事態も発生しました。

POの意思決定権を明確にし、応答ルールを決め、スプリントレビューに事業側や顧客を直接参加させるよう運用を変えてから、学習サイクルが機能し始めました。 POの関与が形だけでは、アジャイルは機能しません。 

チームの裁量が小さい場合

自律的な判断や改善が許されない組織では、アジャイルの自己組織化という前提が崩れます。承認プロセスが多層的で、現場が自分たちで方針を変えられない環境では、検査と適応のサイクルが回らないためです。

人を頻繁に入れ替える運用も、自己組織化を阻害します。遅れたら別チームから増員する 、都度メンバーを動かすという運用ではチーム内の信頼関係が育たず、心理的安全性も生まれません。小さく安定したチームを維持し、まずそのチームで価値を出せるようにするのが、結果的に近道になります。

日本でアジャイルが普及しない背景

日本固有の構造的な要因も、アジャイル普及を阻む原因となっています。 経済産業省のDXレポート2.2でも、日本でアジャイル普及が阻害されている要因として「受託開発が多いこと」「契約・コミュニケーションの壁」「技術者がユーザー企業に所属していないこと」の3点が指摘されています。

要件を固めて進める文化

日本のIT投資は、契約や稟議の前提として「先に全体像を固めたい」という志向が強い傾向があります。予算確定、契約締結、社内承認のいずれも、最初に要件と期間とコストを確定させることを求める運用が一般的です。

この文化は、ウォーターフォール型開発と相性が良く、要件が動くことを前提とするアジャイルとは前提が衝突します。私の経験でも、ガバナンス不安から中間承認会議やステージゲートを何重にも載せた結果、Scrumの上に追加の会議体が積み重なり、かえって意思決定が遅くなる現場を見てきました。透明性の高い情報共有や見える化で安心材料を作る方向に変えると、追加の会議に頼らなくても進められるケースは多くあります。

発注者と開発側の分断

日本のソフトウェア開発は、ユーザー企業がベンダーに外注する受託開発が中心です。発注者と開発側が組織として分断されているため、アジャイルが前提とする「ビジネス側と開発者が日々一緒に働く」という体制が作りにくいのが実情です。

私が担当したSIer案件も、スクラムチームの外側にステークホルダーや関係部署が多く存在し、プロダクトオーナーと足並みが揃いやすい環境ではありませんでした。 発注者と開発側が分断される体制では、契約や役割分担を一気に変えられない前提で、変更頻度が高く事業側が継続関与しやすい領域から、小さく始めることをおすすめします。

評価制度と進め方の不一致

短期成果や計画遵守を重視する評価制度も、アジャイルの前提とずれやすい要因です。改善を重ねながら段階的に価値を出すアジャイルの進め方は、四半期ごとの目標達成や計画通りの納期遵守を評価する仕組みと噛み合いにくいのです。

KPI設計が弱く「やりっぱなし」になりやすいのも、日本の現場でよく見られる課題です。スプリントを重ねても「何が良くなったのか」が説明できず、経営層から「結局効果がないのでは」と評価され、現場も「なんちゃってアジャイル」に流れてしまいます。手法の前に、成果と状態を見える化する設計を整えることが先決です。

アジャイルとウォーターフォールの使い分け

アジャイルかウォーターフォールかの二択ではなく、案件特性に応じて使い分けることが重要です。両者は計画の固め方や変更への対応で違いがありますが、優劣ではなく適材適所で考えるのが実務的です。

要件の確定度合いで使い分ける

要件が早期に確定し、変更が少ない案件はウォーターフォールが向きます。業務要件が固まっており、関係者の合意が取りやすい案件、規制要件が厳しく途中変更が許されない案件などです。

逆に、要件が確定しにくく、市場や利用者の反応を見ながら方向修正する必要がある案件は、アジャイルの強みが活きます。新規プロダクトやSaaS開発、DX推進案件などはアジャイル向きです。

関係者の関与度で使い分ける

利用者や事業側が継続的に関われる案件はアジャイル、関与が限定的な案件はウォーターフォールが現実的です。自社サービス改善や社内向けシステム開発のように事業部門が日常的に関われるならアジャイル、稟議や定例会議でしか関与できない大規模受託案件ならウォーターフォールが向きます。 

プロジェクトの期間と規模で使い分ける

短期・小規模ならアジャイル単体で機能しやすく、長期・大規模になると段階的アプローチや併用を検討します。

少人数チームのSaaS開発や、数か月単位の単機能リリースならアジャイルが適します。1年以上の基幹システム刷新なら、ウォーターフォールを中心に据えつつ、変更頻度が高い領域からアジャイルを段階的に取り入れる形が現実的です。  

アジャイルが現場で採用され続けている理由

ネガティブな評価がある一方で、アジャイルが現場で採用され続けているのには明確な理由があります。当社が2025年2月にシステムエンジニア1,093名を対象にした調査では、アジャイル開発を採用している企業の約80%が導入効果を実感しているという結果も出ています。

変化に対応しながら学べるため

不確実性が高い案件では、最初に全要件を固めるよりも、学びながら進める価値が今も大きいと言えます。市場の反応、技術的な制約、利用者の実際の使い方は、作ってみて初めて見えるものが少なくありません。

短いサイクルでリリースし、フィードバックを受けて方向修正できるアジャイルの仕組みは、変化が激しい領域で依然として有効です。

利用者に近い開発を進めやすいため

スプリントレビューで利用者の反応を直接受けながら、次の計画に反映できる構造は、ウォーターフォールでは難しい強みです。「作って終わり」ではなく、「作りながら価値を確かめる」という進め方が、利用者満足度の向上につながります。

ただし、レビューが単なる成果報告会で終わると学習は起きません。意思決定に必要な関係者を固定で呼び、レビュー前に「何を学びたいか」を決めておくことが重要です。

ハイブリッド開発で柔軟かつ計画的に進められるため

アジャイルとウォーターフォールを組み合わせるハイブリッド開発も、近年広く採用されています。全体計画はウォーターフォールで設計し、機能開発はスプリント単位でアジャイルに進める、というアプローチです。

当社が2025年2月にシステムエンジニア1,093名を対象にした調査では、ハイブリッド開発の採用率は26.8%で、純粋なアジャイル単体(23.2%)よりも高い結果が出ています。日本の発注構造や予算管理と折り合いをつけつつ、変化への対応力も確保できるため、現実解として広がっています。

アジャイルを再設計するときのポイント

アジャイルがうまく機能していない場合、手法を捨てるのではなく、再設計するというアプローチが有効です。ここからは、再設計する際に重要となる3つのポイントを整理します。

手法ではなく課題から考えること

「アジャイルが流行っているから」「ウォーターフォールが古いから」という流れで導入すると、自社の課題と手法が合っていない事態になりやすいです。まずは、自社が解決したい課題は何か、その課題にアジャイルが本当に合うのかを、手法選定の前に整理する必要があります。

たとえば、「変更が多い案件で手戻りが多い」「利用者の反応を早く取り入れたい」という課題であれば、アジャイルが合います。「要件は固まっており、納期と予算を厳守したい」という課題であれば、無理にアジャイルを導入する必要はありません。

導入範囲を小さく始めること

アジャイル導入を一気に全社で進める方法は、失敗しやすい傾向があります。 まずは、変更頻度が高く、事業側が継続関与しやすい領域から、小さく始めることが現実的です。

最初は1チーム、1プロダクトで効果を出し、その経験をもとに横展開していく方が、結果的に組織全体への定着は早くなります。効果が出ていない状況で押し進めると、組織文化との衝突が大きく、アジャイルが機能しなくなる可能性が高まります。

支援体制を先に整えること

役割設計、意思決定権限、レビュー体制が整っていないままアジャイルを始めると、形骸化します。スクラムマスター(またはアジャイルコーチ)の配置、プロダクトオーナーの権限明確化、レビュー参加者の固定など、運用の土台を先に整えることが重要です。

支援体制を整えることとあわせて、技術的な土台も欠かせません。会議体だけアジャイルにしても、変更に耐えるコード基盤やテスト環境がなければ、手戻りが多くなります。CIやTDD、ペアプログラミングなど、変更容易性を支える技術プラクティスを並行導入する必要があります。

【時代遅れと言わせない】アジャイルの弱みを補うならプロジェクト管理ツールが有効

アジャイルの実務で起きる問題の多くは、「何をどこまで開発すればゴールなのか見えにくい」「全体像と現状の進捗が把握しづらい」という透明性の欠如に起因します。これを補うには、プロジェクト管理ツールによる見える化が有効です。

スクラムは、経験主義に基づくフレームワークで、透明性・検査・適応が成り立つことで機能します。タスクの状態や優先度、ブロッカーや完了条件が曖昧なままでは、検査も適応も形骸化するかもしれません。

アジャイルの弱みを補う方法として、Lychee Redmineを導入することが挙げられます。Lychee Redmineには、アジャイル運用の透明性を支える下記の機能が備わっています。

• ガントチャートによる全体計画の見える化
• カンバンやバックログによるタスク管理
• 工数管理によるチーム負荷の把握　など

Lychee Redmineを提供する当社では、サービスの効果を感じていただくために30日間の無料トライアル期間を用意しています。「自社の運用に合うのかを試してみたい」という方は、ぜひ、無料トライアルを活用してみてください。クレジットカード登録不要で始められます。

アジャイルに関するよくある質問

アジャイルについて深く知っておけば、今抱えている悩みや、疑問を解決できる可能性があります。以下では、アジャイルに関するよくある質問とその回答について紹介します。

アジャイルが向く人・向かない人の特徴はありますか

アジャイルが向く人と向かない人の特徴は、それぞれ次のとおりです。

向く人の特徴	向かない人の特徴
・変化を前向きに受け止められる ・対話や協働を好む ・自律的に判断・改善できる ・不確実性を許容できる　など	・計画通りに進めることを重視する ・明確な指示や手順がないと動きにくい ・対話より個別作業を好む　など

ただし、「向かない人だから不適格」ということではありません。チームでお互いの素養を補い合える関係性が重要であり、計画性に強い人と変化対応に強い人が組み合わさることで、より機能するチームになります。

アジャイルとスクラムは何が違いますか

アジャイルは、2001年の「アジャイルソフトウェア開発宣言」を原点とする考え方や価値観の総称です。一方、スクラムはアジャイルを実現する具体的なフレームワークで、ロール(プロダクトオーナー、スクラムマスター、開発者)、イベント(スプリント、デイリースクラムなど)、成果物(プロダクトバックログなど)と定義されています。

アジャイルの中にはスクラム以外にも、カンバンやXP、リーン開発などが含まれます。スクラムは数あるアジャイル手法の中で最も普及しているフレームワークの一つです。

アジャイル導入はどこから始めればよいですか

適用範囲を絞り、関係者が関与しやすい領域から始めるのが現実的です。具体的には、変更頻度が高く、事業側がフィードバックを継続的に返せるプロダクトや機能を選びます。

新規開発のSaaSプロダクトや、既存システムの機能追加・改修などが候補になりやすい領域です。逆に、要件が固定されていて、契約上スコープが動かせない案件はアジャイルを避けるのが無難です。

アジャイルでもドキュメントは必要ですか

アジャイルでも、必要なドキュメントはあります。アジャイルソフトウェア開発宣言が「包括的なドキュメントよりも動くソフトウェアを」と述べているのは、「ドキュメントをゼロにする」という意味ではありません。「動くソフトウェアにより価値を置く」という、相対的な優先順位に基づいています。

実務では、ユーザーストーリーやシステム構成図、運用引き継ぎ資料など、目的に応じて必要なドキュメントは残します。重要なのは、「何のために書くのか」を明確にし、不要な形式的ドキュメントを削減することです。すべてを省略するといった意味合いではないことを知っておきましょう。

まとめ:アジャイルは時代遅れではなく前提条件に合うかで判断することが重要

アジャイルが時代遅れと言われる背景には、誤解の広がり、関係者の負担感、形骸化した導入事例の3つがあります。一方で、現場で採用され続けている理由も複数存在し、アジャイルは衰退している手法ではありません。

重要なのは、手法そのものの是非ではなく、自社の前提条件に合うかで判断することです。要件の確定度合いやプロジェクトの期間と規模、組織文化や評価制度などを踏まえて、適切な手法を選ぶことが重要です。

アジャイルがうまく機能していない場合は、手法を捨てるのではなく、再設計するといったアプローチで立て直すことも可能です。

「進捗を把握しにくい」という現場の透明性に課題がある場合は、Lychee Redmineのようなプロジェクト管理ツールを導入することがおすすめです。ガントチャートによる全体把握やバックログによるタスク管理が可能で、プロジェクトを効率的に管理できます。

「実際に運用してみてから本格的に導入してみたい」という方は、30日間の無料トライアルを通じて業務効率化につながるか検討してみてください。