アジャイル開発にPM（プロジェクトマネージャー）は必要か？

はじめに

ウォーターフォールのPM視点からアジャイルSMへ挑戦し失敗した筆者は、「マインドセットの変革が不可欠」と気づいた。
今回、さらに「AI・クラウド・ビジネスアジリティ」などの2025年以降のトレンドを踏まえ、PM／スクラムマスターが進化すべき価値観を強化しました。

失敗談

アジャイル開発はやり方を変える必要がある、と聞いたことはありませんか。

我々もそれを念頭におき、事前に書籍等で情報収集してから着手しました。
チーム全員が未経験でしたが、まずは気軽にやってみようと始めた結果、こんな状態に陥ったのです。

• スプリント内で１つもバックログを完了できない
• スプリントプランニングで何を作るか認識が合っていない
• 完了の定義を設定したものの運用できない
• デイリースクラムに１時間以上かかる
• 開発者がSMに指示を仰ぐ
• 問題を解決するためにSMがバックログを作成する
• うまくいかなかった原因を他者に求めてしまうため、振り返りが十分に機能しない

2か月程実施しましたが、チームメンバーだけでは状況を解決できず、この取り組みを中断しました。

失敗から得られた教訓

何が原因だったのでしょうか？ 様々な要因が掛け合わさってこの状態が起きたのですが、根本的要因の１つとして、「従来のテーラリング感覚で、アジャイル開発の手法から自分達に合う部分だけを採用しようとしており、立場や価値観を変えていなかった」ことです。

「アジャイル開発では自己組織的（自己管理的）に作業を進めるため、マネージャーが作業の計画や指示をしてはいけない」「スクラムマスターは、サーバントリーダーである」ということは知っていました。

でも、なぜそうするのか、それを実現するためにどのように行動すべきなのかは分かっていなかったのです。

筆者がそれに気づいたきっかけは、社内で開催しているアジャイル体験型研修に参加し、基礎から知識を学び直したことと、アジャイルコーチとのコミュニケーションがきっかけでした。

ここでは、ウォーターフォール開発しかやったことがない人、特にPMという立場の方がアジャイル開発を始める時に変えるべき価値観を２つお伝えします。

時間軸と成功基準の違い

ウォーターフォール開発とアジャイル開発のマネジメントの違いは、タイム、スコープ、リソースで構成する鉄の三角形でよく表現されますが、少しかみ砕いて説明していきます。

まず、「プロジェクト」という考え方です。プロジェクトは「有期性のある業務」ですね。

プロジェクト型開発では、予め案件概要と終了日を設定し、計画したことを最大のパフォーマンスで完了することを成功と考えます。その背景には、完璧な計画を作れる、計画通りにできればビジネスが成功するという自信があるとも言えます。
やることが決まっているなら、類似の作業をまとめてやると効率的なので、工程に区切って進めるのではないでしょうか。

一方、アジャイル開発を採用するプロダクトは、不確実性が高く、完璧な計画は立てられないという前提のもと、小さく作り大きく育てるというアプローチをとります。終わりはありません。
プロダクトを育てる過程において、適切な判断ポイントを自ら設定し、評価と改善を繰り返しながら市場ニーズに適合していきます。そのため、できるだけ早く効果に結び付くこと、効果を獲得し続けることを成功と考えています。
仮に計画より作業の進みが遅く成果物が少ししかできていなくても、期待した効果を得られるなら成功と言えます。

ウォーターフォール開発にも、イテレーションやフェージングなど期間を細分化して進める方法があります。
これはスクラムと同じではないかと考えるケースがありますが、上記のように成功基準が違うためマネジメント方針が異なります。

アジャイル開発だと、「ニーズが高まっているから今のタイミングが効果的！ここまででいいから、予定より早くリリースしてしまおう！」なんてことができますが、ウォーターフォール開発では変更管理によるコスト増を回避するため期日までやりきってから次のフェーズで調整するかもしれません。

管理者の方にお伺いします。
アジャイル開発をしているのに、

「予定通りに終わりそうか？」
「WBSで計画と実績を表現してほしい」

などと言っていませんか？

もしそうだとしたら、適切な価値観で判断できていない可能性があります。

元来、小さく作り大きく育てるアプローチだが、2025年以降はAI・クラウド技術の助けを借り、フィードバックループが劇的に高速化しています。
クラウドネイティブ環境やCI/CDでの継続デリバリで、「価値がユーザーに届く」までの時間がさらに短縮可能です。

また、AIによる需要予測・品質改善支援も進化。
AIが定量的な意思決定をサポートし、「予定より作業が遅れても、価値があるならOK」といったアジャイル判断の幅が広がっています。

役割の違い

アジャイルにPMというロールはありません。

従来のPMが担っていた役割が不要なのではなく、PO、SM、開発者に振り分けたり、チーム全体で扱うものとなります。

まず、各ロールに定義された役割と３役で構成されている理由を正確に把握することが大切です。

その上で、メンバの知識やスキルを鑑みて、そのチームにとって最適な役割分担や進め方に調整していきます。
譲ってはいけない部分はあるものの、決まった形はありません。

チームメンバや時期によっても最適解は変わります。この匙加減が未経験者には難しいため、経験のあるSMやアジャイルコーチの支援が必要となります。 しかし、理解しておくべきことは、決まっているものでも誰かが決めるものでもなく、チーム全員で調整するものだという姿勢がチームのコミュニケーションを円滑に進める上で重要だということです。

PMというロールはいないのでしょうか？

SAFeでは「リーンアジャイルリーダー」が不可欠とされています。
これらの価値観を把握した上で、チームが実力を発揮できるように環境を整えるサーバントリーダーです。
初期にウォーターフォールとアジャイルどちらを採用するかを判断したり、適切なメンバをアサインすることもあるでしょう。

「アジャイル宣言の背後にある原則」はリーダーなくして実現できません。

アジャイルの3つの役割（PO/SM/開発者）は変わらないものの、組織横断的リーダーシップの重要性が高まっています。

マーケ・営業・人事など事業部門でのアジャイル導入例が増加し、スクラムマスターがビジネス部門横断で調整役となる場面も増えています。

さらに、 「アジャイルリーダーシップ」 としてのスキル
― 目標と現場自律のバランス、学習と実験の促進、文化形成といった、伝統的なPMがまだ不得手な領域への対応力が求められます。

まとめ

• ウォーターフォールとアジャイルでは成功基準が根本的に異なる
  ― 計画通りの完遂ではなく、「価値が市場に届き続けること」がアジャイルの成功指標

• PMの役割は消えるのではなく再構成される
  ― PO・SM・開発者に分散されつつ、組織横断的なリーダーシップがより重要になる

• マインドセットの変革が不可欠
  ― 指示や管理ではなく、自己組織化を促進するサーバントリーダーとしての姿勢が求められる

• AI・クラウドの進化でアジャイルの価値創出サイクルはさらに加速
  ― フィードバックループ短縮、需要予測や品質改善など、意思決定の幅が広がる

• 「最適な進め方」はチームと時期ごとに変わる
  ― 決まった形はなく、経験者の支援やチーム全員での調整が成功の鍵となる

参考リンク