Embed Size (px)
Citation preview
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフトウェア開発炎上の考察[email protected]
山上俊彦
IoT 事業本部, ACCESS
2016/07
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 1 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフトウェア開発プロジェクト炎上の 鎮火方法を 捜す人が対象
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 2 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフトウェアプロジェクト炎上を 複雑性の管理を 基本に解説
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 3 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
目次
炎上とは
炎上を防ぐプロマネの仕事
PMO 外注の利点ソフトウェア開発での複雑性管理
ソフトウェア開発は人の管理
複雑さの源泉は「顧客」
現在地点と到達地点の明確化
幸福な家は似たようだが不幸な家はそれぞれに不幸
メニューと対象範囲外
PMO 外注ビジネスの過去事例炎上の本質
付録
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 4 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
炎上とは
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 5 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
炎上の定義
現状のままでは完成せず品質上がらず仕切り直しもできず
- 作業すればするほど進捗が悪化する状態
【炎上の定義 http://www.4gamer.net/games/210/G021014/20130416053/ 】
炎上は複雑性が単調に増加：炎上が終わったらデスマーチが始まる
コスト (C) の崩壊(残業、休日出勤、
援軍)-
品質 (Q) の崩壊(仕様管理や試験の手抜き)
-納期 (D) の崩壊(遅延、未完了動かない)
【QCD 崩壊の 3 段階モデル】参考:http://lightgauge.net/soft-dev/journal/3548/を改
(なんらかの原因で管理放棄) (不整合拡大でプロセス放棄) (完了・未完了が混沌、混乱が混乱を助長)
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 6 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフトウェア開発の炎上対策
ソフトウェア開発は難しい(7 割は失敗)
- 簡単に鎮火しない原因の大部分は上流工程
【ソフトウェア開発の課題の多くは上流工程: 複雑性の制御はここから始まる】
PMO - プロジェクトマネジメントを横断的に行う組織
【PM を支援する専門組織 PMO(Project Management Office) を設置】
(組織横断的機能)
・技術力不足よりもコミュニケーションやマネジメントの問題で炎上が圧倒的に多い
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 7 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
炎上プロジェクトのパターン
曖昧 頻繁な変更(伝わらない)
対応する機能項目がない
対応する試験項目がない
【顧客仕様管理の問題】
作る前に最終工程を考える
- 多くの炎上案件でできていない
【詳細設計前に試験仕様を作る】
・性能仕様や安定化仕様はコーディング後に直すのは難しい
要件、役割曖昧
- 丸投げ - 無吟味の仕様変更
- 原因不明の開発遅延がんばります
- 破綻
【炎上のあるある時系列パターン】
(デスマーチ)
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 8 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
大きくても小さくても炎上は起こる
他プロジェクトや掛け持ちの都合
- ずさんな仕様やプロセス管理
- 現状把握の喪失と爆弾の大量埋め込み
【小規模プロジェクトが炎上するのは必要資源配置不足: 資源配置できない赤字受注も遠因】
・実行に必要資源をわりあてないで開始、ある意味、自業自得 (自分にふさわしい結末)
大規模プロジェクト
- ソフト開発でなくても規模自体が課題
【大規模プロジェクトが炎上するのは本質的複雑さとマネジメントの問題の掛け算】
・分割設計、コミュニケーション、組織間連携、…・そもそも大規模プロジェクトの必要資源は誰にもわからない
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 9 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
炎上を防ぐプロマネの仕事
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 10 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
プロマネの仕事
カテゴリ 仕事の例統合 チーム内の意思統一スコープ 目標、成果決定タイム 期限、スケジュール管理コスト 予算、費用管理品質 品質管理。バグ管理。人的資源 メンバーの能力管理、生産性向上コミュニケーション
チーム内外との調整、情報共有
リスク 人的リスク、時間リスクなど。調達 リソース調達、メンバー教育など
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 11 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
プロマネの基本
顧客を含めてシンクロ
仕様、試験仕様を固定
基本動作を確認
人の感情、文化を尊重
【プロマネの基本】
問題から逃げない出し過ぎほど情報を出す
曖昧にしない何を拾い、捨てるかの意識
人の好き嫌いで仕事をしない
問題点・対策を全員から集約 人心を掌握 仕様を絞り
試験仕様を固定顧客を含め
人間問題に対応
【失敗プロジェクトの炎上消火の基本】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 12 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
テクノロジーの利用
テクノロジーが解決
- 深夜の会議、深夜の文書レビュー
【テクノロジーの利用】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 13 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
単にプロマネの能力が低いだけでも炎上は起こる (軽微なケース)
誰でもいいから援軍が欲しい
- スキル把握、要件、残存作業の把握が甘い
【プロマネの能力が低いパターン：大して複雑でなくても大混乱】
問題の核心の無視や隠蔽
- 最終地点不明確残存案件と状態が
不明- 見えない部分で
どんどん火の手で対応不能に
【プロマネが原因で炎上する例】
何を作っているのかわかる
完了課題、残存課題(未解決分の履歴) が記録として存在
【鎮火できるパターン：残存課題を解決するスケジューリングが可能】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 14 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
PMO 外注の利点
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 15 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
元の当事者でないから解決できる
絶対に当事者だけが解決可能
-� 絶対に当事者だけでは解決不能
【炎上プロジェクトの問題解決の 2 パターン】
炎上慣れ - 自分の不始末でなければ気楽
【炎上プロジェクトの PMO (Project Management Office) をシニアがやるパターン】
(大規模開発の常)
・経験豊富なプロマネは不可能は不可能だし、銀の弾丸はないことを知っている (感性の鈍化)・プロマネは誰もが救われた経験を持っている
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 16 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
船頭多くしてを防ぐ PM コーチング
体制はかえずPM コーチングを実施
- 「聞く」に徹する
【専門スキル提供に加えてのコーチング効果】
正確な状況分析を提供
見捨てられていない 上層部の本気 変える視点提供
【コーチングの心理的誘導効果】
(絶望感の払拭) (解決のために投資) (問題継続なら変化必要)
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 17 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフトウェア開発での複雑性管理
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 18 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
炎上における複雑性の拡大
時間 →
複雑性
↑
時間 →
複雑性
↑
複雑性が減少する場合 複雑性がある地点から発散する場合
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 19 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
複雑さの爆発
上流工程が生む複雑さ
下流工程が生む複雑さ
【複雑さの等比級数的爆発】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 20 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
複雑さを下げる: 複雑性の分解
本質的複雑さ プロセスの生む複雑さ
過去の組織的・技術的負債
【複雑性の分解: 炎上ルートの把握】
他に人間関係、複雑さ自身の生む複雑さ
複雑さが許容越えする仕組みの抑止
過去のダメージの修復
仕切り直しの仕組み作る
【鎮火のための複雑性の制御】1. 複雑性制御不能原因の除去 2. 負の遺産の見える化と措置 3. 実行可能な開発運用の実践
仕様、プロマネ、プロセス、ツール 仕様、コード、人間関係 仕様管理、プロセス管理、組織管理
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 21 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
複雑さをあおるギャップ
問題 ギャップ仕様 顧客と開発者顧客社内 発注者と顧客企業内ステークホルダー仕様管理 仕様管理者とそれ以外の開発チーム開発社内 (仕様) 営業と開発チーム受託者同士 サブシステム開発チーム同士受注連鎖 n-1 次請けと n 次受けヘルプ オリジナルメンバと炎上後応援要員チームリーダ 開発サブチームリーダ同士DevOps 開発と運用チーム 開発チーム内 開発者同士下請け 開発者と開発下請けチーム国境 開発チーム（プロマネ）とオフショア開発社内 (試験) 開発チームと試験チームマネジメント プロマネと開発担当者時間軸 以前の開発者と現在の開発者
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 22 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
人月神話に学ぶ複雑性を下げる
人月の神話(1975 年発行)
- 崩壊プロジェクト：仕様削減しかない
【本当に崩壊したプロジェクトには「仕様削減」が基本的回答 (1975 年から変わらない)】
労力と進捗の混同 (労力 � 進捗)・人は「仕様削減するのは許されない」と叫ぶが、削減しないで動くのは稀
TSOL は当初 60 人
- 最後は 1200 人(6 年かけて中止)
【特許庁の 55 億円崩壊プロジェクト】
1 % の進捗を定義
- 100 個積んだら完成ではない
【複雑さの本質: リニアに落とすまでの労力のほうが大きい】
・100 % を定義すること自体の難しさを過小評価
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 23 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
シンプル化と複合対応
炎上チームは体力低下：
シンプル化が必要-� 炎上時には複数の
問題が合併症(個別にほぐす)
【炎上プロジェクトはシンプル化と複合対応】
・現在地、目標地点、行程の明確化・わかっているつもりがわかっていなかった: 再認識
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 24 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフトウェア開発は人の管理
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 25 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフトウェアは「人」が作る
ソフトウェアは人が作る
- ソフト以上に人の管理が重要
【難局こそ人の管理が重要：モラル低下に適切に対応】
仕様管理や線表管理を放棄
- プロジェクトは炎上最終段階
【最後はプロマネの意識の糸が切れて、炎上は最終段階】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 26 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
モラル維持、目標の維持
炎上プロジェクトは管理の強化や進捗対策が失敗済
- まずモラル維持(失敗の解きほぐし)
【炎上プロジェクトは進捗対策を失敗した過去: 再現にならないように解きほぐし、モラル維持】
・「マイナス」からのスタート: 急がば回れ
嘘をつく 人間軽視 責任転嫁
【炎上プロジェクトあるある】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 27 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
複雑さの源泉は「顧客」
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 28 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
顧客がわかっていなければ誰もわからない
クールな、とかブランドに合うという
曖昧な要件- 炎上への一里塚
【顧客自身にわからなければ誰にもわからない】
・作ってみないとわからないという人は作ってもわからないことが多い
安価で強固で高速で安全なという
要件- 部署間調整は難しい
(特に大企業)
【顧客社内が部署毎に矛盾した要求 (経営企画、営業、情報システム、財務、…)】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 29 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
開発プロセスの一部としての「顧客」
ソフトウェア開発は論理的な構成の
追求- 最も論理的でない構成要素は「顧客」
【「顧客」は開発プロセスの一部： 本質的でない「複雑さ」を作るのを抑制すべき)】
「自分は善人で開発者は嘘つきで悪人」ではない
「自分の逸脱は状況、相手の逸脱は人格」
ではない
【顧客は自制すべき: 開発と人間への深い洞察でお互いに幸福になれる】
・嘘、裏切り、矛盾、責任転嫁、は開発者の専売特許ではない
プロジェクトの最終目的と成功の尺度
仕様の一貫性と論理性
開発プロセスの一部として正しく機能
【顧客が念頭におくべきこと】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 30 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
成功する開発に必要な「顧客との握り」
仕様変更やプロジェクト管理
- 顧客とのシンクロが必要
【「顧客」が重要なプロジェクト管理要素：ここを管理しないとうまくいかない】
・動かなければ困るのは顧客、をご理解いただく (on the same page)・発注側の力が強いほど炎上する比率は大きい
プロマネは複雑さを制御
- 複雑さの源泉は顧客
【崩壊したプロジェクトは「複雑さとの戦いに敗北した結果」】
・短納期や納期重なりで破綻するプロジェクトは「顧客側作業」の過小評価・複雑さが管理できないならマイクロマネジメントしても新しく創出される複雑さで破綻
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 31 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
現場が取れない仮想解
マネジメント含めリプレース
- フルスクラッチで作り直す
【仮想解：諸般の事情で難しい】
・これができれば「複雑骨折」状態にはなっていない・顧客側で作られる複雑さが問題解決していることが前提
デスマーチ - 事実上毎日バグを再生産
【デスマーチで上流工程の失敗やサブプロジェクト間の連携ミスを解決することはできない】
・懲罰的意味以上のものはない
(不眠不休徹夜作業)
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 32 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
現在地点と到達地点の明確化
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 33 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
20 % くらいなら「見える化」で解決可能
燃費改善魔法のセラミック数千台で 15 % 改善
- 実は無効果意識と声掛けで
改善
【見える化の効果: 魔法のセラミックの例】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 34 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
処理可能に分解
管理できる単位に分解
- 管理できるものをトレースして見える化
【現在時点の見える化】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 35 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
何が 100 % かわからない進捗管理から脱却
何が 100 % かわかっていない
-� 定義できない進捗管理に固執
【炎上プロジェクトあるある：全体が何かが把握できない】
「きちんとやればできるはず」：正論だが何が全体かわからない人には無意味・自分がわかっていないことを知らないで管理するのが不幸の源泉
見えるものに引きずられる
- 見えないものの管理が疎か
【炎上プロジェクトあるある：管理が UI とかバグ票とか見えるものに偏重】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 36 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
順工程が駄目なら逆工程から考える
最後に何の試験をしたら終わりか
- コーディングの前に合意
【最終地点から逆算する】
・性能仕様や安定化仕様も含めて試験項目と試験データを考える
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 37 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
幸福な家は似たようだが不幸な家はそれぞれに不幸
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 38 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
ソフト開発は同じ、という幻想
ソフトウェア開発は同じ
- 要件と顧客が同じという条件付き
【開発者の「ソフトは全て同一視する」傾向】
・炎上には「俺が考えた開発管理」が出るが、プロジェクトは千差万別：個別対応が必要
10 人未満 -� 3000 人以上【ソフトウェア開発プロジェクトのスペクトラムは広い】
みずほ銀行の勘定系更改は 8000 人少人数でも必須手順を省けば炎上
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 39 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
チェックリストでは解決しない
炎上があると事故調査
- チェックリストが作られるが
炎上防止は限定的
【チェックリストでプロジェクト炎上を防ぐのは難しい：失敗への道は多数ある】
基盤選択ミス、IF ミスマッチ
顧客側不信感増幅
人間関係や相性
予定外の人事
性能などの設計不足
下請け能力不足
試験生産性不足
予定外の納期変更
【問題はいろいろ: プロジェクトは生き物、それぞれに違う (人は自分の成功体験に合わせようとする)】
・仕様管理、試験管理、サブチームの成果同期問題、開発環境管理、など
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 40 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
技術的負債と組織的負債はプロジェクトそれぞれ
組織的負債 技術的負債
過去の不適切な対応：未来に残す支払い【組織的負債と技術的負債：本来の根本的解決の先送り】
誤った処遇、ルール、不適切な例外扱い、時代錯誤な手続き、顧客に誤った期待を与える対応、など
バグを隠す分岐、安易なコピペ、性能改善のための安易な近道など
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 41 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
プロジェクト末期は精神状態管理から
正論は聞きたくない
- 不毛な過去を否定したくない
【プロジェクト末期の精神状態：論理的に考えたくない、をほぐしていく】
・ストックホルム症候群的状況 (誘拐被害者が誘拐犯に同情) からの解放
論理的管理を放棄した状態
- 論理的管理へ収束
【論理的管理へ戻し、ひとつずつ作業を消化していく】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 42 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
現実に即して管理
工程分解、文書、レビューを適切粒度で
結局ソースPMO でしっかりソースを把握
【現実に即して管理】
・過剰管理しない (不足もダメ)
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 43 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
メニューと対象範囲外
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 44 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
メニュー
PM 代行(仕様変更可能)
- フルスクラッチでマネジメント再構築
【フルサービス： 全体制御権限がある場合 (PM: Project Manager)】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 45 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
サブメニュー
部分 PM 代行(20-25 時、土日祝日) PM コーチング
【サブサービス：PM を補佐】
PM に戦略思考時間を与える
スケジュール、マイルストーン管理
ステークホルダミーティング事務局 試験仕様、
試験環境作成
【マイクロサービス：部分的切り出し】
(顧客、外部開発、…)最終地点：試験項目が未定義の場合
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 46 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
対応範囲外
顧客が問題だが事情で問題解決不能
人事上の問題放置 デスマーチで勤務を是とする
【合理的解決を求めていない案件】
(懲罰、パワハラ、…)
約束不履行再犯で調整不能・他に: 巨大すぎて仕様管理できない案件 (四次請け、五次請け、…)
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 47 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
PMO 外注ビジネスの過去事例
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 48 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
クロスリンク・コンサルティングの事例
拜原創業者が炎上消火を事業に
- 結構流行っていたが創業者が病気で交代
【昔、クロスリンク・コンサルティングという会社が炎上プロマネのコンサルで流行った】
会社は失敗プロジェクトを隠す
- 失敗プロジェクトを見つける営業力が鍵
【クロスリンク・コンサルティングの成功の理由】
創業メンバの高齢化(65 歳以上)
- 深夜まで対策会議、
【クロスリンク・コンサルティングの停滞の理由：体力的限界】
早朝から顧客謝罪行脚はきつい
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 49 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
炎上の本質
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 50 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
炎上は三者の美しいオーケストラ
経営陣
顧客
プロジェクトマネージャ
【炎上は三者の美しいオーケストラ：40 % 顧客、35 % プロマネ、25 % 経営陣の責任】
上流は無管理、下流は過剰管理高度工程に人材確保できない赤字受注
全体管理の放棄、一貫性のない管理仕様管理や試験管理の手抜き
目的、出力の曖昧さ。開発当事者意識の薄さ
・多くの場合、上流で複雑さを作りだす顧客と経営陣の改善は放置
言うべきことが言えなくなる
- ソフトウェア開発でなくても危険な兆候
【「言うべきことを言い」、「論理性を重んじる」 できないと炎上】
・全員が正しい現状認識、目標、到達プロセスを共有・情報共有の前提: 信頼感: 誠実、ぎりぎりの情報も開示、聞く姿勢、人として尊重、目的を達成する意識
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 51 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
付録
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 52 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
IT おとぎ話と三次請けあるある
一番上の子豚は仕様なしで作り
炎上- 二番目の子豚は
人海戦術で作り炎上
- 一番下の子豚は緻密な検討と余裕の線表で、失注
【それじゃダメじゃん：IT おとぎ話三匹の子豚】
金がもらえるなら炎上プロジェクトはいやではない
- それ以上悪化しないから
【三次請けあるある】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 53 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
終結の 3 パターン
トップ同士が合意ハードランディング
マネージャやチームを入替仕切り直し
社員や下請けがデスマーチ
【終結の 3 パターン】
「開発中止」という選択肢を入れる
- 上長は全部資料を読む
【仕切り直しの資料を上長に読ませる方法 (by 山本一郎)】
・上長は「開発中止」したくないという強いインセンティブがある
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 54 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
顧客のあるべき姿勢
目的が明確、仕様を固定、厳密に変更管理
- 詳細設計前に試験項目を明示
【炎上防止のために顧客のあるべき姿勢 3 社分割発注プロジェクトの例】
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 55 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
参考文献 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
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 56 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
参考文献 IIIT・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
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 57 / 58
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
...
.
参考文献 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%82%A4/%E9%96%8B%E7%99%BA%E3%82%92%E7%A2%BA%E5%AE%9F%E3%81%AB%E7%82%8E%E4%B8%8A%E3%81%95%E3%81%9B%E3%82%8B3%E3%81%A4%E3%81%AE%E3%81%93%E3%81%A8ブルックスの法則, Wikipedia人月の神話, Wikipedia問題プロジェクトの火消し術、長尾清一 (2007)
山上俊彦 (ACCESS Confidential) ソフトウェア開発炎上の考察 2016/07 58 / 58
