- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
プロジェクトマネージャ試験の午後Ⅱの対策として、自分が実際に練習用に作成した小論文を紹介します。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
解答例
設問ア
1.プロジェクトの概要と問題の兆候
1.1.プロジェクトの概要
私が担当するプロジェクトは、インターネットサービスプロバイダであるA社向けの「法人顧客向けプロモーションメール配信管理システム(以下、A社システム)」の開発プロジェクトである。
プロジェクトの期間は、要求分析から本番稼動まで4ヶ月、システム開発に掛かる工数は160人月である。
プロジェクトの体制は次の通り。
(1)プロジェクトオフィス
A社法人営業企画部(プロジェクトオーナーであるB部長を含む5名)と私
(2)Aシステム利用部門
A社第一~第三法人営業部総勢60名、各部門ごとに調整役として2名ずつアサイン
(3)A社情報システム部
Aシステムが接続する顧客システム担当部門、顧客システムに関する問合せ・調整窓口として2名アサイン
(4)当社開発チーム
ユーザインターフェース開発、メール配信バッチ処理開発の計2チーム、総勢20名
1.2.遂行中に察知した問題の兆候
プロジェクト遂行中に察知した問題の兆候は、プロジェクトメンバーの会議出席率の低下である。
具体的には、開発チーム間で週次で行っている進捗会議へのバッチ処理開発チームの出席率が、製造工程に入ってから半減した。
詳細設計工程の期間中もバッチ処理開発チームのリーダーが会議に出席できないことはあったが、その場合は必ず別のメンバーが会議に参加していた。しかし、製造工程に入ってからは代替メンバーの出席もないことが多くなり、事前の連絡なしに欠席するケースも目立つようになっていた。
(637文字)
設問イ
2.察知した兆候に対する調査と発展する問題に対する対策
2.1.問題の兆候や出現の背景に関する調査内容
前述した兆候を受けて、会議に出られないことからバッチ処理の製造工程に何らかのトラブルが起こっている可能性を疑い、進捗状況、メンバーの稼動状況、不具合の状況を確認することにした。
具体的には、作業スケジュール表から進捗に遅れが出ているタスクがないか、勤務管理表からプロジェクトメンバー稼働減っていないか、もしくは急増していないか、不具合一覧から不具合が急増していないか、などドキュメントベースの確認を行った。
また、バッチ処理開発チームのリーダーおよびメンバーのそれぞれに聞き取り調査を行い、プロジェクトメンバーに不平・不満がでていないかの確認を行った。
その結果、進捗や不具合の摘出状況は予定通りであったが、A社情報システム部からの問合せが製造工程に入ってから多発しており、その割り込みを吸収するための残業によってメンバーの稼動が急上昇しており、会議への出席ができないでいることが判明した。
2.2.静観した場合の問題とその根拠
現状を静観した場合に、以下の理由により問題が拡大すると判断した。
(1)手戻りによる進捗の遅れやコスト増
会議を通して伝えるべき重要な指示事項が、バッチ処理開発メンバーへ伝わらないことにより、仕様変更に関する決定事項の伝達が遅れる可能性がある。また、バッチ処理とユーザインターフェースの両方に影響する不具合を発見した場合に、お互いの情報伝達が遅れる可能性もある。
(2)メンバーが高稼動状態のままでいることにより、生産性が悪化する。
例えば、体調不良のプロジェクトメンバーが出ることによって、メンバー交代をした場合、交代前のメンバー並みの生産性を最初から求めるには無理がある。プロジェクトメンバーの交代がない場合であっても、モチベーション低下による生産性低下の可能性がある。
2.3.実施した対応策
バッチ処理開発チームの負荷増の原因が、A社情報システム部からの問合せによるものであったため、A社と当社間のコミュニケーションルールの見直しを行った。具体的には、以下の二つのルールを追加した。
(1)情報システム部からの問合せは一旦プロジェクトオフィスで受け、プロジェクトオフィス内で回答できない、かつ緊急の問合せについては開発チームに対応を依頼する。
(2)各チームの担当者は、問合せなどの割り込み作業の状況を記録する。また、各チームが記録する割り込み発生件数をA社との週次の定例会の場で確認し、コミュニケーションルールのさらなる見直しを行うこととを、プロジェクトオフィス内で合意した。
(1,095文字)
設問ウ
3.対策の実施結果に対する評価と今後の課題
3.1.対応策実施結果に対する評価
情報システム部からの問い合わせをプロジェクトオフィスで受けたことにより、バッチ処理開発チームへ行っていた問合せが、概ねA社内で解決できることが判明した。具体的には、バッチ処理に関する問い合わせの90%以上が、バッチ処理開発チームと法人営業企画部が共有している設計書を見ることで知ることができる内容であった。
そこで、バッチ処理開発チームで作成した仕様書などの成果物を、情報システム部のファイルサーバに毎日コピーするようにした。さらに、情報システム部は問い合わせの前に、この成果物を確認してから問い合わせをしてもらうようにしてもらった。
情報システム部からの問い合わせをプロジェクトオフィスで受けるようにしたことで、バッチ処理開発チームへの問い合わせの90%は削減された結果、バッチ処理開発チームへの負荷は次第に減少し、対策実施後1週間で通常の負荷状況に戻り会議への出席率も改善した。
さらに、情報システム部門との情報共有の仕方を改善したことにより、プロジェクトオフィスへの問い合わせ事態も30%削減することができた。
その後、更なる負荷増の原因になる割り込みは発生せず、ひとりの脱落者も出さずに予定通りに本番稼動を迎えることができたことは、今回の対策がひとつの要因となったと評価している。
3.2.今後の改善課題
今回、問題の兆候を察知してからの対応となったが、今後はこういった問題が発生しないようにするため、ステークホルダ間のコミュニケーションルールを決める際は、情報の方向や情報量を意識して設定すべきと考えた。
(689文字)
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
コメント