【SM】令和6年度 午後Ⅱ 問1(ヘルプデスク編) – 情報処理技術者試験(PM/SM)に連続で一発合格したおじさんによる 過去問論文事例

こんな人におすすめ
  • 午後Ⅱ(小論文)でいつもつまづいている
  • 小論文のネタを探している
  • 合格者のアドバイスを受けたい

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

問題文および設問

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

問題文

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

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

設問ア

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

設問イ

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

設問ウ

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

解答例

設問ア

1.ITサービスの概要と環境変化

1.1.ITサービスの概要
 私が担当したITサービスは、従業員数5,000名規模の製造業A社における社内ITヘルプデスクである。このヘルプデスクは、社内の情報システム部門に所属する10名の専任要員で構成されており、社内システムの利用方法や障害に関する問い合わせ対応、各種申請の受付、システム変更作業などを担当している。私は情報システム部門のマネージャとして、このヘルプデスクの統括責任者を務めていた。

1.2.環境変化の内容
 従来、ヘルプデスクが担当する変更作業は、主にパソコンやプリンタの設定変更、ユーザIDの払い出しなど、定型的な作業が中心であった。しかし、次の3つの環境変化が発生し、既存の変更管理プロセスへの影響が生じた。

1)クラウドサービスの本格導入
 コスト削減と業務効率化を目的として、社内の主要なシステムをオンプレミスからクラウドサービスへ移行することになった。これにより、クラウドサービス特有の頻繁なバージョンアップへの対応や、新機能のリリースに伴う設定変更作業が増加した。

2)DevOps手法の採用
 クラウド移行を契機に、一部のシステムでDevOps手法を採用することになった。これにより、従来の月次や四半期でのリリースから、週次や日次での小規模なリリースが増加した。

3)リモートワークの拡大
 新型コロナウイルス感染症対策として、全社的にリモートワークを導入することになった。これにより、VPN接続やセキュリティ設定など、リモートワーク環境整備に関する変更作業が急増した。

(690文字)

設問イ

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

2.1.変更管理プロセスの問題点
 環境変化により、既存の変更管理プロセスには次の問題が生じた。

1)承認プロセスの長期化
 従来の変更管理プロセスでは、全ての変更作業について部門長の承認が必要だった。しかし、クラウドサービスの頻繁なアップデートやDevOpsによる小規模リリースの増加により、承認待ちの案件が増加し、変更作業の実施が遅延する事態が生じた。具体的には、部門長の承認を得るまでに平均で3営業日を要し、緊急性の高い変更要求に対しても迅速な対応ができない状況であった。例えば、チャットツールのセキュリティアップデートの適用が5日間遅延し、既知の脆弱性への対応が遅れるケースがあった。

2)変更作業の属人化
 クラウドサービスやDevOpsに関する変更作業は、それらの知見を持つ要員に依存していた。その結果、担当要員の不在時には変更作業を実施できない、作業品質にばらつきが出るといった問題が生じた。

3)リスク評価の形骸化
 変更作業の増加に伴い、リスク評価が十分に行われないまま変更を実施するケースが増加した。特に、リモートワーク環境の整備では、セキュリティリスクの評価が不十分なまま変更を実施し、セキュリティインシデントにつながるケースがあった。例えば、VPNクライアントの設定変更時に、アクセス制御の設定を誤り、一時的に社外からの不正アクセスのリスクが生じた。

 これらの中で、特に「承認プロセスの長期化」が最重要課題だった。承認の遅延はサービス提供に直接的な影響を与え、事業部門からの信頼を損なう可能性が高いためである。

2.2.改善策の実施
 これらの問題点を解決するため、次の4つの改善策を実施した。特に「標準変更の範囲拡大」を最優先と考えた。最も即効性が高い対策と判断したためである。属人化の問題は、即効性が見込めないため継続検討課題とした。

1)標準変更の範囲拡大
 変更作業を「標準変更」「通常変更」「緊急変更」の3つのカテゴリに分類し、特に「標準変更」の適用範囲を拡大した。分類の基準を明確にするため、過去1年間の変更作業履歴を分析し、リスク評価と所要時間をもとに次の基準を策定した。

・標準変更:リスクが低く、手順が確立された定型的な変更作業
 例:ユーザIDの払い出し(30分程度)、クラウドサービスの定期アップデート(2時間程度)、DevOpsによる小規模リリース(影響範囲が特定の部署内に限定)など
・通常変更:一定のリスクを伴う変更作業
 例:新規クラウドサービスの導入(他システムとの連携が必要なもの)、セキュリティポリシーの変更(全社に影響するもの)など
・緊急変更:障害対応など、即時対応が必要な変更作業
 例:セキュリティインシデント対応(データ漏洩のリスクがあるもの)、システム障害復旧(業務停止の影響があるもの)など

2)承認フローの簡素化
 ヘルプデスクのチームリーダーによる承認のみで、標準変更を実施可能とし、承認待ち時間の短縮を図った。チームリーダーには、変更管理に関する研修を実施し、リスク評価の能力を向上させた。通常変更と緊急変更については、従来通り部門長の承認を必要とした。

3)CABの運営方法見直し
 従来は月1回の定例開催であったCABを、週1回のオンライン開催に変更した。また、CABのメンバーに次のメンバーを追加した。各専門家の知見を活かして、リスク評価を強化するためである。
・情報セキュリティ部門の担当者(セキュリティリスク評価)
・主要事業部門の業務責任者(業務影響評価)
・クラウドサービス導入プロジェクトのリーダー(技術的評価)

(1572文字)

設問ウ

3.改善策の評価と課題

3.1.改善策の評価
 変更管理プロセスの改善策について、6か月間の運用結果から次のような評価を行った。

1)定量的評価
 改善策の効果を定量的に評価するため、次の3つの指標を設定し、測定を行った。

・変更要求の承認所要時間
 標準変更の平均承認時間が3営業日から0.5営業日に短縮された。これにより、次のような効果が得られた。
 ・クラウドサービスの更新を、ベンダー推奨期限内に100%完了できるようになった
 ・DevOpsチームの日次デプロイメントの遅延が月平均12件から0件に改善
 ・セキュリティパッチの適用までの所要時間が平均72時間から24時間に短縮

・変更実施の精度
 変更実施計画と実際の所要時間の乖離が、平均40%から10%に改善された。これは、CABでの事前評価の精度向上が要因と考える。

・セキュリティインシデント数
 変更作業に起因するセキュリティインシデント数が、月平均2件から0件に減少した。これは、CABにセキュリティ部門が参加したことによるリスク評価の強化と、評価基準の見直し効果
による元も考える。

2)定性的評価
 主要なステークホルダーへのヒアリングから、次のような効果が確認された。

・事業部門の評価
 ・変更要求から実施までのリードタイムが短縮され、業務効率が向上した
 ・変更カレンダーにより、システム変更の影響を事前に把握できるようになった
 ・変更実施後のトラブルが減少し、業務の安定性が向上した

・開発チームの評価
 ・DevOpsによる継続的デリバリーが計画通りに実施できるようになった
 ・標準変更の範囲拡大により、開発生産性が向上した
 ・CABの週次開催により、変更計画の柔軟な調整が可能になった

3.2.今後の課題
 一方で、次のような課題も明らかになった。

1)標準変更の範囲見直し
 標準変更の適用範囲拡大により、本来は詳細なリスク評価が必要な変更作業が、標準変更として処理されるケースが生じた。例えば、セキュリティパッチの適用で、アプリケーションの互換性問題が発生したケースがあった。
この問題に対して、影響範囲の評価基準の見直しや、事前検証環境での評価確認プロセス追加を行う。

2)CAB運営の効率化
 CABの週次開催により、事前評価資料作成時に伴う負荷や、参加メンバー負荷が増大する問題が生じた。
この課題に対応して、資料の簡素化、リスク評価プロセスの自動化の検討、審議案件の優先順位付け、といった対策を検討する。

対策を見送った課題を含め、上記課題の対策を実行すると伴に、変更管理プロセスの継続的な改善を行っていく。

(1165文字)

まとめ

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

参考図書

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

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

コメント