令和3年 秋 アジャイル開発
プロダクトオーナーの役割 問1(1)
本プロジェクトのプロダクトバックログアイテムを作成・管理する（エ）
スクラム：アジャイル開発のフレームワーク
プロダクトオーナー・スクラムマスター・開発者で構成
プロダクトオーナー
プロダクトに必要な機能を定義し、プロダクトバックログの追加・削除・順位付けを行う。
開発への投資に対する効果を最大にすることに責任を持つ。
スクラムマスター
スクラムチーム全体が自律的に共同できるようにファシリテータ的な役割を持つ。
メンバーの相談に乗ったり、開発チームが抱えている問題を取り除いたりする。
スクラム全体をうまく回すことに責任を持つ。
開発チーム
実際に開発を行うチーム。
バックログに入っている項目を完了状態にし、プロダクトの価値を高めていくことに責任を持つ。
人材育成を踏まえた体制 問1(2)
スクラム開発要員を育成し、本格的なスクラム開発の人材を確保する
問題文に「本プロジェクトの方針に沿った人材育成の観点から」とあるので、対象になる箇所を確認する。
→スクラム経験者が少ない。試行開発の段階を設け、スクラム開発の理解を深め、スクラム開発要員を育成・・・などの部分があるため、それを根拠に文章を作成する。
競合他社に勝つために 問2(1)
顧客からの要求に競合相手より迅速に対応すること
競合他社が1年に1～2回のリリースに対し、P社は3か月に1回（1年に4回）とした狙いの問い
問題文に「顧客の特性を考慮して」ともあることから関係する箇所を確認する。
「要求が満たされないと顧客は簡単に競合他社に移ってしまう」という記載があるため、
リリースサイクルが競合他社より短くすれば、顧客の要求を迅速に満たせ、顧客の囲い込みにつなげられる。
それを根拠に文章を作成する。
時間と残り作業を折れ線グラフで表す進捗管理 問2(2) b
バーンダウンチャート
アジャイル開発で進捗管理によく用いられるグラフ
計画と実績の差分が視覚的に把握できるので便利
左端上：プロジェクト開始日時
右端下：プロジェクトの完了予定日時
横軸：時間経過
縦軸：残り作業量
グラフ上の線：3本
1直線：開始から終了予定までの線
2理想線：計画上の進捗
3実績線：実績の進捗
外部の見た目動作は変えず、ソースコードの内部構造を整理 問2(2) c
リファクタリング
長期間にわたる開発や頻繁な仕様変更により、コードが複雑化し、柔軟性や拡張性が低下することがあるため、機能拡張や保守性などの向上を目的として実施される
何か問題が発生した際は、プロセスの確立が必要 問3(1)
T氏とプロダクトバックログアイテム変更に伴う対応方法を決めておく
アジャイル開発経験のあるプロダクトオーナと経験のないユーザーチームとの間で、プロダクトバックログアイテム（要件）の変更に関して認識齟齬が発生してしまった。
経験の有無はあるかもしれないが、そもそもプロダクトバックログアイテムを追加する際の手順があらかじめ定まっていなかったことが一番の原因である。
その旨を文章にする。
プロダクトバックログの計算 問3(2)
50
リリース1で開発予定だったもの：優先順位A、優先順位B（進捗によりけり）
→※T氏からのプロダクトバックログがリリース1に追加される
S-1～S-4時点で優先順位Aの未開発のプロダクトバックログ＝18pt
残り（S-5,S-6,リリース2のS-7~12）のベロシティはすでに終了しているベロシティの平均値を用いる→S-1～S-4 の平均＝9pt
9pt×S-5,S-6(計2)＝18pt
よってリリース1にて優先順位Aは間に合わせることが可能の判断ができる。
しかし優先順位Bに関してはリリース2に先送りせざるを得ないことがわかる。
完成見込みのストーリーポイント
9pt×リリース2のS-7~12(計6)＝54pt
残っているプロダクトバックログ
小4×2pt＋中4×3pt＋大6×5pt＝50pt
→ベロシティ上の問題はない
※ベロシティ：開発速度
令和5年 秋 システム開発プロジェクト
アジャイル開発の利点（色々コロコロ変わりそうなら・・・） 問1(1)
頻繁なスコープの変更を想定する
アジャイル開発：顧客の要求に応じて、迅速かつ適応的にソフトウェア開発を行う軽量な開発手法
- 動くソフトウェアを早期に提供できる
- 反復型のアプローチにて、ビジネスニーズの変化に俊敏に対応できる
- 現物での仮説検証サイクルが行え、顧客価値を確認しながら開発を進められる
すでに記載されている「PoCによる仮説検証」や「早期リリース」以外にアジャイル開発である必要があるのが「頻繁なスコープ変更を想定」とのことなのでそれを記載する
できないものは依頼しよう 問1(2)
機械学習技術の習得の時間がない
文章の中で「本プロジェクトのリリースは6か月」、「自社だけで機械学習技術を習得しようとしたら2年かかった話を聞いている」とあるので、スケジュール的に自社だけで技術習得するには時間が足りない。そのためベンダーに技術支援を依頼する判断になる。
ベンダー比較表の見方 問2(1)
Q
B役員の指示とそれに当てはまるであろう評価項目
- 「機械学習技術を習得する支援をしてもらうこと」→定着化
- 「顧客の様々な年代層が容易に利用できるシステム開発を支援できる」→使用性
上記2点が最高得点なのがQなため。
また文章は評価項目の字句を使用するとのことなのでその形で文章を記載する
成果物があいまいな契約 問2(2)
実現性を検証することが目的である（イ）
本プロジェクトのPoCは、具体的な成果物を完成させることではなく、これから提供しようとしているサービスの価値と実現性を検証することを目的としているので、請負のような成果物を目的とする契約ではなく、準委任のような業務の遂行自体が目的となる契約のほうがいい。
- 請負：受託者が成果物の完成に責任を負う。成果物の内容が具体的に特定できる場合に選択
- 準委任：作業自体の実施を目的とする場合や成果物の内容が具体的に特定できない場合に選択
ベンダーに確認すること 問2(3)
システム開発フェーズの回復力を確かめるため
問題文に「プロジェクトが進むにつれて明らかになる未知のリスクへの対策として、プロジェクトの回復力（レジリエンス）を高める対策が必要と考えた」とあり、システム開発フェーズの途中における対応策をベンダーに確認しようとしていることから、このプロジェクトの回復力を確認しようとしている。
プロダクトオーナーへアサインした理由 問3(1)
マーケティング業務と開発プロジェクト参加の経験があるから
プロダクトオーナーのスキル
業務領域のニーズを理解するスキルと、システム開発をコントロールするスキル
スキルと経験の中で「マーケティング業務の専門家」と「システム開発プロジェクトに参加した経験」とあるためその旨を記載する
マーケティング部で測定するもの 問3(2)
重要成功原因の指標の値
MVP：顧客に価値を提供できる実用最小限の機能を持つ製品のこと
「PoCフェーズの評価基準には、顧客関係性の強化の達成状況など、定量的な評価が可能な重要成功原因の指標を用いる」とあるのでMVPを試用してその評価を行うために重要成功原因の指標を測定することがわかる
令和4年 秋 リスクマネジメント
リスクを階層化して整理する手法 問1
RBS（Risk Breakdown Structure）
特定されたリスクをカテゴリでグループ化し、リスク区分を階層化して整理する手法
WBSのリスク版みたいなところ
リスク特定ができない理由 問2(1)
AIに知見のあるT社が参画していないから
※K社にはAI機能の利用の経験がないことを理由に挙げてもいいと思う
「リスクの特定は7月」とのことなので、リスク工程の期間にはT社の支援がない状態なため
リスクに関する情報収集や原因の分析に有効な図 問2(2)
特性要因図（ウ）
特性（結果）とそれに影響を及ぼしたと思われる要因（原因）の関係を体系的に表した図
デシジョンツリー 問3(1)
遅延なし
T社との契約を変更した際、U氏1人だけで8回/週までの問い合わせに回答可能となる。
よって問い合わせに対する回答の遅れはなくなる。
デシジョンツリー（決定木分析）
選択肢を洗い出し、それらを評価・比較するために使用する
追加コストの期待値 問3(2)
工番：2
期待値：80
工番1：期待値200万円
10万円×20日＝200万円
スケジュール遅延はなし
工番2：期待値80万円
「要件定義が当初予定から最大で5日遅れる」
「遅延する稼働日は1日あたり20万円の追加コストが発生する」ので
20万円×5日＝100万円
追加コスト30％の確率で150万円、70％の確率で50万円
150万円×0.3＋50万円×0.7＝80万円
リスクマネジメントの進め方不足 問4
プロジェクトの進行に従ってリスクの特定を継続して行う
プロジェクトのリスクマネジメントは期間を通して継続的に出現し、特定は繰り返し実施しないといけないプロセスとなる。
「これまでに特定したリスクを対象に」とのことなので潜在リスクへの配慮が足りていない。
プロジェクトの進行に合わせ定期的、反復的にリスク特定の実行が必要な旨記載する
令和7年 春 CCPM法スケジュール管理
なぜ加重総和法を採用したのか 問1（1）
費用及び要求充足度を重要視するため
- 費用を抑える方針
- どうしてもSaaSの標準機能に合わせられない機能は業務要求を追加
上記のように評価項目ごとの点数に重みを乗せる必要があったため、
単純総和方式ではなく、加重総和方式である必要があった。
加重総和法で選定された会社は 問1（2）
k
- 再評価値の合計が最も大きいベンダーを選定
- 一つでも評価点数が2点以下の評価項目があるベンダーは選定しない
M社は評価点数が2点の項目があるので選定から除外
その他会社は評価項目の重みを乗じた値の総和を計算する
最遅開始日 問2（1）
41
- 最早開始日：先行作業の完了を前提とし、その作業を最も早くできる日
- 最遅開始日：プロジェクト完了を遅らせないことを前提とし、その作業を最も遅く開始できる日
クリティカルパス：A（30日）→C（40日）→D→G
Bが30日のため、逆算すると41日目が最遅開始日となる
いたずらにバッファを消費しない 問2（2）
バッファを消費しなくなる
「仕事は完成のために与えられた時間まで膨張する」パーキンソンの法則
作業時間に余裕があるとだらつきやすい
クリティカルチェーン法では個別バッファを設けず、全体でバッファ管理する。
バッファの種類 問2（3）
c：プロジェクト（エ）
プロジェクトのクリティカルパスを守るため、クリティカルチェーンの最後に配置
d：合流（イ）
クリティカルパス上にない作業の遅れがクリティカルパス上のタスクに影響を与えることを防ぐために作業の合流地点に配置
完成予定日より遅れる日数 問3（1）
1
クリティカルパスがA→C→D→GからCとDが要因の追加投入（クラッシング）で分割され
A→C→D1／D2→Gとなった。
Z社では「所要日数のうち10％の日程をアクティビティごとに安全余裕（バッファ）として設定していた」とのことなので
A：3日 B：3日 D1／D2：3日 G：2日 計11日のバッファが設けてあった。
D2が12日遅れた場合、完成予定日より1日遅れる。
追加投入 問3（2）
J3チームだった要員をD2に投入する
問題文を読むと
- J社内でC～F間のシフト調整が可能
- J1,J2,J3とチーム編成されている
- 並行作業D1（J1）は遅延していないが余裕はない
- J3はF作業終了後に現行システムの維持管理対応に戻る
- これらのアクティビティ以外は順調に進捗していた
これらを踏まえるとJ3チームの予定を変更しD2へ再配分することが可能
参考：https://www.ap-siken.com/apkakomon_pm.php
コメント