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

3月 22, 202012月 21, 2023プロジェクトマネージャ試験

プロジェクトマネージャ試験の午後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%。極端な差異は発生していませんし、全て月の区切りで書き出せるので、本番でスラスラと書きやすいです。

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

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

成功するためのプロジェクトマネジメント～計画フェーズ～ | ティースリー株式会社

ITやWebのお困りごとならティースリーにお任せください。ITサポートを当たり前の社会インフラに。

https://t-tthree.com/2018/08/31/プロジェクト-成功/

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

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

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

そこでプロジェクトマネージャ試験の午後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」を参考にすると「レビュー指摘件数」をはじめとする膨大な定量的に使える実例が確認できます。が、内容が専門的で、そもそもシステム開発に縁が遠い人では、理解するのに時間がかかるかと思います。当然、論文で使いこなすのはハードルが高めですので、興味がある人は参考にしてもいいですが、あえて読む必要はありません。