ITサービスマネージャ論文メモ

平成29年度問1、ITサービスの提供における顧客満足度の向上を図る活動について

ITサービスの概要と顧客とのコミュニケーションの仕組みについて

サービスの概要

・T社案件

・情報システム部門で行っている運用とヘルプデスク業務をC社に委託する。

顧客とのコミュニケーションの仕組み

・A社の情報システム部門と週次で打ち合わせを行う。

・A社のシステム利用者からヘルプデスク業務に関する意見をいただくこともある。

サービスの報告でレビューしたサービスの達成状況、課題、及び課題への対応について

サービスの達成状況

・問い合わせ受付から回答までの目標期間は3日であり、95％の問い合わせについて達成している。

・残りの5％については納期を相談済

・運用については与実を管理するチェックリストを作成し、その結果を報告している。

サービスの課題

・問い合わせ完了後に残作業がのこりインシデントがクローズできない状況が発生している。

・情報システム部門からの作業依頼の納期を守れないという事象が発生している。・

課題への対応

・問い合わせが完了しているインシデントについてはクローズし、残作業は別の管理表を作成してそこで進捗管理を行う。

・情報システム部門からの問い合わせについてボリュームの大きいものは別途管理表を作成してそこで管理を行う、優先度を設定してもらい、納期を合意する。

顧客の期待と満足の状態、及び顧客満足度向上のために策定した活動計画と実施状況について

顧客の期待と満足の状態

・サービスの状態については概ね満足

・サービス品質向上と、工数削減につながる活動をしてほしい。

策定した活動計画

・インシデント分析を行い、月次で改善に向けた検討会を内部で開催する。

実施状況について

・同じような問い合わせを何度も受けており、FAQの改善が必要であることがわかった。

・月次のインシデント分析と、内部検討会で改善案を出し、顧客に提案ができている。

平成29年問2、継続的改善によるITサービスの品質向上について

ITサービスの概要及び特に重要と考えたサービス品質とその目標値について

ITサービスの概要

・A社の業務システムBシステムの問い合わせ窓口

重要と考えたサービス品質とその目標及び目標値について

・ユーザーからの問い合わせに3日以内に回答すること、95％以上の問い合わせで達成することをSLA目標としている。

・あまり余裕を持って達成できておらず、問い合わせ受付から回答までの期間の5％短縮を目標として活動した。

サービス品質の目標値と達成するために立案した管理指標

立案した方策と、立案時の考慮点

・2つの方策を考えた。

・1つ目は、問い合わせの受付方法を電話ではなく、なるべくメールにしてもらうということ。

・問い合わせにかかった時間を分析した結果、スキルの低いメンバーが電話で問い合わせを受けた場合、ヒアリングがうまくできず聞き返しなどで時間がかかっていることがわかった。

・考慮点としてユーザーの利便性を損なわないよう、電話とメールの問い合わせの受付に関するガイドラインを作成し、周知した。

・2つ目はナレッジの蓄積

・過去の問い合わせはシステムに登録しているが、数が多くうまく探せていない。

・よくある問い合わせや、対応方法が決まっているものをナレッジとしてまとめて蓄積することで問い合わせ時間の軽減ができると考えた。

・考慮点としてナレッジを登録するための時間が必要になるので、顧客に説明し了承いただく必要があった。費用対効果を算出し了承いただいた。

管理目標

・メール問い合わせ率を50％⇨70％にする。

・ナレッジ蓄積は2ヶ月間に100件の登録を目標とし、全体の20％の問い合わせについてナレッジを見て回答できることとした。

改善活動の評価と、評価結果を次の取り組み計画に生かした継続的改善活動

改善活動の評価

・最終目標は達成できた。

・実施した施策についてチーム内で振り返りを実施

・メール問い合わせは60％でチーム内でも大きな効果を実感できていなかった。

・ナレッジの蓄積について150件の登録を行い、全体の25％の問い合わせをナレッジから回答できた。

評価した結果を次の取り組みに生かした継続的改善活動

・達成状況とメンバーの実感した効果から効果の期待値を数値化し、それをコストで割って継続するかどうかを検討した。

・毎月振り返り会を開催し、改善活動の再評価や改善を行うとした。

平成30年問1、ITサービスマネジメントにおけるプロセスの自動化について

ITサービスの概要と、自動化対象としたプロセスの概要及び自動化の状況について

ITサービスの概要

・A社は複数のパッケージソフトを組み合わせた業務システムを使用している。

自動化対象としたプロセスの概要及び自動化の状況について

・A社は人事異動が多く年度末は数百人規模に登ることもある。

・ユーザーシステムはそのうちの1システムに登録し、他システムにデータ連携している。

・ユーザーマスタは項目数が多く、人が作成、登録、チェックを行っている。

・ユーザー登録の支援ツールを作成することとした。

自動化の範囲拡大にあたっての活動における取り組み内容及び実施計画について

取り組み内容

・年度末の人事異動対応は多大な時間がかかりA社内でも問題とされていた。

・ツールを作成する場合、どこまで機能を盛り込むか、そのためにどれだけの費用をかけるかを検討する必要があった。

・人事異動パターンを分析し、作成するツールの提案を行った。

・作成するツールについていくつかの案を作成し、自動化範囲とそれによる削減工数と開発工数を算出し、費用対効果を計算した。

・作成した資料をもとに社内での作成承認を得た。

実施計画

・承認を得た5月からスタートし翌年の人事異動に間に合うようスケジュールを立てた。

・運用チーム内でプロジェクトチームを立ち上げ、週次で状況確認の打ち合わせを行うとした。

KPIとその目標値

・目標値は5段階評価するものとし、予定通り達成できた場合は3とする。

・ツール作成度合いをKPIとし、予定通りの機能で作成できた場合は3と評価する。

・ツール作成により削減できた工数をKPIとし、想定した削減工数5人日を達成した場合を3と評価する。

実現したプロセスの自動化及び組織におけるプロセス習熟度向上の評価について

プロセス自動化の評価について

・ツールの作成度合いは当初予定した機能を作成し、評価は3とした。

・削減工数は7人日の工数削減効果があり、評価を4とした。

プロセス習熟度向上の評価について

・今まで、登録データ取りまとめ、登録データ作成、登録後の確認を人が行っていたが、ツール作成により、ツールの投入用データ作成とその確認だけで良くなった。

・人が正確性を担保しなければならない部分が大幅に削減された。

・ツール作成前は1件あたり30項目を人が作成していたが、ツール作成後は5項目で良くなった。

・今後、登録データに問題が見つかった場合などはツールにチェックの仕組みを追加することでさらにプロセス習熟度向上を行うことができる。

平成30年問2、ITサービスの運用チームにおける改善の取り組みについて

ITサービスの概要と運用チームの構成及び運用チームの課題とその根拠について

ITサービスの概要と運用チームの構成

・A社の業務システムであるBシステム

・C社はBシステムの運用とサービスデスク業務を請け負っている。

・業務は3名で行っており、最近1人のメンバー入れ替えがあった。

運用チームの課題とその根拠について

