ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問１　顧客満足を向上させるための活動について

　ＩＴサービスを提供する組織にとって、顧客満足は重要な関心事である。
　顧客満足を向上させるには、顧客の期待と評価を把握して対応することが求められる。ＩＴサービスマネージャは、事業関係管理における顧客とのコミュニケーション活動やサービスレベル管理におけるＩＴサービス報告などの活動を通じて、顧客の期待と評価を把握する。
　顧客とのコミュニケーション活動では、顧客の事業環境の変化に対する理解を深め、ＩＴサービスの価値向上などに対する顧客の期待を把握することが必要となる。また、ＩＴサービス報告では、状況に応じて変化するＩＴサービスに対する顧客の評価を把握する。例えば、ＩＴサービスに十分な価値があるとみなされなくなった場合、サービスレベル目標を達成したという報告を行っても顧客は不満足と感じることがある。
　次に、把握した顧客の期待と評価の内容を分析し、顧客満足向上のための改善計画を策定する。例えば、
・顧客の事業環境の変化を背景としたＩＴサービスの価値向上などに対する期待については、組織のサービスカタログを調査し、新サービスを迅速に提案できないかなど組織内の考えをまとめ、顧客に提案できる改善計画として取りまとめる。
・顧客に提供しているＩＴサービスに対する評価については、満足度を数値で評価してもらい、評価の理由も確認する。顧客の期待と現状とのギャップを分析し、顧客満足向上のための改善計画を取りまとめる。
　また、改善計画を顧客と討議し、合意することも重要である。改善計画にはＫＰＩを設定し、計画の達成状況を把握することも必要となる。

　あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。

設問ア

あなたが携わったＩＴサービスの概要と、顧客の期待と評価を把握するためにどのような活動を行っているかについて、４００字以上８００字以内で述べよ。

設問イ

設問アで述べた活動から把握した顧客の期待と評価の内容をどのように分析したか。また、顧客満足向上のためにどのような改善計画を策定したか、設定したＫＰＩを含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた改善計画の実施状況と評価、及び顧客の期待と評価を把握するための活動の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスの概要と顧客の期待・評価の把握

１．１．ＩＴサービスの概要

　私が担当するＩＴサービスは、大手小売業Ａ社向けのＰＯＳシステムの運用保守である。全国展開するＡ社のＰＯＳレジ、店舗サーバー、ネットワーク等の安定稼働維持を目的し、２４時間３６５日のサービスデスク、インシデント・問題・変更・リリース管理のサービスを提供している。私はＩＴサービスマネージャとして、サービス提供責任を負い、特にサービスレベル管理、顧客コミュニケーション、継続的改善を担当する。本サービスはＡ社の基幹業務である販売活動を支え、その安定性と信頼性は事業継続に極めて重要である。

１．２．顧客の期待と評価を把握するための活動

　Ａ社の期待と評価を把握し、満足度向上に繋げるため、主に以下の活動を実施している。
１）定例報告会
　情報システム部および店舗運営部の責任者・担当者と、月次定例会を開催する。ＳＬＯ達成状況、インシデント・問題状況、変更・リリース結果等を報告する。質疑応答や意見交換で、顧客の現状評価、課題認識、短期的な改善要望等を直接把握する。ＳＬＯ達成度に加え、店舗業務への影響や現場の問題点に関する意見聴取を重視する。これにより、目標達成度と顧客実感のギャップ把握に努める。
２）顧客満足度調査
　半期に一度、情報システム部・店舗運営部の担当者を対象にウェブアンケート調査を実施する。サービスデスク品質、障害復旧時間、提案、コミュニケーション等について５段階評価と自由記述で回答を得る。結果を集計・分析し、評価傾向や重点課題を特定する。分析結果は定例会でフィードバックし、評価背景等の対話材料とする。これにより、定量的・定性的両面から網羅的に評価と期待の把握に努める。
　これらの情報を総合的に分析し、期待と評価のギャップを特定、サービス改善に繋げている。

（７９６文字）

設問イ

２．顧客の期待・評価の分析と顧客満足向上のための改善計画

２．１．顧客の期待と評価の分析

　定例報告会や顧客満足度調査から、以下の期待と評価を把握した。
１）顧客の期待
　最たるものは「繁忙期のＰＯＳ障害ダウンタイム短縮」であった。これは売上機会損失に直結し、経営層も重視していた。他に「新機能への迅速な対応」も期待されていた。
２）顧客の評価
　一次解決率は評価されたが、「専門的な問い合わせへの回答時間」に不満があった。障害復旧時間はＳＬＯ達成も、現場は「体感的に遅い」と感じ、特に繁忙期の迅速対応を求めており、期待とのギャップが大きかった。
　これらの結果を受けて、下記の分析を行った。
１）ギャップ分析
　最も深刻なギャップは「期待されるダウンタイム短縮」「ＳＬＯ達成だが現場は不満」と判断した。事業インパクトが大きく顧客満足度低下に繋がるため、最優先課題とした。「専門的な問い合わせへの回答遅延」もサービス品質に関わる重要課題とした。
２）原因分析
　ダウンタイム長期化の原因は「リモート切り分け時間」「現地移動時間」「部品調達時間」がボトルネックであった。「なぜなぜ分析」により、「リモート診断では原因特定に至らないハードウェア障害」「広域な店舗網による移動時間の長さ」「特定部品の在庫不足」が影響していることが判明した。回答遅延の原因は「サービスデスクの二次対応スキル不足」「専門チームの負荷増大による応答遅延」であり、特に新機能関連の問い合わせ対応に時間を要していた。

　以上の分析結果から、対策の優先順位は「繁忙期のダウンタイム短縮」「専門的な問い合わせ回答時間短縮」の順とし、この優先順位は定例会でＡ社と合意した。

２．２．改善計画とＫＰＩ
　前述の結果に基づき、ボトルネック解消のための以下の対策を計画し、Ａ社と合意した。
１）繁忙期のダウンタイム短縮（目的：「リモート切り分け」「部品調達」の時間短縮）
・リモート診断ツールの高度化
　サービスデスクでの一次切り分け精度と速度を向上させるため、ＰＯＳ等の内部パラメータ参照やエラーログ詳細分析、簡易復旧機能を持つツールを導入した。これにより、リモート解決率向上と、現地派遣時の的確な情報連携を目指した。切り分け精度、特にハード/ソフト切り分けの向上を期待した。
・主要保守拠点への予備部品配備強化
　部品調達時間短縮のため、過去実績から故障頻度の高い部品や調達に時間を要する部品を特定し、主要保守拠点への在庫を増強した。これにより部品配送リードタイム短縮を図った。在庫管理プロセスも整備した。
・ＫＰＩ：繁忙期におけるＰＯＳシステム障害の平均復旧時間（現行比１５％削減：内部ＳＬＯ）
２）専門的な問い合わせ回答時間短縮（目的：「サービスデスクの二次対応スキル向上」「専門チーム応答時間短縮」）
・ナレッジベースの拡充とＦＡＱ整備
　担当者の自己解決率向上のため、二次エスカレーション事例等を体系化し、キーワードや症状から検索できるナレッジベースを構築した。特に、新機能や頻発問い合わせの情報を充実させた。店舗向けにＦＡＱも公開し、問い合わせ削減を図った。継続的に更新するプロセスも定めた。
・専門チームとの連携プロセス見直し
　エスカレーション後の回答時間短縮と専門チーム負荷軽減のため、情報連携フォームで必要情報を構造化し、専門チームの状況把握時間を短縮し、回答状況の可視化も実現した。
・ＫＰＩ：二次エスカレーション時の平均回答完了時間（現行比２５％削減：内部ＳＬＯ）

　これらの改善計画は、特定された課題の根本原因に直接アプローチし、測定可能なＫＰＩを設定することで、効果的かつ効率的な顧客満足度向上を目指すものである。

（１５８９文字）

設問ウ

３．改善計画の実施状況・評価と活動の改善点

３．１．改善計画の実施状況と評価

　策定した改善計画について、実施状況と評価は以下の通りである。

１）実施状況
・繁忙期のダウンタイム短縮計画
　リモート診断ツールの高度化により一次切り分け時間が平均約１５％短縮、リモート解決率も５％向上した。予備部品配備強化により部品到着待ち遅延は平均約４５分短縮した。
・専門的な問い合わせ回答時間短縮計画
　ナレッジ拡充とＦＡＱ整備により、サービスデスクのナレッジ参照は増加し、自己解決率は８％向上した。情報連携フォーム活用で、専門チームへの情報連携不備はほぼなくなり、状況把握も容易になった。
２）評価
・ＫＰＩ達成状況
　「繁忙期平均障害復旧時間」は実績１３％削減で未達だった。一部店舗のネットワーク不安定さによる部品配送遅延が要因である。しかし前年比では改善し、店舗運営部からは「以前より早く復旧するケースが増えた」との評価を得た。
　「二次エスカレーション平均回答完了時間」は目標２５％削減を達成した。ナレッジ活用と連携改善の相乗効果と考える。顧客からの回答遅延指摘は大幅に減少した。
・顧客満足度への影響
　満足度調査の総合満足度は５段階評価で３．５から３．９へ向上した。特に「障害対応迅速性」「サポート品質」の評価が改善した。Ａ社からのフィードバックも肯定的であり、実施した施策が顧客満足度向上に寄与したと評価する。
・今後の課題
　ＫＰＩ未達部分の改善として、店舗ネットワーク改善提案や予兆検知の導入を検討する。

３．２．顧客の期待と評価を把握するための活動の改善点

　現在の、期待と評価を把握する活動については、以下の課題があると認識し、改善策を検討している。

１）現状の活動の課題
・定例報告会
　報告中心で議論が不足し、現場の意見が反映されにくい。
・顧客満足度調査
　設問が定型化し新たなニーズを捉えにくい。回収率にばらつきがあり、自由記述分析も不十分。
・潜在的な期待・不満の把握不足
　公式な活動だけでは潜在ニーズや日々の細かな不満を見過ごしやすい。
２）活動の改善策
・定例報告会の運営改善
　報告時間を短縮し、事前設定テーマに基づく議論時間を確保する。四半期毎に現場担当者にも参加を依頼し、現場視点を取り込む。
・顧客満足度調査の見直し
　設問に事業戦略やトレンドに関する項目を追加し、自由記述を重視、分析も強化する。調査目的やフィードバック計画を明確化し、回収率向上策も講じる。
・コミュニケーションチャネル多様化と情報集約
　気軽に意見交換できるポータルやチャット導入を提案する。日常的な顧客の声をＣＲＭ等で組織的に集約・分析し、サービス改善に繋げる仕組みを構築し、潜在ニーズ把握に努める。

（１１９９文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　クラウドサービスを活用したＩＴサービスのサービスマネジメント活動について

　組織が提供するＩＴサービスの一部に、クラウドサービスプロバイダ（以下、ＣＳＰという）が提供するクラウドサービスを活用したＩＴサービスが増加している。クラウドサービスを活用したＩＴサービスのサービスマネジメント活動は、ＩＴサービスマネージャの重要な業務である。
　クラウドサービスの活用に当たっては、組織が提供するＩＴサービスの目標に照らして、ＣＳＰが提供するサービスカタログのサービス内容や、提案依頼に対してＣＳＰが提示するサービス内容を、関係部署とも連携を図り、十分に検証することが重要である。
　クラウドサービスでは、使用されるリソースのモニタリングやリソースのコントロールをＣＳＰが実施するので、オンプレミスで提供するサービスとは異なり、例えば、次のようなサービスマネジメントにおける問題に直面する。
・クラウドサービスの障害対応はＣＳＰが行うので、ＣＳＰの作業の進捗状況が把握できず、利用者へのサービス回復時刻の見通しなどの連絡がタイムリーに行えない。
・顧客からのクラウドサービスに関連する改善要求及び苦情対応はＣＳＰと調整することになるので、顧客へのフィードバック及び対応に時間を要する。
　ＩＴサービスマネージャは、このような問題の解決に向けて、組織の管理プロセスを見直すＣＳＰと十分対応を協議するなどして、対応策を決定する必要がある。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったＩＴサービスの概要と、活用するクラウドサービスの概要を組織が提供するＩＴサービスの目標に照らして、４００字以上８００字以内で述べよ。

設問イ

設問アで述べたクラウドサービスの活用において直面したサービスマネジメントにおける問題、解決に向けて実施した対応策、及び対応策を決定する上で工夫した点について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで実施した対応策の評価、及び改善に向けて今後取り組むべきと考えていることについて、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスとクラウドサービスの概要

１．１．ＩＴサービス概要

　私がＩＴサービスマネージャとして運用管理を担当したのは、中堅アパレル企業の主力販路であるＥＣサイトプラットフォームである。Ｗｅｂでの商品展示・販売を主機能とし、頻繁なセールによるアクセスが集中する傾向があった。私の役割は、安定稼働維持とサービスレベル管理・向上であった。
　本サービスのサービスレベル目標（ＳＬＯ）は、「月間稼働率９９．９％以上」「主要ページの平均応答時間３秒以内」「障害発生時の平均復旧時間（ＭＴＴＲ）４時間以内」を定めていた。同社は経営目標で、年間売上高１２０％向上と新規会員登録数１１０％向上（いずれも昨年度比で）を掲げており、本サービスには機会損失の最小化が強く求められていた。ＳＬＯはこれを達成するため指標だった。

１．２．クラウドサービスの概要

　本ＩＴサービスの基盤には、大手ＣＳＰが提供するＩａａＳモデルのパブリッククラウドを採用した。具体的には、仮想サーバ、マネージドデータベースサービス、オブジェクトストレージ、負荷分散のためのロードバランサ、コンテンツ配信を高速化するＣＤＮ等を組み合わせて利用し、インフラ層の運用管理をＣＳＰに委ねる構成とした。アプリケーション層は自社で管理した。
　ＩａａＳを選択した最大の理由は、セール時のアクセス集中に迅速に対応できる、スケーラビリティ確保にあった。これは、オンプレミス環境では困難なリソース調整を可能とし、機会損失防止に直接繋がるためである。加えて、初期投資の大幅な抑制と、ハードウェア管理等の運用負荷軽減の点も、限られたリソース制約の中でＳＬＯ（特に稼働率とＭＴＴＲ）を達成し、運用コストを最適化する上で有効であると考えた。これらの理由から、ＩａａＳの活用が、ＩＴサービスの目標達成の最も貢献する最適な選択肢だった。

（８００文字）

設問イ

２．クラウド活用における問題と対応策

２．１．クラウド活用において直面した問題

　クラウドサービスを活用する中で、従来のオンプレミス環境とは異なる、以下の問題に直面した。
１）障害発生時の原因切り分けの遅延
　ＥＣサイトで障害が発生した際、クラウド基盤のブラックボックス化により、その根本原因が自社管理領域にあるのか、ＣＳＰ管理下のインフラにあるのかを迅速に特定することが困難だった。自社での調査には限界があり、ＣＳＰ側の要因特定に時間を要した結果、ＳＬＯとして定めたＭＴＴＲの目標値を超過するリスクが高まった。利用者への説明も曖昧にならざるを得ず、サービス信頼性に関わる深刻な問題だった。
２）ＣＳＰ側の情報提供の不足とタイムラグ
　ＣＳＰ起因の障害発生時、ＣＳＰから影響範囲や復旧見込み等の情報が提供されるまでに、タイムラグがあった。ＣＳＰ公式のステータスページ更新も遅れがちで、我々が問題を先に検知することもあった。この情報入手の遅れが、我々の状況把握と適切な初期対応の開始を妨げ、結果として利用者からの問い合わせ増大や混乱を招いた。迅速な情報共有は、利用者との信頼関係維持のためにも極めて重要だった。

２．２．解決に向けて実施した対応策

　上記の問題を解決するため、以下の対応策を実施した。
１）監視体制の強化と多層化
　原因切り分け遅延に対応するため、従来の監視に加え、ＣＳＰが提供する詳細なパフォーマンスメトリクス監視を追加契約し、さらにサードパーティ製のＡＰＭツールを導入した。この多層的な監視体制により、アプリケーションからインフラまでを横断的に分析し、原因箇所の特定を迅速化を図った。特にＡＰＭツールを活用することで、従来は特定が困難だったボトルネックを可視化し、データに基づいたインシデント対応と性能改善を目指した。
２）ＣＳＰとの連携強化
　情報提供不足に対応するため、ＣＳＰ担当のＴＡＭとの月次定例技術協議会を設置し、稼働状況レビューや課題協議を開催することにした。また、障害発生時の緊急連絡体制（連絡手段、エスカレーションプロセスなど）を文書化し、双方で合意した。さらに、ＣＳＰ起因障害時の情報提供の迅速化について、ＳＬＡへの明記を目指して交渉を行った（結果は努力目標での合意）。この施策を通じて、有事の際の円滑な連携と情報入手のタイムラグ短縮を狙った。

２．３．対応策決定における工夫した点

　上記の対応策を実行する上で、以下の２点について特に工夫した。
１）費用対効果を考慮したツール選定
　ＡＰＭツール導入にあたっては、限られた予算内で最大の効果を得ることを重視した。単に高機能なものを導入するだけでは、宝の持ち腐れになるためである。機能、コスト、サポート等を多角的に比較評価した。特に我々のチームが「使いこなせるか」という視点を重視した。候補を２製品に絞ってＰｏＣを実施し、ニーズに合致しコストパフォーマンスが最も高いツールを選定した。この段階的な評価・検証プロセスにより、投資対効果の最大化と導入後の形骸化リスク低減を図った。
２）ＣＳＰとの粘り強い交渉と関係構築
　情報連携迅速化などのＳＬＡ交渉では、ＣＳＰは当初消極的だった。そこで、単に技術的要求をするだけでなく、本ＥＣサイトが顧客ビジネスに与えるインパクト（売上規模、機会損失額試算等）を具体的なデータで示し、戦略的重要性を訴求した。また、ＴＡＭとの定例会等を通じて、技術的な議論に留まらず良好な人間関係の構築にも努めた。ビジネスへの影響を理解してもらい、パートナーとしての協力関係の重要性を強調したことが、最終的に努力目標での合意形成に繋がったと考える。

（１５５７文字）

設問ウ

３．対応策の評価と今後の改善点

３．１．実施した対応策の評価

１）有効だった点（定量的・定性的な成果）
　特にＡＰＭツール導入により、ボトルネックの迅速な特定が可能になった。結果、原因切り分け時間が短縮し、根本原因特定に要する時間は平均３０％短縮できた。また、ＡＰＭツールは性能課題の改善活動にも役立った。
　ＴＡＭとの月次定例会は、障害時連携の円滑化に加え、ＣＳＰ側の情報（メンテナンス計画、他社事例等）を入手する機会となり、潜在リスクへの事前対応が可能になった。ＣＳＰ起因障害時の情報入手までの時間も、平均１時間短縮された。
　これらの複合効果により、利用者への報告が改善し、問い合わせ件数は月平均２０％減少した。また、ＳＬＯで定めたＭＴＴＲ目標の達成率は、対策前の７５％から９０％へ向上した。原因切り分け・情報入手迅速化が貢献した。
２）不十分だった点・新たな課題
・ＡＰＭツールは多機能な反面、チームメンバーの活用度が十分ではなく、継続的なスキル向上が必要である。
・ＣＳＰとの情報連携は改善したが、依然としてＣＳＰ側のプロセスに依存し、契約上の強いコミットメントがない限り、大規模障害時などの情報提供遅延リスクは残る。
・現在の監視・対応プロセスは、障害予兆検知などのプロアクティブな対応能力が不足している。根本的な安定性向上が必要である。

３．２．改善に向けて今後取り組むべきこと
　評価を踏まえ、以下の活動によって更なる向上を目指す。
１）監視と分析能力の向上
　まずＡＰＭ活用度向上に向け、スキル向上施策で分析スキルを底上げし、導入効果を最大化する。次に各種ログを一元管理・相関分析できるログ基盤導入を検討。これにより原因究明迅速化と潜在的問題発見を可能とする。将来はＡＩによる予兆検知導入も視野に入れ、インシデント未然防止とプロアクティブ運用を目指す。
２）ＣＳＰとの戦略的パートナーシップ強化
　技術課題／ビジネス戦略／ロードマップを共有し、中長期視点でＩＴ基盤戦略や新技術活用を協議する、経営層参加の戦略レビュー会（四半期毎）の開催をＣＳＰに提案する。これにより互恵的な戦略的パートナー関係構築を目指す。また、次期契約更新時、情報連携等に関する実効性あるＳＬＡ（ペナルティを含む）締結を粘り強く交渉する。
３）自動化による運用効率化と信頼性向上
　インシデント対応での定型作業（一次切り分け、通知、自動復旧等）は自動化を推進し、オペレータの負荷とヒューマンエラーを低減する。また、ＩａＣの考えに基づき、構成管理ツールの適用範囲を拡大する。これにより、構成管理の強化、再現性・テスト容易性の向上を図り、人的ミスによる構成不備リスクを低減する。これにより、運用効率化／コスト削減／サービス全体の信頼性向上を目指す。

（１１９１文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

具体的な問題はIPAにてご確認ください。

問題文

問１　環境の変化に対応するための変更管理プロセスの改善について

　ＩＴサービスマネージャは、変更管理プロセスを定め、変更によるサービスへの影響を評価する。近年、サービス改善のための変更要求の増加、ＤｅｖＯｐｓの採用などによって、展開を行う回数が増加するなどの環境の変化が起きている。
　従来の変更管理プロセスは、ウォーターフォール型開発を前提として内部統制の強化に重点を置いたものも多く、高頻度、短期間で変更要求を承認できる規程となっていない場合がある。ＩＴサービスマネージャは、このような環境の変化に合わせて必要な統制を確保しつつ、変更要求の承認を遅延させないために、変更管理プロセスを改善していく必要がある。例えば、次のような改善策を行う。・変更要求の対象範囲を見直し、変更のカテゴリ“標準変更”の適用を拡大する。
・ＣＡＢ（変更諮問委員会）の運営方法を見直す。
・ＤｅｖＯｐｓによる展開に合わせて、変更のカテゴリを新たに定義し、適用範囲や変更のプロセスを定める。
　また、変更管理プロセスの改善策実施後に、変更要求の承認が適切に実施されているか、サービスに影響を与えていないかなど、採用した改善策の効果を評価し、変更管理プロセスの更なる改善を進めていくことも重要である。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったＩＴサービスの概要と、既存の変更管理プロセスに影響を与えた環境の変化の内容について、８００字以内で述べよ。

設問イ

設問アで述べた環境の変化によって、変更管理プロセスに生じた問題点、及び問題点を解決するために実施した変更管理プロセスの改善策について、８００字以上１６００字以内で具体的に述べよ。

設問ウ

設問イで述べた変更管理プロセスの改善策の評価と課題について、６００字以上１２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスの概要と環境変化

　私が担当したＩＴサービスは、クラウドベースの統合業務システムの運用管理である。当該システムは、大手製造業の基幹システムとして、会計、販売、在庫、生産管理などの業務機能を提供する。利用部門は国内外２０拠点、利用者数は約５，０００名規模であり、２４時間３６５日のサービス提供が求められる重要システムであった。

環境変化として、以下の３点が既存の変更管理プロセスに大きな影響を与えた。

