- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
ＩＴサービスマネージャ試験の午後Ⅱの対策として、私が実際に練習用に作成した小論文を紹介します。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
ＩＴサービスマネージャに限らず、マネジメントを語るうえでは切っても切れない「継続的改善」に関する問題です。
問題文の上記に述べられているように、重大障害や軽微なミスといったトラブルの是正か、顧客からの高評価といった「よかったこと」をより良くする活動が論述の軸になります。
個人的には「トラブルの是正」の方が書きやすいです。
おじさんの業務経験が、トラブルの是正が多かったからですが、「トラブルが何％減った」と論述すると、定量的で説得力のある内容にできるのも理由のひとつです。
解答例
私が書いた解答例は、次の通りです。
設問ア
１．ＩＴサービス概要と改善の対象とした事象
１．１．ＩＴサービス概要
私が携わったＩＴサービスは、ＩＳＰ事業者Ａ社の顧客管理システムの運用管理システムに関するサービスである。関東を中心に１０万人以上の会員を持つＡ社は、インターネットにて会員の登録・更新を２４時間３６５日受け付けている。また郵送での申し込みも受け付けており、Ａ社に設置した事務処理センターにて平日９時から１８時の間に処理を行っている。
顧客管理システムでは、上記のサービスを提供するほか、課金システムや認証システムなどのＡ社の他システムとの連携を行うバッチ処理が稼動している。
私はＡ社のシステム管理部門に所属するＩＴサービスマネージャであり、顧客管理システムの運用管理と会員と事務処理センター向けの顧客管理システム専用のサービスデスクの管理を行っている。
１．２．改善活動の対象とした事象
サービスデスクでは、四半期に一度サービスデスクにて検知したインシデントの分析を行っている。ある日に実施した分析において、事務処理センターでの登録処理に起因するインシデントが増加傾向にあることを発見した。具体的には、顧客管理システム上必須項目とされる項目（カード番号、希望パスワードなど）が登録されておらず、課金システムや認証システムなどとの連携バッチ処理においてエラーが発生した、というものである。
サービスデスクにてエラーを検知し、すぐに対応を行ったため大事には至っていないが、件数が増加傾向にあるため重大な障害に繋がる可能性を考え、必須項目入力漏れによるインシデント防止を目的とした改善活動を実施することにした。目標５０％削減とした。
（６９６文字）
設問イ
２．改善活動の内容と得られた成果
２．１．事象に対して実施した対応
事前予防策を検討するにあたり、以下の観点で網羅的に原因分析できるよう事務処理センターにヒアリングを行い、それぞれの点で問題があることが判明した。
（１）申込用紙の問題
会員から郵送されてくる申込用紙に、必須項目であるにもかかわらず記載されていなかった。
（２）登録手順の問題
登録手順には「必須項目が申込用紙に記載されていることをチェックする」との記載があったが、どの項目をチェックするのか、チェックした結果によってどうアクションするのかが明記されていなかった。
（３）登録システムの問題
事務処理センターでの登録に使用しているシステムにて、必須項目の入力がない場合に警告メッセージが表示されるがそのまま登録できる仕様になっていた。
これらの問題に対して、それぞれ次のような対応をとることにした。
（１）申込用紙の改善
必須項目であることを分かりやすくするため、必須項目部分の背景色をほかの箇所とは別にし、「必須」の文字を強調するようにした。
（２）登録手順の改善
申込用紙の必須項目部分を確認することと、記入されていない場合は申込用紙に記載された連絡先に確認する手順を明記した。
（３）登録システムの改善
必須項目チェックを強化し、必須項目が登録されていなければ後続処理が出来ないようにした。
特に重要と考えているのは（２）である。なぜならば（１）（３）の改善による効果は高いものであるが、いずれの対策も実現するまでに時間を要するものであるため、（２）の対策をいち早く実施する必要があると考えたからである。
２．２．対応の結果得られた成果
前述の（２）の対策を実施した結果、事務処理センターで登録した会員情報に起因するインシデントが５０％削減することが出来た。
さらに（３）の対策後は、９５％のインシデントの削減に成功した。
また（１）の改善により、申込用紙の不備を８０％削減でき、事務処理センターでの申込用紙の不備に関わる対応コストを（２）の対策実施直後と比較して４０％削減できた。
原因分析を網羅的に実施したのは、より効果の高い改善課題を見出すことが目的であったが、今回の結果は目的を十分に達成できたと評価している。
（９３５文字）
設問ウ
３．組織全体への展開にあたっての工夫
成果を組織全体に展開することは、組織内のほかのＩＴサービスの改善につなげるという意味と、成果を出したメンバーに対する更なるモチベーション向上という二つの意味で重要なことと考えている。今回の成果については、次のようにＡ社全体に展開するようにした。
３．１．部内ポータルサイトへの登録
私が所属しているシステム管理部門では、部内のポータルサイトを立ち上げており、過去の改善活動の事例を登録している。今回の活動においても、ポータルサイトに登録を行い部内に展開するようにした。特に工夫している点は、部内のメンバーがポータルサイトを見に行くように心がけた点である。具体的には、改善の中心メンバーを部内での朝礼で表彰し、表彰したメンバーには更なるモチベーション向上を、ほかのメンバーには部内ポータルを確認する機会を与えるようにした。
３．２．全社の施策発表資料への記載
改善活動の事例については、部内のポータルサイトに登録しているが、特に改善効果の大きかったものについては、Ａ社にて半期に一度行っている全社員向けの施策発表会の場で、前期の成果として担当役員に発表してもらうようにしている。全社に発表することにより、他の部門での改善の参考事例となるため、組織全体の改善として展開できると考えたからである。また、全社の発表に含めることで、メンバーのさらなるモチベーション向上も期待できる。
今回の活動においては、施策発表会の場で発表されたことにより、メンバーからは「さらにやる気が出た」とのコメントをもらった。
また、他部門からは「詳しい内容を聞きたい」との問合せがあり、一定の効果があったと考えている。
（７１３文字）
以降では、この解答をどのような手順で作成したかを解説します。
解説
小論文の全体像を設計する
解答を作成する前に、まずは小論文の全体像を設計します。
問題用紙の余白やメモ用紙部分を使って、小論文の章立てや論述の概要を記載していきます。
最初に全体像を設計するのは、読み手(採点をする人)が読み易い論述をするために必要な作業です。
行き当たりばったりで解答を作成しようとすると、論旨がぶれるリスクが高くなります。その結果、読み手は「この人は何が言いたいんだ？」と困惑してしまいます。
解答作成中に見返すことができるので、論旨がぶれそうなときに軌道修正ができます。
- 論旨が途中でぶれなくなるので、読み手が読み易くなる。
- 解答作成中に見返して、軌道修正ができる。
最終的に出来上がる設計図の全体像は、以下のようなものになります。
実際に試験の場では、こんなにきれいに書く必要はないです。
これから解答を書く際に、自分が迷わなければＯＫです。
章立てを決める
小論文の全体像を設計するために、最初にすることは、章立てです。
章立てには「設問の要求に沿った解答」にするために、設問で使用されているキーワードを利用します。
読み手の側に立って自分の小論文をみると、章立てを見ただけで「設問の趣旨に沿った解答になっていそうだ」といった印象を受けると思います。
改めて設問を見てみると…
上記の黄色の部分をもとに章立てを構成すると、次のようになります。
「３．１．部内への展開」「３．２．全社への展開」は、以下のモジュールを応用しました。
情報共有を行うにあたって工夫した点は、組織の大きさによって手段を変えたことである。
例えば、部内への展開では部内のポータルサイトを使用し、全社への展開では全社の施策発表を利用した。
手段を変えた理由は、次の２点である。
- 部内のポータルサイトには部外秘の情報があるので、全社展開には向かない。
- 部外への展開は、上位組織を通すとやりやすい。したがって、全社展開は経営トップからの発信が最も効果が高い。
各章にどんなことを記述するか決める
章立てが決まったら、各章に記述するおおよその内容を決めていきます。
ＩＴサービスの概要
設問の最初に必ずと言っていいほど登場する「ＩＴサービスの概要」は、事前に準備したモジュールを使用します。
私が携わったのは、ＩＳＰ事業者Ａ社の顧客管理システムの運用管理である。
関東を中心に１０万人以上の会員を持つＡ社は、インターネットにて会員の登録・更新を２４時間３６５日受け付けている。また郵送申込も受け付けており、Ａ社に設置した事務処理センターにて平日９時から１８時までの間処理を行っている。
顧客管理システムでは、上記の会員登録・更新サービスのほか、課金システムや認証システムなどのＡ社の他システムとの連携サービスを提供している。
私はＡ社の全システムを管理するシステム管理部に所属しており、顧客管理システムの管理責任者として顧客管理システムの運用管理と、顧客管理システム利用に関するＡ社ＩＳＰサービスの会員および事務処理センター向けのサービスデスクの管理を担当している。
＜体制＞
エンドユーザ：ＩＳＰ会員、事務処理センター要員
顧客 ：Ａ社営業部
一次サポート：サービスデスク（システム管理部）
二次サポート：システム開発部
このモジュールの中で、後続の論述に展開しやすそうなものを「ＩＴサービスの概要」に記述する主な内容になります。
ここでは、後続に論述する改善活動につながりそうな、「事務処理センター向けのサービスデスク」とします。
改善活動の対象とした事象と、改善活動の内容と結果
次に、後続の各章に記載する内容を決めていくのですが、試験本番中の限られた時間内にぱっと思いつかない場合が多いかと思います。
そんな場合は、問題文の内容を利用します。
問題文を見てみると…
問題文を読むと、「軽微なミスを事前に予防する」ことを論述すればよいことがわかります。
「１．２．改善活動の対象とした事象」は「軽微なミス」、「２．１．事象に対して実施した対応」は「事前予防策」とします。
「２．２．対応の結果得られた成果」は「１．２．改善活動の対象とした事象」が改善したことを論述すればよいので、「軽微なミス」が減ったことが、論述する内容になります。
さらに問題文には「事前予防策」をするには、「すべての作業を点検」すると記載されていますので、事前予防策は次のように詳細化します。
「対策」を論述する際は、必ず「重点対策」が何かをセットにして論述します。
解答時間が少なくなった場合に、当初すべての対策について論述する予定だったのを、重点対策に絞った論述に軌道修正できます。
「軽微なミス」の具体化
「ＩＴサービスの概要」に記載したＩＴサービスのなかで、「重大な障害とならないように事前に予防する」必要がある「軽微なミス」をより具体化します。
「事務処理センター」での「軽微なミス」なので、会員情報を登録する際の入力ミスのモジュールを、「重大な障害」は、認証システムとの連携エラーのモジュールを応用しました。
最も重要視した問題は、事務処理センターでの登録作業時のミスである。
なぜならば、作業ミスの増加は、サービスレベルである「１日に処理可能な件数」の低下を意味しているからである。現在の要員体制のまま修正作業時間が増加すると、本来登録するデータ処理にかける時間が減少してしまう。
最も重要視した問題は、認証システムとの連携処理でのエラーである。
連携処理でエラーになると、インターネット経由での申し込み情報が認証システムに連携されなくなり、システム全体のサービスレベル目標である「顧客情報が登録されてから１分以内に、エンドユーザーがサービスを利用可能にする」を達成できないからである。
「事前予防策」「対策」の具体化
まずは「作業の点検結果」と「対策」を具体化します。
「対策」は「作業の点検結果」の対策を記述することになります。
「点検」を行うのは、改善すべき問題を特定する作業なので、ここでも「発生している問題」モジュールを使用しました。
最も重要視した問題は、申込用紙の記入ミスである。
なぜならば、記入ミスが多いその確認作業に時間を取られることになるため、サービスレベルである「１日に処理可能な件数」が低下してしまうからである。
最も重要視した問題は、リリース作業手順書の不備である。
作業手順に不備があると、作業手順の確認に時間がかかることにより、目標時間内にリリース作業が完了できなくなったり、作業ミスに起因する障害が発生しやすいためである。
最も重要視した問題は、変更を承認したアプリケーションの不具合である。
アプリケーションの不具合の原因によっては、サービスレベルに重大な影響を及ぼす他の不具合が作りこまれている可能性があるからである。
「重点対策」の選定
先に挙げた対策の中から、元も大事な対策を１つ挙げ、その理由を決めます。
どの対策を重点対策とするかは、後続に論述しやすいものを選択します。
ここでは「手順の対策」を重点対策とし、その理由は３つの対策の中ですぐにできる対策であることをあげていますが、他の対策が論述しやすければ、別の理由でほかの対策を重点対策とすれば良いです。
もっともらしい理由であれば、多少こじつけであっても問題はありません。
「ＩＴサービスマネージャとして、限られたリソースの中で効果的な対策を講じている」ことを、読み手にアピールすることが重要です。
「対応の結果得られた成果」を具体化する
「改善活動の対象とした事象」が、「事前予防策」で改善していることを論述することになります。
実際の現場では、こんなにうまくいかない場合もあるかと思いますが、対策が有効だったことを論述する必要があるため、基本的にはうまくいったこと論述するようにすればＯＫです。
「対策実行時に何らかの課題が見つかったこと」を論述するような問題がありますが、その部分は別の個所で論述すれば良いです。
組織全体への展開にあたっての工夫
最期に「組織全体への展開にあたっての工夫」を具体化しますが、考え方は同じです。
３の組織全体への展開については、以下のモジュールを応用することにしました。
部内のメンバー全員と情報共有するようにした。
具体的には、部内にポータルサイトに掲載して、部員全員が参照できるようにした。
特に工夫した点は、部員が積極的にポータルサイトを見に行くように心がけた点である。
ポータルサイトに掲載しても、誰も見なければ情報共有の効果がなくなってしまうためである。
全社に情報共有した。
例えば、全社の施策発表の場を利用して全社員に発信するようにした。
他部署の社員が参加するイベントを利用することで、効率的な情報共有をする狙いがあった。
特に留意した点は、部員のモチベーション維持である。
モチベーションが低下は、生産性の低下や作業ミスによる障害発生といったリスクがあるからである。
具体的には、部内の朝礼で成績の良い部員を表彰するようにした。
他の部員の前で表彰することは、本人のモチベーションだけでなく、他の社員にも好影響があると考えたからである。
特に留意した点は、部員のモチベーション維持である。
モチベーションが低下は、生産性の低下や作業ミスによる障害発生といったリスクがあるからである。
具体的には、経営幹部による全社の施策発表の場で、部員の活動の成果を発表してもらった。
経営幹部からの発表に自分の活動が紹介されることで、「自分の業務が会社にとって重要だ」と部員に感じさせる狙いがあった。
これで全体像の設計は終わりです。
これが小論文の全体像です。
論文の設計に基づいて解答を作成する
論文の設計が終われば、あとはひたすら書くだけです。
書いている途中で迷いそうになれば、設計図を見返して軌道修正をしていきます。
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント