- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題文および設問は、下記にてご確認ください。
解答例
設問ア
１．ＩＴサービスの概要と変更管理の背景
１．１．ＩＴサービスの概要
私が担当したＩＴサービスは、国内大手の証券会社が運営する顧客向けコールセンターサービスである。このサービスは、個人投資家からの株式売買や各種問い合わせに対応するものであり、顧客満足度を左右する重要な顧客接点である。サービスは、ＣＴＩ、ＣＲＭ、オペレータが参照するＦＡＱ、そして応対スクリプト表示システム等で構成されている。私はＩＴサービスマネージャとして、これらのシステムの安定稼働とサービス改善の責任を担っていた。
１．２．厳格な変更管理の歴史的背景
当サービスの変更管理プロセスは、意図的に極めて厳格な規程となっていた。その背景には、５年前に私が着任する以前に発生した、変更作業に起因する重大なシステム障害があった。オペレータによる設定ファイルの誤操作が引き金となり、約３時間にわたりコールセンター業務が全面停止し、多大な顧客影響と金融庁への報告を要する事態となった。この苦い教訓から、「いかなる軽微な変更も、人の判断ミスを内包するリスクである」という思想が根付き、全ての変更要求をＣＡＢ（変更諮問委員会）で多角的に審議することが絶対的なルールとして定着した。
１．３．既存プロセスに影響を与えた環境の変化
しかし近年、ネット証券の台頭による市場競争が激化し、この鉄壁のプロセスがビジネスの足かせとなり始めた。迅速なサービス改善が経営戦略上の重要課題となり、ビジネス部門からの軽微な変更要求は従来の月１０件から５０件へと急増した。安定稼働を最優先するあまり硬直化したプロセスは、この変化のスピードに全く追随できなかった。結果として、ＩＴ部門はビジネス部門から「動きが遅い抵抗勢力」と見なされ、両者の間には深い溝が生まれつつあり、私はＩＴサービスマネージャとして強い危機感を抱いていた。
（７８８文字）
設問イ
２．変更管理プロセスの問題点と試行錯誤を経た改善策
２．１．環境の変化によって顕在化した問題点
急増する変更要求と硬直化したプロセスの間の歪みは、３つの深刻な問題点を顕在化させた。
１）承認リードタイムの遅延によるビジネス機会の損失
全ての変更が週次ＣＡＢでの審議を必須としていたため、承認に最大７営業日を要した。これにより、競合の動きに対応する緊急キャンペーンの開始が１週間遅延するなど、市場のスピード感から完全に取り残されていた。
２）ＣＡＢの形骸化と関係者の疲弊
月５０件にも及ぶ案件が上程され、１案件あたりの審議時間は平均３分程度に短縮された。会議は報告会と化し、本来のリスク評価機能は完全に失われていた。一方で、軽微な変更のために関係者は多大な準備工数を強いられ、会議中は疲弊感が色濃く漂っていた。
３）統制の形骸化によるシャドーＩＴの発生
煩雑な正規プロセスを敬遠したビジネス部門が、非公式な手順でＦＡＱを更新する事案が発覚した。これは過去の重大障害の再発に直結しかねず、ルールで縛ることによる統制が、逆に統制不能な状況を生み出すという本末転倒な状態に陥っていた。
２．２．試行錯誤を経た改善策の策定と実行
この状況を打開すべく、私は「統制の実効性を確保しつつ、ビジネスの速度向上に貢献する」ことを基本方針に改善に着手した。当初、私はリスクベースの考えに基づき、リスクが低い定型的な変更を「標準変更」と定義し、ＣＡＢ審議を不要とする大胆な改革案を提示した。しかし、この提案は二つの大きな壁に直面した。
１）監査部門からの極めて強い反対
「過去の重大障害の教訓を忘れたのか」と厳しく指摘され、プロセスの簡略化は内部統制の重大な欠陥と見なされた。私は、シャドーＩＴという統制の現状がいかに危険かを訴えると共に、全変更の７割が軽微な修正であるというデータを示し、この非効率性こそがリスクの温床であると主張したが、一度で理解を得ることはできなかった。
２）運用チームからの懸念
「何か問題が起きた時に責任を取らされるのは我々だ」という声が上がり、彼らにとってこの改革はリスクでしかないと受け止められた。
私は、理想論だけでは組織は動かないことを痛感し、計画を以下のように修正した。
・監査部門に対する提案
複数回にわたる対話の場を設け、粘り強く交渉を続けた。最終的に、一度に全てを変えるのではなく、適用範囲を影響が最も少ないＦＡＱのテキスト更新のみに限定した「３ヶ月間の試行導入」とすることを提案した。その上で、試行期間終了後にリードタイムとインシデント発生率を評価し、本格導入を判断するという明確なゲートを設けること、全ての作業記録が追跡・監査可能であること、逸脱時のエスカレーションルールを定めることを約束し、条件付きでの暫定的な合意を取り付けた。
・運用チームに対する提案
彼らを巻き込むアプローチに切り替え、私がファシリテータを務めるワークショップを開催し、彼らの懸念をすべて洗い出した。そして、その懸念を払拭するための具体的な対策を盛り込んだ作業手順書と、ヒューマンエラーを防ぐためのセルフチェックリストを共同で作成した。これは、責任を押し付けるのではなく、共に安全な仕組みを構築するパートナーであるというメッセージを伝えるための、私なりの工夫であった。
この地道な活動を通じて、彼らの不安を少しずつ解消し、最終的に協力を得ることができた。このように、当初の理想案から、関係者の懸念を汲み取った現実的な施策へと修正し、段階的に導入することで、ようやく改善の第一歩を踏み出すことができた。
（１５１７文字）
設問ウ
３．改善策の多角的な評価と今後の現実的な課題
３．１．改善策の多角的な評価
３ヶ月間の試行導入を終え、その効果を多角的に評価した。結果として、当初の狙いであったビジネススピードの向上と統制の実効性回復において、一定の成果を上げたと判断している。
１）定量的な評価
対象としたＦＡＱ更新の平均リードタイムは、従来の５．０営業日から１．２営業日へと７６％短縮された。これにより、ビジネス部門からは高い評価を得ることができた。しかし、その一方で副作用も確認された。導入当初、手順の不徹底によるリンク切れなどの軽微なインシデントが月に２件発生した。これは改善前のゼロ件と比較すると明確な品質低下であり、トレードオフの関係にある。私はこの結果をありのままＣＡＢと監査部門に報告し、インシデントは許容範囲内であり、再発防止策を講じることでリスクは管理可能であると説明し、本格導入への理解を得た。
２）定性的な評価
最も重要な成果は、シャドーＩＴの扱いの変化である。撲滅には至らないものの、非公式な更新の必要性が低下したことで、そのほとんどが管理下の正規プロセスに移行し、可視化されるようになった。これにより、「統制しているつもり」の状態から、「リスクを把握し、管理できている」状態へと移行できた。これは統制の実効性という観点で大きな前進であった。
３．２．今後の現実的な課題と対策
今回の改善は成功への第一歩であるが、その一方で、新たな２つの足元の課題が浮上してきた。私はこれらを次の改善テーマと位置づけている。
１）「標準変更」に該当するか否かの判断基準の属人化
試行導入したＦＡＱ更新以外の類似の変更依頼に対し、担当者によって判断が揺れ、結局私に確認が集中するという事態が発生した。このままでは、ボトルネックがＣＡＢから私自身に移っただけであり、スケールしない。この対策として、判断に迷った事例を収集・分析し、具体的なＯＫ例とＮＧ例を記載した判断基準ガイドを拡充する。さらに、月に一度、運用チーム内で事例共有会を開催し、判断基準の目線を合わせることで、組織としての対応能力向上を図る。
２）承認者となった運用チームリーダーの負荷増大
承認作業に時間を取られ、本来のチームマネジメント業務にしわ寄せが出始めているとの声が上がっている。この対策として、リスクが極めて低いと定義できる一部の定型的な変更（例：誤字脱字の修正）については、リーダー承認を不要とし、作業者とレビュー担当者の２名によるピアレビューで実施可能とする、新たな承認プロセスの導入を検討している。これにより、リーダーの負荷を軽減しつつ、ガバナンスを維持することを目指す。
このように改善によって生まれる新たな課題に一つ一つ対処し、継続的サービス改善を続ける。
（１１６９文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント