プロジェクトマネージャ試験の午後Ⅱ論文のパーツ（品質領域）をサンプル論文とともに公開します

　この記事では、「品質」領域のサンプル論文をいくつか掲載します。

　サンプル論文を掲載する理由は、「品質領域における論文のパーツ」を提供するためです。なぜパーツを提供するのかというと、午後Ⅱ試験の具体的な対策として、論文をパーツを準備しておくことが有効な方法だからです。

　プロジェクトマネージャ試験の午後Ⅱで、問題文を見てゼロから2000字超えの論文を書き上げることなんて不可能だと思いますよね。しかも、問題文に合わせる必要があるので、予め作っておいた論文を書いてもテーマに沿わない可能性が高く、それでは合格の確率は極低いです。

　アママネくんのこの感覚は正しいです。プロジェクトマネージャ試験のプロでないかぎり、「準備無し」で合格論文を書くのは無理です。

　ではどうすると良いかというと、準備をしておくんです。具体的に準備というのは、使い回しできる論文のパーツを用意しておくことです。

　私は都内の上場IT企業で、プロジェクトマネージャ試験対策の社内勉強会を2016年から主催しています。その活動の中で午後Ⅱ論文の添削をやっています。年40本として、合計で250本は添削しました。

　ここでは、私が添削した午後Ⅱ論文の中から、「合格レベル」と言い切れる水準の論文をいくつかピックアップしてみます。ぜひ、午後Ⅱ論文のパーツとして使用してみてください。つまり、パクってみてください！

プロジェクトマネージャ試験 平成21年 問2 情報システムの本稼働開始について

平成21年 問2 問題文

　プロジェクトマネージャ(PM)には,プロジェクトの立上げ時に,信頼性,操作性などに関するシステムの品質目標が与えられる。PM は,品質目標を達成するために,品質を作り込む施策と品質を確認する活動を計画する。
　PM は,設計工程では,計画した品質を作り込む施策が確実に実施されるように管理するとともに,品質目標の達成に影響を及ぼすような問題点を,品質を確認する活動によって早期に察知し,必要に応じて品質を作り込む施策を改善していくことが重要である。
　例えば,サービスが中断すると多額の損失が発生するようなシステムでは,サービス中断時間の許容値などの品質目標が与えられる。設計工程で品質を作り込む施策として,過去の類似システムや障害事例を参考にして,設計手順や考慮すべきポイントなどを含む設計標準を定める。品質を確認する活動として,プロジェクトメンバ以外の専門家も加えた設計レビューなどを計画する。品質を確認する活動の結果,サービス中断時間が許容値を超えるケースがあるという問題点を察知した場合,その原因を特定し,設計手
順の不備や考慮すべきポイントの漏れがあったときには,設計標準を見直すなどの改善措置をとる。それに従って設計を修正し,品質目標の達成に努める。
　あなたの経験と考えに基づいて,設問ア~ウに従って論述せよ。

平成21年 問2 設問文

　設問ア あなたが携わったシステム開発プロジェクトの特徴,システムの主要な品質目標と品質目標が与えられた背景について,800 字以内で述べよ。

　設問イ 設問アで述べたプロジェクトにおいて計画した,設計工程で品質を作り込む施策と品質を確認する活動はどのようなものであったか。活動の結果として察知した問題点とともに,800 字以上 1,600 字以内で具体的に述べよ。

設問ウ 設問イで述べた問題点に対し,特定した原因と品質を作り込む施策の改善内容について,改善の成果及び残された課題とともに,600 字以上 1,200 字以内で具体的に述べよ。

平成21年 問2 サンプル論文

１－１　概要・特徴（347字）

　私はシステム開発ベンダーZ社のプロジェクトマネージャーである。今回私が担当したプロジェクトは、外食チェーン店A社の店舗販売状況の可視化システムのリプレイスである。具体的には、現行版BIシステムのベースとなるパッケージソフトウェアを、より高機能な分析が可能な別メーカーのBIシステム用ソフトウェア（以後、新BIソフトと呼ぶ）に切り替える、というものだ。体制は2チーム最大8人・総工数約60人月・PJ期間は2020年4月～2021年2月の10ヶ月であった。

