dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

『本プロジェクトの目的は、プロジェクトマネージャ試験に合格することである』(2)

 さて。

2022年度のプロジェクトマネージャ試験の変更点

 今年の5月に、こんな文書がIPA掲示されたんですよ。

www.jitec.ipa.go.jp

 情報処理技術者試験は、試験範囲を明示した『試験要項』と、各区分に対して要求される知識、技能を明確化した『シラバス』によって試験内容が規定されるわけですが、よりにもよって私が受験するタイミングで改訂してきたわけです1

変更内容は次のとおりです。

(1)アジャイル型開発プロジェクトの増加、プロジェクトマネジメントに携わる者の業務と役割の変化を踏まえた変更(プロジェクトマネジメントの業務を、特定のプロジェクトマネージャが任命されて担う、チームの一部のメンバーで分担する、又は全メンバーで分担するといった多様な形態を想定)

(2)その他、シラバス用語例などの整理

 IPAのプロジェクトマネジメントに関する認識は、基本的にSIerがやるようなウォータフォールモデルに基づく、どちらかというと古典的なプロジェクトマネジメントのそれだったんですが、今年からアジャイル的なマネジメントについても問うよ、と言い出したわけです。

 冒頭で説明したプロジェクトマネージャの対象者像や役割、技術水準も、この影響を受けて変わっています。

プロジェクトマネジメント業務を単独で又はチームの一員として担う

メンバーの成長とチームの自律的なマネジメントに向けた継続的な改善

メンバーの多様な考えを活用して早期に対応し、変化に適応

プロジェクトチームの自律的な成長を促進

多様な考えを理解して,変化に柔軟に適応

 この辺りは従来の統制を主とし、強いリーダーシップで牽引していくというプロジェクトマネージャ像とは大きく異なっています。むしろ協調、支援を主としたサーバントリーダーシップに近いと言えるでしょう。

 後述しますが、これは実際の問題傾向にも波及してきていて、この考え方にキャッチアップしていかないと、いくらプロジェクトマネージャの経験があったとしても、大きくビハインドを背負うことになってしまいます。

私の蓄積

アジャイルに対する蓄積

 これに対するに私としては、本を買って勉強するなどの対応なしに、『うん、分かった』の一言である程度済んでしまいました。

 というのも、実はこの手の本、自社でウォータフォールでプロジェクトを回していたくせに、結構読み込んでいたんですよ。

 おそらく普通のプロマネさんとはこの点が大きく異なると思うので、私が読んでいたアジャイル関連の本をピックアップして紹介しておきます。

 いずれもアジャイルの文脈におけるプロジェクト運営の方法について記述されており、日本の旧来の上意下達的なプロジェクトマネジメントとは全く異なっています。この辺りを私は割とよく読み込んでいて、アジャイルの空気感がどういうものかを概ね把握していました。

 それどころか、私自身はウォータフォールプロジェクトの中にアジャイルの技術やプラクティスの一部を持ち込んで、プロジェクトを安定化させるなどということを、これらの本が出るかどうかのタイミングで実施していた立場だったので、問われれば答えられる、ぐらいの自信はありました。

アジャイルに対する蓄積

 それだけではなく、非アジャイル、つまりウォータフォールを前提とした書籍の蓄積も、実は相当量あったわけです。

 これはあくまでも一例ですが、プロジェクトマネージャ試験に先立って、実はこんな感じで膨大な蓄積があって。この蓄積が、今般の受験で参考書がたったの1冊で済んだ最大の理由と言えます2

 なので、これを読んでいる方で来年以降プロジェクトマネージャを受験される方は、先程示した教科書類に加えて、アジャイルと非アジャイルの両側面において、面白そうだと思える書籍をそれぞれピックアップして読んでおくと良いでしょう。

 特に、自社で採用していない(有用性を認識していない)が、業界的、世界的には有用なプラクティスが示されている書籍が良いです。そういう書籍を読んでおくと、問題一つ解くときにも、自社の考えに凝り固まることなく、より広い視野で有用とされているプラクティスを参照してより良い正解を書くことができるようになります。

 プロジェクトマネージャ試験は特に自己の経験に自縄自縛されやすい試験なので、上手にアンラーニングしつつ、多様なプラクティス、考え方を選択肢に組み込んでから挑みましょう。

試験準備

午前と午後1

 午前と午後1に関しては特に言うべきことはなく、試験対策本と前述の書籍から知識を付けつつ、過去問を解き、結果を評価する、ただその繰り返しです。

 強いて言うならこの2点でしょうか。

1.午前2対策は、試験学習開始時と終了時に実施するのがオススメ。

 先に紹介した試験対策本だと、午後試験から学習を開始し、午前2は最後に取り組むように推奨していますが、それは当該区分にある程度習熟した下地のある受験者が取るべき戦略だと思っています。

 対象区分に対する理解度が低い場合、語彙が少なすぎて教科書や問題文の読解に支障が出ることも想定され得るので、

  • 学習を始める際、まず語彙を獲得するために午前2をざっと解いていく。
    • 問題文や教科書を読むための基礎知識をつける。
  • 学習の終盤で、最終仕上げとして午前2を解く。
    • 論文等の重い学習で終盤消耗することを避けつつ、単発知識を再度刷り込んでおく。

 私は(どの試験区分であっても)この手法で取り組むことにしています。

2.午後1を解く際には、論理的かつ客観的な解答解説が示されている試験対策本を選ぶ。

 これはどの区分でもそうですが、午後1の問題文から回答に至るまでに適用する論理こそが、論文試験系の午後1を解くために必要な唯一の武器だと言っても過言ではありません。この武器を磨くことができる書籍の選択だけは確実にしましょう。

 その観点で言うと、先に紹介した試験対策本は、私からも太鼓判を押せます。

午後2

 今回、午後2については、私は先に紹介した試験対策本については全く参照しておらず、完全に私のオリジナルのやり方で挑んでいます。

 例によってPCで5本、手書きで5本ぐらい書いたんですが、今回私が意識したのは、

  • プロジェクトという活動には、複数の側面がある。

 ということです。

 午後2対策の文脈で平易に言うと、こういう意味です。

  • ある一つの完結したプロジェクトは、各側面毎に複数の論文に書き下すことができる。

 ここでいう側面は、例えばPMBOKの知識エリアで切り分けたり、プロジェクトに対する関心事で切り出すことができます。

 PMBOKの知識エリアで切り出すなら、例えばこんな感じでプロジェクトを表現することができると思うんですが、

  • スコープ:
    • プロジェクト序盤の要件定義は準委任契約、アジャイルにスコープを探索。
    • 設計以降はスコープクリープを防止するため、変更委員会で保守的に管理。
  • 品質:
    • 設計工程ではレビューの指摘事項密度から設計品質を把握。
    • 一部設計では形式手法を用いて自動検証を実施。
    • 実装工程では単体テスト推進のためTDDを一部導入。
  • コミュニケーション:
    • プロジェクト計画段階でステークホルダ登録簿を作成、洗い出し。
    • 工程横断のステアリングコミッティと、各工程個別の会議体、連携フローを計画。
    • メンバーの意見を取り入れ柔軟にコミュニケーションパス変更に対応。

 これらが実は全て単一のプロジェクトの活動だったりするわけです。

 何が言いたいかと言うと、仮に受験者が1つのプロジェクト経験しか持ち合わせていなかったとしても、そのプロジェクトについてあらゆる側面で説明できれば、複数の論文を苦もなく記述可能なのだ、ということです。

 プロジェクト経験が豊富であれば良いに越したことはないのですが、それは論文中で引き合いに出せるプラクティスや実経験といった、いうなれば引き出しの数に関する話です。

 問題文中で特定の制約がない限りは、論文の題材にするプロジェクトは実は1つ2つあれば十分だったりします。そのプロジェクトについて、問題文中で問われた側面さえ論述できればそれで良いのです。

 実際、私自身は複数の論文を書いていますが、その半分をある単一のプロジェクトを元ネタにして書いていたりします。試験本番ですらこの単一のプロジェクトから書いているのです。

 問題文中で発生し得る制約としては、

  • 対象システムの特性(エンプラ系 or 組み込み系)
  • プロジェクトの攻め度合い(SoR: System of Records or SoE: System of Engagement)
  • プロジェクト体制(ウォータフォール的 or アジャイル)

 この辺りが想定されますが、過去問を見て、問題文中で縛りがありそうだなと思ったら、それに対応したプロジェクト事例を思い出すなり、調べて手元に持っておくとよいでしょう。プロジェクトのストックとしては2、3個あれば良いんじゃないでしょうか。

 一つの事例には複数の側面がある、ということを覚えておいて、単一のプロジェクトを複数の側面から説明、描写できるようにしておきましょう。おそらくそれがプロジェクトマネージャ試験の午後2で効率よく勝つ秘訣です。

 これ以外の事項は、私の論文攻略本に書かれているプラクティスをそのまま使っています。ガッツリ書いてありますので、よろしければ手にとって参照ください。

zenn.dev

 学習時間とかもいつもどおりです。週末の土日午前中に数時間、というのを3ヶ月ほど繰り返した程度です。

 では、本番に行きましょうか。


  1. そういえば、似たようなことがシステム監査技術者試験でもありましたねぇ…。何だろう、こういう試験制度改訂については、私は結構運が悪いようです。
  2. 『勝つべくして勝った』というのはこの辺りの事情もあります。