この記事は何

f:id:misos:20210506015908p:plain

午前・午後Ⅰの全ての試験において100点満点中60点以上、午後Ⅱの論述試験の評価ランクがAであれば合格になります。プロジェクトマネージャ試験の午後Ⅰ・午後Ⅱの記述式で問われる課題を調べて、それに必要な知識＋調べたことをメモする記事。あくまで自分の解釈であり、正確さは担保していません。

前回

過去問・解答例・講評

毎年IPAが公開しているので、それを参考にする。以下のページから各年度の過去問・解答例・講評を確認できる。

www.jitec.ipa.go.jp

過去問を解きながら調べたこと

ここの過去問を昔のものから辿っていき、調べたことをメモする。

平成28年度春期

問１：プロジェクトのリスク管理、スケジュール遅延リスクの原因を理解する
問２：チーム内のコミュニケーション＋顧客のコミュニケーション
問３：遅延するプロジェクトでの進捗・品質管理

システム導入時に既存の業務に新しい業務プロセスや仕組みを導入する必要がある場合は、業務プロセスがワークするかを確かめるために早い段階でプロトタイプなどを通じて検証を行う必要あり。新しいプロセス・はじめての協業相手の管理負荷など、初めてXXXするケースは必ずリスクを検討する。少し古い資料だが

f:id:misos:20210703145526p:plain — リスク事象トライバーの一覧、[2] "ITプロジェクトのリスク予防への実践的アプローチ(2013)"より引用

などを見てどのような箇所がリスクになりうるかを把握しておく。

要求仕様を記述する時は、相手の視点から見て明確に記述しないとコミュニケーションロスが生まれる。なぜ作るか・作ることにした背景・何通りの解釈も生まない明確性・表記ゆれが無いなどの一貫性・読者が関連する資料を探しだす必要がない（完全性）・完成したかを検証する方法が記載されている（検証性）などを念頭に入れる。また、業務プロセスの一部をシステム化する場合は、基本的にはビジネスプロセス関連図・業務処理定義書は利用者部門が中心、概念データモデル（ER図）・CRUD図・非機能要件書はシステム部門が中心となってドキュメントを作る[4]。

参考文献

平成29年度春期

問１：プロジェクト計画作成
問２：自社との契約実績が無い委託先とのシステム開発における請負・派遣契約
問３：バグの発見・テスト手法について

問２は実績がない委託先があるプロジェクトについて。派遣契約と請負契約の違いを理解しておかないと解けない。特に、指揮命令関係は派遣にはあるが請負には無い。つまり、請負の場合は発注者は請負社員に指揮命令権が無いため、指示をすることはできない。

契約名	発注者側の指揮命令権	完成責任	瑕疵担保責任
派遣契約	あり	なし	なし
準委任契約	なし	なし	なし
請負契約	なし	あり	あり

にて『あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提』とあるように、契約方式は開発手法にも関わってくることがあることを理解しておく。請負契約の場合、その会社がどれくらい遂行能力があるかを直接把握できていない場合はリスクになりうることを頭の片隅においておく。

テストの設計は、より最近の修正を反映したテストほど（テスト設計の時間分の遅延が発生するかもしれないが）手戻りは少なくなる。問１の解答は「内部設計で発見した誤りを修正したものを用いることで手戻りが少なくなるため」。大問１と同様、バグ発見件数やテストの量でリスクを予兆できるように、プロジェクト内で以下のような指標をいつでも確認できる仕組みも必要。

f:id:misos:20210703190337p:plain — 定量的な測定量の例引用元：プログラム1ソフトウェア開発における定量的管理の主な手法独立行政法人情報処理推進機構（IPA）社会基盤センター

引用元：ソフトウェア開発における定量的管理の主な手法、独立行政法人情報処理推進機構（IPA）社会基盤センター、https://www.ipa.go.jp/files/000072870.pdf

テストケースを追加する際は、テストケース追加でバグが検出されることを期待している、良いテストケース＝バグが減らせるテストケース。なので、テストケースを増やしつづけることでバグ密度を減らす、という方針は正しいとは言えない。

あくまで試験で点数を取る視点だと、平成28、29ともに、講評において『一般論的な解答ではなく〜、XXXの意図を理解してっほしかった』とあるので、特に一般論的な解答を書く場合は一度出題者がなぜこの問題を作ったのかを考えてみる？ただ、こんなことを考えても実務で役に立たないので、やっぱりプロジェクトの状況を把握した（＝問題文を読んだ）時点で「こんな問題がありそうだな」と自分で考えられるようになりたい。