自分で書いたQiitaの記事は、自分が「こういう解説だったら理解しやすいな」と思った書き方になっている
その書き方に沿って解説してもらえば、理解しやすい用語解説をしてもらえると思った
やってみる

質問文
Facadeパターンについて、[前提条件]を前提に、[テンプレート]に沿って、用語解説をしてください

[前提条件]
- テンプレートの構成を厳密に踏襲する必要はありません
    - 例えば、解説対象の用語に内包される別の専門用語がない時は、「## 用語」のセクションを消しても問題ありません
    - 例えば、デザインパターンの解説の時は、「## 運用の例」を「##実装の例」などに変えても問題ありません
- 逆にテンプレートの中で重視してほしいのは以下の箇所です
    - 解説対象の用語以外に極力専門用語を使わないこと
    - 平易で親しみやすい単語を使うこと
    - 句読点を入れて、視覚的に見やすい文章にすること
    - 1文を短くして認知不可を減らすこと
    - 箇条書きを使って認知不可を減らすこと

[テンプレート]
## EVMとは
- プロジェクトを管理する時に、タスクの完了率だけじゃなく、予算の消化率も管理すること

## 何が嬉しいのか
- 予算を常に把握できる
    - 「タスクの完了率は遅れてるけど、予算は余っているので、人員を追加しましょう」みたいな話がノータイムでできる

## 何が嬉しくないのか
- タスクの完了率だけじゃなく、予算の消化率も計算するので、以下のデメリットが生まれる
    - 予算消化率の計算作業が手間
        - 自動化するにしても、自動化を確立するまでが手間
    - 予算を厳密に管理しなくていい時は、ノイズの情報になる

## 用語
### PV(Planed Value)
- ある時点でかかっているはずの費用(予定)
    - 「どのタスクにいくらかかるか」を事前に割り当ててあるので、「その時点で完了しているはずのタスク」も費用から計算できる
    - ITのプロジェクトだと、「費用=人件費」と考えると理解しやすい

### EV(Earned Value)
- ある時点で完了したタスク(実績)から、求めた費用(予定)
    - 「今日の時点でタスクAまで終わっている。タスクAに割り当てた予算は1万円だから、今日の時点で1万円費用がかかっているはずだ」という風に求める

### AC(Actual Cost)
- ある時点でかかっている費用(実績)

### SV(Schedule Variance)
- スケジュール不一致
    - 「スケジュールが予定より進んでいる or 遅れている」がわかる数値
- EV - PVで求める
- SV > 0 なら予定より進んでいる
- SV < 0 なら予定より遅れている

#### 私がつまづいたところ
- 仮にEVとPVで差があっても、タスクあたりの予算見積もりが間違っていただけの場合、スケジュールの指標にはならないのでは？
    - SVの考え方はタスクに紐づいた予算が正確であることを前提として、予算を比較することで、タスク完了率の予定と実績を比べる考え方なので

#### つまづきが解消された理由(勘違いしていたところ)
- EVはあくまで「プロジェクト開始時(PV決定時)」に、タスクに割り当てた予算をもとに計算するもの
    - 「このタスクに思ったより予算がかかった」という事態は、反映されない
    - その事態はACに反映される

### CV(Cost Variance)
- 費用不一致
    - 「費用が予定よりかかっている or かかっていない」がわかる数値
- EV - ACで求める
- CV > 0なら予定よりかかっていない
- CV < 0なら予定よりかかっている

### SPI(Schedule performance index)
- スケジュールパフォーマンス指標
    - 「スケジュールが予定より進んでいる or 遅れている」がわかる数値
- EV / PVで求める
- SPI > 0なら予定より進んでいる
- SPI < 0なら予定より遅れている
- SVとの使い分け方は分からない

### CPI(Cost performance index)
- 費用パフォーマンス指標
    - 「費用が予定よりかかっている or かかっていない」がわかる数値
- EV / ACで求める
- CPI < 0なら予定よりかかっている
- CPI > 0なら予定よりかかっていない
- CVとの使い分け方は分からない

## 運用の例

### 想定するプロジェクト
- プロジェクト期間は1/1~1/30
- 作業者はAさん1人
- タスクはタスク1~タスク30まである
    - つまり1日につき、1タスク終わる予定
- 1日の費用(Aさんの人件費)は1万円
    - つまり1つのタスクにつき、1万円の費用がかかる予定
- 残業代は、時間内労働と同じ人件費がかかる
    - 1日分の残業をしたら、1万円の人件費がかかる

### 1/15時点での、タスク完了率・予算消化率の判断
- タスク10まで終わっているとする
- Aさんは1日分残業したとする

#### PV
- 15万円
    - タスク15まで進んでいる予定なので

#### EV
- 10万円
    - タスク10まで終わっているので

#### AC
- 16万円
    - Aさんは15日の時間内労働と、1日分の残業をしたので

#### SV
- 10(EV) - 15(PV) = -5
    - 予定より遅れている

#### CV
- 10(EV) - 16(AC) = -6
    - 予定より費用がかかっている

#### SPI
- 10(EV) / 15(PV) = 0.67
    - 予定より遅れている

#### CPI
- 10(EV) / 16(AC) = 0.63
    - 予定より費用がかかっている

1/15時点での予算と、1/15時点で完了したタスクに割り当てられた予算を比較して、
スケジュールが予定通りどうかを判断するのが、ややこしいポイントだなと思いました
(予算を起点にしているのに、スケジュールの判断に直結しているのは、結局タスクの完了率)

タスク完了率・予算・実際かかった費用・時間軸の4つを材料に、進捗率と予算消化率を判断するのが、EVMの肝なんだと思いました

## 再結論
- タスクの完了率だけじゃなく、予算の管理もするのがEVM
    - 一般的なプロジェクト管理は、「1/15までにタスク10まで終わりました」だけを管理する
    - でもEVMは予算消化率も管理する
- 厳密に予算を管理する、受託の案件とかだと、便利かもしれないと思った
- 逆に、細かく人月あたりの予算を管理してない自社サービスの社内案件とかだと、過剰かもしれないと思った
回答
悪くない
必要に応じてコードの実装例にしたり、改良はできそう