　特徴としては、昨今のデータサイエンスの隆盛により、新BIソフトに詳しいZ社のベテランが軒並み他プロジェクトに入ってしまっていたことが挙げられる。そのため、本プロジェクトは新BIソフトの知見が相対的に浅いメンバーが中心で進めることとなった。

１－２　主要な品質管理目標と与えられた背景(336字)

　主要な品質管理目標は性能だ。具体的には「同時接続60人のとき、全ての帳票で、レスポンスタイム3秒以内（特に60人が重要）」である。この数字の背景は、現行可視化システムが現段階で「同時接続30人のとき、全ての帳票で、レスポンスタイム3秒以内」を満たしており、かつ、今後は販売部門（30人）に限らず、プロモーション部門（30人）も本可視化システムを活用することが決まっているからである。現行システムがあるため、これよりも性能が低い（レスポンスが悪い）場合、ユーザーから多大な不満が出ると想定される。（機能が適切に揃っていることが前提だが）BIシステムの利用者の満足度は、特にレスポンスタイムに左右されることが多いため、このように目標設定されていた。

２ー１　品質を作り込む施策の計画（885字）

　2020年4月に、品質計画の立案および策定を行った。計画の策定においては、Z社における過去の新BIソフトを用いたプロジェクトを7つほど分析した。また、新BIソフトの特徴を考慮した設計標準を立案するために、それらプロジェクトのプロジェクトマネージャからヒアリングを行った。特に重要な情報は、「外部設計が重要。新BIソフトは高機能であるがゆえに、画面に凝ってしまいがちで、結果、性能低下に繋がりやすい」というものだった。そこで今回は、ユーザーの画面要件チェックとZ社の性能チェックを設計段階から行うために、設計フェーズにおいてプロトタイプ手法を採用することにした。以下に、計画した品質を作るこむ施策が実施できるための管理の手段を、①設計手順と②設計の考慮すべきポイントの２つの観点で記載する。

　①設計標準における具体的な設計手順は、外部設計にて、週に１度の頻度で、プロトタイプを用いてユーザーとの合意を進めつつ、そのプロトタイプを用いて同じく週に１度の頻度で負荷試験を行う、というものだ。このようにした理由は、ユーザーと合意した画面のうち、性能目標に悪い影響を与えそうな画面を早期に把握し、対策を検討するためである。プロトタイプとはいえ、負荷ツールで負荷をかければ、性能面のリスクが大きそうな画面は把握できる、という判断である。プロトタイプに負荷ツールで同時60人アクセスの負荷をかけた結果、レスポンスタイムが2.5秒を超える画面については、画面の設計をやり直すことにした。

　②設計標準における考慮すべきポイントは、スコープの膨張を防ぐこととした。これは、「高機能であるがゆえに、画面に凝ってしまいがち。結果、性能悪化に繋がる」というヒアリングから着想を得たものだ。現実的には、外部設計で一定量のスコープ増加は生じると考えられる。スコープ増加の早期発見のためのプロトタイプでもあるためだ。しかし、スコープの増加が過大となった場合、画面に機能を盛りすぎている可能性がある。この場合、性能が悪化する。そこで、画面別に、外部設計で生じたスコープ増加の量を監視することを計画した。

２－２　品質を確認する活動計画（373字）

　品質を確認する活動においては、設計のレビューを重視した。Z社の標準では、定量的には、設計書の初回レビューにおいて、設計書１０ページあたりの指摘数を１～３つを正常値として定めている。これを超えるようであれば、原因を分析・対策した上で、設計書作成をやり直す、という流れにした。

　また、本プロジェクトでは、レビューに関しては特別に、プロジェクトの外部人材という立ち位置で、Z社の新BIソフトに詳しいベテランを招聘した。この理由は、新BIソフトに長けていない新人では、レビュー作業の品質そのものが低い可能性があるためだ。忙しいベテラン勢だったが、レビューだけは一時的に本プロジェクトにリソースを割けるように調整した。ベテランの力を割ける時期としては、外部設計中盤以降の６月下旬～７月末までとなった。これも、潜在的な不具合やリスクなどの早期発見を目的とするものだ。

２－３　品質確認活動の実績とそこで察知した問題点(234字)

　計画通り、6月～7月で、外部設計作業が始まった。プロトタイプを用いて外部設計の検討・負荷に対する性能検査を実施した。ベテランには6月3週目から外部のレビュアーとして活動を指示した。より具体的には、性能劣化に繋がりやすい画面を重点的に抽出することを指示した。

　結果、外部設計の中盤に入る6月4週目に、ベテランによる指摘が数多く生じた。指標としては、設計書への指摘が10ページあたり4.2という状態で、許容範囲を超えていた。いずれの指摘も、性能を大きく劣化させる可能性があるもの、ということだった。

３－１　原因分析（２５２字）

　7月1週に、まずは原因分析を行った。ベテランによる指摘内容を、ジャンル別にパレート分析する指示を出した。マテリアライズドビューに関する指摘が最も多く、これだけで指摘全体の50％を占めていた。マテリアライズドビューを起因にして、性能が劣化しやすい状態になっている、ということである。ここで私は、さらに原因を深堀りした。結果、マテリアライズドビューへの指摘が多い原因は、設計における新BIソフトへの知見不足にあると判明した。メンバーには、新BIシステムのマテリアライズドビュー関連の知見が足りていなかった。

３－２　改善内容とその成果（５９７字）

　7月2週には、改善として、体制の強化を図った。メンバーには知見が足りず、ベテランはレビュー以上の工数を割くことはできない。そこで、新BIシステムのメーカーのコンサルタントに参画を依頼した。知見が足りない可能性があることは、計画段階でリスクとして認識していたため、予め備えていたコンティンジェンシー予備費を使った。

　結果、コンサルタントの知見を取り込むことで、7月4週には、1.1指摘/10ページ程度まで改善された設計書が完成した。また、プロトタイプの負荷試験状況も良好だった。内部設計以降も設計・開発は順調で、最終的には、コンティンジェンシー予備費は使ったもののコスト、納期、性能品質ともに目標は全て計画通りに収まった。プロジェクトの目的であった顧客の分析業務の高度化も実現したことで、成功としてプロジェクトは完了した。成功の背景としては、メーカーのコンサルタントの知見を早期に取り込むために、コンサルタントがチームに早く溶け込めるように、彼のパフォーマンスを重点監視し、1日1回の1対1コミュニケーションの場を用意したことが良かった。このようにした理由は、新メンバーの加入時には、新メンバーがパフォーマンスを思うように上げられないことがある、というリスクを鑑みたからだった。また、メーカー側には事前にコンサルタントの力を借りる可能性があるとして、見積もり取得と調整を行っていたのも奏功した。

３－３　残された課題（２３０字）

　本プロジェクトではコンサルタントの力でカバーできたが、現状の問題は、Z社には機能と性能劣化の関係性の知見が無いことだ。ゆえに、外部設計で問題が出てしまった。そこで、今回得たコンサルタントの知見と新BIシステムに関する知見を可視化し、機能と性能劣化の関係を標準化することが残された課題だと考えている。結果、Z社作業標準はさらに水準が向上するだろう。

　新IBソフトは全世界で導入が進んでおり、今回定めた作業標準は、必ず別のプロジェクトでも有用になると考えている。

まとめ

　午後Ⅱの解き方そのものは、プロジェクトマネージャ試験対策として最強の参考書であるはみよちゃん本こと、翔泳社の「情報処理教科書 プロジェクトマネージャ」で勉強しましょう。

　このブログでは、あくまでパーツの用意に特化していきます。他のマネジメント領域のサンプル論文も用意していますので、ぜひご活用いただければ幸いです。