午後Ⅱ論文の「論述の対象となるプロジェクトの概要」や「設問ア」のためのプロジェクト設定集を公開します

　この記事では、プロジェクトマネージャ試験の午後Ⅱ論文のパーツ（論述の対象となるプロジェクトの概要や、プロジェクトの設定）をサンプルとともに公開します。

　公開する理由は、午後Ⅱ論文の「論述の対象となるプロジェクトの概要」や「設問ア」で論述が必要となる設定用の論文パーツを提供するためです。なぜパーツを提供するのかというと、午後Ⅱ試験の具体的な対策として、論文をパーツを準備しておくことが有効な方法だからです。

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

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

　ではどうすると良いかというと、準備をしておくんです。具体的に準備というのは、使い回しできる論文のパーツを用意しておくことです。ここでは、「論述の対象となるプロジェクトの概要」や設問アの「プロジェクト概要」のパーツを掲載します。

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

　ここでは、私が添削した午後Ⅱ論文の中から、「合格レベル」と言い切れる水準の論文において、プロジェクト概要の部分をいくつかピックアップしてみました。ぜひ、午後Ⅱ論文のパーツとして使用してみてください。つまり、つかえそうなところがあったら、パクってみてください！

キーワード　「ステークホルダ」

①プロジェクトの名称

データ可視化ツールのリプレイスプロジェクト

プロジェクトの目的

• POSデータの可視化
  • これまでは、店の売上高だけを可視化し、経営層と販売部門が閲覧していた
  • 今後はプロモーションのデータも入り、売上高とプロモーションの因果関係を可視化＋分析する

プロジェクト進行上の問題と対策

• ユーザー部門（販売部門とマーケティング部門）が3月～4月で繁忙期に入ってしまう。
• ユーザー部門の担当者（兼任）の稼働状況を監視していたら、要件定義でこのプロジェクトに全く動いてない様子がわかった。これが危険の兆候。
• 明確な遅れは出ていないが、要件定義の際の質疑応答の回答が遅い状態にある。チームリーダーに確認したところ、ちょっとした質問でも時間がかかることがあり、平均5営業日かかっていた。明らかに後回しにされている。そこで対策を取ることにした。

• 対策はトップへの働きかけ ＆ 遅れをクラッシングでのカバー。クラッシングの留意点として、新規メンバーが参画直後からパフォーマンスを発揮できるように1on1を実施して重点管理した。

②企業・機関等の種類・業種

• 商社・卸・小売

③企業・機関等の規模

• 301～1,000 人

④対象業務の領域

• 経営・企画、営業・販売、管理一般

⑤システムの形態と規模

• Web システム (サーバ 約 10台，クライアント 約 300台)

⑥ネットワークの範囲

• 同一企業・同一機関の複数事業所間

⑦システムの利用者数

• 101～300 人

⑧総開発工数

• 約60人月

⑨開発費総額

• 9,000万円　（ハードウェア費用を 含まない）

⑩開発期間

• 2023年1月～2024年10月
• 10ヶ月

⑪あなたが所属する企業・機関等

• 一般企業などのシステム部門

⑫あなたが担当したフェーズ

• システム企画・計画、システム設計、プログラム開発、総合テスト、移行・運用

⑬あなたの役割

• プロジェクトの全体責任者

⑭あなたの管理対象人数

• 約4人～8人

⑮あなたの担当期間

• 2023年1月～2024年10月

体制

• 2チーム、最大8人
  • Aチームのスコープは既存アプリ機能の載せ替え部分（BIツールにおける可視化機能）
  • Bチームのスコープは新規機能の開発部分（BIツールにおけるダイシングなどの分析機能）

プロジェクト期間

• 10ヶ月（1月～10月）
  • 要件定義
    • 1月、2月
  • 外部設計
    • 3月、4月
  • 内部設計
    • 5月、6月
  • 製造・単体テスト
    • 6月、7月
  • 結合テスト
    • 8月、9月
  • 総合テスト＋移行等
    • 10月

キーワード　「予算」

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

プロジェクト進行上の問題と対策

• 社内では、BIシステム開発のコストに影響を与える要素のうち、最も大きいものは、スコープの変更であるとしている。スコープの変更に伴い、作業量が想定以上に増え、品質を満たせなくなり、残業や人員増加を招き、コストが悪化する、という流れである。
• そこで、対策として、コロナ禍によるコストの制約が非常に厳しい本プロジェクトでは、最重要の監視対象をスコープであるとした。
  • 具体的には、①週あたりの、変更管理委員会での、仕様変更が決定された数である。粒度は様々だが、３変更／週を超えるようであれば、作業量の再見積もりを行うルールとした。
  • ②また、そもそも仕様変更が生じないようにすれば、①のパターンで変更が生じるリスクも小さくなる。そこで、要件定義と外部設計においては、プロトタイプを使って顧客レビューを進めることにした。
• BIシステムは、業務上、分析したい項目や扱いたいデータがどんどん増えていく傾向がある。分析業務は、分析項目の細分化や扱う範囲の拡大をすることで更に精度・品質が高まるため、構造的に、想像（空想）であれも分析したいこれも分析したい、と際限ない機能追加が生じてしまいやすいのである。結果、あまり使われない機能もふんだんに搭載したBIシステムが要求され、コストが高まってしまう。
  • そこで、対策として、プロトタイプを用いて要件定義・外部設計し、ユーザーレビューすることで、必要なさそうな情報項目や画面について、ユーザーが空想ではなく地に足ついた形で検討することができるようになる。

体制

• 2チーム、最大8人
  • Aチームのスコープは既存アプリ機能の載せ替え部分（BIツールにおける可視化機能）
  • Bチームのスコープは新規機能の開発部分（BIツールにおけるダイシングなどの分析機能）

総工数

• 60人月

プロジェクト期間

• 10ヶ月（1月～10月）
  • 要件定義
    • 1月、2月
  • 外部設計
    • 3月、4月
  • 内部設計
    • 5月、6月
  • 製造・単体テスト
    • 6月、7月
  • 結合テスト
    • 8月、9月
  • 総合テスト＋移行等
    • 10月

プロジェクトの目的

• POSデータの可視化
  • これまでは、店の売上高だけを可視化し、経営層と販売部門が閲覧していた
  • 今後はプロモーションのデータも入り、売上高とプロモーションの因果関係を可視化＋分析する

キーワード　「品質」

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

プロジェクト進行上の問題と対策

• 特徴は、品質面で機能要件が厳しかったことである。
• リプレイスによるものであるため、基本的には「現行と同じ機能と性能でお願いしたい」という要求だった。
  • しかし、この形の要求で、既に同じものがあるからと要件定義や外部設計の工数を低く見積もることは、非常にリスキーである。
  • 実は既存システムの表面に出ていない部分が複雑であるとか、A社情報システム部門が把握していない特殊な使い方をA社ユーザー部門である販売部門やマーケティング部門がしている可能性も十分にある。
  • ユーザー部門が使い勝手（些細な画面の配置や機能の差なども含む）を重視しており、拒否反応を起こすリスクもある。
• そのため、あくまでもZ社標準をベースに工数を算出し、見積もりを出した。
• 実際、A社の既存システムは古く、ドキュメントが無いことや構築当時の社員が退職していることもあって、既存システムを用いて「現行と同じ機能」を定義することが非常に難しい状態った。
• そこで、私は、要件定義と外部設計で、プロトタイプモデルを用いることにした。プロトタイプを触ってもらうことで、要求を引き出すことにした、ということだ。これならば、現行システムとの使い勝手の差分も十分に引き出すことができ、要件のヒアリング漏れを防ぐことができると判断した。

体制

• 2チーム、最大8人
  • Aチームのスコープは既存アプリ機能の載せ替え部分（BIツールにおける可視化機能）
  • Bチームのスコープは新規機能の開発部分（BIツールにおけるダイシングなどの分析機能）

総工数

• 60人月

プロジェクト期間

• 10ヶ月（1月～10月）
  • 要件定義
    • 1月、2月
  • 外部設計
    • 3月、4月
  • 内部設計
    • 5月、6月
  • 製造・単体テスト
    • 6月、7月
  • 結合テスト
    • 8月、9月
  • 総合テスト＋移行等
    • 10月

プロジェクトの目的

