QCDSはトレードオフの関係ではない

# QCDSとは

* Q(品質)  --- **Quality**
* C(費用)  --- **Cost**
* D(納期)  --- **Delivery**
* S(範囲)  --- **Scope/Service/Support**

プロジェクト管理において、重要とされる**QCDS**。
社内監査・報告は、**QCDS**について説明を求められることが多いのではないでしょうか？

## プロジェクト管理におけるQCDS
* プロダクトのQ(品質)を確保する。
* プロジェクトのC(費用)は、予算オーバーしてはいけない。
* プロダクトの提供は、D(納期)を厳守する。
* プロジェクトのS(範囲)は、計画通りに対応する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282054/5ad3014f-8afc-e1d5-0413-33062998b94a.png)

# よく議題に上がる、誤った関係性。

```
* Q(品質)を上げると、Q(品質)確保に人員を追加するのでC(費用)が上がる。
* Q(品質)を上げると、Q(品質)確保に時間を要すのでD(納期)が伸びる。
* Q(品質)を上げるには、対応するS(範囲)を絞る必要がある。
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282054/617363de-d58f-9ead-f630-d4ebea86beb9.png)

```
* C(費用)を下げると、確認作業を省略するのでQ(品質)が落ちる。
* C(費用)を下げると、人員を削減するのでD(納期)が伸びる。
* C(費用)を下げるには、対応するS(範囲)を絞る必要がある。
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282054/b00ff488-f0b7-574e-1a16-abc6c68db8c4.png)

```
* D(納期)を短縮すると、確認作業を省略するのでQ(品質)が落ちる。
* D(納期)を短縮すると、Q(品質)確保に人員を追加するのでC(費用)が上がる。
* D(納期)を短縮するには、対応するS(範囲)を絞る必要がある。
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282054/06dd9368-69a4-433a-6447-71e22a9d5a9d.png)


```
* S(範囲)を広げると、確認作業を省略するのでQ(品質)が落ちる。
* S(範囲)を広げると、追加となった範囲を対応する人員を追加するのでC(費用)が上がる。
* S(範囲)を広げると、D(納期)が伸びる。
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282054/502f50cc-19fb-6399-6a4c-dc6af389570d.png)


# なぜトレードオフになってしまうのか？
短い期間に人的リソースで対応しようとするから。

### よく直面するシチュエーション
**問題検知したタイミングがすでに差し迫った状況**で、現在の人的リソースでどうにかしないといけない。
正直このタイミングでは、問題検知が遅すぎてトレードオフとするしかない場合が多い。

# トレードオフにしない方法
プロジェクト管理において、事前に**作戦を講じる**。

## POINT
* **人的リソースの消費を少なく**し、最大の結果を出す。

## 作戦
* CI/CDを導入する。
* コミュニケーション方法、ルートを限定する。
* メンバー全員に目的意識を植え付ける。
* レビュールールを決める、徹底する。
* GitFlowを適用する。
* 共通処理と固有処理の定義を明確にする。
* ...etc


# CI/CDを導入する。
## CI(継続的インテグレーション)
GitPushやMergeトリガーで起動する自動テストをプロジェクトに適用する事で

* リグレッションテストが無意識に行えるようになり、Q(品質)が向上する。
* テスト実施回数が増えて、Q(品質)が向上する。
* テストに要する時間が削減されて、次の作業を実施できる。（C(費用)、D(納期)、S(範囲)に良い影響を与える）
* プログラミングレベルでの不具合や問題が早期に発見される。（Q(品質)、C(費用)、D(納期)、S(範囲)に良い影響を与える）
* 新規メンバーのプロジェクト参画難易度が下がる。
* 人的作業が減って、Q(品質)が向上し、C(費用)が削減される。

## CD(継続的デリバリー)
Gitでmaster/developブランチへのMergeトリガーで起動する自動デリバリーをプロジェクトに適用する事で

* リリース作業が不要となる。（C(費用)、D(納期)、S(範囲)に良い影響を与える）
* リリース回数が増えて、変更が容易になり、障害解決速度が向上する。(Q(品質)に良い影響を与える）
* 人的作業が減って、Q(品質)が向上し、C(費用)が削減される。

# コミュニケーション方法、ルートを限定する。
強制力を持って限定するのは、困難なので、コミュニケーションの場を提供する事が必要。

コミュニケーションは、全ての工程・作業において重要な役割となる。
しかし、コミュニケーションは各自が好きなように行ってしまうと、情報が散在し取りこぼしが発生する。
取りこぼしが発生すると、要件もれ、作業もれ、手戻り、強いては障害に発展する。

## 失敗例
全てのやり取りをメールグループ宛に送信する。
（メールボックスが肥大化して、不要なメールを削除する必要があったり、必要なメールが埋もれる状態を招く）

## 推奨
目的にあったコミュニケーションインフラを準備する。

* 周知、QA、チーム・グループ共有、雑談、システムBot連携
    * チャットツール　Slack、Teams・・・
* 要求、要件、スケジュール、課題、TODO
    * タスク管理ツール　Jira、Tolero、BackLog、GitLab、Redmine・・・

# メンバー全員に目的意識を植え付ける。
各自、目標を正しく理解して、正しい行動をとる。

与えられた作業を実施する、作業者意識を強く持ったメンバーで構成されたチームは失敗する。
目的を正確にとらえた（捉える事ができる）メンバーで構築したチームは成功する。

・・・そのうち加筆します。

# 最後に
結局は、`QCDSはトレードオフ関係じゃないか！`という意見もあるかと思います。
トレードオフになる前に、ならないようにするのがプロジェクト管理者（マネージャ、リーダ）の役割なので、
これを理解して作為的に作戦を講じていく必要があると考えます。

私の経験上、何も作戦を講じずに無作為の状況では、プロジェクト崩壊、炎上、デスマーチが発生する。
これらの状況において、プロジェクト管理者は`仕方ないじゃないですか！`と半ば逆ギレ状態に陥る。

今後も、`仕方ないじゃないですか！`が少なくなるように努力していきます。