- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
具体的な問題はIPAにてご確認ください。
解答例
設問ア
１．ＩＴサービスの概要と環境変化
私が担当したＩＴサービスは、クラウドベースの統合業務システムの運用管理である。当該システムは、大手製造業の基幹システムとして、会計、販売、在庫、生産管理などの業務機能を提供する。利用部門は国内外２０拠点、利用者数は約５，０００名規模であり、２４時間３６５日のサービス提供が求められる重要システムであった。
環境変化として、以下の３点が既存の変更管理プロセスに大きな影響を与えた。
１）変更頻度の増加
・パブリッククラウドの採用により、インフラ環境の変更が年間数回から月次へと増加
・ＳａａＳ／ＰａａＳベンダによる更新への対応が必須となり、変更件数が年間２００件超に増加
・マイクロサービスアーキテクチャの採用により、個別機能単位での変更が可能となり、変更の粒度が細分化
２）アジャイル開発手法導入
・従来の半期に１回のリリースから、２週間単位のスプリントでの継続的なリリースに移行
・ＤｅｖＯｐｓの導入による開発・運用の統合と、ＣＩ／ＣＤパイプラインの整備
・自動テスト・自動デプロイの導入によるリリース作業の自動化推進
３）ビジネス要件の変化への対応スピード強化
・ＤＸ推進による新規サービス開発の増加
・競合他社のサービス展開に対する迅速な対応要求
・コロナ禍におけるリモートワーク対応など、急速な業務形態の変化への対応必要性
これらの環境変化により、従来のウォーターフォール型を前提とした変更管理プロセスでは、変更要求への迅速な対応が困難となった。特に、従来の承認プロセスでは、変更の影響範囲やリスク評価に時間を要し、ビジネスの要求する展開スピードに追従できない状態であった。
上記の状況を踏まえ、内部統制を維持しつつ、変更管理プロセスの効率化と迅速化が最優先課題となった。
（７９６文字）
設問イ
２．変更管理プロセスの問題点と改善策
２．１．変更管理プロセスの問題点
以下の問題が顕在化した。
１）変更承認プロセスの硬直化
・軽微な変更でも複数の承認者による承認が必要であった。過去に発生した重大障害の対策として、リスクの大小に関わらず画一的な承認プロセスとしたためである。
・ＣＡＢメンバーが多忙のため、ＣＡＢの開催が月１回の定例のみとなっている。そのため、緊急性の高い変更要求への即応ができず、「承認待ちで事業機会を逃した」という経営層からの指摘もあった。
２）ＤｅｖＯｐｓとの不整合
・開発チームが実装した変更が、承認待ちにより展開できない状況が頻発している。「毎日コードをプッシュしているのに、本番反映は月１回」という開発者の不満が蓄積し、モチベーション低下につながった。
・自動テストによる品質確認結果が承認プロセスに反映されない。これは、品質保証部門が自動テスト結果を信頼できないと考え、従来通りの手動テストと承認を要求しているためである。
３）クラウドサービス特有の変更への対応不備
・従来の変更管理プロセスは、クラウドベンダによる変更を想定していなかった。
２．２．変更管理プロセスの改善策
以下の改善策を実施した。
１）変更カテゴリの再定義と承認フローの最適化
・変更の影響度とリスクに基づく４段階のカテゴリ分類を導入した。例えば、過去３回以上成功実績のある定型的な変更は「標準変更」として事前承認とし、単一のマイクロサービスへの変更は「軽微変更」として担当マネージャーの承認のみで実施可能とした。成功実績のある変更は、他の変更に比べて重大障害が発生確率が低いと考えた。
・標準変更の適用範囲を拡大し、定型的な変更の９５％をカバーした。例えば、セキュリティパッチの適用など、手順が確立された作業を標準変更に分類した。
２）ＣＡＢ運営の効率化
・従来、月１回の対面式で開催していた会議を、週１回のオンライン形式に変更した。これは地理的制約を排除することより、ＣＡＢメンバー全員が迅速に参加可能となり、承認プロセスの即時性を向上させた。また、会議室確保が不要になり、会議室確保のための日程再調整、と言ったムダな工数の削減も期待できた。
・軽微変更に関しては、ワークフローシステムによる承認を可能とした。迅速な変更実施に寄与できると考えた。
３）ＤｅｖＯｐｓ対応の変更プロセス確立
・ＣＩ／ＣＤパイプラインと変更管理システムを統合し、自動テスト合格⇒変更承認済になるようにした。具体的には、「開発者がコードをソースコード管理ツールにプッシュ⇒ＣＩツールがテストを自動実行⇒テストが成功した⇒変更の自動承認」となるようにした。これはＣＡＢメンバーの負荷軽減の狙いもあった。
・開発者がコードレビューを完了すると、システムが自動的に変更要求を生成するようにした。変更要求の作成工数削減による、変更管理の効率化を狙った。
・ 開発環境での変更（例：テストサーバーへのデプロイ）については、最小限の承認手続きとした。具体的には、開発環境では開発リーダーの承認のみで変更できるようにした。開発環境での変更は本番環境に比べてリスクが低く、承認プロセス簡素化により、開発効率の向上が期待できた。
４）クラウドサービス特有の変更管理方式の確立
・クラウドベンダによる更新に伴う影響を評価するための、基準を策定した。例えば、クラウドベンダのＡＰＩ変更時、自社システムへの影響度を評価し、影響度に応じた対応策を決定するようにした。
事前対策によって、クラウドベンダによる更新に起因する障害を防止でき、サービスの安定稼働に寄与すると考えた。
（１５９０文字）
設問ウ
３．改善策の評価と課題
３．１．改善策の評価
１）変更要求の処理時間
標準変更の承認待ち時間が劇的に改善された。具体的には、従来は申請から承認まで平均２日かかっていた作業が、事前承認により即時対応可能となった。例えば、セキュリティパッチの適用が「今すぐ必要」という要望に対して、その場で対応できるようになった。
重要変更についても、ＣＡＢのオンライン化により承認待ち時間が１４日から５日に短縮。「月末の決算処理に間に合わない」という苦情が激減した。
２）変更成功率
全体の変更成功率が９２％から９８％に向上した。これは、標準変更の手順書整備と自動化により、人的ミスが大幅に減少したためである。特に深刻な事例として発生していた「本番環境での設定ミス」が、自動化によりゼロとなった。
３）作業効率
ＣＡＢメンバーの審議工数が激減した。具体的には、毎月の資料作成と会議で４０時間を費やしていた工数が、オンライン化とドキュメント自動生成により１５時間まで削減された。
変更管理担当者の精神的負担も大幅に軽減し、「会議のためだけに出勤せずに済むようになった」と、感謝の声をもらった。
さらに、「作業負担が減り、集中して開発に取り組める」「以前よりも確実にスケジュール通りに変更が実施されるようになったため、業務への影響が減った」といった声が届いた。
３．２．今後の課題と対応方針
１）リスク評価の精度向上
例えば、「標準変更として承認済なので大丈夫」という声が様々な場所で聞こえ始め、伴うリスク評価の質の低下が懸念された。
下記の対策によってリスク評価の精度向上を図る。
・過去の変更履歴を機械学習で分析し、リスクの予兆を自動検知する仕組みを構築し、「この時間帯の変更は失敗率が高い」といった傾向を検知し、警告を出す。
・四半期ごとに変更管理委員会を開催し、リスク基準の見直しを行う。具体的には、インシデント分析結果を基に、標準変更の判断基準を継続的に改定する。
２）変更の相互依存性管理
例えば、「ＡＰＩの変更とＤＢの変更が重なって障害が発生した」という事例が報告されるなど、複数チームでの同時変更時の情報共有が不十分であった。
下記対策で、チームメンバーでの情報共有を強化する。
・変更カレンダーをダッシュボード化し、全チームがリアルタイムで変更状況を把握できるようにする。
・依存関係のある変更を自動検知し、関係者に通知する仕組みを実装する。例えば、同じデータベースに対する変更が計画されている場合、関係者全員にビジネスチャットツールで自動通知を行う。
今後は、これらの課題に対して、より実効性の高い対策を実施していくつもりである。
（１１７３文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント