『本プロジェクトの目的は、プロジェクトマネージャ試験に合格することである』(3)
本試験
IPA試験の受験、果たしてもう何度目でしょうね。
会場
千葉県の某大学です。システム監査技術者、ITストラテジスト、データベーススペシャリストの各試験で訪問しているので、ここに来るのはもう4回目。
午前2
ここはもはや、特に言うべきこともないですね。
過去問で頻出のRACIチャートとかEVMとか、PMに新たに組み込まれたアジャイルの文脈でも、アジャイルマニフェストとかXPとか、過去問やってればだいたいわかるよね、という感じです。
ここまで来たら、いっそ全区分で午前2を免除してほしいぐらいです。
午後1
私が選択したのは問2と問3でしたが、この辺りは今般試験の変更点が浮き彫りになっている問題です。
令和4年度 秋期 プロジェクトマネージャ試験 午後1 問2より抜粋
メンバーの多様な考えを活用して早期に対応し、変化に適応
令和4年度 秋期 プロジェクトマネージャ試験 午後1 問3より抜粋
メンバーの成長とチームの自律的なマネジメントに向けた継続的な改善
それぞれ、試験要項の改訂事項と真っ向対比できるレベルで、明確に反映されています。
統制型のプロジェクト運営だけで、いわゆる剛腕だけでプロジェクトを進めてきたPMには解きづらい問題と言えるでしょう。
ただ、過去問の時点でも、自律的なマネジメントという文脈は結構出ていました。
令和3年度 秋期 プロジェクトマネージャ試験 午後1 問1より抜粋
令和2年度 秋期 プロジェクトマネージャ試験 午後1 問2より抜粋
試験要項に変更があったと言っても、実際の所、試験問題の傾向としては連続しているのがよく分かると思います。過去問への演習は嘘をつかないということの証左で、変更点に向けてあからさまに準備していなくても対応可能だった、というのが実際のところでした。
まぁそういうわけで、私自身は午後1も快調に筆を進めていたのですが、返ってきたスコアを見ると予想より若干低くて。IPA発表の回答とそれほど乖離しているようにも思えず、ちょっと採点者に文句を言いたい気分にはなりました。
午後2
技術士試験の峻厳さには程遠いものの、IPA三大難関の最大の壁は、なんだかんだ言って論文です。
まず問1を見たんですが、
問1 システム開発プロジェクトにおける事業環境の変化への対応について
と書かれていて、ここで若干悩みました。
どちらかと言うと変化への対応性を強く持つべきプロダクト、具体的にはSoEのシステムやエンプラ系のシステムに対して親和性が高く、組込のような深層、低レイヤのシステムに対しては適用しづらいテーマです。
そういう事例を書くこともできたんですが、私が得意としてきたのは組み込み系の話なので、問2のタイトルを確認し、
問2 プロジェクト目標の達成のためのステークホルダとのコミュニケーションについて
これならいけそうだな、と思ったんですが、一つ、ある事に気付いて警戒のレベルを上げました。
それは設問の書き方です。
令和4年度 秋期 プロジェクトマネージャ試験 午後2 問2より抜粋
システム監査技術者以外の他区分について論文答練をしてきた人なら、この設問の書き方の違和感に気づくはずです。
対比してみましょうか。前年度の問2とかどうでしょう。
令和3年度 秋期 プロジェクトマネージャ試験 午後2 問2より抜粋
まだピンときませんかね? では令和3年度問1を、対比箇所を強調して見てみましょうか。
そう。設問ウの書き方が異なっているのです。
システム監査技術者試験を除き、IPA論文試験の設問の定石は、概ねこんな形になっています。
- 設問ア: 与件(対象となるプロジェクト)の説明
- 設問イ: 与件に対して受験者が行った施策、行動の(題意に基づいた)説明
- 設問ウ: 設問イで受験者が行った施策、行動に対する評価、改善点
ところが今年度の問2だけはそうではありません。設問ウにおいて、
”実行段階"において生じた認識の不一致とその原因、及び"実行段階"において認識の不一致を解消するために積極的に行ったコミュニケーション
つまり、設問イと同様、与件に対して受験者が行った施策のさらなる説明を要求しています。
応用力と論理展開を求める設問の変化球
プロジェクトマネージャ試験ほどのレベルの試験でも、論文を事前作成しておき、その論文を本番上で展開してしまう人は結構いるようですが、この手の変化球が来た場合、真っ先にふるい落とされるのはそういう人々です。
そりゃぁそうですよね。定石に従って論文作成するなら、設問ウに相当する中身は評価や改善点であって、施策の第2段階ではないのですから。
私の論文攻略本でも、IPA試験に対しては『論文の事前作成&展開は避けよ!』とはっきり言明しています。これは論文評価ランクを落とす最大の落とし穴なのですが、ここで調子を狂わされた人も結構いるのではないでしょうか。
経験と論文展開力を持つ者の余裕
一方で私はこれを見て、逆に得たりと思いました。
ステークホルダ間の認識齟齬は、私自身のプロジェクト管理経験における最大のテーマの一つで、書くべきことはたくさんあったからです。
あまりにも言うべきことが多かったがゆえに、技術士口頭試験においてすら言及したほどでした。
Q.チームの質問がお客様に伝わらない言葉だったので、それを書き直した、というお話でしたが、具体的な事例を挙げることはできますか？
A.昔のことなので大分忘れていますが…。
開発しているデバイスにはファイルシステムがあって、アプリケーションごとに階層が分かれているんですが、この状態で『カレントフォルダ』という言葉をメンバーが使うことがあって。
チームメンバーは自分の担当アプリケーションが念頭にあって、一意と思い込んでそう言ってしまうんですが、絶対パスで示さないとお客様にはわからないだろう、という話をしたことがありました。
このように、論文試験では、試験に対する取り組みや姿勢によって、初手で決着がついてしまうことが普通にあります。
論文試験において勝利を確実にするのは、事前に論文を書く行為ではなく、自身の経験をその場で形式知化し、文章として説明できる能力なのだということを押さえておきましょう。
論文設計
せっかくなので論文設計も、差し障りがない範囲で残しておきましょうか。
- 第1章 私が携わったプロジェクトについて
- 1.1 概要
- 大手企業向けICチップ形状製品
- 2.5年、20人、約300人月、2億程度のPJ
- 得意先要求仕様への配慮と、工場に量産品書込コードを送った上で、工場で量産させる点に注意が必要
- 1.2 目標
- 1.5年以内に得意先評価用サンプルを提出
- 2.5年後に工場量産品の納品開始
- 1.3 重要ステークホルダと影響
- 得意先仕様管理部署
- 仕様コミュニケーション上の手戻り→サンプルの納期に影響する
- 工場
- 量産品書込コードの遅延→量産遅れにつながる
- 得意先仕様管理部署
- 1.1 概要
- 第2章 計画時の期待値コントロール
- 2.1 期待の内容
- 得意先:
- フル仕様でサンプルが納品されると思っている
- 工場:
- 得意先へのサンプル納品と同時に量産品書込コードが完成すると思っている
- 得意先:
- 2.2 理由
- 得意先:
- 開発リソース上、1年間でフル仕様の実現は困難。
- 仕様齟齬は過去開発でも発生しており、仕様Fixが間に合わないリスクがある
- 工場:
- 得意先側のサンプル評価によってはコード修正が必要→量産品書込コードの納期は変わりえる
- 得意先:
- 2.3 コミュニケーション
- 得意先:
- リリース計画と、各時点の搭載機能の対応表をキックオフ時に説明
- 仕様、認識齟齬による遅延可能性を明言し、リスク認識させた
- 工場
- 予め、量産品書込コード提供時期が未定であると明言
- 量産時の作業について初期段階で明確化し、前倒し実施
- 得意先:
- 2.1 期待の内容
- 第3章 実行段階での認識不一致について
- 3.1 不一致の内容
- 顧客の受け入れ試験における、自社仕様認識との不一致
- 3.2 原因
- 顧客が受け入れ試験を定めるに当たって、他ベンダーの仕様を流用した
- 結果、自社製品と仕様が乖離していたが
- 顧客の仕様理解は大雑把で、仕様乖離を認識していなかった
- 3.3 コミュニケーション
- 自社製品(顧客仕様)と受け入れ試験仕様の乖離をテーブル化するようリーダに指示
- 他ベンダーの仕様とも整合するよう、自身が監修して受け入れ試験仕様を確定させた
- 最終的に各社が共通の受け入れ試験仕様で量産化し、市場投入に成功
- 3.1 不一致の内容
だいたいこんな感じです。
まぁ、書いた結果が全てといえば全てなのですが、一つ言っておいたほうが良いことがあるとすれば。
- プロジェクトの規模に関する情報を除けば、数字は必ずしもMustではない。
ということでしょうか。
納期に関しては1.5年、2.5年などのざっくりとした数字を出してはいますが、やれ試験項目数が何項目あるかとか、コードの規模が何LoCだとか、量産品が何万個なのかとか、そういう細かい数字は一切使っていません。
プロジェクトマネージャ試験の対策本によっては、こういう数値を出すことによってリアリティを出すんだよ、みたいな記述を見かけたりもするのですが、設問で必要な情報を論理立てて十分に説明することさえできれば、細かい数値の明示などは些末事に過ぎません。
- 一般論ではなく自分独自の経験、知見に基づいて
- 設問から要求される、プロジェクトの文脈と、受験者の行動を
- 適切な粒度で、論理的に、ストーリーを立てて説明する
これが論文試験で成すべきことの全てです。来年以降挑まれる方の健闘を祈ります。
さいごに
従前で書いてきたように、私自身はプロジェクトマネージャとしての仕事をするつもりはあまりなくて。
つまりこの試験で勝ち得たロールを実業務で実施することはあまり予定していないのですが、こうしてIPAからプロジェクトマネジメントの有識者である旨のお墨付きをもらったので、
- 組織内でのプロジェクト運営体制に関するチェックやバックアップをしたり
- プロジェクトマネジメントに関わる後進の育成に活かしたり
することができるだろう、と思っています。
また、自身が書いた論文対策本のプラクティスを試す絶好の機会でもあり、この通り効果を立証することもできました。
キャリア途中の置き土産の回収を通して、こんな成果が得られたので、これをご覧の皆様も、プロジェクトマネージャ試験を通し、何らか勝ち取るものを得られれば幸いでございます。
