第 26 回経営情報学会「システム統合」特設研究部会会議録日時：平成 1７年２月 21 日(月)18:00-21:00 場所：ＫＤＤＩ本社ビル（千代田区飯田橋 3-10-10 ガーデンエアタワー27 階 L 会議室）出席者：伊藤誠彦，繁野高仁，島田裕次，手島歩三，南波幸雄，飯島淳一，金翰局（記）（敬称略）資料： 1. システム統合の問題の本質と教訓（島崎理一氏） 2. 「システム統合研究部会」報告書打合わせ合宿（飯島主査）議事： 1. 株式会社プロシードの島崎理一氏により，「システム統合の問題の本質と教訓」（副題：みずほファイナンシャルグループでのシステム統合作業から見えるプロジェクト管理の重要性）についての報告があった。（今回の報告にあたっては，すべて雑誌・新聞等で公表された内容のみから構成されており，その内容を材料にしてプロジェクト管理の観点からまとめたものである）・みずほファイナンシャルグループ統合の流れ − １９９９年８月１９日，記者会見にて２００２年に 3 行統合し，業務別銀行へ移行すると発表する。以降，システム別に分科会が設置され，システム選定作業が行われる。 − ２０００年 3 月 25 日，国内勘定系システムが旧 DKB の富士通システムに決まるなどシステム選定作業が終わり，ようやく統合作業が開始される。 − ２００1 年 5 月 10 日，予定通り，2002 年 4 月システム移行計画をみずほ HD 経営会議で確定する。 − 2002 年 4 月 1 月 3 行統合当日，ATM 障害などシステムトラブルが発生する。・システム統合作業での問題の本質と教訓 − 問題① ユーザー部署が統合後でも既存のサービスは変わらないと判断し，システム側への変更依頼をしていなかった。また，統合準備作業をユーザーとシステムで分けて行った際に，お互いのシステム上の特殊処理についてシステム側が理解できていなかった。これらの問題への教訓としては，統合作業における変更内容のオーナーの明確化，システム側での特殊なシステム仕様のドキュメント化，システム側での作業スコープをユーザー・オーナーと合意すること等が挙げられる。 − 問題② 意思決定者と現場の意思疎通がうまくできていない，また銀行子会社の位置づけが 3 行でお互いに合わないなどというコミュニケーションの面で様々な問題が起こっていた。これらの問題への教訓としては，発注側作業（WBS）の明確化，システム子会社政策の早期統一，背番号をはずしたバーチャルな統合作業用の人事異動での意識化改革等が挙げられる。 − 問題③ システム選定後，GAP 分析を行っていた際に，To−Be モデルを最初明確にしておかなかったため，その後の作業が現状分析から見た内容が中心となりあるべきビジョンにつながらない部分がでてしまった。また機能の絞りこみでユーザーの視点が見られない部分があった。これらの問題への教訓としては，GAP 分析移行の作業工程とゴールを明確にすること，将来モデルを固まらない場合はスコープの絞込みにユーザーの参画が必要，ユーザーの戦略に基づいた機能選択等が挙げられる。 − 問題④ システム開発工程の定義などプロジェクト管理に関する社内で使っていた用語が業界標準でなかったため，お互いに通じない場合があった。これらの問題への教訓としては，開発工程の定義をプロジェクト計画策定前に実施すること，またできれば PMBOK や海外での標準的な工程を参照し，その定義の変換を行っておくこと等が挙げられる。 − 問題⑤ ビジネス戦略と分断されたところに IT 戦略がなかった。つまり，IT への投資額は外資系銀行に匹敵する規模ではあったが，主に統合作業，追加開発，運用維持等に使われてしまい，戦略的な面ではほとんど使われていなかった。これらの問題への教訓としては，当初の統合時点，その後の運用における中期戦略の必要性，運用コストについての視点を明確に戦略に入れること， ITIL （Information Technology Infrastructure Library）等のマネジメントプロセスの導入の必要性等が挙げられる。 − 問題⑥ トップダウンでのシステム選定の際に，企業のミッションと選定過程に相当な乖離があった。つまり，統合作業の目的に顧客視点がない部分もあった。これらの問題への教訓としては，選定基準の明確化，選定結果の社内公表及びコンセンサス，明確な個人の人事評価基準の設定，またそれに基づいた統合作業の実施等が挙げられる。 − 問題⑦ リレーコンピュータの導入などの重大な変更への対応ができていなかった。つまり，変更管理プロセス，また変更管理のための課題管理，進捗管理のプロセスが統合関係者の間で認識共有されていない部分があった。これらの問題への教訓としては，プロジェクト実施着手までに変更管理プロセスを計画すること，意思決定までのコミュニケーション計画も変更管理にあわせて導入すること，進捗管理の可視化等が挙げられる。 − 問題⑧ 取引先情報の最終形を固めるにはかなりの時間が費やされるにもかかわらず，取引先情報をどうするかについては早期に方針が出せない部分があった。この問題への教訓としては，取引先情報を最終的に組織としてどう持つかについての設計を早期実施することが挙げられる。 − 問題⑨ 本番開始が無理であったことを事前に認知していたにもかかわらず，本番開始時期についての見直し，延期等を公式の議論に展開するプロセスが実質機能しなかった。これはそれまでの進捗管理，課題管理の問題の他に，プロジェクト中断のプロセスを事前に用意していなかったため，そのための判断ができなかったことも遠因の１つと考えられる。これらの問題への教訓としては，進捗管理における進捗の可視化，プロジェクトオーナーによるプロジェクト中断プロセスの導入の必要性等が挙げられる。 − 問題⑩ しっかりとした運用テストが行われていなかったことによる振込み漏れ及び 2 重引き落としの発生の可能性も考えられる。これらの問題への教訓としては，運用テストにおける人間系のテストの重要性，システム統合プロジェクトにおける運用本番テストの重要性等が挙げられる。・本番開始直前の状況，統合対象となるシステムの評価の重要性，EVM 手法によるプロジェクト中断の判断基準などについて活発な議論が行われた。２．次回の予定・次回は，報告書の原稿の検討及び打合わせを予定している。以上