ソフトウェア開発炎上の検討 (in Japanese)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェア開発炎上の考察
Toshihiko.Yamakami@access-company.com
山上俊彦
IoT 事業本部, ACCESS
2016/07
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 1 / 58

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェア開発
プロジェクト炎上の
　鎮火方法を
　　捜す人が対象

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェア
プロジェクト炎上を
　複雑性の管理を
　　　基本に解説

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
目次
炎上とは
炎上を防ぐプロマネの仕事
PMO 外注の利点
ソフトウェア開発での複雑性管理
ソフトウェア開発は人の管理
複雑さの源泉は「顧客」
現在地点と到達地点の明確化
幸福な家は似たようだが不幸な家はそれぞれに不幸
メニューと対象範囲外
PMO 外注ビジネスの過去事例
炎上の本質
付録

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
炎上とは

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
炎上の定義
現状のままでは
完成せず品質上がらず
仕切り直しもできず
- 作業すればするほど
進捗が悪化する状態
【炎上の定義 http://www.4gamer.net/games/210/G021014/20130416053/　】
炎上は複雑性が単調に増加：炎上が終わったらデスマーチが始まる
コスト (C) の崩壊
(残業、休日出勤、
援軍)
-
品質 (Q) の崩壊
(仕様管理や
試験の手抜き)
-
納期 (D) の崩壊
(遅延、未完了
動かない)
【QCD 崩壊の 3 段階モデル】参考:http://lightgauge.net/soft-dev/journal/3548/を改
(なんらかの原因で管理放棄) (不整合拡大でプロセス放棄) (完了・未完了が混沌、
混乱が混乱を助長)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェア開発の炎上対策
ソフトウェア
開発は難しい
(7 割は失敗)
-
簡単に鎮火しない
原因の大部分は
上流工程
【ソフトウェア開発の課題の多くは上流工程: 複雑性の制御はここから始まる】
PMO - プロジェクト
マネジメントを
横断的に行う組織
【PM を支援する専門組織 PMO(Project Management Office) を設置】
(組織横断的機能)
・技術力不足よりもコミュニケーションやマネジメントの問題で炎上が圧倒的に多い

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
炎上プロジェクトのパターン
曖昧
頻繁な変更
(伝わらない)
対応する
機能項目がない
対応する
試験項目がない
【顧客仕様管理の問題】
作る前に
最終工程を考える
- 多くの炎上案件で
できていない
【詳細設計前に試験仕様を作る】
・性能仕様や安定化仕様はコーディング後に直すのは難しい
要件、役割
曖昧
- 丸投げ - 無吟味の
仕様変更
- 原因不明の
開発遅延
がんばります
- 破綻
【炎上のあるある時系列パターン】
(デスマーチ)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大きくても小さくても炎上は起こる
他プロジェクトや
掛け持ちの都合
- ずさんな仕様や
プロセス管理
- 現状把握の喪失と
爆弾の大量埋め込み
【小規模プロジェクトが炎上するのは必要資源配置不足: 　資源配置できない赤字受注も遠因】
・実行に必要資源をわりあてないで開始、ある意味、自業自得 (自分にふさわしい結末)
大規模
プロジェクト
- ソフト開発でなくても
規模自体が課題
【大規模プロジェクトが炎上するのは本質的複雑さとマネジメントの問題の掛け算】
・分割設計、コミュニケーション、組織間連携、…
・そもそも大規模プロジェクトの必要資源は誰にもわからない

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
炎上を防ぐプロマネの仕事

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
プロマネの仕事
カテゴリ仕事の例
統合チーム内の意思統一
スコープ目標、成果決定
タイム期限、スケジュール管理
コスト予算、費用管理
品質品質管理。バグ管理。
人的資源メンバーの能力管理、生産性向上
コミュニケーショ
ン
チーム内外との調整、情報共有
リスク人的リスク、時間リスクなど。
調達リソース調達、メンバー教育など

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
プロマネの基本
顧客を含めて
シンクロ
仕様、試験仕様を
固定
基本動作を
確認
人の感情、
文化を尊重
【プロマネの基本】
問題から逃げない
出し過ぎほど情報を出す
曖昧にしない
何を拾い、捨てるかの意識
人の好き嫌いで仕事をしない
問題点・対策を
全員から集約
人心を掌握
仕様を絞り
試験仕様を固定
顧客を含め
人間問題に対応
【失敗プロジェクトの炎上消火の基本】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
テクノロジーの利用
テクノロジーが
解決
- 深夜の会議、
深夜の文書レビュー
【テクノロジーの利用】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
単にプロマネの能力が低いだけでも炎上は起こる (軽微なケース)
誰でもいいから
援軍が欲しい
-
スキル把握、
要件、残存作業の
把握が甘い
【プロマネの能力が低いパターン：大して複雑でなくても大混乱】
問題の核心の
無視や隠蔽
-
最終地点不明確
残存案件と状態が
不明
-
見えない部分で
どんどん火の手で
対応不能に
【プロマネが原因で炎上する例】
何を作って
いるのかわかる
完了課題、残存課題
(未解決分の履歴) が
記録として存在
【鎮火できるパターン：残存課題を解決するスケジューリングが可能】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
PMO 外注の利点

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
元の当事者でないから解決できる
絶対に当事者
だけが解決可能
- 絶対に当事者
だけでは解決不能
【炎上プロジェクトの問題解決の 2 パターン】
炎上慣れ - 自分の不始末で
なければ気楽
【炎上プロジェクトの PMO (Project Management Office) をシニアがやるパターン】
(大規模開発の常)
・経験豊富なプロマネは不可能は不可能だし、銀の弾丸はないことを知っている (感性の鈍化)
・プロマネは誰もが救われた経験を持っている

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
船頭多くしてを防ぐ PM コーチング
体制はかえず
PM コーチングを実施
- 「聞く」に徹する
【専門スキル提供に加えてのコーチング効果】
正確な状況分析を提供
見捨てられていない上層部の本気変える視点提供
【コーチングの心理的誘導効果】
(絶望感の払拭) (解決のために投資) (問題継続なら変化必要)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェア開発での複雑性管理

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
炎上における複雑性の拡大
時間 →
複雑性
↑
時間 →
複雑性
↑
複雑性が減少する場合複雑性がある地点から発散する場合

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
複雑さの爆発
上流工程が
生む複雑さ
下流工程が
生む複雑さ
【複雑さの等比級数的爆発】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
複雑さを下げる: 複雑性の分解
本質的複雑さプロセスの
生む複雑さ
過去の組織的・
技術的負債
【複雑性の分解: 炎上ルートの把握】
他に人間関係、複雑さ自身の生む複雑さ
複雑さが許容越え
する仕組みの抑止
過去のダメージの
修復
仕切り直しの
仕組み作る
【鎮火のための複雑性の制御】
1. 複雑性制御不能原因の除去 2. 負の遺産の見える化と措置 3. 実行可能な開発運用の実践
仕様、プロマネ、プロセス、ツール仕様、コード、人間関係仕様管理、プロセス管理、組織管理

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
複雑さをあおるギャップ
問題ギャップ
仕様顧客と開発者
顧客社内発注者と顧客企業内ステークホルダー
仕様管理仕様管理者とそれ以外の開発チーム
開発社内 (仕様) 営業と開発チーム
受託者同士サブシステム開発チーム同士
受注連鎖 n-1 次請けと n 次受け
ヘルプオリジナルメンバと炎上後応援要員
チームリーダ開発サブチームリーダ同士
DevOps 開発と運用チーム　
開発チーム内開発者同士
下請け開発者と開発下請けチーム
国境開発チーム（プロマネ）とオフショア
開発社内 (試験) 開発チームと試験チーム
マネジメントプロマネと開発担当者
時間軸以前の開発者と現在の開発者

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
人月神話に学ぶ複雑性を下げる
人月の神話
(1975 年発行)
- 崩壊プロジェクト：
仕様削減しかない
【本当に崩壊したプロジェクトには「仕様削減」が基本的回答 (1975 年から変わらない)】
労力と進捗の混同 (労力進捗)
・人は「仕様削減するのは許されない」と叫ぶが、削減しないで動くのは稀
TSOL は
当初 60 人
- 最後は 1200 人
(6 年かけて中止)
【特許庁の 55 億円崩壊プロジェクト】
1 % の進捗を
定義
- 100 個積んだら
完成ではない
【複雑さの本質: リニアに落とすまでの労力のほうが大きい】
・100 % を定義すること自体の難しさを過小評価

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
シンプル化と複合対応
炎上チームは
体力低下：
シンプル化が必要
-
炎上時には複数の
問題が合併症
(個別にほぐす)
【炎上プロジェクトはシンプル化と複合対応】
・現在地、目標地点、行程の明確化
・わかっているつもりがわかっていなかった: 再認識

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェア開発は人の管理

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェアは「人」が作る
ソフトウェアは
人が作る
- ソフト以上に
人の管理が重要
【難局こそ人の管理が重要：モラル低下に適切に対応】
仕様管理や
線表管理を放棄
- プロジェクトは
炎上最終段階
【最後はプロマネの意識の糸が切れて、炎上は最終段階】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
モラル維持、目標の維持
炎上プロジェクトは
管理の強化や
進捗対策が失敗済
- まずモラル維持
(失敗の解きほぐし)
【炎上プロジェクトは進捗対策を失敗した過去: 再現にならないように解きほぐし、モラル維持】
・「マイナス」からのスタート: 急がば回れ
嘘をつく人間軽視責任転嫁
【炎上プロジェクトあるある】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
複雑さの源泉は「顧客」

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
顧客がわかっていなければ誰もわからない
クールな、とか
ブランドに合うという
曖昧な要件
- 炎上への一里塚
【顧客自身にわからなければ誰にもわからない】
・作ってみないとわからないという人は作ってもわからないことが多い
安価で強固で
高速で安全なという
要件
- 部署間調整は難しい
(特に大企業)
【顧客社内が部署毎に矛盾した要求 (経営企画、営業、情報システム、財務、…)】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
開発プロセスの一部としての「顧客」
ソフトウェア開発は
論理的な構成の
追求
- 最も論理的でない
構成要素は「顧客」
【「顧客」は開発プロセスの一部：　本質的でない「複雑さ」を作るのを抑制すべき)】
「自分は善人で
開発者は嘘つきで
悪人」ではない
「自分の逸脱は状況、
相手の逸脱は人格」
ではない
【顧客は自制すべき: 開発と人間への深い洞察でお互いに幸福になれる】
・嘘、裏切り、矛盾、責任転嫁、は開発者の専売特許ではない
プロジェクトの
最終目的と
成功の尺度
仕様の一貫性と
論理性
開発プロセスの
一部として
正しく機能
【顧客が念頭におくべきこと】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
成功する開発に必要な「顧客との握り」
仕様変更や
プロジェクト管理
- 顧客とのシンクロが
必要
【「顧客」が重要なプロジェクト管理要素：ここを管理しないとうまくいかない】
・動かなければ困るのは顧客、をご理解いただく (on the same page)
・発注側の力が強いほど炎上する比率は大きい
プロマネは
複雑さを制御
- 複雑さの源泉は
顧客
【崩壊したプロジェクトは「複雑さとの戦いに敗北した結果」】
・短納期や納期重なりで破綻するプロジェクトは「顧客側作業」の過小評価
・複雑さが管理できないならマイクロマネジメントしても新しく創出される複雑さで破綻

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
現場が取れない仮想解
マネジメント含め
リプレース
- フルスクラッチで
作り直す
【仮想解：諸般の事情で難しい】
・これができれば「複雑骨折」状態にはなっていない
・顧客側で作られる複雑さが問題解決していることが前提
デスマーチ - 事実上毎日
バグを再生産
【デスマーチで上流工程の失敗やサブプロジェクト間の連携ミスを解決することはできない】
・懲罰的意味以上のものはない
(不眠不休徹夜作業)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
現在地点と到達地点の明確化

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20 % くらいなら「見える化」で解決可能
燃費改善
魔法のセラミック
数千台で 15 % 改善
-
実は無効果
意識と声掛けで
改善
【見える化の効果: 魔法のセラミックの例】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
処理可能に分解
管理できる
単位に分解
-
管理できるものを
トレースして
見える化
【現在時点の見える化】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
何が 100 % かわからない進捗管理から脱却
何が 100 % か
わかっていない
- 定義できない
進捗管理に固執
【炎上プロジェクトあるある：全体が何かが把握できない】
「きちんとやればできるはず」：正論だが何が全体かわからない人には無意味
・自分がわかっていないことを知らないで管理するのが不幸の源泉
見えるものに
引きずられる
- 見えないものの
管理が疎か
【炎上プロジェクトあるある：管理が UI とかバグ票とか見えるものに偏重】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
順工程が駄目なら逆工程から考える
最後に何の試験を
したら終わりか
- コーディングの
前に合意
【最終地点から逆算する】
・性能仕様や安定化仕様も含めて試験項目と試験データを考える

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
幸福な家は似たようだが
不幸な家はそれぞれに不幸

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフト開発は同じ、という幻想
ソフトウェア開発は
同じ
- 要件と顧客が
同じという条件付き
【開発者の「ソフトは全て同一視する」傾向】
・炎上には「俺が考えた開発管理」が出るが、プロジェクトは千差万別：個別対応が必要
10 人未満 - 3000 人以上
【ソフトウェア開発プロジェクトのスペクトラムは広い】
みずほ銀行の勘定系更改は 8000 人少人数でも必須手順を省けば炎上

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
チェックリストでは解決しない
炎上があると
事故調査
- チェックリストが
作られるが
炎上防止は限定的
【チェックリストでプロジェクト炎上を防ぐのは難しい：失敗への道は多数ある】
基盤選択ミス、
IF ミスマッチ
顧客側
不信感増幅
人間関係や
相性
予定外の
人事
性能などの
設計不足
下請け
能力不足
試験生産性
不足
予定外の
納期変更
問題はいろいろ: プロジェクトは生き物、それぞれに違う (人は自分の成功体験に合わせようとする)】
・仕様管理、試験管理、サブチームの成果同期問題、開発環境管理、など

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
技術的負債と組織的負債はプロジェクトそれぞれ
組織的負債技術的負債
過去の不適切な対応：未来に残す支払い
【組織的負債と技術的負債：本来の根本的解決の先送り】
誤った処遇、ルール、
不適切な例外扱い、時代錯誤な手続き、
顧客に誤った期待を与える対応、など
バグを隠す分岐、安易なコピペ、
性能改善のための安易な近道など

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
プロジェクト末期は精神状態管理から
正論は
聞きたくない
- 不毛な過去を
否定したくない
【プロジェクト末期の精神状態：論理的に考えたくない、をほぐしていく】
・ストックホルム症候群的状況 (誘拐被害者が誘拐犯に同情) からの解放
論理的管理を
放棄した状態
- 論理的管理へ
収束
【論理的管理へ戻し、ひとつずつ作業を消化していく】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
現実に即して管理
工程分解、
文書、レビューを
適切粒度で
結局ソース
PMO でしっかり
ソースを把握
【現実に即して管理】
・過剰管理しない (不足もダメ)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
メニューと対象範囲外

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
メニュー
PM 代行
(仕様変更可能)
- フルスクラッチで
マネジメント再構築
【フルサービス：　全体制御権限がある場合 (PM: Project Manager)】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
サブメニュー
部分 PM 代行
(20-25 時、土日祝日) PM コーチング
【サブサービス：PM を補佐】
PM に戦略思考時間を与える
スケジュール、
マイルストーン管理
ステークホルダ
ミーティング事務局
試験仕様、
試験環境作成
【マイクロサービス：部分的切り出し】
(顧客、外部開発、…)
最終地点：試験項目が未定義の場合

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
対応範囲外
顧客が問題だが
事情で問題解決不能
人事上の問題放置デスマーチで
勤務を是とする
【合理的解決を求めていない案件】
(懲罰、パワハラ、…)
約束不履行再犯で調整不能
・他に: 巨大すぎて仕様管理できない案件 (四次請け、五次請け、…)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
PMO 外注ビジネスの過去事例

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
クロスリンク・コンサルティングの事例
拜原創業者が
炎上消火を事業に
- 結構流行っていたが
創業者が病気で交代
【昔、クロスリンク・コンサルティングという会社が炎上プロマネのコンサルで流行った】
会社は失敗
プロジェクトを隠す
- 失敗プロジェクトを
見つける営業力が鍵
【クロスリンク・コンサルティングの成功の理由】
創業メンバの高齢化
(65 歳以上)
- 深夜まで対策会議、
【クロスリンク・コンサルティングの停滞の理由：体力的限界】
早朝から顧客謝罪行脚はきつい

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
炎上の本質

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
炎上は三者の美しいオーケストラ
経営陣
顧客
プロジェクト
マネージャ
【炎上は三者の美しいオーケストラ：40 % 顧客、35 % プロマネ、25 % 経営陣の責任】
上流は無管理、下流は過剰管理
高度工程に人材確保できない赤字受注
全体管理の放棄、一貫性のない管理
仕様管理や試験管理の手抜き
目的、出力の曖昧さ。開発当事者意識の薄さ
・多くの場合、上流で複雑さを作りだす顧客と経営陣の改善は放置
言うべきことが
言えなくなる
- ソフトウェア開発で
なくても危険な兆候
【「言うべきことを言い」、「論理性を重んじる」　できないと炎上】
・全員が正しい現状認識、目標、到達プロセスを共有
情報共有の前提: 信頼感: 誠実、ぎりぎりの情報も開示、聞く姿勢、人として尊重、目的を達成する意

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
付録

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
IT おとぎ話と三次請けあるある
一番上の子豚は
仕様なしで作り
炎上
-
二番目の子豚は
人海戦術で作り
炎上
-
一番下の子豚は
緻密な検討と余裕の
線表で、失注
【それじゃダメじゃん：IT おとぎ話三匹の子豚】
金がもらえるなら
炎上プロジェクトは
いやではない
- それ以上
悪化しないから
【三次請けあるある】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
終結の 3 パターン
トップ同士が合意
ハードランディング
マネージャや
チームを入替
仕切り直し
社員や下請けが
デスマーチ
【終結の 3 パターン】
「開発中止」という
選択肢を入れる
- 上長は
全部資料を読む
【仕切り直しの資料を上長に読ませる方法 (by 山本一郎)】
・上長は「開発中止」したくないという強いインセンティブがある

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
顧客のあるべき姿勢
目的が明確、
仕様を固定、
厳密に変更管理
- 詳細設計前に
試験項目を明示
【炎上防止のために顧客のあるべき姿勢 3 社分割発注プロジェクトの例】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
参考文献 I
鎮火する炎上プロジェクトと、鎮火しないプロジェクト（2014 年）
http://www.tailpiece.jp/projectmanagement/286/
多数決で仕様を決めて“炎上”、少数意見に目を向けよ　 (2015 年)
http://itpro.nikkeibp.co.jp/atcl/column/14/120500119/061200018
「進捗どうですか？」と聞かれなくて済む、カンバンと Git で始める進捗管理を自動化する
方法 http://www.publickey1.jp/blog/15/atlgit.html
残業だらけの現場－ソフトウェア業界のとあるプロジェクト　
http://xn–idrw77cppbb4d.com/?p=24
デスマーチ・激務に巻き込まれたアナタが取るべき 12 の対策【メンバー編】(2015 年)
http://wiz7.hatenablog.com/entry/2015/03/30/060000
もはやプロジェクト炎上を防ぐ手段は無い　（2009 年 10 月）　
http://d.hatena.ne.jp/fulic/20091018/1255868644
第 3 回　プロジェクト炎上を防ぐには（2009 年)
http://gihyo.jp/lifestyle/serial/01/dilemma/0003
なぜ、いまだ 7 割の IT プロジェクトが失敗するのか？「再生人」が明かす炎上メカニズ
ムと立て直しの知恵 (2013 年) http://type.jp/et/feature/233
炎上プロジェクトの責任はプロマネが９割 (2014 年)
http://getlife.hateblo.jp/entry/2014/01/26/045603

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
参考文献 II
IT・Web 系エンジニアの「三次請けあるある」　 (2015 年)
http://next.rikunabi.com/tech_souken/entry/ct_s03600p002455
システム開発プロジェクトはなぜ“カオス化”するのか　（2013 年)
http://www.itmedia.co.jp/enterprise/articles/1302/20/news003.html
システム開発で炎上した時に自分だけ助かる方法を経験者が教えます (2015 年) 　
http://mikumikuplay.com/it/enjou-tasukaru-houhou/
なぜ、プロジェクトの 7 割が失敗するのか？
http://www.cisco.com/web/JP/news/cisco_news_letter/mail/0210/special/index.html
システム開発プロジェクトの失敗事例の原因とその対策方法　（2014 年)
http://liginc.co.jp/life/business/88342
プロジェクト炎上のメカニズムと早期発見，行うべき処理の概論　 (2013 年)
http://www.4gamer.net/games/210/G021014/20130416053/
炎上プロジェクトと QCD 崩壊の関連性について　 (2014 年)
http://lightgauge.net/soft-dev/journal/3548/
プロジェクトは何故炎上するのか | UTAGE BLOG (2014 年)
https://utage.headwaters.co.jp/blog/?p=3840
山本一郎氏が語る、プロジェクト炎上のメカニズムと鎮火法 (2013 年)
http://www.atmarkit.co.jp/ait/articles/1304/16/news105.html
プロトタイプ開発の日々: 炎上プロジェクトに見られる 3 つの共通点 (2010 年)
http://el.jibun.atmarkit.co.jp/karutaya/2010/09/3-6d63.html

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
参考文献 III
特許庁の 55 億かけて頓挫したプロジェクトの報告書が面白い　 (2012 年)
http://anond.hatelabo.jp/20120127061544
プロジェクトマネージャなら必ず意識したい！炎上しないプロジェクトの進め方 (2014
年) 　 http://crunchtimer.jp/blog/technology/839/
本当に残酷な IT 業界の童話たち〜「そうだ、このマッチでプロジェクトを炎上させれ
ば・・・」(2013 年) http://it-ura.seesaa.net/article/375319441.html
開発を確実に炎上させる 3 つのこと http://xn–972-
o73bf2b4jwbzftixktbzfvb4o4tqfvmg57147a.com/%E3%82%A8%E3%83%83%E3%82%BB%E3
ブルックスの法則, Wikipedia
人月の神話, Wikipedia
問題プロジェクトの火消し術、長尾清一 (2007)

ソフトウェア開発炎上の検討 (in Japanese)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to ソフトウェア開発炎上の検討 (in Japanese)

Similar to ソフトウェア開発炎上の検討 (in Japanese) (20)

More from Toshihiko Yamakami

More from Toshihiko Yamakami (20)

ソフトウェア開発炎上の検討 (in Japanese)