既存プロセスの体系 ／ 種別: ハイブリッド開発の実態(アンチパターンを含む現実の運用)
スクラム/アジャイルを名乗りながら、原典の設計から逸脱し価値を生まない運用形態の総称。日本企業で実際に起きている「建前はスクラム、実態は混乱」という From の実態
ひとことで言うと: イベントやロール名という「形」だけを輸入し、経験主義・自己組織化・単一責任という「魂」を輸入し損ねた状態。日本ではこれに稟議・合議・品質ゲート文化が接ぎ木されて固有の形になる。ただしすべてが「悪」ではなく、境界を意識的に設計した過渡形なら有効な場合もある
全体マップ(第1階層)
各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。
graph LR
ph0["Water(前段=ウォーターフォール)"]
ph1["Scrum(中段=反復)"]
ph0 -->|"要件承認ゲート(前段WF)"| ph1
ph2["Fall(後段=ウォーターフォール)"]
ph1 -->|"スプリントレビューの検収化"| ph2
gEnd{"リリース承認ゲート(後段WF)"}
ph2 --> gEnd
click ph0 "/process-compass/processes/hybrid/water/" "Water(前段=ウォーターフォール)の詳細へ"
click ph1 "/process-compass/processes/hybrid/scrum/" "Scrum(中段=反復)の詳細へ"
click ph2 "/process-compass/processes/hybrid/fall/" "Fall(後段=ウォーターフォール)の詳細へ"目的と成果
目的(purpose): 既存の WF 型ガバナンス・決裁構造を維持したまま、開発工程だけを反復化して「アジャイルをやっている」体裁を得る(実際に果たしている機能)
成果(outcomes):
- イベントは実施されるがリリース可能なインクリメントが稀にしか生まれない(ゾンビスクラム)
- 意思決定が合議で滞留しスプリントが空回りする
- 開発は速くなってもリリース前決裁がボトルネックになる
- 開発者の疲弊・モラール低下(ダークスクラム)
原典: Dave West / Forrester「Water-Scrum-Fall」(2011)。ほか Ron Jeffries「Dark Scrum」、Christiaan Verwijs「Zombie Scrum」、Stefan Wolpers の PO アンチパターン集
ISO/IEC/IEEE 12207 対応: 主に「該当なし(正規のプロセスではなく逸脱形態の観察対象)」プロセス群をカバー
ロール
| ロール | 責任 | 日本の現場での実態 |
|---|
| プロキシPO(代理プロダクトオーナー) | 【アンチパターン】決定権も顧客への直接アクセスも持たないまま PO 席に座る | スクラムガイドは「PO は1人の人間であり委員会ではない」と明記。代理POはボトルネック化し、優先順位のズレと意思決定遅延を招く |
| PO委員会 / 企画部門によるPO代行 | 【アンチパターン】部署単位・委員会でバックログの優先順位を決める(prioritization by proxy) | 稟議・合議文化が「1人のPO」を制度的に拒む。Wolpers は「その権限を奪うとスクラムは強力な waterfall 2.0 に変わる」と指摘 |
| 過剰な承認者・調整役・部門代表 | 【アンチパターン】PO/SM/開発者の3責任以外に、承認者・レビュアー・部門代表が大量に存在する | 責任分散文化(合議で誰も単独責任を負わない)と多段稟議・深い階層により、各部門が「関与しないと責任問題になる」ため関係者が積み上がる |
| 上司を兼ねる SM / 権力保持者 | 【アンチパターン】管理職が SM/PO を兼ね、旧来のコマンド&コントロールを温存する | デイリーが監視・命令の場に、レビューが失敗糾弾に、レトロが改善却下に転化する(ダークスクラム)。SM は本来「真のリーダー」で管理者ではない |
ゲート(決裁・レビュー)
| ゲート | 種別 | Deliverables | 判定基準 | 判定者 | 判定結果 |
|---|
| 要件承認ゲート(前段WF) ※スクラムが排除したはずの事前固定ゲート。年度予算主義と稟議構造が要求する | 決裁(Go/Kill) | 要件定義書 | 範囲・予算の合意 | 企画部門/決裁階層(合議) | Go / 差し戻し |
| スプリントレビューの検収化 ※スクラムガイドは「レビューを価値リリースのゲートと見なしてはならない」と明文で禁止。実態では検収イベント化する | 決裁(Go/Kill) | インクリメント | 発注側の受入基準 | 発注側ステークホルダー | 承認 / 手戻り |
| リリース承認ゲート(後段WF) ※「承認待ち」滞留が復活し、反復のリズムが決裁サイクルに律速される | 決裁(Go/Kill) | リリース判定資料 | 品質ゲート・QA部門承認 | 品質保証部門/運用部門(多段決裁) | Go / Hold |
成果物(information items)
| 成果物 | 作成者 | 説明 |
|---|
| 先に固定された要件定義書(前段WF) | — | アジャイルチームが関与する前に範囲・予算・スケジュールが確定される |
| インクリメント(検収対象化) | — | 本来は検査イベントの対象だが、実態では発注側の受入・検収の対象になる |
アンチパターン(建前 vs 実態)
AP-1 Water-Scrum-Fall(要件とリリースをWFで挟む)
| 建前(あるべき姿) | スクラムはフェーズ列を持たず、意思決定は PO の並び替え・DoD・スプリントゴールに分散・常時化される |
|---|
| 実態 | 予算・範囲・スケジュールを先に固定し、真ん中だけ反復する。Forrester は「大半の組織にとってこれがアジャイルの現実」と観測 |
|---|
| なぜ起きるか | 一括請負・検収の商慣行、年度予算主義、上流で承認を固めないと稟議が通らない構造 |
|---|
| 弊害 | 反復で得た学習を要件・リリース計画に還流できない。「開発は速いがリリースは遅い」乖離 |
|---|
AP-2 単一PO原則の崩壊(複数PO / PO委員会 / 企画部PO / プロキシPO)
| 建前(あるべき姿) | スクラムガイドは明文で「プロダクトオーナーは1人の人間であり委員会ではない」と規定。作業は委譲できるが結果責任は PO に残る |
|---|
| 実態 | PO が複数名いる、企画部など部署単位でPO機能を運用、現場には決定権のないプロキシPOだけが座る |
|---|
| なぜ起きるか | 稟議・合議・根回し文化。単独者に重要決定の権限と責任を集中させることを組織が忌避し、部門横断の合意形成を正とする |
|---|
| 弊害 | 意思決定の滞留、優先順位の一貫性喪失、スクラムの「waterfall 2.0」化 |
|---|
AP-3 役割肥大・関係者過多
| 建前(あるべき姿) | スクラムチームは通常10名以下でサブチームも階層もない。ガイドは管理階層・組織上独立したレビュー部門・PMOを一切定義しない |
|---|
| 実態 | PO/SM/開発者の3責任以外に、承認者・調整役・レビュアー・部門代表が大量に存在する。複数の「上司」がデイリーやレビューに参加する |
|---|
| なぜ起きるか | 責任分散文化と多段稟議・深いピラミッド構造。各部門が「関与しないと責任問題になる」ため関係者が積み上がる |
|---|
| 弊害 | ステークホルダー過多で意思決定が進まない。会議コスト増大。自己組織化の阻害 |
|---|
AP-4 ゾンビスクラム(心拍のないスクラム)
| 建前(あるべき姿) | スプリントごとに「完成の定義」を満たす利用可能なインクリメントが少なくとも1つ生まれる |
|---|
| 実態 | 全イベントを実施するが、動くソフトがほぼ無い / 貧弱なDoD / 外の世界との接触を避ける / 低いモラールと諦め(Verwijs の4症状) |
|---|
| なぜ起きるか | 上流でスコープが固定され開発が作業消化化し、レビューが承認プレゼン化して顧客との真の対話がない |
|---|
| 弊害 | 「アジャイルなメリットを感じたことがない」状態が固定化する |
|---|
AP-5 ダークスクラム(開発者を抑圧する道具への転化)
| 建前(あるべき姿) | SM は「真のリーダー」でチームの自己管理・障害物除去を支援する。管理者・進捗報告者ではない |
|---|
| 実態 | 権力保持者(管理職・PO・SM)がスクラムの器で開発者を監視・強制する。デイリーが監視、プランニングが押し付け、レトロが脅迫的動機づけに転化する |
|---|
| なぜ起きるか | 旧来のコマンド&コントロール型管理を温存したままロール名だけ変える。上司がPO/SMを兼ねる |
|---|
| 弊害 | 開発者の疲弊・離職・心理的安全性の欠如。「持続可能な開発」原則の破壊 |
|---|
AP-6 WF決裁ゲートのスクラムへの接ぎ木
| 建前(あるべき姿) | スクラムには Go/Kill 型のフェーズゲートがない。「スプリントレビューを価値リリースのゲートと見なしてはならない」と明文で禁止 |
|---|
| 実態 | 要件承認・設計承認・リリース承認といったWFの直列決裁ゲートがスプリントの前後に差し込まれ、レビューが検収ゲート化する |
|---|
| なぜ起きるか | 品質ゲートは「日本の品質レベルを支えてきた技術」と位置づけられ手放しにくい。稟議による多段決裁が制度化されている |
|---|
| 弊害 | 「承認待ち」滞留の復活。反復のリズムが決裁サイクルに律速される |
|---|
建前と実運用(日本の現場)
- 共通の病理は「構造の輸入・中核の非輸入」。イベント・ロール名という観察可能な形だけを移植し、経験主義・自己組織化・単一責任という中核を移植し損ねている
- 海外のアンチパターンは「権力の誤用」「動機の欠如」が主因だが、日本ではこれに制度化された合議・多段決裁が加わり、単一PO崩壊とロール肥大が「個人の失敗」でなく「組織構造の既定値」として現れる
- 健全なハイブリッドか無自覚なアンチパターンかの判別軸は、(a)境界線が明示設計されているか、(b)反復の学習が上流・リリースに還流するか、(c)単一の価値判断者が実在するか。この3軸で診断できる
フェーズ一覧(第2階層へ)
参考文献