- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題文および設問は、下記にてご確認ください。
解答例
設問ア
１．ＩＴサービスの概要と環境の変化の内容
１．１．ＩＴサービスの概要
私が担当したＩＴサービスは、数百万の会員を抱える大手インターネットサービスプロバイダ（以下、ＩＳＰと呼称）の顧客管理・課金システム及び、それに連携する各種付加価値サービスである。私はこのサービス群のＩＴサービスマネージャとして、システムの安定稼働の維持と、サービスの継続的改善活動の全体を統括する役割を担っていた。本サービスは、２４時間３６５日の無停止稼働が求められる社会インフラとしての側面を持つため、システムの変更管理には極めて高い信頼性と統制が要求されていた。
１．２．既存の変更管理プロセスに影響を与えた環境の変化
本サービスを取り巻く環境は、近年大きく変化した。ＭＶＮＯ等の異業種参入による市場競争が激化し、ビジネス部門からは、競合に対抗するための新料金プラン等を、アジャイル開発によって短期間でリリースするという要求が急増していた。この環境変化に対応する中で、既存の変更管理プロセスの脆弱性を露呈する決定的な事象が発生した。
具体的には、ある緊急の料金プラン変更案件において、増加する変更要求で審議が形骸化していたＣＡＢ（変更諮問委員会）のチェックをすり抜け、関連システムへの影響分析が不十分なままリリースが承認された。その結果、本番環境で数時間にわたり新規顧客の申込受付が停止するという重大なサービス障害を引き起こした。この障害による数千万円規模と試算される機会損失は経営会議でも問題となり、その結果、担当役員であるＣＩＯから私に対し、「３か月以内に再発防止策と、ビジネススピードを両立する新プロセスの骨子を提示せよ」という業務指示が下された。これにより、公式な改善プロジェクトが開始されることになった。
（７５２文字）
設問イ
２．変更管理プロセスの問題点及び改善策
２．１．変更管理プロセスに生じた問題点
私は、今回の障害が単なる手続き上の不備ではなく、組織の構造的な問題に起因すると分析し、以下の３点を問題点として特定した。
１）プロセスの形骸化と客観性の欠如
直接の原因は、ＣＡＢが機能不全に陥っていたことであった。変更要求の急増に対し、審議が追いつかず、客観的なリスク評価基準がないまま、担当者の経験則に依存した承認が常態化していた。
２）部門間の対立を生む組織構造
さらに分析を進め、部門間の対立を生む構造的な欠陥を特定した。それは、開発部門が「機能のリリース速度」で、運用部門が「障害発生件数」で評価されるという、本質的に矛盾したＫＰＩ設定が存在していたことであった。このため、両部門は共通の目標を持てず、対立せざるを得ない状況に陥っていた。この構造が背景となり、長年の安定稼働に自負を持つ運用マネージャは手動確認に固執し、開発チームのリーダーはプロセスそのものに反発していた。
３）経営リスクとしての認識
障害による機会損失額が経営会議で問題視されたことで、ＩＴサービスの信頼性低下が事業継続を脅かす重要リスクとして、経営層に初めて明確に認識された。
２．２．問題点を解決するために実施した改善策
これらの複雑な問題を解決するため、私は以下のプロセスで改善策を策定した。
１）公式な協力体制の構築
私はまずＣＩＯに対し、根本原因が「ＫＰＩの矛盾」にあると報告した。しかし、人事制度の即時改革は困難であるため、「まずはＫＰＩの矛盾を前提とした上で、現実的に機能するプロセスを構築する」というアプローチを提案し、了承された。このアプローチを選択した意図は、理想論に固執して時間を浪費するのではなく、現状の制約下で実現可能な最大の結果を出すことを優先したからである。その上で、改善活動を公式プロジェクトとして認めさせ、各部門から主要な担当者を０．２人月ずつアサインするための、公式な協力指示を取り付けた。
２）個別調整による合意形成
タスクフォースでの全体議論と並行し、私は各主要担当者と個別に面談を重ねた。例えば、運用マネージャには「あなたの障害対応経験は組織の財産だ。その知見をリスク評価基準に組み込み、プロセスとして定着させたい」と敬意を示し、彼の経験を尊重する姿勢を明確にした。開発リーダーには「無駄な審議をなくし、自動化テストで安全が担保された領域では、あなた方にリリース判断の裁量を与える。そのための仕組みを一緒に作らないか」と、官僚主義の排除と合理化というメリットを具体的に提示した。客観的なデータ（パレート図）は、彼らを感情論から引き離し、客観的に説得するための共通言語として有効に機能した。
３）協議に基づく改善策の合意
最終的に合意した改善策は、全員が満足するものではなく、協議の末の現実的な妥協点であった。協議では、標準変更の適用範囲を巡って意見が対立したが、過去の障害発生率データを追加分析し、客観的な線引きを行うことで決着させた。こうして合意した改善策は、以下の３つの施策を一体としたパッケージである。
・標準変更の拡大
すなわちＷｅｂサイトの文言修正など低リスクな定型変更のＣＡＢ審議を不要とする。
・ＣＡＢの役割強化と技術アドバイザーの設置
ＣＡＢの審議対象を重要変更に限定し、運用マネージャの承認を必須とする。
・二重の統制モデルを持つ新カテゴリの創設
アプリの自動デプロイは許容するが、そのパイプライン自体の変更はＣＡＢの厳格な承認事項とする。
このパッケージ提案は、対立する両部門に譲歩と利益を同時に与え、変革を前進させるための戦略的な次善の策であった。
（１５５２文字）
設問ウ
３．改善策の評価と今後の課題
３．１．改善策の評価
一連の改善策は、当初の目的であった統制の維持とスピード向上に対し、明確な成果を上げた一方で、その限界も明らかにした。
１）得られた成果
定量的な成果として、変更要求の平均リードタイムは３０日から１０日へと約６７％短縮され、リリース頻度は月次から週次へと向上した。また、変更に起因する重大なサービス障害は月平均３．５件から０．８件へと約７７％減少し、統制も強化できた。定性的には、改善後に競合他社の新サービスへ対抗する重要案件が申請された際、新設された事前レビューが機能し、データベースの特定テーブルへのアクセスが集中するという潜在的な性能劣化リスクを運用部門が指摘した。これにより、リリース前にボトルネックを特定・回避でき、事業機会を損失することなく安全なサービス提供が実現した。
２）顕在化した新たな課題
しかし、私はこの成果が限定的であると評価している。根本原因である「ＫＰＩの矛盾」は残存したままであるため、開発と運用の間には依然として緊張関係が残り、プロセスの解釈を巡る小さな対立が散発的に発生していた。また、プロセスの濫用や、若手運用担当者のスキル低下懸念といった、新たな問題も顕在化した。特にプロセスの濫用は、意図的なルール違反であり、放置すれば新プロセス全体の信頼性を損なう、極めて深刻なリスクであると認識している。
３．２．今後の課題と対策
これらの新たな課題に対し、私は以下の継続的な改善を計画している。
１）短期的な対策
プロセスの濫用に対しては、定期的な監査と改善指導を行うだけでなく、逸脱が続くチームに対しては、一時的に標準変更の利用を停止するといった、より厳格な措置も検討する。人材育成の課題に対しては、過去の障害を題材とした実践的なインシデント対応訓練を実施する。
２）中長期的な対策
現行プロセスの改善に留まらない。今回の改善活動で得た定量的な成果と、「ＫＰＩの矛盾」という根本原因分析レポートを客観的な根拠として、ＣＩＯと人事部門に対し、「開発と運用の共通目標を持つ、新しい評価制度の試験導入」を正式に提言する。その際、想定される現場の反発（評価制度変更への抵抗）に対しては、まず特定のプロダクトチームに限定して試験導入し、その効果を測定・共有した上で、全社展開の是非を判断するという、現実的な導入計画も併せて提示する。部分最適の集合から脱却し、組織全体のパフォーマンスを最大化するこの本質的な改革を主導することが、ＩＴサービスマネージャとしての重要な役割であると考える。
（１０８９文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント