メインコンテンツへスキップ
見出し画像

【完全攻略講座 #26】プロジェクトマネジメント 完全攻略|WBS・クリティカルパス・EVM・見積り・リスク・品質管理

    #25では、教師あり学習・教師なし学習・強化学習・評価指標・ディープラーニング・生成AIなど、AI・機械学習の基礎を学びました。

    今回からは、マネジメント系に入ります。

    最初に扱うのは、科目Aでも計算問題・用語問題の両方が出題されやすいプロジェクトマネジメントです。

    プロジェクトマネジメントでは、

    「WBSは何のために作るのか」
    「クリティカルパスはどう求めるのか」
    「EVMのPV・EV・ACは何を表すのか」
    「SV・CV・SPI・CPIから何が分かるのか」
    「工数・期間・人数はどう計算するのか」
    「リスクへの対応方法には何があるのか」

    といった用語の意味+計算方法をセットで理解することが重要です。

    今回は、

    プロジェクト → WBS → スケジュール → アローダイアグラム → クリティカルパス → 見積り → EVM → リスク → 品質

    という順番で体系的に整理します。

    なお、#38「科目A 頻出計算問題 完全攻略」でもEVMなどを扱いますが、#38は計算演習・総復習が中心です。プロジェクトマネジメントとしての仕組みや意味は本記事が主担当です。


    1.今回の学習ポイント

    画像

    2.プロジェクトとは

    プロジェクトとは、

    特定の目的を達成するために、開始と終了を定めて実施する一時的な活動

    です。

    たとえば、

    • 新しいシステムを開発する

    • Webサービスを構築する

    • 基幹システムを移行する

    • 新製品を開発する

    などがあります。


    3.プロジェクトと定常業務

    プロジェクトは日常的に繰り返す業務とは異なります。

    画像

    4.プロジェクトマネジメント

    プロジェクトマネジメントとは、

    プロジェクトの目標を達成するために、計画・実行・監視・調整などを行うこと

    です。

    管理対象には、

    • スコープ

    • スケジュール

    • コスト

    • 品質

    • リスク

    • 資源

    • コミュニケーション

    などがあります。


    5.プロジェクトマネージャ

    プロジェクトマネージャ(PM)は、

    プロジェクト全体を管理し、目標達成へ導く役割

    を担います。

    単に進捗だけを見るのではなく、

    • スケジュール

    • コスト

    • 品質

    • リスク

    • ステークホルダ

    などを総合的に管理します。


    6.ステークホルダ

    ステークホルダとは、

    プロジェクトへ影響を与える、またはプロジェクトから影響を受ける個人・組織

    です。

    たとえば、

    • 顧客

    • 利用者

    • プロジェクトメンバ

    • 経営層

    • ベンダ

    • 関係部署

    などがあります。


    7.プロジェクトの制約

    プロジェクトでは、

    • スコープ

    • スケジュール

    • コスト

    • 品質

    などが互いに影響します。

    たとえば、

    納期を短縮する
    ↓
    人員追加
    ↓
    コスト増加

    ということがあります。

    そのため、一つの要素だけを見るのではなく、全体のバランスを管理することが重要です。


    8.スコープ

    スコープとは、

    プロジェクトで実施する作業や成果物の範囲

    です。

    「何を作るのか」「どこまでをプロジェクトに含めるのか」を明確にします。


    9.スコープクリープ

    スコープクリープとは、

    適切な管理を行わないまま、プロジェクトの作業範囲が徐々に拡大していくこと

    です。

    たとえば、

    「この機能も少し追加して」
    「ついでにこの画面も変更して」

    といった変更を管理せず受け入れ続けると、納期やコストへ影響します。


    10.WBS

    WBS(Work Breakdown Structure)とは、

    プロジェクトの作業を、管理しやすい単位まで階層的に分解したもの

    です。

    プロジェクトマネジメントで非常に重要な用語です。


    11.WBSのイメージ

    たとえばWebシステム開発なら、

    Webシステム開発
    ├ 要件定義
    ├ 設計
    │ ├ 画面設計
    │ └ DB設計
    ├ 開発
    │ ├ フロントエンド
    │ └ バックエンド
    └ テスト

    のように作業を分解します。


    12.WBSの目的

    WBSを作成すると、

    • 必要な作業を把握しやすい

    • 作業漏れを防ぎやすい

    • 担当者を割り当てやすい

    • 工数を見積もりやすい

    • スケジュールを作成しやすい

    • 進捗を管理しやすい

    というメリットがあります。


    13.ワークパッケージ

    WBSで管理可能なレベルまで分解した作業単位をワークパッケージと呼びます。

    つまり、

    大きなプロジェクトを小さな作業へ分解

    することで管理しやすくします。


    14.WBSと組織図

    混同しないようにしましょう。

    WBS
    → 作業を分解

    組織図
    → 組織・人員構成を表現

    です。

    WBSは、

    誰がいるか

    ではなく、

    何をするか

    を整理します。


    15.ガントチャート

    ガントチャートとは、

    作業項目と実施期間を横棒で表した図

    です。

    たとえば、

    画像

    のように表します。


    16.ガントチャートの特徴

    ガントチャートでは、

    • 各作業の開始時期

    • 終了時期

    • 作業期間

    • 作業の重なり

    • 進捗状況

    などを視覚的に確認できます。

    一方で、複雑な作業の依存関係やクリティカルパスを把握する場合は、ネットワーク図などが有効です。


    17.マイルストーン

    マイルストーンとは、

    プロジェクトにおける重要な節目

    です。

    たとえば、

    • 要件定義完了

    • 設計完了

    • テスト開始

    • 本番リリース

    などをマイルストーンとして設定します。

    通常、作業期間そのものではなく、重要な到達点を表します。


    18.アローダイアグラム

    アローダイアグラムは、

    作業の順序関係や所要時間をネットワーク形式で表す図

    です。

    科目Aでは、ここからクリティカルパスを求める問題が重要です。


    19.作業の依存関係

    たとえば、

    A完了後にB開始
    B完了後にC開始

    なら、

    A → B → C

    という依存関係になります。

    一方、A完了後にBとCを並行して実施できる場合は、経路が分岐します。


    20.ダミー作業

    アローダイアグラムでは、作業間の順序関係だけを表すためにダミー作業を利用する場合があります。

    ダミー作業は、

    実際の作業を伴わず、所要時間0として依存関係だけを表す

    ためのものです。


    21.クリティカルパス

    クリティカルパス(Critical Path)とは、

    プロジェクト全体の最短完了期間を決定する経路

    です。

    基本的には、

    開始から終了までの経路のうち、所要時間が最も長い経路

    を探します。


    22.クリティカルパスの例

    次の2経路があるとします。

    A → B → D
    3日 + 5日 + 2日 = 10日

    A → C → D
    3日 + 4日 + 2日 = 9日

    この場合、

    A → B → D

    がクリティカルパスです。

    プロジェクト全体の最短完了期間は10日です。


    23.なぜ最長経路なのか

    一見すると、

    「最短完了期間なのに、なぜ最長経路?」

    と感じるかもしれません。

    すべての必要な作業が完了しないとプロジェクトは終了できません。

    そのため、

    最も時間がかかる経路が終わるまで待つ必要がある

    からです。


    24.クリティカルパス上の遅延

    クリティカルパス上の作業が1日遅れると、他の調整を行わない限り、

    プロジェクト全体も1日遅れる

    可能性があります。

    そのため、クリティカルパス上の作業は特に重点的な管理が必要です。


    25.余裕時間

    余裕時間(フロート/スラック)とは、

    プロジェクト全体の完了時期を遅らせずに、作業を遅らせることができる時間

    です。

    一般に、クリティカルパス上の作業は余裕時間が0になります。


    26.最早開始時刻と最遅開始時刻

    ネットワーク図では、

    最早開始時刻
    → 最も早く作業を開始できる時刻

    最遅開始時刻
    → 全体の完了を遅らせずに開始できる最も遅い時刻

    を求める場合があります。

    その差から余裕時間を考えることができます。


    27.クリティカルパスの求め方

    基本手順は、

    ① 開始から終了までの経路を確認
    ↓
    ② 各経路の所要時間を合計
    ↓
    ③ 最も長い経路を探す

    です。

    複雑な問題では、各作業の依存関係を正確に読み取ることが重要です。


    28.工数

    工数とは、

    作業を完了するために必要な作業量

    です。

    代表的な単位には、

    • 人時

    • 人日

    • 人月

    などがあります。


    29.人月

    1人月は、

    1人が1か月作業する量

    を表します。

    たとえば、

    3人 × 4か月
    = 12人月

    です。


    30.工数・人数・期間

    単純化した問題では、

    工数 = 人数 × 期間

    として計算します。

    したがって、

    期間 = 工数 ÷ 人数

    です。


    31.工数計算の例

    必要工数が24人月で、6人で作業するとします。

    24 ÷ 6
    = 4か月

    となります。

    ただし、実際のプロジェクトでは人数を増やせば必ず反比例して期間が短縮できるとは限りません。


    32.人数を増やせばよいとは限らない

    プロジェクトでは人数が増えると、

    • コミュニケーション

    • 教育

    • 作業調整

    • 管理

    などの負担も増えます。

    また、作業によっては並列化できません。

    したがって、

    人数2倍=期間半分

    とは限りません。


    33.見積り

    プロジェクト開始時には、

    • 規模

    • 工数

    • 期間

    • コスト

    などを見積もります。

    代表的な見積り方法として、

    • 類推見積り

    • パラメトリック見積り

    • ボトムアップ見積り

    • 三点見積り

    などがあります。


    34.類推見積り

    類推見積りとは、

    過去の類似プロジェクト・作業を参考に見積もる方法

    です。

    比較的簡単に見積もれる一方、類似性が低い場合は精度が下がる可能性があります。


    35.ボトムアップ見積り

    ボトムアップ見積りとは、

    細かい作業単位ごとに見積もり、それらを積み上げて全体を求める方法

    です。

    WBSで作業を細分化した後に利用しやすい方法です。


    36.三点見積り

    三点見積りでは、

    • 楽観値

    • 最可能値

    • 悲観値

    を利用します。

    PERTで用いられる代表的な期待値は、

    期待値 =(楽観値+4×最可能値+悲観値)÷6

    です。


    37.三点見積りの例

    楽観値4日、最可能値7日、悲観値16日なら、

    (4+4×7+16) ÷ 6
    = 48 ÷ 6
    = 8日

    です。


    38.ファンクションポイント法

    ファンクションポイント法(FP法)とは、

    利用者から見たシステムの機能量を基に、ソフトウェア規模を見積もる方法

    です。

    プログラムの行数そのものではなく、

    システムが提供する機能

    に着目します。


    39.ファンクションポイント法の特徴

    代表的には、

    • 外部入力

    • 外部出力

    • 外部照会

    • 内部論理ファイル

    • 外部インタフェースファイル

    などを評価します。

    科目Aでは、

    利用者から見た機能量による規模見積り

    と覚えておくことが重要です。


    40.LOC法

    LOC(Lines of Code)を利用して、

    プログラムのソースコード行数から規模を見積もる

    考え方もあります。

    FP法との違いは、

    LOC
    → コード量

    FP
    → 利用者から見た機能量

    です。


    41.EVM

    EVM(Earned Value Management)とは、

    プロジェクトの進捗とコストを、金額などの共通尺度を使って統合的に管理する方法

    です。

    科目Aでは非常に重要な計算分野です。

    まず、

    • PV

    • EV

    • AC

    の3つを覚えます。


    42.PV

    PV(Planned Value:計画価値)とは、

    現時点までに計画上完了しているはずの作業の予算額

    です。

    簡単に言えば、

    予定ではどこまで進んでいるはずか

    を金額で表します。


    43.EV

    EV(Earned Value:出来高)とは、

    実際に完了した作業を、当初の予算額で評価した値

    です。

    簡単に言えば、

    実際にどこまで仕事が終わったか

    です。


    44.AC

    AC(Actual Cost:実コスト)とは、

    実際に発生したコスト

    です。

    つまり、

    実際にいくら使ったか

    を表します。


    45.PV・EV・AC

    覚え方は、

    PV
    → Plan=予定

    EV
    → Earned=出来高

    AC
    → Actual=実際のコスト

    です。

    この3つを正確に区別できれば、EVM計算がかなり楽になります。


    46.EVMの例

    ある時点で、

    • PV=100万円

    • EV=80万円

    • AC=90万円

    だったとします。

    これは、

    計画上は100万円分終わっている予定
    実際には80万円分しか終わっていない
    そのために90万円使った

    という状態です。


    47.SV

    SV(Schedule Variance:スケジュール差異)は、

    SV = EV − PV

    です。


    48.SVの見方

    SV > 0
    → 計画より進んでいる

    SV = 0
    → 計画どおり

    SV < 0
    → 計画より遅れている

    です。

    先ほどの例なら、

    80 − 100
    = −20万円

    なので、スケジュールは遅れています。


    49.CV

    CV(Cost Variance:コスト差異)は、

    CV = EV − AC

    です。


    50.CVの見方

    CV > 0
    → 予算面で良好

    CV = 0
    → 予算どおり

    CV < 0
    → コスト超過

    です。

    先ほどの例なら、

    80 − 90
    = −10万円

    なので、コスト超過です。


    51.SPI

    SPI(Schedule Performance Index:スケジュール効率指数)は、

    SPI = EV ÷ PV

    です。


    52.SPIの見方

    SPI > 1
    → 計画より進んでいる

    SPI = 1
    → 計画どおり

    SPI < 1
    → 遅れている

    です。

    先ほどの例なら、

    80 ÷ 100
    = 0.8

    なので、計画より遅れています。


    53.CPI

    CPI(Cost Performance Index:コスト効率指数)は、

    CPI = EV ÷ AC

    です。


    54.CPIの見方

    CPI > 1
    → コスト効率が良い

    CPI = 1
    → 予算どおり

    CPI < 1
    → コスト効率が悪い

    です。

    先ほどの例なら、

    80 ÷ 90
    ≒ 0.89

    なので、コスト効率は良くありません。


    55.SV・CV・SPI・CPI

    画像

    ここは必ず覚えておきましょう。


    56.EVMの覚え方

    まず、

    スケジュールはPVと比較

    コストはACと比較

    と覚えます。

    したがって、

    Schedule
    → EV − PV
    → EV ÷ PV

    Cost
    → EV − AC
    → EV ÷ AC

    です。

    どちらもEVが先頭になります。


    57.BAC

    BAC(Budget at Completion)とは、

    プロジェクト完了時点の当初予算

    です。

    つまり、

    プロジェクト全体で最初に予定していた予算

    と考えられます。


    58.EAC

    EAC(Estimate at Completion)とは、

    現在の状況を踏まえた、プロジェクト完了時の総コスト予測

    です。

    問題の前提によって計算方法が異なります。

    たとえば、現在のコスト効率が今後も続くと仮定する場合、

    EAC = BAC ÷ CPI

    とすることがあります。


    59.ETC

    ETC(Estimate to Complete)とは、

    残りの作業を完了するために必要と予測されるコスト

    です。

    関係の一例として、

    ETC = EAC − AC

    があります。


    60.VAC

    VAC(Variance at Completion)とは、

    完了時点での予算差異

    です。

    VAC = BAC − EAC

    で求められます。

    VAC < 0なら、完了時に予算超過が予測されます。


    61.EVM全体

    整理すると、

    画像

    62.リスク

    リスクとは、

    発生した場合にプロジェクトの目標へ影響を与える不確実な事象・状態

    です。

    リスクは必ずしも悪影響だけとは限りませんが、試験では特に脅威となるリスクへの対応が重要です。


    63.リスク管理

    リスク管理では、概念的に、

    リスクを特定
    ↓
    分析・評価
    ↓
    対応を計画
    ↓
    監視

    という流れで管理します。


    64.リスクの評価

    リスクは一般に、

    発生確率 × 影響度

    などを考慮して優先順位を決めます。

    たとえば、

    画像

    のように評価します。


    65.リスク回避

    回避(Avoid)とは、

    リスクの原因となる活動そのものを変更・中止して、脅威をなくす対応

    です。

    たとえば、リスクの高い技術を採用しない、といった対応です。


    66.リスク軽減

    軽減(Mitigate)とは、

    リスクの発生確率や影響を小さくする対応

    です。

    たとえば、

    • 事前テストを増やす

    • バックアップ要員を用意する

    などです。


    67.リスク転嫁

    転嫁(Transfer)とは、

    リスクによる影響や責任の一部を第三者へ移す対応

    です。

    たとえば、

    • 保険

    • 契約による外部委託

    などがあります。

    ただし、リスクそのものが消えるとは限りません。


    68.リスク受容

    受容(Accept)とは、

    リスクを認識した上で受け入れる対応

    です。

    対策コストがリスクの影響より大きい場合などに選択されることがあります。


    69.4つのリスク対応

    画像

    70.コンティンジェンシープラン

    コンティンジェンシープランとは、

    リスクが実際に発生した場合に実施する対応計画

    です。

    「発生しないようにする対策」だけでなく、

    発生したらどうするか

    も事前に考えておきます。


    71.リスク登録簿

    プロジェクトで特定したリスクについて、

    • 内容

    • 発生確率

    • 影響

    • 優先度

    • 対応策

    • 担当者

    などを記録して管理するものをリスク登録簿と呼びます。


    72.品質管理

    プロジェクトでは、

    納期と予算を守れば成功

    とは限りません。

    成果物が要求された品質を満たすことも重要です。


    73.品質

    品質とは単純に、

    高性能であれば高品質

    という意味ではありません。

    プロジェクトでは、

    要求された仕様・品質基準を満たしているか

    という観点が重要です。


    74.品質保証と品質管理

    品質保証
    → 適切なプロセスや仕組みによって、品質を確保できるようにする

    品質管理
    → 成果物などを測定・確認し、品質基準を満たしているか確認する

    という違いで整理できます。


    75.レビュー

    レビューは、

    成果物を関係者が確認し、問題や欠陥を早期に発見する活動

    です。

    開発工程におけるレビューの詳細は#19で扱いました。

    プロジェクトマネジメントでは、

    品質確保のための活動の一つ

    として位置付けます。


    76.パレート図

    パレート図は、

    項目を件数などの大きい順に並べた棒グラフと、累積比率の折れ線を組み合わせた図

    です。

    品質問題の原因を分析し、

    影響の大きい問題から重点的に対策

    するときなどに利用します。


    77.特性要因図

    特性要因図は、

    問題となる結果と、その原因候補の関係を魚の骨のような形で整理する図

    です。

    フィッシュボーン図とも呼ばれます。

    原因分析に利用します。


    78.管理図

    管理図は、

    工程の状態を時系列で監視し、異常な変動が発生していないか確認する図

    です。

    通常、

    • 中心線

    • 上方管理限界

    • 下方管理限界

    などを利用します。


    79.ヒストグラム

    ヒストグラムは、

    データを区間ごとに集計し、分布を棒グラフで表したもの

    です。

    データの、

    • ばらつき

    • 分布

    • 偏り

    などを確認できます。


    80.散布図

    散布図は、

    2つの変数の関係を点として表した図

    です。

    たとえば、

    テスト時間と障害件数

    など、2変数の関係を確認するときに利用します。

    ただし、相関が見られても、それだけで因果関係があるとは限りません。


    81.品質管理で使う図

    画像

    82.プロジェクトの変更管理

    プロジェクト途中で、

    • 要件

    • スケジュール

    • コスト

    • 設計

    などの変更が発生することがあります。

    重要なのは、

    変更を無条件で受け入れるのではなく、影響を評価して管理する

    ことです。


    83.変更管理の流れ

    概念的には、

    変更要求
    ↓
    影響分析
    ↓
    承認・却下
    ↓
    計画更新
    ↓
    実施・追跡

    という流れになります。

    これによってスコープクリープなどを防ぎます。


    84.コミュニケーション管理

    プロジェクトでは、

    誰に・何を・いつ・どの方法で共有するか

    を管理することも重要です。

    たとえば、

    • 定例会議

    • 進捗報告

    • 課題管理

    • リスク共有

    などがあります。


    85.プロジェクトマネジメントの全体像

    全体をつなげると、

    目的・スコープを明確化
    ↓
    WBSで作業を分解
    ↓
    工数・コストを見積り
    ↓
    スケジュールを作成
    ↓
    クリティカルパスを管理
    ↓
    EVMで進捗・コストを評価
    ↓
    リスク・品質・変更を管理
    ↓
    プロジェクト完了

    という流れで整理できます。


    86.頻出ポイント整理

    WBS

    作業を階層的に分解

    ガントチャート

    作業期間を横棒で表示

    マイルストーン

    重要な節目

    アローダイアグラム

    作業の順序・依存関係を表現

    クリティカルパス

    開始から終了までの最長経路

    余裕時間

    全体を遅らせずに遅延できる時間

    工数

    人数 × 期間

    FP法

    利用者から見た機能量で規模を見積り

    PV

    計画価値

    EV

    出来高

    AC

    実コスト

    SV

    EV − PV

    CV

    EV − AC

    SPI

    EV ÷ PV

    CPI

    EV ÷ AC

    リスク回避

    原因をなくす

    リスク軽減

    確率・影響を下げる

    リスク転嫁

    第三者へ移す

    リスク受容

    認識して受け入れる


    87.間違えやすいポイント

    ① WBSとガントチャート

    WBS
    → 作業を分解

    ガントチャート
    → 作業と期間を表示

    です。


    ② クリティカルパス

    クリティカルパスは、

    最も短い経路

    ではありません。

    開始から終了までで所要時間が最も長い経路です。

    その経路がプロジェクト全体の最短完了期間を決めます。


    ③ 工数と期間

    工数
    → 作業量

    期間
    → カレンダー上で必要な時間

    です。

    24人月の仕事だから必ず24か月かかるわけではありません。


    ④ FP法とLOC

    FP
    → 機能量

    LOC
    → コード行数

    です。


    ⑤ PVとEV

    PV
    → 予定ではどこまで進むはずか

    EV
    → 実際にどこまで終わったか

    です。


    ⑥ SVとCV

    SV
    → Schedule
    → EV − PV

    CV
    → Cost
    → EV − AC

    です。


    ⑦ SPIとCPI

    SPI
    → スケジュール

    CPI
    → コスト

    です。

    どちらも、

    1より大きい=良好

    と覚えます。


    ⑧ 回避と軽減

    回避
    → リスク原因をなくす

    軽減
    → リスクは残るが確率・影響を下げる

    です。


    ⑨ 転嫁と受容

    転嫁
    → 第三者へ影響などを移す

    受容
    → 自分たちで受け入れる

    です。


    ⑩ 品質保証と品質管理

    品質保証
    → 品質を確保するためのプロセス・仕組み

    品質管理
    → 実際の成果物・結果を確認

    という違いを押さえましょう。


    88.確認問題

    問1

    プロジェクトの作業を階層的に分解し、管理しやすい単位へ整理するものはどれか。

    ア.WBS

    イ.EVM

    ウ.SLA

    エ.DFD


    問2

    開始から終了までの経路のうち、プロジェクト全体の最短完了期間を決定する経路はどれか。

    ア.最短経路

    イ.クリティカルパス

    ウ.ダミー作業

    エ.マイルストーン


    問3

    ある時点でPV=200万円、EV=160万円、AC=180万円であった。SVはいくらか。

    ア.−40万円

    イ.−20万円

    ウ.20万円

    エ.40万円


    問4

    問3と同じ条件でCPIはいくらか。

    ア.0.8

    イ.約0.89

    ウ.約1.13

    エ.1.25


    問5

    利用者から見たシステムの機能量を基にソフトウェア規模を見積もる方法はどれか。

    ア.LOC法

    イ.ファンクションポイント法

    ウ.EVM

    エ.クリティカルパス法


    問6

    リスクの発生確率や影響度を小さくする対応はどれか。

    ア.回避

    イ.軽減

    ウ.転嫁

    エ.受容


    問7

    品質問題を件数の多い順などに並べ、累積比率と組み合わせて重要な問題を絞り込むために利用する図はどれか。

    ア.散布図

    イ.特性要因図

    ウ.パレート図

    エ.管理図


    問8

    プロジェクト途中の変更要求への対応として最も適切なものはどれか。

    ア.すべて即座に受け入れる

    イ.変更要求を原則として無視する

    ウ.スケジュール・コストなどへの影響を評価して承認手続きを行う

    エ.プロジェクトメンバ個人の判断だけで実施する


    89.解答・解説

    問1:正解 ア

    WBSは、プロジェクトの作業を階層的に分解します。

    作業漏れ防止や工数・担当・スケジュールの管理につながります。


    問2:正解 イ

    クリティカルパスは、開始から終了までの経路のうち所要時間が最も長い経路です。

    この経路が全体の最短完了期間を決めます。


    問3:正解 ア

    SVは、

    SV = EV − PV

    なので、

    160 − 200
    = −40万円

    です。

    負の値なので、計画より遅れています。


    問4:正解 イ

    CPIは、

    CPI = EV ÷ AC

    なので、

    160 ÷ 180
    ≒ 0.89

    です。

    1未満なので、コスト効率は良くない状態です。


    問5:正解 イ

    ファンクションポイント法は、利用者から見た機能量を基にソフトウェア規模を見積もります。

    LOCはソースコードの行数に着目します。


    問6:正解 イ

    リスク軽減は、リスクの発生確率や影響を小さくする対応です。

    原因そのものをなくすのは回避です。


    問7:正解 ウ

    パレート図は、項目を件数などの大きい順に並べ、累積比率と組み合わせて重点的に対策すべき問題を把握するために利用します。


    問8:正解 ウ

    変更要求は、スケジュール・コスト・品質・スコープなどへの影響を分析し、適切な承認手続きを経て管理します。


    90.最終チェック

    この記事を読み終えたら、次の項目を確認してください。

    □ プロジェクトと定常業務を区別できる
    □ プロジェクトマネージャの役割を理解している
    □ ステークホルダを説明できる
    □ スコープの意味を理解している
    □ スコープクリープを説明できる
    □ WBSの目的を説明できる
    □ ワークパッケージを理解している
    □ WBSと組織図を区別できる
    □ ガントチャートを説明できる
    □ マイルストーンを説明できる
    □ アローダイアグラムを理解している
    □ ダミー作業の意味を理解している
    □ クリティカルパスを求められる
    □ 余裕時間を理解している
    □ 工数・人数・期間の関係を理解している
    □ 人数を増やせば必ず期間が反比例して短くなるわけではないと理解している
    □ 類推見積りを説明できる
    □ ボトムアップ見積りを説明できる
    □ 三点見積りを計算できる
    □ FP法とLOCを区別できる
    □ PV・EV・ACを区別できる
    □ SV=EV−PVを覚えている
    □ CV=EV−ACを覚えている
    □ SPI=EV÷PVを覚えている
    □ CPI=EV÷ACを覚えている
    □ SPI・CPIの1より大/小を判断できる
    □ BAC・EAC・ETC・VACの意味を理解している
    □ リスク管理の流れを理解している
    □ 回避・軽減・転嫁・受容を区別できる
    □ コンティンジェンシープランを説明できる
    □ リスク登録簿の役割を理解している
    □ 品質保証と品質管理を区別できる
    □ パレート図の用途を理解している
    □ 特性要因図の用途を理解している
    □ 管理図の用途を理解している
    □ ヒストグラムの用途を理解している
    □ 散布図の用途を理解している
    □ 変更管理の基本的な流れを理解している


    まとめ

    プロジェクトマネジメントでは、用語を個別に暗記するのではなく、

    「何を作るか決める」
    →「作業を分解する」
    →「期間・工数・コストを見積もる」
    →「スケジュールを作る」
    →「進捗とコストを測る」
    →「リスク・品質・変更を管理する」

    というプロジェクト全体の流れで理解することが重要です。

    特に科目Aで重要なのは、

    WBS=作業を階層的に分解
    ガントチャート=作業期間を横棒で表示
    クリティカルパス=開始から終了までの最長経路
    FP法=利用者から見た機能量で規模を見積り
    PV=計画価値
    EV=出来高
    AC=実コスト
    SV=EV−PV
    CV=EV−AC
    SPI=EV÷PV
    CPI=EV÷AC
    回避=原因をなくす
    軽減=確率・影響を下げる
    転嫁=第三者へ移す
    受容=認識した上で受け入れる

    です。

    特にクリティカルパスとEVMは、意味を理解した上で実際に計算できる状態にしておきましょう。

    次回の#27「サービスマネジメント 完全攻略」では、ITIL・SLA・インシデント管理・問題管理・変更管理・構成管理・可用性管理などを扱い、ITサービスを安定して提供・改善するための仕組みを体系的に整理していきます。

    ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
    📔 この記事は「応用情報|科目A 合格完全攻略講座【全40回】」の一部です。
    本編では、科目Aの重要分野を基礎から体系的に整理し、頻出計算・比較問題・直前総復習まで全40回で収録しています。
    ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

    あなたへのおすすめ