【未経験者向け】プロジェクトマネージャ試験の午後II論文で使える「定量的表現」について

プロジェクトマネージャ試験

プロジェクトマネージャ試験の午後IIについて、システム開発未経験の方向けに解答で利用できる定量的表現の例をまとめました。論文試験対策の参考にしていただければ幸いです。

本記事は未合格者かつプロジェクトマネジメント未経験者が執筆しております。多くの教材や学習のハウツー本にも書かれておりますが、合格していない人の「これをやると効果的!」という内容はあまり信憑性がありませんので、ご注意ください。

【スケジュールマネジメント】の定量的な表現

プロジェクトの各工程について

まず、各工程について先に定義しておきます。呼び方が会社によって違うかと思いますが、ウォーターフォールモデルの場合は、おおむね以下の工程に分類できます(実際の試験でも以下の名称での表現が多いです)。

プロジェクトの各工程について

  • 計画フェーズ:プロジェクト開始前。「要件のヒアリング」「スコープの定義」「システム化の方針検討」「WBSの作成」「資源の調達」などのPMBOKにおける計画段階で実施する内容が対象となる。
  • 要件定義:プロジェクトスタート後。システムの機能、目的、対象範囲などを決定する。若干計画フェーズと被っているような印象。
  • 外部設計:要件定義の内容を基に、画面などのUIを設計する工程。「基本設計」などとも呼ばれる。
  • 内部設計:外部設計の結果を、実際にプログラミングできるように詳細な設計に落とし込む工程。ユーザーにもクライアントにも見えないシステムの内部の処理を設計する。
  • 製造(プログラミング):設計書を基にして、実際にプログラミングを行う工程。
  • 単体テスト:作成したプログラミングに対して、単体テスト仕様書を利用してテストを行う工程。
  • 結合テスト:各プログラムを統合して連携がうまくいくかをテストする工程。
  • 総合テスト:ユーザーが利用するのと同じ本番環境か、それと同等の環境で行うテストの工程。
  • 運用テスト:実際にユーザーに利用してもらい、要求された機能が満たされているか、操作感に問題がないかを確認してもらうテスト工程。

そして、これらの内システム開発部分にかかる期間については、一般的なウォーターフォールモデルでは以下のようになります。

工程に対するスケジュールの割合

  • 上流工程(要件定義~内部設計):全体の5割程
  • 製造工程(プログラミング):全体の2割程
  • テスト工程(単体~運用テスト):全体の3割程

要件定義~カットオーバーまでの日程例

ここまでの内容を考慮して、1年のプロジェクトを記述するのであれば、下のようにプロジェクトの期間を設定し、論文を書くことができます(私は実際にこんな感じにしています)。

要件定義~カットオーバーまでの日程例

  • 要件定義:4月1日~5月31日
  • 外部設計:6月1日~7月30日
  • 内部設計:8月1日~8月31日
  • 製造(プログラミング):9月1日~11月30日
  • 単体テスト:12月1日~12月31日
  • 結合テスト:1月1日~1月31日
  • 総合テスト:2月1日~2月28日(うるう年なら29日)
  • 運用テスト:3月1日~3月31日

この流れですと、要件定義~内部設計までの上流工程で約41.7%、製造工程で25%、テスト工程で33%。極端な差異は発生していませんし、全て月の区切りで書き出せるので、本番でスラスラと書きやすいです。

スケジュールについては論述する内容によって若干変更しますが、大まかに上のようなスケジュールを決めておいた方が、試験当日に迷う確率が低くなりますのでおすすめです。スケジュールマネジメントの問題では「具体性がある」という評価を得やすいですし、文字数も稼げるようになります。

各工程のフェーズについて詳細を確認したい方は、以下の記事(と、その続きの記事)を確認することをおすすめします。私はシステム開発経験がないので、いい参考になりました。

【品質マネジメント】欠陥指摘密度やレビュー時間はどの程度なら妥当か?

恐らく、システム開発経験がないと、全く見当が付きにくいのがこの部分ではないかと思います。私も「品質マネジメント」は苦手です。

自社の標準などをそのまま利用できる人であれば迷うことはありませんが、経験も会社標準もない場合「具体的・定量的」な表現をできているか、値が適切な範囲になっているか不安になるのではと思います。

