QCDSとは

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

プロジェクト管理におけるQCDS

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

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

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

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

短い期間に人的リソースで対応しようとするから。

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

プロジェクト管理において、事前に作戦を講じる。

GitPushやMergeトリガーで起動する自動テストをプロジェクトに適用する事で

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

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

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

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

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

各自、目標を正しく理解して、正しい行動をとる。

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

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

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

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

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