プロジェクトマネージャ試験 午後2論文ネタ

作成日時：2024-08-01以前
更新日時：2024-08-01

PMなので指示をしろ。作業をするな

◯◯をした。ではなく、◯◯するように指示した。

書き方

• 記法系
  • 章は大文字で太く書け
  • -以上-を忘れるな
  • 英字(大文字は1マス1文字、小文字は2文字)、数字(1マス2文字、小数点も)
  • 行末の句読点は一緒に
  • 主語の明確化 + 主題とPREP
  • 形容詞と感想の削除。数値を使って具体的に。
• 実務経験ありと思わせる書き方
  • PMのスタンス。実施じゃなくて指示。詳細な技術情報は問われていない。
  • 実務経験っぽい、その時あったような出来事
  • どのフェイズ、どの時系列に置ける記述なのかを確認する。立ち上げ段階なのに試験やっていますとかはおかしいから。
• 言い回し
  • 社内で検討した結果～
  • 具体的には / 例えば (→具体例を求められている)
  • 情報基幹系システム
  • コスト面に言及するときは「予備費用」とか出しておけ
• 文字数稼ぎ
  • 問題文をそのまま転記
    • 要求部について回答していることを強調できる
• TIPS
  • 設問アと質問書は先に設問イウの構想を立ててから、それらが書きやすい内容を設定
  • システムの目標は対象のシステムの負の特徴の改善点
  • 質問票 2-10人 * 12ヵ月 110百万

課題/問題点ネタ

• ドキュメントが整備されていない。
• 想定外の不具合が発生し、作業が予定通りに進まない。
• 納期系：客都合でスタート遅れた
• 要員系：↑の所為で計画していたメンバを別の所にアサインして、再スタート時は確保できなかった
• 要員のスキル不足。
  • ベテランの追加。勉強会。ドキュメント整備。
• 顧客がシステムに詳しくない人へ変わった
  • →要件定義が進まない、仕様変更が増える
  • →プロトタイプ手法によりレビュー
  • +熟練技術者を計画より多く要因追加して仕様の確定を加速(クラッシング)
• 専門性の高い案件に入場。用語が分からなく生産性低下。
  • 用語集の作成と勉強会により予防と対策した。
• 重要ステークホルダはもうユーザでいいよ
  • UI駄目なら手戻りが発生しQCDに影響与えるし
  • シフトレフト
• 業務が分からんくて要件定義できない
  • 客先に出向して業務でもしとけ
    やらないことを明記(スコープマネジメント)
• 顧客が無知。ユーザ部門の意見取り入れ。使用性に難あり。要件が纏まらない。
  • プロトタイプ作ってユーザに触らせる。手戻りを減らせる。要件定義の精度を上げる。
• セキュリティが求められる→シンクラ
• 要件定義の曖昧さ、断片的→後工程で漏れや手戻り
• 用語集はシステムの理解を深める。パッケージ利用と絡める。
• 品質の問題点。あるチームの品質悪ければそいつが触ったとこ全部観ろ
• 顧客の目標をちゃんと書く
• メンバ構成とか
• 時間が絡んだら定量的に書け(稼働日まで後1ヵ月の段階で問題が起こったとか)
• 何かあったら顧客とヒアリング→話した内容と結果で文字埋めろ
• 週次の進捗報告じゃ駄目でした→じゃあ日次にして適宜最新の情報を
• 過去の同規模案件のプロジェクト報告書
  • 類似案件のPJ報告書から見積。指標値も過去案件から実績もってくる。要件の精度向上
• 承認・合意・同意・ヒアリング
• 変更要求/スコープ変更：PJの目的に貢献するかで優先度
• 性能要件を満たしていなくとも、リリース直後は許してくれる？
• 上流工程はユーザを巻き込め。手戻りを減らす為
• 炎上時の要員追加。ブルックス。ドキュメントを理由に問題なし
• 心理的安全性、みんなの前で説教
• 概要に客の目標書いておけ
• 具体性と定量
• 何故それをやらなかったかを書くといい　〇をやらず〇した
  • ブルックス
  • 学習コストとコミュニケーションコスト掛からんし
  • タスク分解可能性もあるからOK
• トラブル時の横展開
• 変更要求は変更管理チームのみ受け付ける
  • 各メンバ個人が変更要求を受け取ってはならない

リスクとは

• スキル不足に伴うスケジュール遅延
• パッケージの新バージョン。知識不足による遅延
• PG難易度→◯◯な理由で作業遅延。予防と対応
• セキュリティも
• 合併
• 個人情報→ルール
• 新人ぶち込め、QCD全てに問題を作ってくれるから。

代表モジュール

業績好調で応答遅延系

A社は中堅の商社である。業績は好調であり、社員数は年々増加している。
しかし社員数の増加により現在稼働している情報基幹系システムでは応答遅延など、業務の妨げとなる事象が多発するようになった。
現状のシステムでは社員数の増加に耐え切れなくなるため、現在稼働している情報基幹系システムを再構築することとなり、
ソフトウェア会社B社がこの案件を受注した。私はB社の社員であり、本案件のプロジェクトマネージャに任命された。

• 納期厳守を強く求められている
• 変更要求：外部連携システム、UI
• 業務の中核である外部IFが変更→時間内→対応は必須→スコープ狭める→新人教育にはデモ環とか
• スケジュール：新卒入社まで
• 性能：営業と経理の使う機能が非機能要件を満たしていないとか
• 納期短縮：パッケージの利用とそれに伴う問題点
• 人材管理サブシステムで情報のIN-OUTでネタ

事業環境の変化系

A社は中堅の衣料品販売会社である。実店舗とA社が運営するECサイト(以下、A社サイト)を通じて衣服を販売している。
近年、新型コロナウイルス感染症の世界的流行に伴い、自宅からでも利用できるECサイトの需要が高まった。
A社もこの影響を受け、A社サイトのアクセス数が急増した。A社はこれを好機ととらえ、売上増加を目標としてA社サイトを再構築を発注することとし、ソフトウェア会社B社がこの案件を受注した。私はB社の社員であり、本案件のプロジェクトマネージャに任命された。

• コストプラスインセンティブフィー
  • 短期納品の話だから

売上増加の為の具体的な改善点としては、UIの改善と応答速度の向上
改修理由は外部連携とタグの概念の欠如とか

• 定量評価：クレーム減、アクセス増加、遅延の撲滅
• ステークホルダ：配送会社C社
• 変更要求：外部連携システム、UI
• スケジュール：なるべく早く
• 性能：一部ページのレスポンスが遅いとか
• 納期短縮：パッケージの利用とそれに伴う問題点(機会損失)
• アジャイル系にも使える
• 「業務パッケージ」と言われたら使えない

どちらも納期が前提なので設問ウの感想部分に書けそう
納期守れたor短縮できたとかで

残業削減モデル

既存の情報基幹系システムがよくない。
使用性が悪いせいで無駄な残業が発生している。
平均残業20h × 社員100人 × 時給2000 = 400万。
⇒ウでの成果になる。どれだけ価値を出せたか。

• 顧客はなる早で何とかしたい
• 既存システムと並行してリリース
• とにかく残業を減らすことができるところから早期に解決していく
  • 優先順位の話につなげる。
  • 優先順位はどのような観点でつけたか
    • 残業時間削減が目的なので、効果が大きいものから。
• 順次移行方式。
• 不満点をヒアリング(早期のユーザー巻き込み、不満点のヒアリング)
  • ⇒優先度、基準はいかに残業を減らすこと繋がるか
• プロキシ・プロダクトオーナー

プロジェクトの特徴面

• 納期を変えられない
  • 設問イでそれへの対応、設問ウでそれに関する評価を書ける
• とりあえず”教育のため”で新人をぶち込まれたことにする
  • 色々問題を起こせるから、それに関して書ける。

ジャンルごとのネタ

1.変更要求(スコープ)

QCDに影響を与える。

基本的に発生した要求は受け入れなければならない。
それは基本的に顧客のビジネス価値に関連するため。
例）外部連携システムが1個追加された、それが無いとシステムに価値がなくなる！とか

優先度を決めて低いものは次ステップにするなどしてスコープ外にする

ネタ1 UI

普段から現行システムのUIに不満を持っている。
操作ミスにより損失が発生したりした。

特に利用頻度の高い、営業と経理部門からクレームが上がっている
→設問イウにつなげられる

問題と対策系

• UIにこだわり、五月雨式に要求が来る→変更取り消しとかが来て、QCD悪化
  • 週単位でまとめてもらう
  • UIの会議を開く
    • 変更必要性をその場で決め、変更要求を減らし稼働を下げる
  • プロトタイプ作成して要件をまとめ制度を高める
• 変更要求が纏まらん
  • 設計段階でモック作ってユーザに触らす
    • ユーザとはどこかを明確にすると書きやすい。経理？営業？
  • UI専門チームを作成し、要求をまとめる。
• 認識相違系は3団体巻き込め

評価と目標系

ユーザからのクレーム数や操作ミスによるインシデント数などを定量的に

ネタ その他

• 機能追加系は外部連携が増えたとか
• スコープ変える系
  • 納期と予算がきつい場合。サブシステムを適当に2個定義しておいて優先度低いサブシステムを後にしておけ
  • 業績好調モジュールなら、営業サブシステムと経理サブシステムを定義しておいて営業を優先するとか
    • 営業と経理で揉めたら、それはそれでステークホルダマネジメントにおけるコンフリクトの解消パターン

2.納期短縮/納期厳守

パッケージ(もしくは新バージョンのモジュール)の使用
それに伴う問題点

• まだ発見されていないバグによる品質低下
• 詳しい要員が居ない
  のでスケジュールや品質に問題がある
  それに伴う改善点
• 勉強会
• 詳しい要員をアサイン
• 販売会社にサポートしてもらえるように契約
• 古いバージョンを使ってもらうように説得
• 過去類似案件で使ってたからとか
  • 見積もりの精度
  • 学習コスト低く。ノウハウも自社に保有している
  • パッケージモジュールをそのまま使う。過去開発PGをそのまま使う
  • そん時のメンバをアサインしたり
  • 問題点は適合性 + 追加開発の要否
  • これだけじゃ書きづらいから新人をメンバにぶち込め
• データ移行ツール

3.チーム再編成

直前で開発言語を指定された

• 説得したが駄目だった
• 経験者は準備できない
• 現在の要員の経歴とスキルの調査、および個別にミーティングを行い対応できるかどうか
• ◯◯人中、経験あり/類似経験あり/未経験
• 未経験を退場させて、類似の人材を追加
• 経験者の内、ベテランをチームリーダ、そうじゃない奴は技術的な問い合わせとか。チートシート作成
• 開発当初は遅れが目立つ
• 勉強会とかは経験者が期待通りの働き
• 後半は生産性が上がり、遅れを取り戻せた
• 反省点系
  • チートシートの準備
  • 最初の遅れは教え方が下手
  • 勉強会とかOJTとかで教える技術を養わせる

4.人的資源系

• 全体通知はデイリー化キックオフ
• 未知のものは勉強会やマニュアルや詳しい人をアサイン。
  • 学びの場を提供する。具体的な例を添えて。
• (チームリーダに権限を委譲する場合)PMにエスカレーションする閾値の設定
• 連帯意識、全員でレビューとか

5.セキュリティ系

• 技術的なことは言わない。PMだから
• 体制づくりやセキュリティポリシを作成する
• キックオフミーティングに置けるセキュリティ教育
• クリーンデスク、クリーンスクリーン
• ローカルに本番データ使うならマスク
• これらのモニタリングはログとか収集しとけ

6.リスク系

• 処理件数増加とかが書きやすいか
• 体調悪い社員が参加して途中退場とか
• 分析(定性「影響度と発生確率」と定量)→対策
• 対応するか否か、どう監視するか
• 発生したらどうするか
• 外部ステークホルダによるリスク
  • 合併によりシステムの仕様変更
    • 要件定義で用語が違う、または複雑で分からん
    • →精度が低い、時間がかかる
      • →用語集を作るとか
  • WMSで対応する会社数追加とか

7.ステークホルダの利害系

• 特定部門がUI変えたくないってごねる
  • 業務効率下がるって
• 説明するっきゃない
  • 既存問題点が解決されるということ
  • なんならUI既存っぽくするよ
  • プロト提示して何がいいかを模索

8.品質系

• 操作性か性能か
• 操作性→UI→納期ギリの案件→手戻りは許されない、とかで
• レビュー指摘件数を定量的な奴に。上限下限
• 原因分析→特定メンバ→スキル不足→ベテラン指導→再レビュー

9.遅延系

• 設計、製造、テストが同一人物
  • 時間とコストが無いから
• 進捗0で嘘の申告
  • 即退場 + リスケとクラッシングで対応
  • 反省：報告内容の裏付け
    • 証跡として成果物を提示
• レビューがないからこのモジュールは危険

10.現場からの反発

慣れたUIを変えたくない、学習コストを発生させたくないなどで現場からの反発が発生する。
説得する。

• 設計段階で現場の人を招く
  • シフトレフト
  • 早期のレビュー・ヒアリング
  • プロトタイプを触ってもらう
• リプレイスにより現状より改善されることを説明する
• 説明会を開く
• 現場の上長から説得してもらう
• UIをなるべく変えない。
  • リプレイスの起因となる場所だけ変更する。
• マニュアルの整備

概要と特徴

概要：文字通り概要。何をするシステムなのか。
特徴：短期間で完成させなきゃとか、要員が新人だからスキル不足とか、要員確保できないとか、なんかpkg使ったりとか

「PJの概要」もしくは「PJの特徴」と2パターンあるが、どっちだろうとどっちも書く。
最初に概要を軽く書いた後に特徴を説明。設問イウに関わるものを記載する。◯◯が求められる。とか。
目標も書かされる場合もあるので、設問イウに関わるものを記載する。
→性能低下/使いづらい/応答遅延/業務に支障 →それらを改善するための案件を受注。目標は左記の改善。とすれば書ける。

流れは、発注先説明→プラスな状況→設問イウに繋がるマイナスの状況→自身の紹介
問題発生が思いつかなければ
設問アの最後：「◯◯しなければならなくなった。」とか。→設問イ等に繋げられる

特徴は箇条書きでイウに書きやすいものを

だいたい納期と新人関連を書けば何とかなる。

プロジェクトの特徴としては以下の2つである。

(1)スケジュールに余裕が無く、短期間での納品が求められた。
A社都合により、プロジェクトのスタートが3ヵ月遅れた。
翌年度の4月には50人以上の新卒が入社予定であり、既存のシステムでは更なる応答遅延が予想された。
これ以上の遅延は業務に支障をきたす為、新卒の入社前に納品をしなければならない。

(2)プロジェクトの要員が当初計画よりも少なくなった。
スタートが遅れたため、アサイン予定のメンバは別のプロジェクトに割り振られた。
プロジェクトの再スタート時には要員の確保の目途が立たず、当初計画より少ない要因で開発することとなった。

問題文と論点のリンク

問題文に「〇〇が重要である」と書かれたら「〇〇が重要であるため××した」と論述。

その他メモ

• トラブったら社長にチクれ
• 顧客の上長に説得してもらう
• 設問アの文字数が長いのは高難易度の傾向
  • 根拠は無い
• 超上流工程関連の事を書けば、やったことと成果を的確に論述できるか？

設問イウ

2.1.期待した効果
短い。もう当たり前のことをそのまま書け
問題点や課題をどう解決できそうか
◯◯できれば◯◯の可能性があり、◯◯できる。

問イの対策はあくまで対策であってまだ実施していない。計画である。
実施状況でやったことを書く

2.2.有効利用を図る上での課題
2.3.対策と実施状況
**実施状況**→数値を使ってどんな状態か。評価ではない。どうやったか。
**実現状況**→実現した結果の状況。どういう結果になったか。
これらは数値を使って具体的に

3.期待した効果の実現状況と評価、および今後の改善点について
3.1.期待した効果の実現状況と評価
**設問イに対して出来た事**
効果は↑+効果：教育とか。新人の成長。プロセス資産形成？蓄積？とか

3.2.今後の改善点
ドキュメント整備とか。**評価でのマイナス面に対する対応**。
最後:ドキュメント化して次回の開発に役立てたい
◯◯すべき。なので◯◯していきたい。とか。
課題は、ドキュメント化、標準化、ノウハウ展開とか
今回の件を教訓に～していきたいと思う。

-以上-
**↑絶対に忘れるな。右寄せである。**