１）変更頻度の増加

・パブリッククラウドの採用により、インフラ環境の変更が年間数回から月次へと増加
・ＳａａＳ／ＰａａＳベンダによる更新への対応が必須となり、変更件数が年間２００件超に増加
・マイクロサービスアーキテクチャの採用により、個別機能単位での変更が可能となり、変更の粒度が細分化

２）アジャイル開発手法導入

・従来の半期に１回のリリースから、２週間単位のスプリントでの継続的なリリースに移行
・ＤｅｖＯｐｓの導入による開発・運用の統合と、ＣＩ／ＣＤパイプラインの整備
・自動テスト・自動デプロイの導入によるリリース作業の自動化推進

３）ビジネス要件の変化への対応スピード強化

・ＤＸ推進による新規サービス開発の増加
・競合他社のサービス展開に対する迅速な対応要求
・コロナ禍におけるリモートワーク対応など、急速な業務形態の変化への対応必要性

　これらの環境変化により、従来のウォーターフォール型を前提とした変更管理プロセスでは、変更要求への迅速な対応が困難となった。特に、従来の承認プロセスでは、変更の影響範囲やリスク評価に時間を要し、ビジネスの要求する展開スピードに追従できない状態であった。

　上記の状況を踏まえ、内部統制を維持しつつ、変更管理プロセスの効率化と迅速化が最優先課題となった。

（７９６文字）

設問イ

２．変更管理プロセスの問題点と改善策

２．１．変更管理プロセスの問題点

　以下の問題が顕在化した。

１）変更承認プロセスの硬直化

・軽微な変更でも複数の承認者による承認が必要であった。過去に発生した重大障害の対策として、リスクの大小に関わらず画一的な承認プロセスとしたためである。
・ＣＡＢメンバーが多忙のため、ＣＡＢの開催が月１回の定例のみとなっている。そのため、緊急性の高い変更要求への即応ができず、「承認待ちで事業機会を逃した」という経営層からの指摘もあった。

２）ＤｅｖＯｐｓとの不整合

・開発チームが実装した変更が、承認待ちにより展開できない状況が頻発している。「毎日コードをプッシュしているのに、本番反映は月１回」という開発者の不満が蓄積し、モチベーション低下につながった。
・自動テストによる品質確認結果が承認プロセスに反映されない。これは、品質保証部門が自動テスト結果を信頼できないと考え、従来通りの手動テストと承認を要求しているためである。

３）クラウドサービス特有の変更への対応不備

・従来の変更管理プロセスは、クラウドベンダによる変更を想定していなかった。

２．２．変更管理プロセスの改善策

　以下の改善策を実施した。

１）変更カテゴリの再定義と承認フローの最適化

・変更の影響度とリスクに基づく４段階のカテゴリ分類を導入した。例えば、過去３回以上成功実績のある定型的な変更は「標準変更」として事前承認とし、単一のマイクロサービスへの変更は「軽微変更」として担当マネージャーの承認のみで実施可能とした。成功実績のある変更は、他の変更に比べて重大障害が発生確率が低いと考えた。

・標準変更の適用範囲を拡大し、定型的な変更の９５％をカバーした。例えば、セキュリティパッチの適用など、手順が確立された作業を標準変更に分類した。

２）ＣＡＢ運営の効率化

・従来、月１回の対面式で開催していた会議を、週１回のオンライン形式に変更した。これは地理的制約を排除することより、ＣＡＢメンバー全員が迅速に参加可能となり、承認プロセスの即時性を向上させた。また、会議室確保が不要になり、会議室確保のための日程再調整、と言ったムダな工数の削減も期待できた。

・軽微変更に関しては、ワークフローシステムによる承認を可能とした。迅速な変更実施に寄与できると考えた。

３）ＤｅｖＯｐｓ対応の変更プロセス確立

・ＣＩ／ＣＤパイプラインと変更管理システムを統合し、自動テスト合格⇒変更承認済になるようにした。具体的には、「開発者がコードをソースコード管理ツールにプッシュ⇒ＣＩツールがテストを自動実行⇒テストが成功した⇒変更の自動承認」となるようにした。これはＣＡＢメンバーの負荷軽減の狙いもあった。

・開発者がコードレビューを完了すると、システムが自動的に変更要求を生成するようにした。変更要求の作成工数削減による、変更管理の効率化を狙った。

・ 開発環境での変更（例：テストサーバーへのデプロイ）については、最小限の承認手続きとした。具体的には、開発環境では開発リーダーの承認のみで変更できるようにした。開発環境での変更は本番環境に比べてリスクが低く、承認プロセス簡素化により、開発効率の向上が期待できた。

４）クラウドサービス特有の変更管理方式の確立

・クラウドベンダによる更新に伴う影響を評価するための、基準を策定した。例えば、クラウドベンダのＡＰＩ変更時、自社システムへの影響度を評価し、影響度に応じた対応策を決定するようにした。
事前対策によって、クラウドベンダによる更新に起因する障害を防止でき、サービスの安定稼働に寄与すると考えた。

（１５９０文字）

設問ウ

３．改善策の評価と課題

３．１．改善策の評価

１）変更要求の処理時間

　標準変更の承認待ち時間が劇的に改善された。具体的には、従来は申請から承認まで平均２日かかっていた作業が、事前承認により即時対応可能となった。例えば、セキュリティパッチの適用が「今すぐ必要」という要望に対して、その場で対応できるようになった。
　重要変更についても、ＣＡＢのオンライン化により承認待ち時間が１４日から５日に短縮。「月末の決算処理に間に合わない」という苦情が激減した。

２）変更成功率

　全体の変更成功率が９２％から９８％に向上した。これは、標準変更の手順書整備と自動化により、人的ミスが大幅に減少したためである。特に深刻な事例として発生していた「本番環境での設定ミス」が、自動化によりゼロとなった。

３）作業効率

　ＣＡＢメンバーの審議工数が激減した。具体的には、毎月の資料作成と会議で４０時間を費やしていた工数が、オンライン化とドキュメント自動生成により１５時間まで削減された。
　変更管理担当者の精神的負担も大幅に軽減し、「会議のためだけに出勤せずに済むようになった」と、感謝の声をもらった。

さらに、「作業負担が減り、集中して開発に取り組める」「以前よりも確実にスケジュール通りに変更が実施されるようになったため、業務への影響が減った」といった声が届いた。

３．２．今後の課題と対応方針

１）リスク評価の精度向上

　例えば、「標準変更として承認済なので大丈夫」という声が様々な場所で聞こえ始め、伴うリスク評価の質の低下が懸念された。
下記の対策によってリスク評価の精度向上を図る。
・過去の変更履歴を機械学習で分析し、リスクの予兆を自動検知する仕組みを構築し、「この時間帯の変更は失敗率が高い」といった傾向を検知し、警告を出す。
・四半期ごとに変更管理委員会を開催し、リスク基準の見直しを行う。具体的には、インシデント分析結果を基に、標準変更の判断基準を継続的に改定する。

２）変更の相互依存性管理

　例えば、「ＡＰＩの変更とＤＢの変更が重なって障害が発生した」という事例が報告されるなど、複数チームでの同時変更時の情報共有が不十分であった。
下記対策で、チームメンバーでの情報共有を強化する。
・変更カレンダーをダッシュボード化し、全チームがリアルタイムで変更状況を把握できるようにする。
・依存関係のある変更を自動検知し、関係者に通知する仕組みを実装する。例えば、同じデータベースに対する変更が計画されている場合、関係者全員にビジネスチャットツールで自動通知を行う。

今後は、これらの課題に対して、より実効性の高い対策を実施していくつもりである。

（１１７３文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　サービス運用におけるヒューマンエラーに起因する障害の管理について

　ＩＴサービスの障害は企業活動に大きな影響を及ぼす。サービス運用の現場で発生する障害は、運用担当者のヒューマンエラーに起因するものが多い。ヒューマンエラーに起因する障害を防ぐことは、ＩＴサービスマネージャの重要な業務である。
　ヒューマンエラーの原因には、不注意、知識不足、思い込み、慣れ、過労などがあるが、ヒューマンエラーの背景として、教育などのスキル管理、作業ルールなどのプロセス、コミュニケーションなどの組織風土に課題があることも多い。
　ＩＴサービスマネージャは、ヒューマンエラーに起因する障害が発生した場合に、次のような技法を用いて、原因を分析して対策を行うことが大切である。
・パレート分析を用いて、重要な原因を見つけ出す。
・なぜなぜ分析を用いて、対策をとるべき根本原因を見つけ出す。
　対策に当たっては、直接原因だけでなく、プロセスや職場環境など、直接原因を引き起こしている根本原因の分析も行い、障害の再発を防止する観点から検討を行うことが重要である。
　また、発生したヒューマンエラーを個々に分析して対策を行うだけでなく、これまでに組織で発生したヒューマンエラーの傾向を分析して組織としての課題を抽出し、対策を行うことも大切である。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

　あなたが携わったＩＴサービスの概要と、運用担当者のヒューマンエラーに起因した障害、及びヒューマンエラーの内容について、８００字以内で述べよ。

設問イ

　設問アで述べたヒューマンエラーに起因した障害の再発を防止するために実施した対策は何か。また、対策を検討するに当たって、根本原因をどのように分析したか。８００字以上１６００字以内で具体的に述べよ。

設問ウ

　これまでに組織で発生したヒューマンエラーの傾向をどのように分析したか。また、組織としての課題は何であったか。６００字以上１２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスの概要とヒューマンエラーに起因した障害

１．１．ＩＴサービスの概要

　私が担当していたのは、全国５００店舗以上を展開する小売チェーン向けの在庫管理システムの運用管理である。このシステムは、店舗在庫のリアルタイム更新、補充依頼の自動化、および中央倉庫との連携機能を備え、店舗運営を支える重要な基盤である。特に、商品の欠品防止や店舗間での在庫調整を可能にすることで、店舗オペレーションの効率化に大きく寄与している。サービスの特性上、システムの可用性やデータの正確性が極めて重要であり、障害発生時には即座に運営に影響を及ぼす。
　
１．２．障害の内容と原因

　ある深夜帯の定期データ更新作業中に、運用担当者が誤ったＳＱＬコマンドを実行し、大量の在庫データが削除される障害が発生した。この障害の影響は以下の通りである。

１）商品発注や補充作業が停止し、翌日の営業開始までに６時間の遅延が発生。
２）複数店舗での商品欠品が発生。主要商品が不足し、約２００万円の売上損失が推定された。
３）一部店舗からのクレーム対応が追いつかず、本部への問い合わせ件数が通常の３倍以上となった。

　障害原因を分析した結果、以下の３点に集約された。

１）人的エラー
　運用担当者が誤ったＳＱＬコマンドを実行した。特に、操作時の確認手順が不十分であった。
２）業務フローの手動依存
　システム操作が一部手動で行われており、自動化されていなかったことがヒューマンエラーを誘発した。
３）確認体制の形骸化
　ダブルチェックが形式的に運用されており、実効性が低かった。特に、深夜帯の作業では疲労の影響も重なり、確認精度が著しく低下していた。

（７３４文字）

設問イ

２．根本原因分析と再発防止策

２．１．根本原因分析

　障害の再発防止を目的として、なぜなぜ分析を実施し、問題の根本原因を特定した。
具体的には、下記のように原因を掘り下げていった。

１）人的エラーの分析
・深堀１：誤ったＳＱＬコマンドを実行　⇒　ＳＱＬ実行前の確認が不十分
・深堀２：ＳＱＬ実行前の確認が不十分　⇒　確認基準が曖昧
・深堀３：確認基準が曖昧　⇒　手順書が不十分
・深堀４：手順書が不十分　⇒　文書化の優先度が低かった