• POSデータの可視化
  • これまでは、店の売上高だけを可視化し、経営層と販売部門が閲覧していた
  • 今後はプロモーションのデータも入り、売上高とプロモーションの因果関係を可視化＋分析する

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

キーワード　「スコープ、計画変更」

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

プロジェクト進行上の問題と対策

• リプレイス＋新機能（ダイシングなどの分析機能）の追加が本プロジェクトで実施する内容だった。
  • しかし、コロナの影響で主要なユーザー部門である販売部門がまるで外部設計レビューに参加できず、遅れが見えてきていた。
  • また、コロナによって店舗の営業活動立て直しは最重要の経営課題となり、販売部門の参加のメドはまるで立たなかった。
• レビューが進まない表面的な原因はA社にあるものの、リスクとして考慮することが難しかったコロナ禍という天災に起因しているため、Z社としても責任を全てA社に押し付けることはできないと判断した。
• そこで二段階リリースを提案した。
  • 具体的には、第一段リリースをリプレイス部分とし、分析機能は第二弾の回すこととした。このスコープ変更の決定に至るまでの流れは以下である。
• まず、開発予定の機能について、サブシステムの粒度で、必須度・効果・搭載しない場合の影響・必要工数を中心に情報を集めた。
• 次に、これらを５段階で点数化し、点数の高い機能を優先して開発することとした。リプレイス部分は、既存の業務でも既に使っているため、搭載しない場合の影響が他の機能と比較すると極端に大きい。
• そのため、最終的に、リプレイス部分を優先度高として、当初のリリース日にリリースすることとした。分析機能のリリースは遅れて３ヶ月後。外部設計まで完了した上で、内部設計の開始は、第一段リリース完了後に回すものとした。
• この結果、要員の総稼働工数は、当初プロジェクトと比較してほとんど変わらなかった。そのため、A社に対するコストの追加請求は無しとして進めることとした。

体制

• 2チーム、最大8人
  • Aチームのスコープは既存アプリ機能の載せ替え部分（BIツールにおける可視化機能）
  • Bチームのスコープは新規機能の開発部分（BIツールにおけるダイシングなどの分析機能）

総工数

• 60人月

プロジェクト期間

• 10ヶ月（1月～10月）
  • 要件定義
    • 1月、2月
  • 外部設計
    • 3月、4月
  • 内部設計
    • 5月、6月
  • 製造・単体テスト
    • 6月、7月
  • 結合テスト
    • 8月、9月
  • 総合テスト＋移行等
    • 10月

プロジェクトの目的

• POSデータの可視化
  • これまでは、店の売上高だけを可視化し、経営層と販売部門が閲覧していた
  • 今後はプロモーションのデータも入り、売上高とプロモーションの因果関係を可視化＋分析する

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

キーワード　「進捗」

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

プロジェクト進行上の問題と対策

• ユーザー部門（販売とマーケ）が３月～４月で繁忙期にはいってしまう。
• ユーザー部門の担当者（兼任）の稼働状況を監視してたら、要件定義で全然動いてない模様。
  • これが兆候だった。
• 明確な遅れは出ていないが、要件定義の際の質疑応答の回答が遅い。
• チームリーダーに確認したところ、ちょっとした質問でも時間がかかることがあり、平均5営業日かかっていた。明らかに後回しにされている。
• そこで対策した。トップに働きかけ＆遅れはクラッシングでカバー。クラッシングでメンバーがちゃんと入れるように1on1を実施して重点管理
• また、進捗は、対策の手段として二段階リリース案も用意しておく。

体制

• 2チーム、最大8人
  • Aチームのスコープは既存アプリ機能の載せ替え部分（BIツールにおける可視化機能）
  • Bチームのスコープは新規機能の開発部分（BIツールにおけるダイシングなどの分析機能）

総工数

• 60人月

プロジェクト期間

• 10ヶ月（1月～10月）
  • 要件定義
    • 1月、2月
  • 外部設計
    • 3月、4月
  • 内部設計
    • 5月、6月
  • 製造・単体テスト
    • 6月、7月
  • 結合テスト
    • 8月、9月
  • 総合テスト＋移行等
    • 10月

プロジェクトの目的