・課題は2点ある。

・1点目は、メンバーの知識に偏りがあり、一部作業が属人化していることである。

・根拠として数ヶ月の運用実績では、同一メンバーが作業を担当し、サービスデスクでもメンバーごとに担当するシステムが固定化される傾向がある。

・2つ目は、ナレッジの蓄積が不足している点である。

・手順書はあるが、暗黙的に実施しているポイントなどが存在している。

・問い合わせはシステムに登録しているが登録内容に一部不足があり、次回以降利用しようとした時に十分活用できないという問題がある。

・根拠として新メンバーが業務を行うにあたり手順書や過去の対応実績をもとに対応しようとしたが情報が不足しておりできないということがあった。

改善の取り組みと設定した目標値、運用チームの力を結集するために行ったこと

改善の取り組み

・①スキルマップの作成とそれを元にした教育活動の実施。

・②ナレッジを蓄積する仕組みの作成。

・①に関しては、スキルマップを作成し4段階でメンバーの評価を埋めた。メンバー間でのレクチャーと業務の割り振りの変更でスキルマップの内容について向上を図る。

・②に関しては、別途ナレッジを登録しチーム内で共有することとした。

目標値

・①に関してはスキルチェックシートで全項目で3以上が2人以上いること、新メンバーが20％以上の項目で3以上となることとした。

・②ナレッジの蓄積件数が半年で100件となることとした。

運用チームの力を結集するために工夫した点

・①に関して週次MTGでチームの達成状況を確認した。

・②に関しては追加したナレッジと役に立ったナレッジがあれば日次MTGで共有した。

・ナレッジ管理システムを導入した。

改善の取り組み結果

目標の達成状況

・スキルチェックシートで、全項目で3以上が2人以上となるという目標については達成できず結果は90％程度であった。新メンバーの目標は達成できた。

・ナレッジの蓄積は目標を達成した。

良かった点、悪かった点

・①の良かった点は結果を定期的に確認することでチームの意欲向上が見られた。自分が担当していない業務を行うことで自然とスキルマップ内容の向上ができた。

・悪かった点としてはレクチャーの計画が明確に決まっておらず、目標達成に必要なレクチャーの実施が行えなかった。

・②の良かった点としては、ナレッジ管理ツールを導入することですぐに業務の役に立つことが実感でき、メンバーの意欲が高まった。自分の登録したナレッジが他メンバーの役に立ったという情報はモチベーションアップに効果があった。

・悪かった点は、ナレッジの書き方のルールが統一されておらず、一部のナレッジを見つけられないと言ったことがあった。また、ナレッジの粒度がバラバラでメンバーが登録時にどのように登録するか迷ってしまうということがあった。

令和元年問1、環境変化に応じたプロセスの改善について

ITサービスの概要と、既存の変更プロセスに影響を与えた環境変化について

ITサービスの概要

・A社はWebサイトの運営を行う企業

・さまざまなサイトを運営しており、コンテンツという単位で管理されている。

・変更案件は、企画チームから開発チームに案件の打診があり、そこから要件定義、スケジュールの調整を行なっている。

・コンテンツごとに1つの開発環境を持ち開発を行なっていたため、一度に進められる変更案件は原則1つである。

・急ぎの修正や、障害対応の際は、検証環境のソースコードを手動で開発前に戻した上で対応を行なっていた。

変更プロセスに影響を与えた環境変化の内容

・A社ではビジネスのスピードアップに対応するため、コンテンツの変更速度を加速させることが決定した。

・重点コンテンツが定められ、企画チーム、開発チームのリソースをそこに集中して変更を実施する。

・今までのように1つの案件が完了したら次の案件という、スピード感ではなく、複数の案件を同時進行させ、順次リリースを行う必要がある。

環境変化によって影響を受けた変更プロセスの概要、変更プロセスに生じた問題点とその理由、改善に向けた施策及び期待効果について

変更プロセスの概要

・A社の変更プロセスは、週次の企画、開発チームミーティングで打診があり、担当者をアサイン、担当者レベルで打ち合わせを行い、チームミーティングで共有され、最終的に変更案件審査会で承認されるという流れである。

変更プロセスに生じた問題点とその理由

・変更案件のスケジュールを決めるフェーズで問題が発生した。

・今までは、開発側から対応可能なスケジュールを提示して進められていたが、重点コンテンツでは、限られた期間で複数の案件を開発し、完了したものから順次リリースすることが求められた。

・問題発生の理由としては、各コンテンツごとに1つの開発環境しか持っておらず、案件の同時進行、順次リリースに対応する仕組みを持っていなかったことである。

改善に向けた施策及び期待効果について

・開発の進め方を変更する。

・検証環境で開発を行うのではなく、検証環境はテストを行うためだけの環境とし、開発は開発者のPCに仮想環境を立ち上げて実施する。

・検証環境、本番環境への反映はツールを用いて自動化する。

・具体的には、定められたgitブランチにソースコードをマージしてツールを実行することで対象ブランチの内容がサーバーに反映される。

・期待効果としては2つある。

・1つ目は開発作業を個人PCで進められるため、開発者の人員を確保すれば案件の同時進行が可能となる。

・2つ目はリリース時の作業軽減と品質向上が見込まれる。

実施結果と評価について

・期待通りの結果を得ることができた。

・俊敏な対応という観点では、スケジュール決定の際に大きな制約となっていた「同時に1案件しか進められない」という事柄を取り除くことができた。

・進められる案件は、かけられるコスト次第という明確なロジックができ、上層部からも対応スケジュールに納得感があると評価された。

・品質の確保という点では、手作業による作業ミスを0にできた。

・リリース時の作業者の負担が減り、ミスが発生する範囲も狭めることができたことから、リリース後の不足の事態にも素早く対応できるようになり、企画チームから品質が上がったと評価された。

・コスト削減効果も大きく、手空きとなっていた開発者を案件が多く発生しているコンテンツに振り分けることで人員リソースの有効活用ができるようになった。また、リリース時の作業工数を試作実施前の40％程度まで削減することができた。

令和元年問2、重大なインシデント発生時のコミュニケーションについて

ITサービスの概要と、発生した重大なインシデントの概要及び利害県警社について

ITサービスの概要

・A社は社員1,000名程度の企業

・社内の業務システムであるBシステムがあり、全社員が利用している。

・保守・運用をC社に業務委託している。

発生した重大なインシデントの概要及び利害関係社について

・夜間バッチでエラーが発生し異常終了が発生した。

・通常は朝6時にシステムが自動で立ち上がるが、夜間バッチでエラーが発生した場合、データの整合性を担保するため、自動起動は停止される。

・利害関係社は、システムを利用するA社の全社員、システムを提供しているA社情シス部のGM、部長、データ連携を行なっている他システム担当者がいる。

重大なインシデントへの対応で実施した手順の内容と利害関係社とのコミュニケーション

インシデントへの対応で実施した手順

・大きく3つの手順で対応が行われた。

・1つ目は関係者への素早い情報連携であり、あらかじめ定められたエスカレーションルートに従って情報連携が行われた。

・2つ目はエラーが発生した原因の特定、対応策の検討

・3つ目は、システムへの緊急対応の実施である。A社情シスのGMが承認者として定められており、この日も対応策が承認の上、実施された。

利害関係社とのコミュニケーション

・情シス関係者には３度のMTGで情報が共有された。

・10時、13時のMTGでは発生している事象について最新情報が連携された。確証の取れていない情報であっても、なるべく最新の情報が連携された。

・15時のMTGでは原因が特定され、復旧手順が示され、GMが承認した。

・システム利用者向けには３度の周知を行った。

・１度目はシステムが利用できない状態であるという第一報であり、情報の正確性と迅速性を重視し、情報量は最低限とした。

・２度目は復旧見通しが立った段階で復旧予定時刻を周知、３度目は復旧完了の周知を行った。

インシデントへの対応で明確となったコミュニケーションにおける課題と改善策について

課題

・2つのコミュニケーションにおける課題が明らかとなった。

・1つ目は場外発生時に一部の関係者が自宅勤務となっており、障害発生の第一報を受け取れていなかったということがある。

・2つ目はD社に24時間365日の監視を委託していたが、検知した障害の連絡がメールとなってしまったため、関係者が障害に気がついたのが翌朝出社した段階になってしまったことである。

改善策

・1つ目の課題に対する改善策は、エスカレーション資料に関係者へのメール連絡が含められた。具体的にはITサービスマネージャがGMに報告するとともに、関係者が登録されたメーリングリストへも発生連絡をすることが定められた。

・2つ目の課題について、緊急の場合は定められた番号へ電話連絡することになっていたが、緊急の基準が定まっていなかったことと、夜間であったため電話をためらってしまったということがあった。

・何を緊急とするか基準を明確にした資料が作成され、A社、D社間で確認された。

・休日夜間は電話ではなく、ショートメールでの緊急連絡とすることが定められた。緊急連絡先の番号も複数に増やされることとなった。

平成29年度問1、ITサービスの提供における顧客満足の向上を図る活動について

ITサービスの概要とコミュニケーションの仕組み

ITサービスの概要

・A社は複数のシステムを組み合わせた業務システムを持っている。

・利用部門ではシステムに関する代表者を立てて、報告を受けたり変更案件の承認を行なっている。

コミュニケーションの仕組み

・システムを提供する情報システム部門と、利用部門代表者で毎月1回の定例会を実施している。

サービスの報告でレビューしたサービス目標の達成状況、課題及び課題への対応について

サービス目標の達成状況

・①サービスデスクの回答時間

・受け付けた問い合わせの種別ごとに回答時間を定めており、90％の問い合わせについて回答時間を達成することを目標としている。

・操作の問い合わせについては回答時間目標を達成できた。調査依頼、作業依頼については目標時間を達成した問い合わせは85％であった。

・②不具合の発生件数及び対応状況

・発生した不具合は半年以内に解消することを目標としている。

・目標を達成したことを報告した。

課題及び課題への対策について

・課題は情報システム部門と利用代表者の双方から挙げられる。

・情報システム部門より、先日リリースした変更案件について不具合があり、利用部門に多大な影響が出たことに関して課題が挙げられた。

・情報システム部門で受け入れテストを行う際に、業務側からすると頻繁に利用する機能について確認ができておらず、不具合が流出してしまった。

・対応として、受け入れテストに利用代表者も参加してもらい、業務的に利用頻度が多い部分などを中心に確認いただくこととした。

コミュニケーションの仕組みを使って把握した顧客の期待と満足の状態及び満足度向上の活動計画と実施状態について

顧客の期待と満足の状態

・報告内容に関しては満足である。

・利用者の少ないシステムの代表者から、（利用者が少ないので）この場では課題をあげづらいという意見が出された。

策定した活動計画について

・対象システムの利用者に後日ヒアリングを行い、対象システムで多くの課題を抱えており、相談したいこともあるとのことであった。

・活動計画としては、別途打ち合わせの場を設けることとした。

・課題を一覧化してもらい、開催頻度を検討し、利用者側には参加者の選定を依頼した。

実施状況について

・課題の数が多かったため、まずは隔週で打ち合わせを実施することとした。

・利用部門からは、各セクションのリーダーにも参加いただくことになった。

・システム代表者からは、協議の場ができてよかったと評価をいただいた。

平成29年度問2、継続的改善によるITサービスの品質向上について

ITサービスの概要及び特に重要と考えたサービス品質とその目標及び目標値について

ITサービスの概要及び重要と考えたサービス品質

・A社は数年前に業務システムを再構築した。

・重要と考えたサービス品質は変更案件の対応である。

・過渡期であるため、ユーザーからの要望が多く発生し変更案件を早く正確に対応する必要があると考えた。

目標及び目標地について

・目標は変更案件の対応期間短縮と、品質向上

・対応期間短縮は要望受付からリリースケジュールの決定までを2ヶ月、リリース完了までを半年と設定

・品質向上は変更案件リリース後の不具合と認識違いの発生を0件とすることとした。

サービス品質の目標値と達成するために立案した方策、管理指標と方策立案時の考慮点

サービス品質の目標値を達成するために立案した方策

・対応期間の短縮に対しては、変更案件のプロセス整理を行うこととした。

・受け付けた要望をどのような期間で何を対応するかを明確化した。

・品質向上に関しては、変更案件へのユーザーの関わり方を改善した。

・要望を受け付けた後の要件定義や受け入れテストは情シスが担当していたが、業務チームの代表者にも参加いただくこととした。

管理指標

・プロセス整理では、新プロセスで対応した要望の割合と目標期間を達成したものの割合とした。

・関わり方の改善では、ユーザーが変更案件の要件定義、受け入れテストに参加した案件の割合とした。

方策立案時の考慮点

・業務プロセス整理では、要望の受け付け方を明確化する必要があった。

・具体的には、変更要望書を記載してもらい個人ではなく部長からメールしてもらうこととした。

・ユーザーの関わり方の改善では、ユーザー担当者の中で案件ごとに誰を代表者とするか明確化してもらった。

改善活動の振り返り結果と次の取り組み計画に生かす継続的改善活動について

改善活動を行なった結果の評価と次の取り組み計画への反映について

・変更案件のプロセス整理では、9割の案件で目標期間を達成した。

・次の取り組みとしては、一律のプロセスではなく簡易な変更は専用のプロセスを作成して対応期間をより短縮する対応を検討した。

・ユーザーの関わり方の改善では、ほぼ全ての変更案件でユーザー代表者が要件定義、受け入れテストに関わることで認識違いが発生しなくなった。

・改善点として、要件定義の際にユーザーから要望が多数寄せられ打ち合わせが長期化する問題があった。対応としてユーザー側で追加要望がある場合は一度持ち帰って検討してもらうこととした。

継続的改善活動について

・情シス内で月次の振り返りを行い、変更案件の品質向上に努めることとした。

・定期的にユーザー代表者と打ち合わせを行い、変更案件の要件定義、受け入れテストについて報告を行うとともに、改善すべき事柄について業務オーナーに継続的にヒアリングを行うこととした。

平成30年問1、ITサービスマネジメントにおけるプロセスの自動化について

ITサービスの概要と、自動化したプロセスの概要及び自動化の状況について

ITサービスの概要

・A社の業務システム

・ワークフローシステムがある。

自動化したプロセスの概要及び自動化の状況

・ワークフローシステムを新しい製品にしたことで、申請書の参照権限を自動設定できるようになった。

・営業部では事務担当者に参照設定を行い、事務担当者が決済結果のダウンロードを行なっている。

・ファイルを案件ごとの共有フォルダに格納している。

自動化の範囲拡大にあたっての活動における取り組み内容及び実施計画について

取り組み内容と実施計画

・営業の事務担当者の負荷軽減のためRPAツールの導入を検討することとなった。

・3つの対応を行なった。

・①社内ニーズの確認、軽減工数の算出

・5つある営業部のうち1つの営業部から要望が寄せられた。担当者にヒアリングを行い削減できる工数を確認した。

・②製品の選定

・RPAツールを扱う企業に製品デモを行ってもらい、コストの提示、提案を行ってもらうこととした。

・③製品決定から自動化までの計画策定

・製品決定後は営業部担当者と要件定義を行い、自動化完了までのスケジュールを作成する。

KPIとその目標値

・①に関しては要件のヒアリング範囲をKPIとした。5段階評価で、担当営業部だけのヒアリングであれば2、営業部全てのヒアリングで3、全社ヒアリングで5とした。

・②に関しては製品を行ってもらい比較検討する製品数をKPIとした。5社の製品検討を評価5とした。

・③に関しては、年度内の対応範囲をKPIとして定め、スケジュール策定完了までを評価3とし、実装完了が4、営業部以外の部署での要件定義もできた場合は5とした。

プロセスの自動化及び組織におけるプロセス習熟度向上の評価について

プロセス自動化の評価

・社内ニーズの確認では営業5部からのヒアリングを行い、全ての部で概ね同じ作業を行なっていることを確認した。

・5社に製品デモを行ってもらい、3社がニーズを満たすことを確認した。

・コストと今後の社内展開を見据え比較検討し導入する製品を決定した。

・営業担当者と開発者を交え要件定義を行い、自動化が完了した。

・1ヶ月あたり50万円のコスト削減が実現できた。

プロセス成熟度向上の評価

・これまでの作業では、各営業部ごとにルールを定めていたが、部ごとの手順の違い、担当者によるアレンジが加えられていることがわかった。

・ツール導入の自動化により、ルールが明確化され、またそれが確実に実施される仕組みができた。

・ツールの利用拡大を含め継続的な改善活動も行って行くこととした。

・営業部の導入事例を全社展開し、他部からも自動化作業についてのニーズを掘り起こすこととした。

平成30年問2、ITサービスの運用チームにおける改善の取り組みについて

ITサービスの概要と運用チームの構成及び運用チームの課題とその根拠について

ITサービスの概要と運用チームの構成

・A社の業務システム

・運用チームは3人体制で行なっている。

運用チームの課題とその根拠について

・課題は年度末対応の業務負荷が高いことと、年度末対応の運用作業が正しく理解できていないことである。

・根拠としてシステム稼働1年目の年度末対応では作業を正しく理解できておらず手戻りや混乱が発生し、一人当たり3月の残業時間が60時間を超えた。

・年度末作業として、システムへの人事異動情報の登録と、年度切り替えのためのシステムの設定情報の収集がある。

改善の取り組み、目標と運用チームの力を結集するために工夫したこと

改善の取り組み

・①人事異動情報の登録支援ツールを作成する。

・②年度切り替えで収集する情報について、背景、具体的な内容、期限、工数を一覧化した資料を作成する。

設定した目標

・ツールの作成は、2年目の年度切り替えが始まる3月までにツールの開発とテストを完了させること、また、作成したツールによって工数を5人日削減することとした。

・一覧表作成では、資料の作成を12月末までに完了させること、次回の年度末対応で資料を用いて手戻りやミスを発生させないこととした。

運用チームの力を結集するために工夫した点

・振り返りを行なって、チーム内で課題を再認識し、改善点も自分たちで考えることで自分ごととして捉えるようにした。

・改善案の進捗状況の確認を月次で行い、現状をチーム内で共有することでチームの力を結集できると考えた。

目標の達成状況及び取り組みの評価について

目標の達成状況

・ツールの作成は、予定通りのスケジュールで作成し、2年目の年度切り替えで5人日の工数削減を達成できた。

・年度末対応の一覧表作成では、予定通りに資料の作成を完了したが、手戻り発生を0件にすることができなかった。

・1年目の年度切り替えでの実績をもとに資料を作成したが、データの状況や組織改正の内容により1年目と異なる対応が必要になり、それが資料に反映されていなかったためである。

取り組みの評価について

・振り返りを行い改善策を自分たちで出すことで、メンバー一人一人が自分ごととして捉え、精力的に取り組むことができた。

・タスクに直接関わらないメンバーも作業を融通して、作業時間を作れるようにチームで協力することができた。

・定期的な進捗確認も有効であり、進捗が遅れそうな時は、アイデアを出し合って乗り切ることができた。

・悪かった点としては、年度切り替え対応資料の作成が不十分であったことがある。改善点としてはシステムの保守チームも巻き込んで資料を作成する必要がある。

令和元年問1、環境変化に応じたプロセスの改善について

ITサービスの概要と既存の変更プロセスに影響を与えた環境変化の内容について

ITサービスの概要

・A社の業務システム

・保守チームと、サービスデスクがある。

既存の変更プロセスに影響を与えた環境変化について

・ユーザーからのシステムのパラーメータ修正や、マスタ値の変更依頼が多く寄せられるようになった。

環境変化によって影響を受けた変更プロセスの概要、変更プロセスに生じた問題とその改善に向けた施策及び施策の期待効果について

変更プロセスの概要

・システムのプログラム改修を伴う変更案件は年に数回のリリース計画を立てて保守チームが実施している。

・システムのパラメータ変更やマスタ値の変更については、簡易変更として保守チームが随時対応を行なっていた。

・ユーザーからの要望、依頼を受けて検証環境を更新する。A社のシステム担当者の承認を受けて本番環境へ反映が行われる。

・保守チームメンバーの本番環境のシステムアカウントは普段無効化されており、本番作業時にはA社情シス部のGM承認が必要となる。

変更プロセスに生じた問題点とその理由

・簡易変更の件数が増加したことで、保守チームの負荷の増加と、要望を受けてから対応完了までの時間がかかりすぎるという問題が発生した。

・対応完了までに1週間程度かかるようになりユーザーからももっと早く対応してほしいという意見が寄せられた。

改善に向けた施策及び期待効果について

・簡易変更の一部の対応をサービスデスクに移管することとなった。

・サービスデスクは、本番アカウントの常時有効化が認められており、リソースにも余裕がある。

・保守チームが検証環境を更新した後、そのエビデンスをもとに本番環境に反映することとした。

・本番環境への反映承認は必要だが、アカウント有効化の承認は不要となる。

・期待効果として、保守チームの簡易工数にかける工数を3人日以内にすること、ユーザーからの要望を受け付けてから対応完了までの期間を3日以内とすることとした。

実施結果と評価について

・概ね期待した通りの結果を得ることができた。

・ユーザーからの要望受付から対応完了までの期間は3日以内をクリアした。保守チームが検証環境を更新する場合は平均3日、サービスデスクだけで対応完了する場合は平均1日で対応が完了する。

・ユーザーとの定期打ち合わせで対応が短くなったと評価された。

・保守チームの対応工数も4人日削減され平均で2人日の対応工数に抑えることができた。

・A社情シス部との定期打ち合わせの中で、GMなどから工数削減について評価された。

・俊敏な対応と品質確保について、サービスデスクで対応を完結する場合、どうしても１度目と同じ者が対応するケースが多くなり、そのメンバーの負荷が高い場合完了までの時間が長くなるという傾向があった。

・また、２度目以降に別メンバーが対応するときは、１度目のエビデンスだけで対応できないケースが発生し保守チームへの質問が発生した。

・対応策として、１度目の対応の時にあらかじめフォーマットを決めた簡易な手順書を作成し、別メンバーも同じ品質で対応できるようにした。

令和元年問2、重大なインシデント発生時のコミュニケーションについて

ITサービスの概要と発生した重大なインシデント及び利害関係社について

・A社はレストラン紹介サイトを運営している。

・DBが高負荷になり応答不能となるインシデントが発生した。

・A社が提供する複数のサイトでエラーが表示されてしまう事態となった。

・利害関係社は社内では障害が発生したコンテンツの開発、企画担当者、問い合わせ窓口、経営層、社外では、コンテンツ利用者、レストランオーナーなどである。

重大なインシデントへの対応で実施した手順の内容と利害関係者とのコミュニケーション

重大なインシデントへの対応で実施した手順

・障害発生時に開発部内で対応チームが結成された。メンバーはDB担当者と影響を受けたコンテンツの担当者である。

・DBの復旧を急ぐとともに、各コンテンツの影響範囲がまとめられた、報告は開発部長より経営層にエスカレーションされた。

・各コンテンツの開発担当者は、それぞれ担当する企画担当者に連絡して対応を協議した。

・具体的には、サイトのメンテナンスページへの切り替え、DB復旧後はサイトにお詫びのお知らせを掲載した。

・DBは1時間程度で復旧したが、一部のコンテンツではデータの復旧完了までに24時間程度を要した。

利害関係者とのコミュニケーションについて

・大きく分けて3つのコミュニケーションが行われた。

・開発部内のコミュニケーションは関係者を宛先に入れたメールでやりとりが行われた。情報の正確性よりも迅速性が重要視され、リアルタイムな情報連携が行われた。

・社内への情報連携では、開発部長から経営層へエスカレーションが行われたのと、企画担当者へ個別連携が行われた。企画担当者と開発担当者の連絡は主に電話でやりとりが行われ、コンテンツごとの対応が協議された。

・ユーザーへの情報連携は、メンテナンス画面への切り替え、復旧後はお詫び文言の掲載を行なった。レストランオーナーにはオーナーサイトへのお知らせ機能を用いて連携が行われた。最低限の確定情報を素早く連携することに重点が置かれた。

インシデントへの対応で明確になったコミュニケーションにおける課題と改善策について

課題

・課題は大きく2つあった。

・1つ目は、開発部ないのコミュニケーションでメールが用いられたがやりとりが多くなりすぎて、DB担当者からの重要な連絡が見落とされるということが発生した。

・2つ目は社内情報の連携に不足があった。問い合わせ窓口にと営業担当者に第一報を連携するのが遅れ、利用者や、レストランオーナーからの問い合わせがあった際に明確な説明ができなかった。

改善

・開発部内のコミュニケーションはチャットツールを使うこととなった。対象メンバーを追加したチャンネルでメンション機能を用いて各メンバーが必要な通知のみを受け取ることができるようにした。

・社内の関係者への連携不足について、今後重大なインシデントが発生した場合は、全社周知を行うこととなった。具体的には、イントラの掲示板への掲載と全社メーリングリストへの送信を行うこととした。

平成29年度問1、ITサービスの提供における顧客満足度の向上を図る活動について

ITサービスの概要と顧客とのコミュニケーションの仕組みについて

ITサービスの概要

T社システム

顧客とのコミュニケーションの仕組み

週次の情報システム部との会議月次でのユーザー部門との会議の2つが行われている。

サービス目標の達成状況、課題及び課題への対策

サービスの達成状況

問い合わせを受け付けてから回答するまでの期間は3日、95％の問い合わせでこの期間を達成することを目標としている。

ほとんどの期間でこの目標を達成したが、繁忙期については達成できないことがあった。

課題

2つの課題があり、1つ目は繁忙期に業務システムの担当者が手一杯となってしまい、サービス目標を達成できないことがあった。

2つ目は、調査に時間がかかる問い合わせについて、ユーザーとのコミュニケーション不足により、状況がわからないとクレームが発生したことである。

課題への対策について

固定化されているシステム担当者の見直しを行い、別のシステムの担当者が繁忙期にはサポートできるようにした。

手順かできる問い合わせ対応について、手順化しサービスデスクに業務を移管した。

時間のかかる問い合わせについてスケジュールを作成し顧客と共有した。

顧客の期待と満足の状態、及び顧客満足度向上のために策定した活動計画

顧客の期待と満足の状態

週次の情報システム部との打ち合わせでは、変更案件の工数削減を求められた。

ユーザー部門との打ち合わせでは、利用者の少ないシステムの意見が出しづらいという意見があった。

課題への対応について

変更案件の口数削減では、ヒアリングを行い、工数削減案を作成した。

顧客がいくつかの前提条件を承認することを条件に新しい方針で顧客と合意し、工数削減を行った。

ユーザー部門との打ち合わせでは、利用者の少ないシステムの利用者との打ち合わせの場を別途儲けることとした。

平成29年度問2、継続的改善によるサービスの品質向上について

ITサービスの概要及び特に重要と考えたサービス品質とその目標及び目標値について

ITサービスの概要

T社システム

特に重要と考えたサービス品質とその目標及び目標値

ユーザーへの問い合わせ対応を実施しているが、回答は3日以内とし問い合わせ全体の95％でこの期間を達成することを目標値としている。

月締めの際の、締めに関連する問い合わせについては、即日対応を基本としている。

サービス品質の目標値を達成するために立案した方策について

問い合わせ回答の目標を達成するための方策

メインの業務システムに関する教育活動を実施して、他の領域のメンバーがサポートできる体制を作ることを方策とした。

管理指標としてスキルマップを作成し、現在値と目標値を記載し、月次で確認を行った。

考慮点としては、スキルの達成度合いを確認しながら、教育活動を見直す必要がないかも検討した。

締めの問い合わせ対応の目標を達成するための方策

締め時の体制の確立を行った。

締めの際に待機するメンバーを定め、定時後も締めが完了するまでは待機することとした。

利用部門とのコミュニケーションルートを確立した。

管理指標としては、締日ごとに発生した対応に関する内容と対応時間記載する一覧表を作成した。

考慮点としては、対応が深夜に及ぶ場合の決着の付け方について柔軟な対応が必要となることである。

嘉永全活動の振り返りと、継続的改善活動について

問い合わせの目標達成に向けた活動について

実施した教育活動の振り返りを実施し、その結果を今後の別メンバーへの教育活動でも活かせるよう計画とともに保管した。

レクチャーが完了したメンバーについても、スキルマップを引き続き運用し、目標達成に向けて継続的に活動を続けることとした。

締めの問い合わせ対応に関する目標達成に向けた活動

締めの対応は概ね問題なく実施されていたが、対応がその場限りとなってしまう問題があった。

継続的改善活動として、対応に関する記録を詳細化し、パターン化できるものについては手順への落とし込みも実施していくこととした。

また、対応内容について内部レビューを行い、目標達成に向けた対応方法の改善も行うこととした。

平成30年度問1、プロセスの自動化について

ITサービスの概要と自動化対象としたプロセスの概要及び自動化の状況について

ITサービスの概要

T社システム

自動化対象としたプロセスの概要及び自動化の状況について

ワークフローシステム変更時のテストの自動化を行った。

ワークフローの本数が多く、毎年、変更時にテスト工数が多くかかっている。

現在のプロセスとしては、テスト対象を絞り込んだ形で決定することができるようになっている。

自動化範囲の拡大にあたっての取り組み内容及び実施計画について

取り組み内容

取り組み内容としては、顧客への提案で自動化の方針を決定した後、計画への落とし込み、実施までを行った。

テストの網羅率は全パターンの50％、削減工数は年間40万円を見込んだ。

実施計画

現在の保守工数をなるべく利用する形を考えた。

10月までに自動化するテストケースの洗い出しを行い、12月までに外部リソースを利用してテストを構築する。

実現したプロセスの自動化及び組織におけるプロセス習熟度の評価について

テスト網羅率の50％を達成、削減費用の40万円も達成できた。

仕様変更の際も、テストの選定し直し、再実施をする必要がなくなり、プロセス習熟度は向上した。

今後の課題として、テスト網羅率をどこまであげるか、その網羅率を達成するために自動化テストを作成する手順の整備がある。

テスト網羅率を不用意に上げすぎると、テスト作成に時間がかかり効率が低下するため、適切なテスト網羅率の見極めが必要となる。

平成30年度問1、運用チームにおける改善の取り組みについて

ITサービスの概要と運用チームの構成、及び運用チームの課題とその根拠について

ITサービスの概要

T社

運用チームの構成及び課題

問い合わせをサービスデスクが受付け、サービスデスクで回答ができないものをシステム保守チームにエスカレーションしている。

システム保守チームのメンバーのうち、一部のメインシステム担当者の業務負荷が高い状態になることがある。

根拠としては、回答期限をオーバーしてしまうことがあるということである。

改善の取り組みと設定した目標、運用チームの力を結集するために工夫した点

改善の取り組みと設定した目標

メンバーの増員、サービスデスクへの業務移管、会計処理の学習会の3点を実施した。

メンバーの増員では、メインシステム担当者の負荷軽減のためにメンバーを一人増員して、教育活動を行った。

目標としてはメインシステムの30％の機能について一人で調査回答ができることとした。

サービスデスクへの業務移管では、件数が多くパターンかできる問い合わせ、リスクの低い運用作業について、サービスデスクで対応できるようにナレッジ、手順の整備を行った。

件数ベースで保守チームの対応の10％の移管を目標とした。

会計処理の勉強会は、保守チームメンバーにレクチャーを行い、基本的な流れと過去に発生した問題点について理解することとした。

運用チームの力を終結するために工夫した点

日次の打ち合わせで、メインシステム担当者の対応状況について他メンバーにも共有し、協力が得られやすくした。

週次で実施しているマネジメント層の打ち合わせでも報告し、改善の状況について他メンバーを含めて状況を理解してもらうこととした。

目標の達成状況、及び取り組みの評価について

メンバー増員については目標を達成した。

適宜目標の達成状況を確認しながら、教育内容を修正することができた。

悪かった点としては、今後の為に、教育の内容を体系だった形で残せなかったことである。

サービスデスクへの業務移管では目標の10％を達成できず5％にとどまった。

良かった点としては、サービスデスクに業務を移管するという意識が定着し継続的な改善活動となったこと。

悪かった点としては、目標の設定を問い合わせ件数に対する割合ではなく、移管できる作業のうち移管できた割合など、もう少し意味を異界しやすいものにすれば良かった。

会計処理の基本的な流れの理解は、都合が悪くレクチャーに参加できないメンバーもいて、全員が理解するという目標は達成できなかった。

良かった点としては、ある程度知識がついたことで、日次報告の中で他メンバーが関連問い合わせの内容をある程度理解できるようになったことである。

令和元年問1、環境変化に応じたプロセスの改善について

ITサービスの概要と既存の変更プロセスに影響を与えた環境変化

ITサービスの概要

T社システム

変更プロセスに影響を与えた環境変化

社内のワークフロー承認権限に見直しが入ることになり、1ヶ月というタイトなスケジュールでシステム変更を行う必要が発生した。

環境変化で影響を受けたプロセスの概要、変更プロセスに生じた問題と改善に向けた施策について

変更プロセスの概要

変更が承認された後は、要件定義、設計、開発、テスト、受入テストの流れで開発が進行する。

変更プロセスに生じた問題点とその理由

対応期間が1ヶ月間しか無いため、既存の変更プロセスでは開発期間が全く足りない状態となってしまった。

改善に向けた施策及び期待効果について

システム変更プロセスを変更して対応することとした。

具体的気には、修正するワークフローごとに五月雨形式で変更プロセスを実施し、それぞれのステータスをエクセル管理することととした。

期待効果としては、仕様が出揃ってから開発を始めるのではなく、仕様が決まった部分から着手することで開発期間を有効に使い、期限に間に合わせることができると考えた。

実施結果と評価

概ねうまくいった。

途中で仕様変更も発生したが、どこまで対応できるかを見極め、各ワークフローのステータス管理により、混乱なく実施することができた。

本来の変更プロセスでは対応できなかったものであるため、俊敏な対応としては成功と言える。

品質確保としてもレビュー工程を十分に確保することができ、問題はなかった。

顧客からも評価いただき、今後同様の案件が発生した場合は今回の方法で対応するよう指示があった。

チーム内の振り返りでは、日次の進捗と問題点の共有を行ったこと、開発スピードを計測して完了予定や対応できる仕様変更を見極められたことが良かったと意見があった。

改善点としては、1つのワークフロー完了までの行程を見直すことでより効率的な作業が可能であると意見があり、こちらは、品質確保の観点も加味した上で見直すこととなった。

令和元年問2、重大なインシデント発生時のコミュニケーションについて

ITサービスの概要と発生した重大なインシデント

ITサービスの概要

T社システム

発生した重大なインシデント

リリース翌日の夜間バッチが異常終了し、データ更新が行われていない状態となった。

利害関係社はT社の全社員である。特に情シス担当者はシステムを統括する立場にある。

重大なインシデントへの対応で実施した手順と利害関係社とのコミュニケーション

重大なインシデントへの対応

サービスデスクリーダーとして、ユーザーとのコミュニケーションである周知業務を担当している。

通常障害発生時は、システム担当者から情シス担当者に障害報告の場が設けられ、その場にサービスデスクも参加する。

周知については情シス担当者から指示がある。

リリース翌日の障害は、障害検知するも、定時前の時間で暫定対応が完了しそうであったため、障害周知は行わない意思決定がなされた。

利害関係社とのコミュニケーション

定時5分前になっても暫定対応が完了せず、このままではサービスデスクに多くの問い合わせが発生する可能性があったため、A社情シス担当者に相談し、急遽障害周知を行うこととなった。

9時45分に障害発生の周知を行った。

周知の正確性と迅速性重視の観点から、周知に必要な事項のヒアリングをA社担当者より行い、本来はA社GMに承認いただくがこの時は、A社担当者に承認をいただき周知を行った。

問い合わせがあったユーザーには、障害内容を説明し、周知実施後は周知内容を確認いただくよう案内した。

コミュニケーションにおける課題と改善策について

周知が遅れたため、多くの問い合わせが発生してしまった。

周知が遅れた原因は2つ考えられる。

一つ目は、周知を出すという意思決定が遅れたことである。

改善策としては、周知の準備に必要な時間を加味して、周知を定時前に出す場合の意思決定タイミングをA社情シス担当者に連携し、周知を出すかどうかを判断いただくことである。

二つ目は、周知の作成に手間取ったことである。

リリース完了周知は準備されており、障害発生時の周知も普段利用しているテンプレートがあった。

今回の場合、リリースが失敗して障害が発生したという周知を作成する必要があり、普段よりも周知文章の作成に時間を要してしまった。

改善策としては、あらかじめリリース失敗時の周知についてもテンプレートを準備しておくことである。

平成29年度問1、ITサービスの提供における顧客満足度の向上を図る活動について

ITサービスの概要と、顧客とのコミュニケーションの仕組み

ITサービスの概要

A社、Cシステム

コミュニケーションの仕組み

コミュニケーションの仕組みとして打ち合わせが2つある。

一つ目は、A社情シス部との隔週の打ち合わせ、二つ目はA社のCシステムチーム担当者とのチームミーティングである。

サービスの報告でレビューしたサービス目標の達成状況及び課題への対策

サービス目標の達成状況

サービス目標として、ユーザー問い合わせ受付から95％の問い合わせについて3日以内に回答する、発生した不具合について業務影響があるものは2週間以内に修正版をリリースするというものがある。

問い合わせの回答の目標について、情シス部との打ち合わせで報告している。

問い合わせ発生件数、消化件数、回答までの平均時間、発生から3日以内に回答した問い合わせが全件に占める割合を報告している。

基本的に毎月達成できているが、ギリギリの月もある。

障害の対応に関する目標については情シス部打ち合わせと、チームミーティング両方で報告している。

不具合の一覧表を使って、新規発生、現在の状況、リリース日を連携している。

解消期間の目標は問題なく達成できている。

課題及び課題への対策について

情シス部打ち合わせの中で、問い合わせが目標期間内に解決できなかった問い合わせについて、件数や状況がわからないと指摘を受けた。

滞留している問い合わせについてはチームミーティングで報告していたが、情シス部打ち合わせでもサマリーを報告することにした。

具体的には、週ごとの滞留問い合わせ件数をグラフ化して件数の推移がわかるようにした。

また、現在滞留している問い合わせがどの部から寄せられたどのような内容の問い合わせかについても、グラフを作成して説明を行った。

顧客の期待と満足の状態及び顧客満足度向上のために策定した活動計画

顧客の期待と満足の状態

情シス部打ち合わせ、チームミーティングにおいて、システム保守の活動はやるべきことを正しく実施できており、問題ないと評価をいただいた。

更なる期待として、チームミーティングの中で2点の依頼があった。

一つ目は、運用作業手順を見直し、省力化してほしいということ、2つ目は、変更案件のリリースまでに時間がかかっているので期間の短縮を検討してほしいとのことであった。

顧客満足度向上のために策定した活動

運用作業の手順見直しについて、リリース当初の厳格なレビュー、承認の手順が引き続き実施されていたが、手順の整備なども進み、運用の実績も多くなったことから一部作業について簡略化することとした。

現在の作業及び作業手順について、修正を行い、チームミーティング内で共有し承認を得た。

システム変更期間の短縮について、内部で検討を行った。

現在は数ヶ月ごとにリリース時期を設定し、含める内容を決定しているため、文言変更などの軽微な修正でも、そのスケジュールに合わせる必要がある。

対応策としては、毎月1回の定期メンテナンスのタイミングを定め、その時点で対応が完了しているものをリリースするという方法を考えた。

この方法を実施するためには、リソース管理の方法の見直しなどの課題がある。

社内でリリースタイミング定期化として活動をスタートし、課題の洗い出しと、タスク化、タスクのスケジュール化を行い、活動についてチームミーティング内で共有を行った。

平成29年度問2、継続的改善によるITサービスの品質向上について

ITサービスの概要及び特に重要と考えたサービスの品質と目標値について

ITサービスの概要

T社

重要と考えたサービス品質とその目標値

問い合わせの回答期間と、軽微な変更案件の対応件数を重要と考えた。

サービスデスクからエスカレーションさらた問い合わせは単純な質問は3日以内、データ変更などの作業を伴うものであれば10日以内に対応するとしている。

軽微な変更案件について3人日いないのものを一月に3件対応することを目標としている。

サービス品質の目標値を達成するために立案した方策と管理指標と方策立案時の考慮点

目標を達成するために立案した方策

案件の対応状況の整理の改善と教育によるリソース活用の効率化を方策として立案した。

一部のシステムの担当者に対応が集中して、作業の優先順位づけや対応方法について非効率的な部分があった。

エクセルで対応内容を一覧化して整理し、現在のステータス、締切りを明確にした上で、朝会の場で優先度を話し合うこととした。

教育については、手が空いているがスキルが足りず、手一杯となっている担当者のヘルプができないということがあったため、スキルトランスファーを行い、ヘルプができる体制を構築することとした。

管理指標と方策立案時の考慮点

対応状況の整理の方策においては、問い合わせ一覧に、受付日と解決日の項目を設け、単純な問い合わせ、データ変更の問い合わせ件数について、週次の対応件数をグラフ化した。

方策立案時の考慮点として、状況一覧のエクセルの記載ルールと報告時の報告内容を統一した。

ルールを決めることで報告する側よりも何を報告するか迷うことがなくなり、報告を受ける側も短時間で理解することができるようになると考えた。

教育活動の管理指標はメンバーごとのスキルマップを作成し、目標値と現状を記載した。

考慮点としては、教える側の担当者がうまく時間を使えるように教育スケジュールを柔軟に変更することとし、また、方策を顧客にも説明し、変更案件の対応を一時ストップしてもらった。

改善活動の評価と継続的改善について

改善活動の評価

問い合わせ対応状況の管理については、効果が高いいと評価できた。

問い合わせに対する週次の件数は、単純な問い合わせ件数はほとんど変化がなかったが、データ変更の対応については20％程度対応期間が短くなった。

教育活動については、スキルレベルは当初予定したところに到達したが、教育側のスケジュールになかなか空きができずに、期間は当初予定の倍かかってしまった。

基本的な知識はついたものの、今後すぐに業務を担当することはできず、課題が残った。

継続的改善活動について

問い合わせ対応状況の管理について、どのような問い合わせがあってどのように回答したかや、データ変更のパターンについて一覧を作成し、エクセルの問い合わせ管理表との紐付けを行うこととした。

また、朝会のやり方や報告内容について週次のチームミーティングで改善を行うこととした。

教育活動については、1回目の教育で、説明する内容についてある程度のカリキュラムができたので教育を受けた側の意見も取り入れて内容を改善した。

次に新メンバーが入ってきた時には、新しい内容で教育を行うこととした。

平成30年度問1、ITサービスマネジメントにおけるプロセスの自動化について

ITサービスの概要と自動化対象としたプロセスの概要及び自動化の状況

ITサービスの概要

T社対応

自動化対象としたプロセスの概要及び自動化の状況について

自動化したのはユーザーからの問い合わせの対応である。

サービスデスクが受付け、サービスデスクで回答できないものは技術チームにエスカレーションしていた。

また、技術チーム内ではリーダーが担当者に対応を割り振っていた。

サービスデスクの対応範囲を拡大し、技術チーム内でも担当者が自分で対応すると判断できるものについては直接対応を開始することとした。

自動化の範囲拡大にあたっての活動における取り組み内容及び実施計画について

FAQツールの利用準備

今回の対応を行うためにFAQツールを利用することとした。

FAQツールにサービスデスクで新しく対応するもの、技術チーム担当者が直接担当する問い合わせについて対応手順と、着手するための判断基準を記載することとした。

FAQツールはサービスデスクがよくある問い合わせや、対応ナレッジの蓄積を行っていたが、技術チームはアクセス権限がなく利用していない。

FAQツールの利用にあたって、技術チームが追加するFAQについてサービスデスク側が混同しないようタイトルなどの記載ルールを定め、顧客にも利用開始の承認を得ることとした。

ツール利用までのタスクを洗い出し、スケジュールを定めた。

KPIはツールを利用開始するまでの期間とし、1ヶ月を目標値とした。

FAQツールへの登録内容整備と利用

FAQツールに新しく登録するものとして３パターンある。

1.サービスデスクに移管する作業、2.技術チーム担当者が直接担当する作業、3.技術チームのノウハウとして利用するものである。

技術チームから2名を選出し、過去の問い合わせからFAQツールに登録する内容をピックアップすることとした。

KPIはパターン1、2のツールへの登録件数とした。

パターン1は10件、パターン2は20件を目標値とした。

プロセスの自動化及び組織におけるプロセス成熟度向上の評価について

ツールの利用準備、登録内容の件数については目標を達成することができた。

サービスデスクがFAQに登録された手順を参照し対応できる問い合わせが拡大し、確実に対応できるようになった。

技術チーム担当者が直接担当するものについても予定通り対応できるようになった。

ただし、一部リーダーは担当者が対応すると思っていたものが実施されないことがあった。

原因としては担当者のルール勘違いとサービスデスクからの依頼の見落としによるものであった。

サービスデスクから依頼後半日以上担当者からのアクションがない場合はリーダーが検知し担当者に連絡することとした。

対応ルールの誤解は日時の朝会で相談の上、FAQツールの記載を修正することとした。

FAQツールの内容は今後も追加を行い、サービスデスク、担当者が直接対応する問い合わせを拡大する方針とし、追加する問い合わせは定例の打ち合わせで相談することとした。

対応開始から半年後、技術チームリーダーが処理していた問い合わせのうち、サービスデスクで新しく対応するようになった問い合わせは10％、担当者が直接対応するようになった問い合わせは20％となった。

平成30年度問1、運用チームにおける改善の取り組みについて

ITサービスの概要と運用チームの構成及び運用チームの課題とその根拠について

ITサービスの概要

T社

運用チームの課題とその根拠について

問い合わせの回答遅延と滞留が課題

問い合わせへの回答は受付から3日以内に回答するとしているが、達成できない問い合わせが月に5件程度発生している。

すぐに解決するのが難しく、後回しになり、顧客と調整はしているものの数ヶ月滞留しているものもある。

改善の取り組みと設定した目標、運用チームの力を結集するために工夫した点

改善の取り組みと設定した目標

一部の領域担当者に業務が集中している。

システム導入後に新しく開始された運用について、手順書が作成されていないものがある。

FAQシステムへナレッジを登録し知識の共有を行うこととした。2ヶ月で30件の登録を目標値とした。

チーム内でのスキルトランスファーを行うこととした。対象メンバーと目標とするスキルレベルを一覧化し、半年後に基幹業務問い合わせの20％を担当者から巻き取ることを目標とした。

チームの力を結集するために工夫した点

ナレッジを追加するたびに朝会で共有し、成果が見えやすいようにした。

問い合わせの発生ベースでFAQを指定し作業を割り振ることで、チームとしての当事者意識を高めることとした。

教育活動は週次の定例打ち合わせで状況の報告を行い、マネジメント層や顧客にも活動を共有することでチームメンバーの意識も高めようとした。

また、定期的に教育活動の振り返りを行い教育を受ける側と教える側が意見を出し合い教育活動をより良く改善してくこととした。

改善の取り組み結果

目標の達成状況

改善取り組みの目標は達成することができた。

FAQの追加は1ヶ月で40件以上を登録することができた。

スキルトランスファーについても予定通り完了し、問い合わせの20％程度を他メンバーが巻き取ることができた。

取り組みの評価

FAQの登録はサービスデスクと登録ルールを定めたおいておかげで混乱なく実施することができ、サービスデスク側にもメリットがあった。

チームメンバーが成果を共有することでモチベーションが高い状態を維持できた。

FAQの登録がひと段落したが、今後も追加した方が良いものについては声をかけて継続的な活動として定着させていくことが必要である。

スキルトランスファーについては、他メンバーが基本的な知識を習得できたことは良かった。

悪かったこととしては、基幹業務担当者が教育活動で負荷が上がってしまったこと、また、問い合わせの20％を巻き取ったものの、基幹業務担当者の負荷がそれほど下がっていないことがある。

対応に時間がかかっている難易度の高い問い合わせをどのように分散させていくかが課題として残っている。