情報処理技術者試験のプロジェクトマネージャ区分、２連敗中のへっぽこ受験生の管理人です。
さて、本日は・・・
待ちに待っていた・・・
という訳ではありませんが・・・
２０２１年度秋のプロジェクトマネージャの試験日でした。
まず、朝起きると・・・
試験会場に行く気がしない・・・
午前１は、春に免除権を獲得していたので、午前２からだったのですが・・・
兎に角、気分が乗らず、直前までは、欠席しようとか考えていましたが・・・
よくよく考えるとお金が勿体無いので、やむを得ず受けに行くことにしました。
ということで、忘備録として、自己採点の結果を掲載しておきます。
午前２
- １：ウ 〇
- ２：エ 〇
- ３：ア 〇
- ４：ウ 〇
- ５：ウ 〇
- ６：ア 〇
- ７：ア 〇
- ８：ウ 〇
- ９：ウ × 正解は イ
- １０：ア × 正解は イ
- １１：ウ 〇
- １２：ウ 〇
- １３：イ 〇
- １４：ウ × 正解は イ
- １５：エ × 正解は ウ
- １６：イ 〇
- １７：エ 〇
- １８：ウ 〇
- １９：ウ 〇
- ２０：ウ 〇
- ２１：ア △
- ２２：ウ △
- ２３：ア 〇
- ２４：イ 〇
- ２５：イ 〇
ということで、△と×を除外すると・・・
２０／２５＝８０点という自己採点となりました。
初見の問題もいくつかありましたが、過去問をやっていれば対応できる問題でしたので、例年よりは比較的難易度が低かったと思います。
公式HPに正式回答がでましたので、再度採点してみるおと・・・
２１／２５＝８４点でした。
鬼門の午後１
午後１は、やはり鬼門でした。
問１と問２を選択しまいたが・・・
正直これが失敗だったと思います。
問１をやり始めてから、失敗したと感じたのですが・・・
時間的に、設問を変更する余裕は既になく、痛恨の極みでした。
問３は、まだ読んでいませんが、おそらく問１よりも簡単だったのではと思います。
問１
１－１：システム開発に伴う初期投資を抑える為。（６／７点）
１－２：顧客のニーズや他社動向の急激な変化に迅速な対応を要する環境。 （６／７点）
１－３：採用する技術を迅速に決定することが可能な為。（４／７点）
２－１：多様な技術の中から仮説と検証を繰り返して採用する技術を決定する方法。（５／７点）
２－２：商品開発や顧客の開拓に必要なDXに柔軟に対応する為。（４／７点）
３－１ーａ：予防 × 正解は 回避 （０／２点）
３－１ーｂ：予想損害額に発生確率を乗じた額 × 正解は リスク許容度 （０／２点）言ってる事は同じなので部分点は欲しい
３－１ーｃ：強化 （２／２点）
３－１－ｄ：転稼 痛恨の漢字ミス 正解は 転嫁 （１／２点）部分点は欲しい
３－２：アジャイル手法により事業部とシステム部が一体となって開発する方針。（３／７点）
かなり甘めな自己採点で・・・
３１／５０点
だったら良いなという感じです。
問２
１：開発と改修の違いを明確にしリスクを特定し施策の優先順位を付ける為。（２／８点）全く分からん
２－１：施策ごとのCS向上の予測値。 （６／７点）
２－１：CSWGの活動予算と効果が出るまでの期間。 （５／７点）
２－３：状況の変化に適応して新たな施策を迅速に展開できる為。 （５／７点）
３－１：改修する機能に精通したメンバでチームを形成する。 （４／７点）
３－２：現状の正確性と処理能力を維持できること。 （７／７点）
３－３：CS調査の結果で高評価の割合の増加率と予測値の比較結果。（２／７点）
こちらもかなり甘めに採点して
３１／５０点
だったら良いなという感じです。
午後１トータルで・・・
６２／１００点ですので・・・
甘めに採点してもギリギリ通過できる・・・かもしれないという状況ですので・・・
正直かなり危ない状況です。
午後１については、昨年よりも難易度が高かったと個人的には感じました。
午後２の論文はそれなりに昨年よりも頑張って書ききったので、なんとか午後１を通過して・・・
論文採点に辿り着いて欲しいですね。
午後１通過の２年間の免除権（試験区分別で良いから）も設定して欲しいと切に願うところです。
また、午後１はやはり時間が厳しいですね。
正誤はともかくとして、兎に角、回答がパッと思いつかず、そこで止まってしまったら・・・
焦燥感に襲われ、思考回路が停止し・・・
回答が出来なくなるという悪循環となります。
かなりの量の過去問を解き、回答のフレーズを頭に入れておいたつもりでしたが・・・
今回の午後１では、あまり役に立たなかった気がします。
やみくもに過去問を解くのではなく、もっと確実に点数が取れる勉強方法に抜本的に変える必要がありそうです。
また、あと３０分あれば、ゆっくり設問を見直す時間も取れると思うのですが・・・
もともと管理人は、文章を読むのも書くのも早くありまえせん。
ですので、この様に回答スピードが要求される試験は、一定のレベルに知識や技術が到達しているかを測るテストには向いていないと思うのですよ。
ゆっくり時間をかけて考えぬいた結果、落ちるのならまだしも・・・
時間が足りずに、ゆっくり考えたり、見直しもできない様な試験のやり方は如何なものかと個人的には思います。
2021/10/11追記
ネットの回答例をチラホラ見ていると・・・
どうも６割届かない可能性が大きい気がしてきてかなり凹んだ・・・
それなりに時間も掛けてきたので、午後１で落とされるのはかなり辛い。
やはり設問選択の失敗で焦り、焦燥感により冷静に考えて問題を解けなかったことが一つの敗因だと思えます。
午後２
午後２の論文は品質管理関連がでると思ったのですが・・・
アテが外れてかなり焦りました。
結局、２時間ギリギリ使ってなんとか文字数を埋めた訳ですが・・・
殆ど読み直しもできませんでした・・・
しかし、昨年の失敗をなんとか活かして、ちょっとはマシな論文を書けたのではないかと自己評価しています。
設問ア
アー１ プロジェクトの特徴
X市は人口１０万人規模の自治体であり国が推進する自治体DXのガイドラインに沿い窓口手続きの電子申請システム（以下「本案件」という。）の導入を決定した。
全工程一括請負契約であり、外部設計までを委任契約とし、確定した条件に基づき、コストを算出し別途請負契約を締結するとう一般的な手法と異なる。
入札に参加する企業は、仕様書などの得られる情報から予備費を含めた全てのコストを積算する必要があり、見込みが甘いと赤字案件となるリスクがある。
A社は、入札の結果、本案件を受託し、私がプロジェクトマネージャとして本案件をマネジメントすることとなった。
工期は８カ月、工数は８０人月、契約額は５千万円であり、類似案件と比較すると４カ月ほど工期が短い。
なお、本案件のサービス開始時期は決まっており納期の遅延が許されないことが特徴である。
アー２ プロジェクトの目標
本案件は、各種窓口手続きの電子申請システムとX市基幹系システムとの連携システムの開発が目的であるが、Ｘ市幹部より電子申請システムについては、クラウドシステムの利用により原則としてカスタマイズをせずに、開発、運用、保守コストを軽減することが指示されている。
アー３ スケジュール管理の概要
スケジュール管理については、全ての要素をWBSに組み込み、各WPのアクティビティを５日以内になるように設定した。
また、アーンドバリューマネジメントにより、週次で、CPIとSPIのモニタリングして進捗管理を実施することとした。
設問イ
イー１ 遅延を生じさせると判断した進捗差異の状況と根拠
本案件は、X市より一般の市民がスマートフォンやパソコンで利用する為に、画面の見やすさや高い操作性といった定性的品質である高いユーザビリティが要求されている。
このため、要件定義において、X市とA社の齟齬が発生しないように、要件定義工程を慎重に進めることとし、類似案件よりも１週間多めに設定した。
しかし、要件定義工程の終了予定の１週間前に、ＳＰＩとＣＰＩを確認したところ、当初の予定値よりも下回っており、要件定義チームの残業時間も右肩上がりで上昇していることが分かった。
これらの事から私は、納期及びコストに重大な影響を及ぼすリスクがあると判断し次の対策を取った。
ブログランキングにご協力ください！
イー２ 対策とばんかい策
対策を取るには、原因を把握する必要がある。
私は、要件定義チームのリーダーとX市の契約窓口である情報部門にヒアリング調査を実施した。
調査の結果、本案件は、X市幹部のトップダウンで決定された事項であり、利用部門である複数の窓口部門とのコンセンサスが十分にとれておらず、X市幹部の「電子申請システムについてはクラウド利用によりカスタマイズをせず開発、運用、保守コストを軽減するという原則」が周知徹底されていないことが分かった。
また、要件定義工程において、複数の窓口部門が画面の見やすさや高い操作性といった定性的品質について、客観的判断基準が無く、要求の膨張、スコープの肥大化と言える状況が発生していることが分かった。
この為、私は、A社の社長に「X市の幹部から利用部門である複数の窓口部門に対して、電子申請システムはクラウド利用によりカスタマイズせず開発、運用、保守コストを軽減するという原則」を改めて周知徹底してもらうことを依頼して実施した。
また、画面の見やすさや高い操作性といった客観的基準が無い定性的品質管理については、Ｘ市とＡ社によるワークショップを開催し、ガイドラインを策定することとした。
さらに、成果物が当該ガイドラインに合致していれば、品質が確保されていると判断することで合意した。
ばんかい策については、まずクラッシングにより要員の増加をPMOに依頼して確保した。
なお、スケジュールに余裕が無い事から、自治体システムの基幹系システムの開発経験があることを条件とした。
次に、ファストトラッキングにより、X市基幹系システムとの連携システムについては、仕様か確定したコンポーネントから順次開発工程に入ることとした。
何故なら、電子申請システムと連携するシステムについては、手続毎にコンポーネントが分割されており、仕様が確定したものから先行して開発することが可能なためである。
なお、進捗が遅延していること、上記の対応策とばんかい策について、プロジェクトーナーに説明し、承認を得た。
設問ウ
ウー１ 対応策とばんかい策の実施状況及び評価
X氏幹部により改めて利用部門である複数の窓口部門に対して、電子申請システムについては、クラウド利用によりカスタマイズせず、開発、運用、保守コストを軽減することを周知徹底、及び、画面の見やすさや高い操作性といった客観的基準がない定性的品質について、ガイドラインを策定しなかった場合を想定すると、要件定義工程が予定のスケジュールで終了することができず、次工程以降のスケジュールや品質に大きく影響を与え、納期の遅延や品質低下、コストの増大といったリスクが顕在化していた。
ばんかい策については、対応策が有効に機能し、発動する事は無かったが、結果的に要件定義工程に設定していたスケジュールバッファ及び予備費内で対応することができたため、対応策とばんかい策は成功であったと判断する。
また、本案件はX市から高い評価を得ており、次年度以降の対象手続きの拡大について、随意契約でと打診があった。このことから顧客との信頼関係の樹立にも貢献できたと判断する。
ウー２ 今後の改善策
全工程一括契約の場合は、顧客の対応よっては、本案件の様に要件定義が確定できないというリスクがある。
本来であれば、要件定義工程は、委任契約とし確定責任は、発注者側としたいところであるが、A社の受託する自治体システムの多くは、まだまだ全工程一括請負契約であるのが実状である。
このため、私は、本案件の事例をPMOに説明し、全工程一括請負契約の場合に要件定義工程をスムーズに進めるためのノウハウの蓄積と解決技法の登録を依頼して、採用された。（以上）
※なお、文字数的には、これで２４００文字でした。
答案用紙的には・・・
設問ア：見開き１ページ目の残り２行まで
設問イ：見開き２ページ目の残り５行まで
設問ウ：見開き１ページ目の残り１行まで
でした。
まとめ
午後１と論文については、若干実際の記載と異なるところがあると思いますが、概ねこんな感じで回答しました。
午後２については【品質管理とリスク管理】を想定して論文を考えていましたが・・・
ちょっとアテが外れてしまいました。
しかし、設問２のスケジュール管理については・・・
スケジュールに関するリスク管理とも取れる問題でしたので、リスク管理で想定していた論文を元になんとか書き上げる事ができたという感じです。
午後２については、２時間という限られた時間の中で、現状での管理人の実力は、ほぼ発揮できたと考えていますので・・・
これで、どのような判定・評価になるのか楽しみでもあります。
しかし、今回は、鬼門の午後１の難易度が管理人的には難しかったので・・・
午後１で不合格となる可能性十分にあります。
なんとか、ギリギリでも良いので、午後１は通過して午後２の採点までは行って欲しいとです。
コメント