プロマネ午後Ⅱ論文の書き方がわからない人へ|一発で合格した実務経験者のサンプル解答【平成30年度:問2】

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

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

問題文および設問

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

問題文

問2 システム開発プロジェクトにおける本稼働間近で発見された問題への対応について

 プロジェクトマネージャ(PM)には、システム開発プロジェクトで発生する問題を迅速に把握し、適切な解決策を立案、実施することによって、システムを本稼働に導くことが求められる。しかし、問題の状況によっては暫定的な稼働とせざるを得ないこともある。
 システムの本稼働間近では、開発者によるシステム適格性確認テストや発注者によるシステム受入れテストなどが実施される。この段階で、機能面、性能面、業務運用面などについての問題が発見され、予定された稼働日までに解決が困難なことがある。しかし、経営上や業務上の制約から、予定された稼働日の延期が難しい場合、暫定的な稼働で対応することになる。
 このように、本稼働間近で問題が発見され、予定された稼働日までに解決が困難な場合、PMは、まずは、利用部門や運用部門などの関係部門とともに問題の状況を把握し、影響などを分析する。次に、システム機能の代替手段、システム利用時の制限、運用ルールの一時的な変更などを含めて、問題に対する当面の対応策を関係部門と調整し、合意を得ながら立案、実施して暫定的な稼働を迎える。

 あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴、本稼働間近で発見され、予定された稼働日までに解決することが困難であった問題、及び困難と判断した理由について、800字以内で述べよ。

設問イ

設問アで述べた問題の状況をどのように把握し、影響などをどのように分析したか。また、暫定的な稼働を迎えるために立案した問題に対する当面の対応策は何か。関係部門との調整や合意の内容を含めて、800字以上1,600字以内で具体的に述べよ。

設問ウ

設問イで述べた対応策の実施状況と評価、及び今後の改善点について600字以上1,200字以内で具体的に述べよ。

解答例

設問ア

1.プロジェクト概要と本稼働間近に発見した問題

1.1.プロジェクト概要

 私が担当したプロジェクトは、全国数百店舗の小売業A社における基幹POSシステムの刷新である。私は、受注側のプロジェクトマネージャとして、参画した。旧システムの老朽化対応と機能強化が、プロジェクトの目的であった。プロジェクト体制は発注者の関係部署と連携して進めた。最大の特徴であり制約は、稼働日が4月1日と厳格に定められていた点である。これは新年度の事業計画遂行に新システムが不可欠であり、経営層から稼働延期は認められないと強く要請されていたためである。また、全店舗一斉切替方式での導入であった。

1.2.本稼働間近で発見した問題

 本稼働予定日の3週間前の利用者による受入テスト(UAT)において、特定の複雑な割引を複数組み合わせた場合に、POSレジでの会計処理で著しい性能劣化が発生する問題が発生した。具体的には、応答時間が大幅に遅延し、タイムアウトして会計処理が完了しないケースがあった。この問題は、高負荷を想定したシナリオテストで初めて顕在化した。
 この問題は、以下の理由から、予定された稼働日までに根本的な解決することは困難と判断した。
1)時間的な要因
 性能ボトルネックの根本改修と、その後の十分な品質保証のための再テストには最低でも6週間を要すると試算された。問題発覚から稼働日まで残り3週間しかなく、根本解決に必要な期間を確保することは物理的に不可能であった。
2)経営及び業務上の要因
 A社経営層から、事業計画上の理由により稼働日の延期は絶対に認められないとの極めて強い意向が改めて示された。PMとしては、稼働日遵守が最優先事項であった。

 これらの理由から、稼働日までの根本解決は断念せざるを得ず、暫定的な対応で稼働を迎える方針を検討する必要があった。

(798文字)

設問イ

2.性能問題に対する当面の対応策について

2.1.状況把握と影響分析

1)状況把握
 開発チームでの再現テストで問題の発生条件を調査した結果、データベースの複雑な割引条件判定ロジックが原因であることが判明した。性能劣化が顕著なのは特定の割引の組み合わせパターンであり、全取引の約0.5%とレアケースであることを確認した。
2)影響分析
 店舗運営部へのヒアリングと性能テスト結果を基に業務影響を分析した結果、問題発生時には一部店舗で深刻なレジ待ち時間が発生し、売上機会損失のリスクがあると判断した。これらの分析結果を関係部門(情報システム部、店舗運営部、経理部)へ速やかに報告し、問題の深刻度を共有した。これにより、迅速な意思決定の必要性を示した。

 暫定的な対応策は、以上の結果を踏まえる必要があった。

2.2.当面の対応策の立案

 開発チームリーダー、A社情報システム部担当者、店舗運営部代表者を招集し、緊急対策会議を複数回開催した。会議では、残された時間で実施可能であり、かつ経営要求である納期遵守を最優先とする観点から、以下の対応策案を検討した。
案1)機能制限
 問題が発生する複雑な割引パターンの機能を、一時的に無効化する。
案2)運用回避
 問題が発生する割引適用時は、レジ担当者が手動で計算し、割引額を特定コードで入力する。
案3)インフラ増強
 データベースサーバのスペックを、一時的に増強する。
案4)暫定ツール開発
 手動計算を補助する、簡易ツールを急遽開発する。

 各案の実現可能性/効果/リスク/所要時間を評価した結果、案1と案2を組み合わせを、当面の対応策とした。具体的には、前述の状況把握で判明したレアケースのパターンは、会計時に自動適用できないように設定変更し、該当する割引を適用したい顧客に対しては、レジ担当者が手動で割引額を算出し、POSレジに専用の割引コードを用いて手入力する、というものである。この対応策を選択した理由は、以下の通りである。
・原因となる処理を回避するため、性能問題によるシステム停止リスクを排除可能。
・影響範囲をレアケースに限定することで、手動運用による現場の負荷増加とオペレーションミスリスクを最小限に抑えられる。
・システム改修が設定変更のみで済むため、限られた期間内で実施可能。
 この策により、納期遵守という最大の経営要求に応えつつ、業務影響を許容可能な範囲に留めることを狙った。さらに、パフォーマンス監視ツールによるレスポンスタイムの常時監視体制を構築し、万が一他の要因で性能問題が発生した場合でも早期に検知できるようにすることも決定した。

 なお、インフラ増強(案3)と暫定ツール開発(案4)については、効果の不確実性/残り3週間では間に合わないリスク/品質リスクなどを考慮し、対応を見送った。

2.3.関係部門との調整と合意形成

 立案した当面の対応策について、関係部門との調整と合意形成を進めた。まず、各関係部門に対し、問題状況、影響分析結果、暫定対応策の内容とメリット・デメリットを説明した。特に現場の負担増を懸念する店舗運営部に対しては、影響範囲が限定的であること、手順書や十分なサポート体制を提供すること、そして稼働後早期の恒久対応実施を約束することで理解と協力を求めた。経理部とは手動入力データのチェック体制について、情報システム部とはシステム設定変更手順について合意した。最終的に、これらの調整結果を踏まえ、経営層に対し、稼働延期リスクと暫定対応リスクを比較提示し、納期遵守を最優先する方針での暫定稼働について承認を得た。合意形成においては、各部門の懸念に具体的な対策を示すことで、不安感を軽減するように努めた。

(1593文字)

設問ウ

3.対応策の実施状況、評価、今後の改善点

3.1.対応策の実施状況

 関係部門の合意後、直ちにタスクフォースを結成し、「性能問題となる割引パターンの自動適用無効化」「手動計算手順書・コードの作成配布」「全店舗への周知・教育」「POS監視体制構築」の各タスクを、稼働日までに実施した。手順書の理解や手動計算ミスといった課題は発生したが、タスクフォースで迅速に共有し、簡略版の手順書配布や個別フォロー、日次データチェック体制により、大きな混乱なく対応できた。

3.2.対応策の評価

 暫定対応によりPOSシステムは予定通り4月1日に稼働開始できた。性能問題による停止を回避し、最大の目標である納期遵守を達成したため、暫定稼働は成功と評価する。経営層からは納期遵守を高く評価されたが、手動運用(取引の0.5%未満)による現場負荷増や計算ミスも発生し、暫定対応の限界も認識した。PMとしては、危機下で関係者と協力し稼働に導いた責務は果たせたが、テスト計画やリスク管理の甘さは反省点である。

3.3.今後の改善点

1)恒久対応の確実な実施
 暫定稼働後、直ちに恒久対応計画に着手した。根本原因であるDB割引ロジックの見直しと関連改修、性能テストを実施し、稼働後2.5ヶ月で改修版をリリースして機能制限と手動運用を解除した。性能問題は解消され、システムは安定稼働している。暫定対応の場合、恒久対応の遅延リスクがあるため、計画から完了までのリソース確保と進捗管理が不可欠である。
2)再発防止策の導入
 テスト終盤での重大な問題発覚を防ぐため、以下の対策を導入する。
①テスト計画の改善
 性能要件定義と合意形成を要件定義段階で具体化する。性能テストは結合テスト段階から本番相当の負荷で実施する。これにより、早期に問題を発見し修正対応することで、手戻りコストの増大や今回のようなリスクの高い暫定対応を回避できる。問題解決に必要な時間を確保し、暫定対応リスクを低減する。
②設計レビューの強化
 複雑なDBアクセスや性能影響が大きい機能は、設計段階で専門家レビューを標準化する。早期の課題特定・解決で手戻りや遅延リスクを低減する。
③リスク管理の強化
 性能等の技術的リスクなど、影響度が大きいリスク事象に対しては、コンティンジェンシープラン(代替策、体制等)を事前に準備しておくよう、リスク管理プロセスを強化する。これにより、万一リスクが顕在化した場合の対応時間を短縮する。
3)プロジェクトマネジメントプロセスの改善
 最終段階での問題発見時の、関係部門へのエスカレーション、影響分析、暫定対応要否判断、意思決定プロセスを明確化し、迅速な対応のためコミュニケーション計画を見直す。これにより、限られた時間でも効果的な意思決定を支援する。

(1191文字)

まとめ

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

参考図書

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

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

コメント