２）手動依存の業務フロー
・深堀１：作業が自動化されていない　⇒　手動作業が中心
・深堀２：手動作業が中心　⇒　手順が属人的で標準化できていない
・深堀３：標準化できていない　⇒　業務の歴史的な経緯により、手作業が主流であった

　なぜなぜ分析においては、犯人捜しにならないよう、特に配慮した。
犯人捜しをしてしまうと、作業ミスをした当事者を攻撃することにつながるため、当事者が委縮してしまい、再発防止策の重要なヒントを得られなくなってしまうと考えた。

２．２．再発防止策の実施

　前述の根本原因を解決するため、以下のような再発防止策を実施した。

１）作業の完全自動化

　人的操作を排除することで、ヒューマンエラーを根本的に防止することにした。具体的には、データ更新作業をスクリプト化し、構成管理ツールを活用して完全に自動化した。また、更新処理前にバックアップを自動取得する機能を追加した。スクリプトの変更についても、テスト環境での自動検証を必須とし、検証を通過した場合のみ本番適用が可能な仕組みを構築した。
更新作業を標準化することで属人性を排除し、作業ミスの軽減が期待できた。

２）チェックツールの導入

　ＳＱＬ実行時の誤操作を未然に防ぐため、ビジネスルールに違反するＳＱＬ（例：ＤＥＬＥＴＥ文におけるＷＨＥＲＥ句不足）を検知する機能を導入した。さらに、データ更新後の整合性を確認する自動検証ツールも実装した。
ビジネスルール違反やデータ整合性を検知可能にすることで、作業精度向上・障害発生率低減に寄与できると考えた。

３）ログ取得とリアルタイム監視の強化

　操作ログをリアルタイムで取得し、異常が発生した場合には即座に通知する仕組みをビジネスチャットツールを活用して整備した。また、ダッシュボードを作成し、視覚的に状況を把握できるようにした。
障害発生時の原因特定と対応を迅速化による、運用の透明性向上・障害対応時間の短縮が狙いだった。

４）運用スキル向上プログラム

　運用担当者が新しい仕組みに迅速に適応できるよう、業務品質の均一化と、担当者間のスキルギャップを解消するようにした。
具体的には、運用担当者に対し、模擬環境を用いた訓練を実施した。これにより、新しい業務手順を実践的に習得させた。また、オンライン学習教材を提供し、知識の定着を図った。

（１２５２文字）

設問ウ

３．組織全体で発生したヒューマンエラーの傾向と課題

３．１．ヒューマンエラー傾向の分析

１）ログ分析による根本原因の特定

　組織全体で発生したヒューマンエラーについて、過去３年間に記録された作業ログを分析した。具体的には、エラーが発生した時間帯、担当者の作業負荷状況、使用された手順書のバージョンなどを分析した。
その結果、エラーの多くが、以下の条件下で発生していることが分かった。
①時間帯：深夜や早朝など、担当者が疲労しやすいシフト中
②担当者：新任者や経験年数が２年未満の者が関与する作業
③手順書：更新が遅れている手順書や不十分な説明の記載がある手順書が使用されている場合

２）傾向分析の結果

　前述の分析により、組織として以下の傾向があった。
①作業環境
　過重労働や深夜作業が原因で、疲労による注意力散漫がエラーを誘発している。
②スキルギャップ
　新任者や経験不足の担当者が十分な教育を受けず、正確な作業が困難になっている。
③手順書の老朽化
　手順書が現行のシステム仕様や業務要件に適合していない場合があり、作業ミスが発生している。

３．２．組織としての課題

　分析結果を基に、組織全体の課題を以下の通り特定した。

１）作業環境の改善

　疲労が蓄積するシフト体制が続いており、ヒューマンエラーの温床となっていた。特に、深夜作業の頻度が高い担当者でエラーが多発していた。
そこで、深夜作業の頻度を減らすためのシフト見直し、在宅勤務による柔軟な働き方の導入、定期的な休憩時間の設定を徹底する。

２）教育プログラムの強化

　新任者への教育プログラムが不十分であり、ＯＪＴのみに依存していた。これにより、作業スキルの習得に個人差が生じており、担当者のスキル不足に起因した作業ミスが多発していた。
そこで、新任者向けの定期研修と、シミュレーションを取り入れた模擬訓練の実施。経験年数に応じたスキル向上プログラムを導入する。

３）手順書管理プロセスの再構築

　手順書の更新頻度が低く、システム仕様や業務フローの変更が反映されていないことがあった。例えば、古い手順書を参照した結果、誤操作や重要なプロセスを見落とすといった事故が発生していた。
対策として、手順書の定期的なレビューを実施し、更新プロセスを標準化する。また、最新手順書を容易に参照できるデジタルプラットフォームを構築することで、正確な作業手順を共有可能にする。

４）ログ分析の定常化

　操作ログは取得しているが、定期的なレビューが行われておらず、エラー発生の予兆を察知できる状況ではなかった。
対策として、ＡＩツールを活用した、エラー発生の予兆を検出する仕組みを導入し、操作ログの分析を定期業務に組み込む。

（１１９５文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問１　サービスレベル管理におけるサービスレベルの合意について

　サービスレベルの維持を目的として行うサービスレベル管理において、顧客ニーズを満たすために必要なサービスレベルを定義、文書化及び合意することは、ＩＴサービスマネージャの重要な業務である。ＳＬＡは、サービスの条件及びサービスレベル目標を記述する文書であり、顧客の視点でサービスレベル目標を定義することが望まれることから、サービス提供組織（以下、組織という）と顧客とのサービスレベルの合意に向けた取組が重要となる。
　顧客のサービス要求事項は、事業環境の変化、社会環境の変化及び情報技術の進展などによって多様化・複雑化・高度化している。例えば、ＱＲコード決済サービスへの高い耐障害性、個人情報を扱うサービスへの高いセキュリティ性などがある。
　また、組織においては、ＡＩ、自動化技術などの新技術活用による品質向上・効率向上が期待される一方、設備面・体制面費用面などの制約が考えられる。組織と顧客とのサービスレベルの合意に向けた取組に当たっては、サービス提供に関わる内部供給者及び外部供給者（以下、サプライヤという）のサービスレベル目標又は契約との整合性が必要となり、サプライヤとの協議・調整も欠かせない。
　サービス開始後、サービスレベル目標を満たせない事態の発生又は兆候を認識した場合には、必要に応じてサービスの条件及びサービスレベル目標を再定義する。また、ＳＬＡの見直しに関わるサービスレベル管理の仕組みを確立することも重要である。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

　あなたが携わったＩＴサービスの概要と、サービスレベルの合意に向けて、顧客との交渉で討議の対象となったサービスレベル項目、及び討議を要することとなった背景について、８００字以内で述べよ。

設問イ

　設問アで述べたサービスレベル項目について、サービスレベルの合意に向けた取組、及びＳＬＡの見直しに関わるサービスレベル管理の仕組みについて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

　設問イで述べたサービスレベルの合意に向けた取組を、どのように評価しているか。また、サービスレベル管理における今後の課題は何か。６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．サービス概要と討議の背景

１．１．サービス概要と討議の中心となったサービスレベル項目

　私が担当したのは、中堅企業向けのクラウド型ＣＲＭ（顧客関係管理）システムの導入および運用管理である。このシステムは、営業プロセスの可視化、顧客情報の一元管理、データ分析による意思決定支援を目的としており、顧客企業の営業活動に不可欠な基盤である。

本システムのサービスレベル合意において、以下の項目が討議の中心となった。
・システム可用性
　稼働率９９．９５％以上の達成が顧客から求められた。特に営業繁忙期には無停止運用が重視された。
・応答速度
　データ検索や画面操作の応答時間を２秒以内とする要件が提示された。
・障害対応時間
　重大障害発生時には、１５分以内の初動対応および１時間以内の部分復旧を保証することが求められた。

１．２．討議を要する背景

　これらの要求の背景には、顧客企業の業種特性と市場競争力への影響があった。顧客企業の収益は、営業活動の即時性と精度に依存しており、特に繁忙期におけるシステム停止は、１時間あたり数百万円の損失に直結するとの試算が示された。そのため、可用性要件については妥協の余地がないとの立場が顧客から示された。

　一方で、当時のサービス運用体制には課題があった。特に障害対応においては、初動対応までに平均３０分以上を要しており、顧客要求との乖離が顕著であった。このギャップを埋めるための取り組みが不可欠であり、これが討議の焦点となった。

（６５９文字）

設問イ

２．サービスレベル合意と見直しの仕組み

２．１．サービスレベル合意に向けた取り組み

　顧客要求に応えるため、以下の取り組みを実施した。

１）顧客ニーズの分析と優先順位の明確化
　顧客とのヒアリングを通じ、システム可用性が最も重要視されることを確認した。営業繁忙期を考慮し、クリティカルな時間帯（午前９時～午後６時）に重点を置いたサービス提供設計を提案した。さらに、レスポンス速度および障害対応時間についても業務への影響度を詳細に分析し、優先順位を設定した。

２）技術的な改善

・可用性の向上
　データセンターの冗長構成を再設計し、地理的に分散したバックアップを導入することにした。さらに、負荷分散技術（ロードバランサ）を活用することで、目標稼働率の目指すようにした。
・応答速度の最適化
　２秒以内のレスポンスタイムを実現するため、データベースのクエリチューニング、インメモリキャッシュ技術の導入、さらに頻繁に使用されるデータのインデックス作成を行った。応答速度の分析の結果、スポンスタイム向上のボトルネックが、データアクセス部分であると確認されたからである。
・障害対応プロセスの強化
　現在の障害対応プロセスでは、障害検知を運用管理部門が行い、初動対応をする担当エンジニアに電話連絡をするようになっていた。そこで、障害通知を即時に担当エンジニアに行うアラートシステムを導入し、初動対応時間を平均１５分以内に短縮することを目指した。さらに、障害復旧プロセスを事前にシミュレーションする訓練を定期的に実施し、１時間以内の復旧が可能かを検証可能にした。

３）合意形成のプロセス

　技術的改善の試験運用を実施し、実測データを顧客に提示した。特に、繁忙期のシミュレーション結果を共有することで、顧客の信頼を獲得し、最終的なＳＬＡ合意を形成した。

２．２．ＳＬＡ見直しの仕組み

　サービス開始後の運用改善のため、以下の仕組みを構築した。
　
１）モニタリングと報告体制

　リアルタイム監視ツールを活用し、稼働率や応答速度を継続的にチェックできるようにした。また、定例会議で顧客にパフォーマンスデータ（例：時間帯別の平均応答時間のグラフ）を提示することで透明性を確保するようにした。

２）見直しプロセス

　事業環境や新技術導入による変更要求が発生した際には、迅速に顧客と協議を行い、ＳＬＡの柔軟な更新を可能とした。例えば、新規サービスの追加に伴う可用性の再評価を実施することにした。

（１０８２文字）

設問ウ

３．取組の評価と課題

３．１．取組の評価

　今回のサービスレベル合意に向けた取組は、以下の成果を生んだ。

１）システム可用性の向上
　稼働率９９．９５％を安定して達成したことで、顧客の業務継続性が向上した。特に営業繁忙期での無停止が継続中であり、顧客から高い信頼を得ることができた。

２）応答速度の最適化
　クエリ最適化やキャッシュ技術の導入により、システム応答時間が顧客の目標である２秒以内を安定して維持することに成功した。この結果、営業担当者の業務効率が向上した

３）障害対応時間の短縮
　障害通知システムの導入により、初動対応時間を平均１５分以内に短縮し、部分復旧も１時間以内に達成した。これにより、障害発生時の影響範囲が最小化され、顧客ビジネスへの影響が軽減された。

　顧客からは、「システムがビジネスの競争力向上に直結している」との高い評価を得た。特に、提供したパフォーマンスデータに基づく透明性のある運用が、顧客との信頼関係の強化に繋がったと考える。

３．２．今後の課題

　本取組で多くの成果を挙げた一方で、下記のような課題が明らかとなった。

１）新技術への対応
　ＩＴ業界はＡＩ、ＩｏＴ、クラウドネイティブ技術の進展に伴い、システム要件がさらに高度化・複雑化することが予想される。例えば、ＡＩを活用したデータ分析機能の追加要求などが考えられる。これに対応するためには、プロアクティブなリスク評価と事前準備や技術革新に対応できる人材育成が重要と考える。特に、人材育成についてはその継続性が重要と考える。技術は常に進歩し続けるからである。

２）プロアクティブな顧客対応の強化
　顧客のビジネス環境の変化に迅速に対応するため、定期的なヒアリングや市場動向のモニタリングを強化する必要がある。これにより、顧客の潜在ニーズや将来的な要求を先取りし、競争優位性を提供できる提案型のサービス提供を目指す。例えば、業界トレンドや法規制変更に基づく要件の見直し提案を行うことで、顧客との関係をより強固なものにすることが可能である。

３）コストパフォーマンスの向上
　高いサービスレベルを維持するには、一定のコストが必要となるが、顧客の予算制約に対応することも重要である。効率的な運用体制の整備や新技術の活用によるコスト削減施策を進めることで、コストとサービス品質のバランスを最適化する必要がある。

　本取組の成功と課題解決を通じて、顧客ビジネスのさらなる成長を支援するＩＴサービスマネジメントを実現したい。

（１０９３文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　リリース及び展開の計画について

　ＩＴサービスマネージャは、変更管理プロセスと連携しながら、リリース及び展開管理プロセスの活動を行う。
　リリースを安全に展開するため、リリース及び展開の計画（以下、展開計画という）を策定する。展開計画の策定に先立って、リスクを特定し、次のような検討を行う。
・リリースがサービスに与えるリスクを分析、評価し、リスクを最小限にとどめるための回避策又は軽減策を検討する。
・リリースがサービスに影響を与えないことを、展開前に本番環境に近い環境で試験し、試験では確認できないリスクを明確にした上で、その回避策又は軽減策を検討する。
・インシデント発生リスクを軽減させるため、展開後の稼働状態の監視方法を検討する。
　特定したリスクと検討した結果に基づき、リスクを回避又は軽減させるための方策をまとめ、リリースを安全に展開するための展開計画を策定する。例えば、
・展開時に発生する想定外の事態に備えて、影響の小さい機能や対象範囲から段階的に展開を行う。
・ＤｅｖＯｐｓの採用などによって、頻繁に展開を行う場合には、展開作業の自動化を行って作業時間の短縮や展開作業におけるミスの混入を防止する。
　また、展開実施後は、リスクを回避又は軽減するために採用した方策及び展開計画の有効性をレビューし、今後の展開に備えることが重要である。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

　あなたが携わったＩＴサービスの概要と、リリースの内容、及び特定したリスクについて、８００字以内で述べよ。

設問イ

　設問アで述べたリスクを回避又は軽減するために採用した方策、及び展開計画について、根拠と期待した効果を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

　展開実施後のレビュー結果を踏まえ、採用した方策及び展開計画の評価と課題について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービス概要とリリースにおけるリスク

１．１．ＩＴサービスの概要とリリース内容

　私が携わったＩＴサービスは、大手小売業向けの顧客管理システム（ＣＲＭ）の運用管理である。
　このシステムは全国約１２０店舗で使用され、日々５００万件以上のトランザクションを処理する。サービスの主要な機能は、リアルタイムの顧客データ管理と、それを基にした販売促進策の支援である。

　今回のリリースでは、ＡＩを活用したパーソナライズドなレコメンデーション機能を追加した。これにより、各顧客に最適な商品を提案できる。これに伴い、以下の変更を実施した。
・データベーススキーマの拡張
・新たなＡＩモデルの導入
・リアルタイム分析基盤の強化

１．２．特定したリスク

　リリースの計画に際し、関係者へのヒアリングと過去のリリースにおける事故の記録から、以下のリスクを特定した。

１）既存機能への影響
　データベーススキーマの変更により、既存クエリとの互換性問題が発生する可能性があった。特に、クエリエラーが本番環境で発生するリスクを１０％と見積もった。
２）システムダウンのリスク
　このシステムは２４時間３６５日稼働しており、１時間のダウンタイムで最大１００万円の売上損失が見込まれる。計画外の停止がブランドイメージに及ぼす影響も懸念された。
３）パフォーマンス低下
　ＡＩモデルによる処理負荷の増加で、ピーク時の処理速度が最大３０％低下するリスクを認識した。
４）運用部門の混乱
　新機能導入に伴う運用手順の複雑化により、サポート対応が遅延するリスクがあった。

　以上のリスクの中でも、特に重要視したのは「システムダウン」である。これが発生すると、即時の売上損失だけでなく、顧客体験の毀損に繋がると考え、最優先で対応すべきと判断した。

（７９０文字）

設問イ

２．リスク対策と展開計画

２．１．リスク回避・軽減のための方策と期待効果

１）段階的展開
　全国展開を一括で行わず、まず３店舗でパイロット展開を実施。発見された問題を修正後、１０店舗→全店舗へと順次展開した。
段階的に展開することで、問題の発生を局所化することがき、ビジネスへの影響を小さくできるからである。
一括展開した場合と段階的展開を行った場合の障害発生件数を、過去の類似プロジェクトのデータを基に試算したところ、今回の展開計画では初期障害の８０％の削減効果が期待できた。
２）ブルーグリーンデプロイメント
　本番環境と同一構成のグリーン環境を用意し、動作確認後にロードバランサを用いて本番環境（ブルー環境）を切り替える方式を採用した。これにより、トラブル時には即座に元の環境に戻すことが可能になる。
　この展開方法での復旧時間をテストした結果、３０分程度での復旧できることが確認できた。過去のインシデント記録から算出した、従来のバックアップからの復旧時間は、４時間以上であることから、復旧時間が８０％以上短縮可能であるため、売上損失を大幅に軽減できる効果が期待できた。

３）負荷試験の強化
　実際のトランザクションデータを基に、ピーク時の負荷を再現した負荷試験を実施した。
具体的には、リソースの割り当て方法やＡＩモデルの調整（アーキテクチャなど）ごとの負荷試験の結果により、リソース割り当てとＡＩモデルの最適化によって、ＡＩモデルの推定速度が２０％以上向上し、パフォーマンス低下を１０％以内に抑制できることが確認できた。

４）運用部門支援
　新機能導入に伴う手順を詳細にマニュアル化し、事前に運用部門へトレーニングを提供した。
これには、リリース直後の問い合わせ件数の抑制により、サポートメンバーの負荷を軽減する狙いがあった。

２．２．展開計画

１）スケジュールと進捗管理
・準備期間（３ヶ月）
　１ヶ月目にリスク評価とテスト計画策定、２ヶ月目にパイロット展開、３ヶ月目に段階的展開するようにした。
これは、技術的なリスクに対応する時間を確保するだけでなく、運用体制を整備する時間を確保する狙いがあった。
・全国展開
　店舗単位で進捗を管理し、ダッシュボードを用いて障害状況をリアルタイムで可視化するようにした。具体的には、パイロット展開店舗数／障害発生件数／問い合わせ件数などをグラフやチャートで表示し、視覚的に状況を把握しやすくした。

（１０５８文字）

設問ウ

３．評価と今後の課題

３．１．方策と計画の評価

　リリース計画の実行により、下記のような成果となった。これは方策がうまく機能したと判断できる。

・段階的展開により、障害発生率を計画比で２０％削減し、初期展開のパイロット店舗での障害発生率を２％に抑制することができた。これにより、全国展開前に、検出された課題を修正する時間を確保することができた。

・ブルーグリーンデプロイにより、ダウンタイムを当初、平均３０分と試算していたが、、結果的に平均２０分に短縮することができた。店舗ごとの切り替え作業を進めるにつれて、メンバーの習熟度が上がってきた結果と分析する。

・負荷試験の結果実施したＡＩモデル最適化により、ピーク時の処理速度低下を当初想定の３０％から１０％に改善することができた。これにより、稼働率９９．９５％を達成し、トランザクション遅延による影響を最小化することができた。

・手順をマニュアル化したことにより、リリース直後の問い合わせ件数が、過去に同程度のリリースした際の問い合わせ件数と比較し、３０％削減することができた。

３．２．課題

・パイロット展開終了後のレビューと修正作業が想定以上に時間を要し、全国展開が計画より２週間遅延した。これは、問題箇所の特定プロセスが属人的で、レビュータスクの標準化が不十分であったことに原因であった。
・運用部門の負荷増大
・新機能導入に伴う問い合わせや不具合報告が一部集中し、運用部門の通常業務が滞る場面があった。これは、リリース直後の対応要員が不足しており、問い合わせがピーク時に集中したためである。

３．３．改善策

・レビュー標準化
　レビューにおける問題特定とっ対応策の記録をテンプレート化し、各プロセスでのレビュー項目を事前に定義することにした。
これにより、問題発見と修正作業の効率化により、次回以降のスケジュール遅延を回避できると考える。
・運用体制の強化
　当面の間は、リリース直後に専任サポート要員を配置することで、要員の負荷分散を図る。
また、増員ができない場合の対策として、並行してチャットボットやＦＡＱを整備する。

３．４．総合評価

　本リリース計画と実施は、大部分で期待通りの成果を上げ、顧客満足度の向上に寄与した。一方、スケジュール管理や運用体制に改善の余地がある。次回以降、これらの課題を解消することで、より円滑なリリース運用を実現する。

（１０５３文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　ＩＴサービスの運用品質を改善する取組について

　ＩＴサービスの運用チームは、サービスの運用を通じて、信頼性の高いＩＴサービスを安定的に提供する。サービスレベルの向上を図り、顧客の期待に応えるために、ＩＴサービスマネージャには、ＩＴサービスの運用品質の改善目標を定めて、運用品質の改善に取り組むことが求められる。
　ＩＴサービスの運用品質の改善目標には、例えば、作業ミス件数の２０％削減やサービスデスクにおける受付から回答までの時間の３０分短縮といった具体的な目標値を設定し、達成期限も設ける。
　次に、改善目標を達成するための方策を立案して実施する。次のような観点から方策の内容を設定する。なお、複数の方策を立案して実施することもある。
・プロセス：手順の見直し、標準化の推進など
・ツール：ツールを使った自動化など
・人：運用チームのメンバのスキル向上、役割と責任の明確化など
　そして、方策の管理指標を定め、定期的に方策の実施状況を確認する。
　方策の実施に当たっては、運用チームのメンバによる議論を促して取組への動機付けを行うなど、運用チームの力を結集するための工夫を行うことも大切である。
　改善の取組においては、方策の管理指標の達成状況及び改善目標の目標値の達成状況を評価する。未達の場合は原因を分析し、必要に応じて、方策などを見直す。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったＩＴサービスの概要と、運用チームの構成、及びＩＴサービスの運用品質の改善目標とその設定根拠について、８００字以内で述べよ。

設問イ

設問アで述べた改善目標を達成するための方策について、方策の内容及び管理指標を、運用チームの実態を踏まえて工夫した点を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた方策の管理指標の達成状況、改善目標の目標値の達成状況及び改善の取組全体の評価について、良かった点、悪かった点、今後の改善点を含めて、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスの概要と運用品質の改善目標

１．１．ＩＴサービス概要

　私が携わったＩＴサービスは、金融業界向けの大規模なＩＴインフラ（主に銀行のオンラインサービスのバックエンドシステム）の運用管理である。このサービスは、２４時間３６５日の運用監視、障害対応、定期メンテナンスを含み、システムの稼働率を９９．９％以上に保つことが求められている。

１．２．運用チーム構成

　運用チームは、以下の役割で構成されている。

１）運用リーダー（私）
　チーム全体の進捗管理と品質保証を担当。
２）システム管理者
　サーバーやネットワーク機器の監視・メンテナンスを担当。
３）サービスデスク担当者
　顧客からの問い合わせ対応や障害受付を行う。
４）トラブルシューティング担当者
　障害の分析と復旧を専門的に担当。

１．３．運用品質の改善目標

　過去１年間のの障害対応データに基づき、運用品質の改善目標を以下に設定した。

１）障害対応時間の短縮：障害受付から復旧までの時間を１時間以内とする。
２）障害発生件数の削減：障害を事前に予測し、発生件数を２０％削減する。

　過去１年間のデータでは、障害発生時の対応時間が最長で２時間を超えるケースがあり、顧客からの不満が寄せられていることが分かった。また、障害発生率が高く、特にシステムの一部で繰り返し同様の障害が発生していた。
このことから、顧客満足度向上と運用効率化を目的に、対応時間を業界標準の１時間以内に短縮する目標を設定した。
また、同じ障害が繰り返し発生することを防ぐために、再発防止策として障害発生件数の削減を目指すことにした。

（７２５文字）

設問イ

２．改善目標達成のための方策と管理指標

２．１．改善目標達成のための方策

　改善目標を達成するために、以下の方策を実施した。

１）プロセス改善

　運用チーム内のスキル差に起因する障害対応の遅延防止策として、下記の対策を実施した。
・障害対応フローの簡素化
　例えば、障害発生時の初動対応に関して、手順を簡略化して重要なアクションを優先的に実施するようにした。具体的には、「障害の初期確認」→「影響範囲の特定」→「エスカレーションの判断」というシンプルな手順に整理した。また、情報共有のための「障害発生報告テンプレート」を導入し、誰が見ても一目で状況がわかるようにした。
・再発防止策の標準化
　障害対応後に「なぜなぜ分析会議」を開催し、根本原因分析をと再発防止策を全員で議論するようにした。この会議では、各メンバ自身の視点で意見を出し合い、その結果を「再発防止マニュアル」に反映して標準化した。例えば、過去の重大障害が「運用手順の不備」に起因していた場合に、新しい手順を設け、その手順を定期的にレビューするようにした。

２）ツール活用

　運用チームは通常業務を兼務しているため、業務負荷が高かった、そこで、下記の対策による業務効率化を図った。

・障害対応の自動化
　ログ解析ツールを導入し、定型的なログチェック作業を自動化した。具体的には、エラーログの自動収集と解析を行い、異常を検出するリアルタイムでアラート発行するようにした。これにより、手動でログを確認する手間が省け、障害対応のスピードが向上した。また、エスカレーションプロセスの一部もツールで自動化し、定型的なエスカレーションを素早く行えるようにした。
・ダッシュボードによる可視化
　サービスの監視ツールを活用し、リアルタイムで障害状況確認できるダッシュボードを作成した。これにより、監視メンバーが一目でサービスの稼働状況を把握でき、障害兆候の早期検知を可能とした。具体的には、サービスの各種指標（稼働率、レスポンス時間、リソース使用率など）を可視化し、異常が発生した際に即座に通知が来るように設定した。

３）人材育成

　運用品質の改善には、スキル差や業務負荷の対策だけでなく、メンバ自身のスキルアップや連携強化が必要と考え、下記の人材育成策を実行した。

・チームメンバーのスキル向上
　定期的に障害対応訓練を実施した。例えば、過去に発生した重大な障害をシナリオとして再現し、メンバーが実際に対応する場面をシミュレーションした。この訓練により、実際の障害発生時に冷静に対応できるスキルを養った。また、問題解決に必要な「ツールの使い方」や「障害対応マニュアル」の理解を深める効果も期待できた。

２．２．管理指標

　方策のモニタリング指標を下記に設定した。

１）障害解決率：９５％以上
　メンバー全員の対応能力向上を測定する指標とした。障害対応フローを簡素化したことで、対応時間の短縮が期待できる。
２）対応手順の順守率：９０％以上
　 障害発生時に新しい手順を遵守した割合を追跡し、フローの改善がどれだけ実行されているかを測定した。本指標の向上は、障害対応時間の短縮や障害の再発防止につながる。
３）ツール活用率：８０％以上
　 ツールの使用頻度を定期的に測定し、ツール活用の効果を評価した。ツールの有効性を高めるため、使いやすさを追求し、現場メンバーからフィードバックを得て改善を加えた。
４）トレーニング完了率：１００％
　トレーニング後の知識向上度を測るため、演習の結果やテスト結果を基にトレーニング完了率を評価した。トレーニング後の対応能力向上を可視化することを重視した。

（１５７６文字）

設問ウ

３．方策の評価と今後の改善点

３．１．方策の実施状況と評価

　前述の管理指標を用いて方策における達成状況を評価した。

１）障害解決率：目標未達
　解決率は９２％で目標には若干届かなかったが、大部分の障害が解決されるようになった。解決までの時間も短縮され、改善活動の効果は十分に見られたが、残りのケースでの改善が必要だった。
２）対応手順の遵守率：目標未達
　新しい手順の遵守率は８７％であり、目標未達であった。運用メンバーの一部で手順の認識に差があり、さらなる訓練や情報共有が必要であることがわかった。
３）トレーニングの完了率：目標達成
　全メンバーが定期的なトレーニングを完了し、実際の障害対応においてもスキル向上が確認された。この結果、メンバーの対応能力が向上し、対応時間の短縮にも寄与した。
４）ツール活用率：目標未達
　ツール活用率は７８％となり、目標値には若干届かなかったが、ツールやダッシュボードの導入が運用メンバーによって着実に受け入れられ、今後の活用頻度のさらなる増加が期待される。

３．２．改善活動の評価

　下記の通り、運用品質の改善目標に対する評価を行った。

１）障害対応時間：目標達成
　障害対応時間は約５０分となり、目標値１時間を達成した。障害解決率は目標に対して未達であったが、方策が概ね有効に機能したと考える。
２）障害発生件数：目標未達
　障害発生件数は前年比１８％削減となり、目標値にはわずかに届かなかった。障害発生件数が削減されたことから、方策の有効性は確認できた。対応手順の順守率やツール活用率を向上させることで、目標を達成できると考える。

３．３．今後の改善点

１）障害解決率の向上
　解決率を９５％以上に引き上げるため、特に複雑な障害への対応を強化する。具体的には、障害解決のためのマニュアルやＦＡＱの整備を進め、事例共有を活発に行うことで、メンバーの対応スピードをさらに向上させる。
２）対応手順の遵守率の向上
　手順の遵守率を９０％以上に引き上げるため、定期的な手順確認とチーム内での共有を強化する。また、手順遵守に関するフィードバックを集め、手順改善に役立てる。
３）ツール活用率の向上
　ツール活用率を８０％以上にするため、メンバーへの定期的なフィードバックとサポートを行い、ツールの利便性を最大限に活用できるようにする。特に新しいツールへの慣れを促進するための追加トレーニングを実施する。

３．４．総括
　改善活動を通じて、運用品質は確実に向上し、顧客満足度も改善された。目標値に達成できなかった一部の指標については、原因を分析し、必要な改善策を講じることで、さらに品質の向上を図る。今後も継続的な改善を進め、運用チームのパフォーマンスを最大化していく。

（１１９８文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問１　事業関係管理におけるコミュニケーションについて

　顧客との関係を良好に保つための事業関係管理は、ＩＴサービスマネージャの重要な業務である。事業関係管理では、顧客の事業及び業務内容を深く理解し、顧客の期待に沿ったサービスの提供に向けて、顧客満足の把握と改善、利害関係者間の調整などのマネジメント活動が必要となる。
　事業関係管理では、目的に応じて、顧客とのコミュニケーションだけでなく、サービスの供給に関与する利害関係者とのコミュニケーションも必要である。
　コミュニケーションの対象とする情報には、例えば、サービスの要求事項、サービスのパフォーマンス傾向、サービス満足度、苦情、障害対応の状況、新規サービス及びサービス変更に関わる要求事項などがある。
　コミュニケーションの仕組みとしては、ミーティングでの報告、電子メールでの相談、グループウェアでの情報共有、ＳＮＳ又は連絡ボードでの連絡などが考えられる。
　情報の重要性、迅速性、緊急性などに配慮して、情報伝達の間隔や方法を定めるなど、サービスや組織の特徴を踏まえた効果的な取決めを行い、確実に実践していくことが重要である。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったＩＴサービスの概要と、事業関係管理の概要及び事業関係管理におけるあなたの役割について、８００字以内で述べよ。

設問イ

設問アで述べた事業関係管理のために特に重要と考えたコミュニケーションについて、その目的、対象とした情報、特に重要と考えた理由、及びコミュニケーションの仕組みについて、工夫した点を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べたコミュニケーションについて、顧客との良好な関係を保つという観点でどのように評価しているか。また、今後の課題と対応についてどのように考えているか。６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスと事業関係管理の概要

１．１．ＩＴサービスの概要

　私が携わったＩＴサービスは、国内製造業向けの統合業務管理システムの運用管理である。本サービスは、顧客のサプライチェーンの効率化や在庫管理の最適化を目的に、基幹システムの２４時間稼働や、月次のバッチ処理やリアルタイムのデータ同期といった、高い可用性が必要だった。

１．２．事業関係管理の概要

　本サービスにおける事業関係管理の目的は、顧客の業務ニーズを的確に把握し、それをＩＴサービスに反映させることで、顧客満足度の向上を図ることであった。具体的には、顧客との多様なコミュニケーション手段を活用し、サービスの品質向上とコスト効率の両立を目指すこと。また、顧客の事業変化に応じた柔軟な対応を実施することで、顧客との信頼関係を強化することであった。

１．３．事業関係管理における私の役割

　私はＩＴサービスマネージャとして、本サービスの管理全般を任されており、事業関係管理においては、主に以下の役割を担った。この活動により、顧客との良好な関係を維持しつつ、サービス品質向上を目指した。
１）顧客ニーズの把握
　定期的なレビュー会議、電子メール、グループウェアなど、多様なコミュニケーション手段を通じて顧客の事業計画や課題を共有し、ＩＴサービスに必要な変更を特定する。
２）利害関係者間の調整
　システム運用部門、開発部門、及び外部ベンダーとの連携を図り、サービス改善プロジェクトを推進する。
３）サービスレベル管理
　ＳＬＡの達成状況を分析し、必要に応じてＫＰＩの見直しや改善策を提案する。
４）コミュニケーションの強化
　顧客と利害関係者との間での円滑な情報共有を促進するため、多様なコミュニケーション手段を効果的に組み合わせて活用する。

（７７７文字）

設問イ

２．事業関係管理における特に重要なコミュニケーション

２．１．コミュニケーション手段の特徴と役割

　事業関係管理において、以下の複数のコミュニケーション手段を状況に応じて使い分けた。
１）定例レビュー会議
・目的：サービスの包括的な状況確認と中長期的な改善計画の策定
・特徴：対面での詳細な議論、顧客との直接的な関係構築に最適
２）電子メール
・目的：迅速な情報伝達、軽微な状況報告や確認
・特徴：即時性が高く、記録として残るため、正式な連絡に適している
３）グループウェア
・目的：継続的な情報共有、関係者間での進捗管理
・特徴：リアルタイムでの情報更新、複数の関係者が同時に情報にアクセス可能
４）チャットツール
・目的：緊急時の迅速なコミュニケーション、簡易な問い合わせ対応
・特徴：即時性が高く、非公式なコミュニケーションに適している

