【SM】平成22年度 午後Ⅱ 問2 – 情報処理技術者試験(PM/SM)に連続で一発合格したおじさんによる 過去問論文事例

こんな人におすすめ
  • 午後Ⅱ(小論文)でいつもつまづいている
  • 小論文のネタを探している
  • 合格者のアドバイスを受けたい

ITサービスマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問2 リリース管理におけるリリースの検証及び受入れについて

 新規のシステム又は改変されたシステムを、稼働環境に円滑に実装するためのリリース管理は、ITサービスマネージャの重要な業務である。リリース管理においては、リリースの内容を把握した上で、適切な実装計画を立案し、確実に実施するためのマネジメントが重要となる。
 中でも、実装直前に行うリリースの検証及び受入れは、リリース管理における重要なプロセスであり、それまでに次のような準備をしておく必要がある。
・受入れテスト環境の構築
・実装手順及び不測の事態に備えた切戻し手順の作成
・人的リソースの確保
 しかし、リリースの検証及び受入れのとき、次のような問題が発生することがある。
・緊急の受入れ要請があり、受入れテストに十分な時間を確保できない。
・受入れテストの結果、運用機能の改善が必要であると判明した。
・実装に当たり、当初想定した以上の作業要員が必要であると判明した。
 このような場合、ITサービスマネージャは、早急な問題解決に向けて利用者、関連部門などと対応を協議し、対策を実施する必要がある。
 また、再発防止に向けて、発生した問題の根本原因を究明し、適切な施策を講じなければならない。根本原因の究明に当たっては、リリースの検証及び受入れ、又はリリース管理の視点にとどまらず、ほかの管理プロセス(変更管理、構成管理など)、更には稼働環境、運用基準なども含めた広範な視点から、分析を行うことが重要である。
 あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。

設問ア

あなたが携わったITサービスの概要と、リリースの検証及び受入れの概要について、800字以内で述べよ。

設問イ

リリースの検証及び受入れのときに発生した問題と、問題解決に向けて利用者、関連部門などと協議した対応の内容及び実施した対策について、800字以上1,600字以内で具体的に述べよ。

設問ウ

設問イで述べた問題の根本原因と、再発防止に向けて講じた施策について、600字以上1,200字以内で具体的に述べよ。

解答例

設問ア

1.ITサービス概要とリリースの検証及び受入れの概要

1.1.ITサービス概要

 私が担当したITサービスは、大手小売業向けの統合顧客管理システム(CRM)の開発および運用である。本システムは、各店舗で収集した顧客情報を集約し、購買履歴や顧客属性に基づくマーケティング施策を可能にすることを目的として設計された。主な特徴は以下の通りである。
・各店舗のPOSシステムとのリアルタイム連携により、購買履歴を即時に分析可能。
・顧客属性に応じたプロモーションメールの自動配信機能を提供。
・クラウド環境を活用したスケーラブルなシステム基盤を採用。

 このシステムは、全国展開する小売チェーンの顧客満足度向上と売上増加を目指し、初期開発から運用改善まで一貫して関与したものである。

1.2.リリースの検証及び受入れの概要

 リリースの検証及び受入れにおいては、特に以下の3点を重点的に管理した。

1)受入れテスト環境の構築
 本番環境と同等のテスト環境を準備し、POSシステムや外部メール配信サービスとの連携を確認可能な状態を整備した。
2)実装手順及び切戻し手順の作成
 システム変更に伴う影響を最小限に抑えるため、詳細な実装手順書を作成。特に、不測の事態が発生した場合に迅速に復旧可能な切戻し手順を記載した。
3)人的リソースの確保
 リリース作業を円滑に進めるため、システム開発チームだけでなく、運用チームや店舗担当者を含む多部門連携体制を整えた。

 これらの準備を踏まえ、リリース当日には事前に策定したスケジュール通りにテストおよびリリースを実施した。さらに、リリース後は想定外の不具合がないことを確認するため、限定的な店舗でのパイロット運用を経て、全店舗への展開を段階的に行った。

(773文字)

設問イ

2.リリースの検証及び受入れ時の問題と対策

2.1.リリースの検証及び受入れ時の問題

 リリースの検証及び受入れ中に、下記の問題が発生した。

1)受入テスト時間の不足
 重要なパッチ適用に関して、実施時期を前倒しするよう、顧客からの緊急要請があった。その結果、全てのテスト項目を実施する時間が確保できず、パフォーマンステストセキュリティテストの一部が後回しとなり、未発見の不具合が残るリスクが生じた。

2)運用機能の不備
 利用者にとっての重要機能である「システム状態のモニタリングダッシュボード」が未完成であることが、受入テスト中の運用部門からのフィードバックによって判明した。この機能は、システムのパフォーマンスや障害の有無をリアルタイムで把握するために必要だったが、初期段階での利用者要件の収集と仕様化が十分でなく、リリース直前に発覚した。

3)要員不足
 リリース直前に、当初想定していた以上の工数が必要であることが判明した。これにより、リリース作業を円滑に進めるための要員が不足し、対応が遅延する可能性が生じた。

2.2.問題解決に向けて関連部門と協議して決定・実行した対策

 これらの問題を解決するために、以下の対策を実施した。

1)受入テストの再設計と優先度設定
 受入テスト項目を重要度に応じて分類し、パッチ適用確認や主要業務フロー(受注から出荷までのプロセス)など、特にクリティカルな機能に関するテストを優先する計画を立てた。また、テスト時間を確保するために、UIの微調整など非クリティカルな項目は一部を省略し、リリース後の追加検証とする計画にした。
さらに、「テスト完了状況」「発見した不具合の優先度」などを記載したチェックリストにより、進捗状況の可視化を図った。このチェックリストは、進捗状況をリアルタイムで更新できるプロジェクト管理ツール上に実装し、関係者間での情報共有のタイムラグを最小化し、迅速な意思決定を可能にした。
さらに、発生確率と影響度を数値化したマトリクスを用いて品質管理部門との協議を行い、発生確率と影響度がともに大きいリスク項目に集中する方針とした。

2)運用機能の改善
 不足している運用機能については、運用部門との緊急会議を開催し、優先度の高い機能を特定した。その上で、開発チームに対して速やかに改善作業を指示し、リリース日までに最小限必要な機能を追加実装した。
また、次回以降は、早期の要件確定を確実にするため、利用者要件の収集プロセスを見直した。具体的には、プロジェクトの初期段階で、運用部門を含むステークホルダー全員が参加する要件定義ワークショップを実施することにした。

3)要員確保
 作業工数増加に対応するため、経営幹部から追加予算の承認を得て、他部門からの支援を要請した。具体的には、過去のプロジェクトで協力実績のある要員がいる部門に連絡を取り、必要なスキルを持つ要員を確保した。また、リリース作業に優先順位を付け、重要なタスクに要員を集中させることで、全体の効率を向上させた。
効率的な要員配置をする工夫として、要員割り当ての基準を設定することにした。具体的には、プロジェクトマネジメント部門や各部門リーダーと、「各作業の緊急性」「重要性」「作業者のスキル適合度」を考慮した基準をもとに協議したうえで要員を配置した。
さらに、支援要員が即戦力として機能するように、簡略化したトレーニング資料を事前に配布し、スムーズな作業参加を図った。

 これらの対策を通じて、発生した問題を短期間で解決し、リリースの円滑な実施を実現することができた。さらに、問題解決の過程で得られた知見をもとに、以降のリリースプロセスの改善にも取り組んだ。

(1588文字)

設問ウ

3.根本原因分析と再発防止策

3.1.根本原因分析

 なぜなぜ分析を用いて、下記の根本原因を特定した。

1)受入テスト時間不足の根本原因
 受入テスト時間不足の原因は、プロジェクト終了時の振り返りが形骸化しており、次のプロジェクトのリスク評価に必要な情報が蓄積されていないことに起因していた。
 この背景には、スケジュール設計時の納期を優先する文化や、振り返り活動の成果を評価する仕組みの欠如があった。
2)運用機能不備の根本原因
 運用機能不備の原因は、システム要件の収集時期が利用者業務の繁忙期と重なったことで、十分なヒアリング時間を確保できなかったことにあった。
 これは、業務繁忙期をスケジュールに反映するプロセスになっていなかったことが原因であった。また、短時間で効率的に要件収集する必要があった。
3)要員不足の根本原因
 リリース作業時の要員不足が発覚した原因は、作業工数の見積もりに必要な過去の実績データ不足し、特に異常系対応の工数が、適切に記録されていなかったことにあった。プロジェクト管理ツールに実績を記録するルールとなっているが、記録用のフォーマットに、正常系・異常系を区別する項目がなく、担当者によって記録内容のばらつきがあった。

3.2.再発防止策

1)振り返り活動の定着化
 振り返り活動の成果をリスク回避策として文書化し、全体ミーティングに発表するように義務付けることにした。顕在化したリスクによる影響が小さかった事象については、記録を簡略化するなど、現場への文書化時の負担を軽減する工夫を行った。
2)繁忙期を考慮した計画
 要件収集の計画時に利用者の繁忙期を考慮するよう、計画プロセスを変更した。具体的には、利用者業務の年間スケジュールを事前に把握し、繁忙期を避けた要件収集スケジュールを策定するようにした。また、オンラインヒアリングツールを活用することで、利用者から短時間で効率的に意見を収集する工夫も行った。
 さらに、利用者部門・運用部門・開発部門での、定期的な打ち合わせの場を設定した。これは、普段から課題共有を行うことで、要件定義プロセスをスリム化する狙いがあった。
3)作業記録の品質と工数見積もりの精度向上
 プロジェクト管理ツールにおける記録フォーマットを見直し、正常系・異常系の区別を明確化し、異常系対応のデータ蓄積を可能した。
 また、全てのタスクに優先順位を設定することで、緊急対応時のリソース配分を明確にした。さらに、工数見積もりには、過去データを活用したシミュレーションを行うことで、異常対応を含む全体工数を正確に見積もるようにした。

 これらの施策によって、リリースの検証及び受入れの改善を行った。今後も継続的な改善活動を行い、サービス品質の向上に努める。

(1193文字)

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

コメント