QCDSとは
- Q(品質) --- Quality
- C(費用) --- Cost
- D(納期) --- Delivery
- S(範囲) --- Scope/Service/Support
プロジェクト管理において、重要とされるQCDS。
社内監査・報告は、QCDSについて説明を求められることが多いのではないでしょうか？
プロジェクト管理におけるQCDS
- プロダクトのQ(品質)を確保する。
- プロジェクトのC(費用)は、予算オーバーしてはいけない。
- プロダクトの提供は、D(納期)を厳守する。
- プロジェクトのS(範囲)は、計画通りに対応する。
よく議題に上がる、誤った関係性。
* 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(納期)が伸びる。
なぜトレードオフになってしまうのか？
短い期間に人的リソースで対応しようとするから。
よく直面するシチュエーション
問題検知したタイミングがすでに差し迫った状況で、現在の人的リソースでどうにかしないといけない。
正直このタイミングでは、問題検知が遅すぎてトレードオフとするしかない場合が多い。
トレードオフにしない方法
プロジェクト管理において、事前に作戦を講じる。
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はトレードオフ関係じゃないか！という意見もあるかと思います。
トレードオフになる前に、ならないようにするのがプロジェクト管理者（マネージャ、リーダ）の役割なので、
これを理解して作為的に作戦を講じていく必要があると考えます。
私の経験上、何も作戦を講じずに無作為の状況では、プロジェクト崩壊、炎上、デスマーチが発生する。
これらの状況において、プロジェクト管理者は仕方ないじゃないですか！と半ば逆ギレ状態に陥る。
今後も、仕方ないじゃないですか！が少なくなるように努力していきます。