ITサービスマネージャ試験 ～練習論文～

こんにちは。

今日は、ITサービスマネージャの午後Ⅱ問題の練習用に作成した、わたしの論文を紹介したいと思います。
学習初期に書いたものですし、誰かに添削してもらったものでもありませんので、品質は高くないですが、ネタ提供等になれれば幸いです。

題材は平成２３年秋季試験の「ITサービスの改善活動について」です。
アプリ運用者としてのネタが使いやすいと思い、手始めにこの題材で練習を行いました。問題、講評等についてはこちらからどうぞ。

以前のブログで紹介させてもらった論文対策本に記載された注意点を意識し、主語を「わたし」にすること、関係者を巻き込んでいったこと、行動の背景をしっかり説明することなどを書いてみたつもりです。

試験合格者の格を落としてしまうようですが、実際には運用チームのリーダ経験もないですし、設問ウの全社への展開などは実績のかけらもないです。

想像や想定だけでは説得力に欠ける論文になってしまうかもしれませんが、４割の事実と４割の想像・想定に２割の『盛り』という名のスパイスをかけることで、ITサービスマネージャとして必要な検討ができる知識・経験・思考が身に着けているかをアピールできればよいと思います。

【タイトル】
ITサービスの概要とITサービスの改善活動の対象とした事象

１　ITサービスの概要

　私はSIer企業であるS社に勤めている。現在、プラント企業であるT社の情報システム部門にて、運用保守チームのリーダを担っている。サービスの対象としているシステムは①ERPシステム（会計、営業、人事、ワークフローシステム）、②プロジェクト管理システム（EVMによる進捗管理、設計・発注・調達業務システム）、③社内ポータルシステム、である。これらのシステムは、T社のグループ会社を含む3社、計3,000名が利用している。運用・保守チームでは、インシデント・障害の対応、機能改善などの保守作業、システム・ジョブ稼動状況の確認といったITサービスを提供している。アドオン機能が多く、完全スクラッチで構築されたシステムもある。そのため、障害発生時などの影響調査ではベンダへの問い合わせといったサポートを使えることが少ない。

１．２　ITサービスの改善活動の対象とした事象

　T社とは、月次で定例会を行っている。そこでT社情報システム部社員より、運用保守サービスの品質低下を指摘された。具体的には、業務処理に関わるインシデント発生時において、対応スピードが以前より落ちていることを指摘された。
　そこで私は、チームメンバ全員に対応スピード低下の原因と、それに対する改善策を提案してもらうこととした。なぜならば、全員の意見をもらうことで、私が認識できない問題を発見することができると考えたからである。また、ボトムアップによる改善を行うことで、チームメンバの士気向上につながるとも考えたためである。私は、チームメンバからのヒアリング結果を運用保守チームのリーダとして取りまとめ、改善策の実施に取り組んでいった。

２．実施した改善策と得られた効果
２．１　ITサービス改善のために実施したこと

　私は、運用サービスの品質向上に向けて次のことを行った。顧客から指摘のあった、インシデント対応スピード低下の原因と対策についてチームメンバへのヒアリングである。ヒアリング対象者は限定せず、新入社員を含め全員に回答をしてもらった。ただ聞いて、考えてもらうだけではなく、アンケートのフォーマットを作成した。フォーマットでは、項目選択（原因・改善策のカテゴリ、緊急度、優先度、など）、数値（対応予定工数など）で回答できる質問を多く用意した。なぜならば、漠然とヒアリングをするだけでは、有益な情報が出にくいのではないか、また、回答レベルにばらつきが生じ、分析が困難になるのではないかと考えたからである。
　ヒアリングの結果、次の理由で対応に時間が掛かっているという意見が多くあげられた。(1)主担当システム以外の仕様が分からない、 (2)不明点の確認先が分からない。
　私は、システムごとでの引継ぎ、有識者の管理は行っているが、システム全体での共有ができていないことが根本原因であると考えた。
　課題の改善策として、システムごとにメンバのスキルを棚卸し、全体で共有することにした。これは、システムごとの有識者の明確化と運用スキルが足りていないステムを見える化を目的とした。
　スキルの棚卸に当たっては、サービス対象システムを機能レベルで一覧化した。さらに、機能ごとに利用者数と機能停止時の顧客業務へのインパクトを数値化し、重要度の高い機能が分かるようにした。メンバのスキルについては５段階とし、設定した指標にそって各人に記入をしてもらった。これにより、インシデントへのスムーズな対応が可能になった。また、効率的な人材育成の計画・実施を行った。具体的には、重要度の高いシステムについては、主担当以外のメンバにも最低限の仕様を理解してもらった。また、有識者の少ないシステムについては早急にメンバの育成を行った。

２．２　得られた効果

　スキルの棚卸、メンバの効率的な育成計画の立案・実施を繰り返し行った。これにより、運用メンバが担当システム以外の仕様についても理解を深めた。また、有識者が不足しているシステムはなくなった。結果的に、インシデントの対応スピードが、改善策の対応前と比べ、15%向上した。また、障害発生時の二次被害の減少、開発チームからの引継ぎ時間短縮といった効果を得ることができた。

３．成果の組織全体への展開と工夫した点
３．１　成果の組織全体への展開と工夫した点　

　成果の展開は、運用保守チームという組織全体への展開と、全社という組織全体への展開を行った。
（１）運用保守チームへの展開について
　運用保守チームは大きくアプリ・インフラチームに分かれている。今回改善活動を行ったのはアプリチームからであった。運用保守チームの品質向上に向けて、スキルの棚卸をインフラチームでも取り組むことにした。しかし、アプリとインフラではスキルの棚卸をする際、観点が異なるという課題が見つかった。インフラはシステムを機能単位で仕様を理解する必要がないからである。そこで、インフラチームでは、システムのサーバごとに一覧化したものと、インフラ技術を一覧化したものを展開することとした。
　また、このような資料は一度展開した後、運用されずに陳腐化することが多々ある。その対策として、定期的にスキル棚卸を実施するタイミングを決めた。予定したタイミングの１ヶ月前にはメンバへリマインドを行い、更新のし忘れがないようにした。また、運用保守をするシステム・機能・サーバは日々変化していく。スキル棚卸の一覧へは開発チームからの引継ぎタイミング、及びスキル棚卸の更新タイミングに合わせて最新化することとし、資料の陳腐化を防いだ。
（２）全社への展開について
　全社への展開に当たっては、スキル棚卸を実施したことを詳細に話すよりも、メンバヒアリングを行った点を重点的に話すようにした。今回私が取り組んだスキルの棚卸は、品質向上に向けた施策の一つでしかない。現場によって取り組むべき課題は異なり、スキル棚卸の実施が各現場にとってもっとも優先すべき改善活動であるとは限らない。そのため、品質向上に向けた改善フローのひとつとして、メンバへヒアリングを行ったことを展開すべきであると考えたためである。
　最適な改善策は状況により異なる。また、現在行った対策も状況によりやり方を変えていく必要がある。今後も継続的に改善に取り組みたい。また、内部のメンバだけでは見出せない改善策もあるので、成果を挙げたものについては発信をし続け、外部からの情報をキャッチし続けていきたい。

―以上―

読み返すと支離滅裂な部分もあり、ひどいものですね（笑）