ID:74198さん

【プロジェクト概要】 ・子会社との基盤統合を伴う、システム全体の運用設計書作成、運用移行、サービスマネジメント（SLA及び運用改善）を実施 【チーム情報】 ・6名（自社1名、協力会社5名、90人月） 【役職】 ・プロジェクトマネージャ 【担当】 ・顧客カウンター及びプロジェクト体制構築、システム運用開始後の運用改善 【環境】 ・顧客環境 【課題・問題点】 ①子会社の情報システム部門の要員スキルが高くない上、体系立てた運用保守設計が出来ておらず、属人化されていた。 ②親会社の情報システム部門の役職者（顧客側のカウンタ）が威圧感のある方で、かつ方針も都度変わるため、 　ドキュメントレビューがなかなか先に進まない。 【打ち手】 ①親会社側で定義したITILベースの下記ドキュメントをベースに子会社との運用の差分（出来ているか否か）を比較表で整理し、 　見える化を行なった。 　・運用・保守計画の策定、運用管理（サービスレベル管理、インシデント管理、問題管理等）設計 　・業務運用（業務監視、業務トラブル、業務オペレーション等）設計 　・アプリ保守設計、インフラ保守設計　 ②親会社の現行システム運用保守作業の課題抽出（プロパー側の課題も含む）を行なった上で業務改善項目を作成した。 　その上で、あらたにシステム運用保守設計を行なったことで、運用ミス低減や作業時間の短縮化が実現出来た。 　また、常にシステム開発リーダも同席するよう社内調整し、顧客レビューを行なった。 　そのことでその場で討議し方向性を決めていったことで、持ち帰り検討項目が減少し、顧客への信頼感も増した（威圧感が徐々に 　薄れていった）。

【プロジェクト概要】 ・ネット証券における全システム（約300）の障害管理及び事後改善を実施 【チーム情報】 ・8名（自社8名） 【役職】 ・品質管理部門　課長 【担当】 ・週次障害精査会（CIO及び各リーダ参加）の事務局運営 ・証券フロント系システム、基盤、ネットワークにおけるシステム障害管理及び事後改善を実施。 ・監督官庁（金融庁、日本銀行、日本証券業協会、日本取引所グループ等）向け、障害メール報告（第1報）及び 　報告書（第2報・最終報）作成 【環境】 ・自社環境 【課題・問題点】 ①全300システムが複雑に絡んでいることから、定常的に毎週10～20個のシステム障害が発生し、 　システムの品質向上が急務の状態だった。システム開発現場では日々開発に追われ、システム障害の改善活動 　手がまわっていなかった。 ②システム障害の改善活動まで至っていなかったことから、監督官庁への最終報告がかなりの件数滞留していた。 【打ち手】 ①システム障害の改善活動 　複数の開発メンバにヒアリングを掛けた結果、改善活動手法（なぜなぜ分析による根本原因の追究とそれに基づく改善立案） 　が未経験だったことが主な理由と判明した。 　各チーム単位に週次MTG（残障害の改善進捗と改善内容レビュー）を設定し、各チームが起こした具体的な障害を基に 　運用改善手法を私の方でレクチャーした。障害事象により、類似事象の横展開を行なったことで、 　障害発生率が以前の半分（過去に構築した古いシステムの潜在バクまでは洗い出せなかったため）となった。 　 ②監督官庁への報告対応 　①により、各システム障害の本格対応まで、凡そ約2週間で完了することが出来るようになった。 　それを受け、報告書（第2報・最終報）作成が素早く対応することが出来るようになった。

【プロジェクト概要】 ・大手化学メーカ向け、全購買業務の順次BPOサービスへの移行及び既存サービスのマネジメント（SLA及び運用改善）を実施 【チーム情報】 ・50名（自社10名、協力会社40名、50名×20カ月=1000人月） 【役職】 ・プロジェクトマネージャ 【担当】 ・顧客カウンター及びプロジェクト体制構築及び各種レビュー、サービスの運用改善 【環境】 ・自社環境（自分も含めメンバの2/3はリモート環境であり、一部中国の子会社メンバ30名あり） 【課題・問題点】 ①サービス提供から1年半経過した中で、顧客の課長（プロジェクトのカウンタ）が威圧感があり何事にも細かい性格だった。 　プロジェクトが安定せず、弊社側のプロジェクトマネージャのメンタルがやられ、計3回変わった。 　そのため、私がプロジェクトを引き継ぐ際、前任者との十分な打ち合わせも出来ず、メールベースでの対応となり、 　スタート当初は手探り状態でプロジェクト運営を行なった。 ②プロジェクト内での運用改善活動が出来ていなかったため、プロジェクト引継ぎ後、半年間で3件の運用ミスを起こした。 【打ち手】 ①対顧客対応とプロジェクト引継ぎ後の安定化活動は下記の通り。 　なお、毎年の顧客満足度調査では5点満点中4点と、プロジェクトへの一定評価を頂いた。 （対顧客対応）　 　定期報告（週次及び月次）、個別MTGを通じ、顧客の課長から次から次へと繰り出された課題に対して、 　逃げずに真摯に対応した。 　その対応にプロジェクトリーダ格と役割を決めて、納得感のある回答を行なうことを心掛けた。 　そのことで徐々に顧客から信頼を勝ち取ることが出来た。 （プロジェクト引継ぎ後の安定化活動） 　プロジェクト参画オファー時、提案書、契約書、月次報告書、課題管理表等、プロジェクトの現状を把握出来るドキュメントは 　すべて読み読み込んだ。その中から、現行の課題や注意すべき点等、確認ポイントを洗い出した上で、引継ぎに臨んだ。 　プロジェクトリーダ格と社内MTGを週1~2回に増やし課題共有とその対応策をスピーディに行った。 　リモート中心のプロジェクトのため、メンバとのコミュニケーションが希薄になるところは、都度電話やスラックの通話機能を 　用いて会話し、メンバとの接点を常に持った。そのことで、今後の問題点や課題の予兆を掴むことができ、 　主に社内MTG（必要に応じて個別MTG）を通じて、リーダと決めた各対処策を行なった。 ②プロジェクトメンバは直接原因及び根本原因を掴むことが出来ないでいたため、運用ミスを題材にプロジェクトメンバと一緒に 　なぜなぜ分析とその後の対処策の立案することで、スキルトランスファーを行なった。 　また、いままでのプロジェクトでの経験を踏まえて「改善活動の進め方」を資料としてまとめ、プロジェクトメンバとの勉強会を 　行なった。この資料を基に継続的な改善活動を行ない、現在プロジェクトで定着している。

【プロジェクト概要】 ・次期基幹系システム稼働（基幹系：6、周辺系：9）に向けた運用保守構築 【チーム規模】 ・5名（自社5名、15人月（現在進行中）） 【役職】 ・プロジェクトマネージャ 【担当】 ・プロジェクト全体総括をしつつ、運用役割定義を行ない、 　次期基幹系システムに向けた考え方整理、想定ロードマップを現在作成中。 【環境】 ・自社環境 【課題・問題点】 ①現行基幹系システムが2000年初頭よりホスト環境で稼働しており、システム構築当時のドキュメントがない中で、 　次期基幹系システムを構築中。 　そのため、現行システム運用でも体系立てた運用設計が出来ておらず、属人化している。 ②情報システム部門（約80名）にシステム運用経験者は私を含め2名しかいない中、システム運用課が立ち上がり、 　メンバの育成が急務な状態である。 【打ち手】 ①この上期に運用体制及び役割のTOBE像と今後の活動に向けたスケジュールを作成すべく、 　下記成果物を定め、ベンダ協力の力を借りず、いままでの経験を活かし各種ドキュメントを他業務と並行で 　作成中（現在オンスケ）。 　・運用役割定義・次期基幹系システムに向けた考え方整理 　・運用標準化　 　・想定ロードマップ ②メンバ育成として上記①の活動を一緒に対応することで、日々のオペレーション業務にとらわれない 　統制的なシステム運用経験を積ませるべく活動中。