この記事は何

f:id:misos:20210506015908p:plain

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

勉強する目的ですが、仕事を進める上で最低限の理解はすべきだと感じる場面が増えた＋在宅勤務の際に通勤時間分の時間的余裕ができたためなんかやろうかと思ったためです。

過去問・解答例・講評

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

www.jitec.ipa.go.jp

講評で『XXXを具体的に書いて欲しかった』『YYYを確認して欲しかった』など出題意図も述べられることが多いので、問題と合わせて出題意図を把握しておく。

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

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

平成21年度春期

問１：リスク対応計画の策定と実施についての問題
問２：要求仕様の策定〜委託先の選定
問３：チームでの作業をする際のルール作成・課題の解決
問４：チームでのコミュニケーションと品質管理

リスクは発生頻度と影響度の軸で表を作成して評価を行う（[1]にもそのような事例がある）。リスクそれぞれに発生確率・影響度・優先順位・コンティンジェンシープラン・コンティンジェンシープランを実施するタイミングを予め決めておくことが望ましい。リスク対応計画にない緊急事態の対応を行うためのコストは上位責任者の承認を必要とする場合がある。

要求仕様は妥当性確認（目的や用途・根本要求に対する正しさの評価）を十分行わないと手戻りが発生する可能性が高いことを確認する。『早めに確認すること』のような簡単な文言であっても、文脈・状況に沿っていれば解答になることがある。

「チームの心理的安全性」という概念...を「対人関係においてリスクのある行動をしてもこのチームでは安全であるという、チームメンバーによって共有された考え」と定義しています。チームメンバーに対してリスクのある行動を取ることは、特別難しいことではないと思われるかもしれません。しかし、「このプロジェクトの目標は何ですか？」などのように、ごく基本的な質問をするときのことを想像してみてください。「そんなこともわかっていないのか」とあきれられることへの不安を覚えるのではないでしょうか。無知だと思われないように、質問をせずにやり過ごそうとする人も少なくないはずです。

チーム内の聞き取りでは心理的安全性が求められる場面があり、また利害関係者に話せないことを聞き出すためには個別での聞き取りも候補になる。チームに新規メンバーや経験が浅いメンバーが入る場合はヒアリングやサポートの時間を確保し、そのために他の業務のスピードが減る可能性を考慮する。

テストはテスト専用のチームと開発チームを分離することで同時並行して実施できる場合がある。内部設計や実装を把握したメンバーがテストを実施することで不具合を発見できる時もあるので、テストの目的を理解した上でメンバーを配置する。

上のように、チームによって用語が異なる場合がある。多くのチームがプロジェクトに参加する場合は用語集を作ることも検討する。

用語

参考文献

平成23年度春期

問１：他社と協業してシステム開発をする際のプロジェクト進行
問２：複数ステークホルダによる要求の調整と判断
問３：旧システムからのデータ移行を伴うシステム開発
問４：コスト・工期見積もり・リスク管理について

他社と協業する場合は、会社ごとの用語の違いや品質評価基準の違いを把握する必要がある。

プロジェクトの企画書について、以下のアカウントにいろいろなスタートアップの資料がアップロードされていた。結構見るだけでも楽しい。

BASE_プレゼン用サービス説明資料 from Find Job Startup

www.slideshare.net

テスト密度・バグ密度を既存プロジェクトと比較することで、開発に問題がないか把握する場合がある。比較対象はなるべく近い内容のプロジェクトになる。

実働期間が短いソフトを開発で使用する場合は未発見の問題が存在する可能性をリスクとして考慮する。用語集の作成や設計のレビューは外部のシステムの理解をすることも狙いに含まれる。テストのバグ密度による測定であまりに密度が低い場合は、テストケースが不十分である可能性も念頭に置く。

PMBOKで学ぶプロジェクトマネジメントの基礎 from Hiroyuki Tanaka

www.slideshare.net

プソロジェクトの目的と目標を伝えるためにプロジェクト憲章を作成し経営議会の承認を得た上で周知を行う。似た目的をもつものにインセプションデッキがある。

blog.nextscape.net

複数部署たステークホルダーが関わるプロジェクトでは、決定権限を持つ人を含めた委員会を設定して調整を行うことを考慮する。

オンプレミスRDBMSをAWSへ移行する手法 from Amazon Web Services Japan

www.slideshare.net

少し古い資料、ただデータ移行までの大まかな流れは把握できる。データサイズの規模と許容できるダウンタイムに依って移行方法の選択肢が増える。テストは可能ならば本番環境のデータを使用して本番データで問題が起きないことを確認する。

f:id:misos:20210606055241p:plain — [5]より引用、品質を予測するためにはあらかじめ欠陥数や開発内容を記録する基盤が必要

テストの欠陥数を記録するだけでなく時系列に沿った記録を比較することで、過去の実績値や計画との乖離を早期に検出する。以前にテストしたソフトウェアが変更・機能追加後もまだ動作するかどうかの確認（リグレッションテスト）は必ず行い、このようなテスト作業はなるべく自動化するのが望ましい。

上記ページを参考にしつつ、テスト自動化をチームで協力して行うには

テストコードを書く工数をもらう
テストコードを書く環境を共通化する
テストの実行環境を自動化する
サンプルコードを書いて他の人でも書けるようにして学習コストを下げる
テスト自動化ツールの使用を属人化せずにチーム内で分担する

などができる環境を整える。

用語

参考文献

平成24年度春期

問１：プロジェクト全体の管理技法・WBSによる進捗管理
問２：ステークホルダ間の調整と要件定義
問３：開発における不具合対応と品質管理
問４：バグ検出の実績値の比較をもとにした定量的品質管理

WBSを始めよう from Takashi Yoshimura

www.slideshare.net

プロジェクト完了までにかかる最長の経路を求めてボトルネックとなっている箇所を分析する。また、全体の遅れが発生しないようにクリティカルパス上の進捗を正確にトラッキングするなどの施策が考えられる。

準委任契約は仕事を完成させる義務を負うわけではなく、約束した時間だけ作業を支援してくれる契約形態。社内システムの開発案件などでは、システム利用者の要求にどこまで対応するか・どのようにして利用社のいる部署の理解を得るかも重要になってくる。システムが業務プロセスに提供する機能と実際の要求との適合度を分析する作業はフィットギャップ分析と呼ばれる。

プログラムコード数による品質管理は昨今のコード記述が無いシステムなどに直接応用する際には課題があることを理解しておく。過去のプロジェクトとの比較には５Mを揃える、要は比較したい点以外の条件をなるべく揃える。セキュリティ・保守性・負荷に関する項目は入出力のテストだけでは検出できないことを把握しておく（ペネトレーションテストや性能テストが必要）。