大規模情報システム開発のリスク管理２０１１．５．１４元日立システム名内泰蔵情報システムのリスクについて１．リスキー情報システム曖昧要件システムその他のリスキー情報システム２情報システム開発リスク３．情報システム稼働開始後のリスク事故（ハード、ソフト）リスク操作ミスリスクシステム維持リスク制度変更（法律、制度、等）リスク時リスク（人事異動等）意図的不正リスク（省略） 1,1曖昧要件システム（ユーザ調査の概要）ＪＵＡＳ１０調査（５００人月以上１７８件） Q:３０%不満、C:43%超過、D:４４%遅延要件定義×：○、で失敗度は約２倍（ＱＣＤともに）日経コン０８調査（赤字：0３）ＱＣＤ成功率ＲＦＰ記述 3 ３１．１%（２６. ７％）３７．４%（２０. ４％）Ｑ失敗最大理由;要件定義不十分（36.7% ；テスト、移行問題(41.7% Ｃ失敗最大理由；追加開発 (58.9% Ｄ失敗最大理由；要件定義遅れ (43.6% 35.9%) 21.9%) 65.5% ) 37.7%) 4 5 曖昧の三角関係客客 200M￥ ↑ 50M￥ 50M￥ＲＦＰ ↑ 100M￥ 6 ＶＶＣＣ金だけが勝手に競争曖昧ビジネス 1,1曖昧要件システムのリスク軽減（１）見積もり条件書の充実 • 提案仕様、見積もり条件書の最大限記述 • 現存仕様の最大活用 • 標準パッケージの最大活用 • 定量的条件の記述、FPパラメータ等画面数、帳票数、バッチ本数など • 想定非機能要件の定義トラッフィク量、許容ダウンタイムなど曖昧要件（仕様）で受注したら • 見積仕様の徹底説明、顧客意図との差の早期発見 • 差が過大であれば、契約の見直し 1,1曖昧要件システムのリスク軽減（２）段階契約の提案 • 仕様確定の為の派遣（準委任）契約と確定後の請負契約に分けて「馬鹿の壁」の除去目標予算枠を設定（想定）して仕様確定に参加 • 段階契約でも予算枠意識は必須 • 枠に合わせて「作るを減らす」提案 • 既存製品、パッケージ等の活用システム構築の目的、基本思想の明確化と追及目的、基本思想をベースに代案提示（参考）要件定義を充実したユーザ事例 • 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社に外注 9 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) • 「異常テスト＞正常テスト」戦略の欠如 • レビュー不足、レビュー遅れ的確指摘やアドバイスなし、出るのは非難とあくび • バグの偏在：露天掘りバグ（特定個所、特定個人） • 残存バグ認識不足：バグ半減法則 • 品質実態がつかめぬ厳しすぎるプロジェクト管理非難、責任追及、能力評価品質リスクの回避（１）要件の明確化曖昧要件の品質への影響 • ユーザの３５．９％が要件定義不良を、Q失敗の理由に挙げている。（03日経コン） • バグの５０％以上は要求の間違い(べーム） • バグ原因の６５％は要件関係（清水吉男） • 仕様変更が発生する理由（清水吉男）顧客からの仕様変更７％仕様漏れ記述漏れ４７％仕様補足２２％誤記１７％動作確認後の変更７％ • 要件の間違いによるバグ修正費用設計、Cに比し、５倍以上（べーム） 17 品質リスクの回避（２）レビューの充実ハンフリーの提案（「チームソフトウエア開発ガイド」） • • • • • 設計レビューで単体テストの２倍以上見つけよ詳細設計時間の５割以上を詳細設計レビューに要件時間の２５％以上を要件レビューにコードレビューにコーデイング時間の５割以上１時間あたりのレビュー，設計文書レビュー＜２∼５頁注；日立：１∼１０頁；（PM学会誌07／10）１頁／人時で計画せよ（「ソフトウエアインスペクション」）詳細設計レビュー＜１００擬似コード、 18 コードレビュー＜２００行，品質リスクの回避（３）テストの充実 • 地道なテストテストカバレージ、Ｃ０，Ｃ１等やみくもにテストをしても効果なし２１９ • 独立テスト部隊の編成とテスト設計の充実他人が見て初めてわかるいい悪い１５５ • 合理的、早めのテスト設計再テストの自動化、テストカバレージ、ソース解析 • ユーザよる仕様誤解の早期発見、テスト結果確認ユーザに見せて気がつく勘違い２１５ • 味見と味見の落とし穴手遅れの一歩手前で味見する味見して意外のうまさに惑わされ２２７ 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日発行著書の紹介カルタでカタルプロジェクト管理（PM学会誌）楽しく学ぶプロジェクト管理ＰＭ格言カルタプロマネ「一日一句」日経BP社 28 大規模情報システム開発のリスク管理２０１１、５、１４名内泰蔵