元日立システム

名内 泰蔵

２０１１．５．１４

大規模情報システム開発のリスク管理

大規模情報システム開発のリスク管理

情報システムのリスクについて

１．リスキー情報システム

曖昧要件システム

その他のリスキー情報システム

２ 情報システム開発リスク

３．情報システム稼働開始後のリスク

事故（ハード、ソフト）リスク

操作ミスリスク

システム維持リスク

制度変更（法律、制度、等）リスク

時リスク（人事異動等）

意図的不正リスク（省略）

3

1,1曖昧要件システム（ユーザ調査の概要）1,1曖昧要件システム（ユーザ調査の概要）

ＪＵＡＳ １０調査（５００人月以上１７８件）

Q:３０%不満、C:43%超過、D:４４%遅延要件定義×：○、で失敗度は約２倍（ＱＣＤともに）

日経コン ０８ 調査（赤字：0３）

３１．１%（２６. ７％）

３７．４%（２０. ４％）

ＱＣＤ成功率

ＲＦＰ記述

Ｑ失敗最大理由;要件定義不十分（36.7% 35.9%)

；テスト、移行問題(41.7% 21.9%)

Ｃ失敗最大理由；追加開発 (58.9% 65.5% )

Ｄ失敗最大理由；要件定義遅れ (43.6% 37.7%)

4

5

6

200M￥

↑

50M￥

↑

100M￥

50M￥

金だけが 勝手に競争 曖昧ビジネス

客客

ＶＶ ＣＣ

ＲＦＰ

曖昧の三角関係曖昧の三角関係

1,1曖昧要件システムのリスク軽減（１）

見積もり条件書の充実

• 提案仕様、見積もり条件書の最大限記述

• 現存仕様の最大活用

• 標準パッケージの最大活用

• 定量的条件の記述、FPパラメータ等

画面数、帳票数、バッチ本数など

• 想定非機能要件の定義

トラッフィク量、許容ダウンタイムなど

曖昧要件（仕様）で受注したら

• 見積仕様の徹底説明、顧客意図との差の早期発見

• 差が過大であれば、契約の見直し

1,1曖昧要件システムのリスク軽減（２）

段階契約の提案

• 仕様確定の為の派遣（準委任）契約と確定後の

請負契約に分けて「馬鹿の壁」の除去

目標予算枠を設定（想定）して仕様確定に参加

• 段階契約でも予算枠意識は必須

• 枠に合わせて「作るを減らす」提案

• 既存製品、パッケージ等の活用

システム構築の目的、基本思想の明確化と追及

目的、基本思想をベースに代案提示

9

（参考）要件定義を充実したユーザ事例

• 800ページのRFPを(U)に支援させ２ヶ月で記述日本ミルクコミュニテイ、基幹シス刷新50億、4347人月

• RFP;大型ファイル３冊、 2,5月で纏めた戸田建設、２５年ぶり経理シス更改（日経コン；07/9/3)

• RFP1500pを外部から５０名支援を受け、２億かけて作成東証売買システムArrowhead（10/1/4稼働2.2MS）

鈴木CIOの下、コンサル（H総研、F総研、アクセンチュ

ア）の支援を受け、06/6~9記述、06/12,外注先Fに決定

07/1まで要件定義書1800P、更に外部設計書として

4000P記述、内部設計以降はF社に外注

1,2その他のリスキーシステム（１）

• 未経験大規模システム「一升枡に二升は入らぬ」：大規模とは経験規模の２倍

• 非現実的納期システムＴ(最適期間）＝2.5（所要人月）1/3   ,¾Ｔ以下はdeath march ｐｊ (ベーム、人月の神話）

• 未経験分野システム「見たとなめたは大違い」

• 未経験開発技術、最新技術への盲信「習わぬ経は読めぬ」

• 二兎追いシステム「虻蜂取らず」（よいとこどり、、）

• 飢えしのぎシステム「餓えては食を選ばず」

1,2その他のリスキーシステム（２）

• 目的不明確「的のない弓は引かれぬ」

• 他社リプレース稼動歴1４年（08調査, 04:17年）あやしいドキュメント

結果確認の難しさ納期遅延で前システムの契約期限切れ、稼動困難契約解消リスク大 突き詰めれば不要システム更改時に在来との差に対する現場クレーム

• 他社パッケージの活用短所、非機能要件など潜在リスクに気づかずパッケージの過剰カスタマイズ（Ｒ／３など）「泥沼に 沈むしかない カ(過）スタマイズ」

• 自社パッケージの活用無償仕様変更要求続出の心配

２．プロジェクト推進リスク

2,1プロジェクト推進リスクの基本要因

• 無計画「朝に夕べを謀らず」

• 雑仕事「四角な座敷を丸く掃く」

• 不適切な道具や手段「塗り箸で素麺」

• 能天気「備えなければ憂いなし（こじつけ）」

• 急ぎすぎ「卵を見て時夜を求む」

2,2工程進捗リスク

• 初期工程遅延「一日の遅れは十日の遅れ」「時は人を待たず」ＮＴＴ－Ｄ岩井敏夫氏 ＳＩ力(日経ＢＰ）遅れの取り戻しには遅れ日数の４倍かかる

• 先にやるべきことを後からやる「渇して井を穿つ」「火事後の火の用心」

• 遅れては何の意味もない絶対納期「十日の菊、六日の菖蒲」 五輪大会システムなど

• 空約束、進捗実態隠ぺい「紺屋の明後日、医者の只今」

「隠すより現る」

工程進捗リスクの回避（１）

• 部下に任せず、リーダ自身も工程設計リーダの 戦略示せ 工程に １３９

見えぬ先 読み取り描け 工程表 １３１

• 定量的進捗度の事前定義物差しが なくては測れぬ 進捗度 １３６定量的進捗管理企業（03：12.8%から 08:29.9%へ)

納期遵守率；定量管理企業が1.4倍高い（日経コン08/12/1)

• 査定せず、定量的に進捗度報告質よりも まず量で言え 進捗度 １５２

注：数字は拙著「一日一句」の番号

工程進捗リスク回避（２）

• 工程は遅れ進みがあって当然と考える工程に 遅れ進みは あるがよし １６１

• 工程表は極力書き直さない書きなおし すれば工程 常にオンスケ １６２

オンスケと 言いたきゃ毎日 書き直せ

• 質的管理はレビューでレビューせず 出来た出来たと よく言うよ １５４

• 本音が言える進捗会議追い込めば 我慢できずに 嘘が出る １６０

2,3品質リスク

• 曖昧要件定義が品質リスクの中心３６％の顧客が品質失敗の最大原因と言う

• 複雑構造、美しくない設計• テスト設計不良 （too late,too rough)

• 「異常テスト＞正常テスト」戦略の欠如• レビュー不足、レビュー遅れ

的確指摘やアドバイスなし、出るのは非難とあくび

• バグの偏在：露天掘りバグ（特定個所、特定個人）• 残存バグ認識不足：バグ半減法則• 品質実態がつかめぬ厳しすぎるプロジェクト管理

非難、責任追及、能力評価

17

品質リスクの回避 （１）要件の明確化曖昧要件の品質への影響

• ユーザの３５．９％が要件定義不良を、Q失敗の理由に挙げている。（03日経コン）

• バグの５０％以上は要求の間違い(べーム）• バグ原因の６５％は要件関係（清水吉男）• 仕様変更が発生する理由（清水吉男）

顧客からの仕様変更７％

仕様漏れ記述漏れ４７％ 仕様補足２２％

誤記１７％ 動作確認後の変更７％

• 要件の間違いによるバグ修正費用設計、Cに比し、５倍以上（べーム）

18

品質リスクの回避 （２）レビューの充実ハンフリーの提案（「チームソフトウエア開発ガイド」）

• 設計レビューで単体テストの２倍以上見つけよ• 詳細設計時間の５割以上を詳細設計レビューに• 要件時間の２５％以上を要件レビューに• コードレビューにコーデイング時間の５割以上• １時間あたりのレビュー，設計文書レビュー＜２～５頁

注；日立：１～１０頁；（PM学会誌07／10）

１頁／人時で計画せよ（「ソフトウエアインスペクション」）

詳細設計レビュー＜１００擬似コード、

コードレビュー＜２００行，

品質リスクの回避 （３）テストの充実

• 地道なテスト テストカバレージ、Ｃ０，Ｃ１等

やみくもに テストをしても 効果なし ２１９

• 独立テスト部隊の編成とテスト設計の充実他人が見て 初めてわかる いい悪い １５５

• 合理的、早めのテスト設計再テストの自動化、テストカバレージ、ソース解析

• ユーザよる 仕様誤解の早期発見、テスト結果確認

ユーザに 見せて気がつく 勘違い ２１５

• 味見と味見の落とし穴手遅れの 一歩手前で 味見する

味見して 意外のうまさに 惑わされ ２２７

2,4プロジェクトリーダリスク

• 間違ったことを押し付ける「鹿を指して馬となす」

• 自分で汗をかかない、実務力なし「伴食宰相」

• 規則ばかり押し付ける 「繁文縟礼」

• 叱責を繰り返す： 「三度目の腹立ち」• 方針が変わる：「朝令暮改」方針を 変えたら変えたと 言ってくれ ２６８

• Leader でなく Reader

自分で考えない、見ない、書かない、部下任せ

• 「相連報」でなく「報連相」ばかり言う

2,5プロジェクトメンバリスク

• 特徴なし、主体性なし「くせなき馬は行かず」「云うなり地蔵」

• 裏表あり「面従腹背」

• 実行力なし「家を出ぬ出家、山に伏さぬ山伏｣ ：知式人

• 何でもできるが何も出来ない「多芸は無芸」

• 柔軟性なし「石部金吉金兜 いしべきんきちかなかぶと」

2,6プロジェクトチームリスク

• 役に立たない者ばかりのチーム「烏合の衆」

• メンバ間の関係に問題あり「船頭多くして舟山に上がる」

• 問題メンバがいるチーム「城狐社鼠」

• コミュニケーションの悪いチーム「ことづてと坊主の髪はゆうたことなし」

• 考えないチーム「一鶏鳴けば万鶏歌う」

３．情報システム稼働後のリスク

3,1 システム事故リスク事例と対策

• 絶対避けたい事故の明確化と最大対策座席予約（マルス）：二重発売、ダブルチェック論理の組み込み

運行管理（コムトラック）：異線進入：２重化３台系システム

• 正確な復旧より素速い復旧座席予約システム（素早く）vs金融システム（正確に）

• システムダウンより部分ダウン、極力止めない、回復最優先不特定多数ユーザ（銀行、マルスなど）への対応：部分ダウン

原因究明より回復、止めて何ができるか考える

• 呼の集中対策：‐取引所、コムトラックなど正帰還形トラッフィク入力抑止手段の用意

3,2オペミス事故リスク事例と対策

• 取り消しミスマルス：三重発売、取り消し座席の間違い入力

現在は発売済み切符の入力で回避

• 数字入力ミス：口座番号など確認メッセージの出力：ATMなど

• ミス確認の落とし穴：慣れ過ぎた操作ミス：確認無視61万円 1 株と 1 株 61万株

• システム回復後の操作ミス回復後は再操作すればよいという原則の堅持

3,3システム維持リスク事例と対策

• 技術者の確保リスク伊勢神宮式年遷宮（２０年）の知恵の活用；

出雲大社：60年に一度5年かけ修繕（仮遷宮）

• ドキュメントの維持リスク定期的更新工事の必要性

• 法改正、制度改正への対応リスク絶対納期を死守すべき最低機能の見極め

• 日付リスク ：２０００年問題、２０３８、うるう年境界日付の事前確認

• 量的拡大による桁あふれ上限値の事前確認

3,3システム維持リスク事例• トラブル回復方法忘却定期的消防訓練

• 緊張感の忘却からの油断１７年目（長期安定稼働後）の危機への備え

• 暗黙知の伝承とぎれ老人の知恵、失敗事例の記述の徹底

• 常識の変化：建設時前提とした条件が変わる初めの使い勝手と習熟後の使い勝手を考慮

• 慣れたら不要なガイダンスプロが使うならガイダンスなんて不要

27

著書の紹介著書の紹介

■ A5判 230ページ

■ 価格 本体2,400円 +税

■ ISBN 4-7981-0905-X

■ 株式会社 翔泳社

■ 2005年 3月17日発行

曖昧性とのたたかい 曖昧性との共存

■ A5判 254ページ

■ 価格 本体2,400円 +税

■ ISBN 4-7981-1143-X

■ 株式会社 翔泳社

■ 2006年 4月17日発行

28

著書の紹介著書の紹介

カルタでカタル プロジェクト管理（PM学会誌）楽しく学ぶプロジェクト管理 ＰＭ格言カルタプロマネ「一日一句」 日経BP社

２０１１、５、１４

大規模情報システム開発のリスク管理

大規模情報システム開発のリスク管理

名内泰蔵