ＥＳＤ２１ ＩＴマネジメントフォーラム

失敗に学ぶ

２０１１/１１/２２

山海 一剛

20１０ OGIS-ＲＩ Copyright reserved私の失敗プロジェクト経験20１０ OGIS-ＲＩ Copyright reserved

忘れられない失敗プロジェクト
Episode １仕様モレ仕様モレがモレが続出
Episode ２

システムがシステムがヘンなヘンなデータをデータを量産
ユーザがユーザが対応に対応に追われてんやわんや

Episode ３

Episode ４20１０ OGIS-ＲＩ Copyright reserved

ちゃんと出来ちゃんと出来たのに出来たのに使われなかった成功！
成功！
ほんとうに？
ほんとうに？

Episode 1仕様モレ
仕様モレがモレが続出


失敗
1.

2.

3.



作業順チェック、権限チェックなど、設計工程に入っても機能横断的な機能横断的な要件の検討が出来ておらず、とんでもないことに…
「生産部品表成を作る」という大きな業務要件
きな業務要件が業務要件がプロジェクト後半
プロジェクト後半まで後半まで確定まで確定できず確定できずとんでもないことに…
プロジェクト後半
プロジェクト後半まで後半まで、まで、移行処理の移行処理の検討が検討が出来ず出来ず（移行について検討する組織が存在せず）とんでもないことに…

原因
1.

2.

3.

非機能要件の抽出・検討を行う担当を設定しなかった。プロジェクトの早期に、担当を細分化（機能毎に担当をアサイン）してしまい、機能横断的な検討が出来ない状態にした。
移行を侮った（後回しにした）。優秀なメンバが本体の開発に吸収され、必要なスキルを持つメンバ（特に移行要件を検討できるメンバ）をアサインできなかった。
過大なユーザ要件を実現可能範囲に収められるメンバがいなかった。

20１０ OGIS-ＲＩ Copyright reserved

Episode ２
システムがシステムがヘンなヘンなデータをデータを量産
ユーザがユーザが対応に対応に追われてんやわんや
失敗



「サービス部品用部品表を作る」という機能を構築したが、問題の問題が発生し、ユーザ部門ユーザ部門の部門の業務そのものが業務そのものが回そのものが回らなくなった。
異常データのフォローばかりで、ユーザが回らなくなった。

原因





ひとことで言えば、機能用件の洗い出しが不十分
その背景として業務運用に業務運用に対する考慮する考慮が乏しすぎた。
正しい情報を事前設定しておきさえすれば正しい結果が得られるという前提で作られていたことが、事態を悪化させた。
得られた結果が不適切である場合の業務的インパクトを想定していなかった。


データの適正さを確認する関門もなく、不適切なデータがそのまま下流工程に流れてしまった。またユーザはデータを訂正するのではなく、新たに正しいデータを投入する必要があり、下流部門も巻き込んで、作業工数がはるかに増大した。

20１０ OGIS-ＲＩ Copyright reserved

Episode ３
ちゃんと出来ちゃんと出来たのに出来たのに使たのに使われなかった

失敗 デスマーチを続けながらも、要求通りの機能を予定通りの納期で完成
 本番運用開始後、ほとんど使ほとんど使われなかった

原因
 連携元のシステムから必要な情報が得られず、運用できなかった。
 連携元システム
連携元システムのシステムの運用実態を把握しないまま開発を進め、本番運用を迎えた。
 例：フォローのため、設計担当者の連絡先を設計部品表システムから取り込む→フタを開けると、ほとんどは設計部のアシスタントの連絡先→同じ部署の部品の連絡先は、ほとんど同じアシスタントなのでフォローできない。

20１０ OGIS-ＲＩ Copyright reserved

Episode ４成功！
成功！ ほんとうに？
ほんとうに？
成功


予定通りカットオーバー
カットオーバー後のトラブルや、機能改善要望も「記録的に」少ない
カットオーバー後の維持管理体制が急激に縮小され、情報子会社が困惑

本当に成功




最初の開発に比べれば、確かに大成功
でもコストは、部分的再構築にも部分的再構築にも関にも関わらず最初わらず最初の最初の開発の開発の４倍に（もっとも最初の開発は大赤字だったので、当時のベンダがどれぐらいコストを注ぎ込んだのかは不明）求めたものは得られたが、求めたものに見合うコストで得られたか？は疑問

20１０ OGIS-ＲＩ Copyright reserved

失敗要因の共通項（ベンダ側の視点）
体制とコミュニケーション






全体を見通す力

ユーザと情報システム部門、情報システム部門とＩＴベンダー
担当ごとの壁（機能毎に分担、個別に管理すると機能横断的な問題は後回し）
全体のことを考えられる人が不在（アサインしない）
進捗と対策ばかりに工数を割くプロジェクトマネージャ

大規模になればなるほど、多くの事柄を判断しコーディネートしなければならない
しかもその立場のマネージャが、進捗や品質の数値処理に囚われてしまう
そもそも大規模であること自体が原因とも言えるのでは？

丸投げ傾向



ユーザ企業側にユーザ要求を調整できる人が不在
強いコーディネート力を持つ人が入った途端に、劇的改善…を何度か経験
信頼関係さえ築ければ、ＩＴベンダの立場でもかなりのことが出来たという経験も。

20１０ OGIS-ＲＩ Copyright reserved

失敗要因の共通項（ベンダ側の視点）


体制とコミュニケーション

ユーザと情報システム部門、情報システム部門とＩＴベンダー
ＩＴ
ＩＴの知識不足？
ＩＴの担当ごとの壁（機能毎に分担、管理されると、機能横断的な問題は後回し）
知識不足？
全体のことを考えられる人が不在（アサインしない）
プロジェクト
プロジェクト管理能力管理能力の問題？
プロジェクト
管理能力の問題？

進捗と対策ばかりに工数を割くプロジェクトマネージャ
ベンダ
ベンダがが業務をベンダ
業務を理解できてなかったから理解できてなかったから？
できてなかったから？
全体を見通す力ダメ
ダメななベンダにダメベンダに頼んでしまったから？
んでしまったから？

大規模になればなるほど、多くの事柄を判断しコーディネートしなければならない

しかもその立場のマネージャが、進捗や品質の数値処理に囚われてしまう
契約契約があいまいだったがあいまいだった？
契約があいまいだった？



そもそも大規模であること自体が原因とも言えるのでは？

丸投げ傾向今度はうまくはうまく出来
今度はうまく出来る出来る？


ユーザ企業側にユーザ要求を調整できる人が不在
強いコーディネート力を持つ人が入った途端に、劇的改善…を何度か経験
信頼関係さえ築ければ、ＩＴベンダの立場でもかなりのことが出来たという経験も。

20１０ OGIS-ＲＩ Copyright reservedところで…最近見つけた資料から第一回スクエア・エニックス オープンカンファレンス(2011/10/8)「ゲーム開発プロジェクトマネジメント講座」より
20１０ OGIS-ＲＩ Copyright reservedよくみられる失敗

ユーザーの評
判が悪い

低いが度
足の満フ
ッ
スタ
見込みよ
り効果が少 ない20１０ OGIS-ＲＩ Copyright reserved

故障者が辞め出たてしまっ 、た生合が発不具

れた
遅が期
ス時
ーリ
リ
リリースに間に合わせるため内容が削られた

問題領域の分類
 スコープの問題
 見積りの問題
 時間の問題 リソース（人員・環境）の問題
 品質の問題
 技術の問題20１０ OGIS-ＲＩ Copyright reserved

主な変動要因 スコープのスコープの変化 仕様の追加・変更
 見積もりの見積もりのエラー
もりのエラー
 工数を見誤った
 時間見込み
時間見込みエラー
 各工程が想定よりも時間がかかった 会議その他で思ったよりも作業時間が取れなかった
 人員計画の人員計画のエラー
 思ったより人数を増やせない 思ったより能力がない 辞められる、故障者が出る
 品質マネジメント
品質マネジメントのマネジメントのエラー 品質が上がらないので作り直し
 技術マネジメント
技術マネジメントのマネジメントのエラー プログラム的に実現が困難なので作り直し20１０ OGIS-ＲＩ Copyright reserved

変動要因別の変化
 仕様追加でスコープ変更
 タスク分解のエラー
 見積もりのエラー 一日あたりの作業時間見込みエラー
 人員計画のエラー 品質マネジメントのエラー 技術マネジメントのエラー

20１０ OGIS-ＲＩ Copyright reserved

変動要因別の変化
 仕様追加でスコープ変更⇒ １．５倍
 タスク分解のエラー⇒ １．４倍
 見積もりのエラー⇒ １．３倍
 一日あたりの作業時間見込みエラー
 ⇒作業時間－２０％＝１．２５倍

 人員計画のエラー

１．２５倍
 思ったような能力が無かった⇒－３０％＝ １．４倍
 品質マネジメントのエラー⇒ １．３倍
 技術マネジメントのエラー⇒ １．３倍
 思ったように増員できなかった⇒－２０％＝20１０ OGIS-ＲＩ Copyright reservedだったとすると…
１．５×１．４×１．３×１．２５×１．２５×１．４×１．３×１．３≒１０倍！

20１０ OGIS-ＲＩ Copyright reservedそもそも不確定、そもそも高リスク
では、どうすれば…

20１０ OGIS-ＲＩ Copyright reservedひとつめのヒント：クラウド
クラウド・
クラウド・コンピューティングとはコンピューティングとは従来のコンピュータ利用は、ユーザー（企業、個人など）がコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングでは「ユーザーはインターネットの向こう側からサービスを受け、サービス利用料金を払う」形になる。
ユーザーが用意すべきものは最低限の接続環境（パーソナルコンピュータや携帯情報端末などのクライアント、その上で動くブラウザ、インターネット接続環境など）のみ。

20１０ OGIS-ＲＩ Copyright reservedふたつめのヒント：アジャイル
アジャイル開発
アジャイル開発とは開発とはソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称。
反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化する手法。
重要な機能から、リスクの高い機能から作りこみ、都度エンドユーザが検証する手法

図はコムチュア株式会社のHPより20１０ OGIS-ＲＩ Copyright reservedクラウド＋アジャイル
 すぐに環境
すぐに環境を用意することが出来環境を用意することがすることが出来る
出来る 必要な必要な機能から機能から作から作らせて使らせて使ってみることができる
 提案段階で提案段階で試しに作しに作らせてみることも 「すぐに＆すぐに＆いつでも」いつでも」クラウド越
クラウド越しに使しに使ってみることができる
 処理量が処理量が増えたら、えたら、自由に自由にキャパシティをキャパシティを増やせる
 環境も環境もベンダもベンダも、やめたくなったらやめられる 単なるＩＴ業界のトレンドではない！
 中小/中堅企業の方がより大きなメリットを引き出せる もちろん「銀の銃弾」ではない
20１０ OGIS-ＲＩ Copyright reserved

以上ありがとうございました！

20１０ OGIS-ＲＩ Copyright reserved