• POSデータの可視化
  • これまでは、店の売上高だけを可視化し、経営層と販売部門が閲覧していた
  • 今後はプロモーションのデータも入り、売上高とプロモーションの因果関係を可視化＋分析する

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

キーワード　「アジャイル、適応型アプローチ」

プロジェクトの概要

データ可視化ツールのリプレイスプロジェクト

プロジェクト進行上の問題と対策

• ２末月に、コロナ禍において、外食産業で、事前注文のテイクアウト専用のインターネット予約サービスを検討した。
• このままコロナ禍が広がれば、営業活動に重大な影響が見込まれる、という状態だった。
• 事前に要件が固まりきることはないと想定された。
  • なぜならば、コンシューマの要求を完全に把握することは難しく、また、コロナ禍の状況によって、コンシューマのニーズも変化することが想定されるからだ。しかしながら、このままでは売上が一方的に落ちていくのみだった。そこで、A社社長の要求は、「とにかく早くリリースしてほしい」というものだった。
• そこで、私は、案として、「現時点で想定される最低限の機能（例　注文機能や決済機能）で可能な限り早くリリースし、消費者のニーズに合わせて変更をかけていく」というプロジェクトの進行スタイルを提案し、ステアリングコミッティでの承認を得た。
• 具体的なプロジェクトの進行手段としては、アジャイル開発のスクラムを採用した。
  • メンバーは８人
  • プロダクトオーナーはユーザー部門の販売部門のB課長。
  • スクラムマスター（兼プロジェクトマネージャー）は私。
  • スプリントの長さは２週間。
  • プロダクトバックログには、欲しい機能をユーザー視点でできることを中心に常に書き貯めていく。
• ２週間ごとのスプリントのたびに、プロダクトバックログから優先度の高い機能を抽出し、２週間のベロシティで開発できるような機能（ものによっては大きな機能の一部分だけ）を作っていった。
  • また、ベロシティは開発当初は不明だったため、暫定で２週あればこの程度が作れるはず、という前提で設定し、徐々に修正をかけていった。
• また、朝会と振り返り会を実施して、次のスプリントに向けてPDCAを短サイクルで回していった。
• 結果、ウェブサービスのリリースは２ヶ月。当初はメニューを選択することもできず（１つのメニューだけでリリースした）決済機能と予約機能だけを用意した。１年経ってスプリントを５０回ほど繰り返し、機能は大小合わせて８０ほどをリリースした。
• 結果は良かった。プロジェクトの目的だった新しい販売形態は奏功した。売上の１０％を占めるほどになった。

体制

• 1チーム、最大6人
  • プロダクトオーナー
  • スクラムマスター（PM）
  • 開発メンバー（4人）

総工数

• 50人月

プロジェクト期間

• 9ヶ月（1月～10月）
  • 要件定義
    • 1月
  • 設計
    • 2月
  • 実装、テスト
    • 3月
  • 継続的改善
    • 6ヶ月
    • イテレーションは2週間
    • プロダクトバックログ
      • バーンダウンチャート
    • スプリント
      • スプリントバックログ
      • 工数はプランニングポーカーで合意
      • スプリントレトロスペクティブ
      • ベロシティを計算して次のスプリントへ

プロジェクトの目的

• ECサイトのリリース＋継続的改善
  • 外食店。コロナ禍でテイクアウトをするためのECサイト
  • 3ヶ月でリリース
    • POCにしても良い
    • 残り6ヶ月で、ユーザーの利用状況などを見ながら継続的に改善していき、いけるいけないを判断

プロジェクトの制約

• 市場の環境が読めない
  • コロナ禍でテイクアウトをするためのECサイト
  • 需要もユーザー要求も読めない。最初に決定することができない
  • 納期が厳しい
    • 営業できないため、最低限の品質で良いので動くことが最優先
  • 機能を想定しても外れるリスクがある。
    • そのため、短サイクルでの機能リリースを繰り返すアジャイルの手法を採用した。結果、売れるECサイトを9ヶ月後に実現する。

まとめ

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

　このブログでは、あくまで、「論述の対象となるプロジェクトの概要」や「設問アの設定」として流用できるパーツの用意に特化していきます。他にも論文パーツを用意していますので、ぜひご活用いただければ幸いです。