- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
ＩＴサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題文および設問は、下記にてご確認ください。
解答例
設問ア
１．ＩＴサービスの概要とヒューマンエラーに起因した障害
１．１．ＩＴサービスの概要
私が担当したＩＴサービスは、数百万の会員を有するインターネットサービスプロバイダ（ＩＳＰ）の顧客管理及び課金システムである。本システムは事業収益の根幹であり、その安定稼働は運用部門の責務であった。一方、開発部門は経営からの強い要請を受け、競合に対抗するため新料金プランの迅速な市場投入を目標としていた。そのため、安定性を重視する運用部門とスピードを重視する開発部門との間には、責任範囲を巡る対立が恒常的に発生していた。
１．２．ヒューマンエラーに起因した障害
このような状況下で、開発担当者が本番環境のデータベースをテスト環境と誤認し、約３０万件の顧客情報を更新するスクリプトを実行するという重大な障害が発生した。この誤操作により、大規模な誤請求に繋がりかねない事態となり、私はサービスマネージャとして、その復旧、原因究明、そして再発防止策の策定を主導した。本障害の背景には、高品質なテスト環境の構築が技術的負債として先送りされ、本番環境のデータを利用したテストが黙認されるという、リスクの高い状態があった。
１．３．ヒューマンエラーの内容
本障害を直接引き起こしたヒューマンエラーは、典型的な状況下で発生した。担当者は両環境のターミナルを同時に開いて作業していた。その最中に上司からの電話という割り込みで作業を中断し、復帰後に、操作対象のターミナルがどちらであるか再確認しないまま、テスト環境と誤認してスクリプトを実行してしまったのである。この行動の背景には、第一に「思い込み」、第二に「不注意」があった。そして第三に、類似作業の繰り返しで確認作業を省略していた「慣れ」が、割り込み後の確認漏れという致命的なミスを誘発した。これらが連鎖し、重大障害へと繋がったと私は分析した。
（７８９文字）
設問イ
２．根本原因の分析と実施した対策
２．１．根本原因の分析
障害発生直後、私は再発防止策として二つの短期対策を講じた。第一に、本番環境接続時のターミナルのプロンプトを警告色である赤色に変更した。これは、特に今回の障害の引き金となった作業中断からの復帰時に、瞬時に環境を再認識させ、今回のような選択ミスといった認知的な誤りを防ぐ効果を期待したものであった。第二に、作業承認プロセスを厳格化したが、これには開発部門から「手続きが煩雑で、緊急時の対応速度を妨げる」との意見が出された。結果として、このプロセスは十分に定着せず、類似の事象が発生するに至った。
この経験から、私は表面的な対策では不十分であると判断し、開発部門のリーダーと改めて対話し、「犯人探しではなく、未来志向で仕組みの問題を解決したい」という私の意図を真摯に伝えた。彼の協力も得て、関係者による原因分析会議を再度設定した。そこで、なぜなぜ分析を深掘りし、「なぜ割り込み後に誤ったか」という問いに対し、「作業再開時の確認が手順として定義されていなかったから」という原因を特定した。さらに「なぜ手順がなかったか」を問うことで、「予期せぬ中断を想定した強靭なプロセスが設計されておらず、個人の注意力に依存する属人的な運用であったこと」、そして「リスクと開発速度のトレードオフを定量的に評価し、組織として合意形成する仕組みの欠如」という、二つの構造的な問題を根本原因であると再定義した。
２．２．再発防止のために実施した対策
特定した根本原因に基づき、私は技術とプロセスの両面から抜本的な対策を立案し、実行した。
１）手動操作の廃止と自動化による統制
技術的な対策として、手動での直接操作を原則禁止とする方針を定めた。これは、割り込みのような人的要因に左右されない、再現性と安全性の高いプロセスを構築するためには、手動操作の介在をシステム的に排除する必要があったからである。その代替として、全ての変更作業を特定のスクリプト言語で記述した自動化スクリプト経由で実行することを義務付けた。さらに、そのスクリプト自体をバージョン管理システムで管理し、変更時には必ず運用と開発の双方のリーダーによるコードレビューと電子承認を経なければ、本番環境に適用できない仕組みを構築した。導入当初は、スクリプト作成の学習コストに対する開発部門からの抵抗もあったが、標準的なテンプレートと勉強会を提供することで、徐々に浸透させることに成功した。レビューでは、処理内容の正当性に加え、万一の際のためのロールバックスクリプトの同梱も必須の確認項目とした。これにより、プロセスとして品質と安全を担保し、かつ作業の再現性を確保することを目指した。
２）リスクの定量化と組織的な合意形成
プロセスの対策としては、まず開発部門と共同で、障害発生時の機会損失と対応コストを具体的な金額として試算した。具体的には、復旧にかかるエンジニアの人件費、コールセンターの増員費用、顧客への補償費用、そして信用の毀損を、業界の平均的な顧客獲得単価を参考に、仮に顧客が一定数解約した場合の再獲得コストとして機会損失に含めるなど、具体的な算出根拠を明示して合算し、一度の重大障害で約５千万円の損失が発生しうると算出した。この客観的な数値を提示することで、開発部門に安全対策の重要性を再認識させることができた。さらに、この試算結果を基に、高品質なテストデータ管理基盤の構築費用（約２千万円）に対する投資対効果（ＲＯＩ）を明確にした資料を作成し、経営会議で説明した。これにより、リスクの大きさを経営課題として明確に提示し、最終的に対策予算の獲得に至った。この一連の活動は、技術的な問題解決に留まらず、組織全体の品質とリスクに対する意識を改革する重要な一歩となった。
（１５８９文字）
設問ウ
３．ヒューマンエラーの傾向分析と組織としての課題
３．１．ヒューマンエラーの傾向分析
先の重大障害への対応を機に、私は個別事象への対処から、組織全体の予防的管理へと移行する必要があると判断した。その第一歩として、過去３年間のインシデントレポートを対象に、パレート分析を用いた傾向分析を実施した。分析の初期段階において、ヒューマンエラーの原因を「手順不遵守」と「確認不足」に分類する際、解釈の対立が生じた。ある事象は手順書通りに行わなかった結果とも、確認を怠った結果とも解釈できたからである。私はこれを重要な論点と捉え、新たに「手順書自体の不備・形骸化」という第三の分類軸を設定した。この工夫により、担当者の個人責任の追及を避け、分析会議の雰囲気がより建設的なものになった。
この分類基準で分析した結果、「確認不足」が４０％、次いで「手順書自体の不備」が３５％となり、この二つで全体の７５％を占めることが判明した。このことから、取り組むべきは個人の注意力向上ではなく、確認を不要にする仕組みの構築と、信頼できる手順を維持するプロセスの整備であることが組織全体の共通認識として明確になった。
３．２．分析によって明らかになった組織としての課題
この傾向分析から、私は組織が抱える３つの構造的課題を抽出した。
１）改善活動が評価されない人事評価制度
「手順書自体の不備」が放置される背景には、手順書の更新のような地道な改善活動が、担当者の人事評価に繋がらない制度上の問題があった。新機能リリースといった目立つ成果が優先されるため、改善活動の意欲が生まれにくく、結果として技術的負債が増大する構造になっていた。
２）部門間で責任が転嫁される技術的負債
高品質なテスト環境の不備という問題は、その構築責任の所在が曖昧なまま、開発部門は「インフラの問題」、運用部門は「そもそもそのようなテストが必要な開発設計の問題」と、互いに責任を押し付け合う状態が続いていた。この責任のなすりつけ合いは、具体的な解決策の検討を停滞させ、リスクを放置し続ける結果を招いていた。
３）建設的な議論を阻害する組織文化
最初に述べた部門間の緊張関係は、健全な議論ではなく、表面的な非難の応酬に留まりがちであった。リスクの兆候に気づいても、関係悪化を懸念して指摘を躊躇う傾向があり、問題が顕在化するまで放置されるという事態を招いていた。
これらの課題解決には、単発の技術的対策では不十分であり、部門横断での共通目標（ＫＰＩ）の設定と、それを支援する評価制度への見直しといった組織的なアプローチが不可欠であると、私は経営層に進言した。
（１１１１文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント