プロジェクトマネージャ

1. テンプレート
   こたえ:

基礎知識

ITのプロ46・三好康之 (2024)『情報処理教科書 プロジェクトマネージャ 2024年版』翔泳社. の章立てに合わせて、覚えておきたい用語をメモしておきます。

PMBOK と JIS Q 21500

1. 心理的安全性
   こたえ:

   周囲がありのままの自分を受け入れてくれるという安心感。A. C. Edmondson が提唱したと言われている。

経営戦略

1. 事業環境分析の整理
   こたえ:

   
   外部環境分析: PEST分析、ファイブフォース分析。 内部環境分析: VRIO分析、バリューチェーン分析。 どちらも: 3C分析、SWOT分析。

デジタルトランスフォーメーション

1. PoC
   こたえ:

   Proof of Content の略。概念実証。前例がない場合に検証を繰り返すこと。

アジャイル開発

1. アジャイル宣言の背後にある原則
   こたえ:

   顧客満足、変化、短時間、一緒、意欲、対面、動く、ペース、卓越と注意、シンプル、自己組織、振り返り。

価値の実現

1. プロジェクト・ベネフィット
   こたえ:

   価値を提供する行動、成果など。

プロジェクト立ち上げ〜プロジェクト計画まで

1. フィージビリティスタディ
   こたえ:

   実現可能性の検討。

2. プロジェクト憲章
   こたえ:

   プロジェクトオーナーやスポンサーが発行する文書。プロジェクトマネージャーが任命される。

3. WBSとWP
   こたえ:

   
   WBS: プロジェクトの成果物を要素分解した階層構造。
   WP: ワークパッケージ。WBSにおける最下位の作業。アクティビティはワークパッケージをさらに細分化したもの。

プロジェクト体制

1. ステアリングコミッティ
   こたえ:

   利害調整や意思決定を行う組織。利用者側の協力意識が低いときに命令してもらうとか。

責任分担マトリックス

1. RAM, RACIチャート
   こたえ:

   
   RAM: Responsibility Assignment Matrix の略。責任分担表。
   RACIチャート: 責任分担表の一種。Responsible, Accountable, Consult, Inform の頭文字をとったもの。

要員管理

リスクマネジメント

1. 純粋リスクと投機的リスク
   こたえ:

   
   純粋リスク: 損失しか生じえないリスク。
   投機的リスク: 利益も損失も生じうるリスク。

2. 感度分析の表示方法2
   こたえ:

   
   スパイダーチャート: レーダーチャートのこと？
   トルネードチャート: どちらかというとコマの形をしたチャート。

3. デシジョンツリー
   こたえ:

   決定木。

4. プロジェクト計画策定時におけるリスクマネジメントの流れ
   こたえ:

   特定 > 定性的分析 > 定量的分析 > 対応戦略 > 対応策。

5. リスクに対する戦略5+5
   こたえ:

   
   【マイナスリスクの場合】
   エスカレーション、回避、転嫁、軽減、受容。
   【プラスリスクの場合】
   エスカレーション、活用、共有、強化、受容。

過去問道場

各過去問題を解くのに必要な知識をまとめます。

令和5年

1. アジャイル宣言の背後にある原則
   • 原則2「要求の本質を見抜き、変更は前向きに」に照らして、コストと変更受け入れのバランスを考慮したものを選ぶ。
2. JIS Q 21500 (プロジェクト全体計画の作成)
   • 立ち上げ: プロジェクト憲章の作成。
   • 計画: プロジェクト全体計画の作成。
   • 実行: プロジェクト作業の指揮。
   • 管理: プロジェクト作業の管理。変更の管理。
   • 終結: プロジェクトの終結。得た教訓の収集。
3. JIS Q 21500 (計画のプロセス群)
   • JIS Q 21500における「プロセス群及び対象群に関連するプロジェクトマネジメントのプロセス」という表を参照するとよい。
   • 具体的な計画系はすべて計画のプロセス群に属する。
4. JIS Q 21500 (ステークホルダのマネジメント)
   • 21500でステークホルダ関係は「特定」と「マネジメント」の二つ。
   • 特定: プロジェクトに関係するステークホルダを明らかにすること。
   • マネジメント: ステークホルダの分析し、課題解決すること。

論述テンプレート

要件の膨張を防ぐ

1. パッケージの導入を提案するが、どうせ不満の声が上がってカスタマイズ要求が飛んでくる。要件が膨張するのをできるかぎり防ぐために、事前にパッケージの有用性をアピールする。

論述の心得

1. プロジェクトの進行について述べるときに考慮すべき事項を頭に入れておきたい。
2. 一般的な文章作法には従わないほうがよい。
   • シタの連続を許容する。すべての文がシタで終わっても構わない。
   • 「さらに」「また」という情報追加の接続表現を積極的に用いる。

論述の便利表現

顧客を目的語にとる動詞表現

• 顧客と交渉した
• 顧客に提案した
• 顧客に説明した
• 顧客の了承を得た

H19-2-3

設問ア

• 情報システム開発プロジェクトの概要と品質上の目標
• (1.1) 情報システム開発プロジェクトの概要
  私がプロジェクトマネージャとして携わったプロジェクトは、会社の合併に伴う新たな経営管理システムの開発であった。会社の合併は1年後であり、合併の1ヶ月前には各社が現行のシステムから新システムに移行することを予定していたため、11ヶ月という短い期間でシステムを完成まで持っていく必要があった。短い期間でのシステム開発では、性能や操作性といった品質の確保が疎かになる可能性が高い。そのため、本プロジェクトでは、品質マネジメントに対してより一層の注意が払われた。
• (1.2) 与えられた品質上の目標
  会社の合併に伴って開発される新システムは、現行のシステムよりも高性能であるだけでなく、会社の合併によって発生する新たな要件をも満たしている必要があった。合併前の時点においては、業務を遂行するうえでどのような性能が求められるかが不明確であることから、開発フェーズに入ってから新たな要件が発生し、開発が遅延することが予想された。加えて、合併予定の各社の従業員にとって良好な操作性を実現するためには、各社の従業員を対象として操作性テストを実施する必要がある。そのため、通常よりもシステムのレビューに時間がかかり、プロジェクトに遅れが生じる可能性が高かった。

設問イ

設問ウ

H24-2-1

設問ア

• (1) プロジェクト、システム化に関する要求の特徴
• (1.1) プロジェクトとしての特徴
  X社は日本に10の拠点、東南アジアに2つの拠点を持ち、国内外で衣服や靴の卸売業を営む大手企業である。当時、X社は他社の販売管理システムAを利用し、製品の情報や流通を管理していたが、1年後にシステムAの保守契約が満了することを踏まえ、当社にX社独自の販売管理システムの開発を依頼した。X社の希望は、契約満了を迎える日時の一ヶ月前に新システムの導入が完了することであった。普通、新たな販売管理システムの開発は1年を超える時間を要するが、当社はX社の希望に沿うように11ヶ月のプロジェクト期間を設定し、予算限度額を1億円としてプロジェクトを開始した。これにより、通常よりも短いスケジュールでのシステム化計画が必要となり、可能なかぎり後戻りを減らすためにも要件定義には普段以上に細心の注意が払われた。
• (1.2) システム化に関する要求の特徴
  X社がアパレル系の卸売業者であるということから、新たな販売管理システムには衣服や靴に特有の入力項目を設けることが要求された。具体的には、サイズや生地、靴底の厚さをはじめとする衣服や靴に関する性質それぞれに対して、選択式ないし記入式の入力項目が必要とのことであった。通常の販売管理システムにおいても製品に特有の値を設定可能ではあるが、本プロジェクトの場合、設定予定の値が非常に多く、新システム上でその値すべてを業務上効果的なやり方で管理することができるかどうかが不明であった。加えて、X社が日本国外にも拠点を展開し、現地で従業員を雇用しているという状況から、新システムは日本語だけでなく英語でも利用可能なものとして提供する必要があった。このように、アパレル製品に特有の入力項目を設ける必要があること、新システムを英語で利用可能な状態にする必要があることの二点が本プロジェクトにおけるシステム化に関する要求の特徴であった。
• 回答作成直後の感想: テーマである要点定義について語るうえで、それなりに使いやすい事例を想像することができたように思う。書き方に問題があることは間違いないが、便利なテーマを想像するという点ではうまくやれている気がする。過去問題や参考書から便利な架空事例をたくさん集めておきたい。また、設問アに回答してみて実感したが、このあとに設問イと設問ウがあることを絶対に忘れてはいけない。設問アはけっこう自由度が高く、小説を書く気分であっという間に800字に到達してしまうが、あまりに自由に書いてしまうと設問イと設問ウでつまずくにちがいない。「今書いている情報は設問イか設問ウで伏線として回収できるのだろうか」と不安になりながら設問アの回答を作成していた。答案用紙は設問ごとにあるから、先に設問イと設問ウに着手するという手もあるが、まだそれが賢明な判断なのかどうか、わからない。とりあえず、明日設問イに回答してみて、いろいろと考えてみよう (2024年09月04日00時28分40秒)。
• 添削: タイトルの作成方法はこれでOK。かならずしも予算額を明確にする必要はない。(1.1) は比較的よく書けている。ただし、この先の文章に関係することだが、会社に関する情報を具体的に書きすぎた。(1.2) では、一般論しか話さないのはよくないと思ったが、逆に具体的すぎた。「要件膨大」と「要件漏れ」に話をつなげるために、どういう状況が「要件膨大」や「要件漏れ」を引き起こすかについて論理的に記述する、というくらいでよかった。「一般にこの種のプロジェクトでは」というような入り方もありかもしれない。

設問イ

• (2) 要件の膨張を防ぐために計画した対応策①
• (2.1) 要求の優先順位を決定する仕組みの構築
  X社が扱う衣服や靴といった製品の性質上、X社は新たな販売管理システムにおいて通常よりも多くの属性値を入力することを想定していた。膨大な数の属性値を管理し、業務に役立てたり有益なデータを得たりすることは困難であると予想されたため、本プロジェクトでは、多様な属性値の設定をはじめとするX社の要求に優先順位を付け、優先度が高いものから新システムに実装することに決定した。一方で、要求の優先度が低く、かつ、その要求を新システムに反映するかどうかがX社の業務に対して大きな影響を及ぼさない場合、その要求は引き受けないことにした。
• (2.2) 対応策①の実施状況と評価
  要求の優先順位を決定する仕組みを構築したことで、重要度が高い要求と実装難易度が低い要求が選別され、実現可能性が高い要求のみを要件として立てることができた。もちろん、重要度が低い要求や実装難易度が高い要求は満たせないことになってしまう。ところが、そのような制限の発生が結果的に新システムの開発に良い効果をもたらした。具体的には、カスタムの属性値を設け、各ユーザーが自分の環境に合わせて特定の属性値を設定することを可能にするという要求が出された。その要求の優先度を高くし、実際に要求を満たすことによって、結果的に他の満たされなかった要求をカバーすることができた。
• (3) 要件の膨張を防ぐために計画した対応策②
• (3.1) 要件の確定に関する承認体制の構築
  要求の優先順位を決定する仕組みが構築され、重要度が低い要求や実装難易度が高い要求は退けられることになった。とはいえ、多くの要求の優先順位が高く設定されれば、結局、達成すべき要件が乱立し、要件の膨張を防ぐことができなくなってしまう。そこで、新たな要求を要件として確定するまでに承認を経る体制を構築した。本プロジェクトでは、打合せや検証の中で要件になりうる要求が発生した場合に、X社および当社のプロジェクト責任者によるメールでの承認をもって、当該の要求を要件として確定することにした。承認にメールを用いたのは、プロジェクト責任者による承認を記録として残すためである。
• (3.2) 対応策②の実施状況と評価
  要件の確定にプロジェクト責任者による明示的な承認が必要になったことによって、多数の要求が要件として確定し、要件が乱立することを防ぐことができた。それに加えて、承認体制の構築は要求の明確化につながった。というのも、プロジェクト責任者に対して要件確定の承認を求めるにあたって、要件候補の内容を具体的に提示する必要があるからである。これにより、具体性を欠く要件や、X社と当社との間で認識の齟齬を含む要件が減り、要件達成の円滑化が実現した。一方で、本プロジェクトでは当該の承認体制が新システムの開発に遅延をもたらすことはなかったものの、二社のプロジェクト責任者による承認を得るのには多少の時間を要するため、あらゆるプロジェクトにおいて実践可能な対応策ではないように思われた。
• 回答作成直後の感想: 実地経験の不足と勉強不足がどちらもよく見て取れる回答になってしまった気がする。論理が破綻しているというわけではないが、プロジェクト進行のどの側面に着目して「実施状況」や「評価」を書くべきかがよくわからない。あと、仕事が終わったあとの、まあまあ疲れ切った状態で回答を作成しているが、これは良いことだと思った。本番も午後IIは疲れ切った状態で受験することになると予想されるからだ (2024年09月05日20時54分00秒)。
• 添削: 第一に、(2) と (3) を分ける必要はなかった。(2.1) 対応策、(2.2) 実施状況と評価という構成でよかった。(2) と (3) を比べると (3) のほうがよく書けている。やはり、あまりに具体的に書くのはよくない。ただし、(3.2) の、ほかのプロジェクトに応用可能かという話は不要だった。

設問ウ

• (4) 要件の定義漏れや定義誤りなどの不備を防ぐために計画した対応策①
• (4.1) 過去のプロジェクトを参考にしたチェックリストの整備と活用
  当社では、本プロジェクト以外においても販売管理システム開発の実績を積み重ねており、過去のプロジェクトの際に作成したドキュメントが数多く存在する。そこで、本プロジェクトでは、そのような過去のドキュメントを振り返り、販売管理システムを開発するにあたって要件になりやすい事項を列挙したチェックリストを作成した。要件定義フェーズにおいてこれを活用することにより、X社と当社との間に生じうる認識の相違を可能な限り減らし、要件の定義漏れや定義誤りの防止に勤めた。
• (4.2) 対応策①の実施状況と評価
  当該チェックリストを活用することによって、過去のプロジェクトにおいて発生した認識の相違が、本プロジェクトにおいても発生していたことが判明した。具体的には、販売管理システム上で行うデータの統計処理について、顧客と当社との間で認識の相違が発生していたのである。通常、販売管理システムは日々の収支の記録を残すだけでなく、その収支の記録から特定の統計処理を実行し、今後の経営計画にとって有益な情報を提供する。過去のプロジェクトでは、その統計処理の内容に認識の相違が見られたのだが、本プロジェクトにおいても同様の認識の相違が確認された。もしもチェックリストによる要件の確認がなかった場合、その認識の相違が見過ごされたまま開発フェーズに移行してしまい、深刻な手戻りが発生していた可能性がある。
• (5) 要件の定義漏れや定義誤りなどの不備を防ぐために計画した対応策②
• (5.1) プロトタイプの利用
  当社は多数のプロジェクトにおいて販売管理システムの開発を行っており、要件定義から運用までの一連の流れがどのように進むかを熟知している。その実績の多さから、販売管理システムの導入に関しては、当社の推奨機能や推奨設定をまとめたパッケージを用意している。そのパッケージは、いわば当社による販売管理システムのプロトタイプであり、多くの顧客に対してそのプロトタイプをカスタマイズする形で新たな販売管理システムの導入を提案してきた。多くの顧客から評価を得ているこの提案をX社に対しても行うことで、要件の定義漏れや定義誤りなどの不備を減らすことを目指した。
• (5.2) 対応策②の実施状況と評価
  プロトタイプのカスタマイズを基本とした提案には、業種の違いにかかわらず必要になる設計が含まれているため、プロジェクト全体を通して特に要件の定義漏れは発生しなかった。一方で、定義誤りと思われる事態は発生した。これは、販売管理システムのプロトタイプがもつ機能についてX社と当社との間で認識違いが生じていたことが原因であった。具体的には、製品のサイズとして当社のプロトタイプが「S/M/L」といった段階式の区別を想定していたのに対し、X社は数値による区別を想定しており、プロトタイプそれ自体に関する認識合わせが不足していたことが判明した。
• 回答作成直後の感想: まだ自分の好きなことばっかり書いているだけだが、架空のプロジェクトを想像することには慣れてきた気がする。何かしらテーマが与えられたときに、何かしらを書くことはできそうだ。あとはどれだけ模範回答に近づけるか。明日は自分の回答を模範解答と見比べて、どのような心構えで回答作成に取り組むべきかについて考えたい (2024年09月06日00時34分38秒)。
• 添削: たしかに、問題では「要件の定義漏れや定義誤りなどの不備を防ぐために計画した対応策」について書けと言っており、回答がそれについて書かれているのは当たり前だが、そのような不備が生じる流れを改めて述べておくことが大切。多少、設問アと重複する文が発生しても構わない。ただ、できれば別の言葉を用いて言い換えるくらいの工夫はしたい。あと、「プロトタイプ」の意味を誤解していた。「パッケージ」に近いものだと思っていたが、そうではなく「テスト機」のようなものだと考えておけばよいだろう。