ITA情報処理システム障害事例集 ～ITA各社における情報処理システムの 障害事例とそこから導かれる教訓～ 障害再発防止策研究会 201４年12月24日 1.0版 試験では何が必要かを見極め、短時間で消化出来る方法を模索せよ 事例№ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 タイトル 品質作りこみのために、暗黙知や職人芸は期待しない 過信は怪我の元 ① － 手順書に見えない部分あり 過信は怪我の元 ② － 連携先の怪我も事前手当 過信は怪我の元 ③ － 記憶は不確か明記は絶対 過信は怪我の元 ④ － 自己満足に陥らない。周囲の意見を大切に レビューに勝る品質向上策なし 同じ構文でも環境が変われば結果は異なる 機能変更は過去データへの影響を配慮せよ 設計はシンプルに！ 過剰な品質管理は品質劣化を招く ユーザ検証時の仕様変更は当たり前 遅れ始めたプロジェクトに人を投入しても遅れを拡大させるだけ 自分で考える － 顧客やプライムSIerの言うことを鵜呑みしない スコープ増大 －現場当事者では気づかない場合あり。上層部の監視も重要 チェックリスト － 過去に痛い目にあった経験を共有する手段 ポカヨケ －ミスを誘発しない手順を、担当者の経験を考慮して文書化する オペミス撲滅 － 詳細な手順・チェックリスト、ペア作業 密なコミュニケーション － 顧客満足度の高いシステム構築への鍵 業務精通者のレビューは必須と心得よ システム運用設計は現実の業務量を想定してシミュレーションすること マニュアル作成では、細かな作業まで反映されていることを必ず確認すべし ゼロ件データチェックは、未登録状態だけでなく全削除状態でも確認すべし 業務精通者のレビューは必須と心得よ。※事例１９と同じ 負荷テストのマシンスペックは推奨環境の最低レベルで確認すべし 暗黙のルール － 「以前からこうだった」になっていないか 安全と効率 － 流れ作業の良い面悪い面 行方不明なステークスホルダー － 追加仕様が青天井に増えて 管理工数の十分な確保 標準化は早期着手 オフショア開発の注意点 コスト圧迫の要因 パッケージ開発の注意点 体制、スキルの注意点 テストケース作成者は具体的なデータイメージを作成せよ 可能な限り、本番環境と同等の環境を構築し、試験せよ ２重チェック、手順を駆使して作業ミスを起こさない意識を徹底すべし 成果物はレビューしないと意味がない 複数人の目で作業ミスを撲滅せよ 安易にデータをマスクするな。本番と同等のデータを使用せよ 試験では何が必要かを見極め、短時間で消化出来る方法を模索せよ 2 キーワード 前 工 程 成 果 物 の 品 質 事例№ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 タイトル 品質作りこみのために、暗黙知や職人芸は期待しない 過信は怪我の元 ① － 手順書に見えない部分あり 過信は怪我の元 ② － 連携先の怪我も事前手当 過信は怪我の元 ③ － 記憶は不確か明記は絶対 成 果 物 合 意 ス コ ー プ 管 理 コ ミ ュ ニ ケ ー シ ョ ン パ ス 指 揮 命 令 系 統 役 割 と 責 任 の 定 義 フェーズ コ ミ ュ ニ ケ ー シ ョ ン 計 画 エ ス カ レ ー シ ョ ン リ ス ク 管 理 教 訓 の 共 有 チ ェ ッ ク リ ス ト ポ カ ヨ ケ ペ ア 作 業 ス テ ー ク ホ ル ダ ー 管 理 エ ン ド ユ ー ザ ー の 関 与 ○ 品 質 管 理 記 曖 影 明 レ テ 述 昧 響 確 ビ ス 漏 調 化 ュ ト ー 漏 れ 査 れ 計 算 精 度 シ ン プ ル な 設 計 作 ル 作 リ 思 業 ー 業 ス い 員 ル 手 ク 込 大 順 分 み 量 析 投 入 流 れ 作 業 入 力 ミ ス 単 純 ミ ス 顧 客 要 求 過 残 体 オ ネ 重 業 制 フ ゴ 労 シ シ 働 ョ エ ア ー 開 シ 発 ョ ン パ ッ ケ ー ジ テ ス ト デ ー タ テ ス ト ケ ー ス デ ー タ イ メ ー ジ 本 番 環 境 スコープ増大 －現場当事者では気づかない場合あり。上層部の監視も重要 本稼動 開発 設計 設計 設計 設計 開発 ○ ○ ○ ○ 試 験 時 間 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ チェックリスト － 過去に痛い目にあった経験を共有する手段 ○ ○ ○ ○ オペミス撲滅 － 詳細な手順・チェックリスト、ペア作業 ○ 密なコミュニケーション － 顧客満足度の高いシステム構築への鍵 業務精通者のレビューは必須と心得よ ○ ○ ○ ○ ○ ○ ○ ○ ○ システム運用設計は現実の業務量を想定してシミュレーションすること ○ マニュアル作成では、細かな作業まで反映されていることを必ず確認すべし ゼロ件データチェックは、未登録状態だけでなく全削除状態でも確認すべし 業務精通者のレビューは必須と心得よ。※事例１９と同じ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 暗黙のルール － 「以前からこうだった」になっていないか 安全と効率 － 流れ作業の良い面悪い面 運用 運用 行方不明なステークスホルダー － 追加仕様が青天井に増えて 設計・開発 ○ ○ 管理工数の十分な確保 標準化は早期着手 ○ オフショア開発の注意点 ○ コスト圧迫の要因 パッケージ開発の注意点 体制、スキルの注意点 ○ ○ テストケース作成者は具体的なデータイメージを作成せよ 可能な限り、本番環境と同等の環境を構築し、試験せよ ○ ○ ○ ○ ○ 負荷テストのマシンスペックは推奨環境の最低レベルで確認すべし ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ２重チェック、手順を駆使して作業ミスを起こさない意識を徹底すべし 試験では何が必要かを見極め、短時間で消化出来る方法を模索せよ ○ ○ ○ ○ セ 手 マ 本 試 ル 作 ス 番 験 フ 業 ク デ 範 チ デ ー 囲 ー タ ェ タ ッ ク ○ ○ ポカヨケ －ミスを誘発しない手順を、担当者の経験を考慮して文書化する 成果物はレビューしないと意味がない 複数人の目で作業ミスを撲滅せよ 安易にデータをマスクするな。本番と同等のデータを使用せよ ク ロ ス チ ェ ッ ク ○ ○ ○ ○ ○ ○ 過信は怪我の元 ④ － 自己満足に陥らない。周囲の意見を大切に レビューに勝る品質向上策なし 同じ構文でも環境が変われば結果は異なる 機能変更は過去データへの影響を配慮せよ 設計はシンプルに！ 過剰な品質管理は品質劣化を招く ユーザ検証時の仕様変更は当たり前 遅れ始めたプロジェクトに人を投入しても遅れを拡大させるだけ 自分で考える － 顧客やプライムSIerの言うことを鵜呑みしない 二 重 チ ェ ッ ク ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 3 障害再発防止策研究会 事例 １ 品質作りこみのために、暗黙知や職人芸は期待しない。 問題 システム保守で1月に1，2個の障害が出る。 障害を出すメンバがある程度偏っている。 原因 障害原因を分析してみたところ以下の２パターンとなった。 ①影響調査不足 ②設計書の精度不足（記述漏れ、曖昧） ①影響調査不足 ・要件対象の機能だけ対応後、そのままリリースしてしまい依存関係がある機能の 再コンパイルがされていないことでシステムエラーとなる。 ・改修対応中（対応期間は数カ月）に改修対象の機能で本番障害が起き、対応版 をリリースして障害は解決するが、数ヵ月後のリリース時に障害対応したものが 含まれておらず、同じ障害を発生させてしまう。 ・要件対応に乗じて同じ機能に対して軽微な改修の依頼を安易に受けてしまい データフロー上の下位の機能で障害が発生。 ②設計書の精度不足 ・改ページ条件項目が曖昧な記述であったため、同一フォーマットのまま次ページが 出力されてしまう。例えば、「グループ値引き行数が10件を超えると改ページフラグ を立てる」という設計書の記述があり、製造担当はグループ値引き名でカウントを とるプログラムを作成したため、グループ値引き名を入れずにグループ値引き金額 だけ入った行がカウントされず、本来別フォーマットに切り替わるべきところが切り 替わらなかった。記述としては、必須項目であるグループ値引き金額を用いて、「グ ループ値引き金額入力行が10行を超えたら」という条件で書くべきであった。 対策 障害をよく出す担当は、当たり前の調査ができてなかったり、成果物だけでレビューし たりして、レビューの質（指摘の内容が品質の作りこみにつながってない）が低かった。 成果物のレベルを一定にするため、下記の対策を講じた。 ①影響調査不足への対策 最低限の調査手順を作成し、設計レビュー時のチェックリストに追加した。 レビュー時に調査結果のないものはNGとするよう徹底した。 最低限の調査：DBオブジェクトの依存関係の調査 キーワードによる、全ソース・設計書のGREP確認 SQLの実行計画の確認 ②設計書の精度不足への対策 設計レビュー時のチェック項目として、曖昧さの排除を追加した。条件分岐に使用 する項目については、特に注意するように徹底した。 条件分岐が多くなりそうなときは、マトリクス化を必須とし、パターンを明確にした。 レビューで漏れた時のことを考慮し、影響の大きい特定機能については、改修時 の必須テスト項目を作成し、実施させるようにした。 それまで別々に行っていた設計とテスト仕様書のレビューを同時に行うようにした。 上記対策をやり始めて3カ月後から、新規リリース時の障害がほぼ発生しなくなった。 4 障害再発防止策研究会 教訓 品質作りこみのために、暗黙知や職人芸は期待しない。 やるべきことを明確化し、着実に実施させるべし。 5 障害再発防止策研究会 事例 ２ 過信は怪我の元 ① － 手順書に見えない部分あり。 問題 本番リース前に、確認したが誤ったバージョンの資材をリリースしようとした。 本番リリース直前に再度リリース手順に沿って確認した結果、 リリースするバージョンが誤っている事を発見し最新バージョンをリリースする事が出来た。 原因 以下の要因により、バージョン誤りが発生している。 ・リリース準備時最新バージョンの見落とし。 ・持ち出し資材の確認漏れ。 ・持ち出し資材のバージョン確認を１人で実施。 対策 本来リリース前に不備な部分は発覚可能な手順書となっているが、 持ち出し資材の確認はダブルチェックする。 対象バージョンの保管場所から最新バージョンを確認して確実にパッケージ化する。 教訓 チェックは一人で実施せずダブルチェックまたは、第三者チェックにて実施する。 6 障害再発防止策研究会 事例 ３ 過信は怪我の元 ② － 連携先の怪我も事前手当。 問題 変更対象外機能の外部インターフェース項目で連携先システムが異常終了。 原因 外部接続のインターフェイスは各機能で共通フォーマットを採用しているが、 共通フォーマットを意識せず連携先で改修を行ったため発生。 ※共通項目を１つの機能では全角項目、またその他の機能では半角項目の スペースとして判断していたことから発生。 対策 1.外部接続テストのテストケース打ち合わせ時に改修対象外の機能も 異常がないかチェックする。 2.連携先システムで誤った改修がおこなわれない様、相互間での仕様確認時に共通認識をもつ。 3.原因確認の元、恒久対応の前に暫定対応など検討しシステムを稼働させる。 ※注意点として連携先のシステム側でテストケースを作成している場合、 相手が作っている為、大丈夫と思い、テストケース漏れに気が付かない。 教訓 改修対象外機能でも、その旨を連携し連携先システムに問題ないか確認を実施。 「・・・だろう」、「・・・はずだ」の思い込みは排除して相互の認識を合わせる。 7 障害再発防止策研究会 事例 ４ 過信は怪我の元 ③ － 記憶は不確か明記は絶対。 問題 事前準備したマスタ初期設定用の設定情報（適用開始日）が未来日となったまま 本番環境に設定していた。 しかし、本番環境で稼働する前、再チェックを実施した際、適用開始日の不備を発見し 再設定を実施。 原因 リリース日が延期になり、マスタの適用開始日が決まっていなかったため、 リリース確定後設定する予定だったが、リリース日が確定されても設定情報を 確認することなく、そのままとなっていた。 ※事前準備したマスタ設定情報は、テストで使用した設定情報を設定したままに なっていた。 対策 従来の手順書に沿って準備はされているが、本番環境設定前に実施する必要がある場合は、 漏れがない様、特記事項等の申し送り事項も明記するルールを新たに追加した。 教訓 チェックは一人で実施せずダブルチェックまたは、第三者チェックにて実施する。 8 障害再発防止策研究会 事例 ５ 過信は怪我の元 ④ － 自己満足に陥らない。周囲の意見を大切に。 問題 オンライン画面で名称表示の要件が反映されていない事象が発生。 原因 変更対象の調査において影響調査が不十分であった。 影響調査に当たり、変更対象を洗い出す時の検索キーワードが不足していた。 洗い出した複数の検索キーワードを元に検索を行ったが、その検索キーワードから 外れるものがあった。 対策 有識者による検索キーワードの洗い出しを徹底的に実施。 情報取得の為、過去発生した時の情報を累積していく。 教訓 検索キーワードの妥当性をどのように判断するかを明確にする。 チェックは一人で実施せずダブルチェックまたは、第三者チェックにて実施する。 9 障害再発防止策研究会 事例 ６ レビューに勝る品質向上策なし 問題 金融系のＷｅｂシステムにおいて、集計用データの保存に失敗して、約2千人分 （２ヶ月分）の一部のデータが消失。 データ復旧の為、ユーザ（約2千人)は２ヶ月分の入力作業を再実施する事となった。 成功 成功 失敗 一部の データが消 原因 障害を発生させた要因として下記の２点が人的ミスがあとしてあげられる。 ①テスト範囲の確認を怠ったことによるテスト項目の漏れ ②日常的なカスタマイズ作業対する業務への慣れ カスタマイズ対象箇所の機能テストを優先的、且つ重点的に行っていた事で、 従来の集計機能（今回の不具合発生箇所：カスタマイズ対象外）に対する テスト作業が十分に行なわれずデグレートを発生させてしまった。 また、集計機能に対してテスト作業が行われておらず、不具合が潜在している ことを顧客も気が付かないまま本番運用に移行してしった。 カスタマイズ作業が短納期だった事と年１回の年次業務だった事で、開発側は 前年実施したテスト仕様書をそのまま流用しテストを実施したことが障害発生 に繋がった。 本来、顧客側のテストとして本番に向けた運用テストが独自に実施されるはず であったが、顧客も開発側が作成したテスト仕様書を流用したことで不良箇所 を発見する事が出来なかった。 対策 今回の発生原因を踏まえ以下の対策を再発防止策として実施した。 ①フェーズ毎のレビュー実施の徹底を図った。 ②改修対象に伴い、影響範囲に対するレビューの実施を徹底した。 ③製造と単体テストは別の担当者が実施する事とした。 本カスタマイズ以外にも短納期の作業が頻発する事から、テスト作業に十分な 時間を割くことが出来ない（工数をかけられない。）との意識が働き、結果的に 品質の低下を招いた。 10 障害再発防止策研究会 不具合発生に至った経緯を再認識することにより、事前に十分なレビューを 実施することで、顧客に対する品質保証の重要性を再認識させることとした。 また、製造担当者と単体テスト担当者を分けて、少なくとも１つのプログラムを ２人以上の担当者が評価する機会を増やす事とした。 但し、本対策③実施の条件として、製造担当者と単体テスト担当者が、業務 及び技術に対して同等のレベルを持つ必要があることも付け加える。 教訓 低予算・短納期であっても、品質保障を維持する為には意識改革とレビューは必須。 11 障害再発防止策研究会 事例 ７ 同じ構文でも環境が変われば結果は異なる 問題 物流系販売管理システムのコンバージョンにおいて、売上伝票の金額計算において 小数点を含む計算がある場合、合計金額に誤差が発生する。 旧システム Visual Basic 6.0 <売上伝票> (A*c)+(B*c) 合計金額 新システム Visual Basic .NET コンバージョン <売上伝票> (A*c)+(B*c) 合計金額 合計金額に 差異が発生 原因 コンバージョン作業において金額計算用の変数型の使用誤りが原因。 計算に使用していたDouble型(浮動小数点数型)の精度が開発環境 「Visual Basic 6.0 と Visual studio 2010」により異なる事が判明。 対策 以下の対策を実施した。 ①誤差の許されない計算は、Double型(浮動小数点数型)を「Decimal利用」に修正。 ②移行対象の全ソースから、Double型、Single型、Double型変換のCDbl関数、 Single型変換のCSng関数を使用しているモジュールを調査し、①の対策を実施 した。 また、再発防止策として、移行手順書に本対策を追記し、周知・徹底を図った。 教訓 同じ構文であっても、開発環境により計算精度が異なる場合がある。 12 障害再発防止策研究会 事例 ８ 機能変更は過去データへの影響を配慮せよ 問題 官庁系の調査システムにおいて、調査データ登録時に正しい品目データであるにも かかわらず、登録済みエラーとなり、入力できない不具合が発生した。 旧システム 仕様変更後 品目Ａ 品目Ａ 品目Ｂ 品目Ｂ 品目Ａ 仕様変 品目Ａ 品目Ｂ 追加 できない 品目Ｂ 品目Ｂ 品目Ａ 原因 改修内容の精査不足が原因。 改修後の新システムでは、品目＝ＡとＢはペアで登録する仕様に変更となり、 両品目がペアで存在する事を前提にプログラムを作成した。 本改修により、過去分データ（ペア登録されていないデータ）への登録処理に おいて不整合が発生して、「登録済みエラー」となった。 対策 機能変更時の影響範囲調査の重要性に関する再教育と他事業部への情報共有を 実施した。 教訓 設計担当者は事前に改修内容が与える全ての影響を考慮する必要がある。 13 障害再発防止策研究会 事例 ９ 設計はシンプルに！ 問題 顧客の要望により、汎用性を保ちつつ、個別の特殊な要件にも対応できるように 設計した為、非常に複雑な仕様となり、設計のみならず、製造・テストも工数超過 （赤字）が発生。 【設計担当】 【製造担当】 機 仕様書 機 機 機 機 機 機 機 機 原因 ①仕様（基本設計・詳細設計）が非常に複雑で製造担当者が容易に理解できなかった。 ②仕様が複雑、かつ複雑なまま整合性を保てる賢い設計ができる者がいた。 対策 再発防止策として、複雑な設計が及ぼす影響事例として社内展開した。 教訓 仕様はシンプルに設計する。シンプルにできなければ「汎用性・将来性」は捨てる事。 【設計担当】 仕様書 機 【製造担当】 仕様書 機 仕様書 機 14 障害再発防止策研究会 事例 １０ 過剰な品質管理は品質劣化を招く 問題 詳細設計（クラス図・シーケンス図）のレビュー実施回数及びレビュー指摘対応工数が 膨大となり、工数超過（赤字）が発生。更に、テストフェーズに十分な時間が掛けられず 品質が劣化し、納期遅れに繋がった。 元請先 相反する指摘事項が多く 手戻り作業が増大。 テストフェーズに十分 内部 中請先 原因 ①1つの成果物に対するレビューが複数回（内部、中請、元請の３回)にわたった、 また、各レビューア毎に相反する指摘も多く、修正後、元に戻すという手戻り作業 （無駄）が多く発生した。 ②受注時の作業条件の確認が十分でなかった。 対策 再発防止策として、以下の運用を社内展開した。 ①品質確保の為、時間と予算がない場合はレビューよりもテスト優先する事とする。 ②同一成果物に対するレビュー回数は、できるだけ減らす。 できれば１回以下が望ましい。 ③汎用的な指摘は規約として周知する。またレビュー対象も効果的に減らす。 ④作業条件を事前に確認した上で見積りを作成し、受注する。 社内として、再発防止策は決めたものの、顧客優先の立場で本対策を実施することは 非常に困難であるのが現状。 教訓 必要以上の品質管理は品質劣化を招く。 15 障害再発防止策研究会 事例 １１ ユーザ検証時の仕様変更は当たり前 問題 ユーザ検証時に大量の仕様変更が発生して、工数超過(赤字）が発生。 事前「要件定義レビュー」や「基本設計レビュー」で承認を頂いていたが、ﾕｰｻﾞ検証 時に大量の仕様変更が発生。 要件定義レ ○ﾕｰｻﾞ承認済 基本設計レ ○ﾕｰｻﾞ承認済 ﾕｰｻﾞ検証 ×検証NG 大量の手戻り作業が発生 原因 ①ユーザ検証時に仕様変更(手戻り作業)が大量に発生。 ②結局の所、エンドユーザは実際に触ってみなければわからない。 設計時の認識合わせ不足との指摘もあるが… ③ユーザ教育も仕事のうち。 ④ユーザが理解可能なドキュメントの作り方を検討する必要がある。 対策 ユーザの理解不足が疑われる場合は、ユーザ検証を結合テストフェーズの途中に 組み入れ、ユーザ検証後の手直し工数もある程度確保(ｽｹｼﾞｭｰﾙ)する事。 教訓 ユーザ検証時に仕様変更が発生する事は「当たり前」の事と認識して予定を決める事。 予定がタイトな場合は、他の作業を多少省く事も検討する事。 16 障害再発防止策研究会 事例 １２ 遅れ始めたプロジェクトに人を投入しても遅れを拡大させるだけ 問題 短納期・低予算の為、大量の開発要員（新人）を投入したが、結局納期遅れが発生。 短納期・低予算のプロジェクト 新人 新人 新人 新人 初心者ロス及びコミュニ 新人 新人 新人 新人 新人 新人 原因 ①初心者大量投入により、初心者ロス×人数が発生して、作業に慣れる前に プロジェクトが終わる。 ②コミュニケーションミスやロスが大量発生。 ③初めての業務で、参照可能なサンプル（プロトタイプ）もなく、重複作業が多かった。 対策 機能に比して短納期の商談は断る事も勇気も必要。 教訓 遅れ始めたプロジェクトに人を投入しても遅れを拡大させるだけである。 （ブルックスの法則） 17 障害再発防止策研究会 事例 １３ 自分で考える － 顧客やプライムSIerの言うことを鵜呑みしない 問題 当社は外部設計から統合テストまでを請け負ったが、想定外の作業が大量に発生。 顧客からは増大した工数分の追加費用をもらうことができず、結果として予定していた 利益率を大幅に下回ってしまった。 原因 3つの原因が特定された。 1.要件定義は顧客側で終わっているという話を信じて開始したが、実際は不十分 であった。 十分な調査をしないままに見積を実施し、プロジェクトを開始してしまったことが問題。 2.見積時に成果物イメージを顧客と明確に合意できていなかったため、想定以上の 作業が発生した。 3.顧客からの要求が担当者に直接来てしまい、作業範囲や量をPMがコントロール できなかった。つまりスコープ管理と要員キャパシティ管理がうまくいかなかった。 対策 上記原因に対して、以下の対策を行った。 1. 外部設計時に要件の確認作業を並行して行った。 (結果) 要件は明確になったが、コストは回収できず、当社の利益は減少した。 2. 顧客と成果物イメージをすり合わせ、成果物を再作成した。 また成果物の顧客レビューを徹底した。 (結果) 顧客の求める成果物は作成できたが、追加となったコストは回収できず、 利益は減少した。 3. 顧客に対して、当社担当者に直接に要求するのではなく、チームリーダーを 経由するように交渉した。 (結果) 顧客は概ね要求に従ってくれたが、一部の顧客は、当社担当者に 直接依頼していた。 再発防止に向けて、更に以下の対策を行った。 1,2: 開始基準の充足度を測定するチェックリストを作成し、以後のプロジェクトで 展開した。 (効果) 以後のプロジェクトから、準備状況が可視化され、問題やリスクを早期に発見し、 対応できるようになった。 18 障害再発防止策研究会 3: 体制定義やコミュニケーション計画作成に関する再教育と、それらの計画を 上層部でレビューすることを徹底した。 (効果) 以後のプロジェクトから、PMがコミュニケーションパスの重要性を認識し、 計画をきちんと立てるようになった。 教訓 顧客やプライムSIerの言うことを鵜呑みにせず、現物を確認し、自分達の頭で 考えることが重要。 自分達の頭で考えるための仕組みとして、この会社では社員に対し、 以下のようなガイドの提供と教育を行った。 ・自分達でプロセスを組み立て、Sierに不足事項を伝えるようことができるように、 開発の標準的な進め方（プロセス）とそれに基づいた標準WBSの提供 ・品質や進捗の問題を自分達で考えて分析できるように、標準的な 指標（下限、平均、上限）を提供した。 19 障害再発防止策研究会 事例 １４ スコープ増大 －現場当事者では気づかない場合あり。上層部の監視も 問題 移行フェーズにおいて必要なタスクの洗い出し、およびタスクの管理が行われず、 移行後に数々の問題が起きた。 そのリカバリー作業のために多くの作業が発生したが、顧客からは増大した工数分の 追加費用をもらうことができず、結果として予定していた利益率を大幅に下回った。 原因 3つの原因が特定された。 1.契約時では当社の作業スコープに移行作業が含まれていなかったが、顧客と 当社を含めた現場担当者は当社が担当すると思い込んでいて、実際に作業を 開始してしまっていた。契約上のスコープ定義が曖昧かつ現場へ徹底していな かったため、現場がスコープ変更であることを認識できなかったことが原因。 2.現場では移行に関する計画をきちんと立てないままに進めた。結果、顧客との役割 分担が不明確、コミュニケーション計画未定義、要員計画未作成による移行スキル 保有要員不足といった問題が発生した。 3.現場のメンバーの中にはリスクを認識していたものがいたが、その話は上層部 まで伝わっていなかった。 対策 上記原因に対して、以下の対策を行った。 1.2.3 担当部長が指揮をとり、移行計画の作成と、管理を行った。 (結果) 移行フェーズの終了は計画より遅れたが、顧客のサービスインには何とか 間に合った。 再発防止に向けて、更に以下の対策を行った。 1: PMへ、契約時のスコープ定義の明確化と、メンバーへの展開の必要性、 契約変更の重要性を周知した。 2: スコープ変更時には、既存のプロジェクト計画を改定するか、新たなプロジェクトを 立ち上げることが必要であることをPMに周知した。 特に役割・責任、コミュニケーション計画、必要スキル計画については重点的に 説明した。 3. リスク管理と監視のプロセスについて周知した。 4. 役員やプロジェクト担当部長が参加するレビューの中で、作業スコープが計画通り であるか確認するようにした。 (効果) 以後のプロジェクトから、大きなスコープ変更に関して上層部の承認なしに進むような ことは無くなった。 20 障害再発防止策研究会 教訓 スコープの増大は当事者であるPMが気づかない場合もあるので、上層部はプロジェクト が契約のスコープを逸脱していないか監視することが大切。 スコープの増大を把握するために工程終了時に上層部も含めて以下のことを実施した。 ・その時点で想定される最終成果物のサイズ（プログラムステップ、 ファンクションポイントなど）と、当初の見積りで前提としていたサイズを比較する。 ・WBSのレベル1-3程度の内容と、契約書での自社の作業範囲を比較する。 21 障害再発防止策研究会 事例 １５ チェックリスト － 過去に痛い目にあった経験を共有する手段 問題 管理者向けの帳票出力時に警告が発生した。帳票自体に問題は無かったが、 警告が発生したことに対し、顧客から問題視された。 原因 警告を出す条件をテストするテストケースに漏れがあった 対策 上記原因に対して、以下の対策を行った。 プログラムとテストケースを修正した。 (結果) 当問題に関しては再発することは無くなった。 同様な問題の再発防止に向けて、更に以下の対策を行った。 テストケースのレビューを徹底するようにした。合わせて、レビューを実施する前に、 レビューでの確認ポイントをチェックリスト化しておくことを徹底した。 (効果) 障害発生率が全体に低下し、3か月後にはSLAを満たせるようになった。 教訓 過去に痛い目にあった経験はチェックリストに追加し、プロジェクトメンバー内で共有 することが重要。 22 障害再発防止策研究会 事例 １６ ポカヨケ －ミスを誘発しない手順を、担当者の経験を考慮して文書化す 問題 銀行へ送信予定だったファイルが送信されず、取引先への支払処理が一日遅れた。 原因 2つの原因が特定された。 1.運用担当者の経験が浅かったため、ジョブスケジュール変更手順の理解が不足 していた。 2. 変更手順書の記述に不足があった。 対策 上記原因に対して、以下の対策を行った。 1,2 昼間にジョブがリランできなかっため翌日のジョブでまとめて処理した。 ジョブスケジュールは正しい内容に修正した。 (結果) 当問題に関しては再発することは無くなった。 再発防止に向けて、更に以下の対策を行った。 1. 運用担当者への再教育 2. 手順書の見直し (効果) 同様なミスは無くなった。 教訓 ・ミスを誘発しない手順を考え、分かり易い手順書を作成することが重要（ポカヨケ） ・経験者には当たり前なことも、初心者には分からないことがある。担当者のスキル 経験に合わせた手順書が必要。 23 障害再発防止策研究会 事例 １７ オペミス撲滅 － 詳細な手順・チェックリスト、ペア作業 問題 マスターデータを更新する四半期処理の夜間バッチ処理が初めて動いたときに、 作成されるべきファイルの一つが作成されなかった。しかしジョブは正常終了して しまいエラーが検知されなかった。 （翌日システムオーナーがデータの誤りを見つけ、早い段階でオンラインを停止した ので、影響を受けたトランザクションは３件のみで済んだ。） 原因 2つの原因が特定された。 1. ファイルが作成されなかったのは、環境ファイルで示した出力ディレクトリーが システムテスト環境のディレクトリーのままで、本番環境用に変更されて いなかったため。 2. ジョブが正常終了してしまったのは、バッチプログラムのエラーリターンコードを シェルスクリプト側でハンドリンクしていなかったため。 これをテストするテストケースも抜けていた。 対策 上記原因に対して、以下の対策を行った。 1. トランザクションデータと環境ファイルを修正後、該当ジョブをリランした。 （結果） 正しいデータをマスターに反映し、午後にはオンラインを開放できた。 100人程度のエンドユーザーに影響が出たと思われる。 2. シェルスクリプトを修正した （結果） 当問題に関しては再発することは無くなった。 再発防止に向けて、更に以下の対策を行った。 1. 本番環境への導入手順書に、環境ファイルに対して何をチェックすべきか詳細に 記述した。また、本番環境へのリリース時には実施者とチェック者の二名の担当者 をアサインするようにした。 (効果) 環境の違いに起因する障害はその後は起きていない。 24 障害再発防止策研究会 2. シェルスクリプトに対するソースレビューやテストケースのレビューが、プログラム に対してのレビューと比較して不十分 であった。シェルスクリプトもプログラムと 同等のレビューを行うようにし、かつ、レビューの際のチェックリストには、異常系の 全ケースがハンドリングできているかの確認項目を追加した。 (効果) 類似障害（プログラムのエラーが検知されない）はその後起きていない。 教訓 重要な運用作業は、手順やチェックリストを詳細化した上で、ペアで行うことで オペミスを無くす。 25 障害再発防止策研究会 事例 １８ 密なコミュニケーション － 顧客満足度の高いシステム構築への鍵 問題 当社は大手SIerの下、外部設計～結合試験までを請け負った。当社の請負作業は 問題なく終了したが、その後の総合試験やUATにてエンドユーザーからの指摘事項を 多数受け修正せざるを得なくなった。 総合試験とUATは当社はSES契約で参加していたので追加費用はもらえたが、一部は 当社の請負範囲の作業での不備とされ、その分のコストはリカバリーできず、 利益が減少した。 原因 2つの原因が特定された。 1. 当社に仕事を依頼したプライムSIerは、顧客の情報子会社とは密に仕様を 確認していたが、エンドユーザーとの仕様確認の頻度は少なかった。 つまりエンドユーザーの巻き込みが不足していた。 2. 当社に渡された要件は固まっており、変更も少なかったので、Sierは途中で 設計書のレビューの手を抜いた。しかしながら手を抜いてレビューした部分も 含め、当社の責任とされた。 （SIerのレビューは通っていたので、本来はSIerの責任のはずだが、品質が 低い設計書もあったので、当社としてはあまり強く主張できなかった。） 対策 上記原因に対して、以下の対策を行った。 1,2 指摘された修正を行った (結果) アーキテクチャー上どうしても修正できない部分が残ったので、エンドユーザーの 不満は残った。顧客が要件変更と認めない部分については当社とSierがコスト 負担することになった。これらの交渉にも工数を要した。 再発防止に向けて、更に以下の対策を行った。 1. 当社がプライムで参加していない場合も、エンドユーザーが誰で、プライムSIerは どの程度エンドユーザーと要件を握れているかを把握しておくべきであった。 この件以後当社では、コミュニケーション計画のレビュー時に、エンドユーザーの 巻き込み度合いを報告させ、不足している場合は顧客と相談しコミュニケーションを 密にする（SIerの下の場合は、SIerに警告を発する）などの対応を促すようにした。 （効果は測定中） 2. PMに対して、プライムSIerのレビューに頼らずに当社で品質を担保するように 周知した。（効果は測定中） 26 障害再発防止策研究会 教訓 ・エンドユーザーとコミュニケーションが密なほど、満足度の高いシステムが作られる ・顧客やプライムSIerの言うことを鵜呑みにせず、現物を確認し、自分達の頭で 考えることが重要 。 (事例13と同じ) 27 障害再発防止策研究会 事例 １９ 業務精通者のレビューは必須と心得よ。 問題 小売卸業の販売管理システムで、今まで基幹システムと別システムだった販売 報奨金システムを基幹システムに組み込むことになった際に発生した問題。 組み込まれた販売報奨金システムで算出された販売報奨金の金額が、基幹の 顧客管理システムの値と異なる場合がある。（必ずではない） 原因 受注→売上、元売上→売上訂正、売上→返品等の商品状態遷移の間に、 商品の価格改定があった場合に採用すべき金額が誤っていたことが原因。 対策 ・顧客システム担当者より仕様を精査頂き、状態遷移パターン毎に採用すべき 金額の仕様を確認し、その確認結果に基づいてプログラムを修正した。 ・プログラム修正後、金額差異データを検出するSQLを作成し、定期的（最初は ４回／日、最終的には日次）で実行し、上記精査で漏れたパターンが無いか 監視を行った。 その結果、 ・販売報奨金の金額差異が無くなり、問題の現象は発生しなくなった。 ・金額差異の把握がユーザー指摘からシステム主導で網羅的に行えるように なった。 テスト設計書のレビューにおいてテストパターンの洗い出しが不十分であった ことから、再発防止のため、その後の案件においてテスト仕様書の外部レビ ュー時やテストパターンの確認にはユーザー側の業務精通者に参画してもらう ように依頼し、ユーザーに了承していただいた。 教訓 様々なパターン処理においてエンドユーザー担当者が全て把握できていない こともある。異なるシステムを統合する場合、双方のシステムを熟知している 人間の有無を確認し、その状況に応じたレビュー、テストの体制を構築すべき である。 28 障害再発防止策研究会 事例 ２０ システム運用設計は現実の業務量を想定してシミュレーションすること。 問題 小売卸業の販売管理システムで、今まで基幹システムと別システムだった販売 報奨金システムを基幹システムに組み込むことになった際に発生した問題。 販売報奨金管理の「金額確認→締処理」の業務が対象件数増大により、 金額確認の作業時間が大幅に延び、締日期間内で終わらない状態になった。 原因 新システムへの移行にあたり、営業活動で計上した販売報奨金の内容を、販売 推進部門が”全て”画面で承認するという新運用を取り入れたことで、担当者の 業務量が増大したたことが原因。 対策 ・販売推進部門が画面で承認する販売報奨金の種類を重要度に応じて限定し、 それ以外はシステムで自動承認することで、担当者の業務量を減らした。 （運用の変更） ・その結果、販売報奨金管理の締業務が締日期間内で終了できるようになり、 正常な業務運用状態になった。 ・再発防止のため、運用仕様検討時はデータ量・業務量面から、実用可能か 否かの視点で問題ないかユーザーと確認合意するというチェック項目をレビュー チェックリストに加えることとした。 教訓 運用が現実の業務量に沿うものか否かを見極め、顧客内で妥当性や実現性の 考慮が欠けていた要求であるならば、設計段階で歯止め・見直しを提案すること が大事である。 29 障害再発防止策研究会 事例 ２１ マニュアル作成では、細かな作業まで反映されていることを必ず確認すべ 問題 医薬業の施設管理システムのあるサブシステムで使用している照会業務で、 ある日突然、データベースを参照できないというエラー表示が出て、照会業務が 出来なくなった。 原因 他サブシステムとのI/Fに使用しているOracleDBのパスワード有効期限が切れた ため、DBに接続できなくなったことが原因。 運用マニュアルに定期的なパスワード更新の作業の記載がなかったことで、 運用担当者もパスワードの更新作業を失念していた。 対策 ・環境設定で新たなパスワードを設定し、ＤＢ接続、データ参照できるようにした。 ・また、運用マニュアルにパスワード更新説明を追加し、関係者への周知も行った。 ・再発防止のため、運用マニュアルは運用担当者と一緒に細かな作業も含め 全ての作業が網羅されているかを実施レベルでレビューすることを徹底するよう にした。 教訓 ルーチン作業については日次、週次、月次、年次それぞれに細かな作業まで 洗い出してマニュアル化を図り、運用と照らし合わせてのレビュー、実地確認が 必要である。 30 障害再発防止策研究会 事例 ２２ ゼロ件データチェックは、未登録状態だけでなく全削除状態でも確認すべ 問題 医薬業の施設管理システムのあるサブシステムで特定の帳票をWebで出力しよ うとすると、「データがありません」ではなく、スクリプトエラーになる。 実際には出力対象となるデータが存在しないため実害はなかった。 原因 プログラムの解析を行ったところ、最初からデータが何もない場合は正常な動き で「データがありません」と表示されるものの、一度データが登録された後にその データを全て削除してしまった場合のみ発生する現象であることが判明した。 対策 ・ユーザーと相談した結果、滅多に使用しない帳票で有り、また発生する条件も 非常にレアであることから、今回は事象が発生したことを記録するのみとした。 ・再発防止のため、今回の障害事例を社内の開発者に横展開し、このような障 害が起きないような設計、コーディングを啓蒙することとした。 教訓 データなしのチェックにおいて、最初からデータがない場合だけでなく、全て削除 された場合での動作確認もすべきであった。 31 障害再発防止策研究会 事例 ２３ 業務精通者のレビューは必須と心得よ。※事例１と同じ 問題 医薬業の施設管理システムのあるサブシステム一部の業務で、照会できない データが発生したり、帳票出力されないデータが発生したりする現象がある。 原因 プログラム及びデータの解析を行ったところ、参照している基幹システムの社員 マスタで、退職した社員が物理削除されている場合に障害が発生していることが 判明した。 基幹システムの社員マスタテーブル設計書には削除フラグが定義されており、 そのことから社員マスタは物理削除ではなく論理削除されるデータだと認識して プログラミングされていたため当該障害が発生した。 対策 基幹システムの職員マスタを参照しているプログラムに対し、プログラム修正を 行って対応した。 再発防止のため、既存データ仕様の確認は設計書だけでなく現実のデータも 確認するように開発メンバーへ事例紹介とともに周知した。 教訓 他システムとの連携がある場合は、概要設計時に連携先のシステム担当者と 掘り下げたレビューを実施すべきである。 32 障害再発防止策研究会 事例 ２４ 負荷テストのマシンスペックは推奨環境の最低レベルで確認すべし。 問題 損保系の保険料集金管理業務での障害事例。複数個所で独自に運用している スタンドアロンシステムで、ある箇所のユーザーで月次バッチ処理がタイムアウト のエラーとなり、業務が止まってしまった。 原因 障害発生箇所よりデータ量の多い他の箇所では発生しておらず、それぞれの 使用しているマシンスペックを確認したところ、障害発生箇所のスペックはシステ ム運用推奨スペック最低限のものであり、'スペックの低いＰＣでトランザクションの データ量が増えたことによりタイムアウトとなっていた。 対策 ・環境設定でデータベースのタイムアウト時間を延長し、インデックスの再編成も 行い、再度処理を実行して正常終了することを確認した。 ・再発防止のため、負荷テストは推奨最低スペックでの確認を行う必要があるこ とを、今回の事例紹介とともに社内に周知した。 教訓 負荷テストは、推奨環境の最低レベルでの確認が必要である。 33 障害再発防止策研究会 事例 ２５ 暗黙のルール － 「以前からこうだった」になっていないか 問題 残高照会等の顧客個人情報が行員端末から閲覧出来ない状況が発生。 環境を復旧するまで2時間、手作業による窓口業務が発生した。 原因 前日分バッチ処理において、該当処理が途中で異常終了しているにも関わらず 異常終了メッセージを正常と誤認して後続処理を実行した為、中途半端なデータが 本番に反映されてしまった。 メッセージを誤認した原因を分析した所、 当該処理は手書き修正の形で当日急遽差し込まれており、内容も誤っていた。 処理手順の変更は承認部署へ通すルールとなっていたが、有名無実化しており、 手順書の誤記を作業者の経験により補足するなどの対応が常態化していた。 正規ルール 承認部署 運用管理 作業者 作業依頼 承認・差戻し 直接依頼 問題① ルール違反 問題② 誤記は作業者の 判断で実行 対策 関係者へのヒアリ・ハットを実施して類似ケースを洗出し、挙がった類似ケースと 併せて手順書発行ルールの見直しを行った上、運用管理者と作業者双方に対して ルール尊守すべく再教育を行った。 教訓 「顧客の言う事だから」、「以前からこうだった」という安易な思い込みや作業環境に なっていないかチェック。暗黙のルールを許すな。 34 障害再発防止策研究会 事例 ２６ 安全と効率 － 流れ作業の良い面悪い面 問題 誤って違うデータファイルを転送して後続の本番反映処理を実行してしまった。 データ復旧の為、オンライン一時停止となる。 原因 作業手順として下記2点のミスがあった。 ①ファイル名の入力ミス ②バッチ処理実行前の確認漏れ(ファイル名、バイト数) 当該作業では規定コマンド一覧をデスクトップ上に用意し、その中から任意の コマンドをカット&ペーストして処理を実行していたが、誤って別のコマンドを 選択して実行していた。 キータッチミスなどの入力間違い防止や作業効率向上のため、利用頻度の高い コマンドをカット&ペーストするだけで良いように手順を組んでいたが、作業者が 処理内容を理解しなくても出来てしまう事から、明らかにおかしいファイル名や データであっても誤りに気付けない状況を生んでしまっていた。 対策 作業者に対して取り扱う全ての処理内容や手順について教育を実施。 規定コマンド一覧に内容説明のコメントを追記。 教訓 安全と効率のバランスには十分な分析を行い、定期的チェックをする事。 35 障害再発防止策研究会 事例 ２７ 行方不明なステークスホルダー － 追加仕様が青天井に増えて 問題 A社の次期販管システム開発案件において、度重なる納期遅延が発生。 人員を大量投入するなどの原価大幅増により採算悪化。 更にC/O後も受発注の数値が実データと合致しない不具合が起こるなど、 数々の品質問題が顕在化し、瑕疵責任を問われる事となった。 原因 原因分析の結果、開発途中で以下3つの問題が起こっていた。 ①受注当初から顧客側情報システム部門の一部窓口担当としか話を詰めておらず、 ある程度出来上がった段階でテスト環境を解放した所、見直し要求が多発。 機能から画面まで全般に渡って見直しを迫られた。 ②開発途中に顧客担当者が人事異動となり、それまでの経緯記録が不十分で あった事と顧客担当者が曖昧のまま推移した為、ユーザーへのテスト環境解放後、 見直し要求が複数部署から開発部門へ直接流れ、コントロール不全に陥っていた。 ③度重なる納期遅延から納期最優先な状況が生まれ、テストが疎かになった。 発注出来ない!! 納期は遅らせら れない Ａ社 使えない!! あの機能もこの 機能も必要だ!! 不十分なサービ システム利用 エンドユー 瑕疵責任追及 機能 要求 間に合わない!! テスト出来てない?! 要件が増えて対 応しきれない!! 追加要求 納期厳守 情報システム部門 状況が判らない!! 要件・要求 開発ベンダ 旧顧客担当 異動 仕様確認 顧客担当 対策 日々のデータ不整合については、別途に修正処理を設ける事で暫定対応とした。 開発第2フェーズの機能拡張時に本対応を行う事となる。 教訓 ステークスホルダーをきちんと見定めておくこと。 顧客からの要求と仕様事項は必ず明確化して、フェース毎に関係者とチェックする事。 36 障害再発防止策研究会 事例 ２８ 管理工数の十分な確保 問題 内部設計以降、慢性的な過重労働や、メンバーの残業が常態化した。 原因 外部設計までは、体制も小さく、有識者が内部レビューを実施することで、 品質がある程度確保できていた。 内部設計に工程が移り、新メンバーがプロジェクト構成員の大半を占めた 体制で以下の状況が発生した。 ① 新メンバーの仕様や開発ルールの理解不足及び、スキル不足 ② ケアレスミスによる手戻りの多発 ③ ＰＬが兼任している他のプロジェクトでも問題が発生 ④ 新機能に対する見積りの甘さ ⑤ 管理者や統合ベンダーとしての管理工数の見積り漏れ など 対策 作業範囲を切り分け、仕様変更を含んで、増員後、別体制を構築し管理者を 増やして対応した。 コストは増えたが、残業が増えないように調整を行い、プロジェクトを運営した。 又、今後の再発防止として、レビューも大事なファクターなので、次工程のメンバー 増員数を考慮して、前工程の人員を配置して対応した方が望ましい。 教訓 統括ベンダー作業、突発的に発生する会議を考慮し、管理工数の割合を見直す 外部設計の工程では、要件定義の内容を理解している人が必須。 その後の体制を考えて、要件定義をする人を配置 37 障害再発防止策研究会 事例 ２９ 標準化は早期着手 問題 外部設計書のレビューは、作成者の自己チェックとリーダーによるドキュメント レビューを行った。 ドキュメントレビューに対しては、主に要件定義から参加しているメンバー（PM） が実施した為、チェックの粒度が高く、人数が少ない為、レビュー待ちによる遅延 が発生した。 また、類似機能でも、記述の仕方が違うといったような指摘が多く見られた。 原因 ドキュメントレビューは、画面レイアウトに関する指摘が、全指摘の半数以上を占めた。 これは初回のユーザーレビュー時に、細かい指摘が多発し、以降も同様のレベルでの レビューが実施されたことによる。 また、IE6～10を許容したが、IE10をベースに作成したため、IE6でのみ発生する画面の 崩れ等が散見された。 類似機能であっても、時間の都合上、複数のメンバーが同時並行的に作業を行って しまったことに起因した。これにより、内部設計やプログラムも違った様に作成されて しまうことが発生した。 対策 規模が大きなプロジェクトでは、標準化が大事になってくる。その作成粒度が、まちまち かもしれないが、まず作成と客先との合意が必要になってくる。今回の画面レイアウトや 類似機能の統一もこの標準化の一部で、画面レイアウトに関しては、画面仕様を標準化 する資料（画面レイアウト共通仕様）の実施、及び類似機能は、1本ベースとなる設計書 を作成し、それを基に他の類似機能の設計を進められるようにすれば細かいレベルの 指摘が少なかったように思える。それを見越しての、要員・スケジュール調整が必要である。 教訓 規模やプロジェクトの粒度に合せて、標準化を要件定義をする段階で実施する 外部設計の工程では、要件定義の内容を理解している人が必須。 その後の体制を考えて、要件定義をする人を配置 38 障害再発防止策研究会 事例 ３０ オフショア開発の注意点 問題 外部設計を弊社で、内部設計から結合テストをオフショアで開発を行うプロジェクトで、弊社で 受入れテスト後、ユーザー受入れテストを行った。しかし、ユーザー受入テスト序盤には、外部 設計不備による障害、終盤はプログラムミスによる障害が多く検出された。特に、イレギュラー ケースやレアケース、実運用を想定したシナリオ等で障害が多く発生し、障害対応が回らなく なってきた。 また、結合テストフェーズで発生した障害より、ユーザー受入検証で発生した障害（要望も 含まれるが）の方が多いということが、発覚した。 原因 ユーザー受入れテストの段階で多くの不具合が発生した原因は、弊社で行った単体テスト フェーズでのケース漏れや全体的にその量が少ないことにあった。また外部設計も遅延し、 Fix前の外部設計を基に内部設計に着手したことも、後に仕様変更に関する指摘も多く発生 する原因となった。 また、今回結合テストのテスト計画とテストパターンの洗い出しを弊社にて行いそれを基に、 オフショアに結合テストケースを作成してもらったが、その結合テストのシナリオ作成にも 問題があった。 対策 序盤、ユーザー受入れテストの障害が多かったことから、要機能を結合テスト実施中に 仮リリースし、ユーザー受入検証前に打鍵してもらうことにした。これにより、早い段階で 指摘を上げてもらい、オフショアとの契約が残っている間に修正依頼を出すことができ、 プログラミング要員がいない弊社の工数を軽減した。 また、今回結合テス仕様書作成にあたっては、要件定義・外部設計から参画している 要員にて、要件定義レベルでのレビュー実施とケース作成フォロー、ポイント説明の 必要性を感じた。 教訓 早い段階で実際にユーザーに現物を見てもらうことが、品質や使用性向上 のためにも非常に有効 オフショアに結合テストケースを作成してもらう場合は、要件定義・外部設計から 参画している要員にて、要件定義書レベルでのレビュー実施とケース作成フォロー、 ポイント説明の必要 39 障害再発防止策研究会 事例 ３１ コスト圧迫の要因 問題 人の運用とシステムの係わりに関する設計の粗さから、業務運用とシステムのGAPが 多く発生した。 その為、運用回避可能な点については対策を依頼、運用時の手間やミスが発生しそうな 内容についてはシステムにて対応とシステム側での対応が多発した。走りながら考える 顧客であるため、その切り分け作業や改善作業で、コスト流失が増えていた。 原因 開発者側の業務に関する知識が乏しく、かつその業務知識をカバーする顧客からの システム要求が提示されませんでした。 また、顧客の業務要求の洗い出しが不十分であったことから、本番稼働までの期間 が短く、納期が迫っていたため、大枠での完成を優先し、細かな要求については運用 が明確になった時点で保守対応することで、客先担当者と合意しました。 このとき、担当者間では認識があっていたので、議事録など作成せず、なおかつ重要な ステークフォルダーへのネゴをとっていなかった為、開発プロジェクトの範疇で対応すること になり、コストが増大しました。 これも、長く付き合いのある顧客だったということと、顧客のコストの厳しさに対する 意識欠如、担当者間の認識が合っていた為の詰めの甘さが原因でした。 対策 今後、同じようなプロジェクトを未然に防ぐために、次のような再発防止策を考えました。 ① 顧客がするべきところと思っていたところが、していただけてなかったので、要件定義 の前に、業務定義から行う。 ② 見積段階で顧客の役割分担や関与具合を見極めたうえで、必要な体制、コスト算出を 行うこと。 ③ 担当者では金額に対する決定権がないため、決済権限のあるステークホルダーと十分な ネゴシエーションを取ること。（ｺﾞｰﾙの明確化と対応金額の認識併せおよび記録と承認） ④ システムに関与するステークホルダーがシステムに求める内容を要件として洗い出す ⑤ 問題は、後になればなるほど、是正に労力がかかる。 教訓 要件定義の前に、業務定義を行う 要件定義に関わることは、決裁権限のあるステークホルダーと 十分なネゴシエーションと記録・承認を行う 40 障害再発防止策研究会 事例 ３２ パッケージ開発の注意点 問題 プログラム/仕様書品質が悪く、成果物が要望と異なるケースが多発。 原因 パッケージの導入のプロジェクトで、安心感から設計開発期間が短いため、 期間を優先してベンダーサイドではそのカスタマイズ作業を簡素化し行っていた。 また、現場の要員は本番稼働準備、運用支援やリハーサル立会いなどを行い、 そこで発生した障害対応が中心となっていた。そのような状況からパッケージは プログラム検証のみを優先し、品質に対してはベンダーサイド任せになってしまった。 対策 今後、同じようなプロジェクトを未然に防ぐために、次のような再発防止策を考えました。 ① パッケージ選定条件に、体制、品質管理基準の評価を追加する。 ② パッケージベンダーへのカスタマイズ要件の管理方法の徹底。 教訓 委託先の体力測定（短期対応が可能であるか、短納期となる懸念があるか など）を実施する。 パッケージベンダーへのカスタマイズ依頼は、その管理方法を徹底すること 41 障害再発防止策研究会 事例 ３３ 体制、スキルの注意点 問題 有識者の不足、設計ｽｷﾙの不足、体制ﾃﾞｻﾞｲﾝの失敗により、基本設計の低品質、 未収束が発生。 原因 要件定義開始時の体制上、原価管理精通者が２名しかおらず、それが業務理解の 不十分が仕様・深堀りの浅さに繋がった。また、客先マネジメント体制に見合う弊社の マネジメントが不足していた。 オフショア側に対しては、弊社による技術者精査が未実施、オフショア側でのアーキ テクチャーに対応できる技術者の不足、生産性の高い技術者の不足も重なった。 対策 今後、同じようなプロジェクトを未然に防ぐために、次のような再発防止策を考えました。 ① ノウハウを持つ業務精通者以外のＳＥをプロジェクト期間中にどのような配置で どう育成していくのが近道かの検討と計画を定義し、前工程で実行する。 ② 次工程以降の一括請負を実施する場合、前工程の準委任のプロジェクトでも 内部レビューを実施し、体制に関するレビューを徹底する。 ③ マネジメントの役割を細分化し、提案時にレビューをする。 ④ オフショアに対しては、全要員体制のキャリアと経験年数などから、通常客先から 求められている内容や言語レベルまでも確認する。 教訓 メンバーの育成と役割の細分化は、それが必要になる前工程で実施すること 次工程以降で請負契約が発生する場合、ステコミは請負契約前の工程から 参加が必要 42 障害再発防止策研究会 事例 ３４ テストケース作成者は具体的なデータイメージを作成せよ 問題 とある金融システムのテスト中に入力された売上金額がデータに正しく 登録されなかった。 原因 入力状態の組み合わせで、入力項目が異なるパターンがあるが、条件の 判定方法が誤っており、どんな組み合わせでも一方の項目のみでデータ登録 されてしまった。 【試験で見つからなかった理由】 ■ テストデータ作成ミス 入力状態が異なるケースをあげているが、試験実施の際に、 本番データでは有りえない値（単純なデータパッチ）で試験しており、 組み合わせパターンの認識不足。 ⇒テストケース作成者（有識者）と、テスト実施者（若手）が異なり、 本来のテストケースの意図が伝わっていない。 対策 上記の問題に対して以下の対策を実施した。 テストケース作成者と、テスト実施者の認識が異なることを考慮し、 テストケース作成者は、具体的なデータイメージ（マトリックス）を 添付資料に追加した。 ⇒実施者と作成者の認識ずれが減少した。 再発防止として更に以下の対策を実施した。 第三者がみても誤解のないテストケースを上げることで、 試験データパターンの作成漏れを防ぐこと。 教訓詳細 テストケース作成では、自分のみ分かる表現で終わらせるのでなく、 第三者がみても誤解のない記載（バリエーション）を提示する。 43 障害再発防止策研究会 事例 ３５ 可能な限り、本番環境と同等の環境を構築し、試験せよ 問題 従業員就業データ取込みに想定より大幅に時間がかかってしまった。 原因 １．性能試験時のテストデータ数と本番時のデータ数が異なっていた。 ２．開発環境と本番環境で以下の点について異なっていた。 ・DBのINDEX項目 対策 上記の問題に対して以下の対策を実施した。 できるだけ本番時と同じ環境及び状況下で試験を行った。 （データ数，設定値等，時間、サイクル，適用モジュール） ⇒本番を意識することで性能面の確認、及び運用することによって、 発見される潜在バグの早期発見を行うことができた。 再発防止として更に以下の対策を実施した。 詳細 本番を意識しないと見落としてしまうことがあるので、 本番の運用を想定した開発及びテストをする必要がある。 44 障害再発防止策研究会 事例 ３６ ２重チェック、手順を駆使して作業ミスを起こさない意識を徹底すべし 問題 経歴処理取得手順にてデータが一部作成されなかった。 原因 「ｄｂuser」権限で実行しなければならない所を「root」権限で実行したため。 対策 上記の問題に対して、以下の対策を実施 本番環境と同等の環境を用意し、テストについても本番と同じデータを使用し、 確認するよう徹底した ⇒同様のミスが減った 再発防止として更に以下の対策を実施した。 １．手順の確認漏れを防ぐ為、チェック項目が追加された新フォーマットの 手順書を印刷して使用する。 また、使用時には実施項目ごとにチェックを入れる。 ２．作業実施の限界時間に余裕があるため、後続開始時間を タスク管理表に明記した上でその時間内に必ず二重チェック者 と作業を実施する。 ３．週次・月次・依頼作業と同等の意識を持って日時作業に取り組むよう 注意喚起を行う。 教訓詳細 チェック確認時の意識の持ち方を改めて考える機会であり、再発防止については 継続的な啓蒙活動が必要である。 45 障害再発防止策研究会 事例 ３７ 成果物はレビューしないと意味がない 問題 NWの通らない箇所を発見。 原因 Comfig内容に誤りがあった。 詳細設計よりConfigファイル作成時に誤入力であることが判明。 対策 上記の問題に対して、以下の対策を実施 Configのレビューが不足していたため、セルフチェック、クロスチェックを 必ず実施することを明確化した。 ⇒バグ件数の減少につながった 再発防止として更に以下の対策を実施した。 レビューは複数人の目を通して確認することを徹底した。 詳細 人為的なミスを回避するために運用ルールに乗せることも検討が必要。 46 障害再発防止策研究会 事例 ３８ 複数人の目で作業ミスを撲滅せよ 問題 ファイル登録時に必要な入力情報がなかったため、異常終了した。 原因 直接原因 バックアップファイル側のファイルは更新していたが、 走行用ファイルは更新されていなかった。 真の原因 作業者が行った作業の検証者がいなかったため、 ファイルの更新作業は行っていてもチェックが行き渡っていなかった。 対策 上記の問題に対して、以下の対策を実施した。 バックアップ側にあったファイルを走行用ファイルにコピーし、再走行した。 ⇒正常終了を確認した 再発防止として更に以下の対策も実施した。 １．作業者と検証者でそれぞれ確認し、作業者だけではなく、 検証者の確認も行う。 ２．単純なコピー作業でも手順書を作成し、手順に沿った作業を実施する。 ３．想定外の結果になった場合は上司にエスカレーションする。 ⇒検証者の視点も増えたことにより、作業者だけの判断で 作業を進めることが減ったため、作業ミスの軽減につながった。 詳細 単純コピー作業においても人が実施していることを想定し、 作業をチェックするよう作業者と検証者を設けること。 47 障害再発防止策研究会 事例 ３９ 安易にデータをマスクするな。本番と同等のデータを使用せよ 問題 ある公共団体のシステムである。該当者のキー情報＋氏名で記録を1件に特定し、 付随情報を取得するはずが複数件ヒットしてしまい、処理できずに移行ツールが 異常終了してしまった。 ※該当者のキー情報は該当者の異動等に伴って複数レコードが存在した。 原因 直接原因 本来、キー情報の異動前後では同じ氏名が登録されるはずだが、登録する際の 漢字が誤って登録されていたため、別ユーザーとして認識された。 （ユーザの登録ミス） 真の原因 テスト環境では本番データをユーザより借用して試験を行ったが、個人情報保護 のために氏名の苗字部分をマスクしていたため検知できなかった。 対策 上記の問題に対して、以下の対策を実施した。 登録済みの氏名を正しい漢字に修正を行い、移行ツールを再走行した。 ⇒移行作業ではデータ起因のトラブルがほぼなくなった。 再発防止として更に以下の対策を実施した。 １．マスクデータの試験ではなく、本番データを使用した試験を行う。 ２．個人情報に関する問題はテスト環境の構築場所をユーザの居室内、 厳格な入退室管理にて対応。 詳細 試験に使用するデータは安易にマスクするべきではない。 マスクすることがわかっていても、実際のデータを使用しての試験も行う必要が ないかは確認すること。 48 障害再発防止策研究会 事例 ４０ 試験では何が必要かを見極め、短時間で消化出来る方法を模索せよ 問題 プログラムから作成するCSVデータに本来は整数値で出力すべきところ 小数点が含まれていた。 原因 直接原因 DBより取得したデータを格納する変数を数値型（整数）から文字列型に変更した 際の考慮漏れ。 （試験中のオーバーフローによるバグに対応するための修正。数値型（整数）の 変数の場合は暗黙的に変換されていた。） 真の原因 リリース直前で試験に避ける時間が限られていたため。 ※上記のオーバーフローに伴うバグ修正後の試験としてオーバーフローしない ことしか確認していなかった。 対策 上記の問題に対して以下の対策を実施した。 機械的な試験の割合を増やした。 ⇒試験時間の減少、バグの検知率が上昇した。 再発防止として更に以下の対策を実施した。 修正内容の確認は修正内容の確認だけでなく、バリエーションで確認する。 詳細 時間がないからといって安易に試験範囲を絞るべきではない。 実施すべき試験範囲をどうすれば短時間で消化できるかを考えるべき。 試験を行うには、どのように作業を行ったら良いか、最短ルートを見極め、 テスト計画を立てるようにすること。 49
© Copyright 2024 Paperzz