そこでプロジェクトマネージャ試験の午後Iや基本情報技術者試験の問題から、レビュー・品質管理の目標値や実績値について、以下の通りまとめました

午後Iで登場する定量的な品質の表現

  • 要件定義の欠陥摘出密度 2件/kstep(平成23年午後I問4)
  • 外部設計のレビュー時間 下限は3分/ページ(平成24年午後I問1)
  • 外部設計のレビューの指摘密度 0.16~0.24件/ページ(平成24年午後I問1)
  • 外部設計の欠陥摘出密度 4件/kstep(平成23年午後I問4)
  • 内部設計のレビュー時間 3時間/kstep(平成21年午後I問4)
  • 内部設計のレビュー時間 3時間/kstep+20%(基本情報 平成25春午後)
  • 内部設計の欠陥摘出密度 4件/kstep±10%(基本情報 平成25春午後)
  • 内部設計の欠陥摘出密度 4件/kstep±30%(平成21年午後I問4)
  • 内部設計の欠陥摘出密度 6件/kstep(平成23年午後I問4)
  • 製造・単体テストの欠陥摘出密度 8件/kstep(平成23年午後I問4)
  • 製造の欠陥摘出密度 6.0件/kstep±10%(基本情報 平成25春午後)
  • 単体テストの欠陥摘出密度 8~12/kstep(平成29年午後I問3)
  • 結合テストのテスト密度 16~24件/kstep(平成22年問1)
  • 結合テストの欠陥摘出密度 2.7~3.3件/kstep(平成22年問1)
  • 結合テストの欠陥摘出密度 2.5件/kstep(平成23年午後I問4)
  • 総合テストの欠陥摘出密度 0.9件/kstep(平成23年午後I問4)

これらの実例を利用するのであれば、欠陥・バグの密度について「○件/kstep」の表現で品質管理を行ったことにすれば、比較的記述しやすく、点数を取りやすいという印象です。

また、実際に件数を記載する際は、上限と下限も記載するようにしましょう。解答例の論文なども見ると、±20~30%あたりを上限・下限としているパターンが多いです。

恐らく、午後IIの対策を行う中で、多くの人は論文の例を読み漁ったり、書き写したりするのではないかと思います。その際に、こういった定量的な表現が解答例で登場するのであれば、メモしておいて、そのまま自分の論文に利用してもいいでしょう。

ちなみに、「ソフトウェア開発データ白書2018-2019」を参考にすると「レビュー指摘件数」をはじめとする膨大な定量的に使える実例が確認できます。が、内容が専門的で、そもそもシステム開発に縁が遠い人では、理解するのに時間がかかるかと思います。当然、論文で使いこなすのはハードルが高めですので、興味がある人は参考にしてもいいですが、あえて読む必要はありません。

【リスクマネジメント】発生確率と影響度

発生確率と影響度については、リスクをどう扱うかによって変化するかと思います。

私の場合、平成21年の午後I問1の本文中に登場するものを利用して、以下のように定義します。

発生確率の定量的表現

  • 発生確率高:0.50以上
  • 発生確率中:0.30以上~0.50未満
  • 発生確率低:0.30未満

正直、平成21年の午後I問1に登場するリスク評価のマトリクスは、そのまま「発生確率」の意味なのか、計算のために用意された数値なのか微妙ですが、サンプルの論文記述の例でも、上記と似通ったものを見ましたのでまず問題はないと考えています。

一方、「影響度」については、プロジェクトの規模によって変わるかと思いますが、私は以下の通りにしています。

影響度の定量的表現

  • 影響度大:1億円以上
  • 影響度中:3000万円以上~1億円未満
  • 影響度低:3000万円未満

これなら発生確率と似た数値なので、暗記も楽です。また、私の書く論文は180百万円(1億8000万円)のプロジェクトなので、だいたいこのくらいの数値なら問題はないかと判断しています。

「論述の対象とするプロジェクトの概要」について

午後IIの論述試験では「論述の対象とするプロジェクトの概要」について簡単な質問に答えるシートがあります。

このシートには

  • ハードウェアの台数
  • 総工数
  • 総費用
  • 開発期間
  • 会社・機関などの規模、システムの利用者数

といった内容について、定量的な記載をする必要があります。

「論述の対象とするプロジェクトの概要」の各項目の書き方については、以下の記事にまとめてありますので、興味がある方は参考にしていただければと思います。