プロジェクトマネージャ試験の練習論文（１）
PCのファイルを整理をしていたら去年(2019年)受験したプロジェクトマネージャ試験（PM）の午後2試験（論述）対策で試験前に練習で書いた論文が出てきましたのでここで上げたいと思います。
今読み返すと定性的な（或いは定量的な）視点が欠けているなどPMの論文としては至らない内容だと思いますが、曲がりなりにもYuubariは論文試験があるプロジェクトマネージャ試験（PM）、ITサービスマネージャ試験（SM）を2019年に初受験で合格しているので、PM受験者の方に何かの参考になればと思い上げてみました。
問題文はこちら
（注意）
・Yuubariが2019年の本試験のときに書いた論文（いわゆる復元論文）ではありません。あくまで本試験前に練習で書いた論文の一つです。
・内容的に至らない点は多々あるかと思いますがご容赦ください。「このレベルで合格できる」とは思わないでいたほうが良いかも。
・午後2試験（論述）の試験時間は2時間ですが、記述スピードが速いPCで作成したので１時間半以内に書きました。
・色を変えた部分は問題文で記載されている状況を充足するために書いた部分になります。
-----------------------------------------------------------------------------------------------
１．私が携わったプロジェクト
１－１．プロジェクトの目標
私は製造業を営むT社のシステム部に所属している。当社では経理業務においてユーザが自ら開発した業務に使うツール（いわゆるエンドユーザコンピューティング＝EUC）の使用が横行しており問題となっていた。
EUCにより作成されたツールはツール作成者が異動や退職などで保守できる人員がいなくなったり、作成されたときやプログラムの改定時の仕様書が残されないのでシステム保守に不都合をきたしていた。そこで経営層はEUCの撤廃を目的として業務で使用しているEUCによるツールをシステム部主導で撤廃したのち、各ツールの機能を統合して再構築するプロジェクトを発足した。
開発期間は今年（2019年）の１月から６月まで。６月１日よりEUCの使用を完全に停止させ、再構築したシステム（新システムという）で業務を開始する。
経営層からシステム部に対し以下２点の目標を厳命された。
・今年６月中に予定されている外部の査察までに間に合うよう納期は確実に守ること
・新システム導入による業務への影響を避けるため正しく業務プロセスを新システムに反映させること
１－１．プロジェクトの目標
私は製造業を営むT社のシステム部に所属している。当社では経理業務においてユーザが自ら開発した業務に使うツール（いわゆるエンドユーザコンピューティング＝EUC）の使用が横行しており問題となっていた。
EUCにより作成されたツールはツール作成者が異動や退職などで保守できる人員がいなくなったり、作成されたときやプログラムの改定時の仕様書が残されないのでシステム保守に不都合をきたしていた。そこで経営層はEUCの撤廃を目的として業務で使用しているEUCによるツールをシステム部主導で撤廃したのち、各ツールの機能を統合して再構築するプロジェクトを発足した。
開発期間は今年（2019年）の１月から６月まで。６月１日よりEUCの使用を完全に停止させ、再構築したシステム（新システムという）で業務を開始する。
経営層からシステム部に対し以下２点の目標を厳命された。
・今年６月中に予定されている外部の査察までに間に合うよう納期は確実に守ること
・新システム導入による業務への影響を避けるため正しく業務プロセスを新システムに反映させること
この２点を遵守することがプロジェクトの成功に不可欠であった。
私はこのプロジェクトのプロジェクトマネージャに任命され、チーム編成と要員管理の運営を担うことになった。
１－２．プロジェクトのチーム編成とその特徴
私は今回のプロジェクトの規模からチーム編成を検討し、チームリーダー兼SEとして１名、プログラム作成チームとして３名、私を含めて計5名のチームを編成した。
チームリーダー兼SEとしては弊社の協力会社でシステム開発経験が豊富なベテランのAさんを起用した。AさんはSEの経歴が長く、ユーザエンドから情報を引き出すのが長けているというのが起用の理由である。
私は今回のプロジェクトの規模からチーム編成を検討し、チームリーダー兼SEとして１名、プログラム作成チームとして３名、私を含めて計5名のチームを編成した。
チームリーダー兼SEとしては弊社の協力会社でシステム開発経験が豊富なベテランのAさんを起用した。AさんはSEの経歴が長く、ユーザエンドから情報を引き出すのが長けているというのが起用の理由である。
２．人間的側面の問題と目標達成を阻害するリスク、問題への対策
２－１．人間的側面の問題
仕様作成フェーズが１月からスタートした。Aさんはエンドユーザである経理部から積極的にEUCにまつわる情報収集を開始した。１月にこのプロジェクトが開始されたばかりの際はAさんの表情は明るくはつらつとしていたのに2月に入る頃にはAさんの活気が薄れているように見えた。またAさんの作成した仕様書はプログラム作成チームに渡される前にシステム部内や業務担当者との週１回のレビューで検討されるのだが、レビューにおいて関係者からAさんの作成した仕様書の見直しの指摘数が想定より多いことに私は懸念を感じた。
私はAさんと個別に話を聞く場を持ち仕様作成が軌道に乗らない原因を確認した。
Aさんによると、仕様書作成のために経理部にヒアリングを行う中で困難を感じていると言う。そのため、最近はプロジェクト自体に対するモチベーションも低下しているとのことであった。
具体的には経理部で使用されているEUCのツールには仕様書が残されていないため、使用しているユーザからできるだけ具体的にそのツールがどう使用されているかヒアリングし新たに仕様書に起こさないといけないのだが、経理部がヒアリングに対して非協力的だと言うことであった。経理部としては現行のEUCで業務ができているのに再構築する利点を感じておらず、当社経理業務の知識が不足しているAさんのヒアリングに時間を取られて自分の業務が停滞されるのを嫌っていると私は感じた。
その状況が続きAさんのモチベーションが下がり、成果物である仕様書の品質が低くなっていると私は分析した。
Aさんによると、仕様書作成のために経理部にヒアリングを行う中で困難を感じていると言う。そのため、最近はプロジェクト自体に対するモチベーションも低下しているとのことであった。
具体的には経理部で使用されているEUCのツールには仕様書が残されていないため、使用しているユーザからできるだけ具体的にそのツールがどう使用されているかヒアリングし新たに仕様書に起こさないといけないのだが、経理部がヒアリングに対して非協力的だと言うことであった。経理部としては現行のEUCで業務ができているのに再構築する利点を感じておらず、当社経理業務の知識が不足しているAさんのヒアリングに時間を取られて自分の業務が停滞されるのを嫌っていると私は感じた。
その状況が続きAさんのモチベーションが下がり、成果物である仕様書の品質が低くなっていると私は分析した。
２－２．プロジェクト目標達成を阻害するリスク
この状況を放置すると、上層部から厳命されている２つの目標を達成できないと私は考えた。
仕様が十分に業務プロセスを反映していないことによるユーザ受け入れ工程からの手戻りにより開発の遅れのリスクは十分にあり得る状況だった。
また、ユーザ側も仕様書レビューに非協力的なところも散見され、業務内容が十分に反映されていないシステムが出来上がるリスクもあった。
この状況を放置すると、上層部から厳命されている２つの目標を達成できないと私は考えた。
仕様が十分に業務プロセスを反映していないことによるユーザ受け入れ工程からの手戻りにより開発の遅れのリスクは十分にあり得る状況だった。
また、ユーザ側も仕様書レビューに非協力的なところも散見され、業務内容が十分に反映されていないシステムが出来上がるリスクもあった。
２－３．人間的側面の問題への対応
私はユーザ部門である経理部の部長にこの状況を伝え、協力を求めた。経理部部長としてはEUCの撤廃と新システム導入に対する意義についてはプロジェクト発足当初より理解を示していたが、経理部課員が本プロジェクトに消極的であることは把握していなかった。
そこで私は以下２点について申し入れをした。
・経理部部長として改めて経理部課員に今回のプロジェクトの意義を説き、できるだけシステム部のヒアリングや仕様書レビューに協力するよう指示してもらう
・作成される仕様書の成果物（仕様定義書）については完成責任について経理部にも負ってもらう。
経理部部長はこの申し入れを受け入れた。
私はユーザ部門である経理部の部長にこの状況を伝え、協力を求めた。経理部部長としてはEUCの撤廃と新システム導入に対する意義についてはプロジェクト発足当初より理解を示していたが、経理部課員が本プロジェクトに消極的であることは把握していなかった。
そこで私は以下２点について申し入れをした。
・経理部部長として改めて経理部課員に今回のプロジェクトの意義を説き、できるだけシステム部のヒアリングや仕様書レビューに協力するよう指示してもらう
・作成される仕様書の成果物（仕様定義書）については完成責任について経理部にも負ってもらう。
経理部部長はこの申し入れを受け入れた。
３．私の行った対策の評価、課題および今後の改善点
３－１．対策の評価
経理部長は早速私の申し入れを受け入れたあと、経理部内の会議で課員に本プロジェクトの意義を説いてくれた。
その後、私はプロジェクトの進捗とAさんの様子を見守った。２月初頭に経理部長がその対応をしてくれて以来、徐々にAさんの表情に活気が戻り、仕様書のレビューにおいては多発していたユーザからの指摘が半分以下に減りレビュー指摘数は標準的な数値に推移した。
Aさんに話を聞くと「経理部も忙しい中でヒアリングに協力的になってくれるようになり、仕様の作成もだいぶ捗るようになった」という意見を寄せてくれた。
結果として、その後特に開発上の問題は発生せず予定通り６月初頭に新システムが無事本稼働した。
この結果から私の取った対策は評価ができると言えよう。
３－２．認識した課題
今回課題としたいのはステークホルダーのモチベーションの把握が当初不足していた点である。ベテランのAさんのヒアリング能力と仕様書作成のスキルは過去の経歴やともに業務を行った経験で把握していたが、Aさんと協力してプロジェクトを進めるべき経理部の課員の意識について把握が不足していたため、当初Aさんの意欲を低下させ、成果物の品質が低くなる事態を招いてしまった。
３－３．今後の改善点
今後は自分のチーム内の人員の意欲だけでなく関係する部署の意欲もプロジェクト開始当初に把握し、可能であれば問題が顕在化する前に手を打ち、チーム内でモチベーションを低下させるような原因を事前に解消していきたい。
以上
-----------------------------------------------------------------------------------------------
読むとおわかりかと思いますが、全然大したこと書いてないです(＊ﾟ◇ﾟ)
こんな大したことない論文しか書けないYuubariですが、設問で問われていることを漏らさないようにしつつ論旨に矛盾点や重大な見落としが無いか確認しながら慎重に骨子を作り、制限時間（2時間）以内に必死に書いて規定字数をクリアするには大変でした。
ちなみにEUCの撤廃と再開発に関しては実際に業務で経験したこともあったので、PM試験の論文ネタのひとつとしてストックしていました。
ほかにもサプライヤ管理ではオフショア開発の経験もあるので、そのあたりは開発経験の浅いYuubariの貴重な論文ネタとしていつでも使用できる状態にしていました。
ほかにもサプライヤ管理ではオフショア開発の経験もあるので、そのあたりは開発経験の浅いYuubariの貴重な論文ネタとしていつでも使用できる状態にしていました。
とにかく手書きで2時間以内に規定字数を埋めるだけでも大変なのですが、論述を開始する前の骨子作成であまり時間を使いすぎると字数不足で大幅減点されますのでできれば短時間で骨子を作る練習もしておいたほうがよいかと思います。
そういう意味でも自分の経験から論文ネタをすっと出せれば骨子作成の時間短縮も可能になりますし、論文自体に迫真性が出ます。
また選択する論文テーマの選択ですが、みなさん同じかと思いますが要員管理はPMの論文としては比較的書きやすいテーマかと思います。
品質管理や開発コストがテーマであったら正直言ってYuubariに合格水準の論文を書くことは難しいと思います。
テーマ別にどれくらい論文ネタを棚卸できるかは完全に経験の差ですね。
品質管理や開発コストがテーマであったら正直言ってYuubariに合格水準の論文を書くことは難しいと思います。
テーマ別にどれくらい論文ネタを棚卸できるかは完全に経験の差ですね。
ある程度ヤマを張って得意なテーマで勝負するためにも得意分野の各テーマで使用できる論文ネタをきちんと棚卸ししてすぐに論文に組み込めるように用意しておくのは重要かと思います。