２．２．最も重要と考えたコミュニケーション手段

　これらのコミュニケーション手段の中で、定例レビュー会議を最も重要と位置づけた。過去の失敗経験（顧客との認識不一致による、大幅なコスト増と納期遅延）から、形式的な会議では顧客の真のニーズを捉えられないと考えたためである。

２．３．定例レビュー会議で共有した情報

　顧客との信頼関係強化と、サービス提供者である当社の責任を果たすために、会議で共有すべき情報は以下の３点とした。
１）サービスパフォーマンスの指標
　現在のサービス提供状況を示し、ＳＬＡの遵守状況を確認するための情報である。この指標を共有することで、サービスの信頼性や価値を明確化し、顧客満足度や改善点を具体的に把握できる。
２）過去の問題と対応状況
　過去の障害や苦情に対してどのように対応しているかを、顧客に説明するための情報である。継続的な改善姿勢と問題対応能力を示すことで、顧客との信頼関係を維持し、安心感を提供できる。
３）新規要望
　今後の計画に反映するための、顧客の新たなビジネスニーズや、システム要件に関する情報である。顧客の事業環境の変化に柔軟に対応する姿勢を示し、サービスの関連性と付加価値を強調できる。

２．４．定例レビュー会議において工夫した点

　会議を効率的に進め、顧客との合意形成をスムーズに行うため、以下の工夫を行った。
１）事前準備の徹底
　会議前にアジェンダを共有し、関係者が必要な資料を事前に用意した。例えば、稼働率や障害対応時間のデータは、最新の内容を基にグラフ化し、分析結果を添付するようにした。
２）可視化ツールの活用
　ＫＰＩや進捗状況をグラフ化し、視覚的にわかりやすい資料を作成した。例えば、稼働率の推移を折れ線グラフ、障害件数の内訳をパレート図で示すことで、直感的に理解できるようにした。
３）フォローアップの実施
　会議後に議事録を迅速に共有し、決定事項の進捗を定期的に確認した。議事録には責任者と期限を明記し、タスク管理ツールを用いて進捗を確認できるようにした。
４）インタラクティブな進行
　単なる報告ではなく、ディスカッション形式で顧客と当社が意見交換を行えるよう心がけた。特に、改善提案時には複数の選択肢を提示し、顧客のニーズに即した選択ができるよう配慮した。
５）定量的データの活用
　過去のトレンドやベンチマークデータを基に課題を具体化し、対策の妥当性を説明した。例えば、直近６か月の稼働率を基に、最も影響を与えた障害要因をパレート図を用いて特定し、解決策を提案した。

　特に、事前準備とフォローアップに配慮した。会議の質を高めるためには、事前事後の対応が重要と考えたからである。

（１５５９文字）

設問ウ

３．コミュニケーションの評価と今後の課題

３．１．コミュニケーションの評価

　定期的なレビュー会議は、顧客との良好な関係を保つ上で非常に効果的であった。具体的には、下記のような評価であった。
１）顧客満足度の向上
　定期的な会議を通じて顧客の要望を的確に反映し、顧客満足度スコアが１０％向上した。例えば、顧客から要望のあった月次レポートの自動出力を提案・実装した結果、顧客の業務効率が大幅に改善され、顧客に好評だった。
２）課題解決の迅速化
　会議後のフォローアップにより、障害対応時間が平均２０％短縮された。例えば、会議で議論した特定の障害（システム応答時間の遅延）について、原因分析の優先順位を設定し、専任チームを編成した結果、解決に要する時間を従来の３日間から２日間に短縮できた。
３）信頼関係の構築
　顧客から、来期も本サービスを継続利用する旨の連絡があった。また、新たな事業展開に伴うシステム拡張案件を受注することができた。これらの事実は、信頼関係が強化された結果と考える。

３．２．今後の課題

　良好な関係を維持する一方で、以下の課題が浮き彫りとなり、情報共有の仕組みや調整プロセスに改善の余地があることが分かった。
１）情報共有のタイムラグ
　システムで重大な障害が発生した際、定期会議まで情報が共有されず、顧客が影響範囲を把握するまでに時間がかかる場面があった。このことから、会議の間隔が長い場合、重要な情報の伝達が遅れるリスクがあることが判明した。
２）全員参加の難しさ
　新たなシステム変更提案に関する会議において、担当役員が多忙のため参加できず、承認が翌月に持ち越されたことで、変更実施が遅れたことがあった。

３．対応策

　下記の技術面・組織面のアプローチで課題に対処し、顧客とのさらなる関係強化を図る。
１）技術的アプローチ
・リアルタイム情報共有ダッシュボードの構築
　グループウェアやチャットツールを活用し、必要な情報を迅速に共有できる仕組みを導入する。具体的には、顧客がシステム状態やＫＰＩを即座に確認できるダッシュボードを構築し、情報共有のタイムラグを解消する。
・ＡＩによる議事録自動生成
　重要な会議内容を録画し、後から確認できるようにする。さらに、ＡＩによって議事録を自動生成し、参加者全員が会議内容を短時間で把握可能にする。

２）組織的アプローチ
・コミュニケーションスキル研修の実施
　定期的な社内研修・ｅラーニング・外部コンサルを招いた研修などを活用し、コミュニケーションスキルを向上し、顧客との関係強化に繋げる。
・柔軟な会議参加方式の導入
　リモート会議ツールを活用して場所の制約を無くしたり、会議録画の自動インデックス化によって、時間的制約を無くす。

（１１９０文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　サービス可用性管理の活動について

　　ＩＴサービスマネージャには、顧客とサービス可用性の目標を合意した上で、サービス可用性を損なう事象の監視、課題の抽出、改善策の実施など、サービス可用性の目標を達成するための活動を行うことが求められる。
　サービス可用性の目標及び目標値については、ＩＴサービスの特徴を踏まえて、例えば、サービス稼働率９９．９％などと顧客と合意する。
　サービス可用性の目標を達成するために、次のような活動を行う。
①サービス可用性を損なう事象を監視・測定する。
　故障の発生などサービス可用性を損なう事象を監視して、事象の発生回数と回復時間などを測定する。また、評価指標を定めて測定結果を管理する。
②測定結果を分析して、課題を抽出し、改善策を実施する。
　例えば、インシデントによって、ＭＴＲＳ（平均サービス回復時間）が悪化している場合は、拡張版インシデント・ライフサイクルでの検出、診断、修理、復旧及び回復のどこで時間を要していたかを分析する。復旧段階の時間が長く、手順の不備が原因であった場合は、復旧手順を整備する。
　また、サービス停止には至らないが、平均応答時間が増加している場合は、原因を分析して改善策を実施し、将来のサービス拡大などの環境変化に備える。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったＩＴサービスの概要と、サービス可用性の目標及び目標値、並びにそれらとＩＴサービスの特徴との関係について、８００字以内で述べよ。

設問イ

設問アで述べたサービス可用性の目標を達成するために重要と考えて行った活動について、監視対象とした事象と測定項目は何か。測定結果の評価指標は何か。また、測定結果をどのように分析したか。８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた分析の結果から、サービス可用性の目標を達成するために対応が必要と考えた課題と改善策は何か、又は、将来の環境変化に備えて対応が必要と考えた課題と改善策は何か。いずれか一方の観点から、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスの概要とサービス可用性の目標

１．１．ＩＴサービスの概要

　私が携わったＩＴサービスは、製造業向けの生産管理システムの運用管理である。このシステムは、部品調達から製品出荷までの一連のプロセスを統合的に管理するものであり、２４時間３６５日の稼働が求められる。システム停止が発生した場合、生産ライン全体に影響を及ぼし、出荷遅延や顧客クレームが発生する可能性が高いため、サービスの可用性が特に重要であった。

１．２．サービス可用性の目標及び目標値

　サービス可用性の目標は、サービス稼働率９９．９７％と定めた。これは、年間の許容停止時間を３時間以内とした場合の目標値である。この設定は、生産ライン停止が発生した場合の生産損失やサプライチェーンへの影響を最小限に抑える必要性を考慮したものである。また、平均サービス回復時間（ＭＴＲＳ）を３０分以内にすることを補足目標とした。

１．３．目標とＩＴサービスの特徴との関係

　この目標設定は、以下の特徴を踏まえたものである。
１）製造業の２４時間稼働体制
　生産ラインが停止すると、直接的な生産損失だけでなく、サプライチェーン全体に波及効果が生じるため、短時間の停止でも許容できない。
２）システムの複雑性
　サーバ、ルーター、ファイアウォールなど多種多様な設備と連携して稼働するため、障害発生時には迅速な原因特定と復旧が必要。
３）季節需要の変動
　４月から６月にかけてアクセス負荷が集中するため、この負荷ピーク時でも高い可用性を維持することが重要。

　これらの特徴を考慮し、高可用性と迅速な復旧を重視した目標を設定した。

（７１９文字）

設問イ

２．サービス可用性の目標達成のために行った行動

２．１．監視対象と測定項目

　サービス可用性の目標を達成するため、以下の事象を監視対象とし、それに関連する測定項目を設定した。

１）監視対象事象
・サーバ障害、ネットワーク障害
・データベース応答時間の増加
・アプリケーションのエラー頻度

　上記を監視対象とした理由は、次の通り。
①サーバやネットワークはシステム全体の基盤であり、これらの可用性が維持されなければサービス全体が停止するリスクが高い。
②データベースとアプリケーションは主要な業務処理を支える中核部分であり、これらの正常性を監視することがサービス品質の維持に直結する。

２）測定項目と測定方法
・障害発生回数：障害ログを収集し、月次で集計する。
・平均サービス回復時間（ＭＴＲＳ）：各障害の発生時刻と復旧時刻を記録し、平均値を算出する。
・平均応答時間：モニタリングツールで主要業務処理の応答時間を計測し、日次平均を算出する。
・稼働率（システム全体および主要コンポーネント別）：稼働時間を監視システムで記録し、目標値と比較する。

　測定方法においては、下記のように測定作業にかかる工数を最小化する工夫を行った。
①ログの収集を自動化し、リアルタイムでログ収集と集計を可能とした。
②測定結果をダッシュボード形式で可視化し、異常を即座に発見できるようにした。

２．２．測定結果の評価指標

　測定結果を評価するために、以下の指標を設定した。

１）稼働率
　月次および年間の稼働率を計算し、目標値との乖離を評価する。
２）ＭＴＲＳ
　各障害に対する回復時間を計測し、目標値（３０分以内）との比較を行う。
３）障害発生頻度
　障害件数の増減を分析し、トレンドを可視化する。
４）応答時間
　主要業務処理における平均応答時間を監視し、異常値の発生を検知する。例えば、通常は平均１秒の応答時間が、１０秒以上に増加した場合にアラートを発行する。

２．３．測定結果の分析

　測定データをもとに以下の分析を実施した。

１）パレート分析
　障害発生の８０％以上が、深夜１時～３時にデータベースサーバに集中していることを確認した。
２）根本原因分析
　なぜなぜ分析を用いて、障害原因を深掘りした。この結果、データベースの応答遅延が、在庫確認業務で使用されるクエリ処理に起因していることを特定した。
３）トレンド分析
　ＭＴＲＳが特定の障害タイプ（ネットワークスイッチの故障）で長引く傾向であることを判明し、復旧プロセスが非効率性であることがわかった。
４）相関分析
　統計解析ソフトウェアを用いた相関分析を行い、障害発生頻度と応答時間増加の相関関係を調査した。その結果、負荷増加が原因であることを特定した。

　これらの分析結果を基にした、改善策を立案・実行することにした。

（１２４７文字）

設問ウ

３．サービス可用性の目標達成のための課題と対策

３．１．課題の特定

　前述の分析の結果、以下の課題を特定した。
１）復旧手順の不備解消
　ネットワークスイッチ障害時の復旧手順の中で、エラー発生時の対処方法が明文化されておらず、復旧時間が長引く原因となっていた。
２）負荷ピーク時の性能改善
　季節需要によりアクセスが集中する期間に、応答時間が通常平均１秒のところ５秒以上に増加し、ユーザーエクスペリエンスの悪化に繋がっていた。
３）障害予兆の監視ポイント追加
　ストレージデバイスの障害予兆に対する監視設定が不足しており、予防的な対応ができていなかった。

３．２．改善策

１）復旧手順の整備
　過去のインシデントデータをもとに、復旧手順を標準化し、復旧時間の短縮を図った。特に、エラー発生時の分岐処理を明文化した。また、手順書を月１回定期的にレビューし、最新の環境に対応させた。
２）負荷分散対策の強化
　アプリケーションの負荷分散設定を最適化し、ピーク時のリソース利用を効率化した。具体的には、ロードバランサーの設定を見直し、処理負荷の均等化を図った。さらに、季節需要を予測するための負荷シミュレーションを導入し、想定される最大負荷条件下でのシステム動作を検証した。
３）監視設定の見直し
　ハードウェア障害予兆を検知するために、新たにストレージＩ／Ｏ速度や電源装置の温度を監視項目として追加し、障害発生前の対応を可能とした。

３．３．結果と展望

　これらの改善策により、ＭＴＲＳが平均２０分に短縮し、応答時間もピーク時において通常比２０％改善された。さらに、予防的対応の実施件数が増加し、稼働率が９９．９７％まで向上した。

　今後は、さらに高い可用性目標（例：９９．９９％）を実現するため、以下の施策を計画している。
１）自動復旧機能の導入
　機械学習を活用した障害予測モデルの導入により、障害発生前に予防措置を自動的に適用し、復旧時間をゼロに近づける。
２）冗長化の強化
　ネットワークおよびデータベースサーバの冗長構成を強化し、単一障害点を完全に排除する。
３）サービスレベルのモニタリング
　リアルタイムダッシュボードを利用して、主要なサービスレベル指標を継続的に監視し、異常を即座に検知・対応する仕組みを構築する。

　これらの施策を段階的に実行し、さらなるサービス品質の向上と顧客満足度の向上を目指す。

（１０５０文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問１　環境変化に応じた変更プロセスの改善について

　ＩＴサービスマネジメントを実践する組織では、品質の確保に留意しつつ、緊急変更を含む変更管理プロセス並びにリリース及び展開管理プロセス（以下、変更プロセスという）を既に構築・管理している。
　しかしながら、俊敏な対応を求める昨今の環境変化の影響によって、既存の変更プロセスでは、例えば、次のような問題点が生じることがある。
①アジャイル開発で作成されたリリースパッケージの稼働環境へのデプロイメントにおいて、変更プロセスの実施に時間が掛かる。
②新規のサービスをサービスデスクで作業可能とする変更要求の決定に時間が掛かる。
　ＩＴサービスマネージャには、このような問題点に対し、変更プロセスの改善に向けて、例えば、次のような施策を検討することが求められる。
①アジャイル開発チームへの権限の委譲、プロセスの簡略化などによるデプロイメントの迅速化
②サービスデスクでの標準変更の拡大を迅速に行うためのプロセス見直しと利害関係者との合意
　改善に向けた施策の決定に当たっては、変更要求への俊敏な対応と品質の確保の両面に配慮する必要があり、俊敏な対応を重視するあまり、品質の確保が犠牲にならないように工夫することが重要である。
　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったＩＴサービスの概要と、既存の変更プロセスに影響を与えた環境変化の内容について、８００字以内で述べよ。

設問イ

設問アで述べた環境変化によって影響を受けた変更プロセスの概要、変更プロセスに生じた問題点とその理由、改善に向けた施策及び施策の期待効果について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた施策の実施結果と評価について、俊敏な対応と品質の確保の観点を含め、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．ＩＴサービスの概要と環境変化

１．１．ＩＴサービスの概要

　私が携わったＩＴサービスは、小売業向けの統合ＥＣプラットフォームの運用と保守である。このプラットフォームは、商品管理、在庫管理、顧客管理、販売データの分析など多岐にわたる機能を提供しており、複数の外部システムと連携している。これにより、顧客はオンラインとオフラインのシームレスな購買体験を享受することが可能となる。このプラットフォームは、顧客企業の競争優位性を高めるため、定期的に新機能のリリースや改善を求められる状況にあった。

１．２．環境変化の内容

　昨今の急速なデジタルシフトと顧客ニーズの多様化に伴い、次のような環境変化が生じた。

１）アジャイル開発の導入
　顧客企業が新機能の迅速な提供を求めたため、従来のウォーターフォール型開発からアジャイル開発への移行が進んだ。これにより、リリース頻度が従来の月１回から週１回に増加した。

２）サービスデスクの負荷増大
　プラットフォームの利用者が１年間で１０万ユーザーから１５万ユーザーに増加し、サービスデスクへの問い合わせ件数が月１，０００件から月１，５００件に増加した。
特に、変更要求件数も月１００件から月２００件に倍増し、変更承認などのプロセスが簡易的な標準変更（ＵＩ改善や定期的なパッチ適用など、低リスクな変更）の範囲拡大が急務となっていた。また、標準変更範囲拡大そのものの迅速化も必要であった。

２）競争環境の激化
　競合他社が迅速に新機能をリリースする中、顧客からは迅速な新機能提供が求められるようになった。例えば、主要競合はＡＩを活用したパーソナライズ機能を短期間で導入しており、競争力を保つためには素早い対応が必要であった。

　これらの環境変化により、既存の変更プロセスがボトルネックとなり、迅速な対応を困難にした。

（７９６文字）

設問イ

２．環境の変化に影響を受けた変更プロセス生じた問題点と改善施策

２．１．変更プロセスの概要

　変更プロセスでは、以下の５ステップで構成されていた。
①変更要求の受付：サービスデスクからのリクエストが提出される
②影響度評価：変更によるシステム停止時間や他の機能への影響・コストとリスクを分析する
③変更の承認：複数部門の担当者によって変更を承認する
④変更の実施：開発チームにて変更をシステムに適用する
⑤レビュー：変更結果を評価し、改善策を立案する
しかし、アジャイル開発による頻繁なリリースや新たな顧客ニーズへの対応が必要となり、従来の変更プロセスでは迅速な対応が難しく、改善が求められる状況となった。

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

　環境変化により、従来の変更プロセスがボトルネックとなり、特にアジャイル開発チームが新機能を迅速にリリースする必要があったにもかかわらず、次のような問題が生じた。

１）デプロイメントの遅延
　アジャイル開発の導入に伴い、リリース頻度が増加したが、従来の変更プロセスは月次でのリリースを前提にしており、リリースのたびに影響度評価や承認プロセスに多くの時間がかかっていた。例えば、アジャイル開発チームは週に１回のリリースを目指していたが、変更のデプロイメントには従来通りの承認手順が必要であった。手動での作業と複数部門による確認が多く、アジャイル開発チームが１回あたり２時間を目指していたデプロイメントが、実際には平均して６時間を要していた。

２）標準変更の拡大の遅延
　標準変更の範囲を拡大し、サービスデスクの負荷を軽減することが求められたが、標準変更を拡大するためには多くの手続きが必要だった。
新たに標準変更項目を追加する際、変更内容を評価し、リスクを分析し、変更手順を詳細化し、複数部門の承認を得る必要があった。このプロセスが非常に時間を要し、通常３週間ほどかかっていた。この遅延が、サービスデスクの負荷を増加させ、顧客からの要望に対して迅速に対応することを困難にしていた。

２．３．改善に向けた施策と期待効果

１）アジャイル開発チームへの権限委譲
　デプロイメントにおける一部の承認プロセスを省略し、アジャイル開発チームに権限を委譲した。例えば、軽微な変更については事前承認なしでリリース可能とした。
これによって、アジャイル開発チームが迅速にリリースを進められるようになり、デプロイメント時間を平均６時間から４時間に短縮することを目指した。
また、アジャイル開発チームの迅速な対応により、リリース頻度の増加と同時に、デプロイメントにおける時間短縮も期待できた。

２）ＣＩ／ＣＤツールの活用
　リリース頻度を週１回から週２回に増加させるため、ＣＩ／ＣＤツールを活用し、ビルド、テスト、デプロイメントの各工程を自動化した。この自動化により、手動作業に伴うエラーリスクを削減し、リリースを効率化させた。
テスト精度の向上によって、リリース時のエラー率が低下する効果も期待した。

３）標準変更プロセスの見直し
　標準変更の範囲拡大に向けて、利害関係者との合意プロセスを効率化するため、変更計画をテンプレート化し、事前承認のプロセスを簡略化した。
この変更により、標準変更項目を追加する際にかかる時間を、従来の３週間から１週間に短縮することを目指した。
標準変更項目の追加がスムーズに進むことで、サービスデスクの負荷軽減も期待した。

（１４８５文字）

設問ウ

３．改善施策の評価

３．１．施策の実施結果

　改善施策を実施した結果、以下のような成果が得られた。特に、デプロイメントの迅速化と標準変更の範囲拡大が、効率化・迅速化に大きく寄与した。

１）デプロイメントの迅速化
　ＣＩ／ＣＤツールの導入により、リリースの頻度が従来の月１回から週２回に増加した。
以前は、変更承認にかかる時間は平均３日であったが、改善後は０．５日に短縮された。
これにより、顧客からの要望に迅速に対応できる体制が整い、特に顧客からの新機能リリースに対する要求に即応できた。

２）標準変更範囲の拡大
　標準変更の範囲をテンプレート化したことにより、変更承認プロセスが効率化し、サービスデスクの負荷が軽減できた。標準変更の承認が従来の３週間から１週間に短縮された。標準変更の割合も増加し、サービスデスクの工数削減にも寄与した。

３．２．施策の評価

１）俊敏な対応
　リリース頻度の増加により、顧客からの要求に迅速に対応する体制が整った。具体的には、顧客からの要請に対して３日以内に新機能をリリースすることができた。これは、他社に対する競争優位性の維持に寄与すると考える。アジャイル開発チームへの権限委譲によって、変更承認プロセスを省略され、リリースのスピードが向上した。

２）品質の確保
　ＣＩ／ＣＤツールの導入により、リリース時のエラー率が従来の５％から２％に低下した。これにより、変更がサービスに与える影響を最小限に抑え、顧客の信頼を維持することができた。また、レビュー工程の強化により、リリース後の問題を最小限に抑えることができ、顧客に対するサービスの信頼性が向上した。

３．３．課題と改善の余地

１）負荷の増加
　アジャイル開発チームへの権限委譲に伴い、チームの負荷が増加した。新しいリリースフローのテストや調整作業が求められ、リリース準備に時間がかかるケースもあった。このため、開発チームの生産性を向上させるためには、教育プログラムなどの追加対策が必要と考える。

２）俊敏性と品質のバランス
　俊敏性と品質のバランスを取ることが今後の課題である。特に、リリース頻度が増えることによる、エラー発生のリスクを最小化する対策が必要と考える。

３．４．総括

　改善施策の実施により、俊敏な対応と品質の確保が一定の成果を上げた。
特に、デプロイメント時間の短縮やサービスデスク負荷の軽減は顧客満足度の向上に寄与した。
しかし、アジャイル開発チームの負荷増加や品質の確保のバランスを取る課題が残っている。今後はこれらの課題を解決し、俊敏性と品質を両立させたサービス提供を心がける。

（１１３７文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場