はじめに
プロジェクトマネジメントの基本としてよく挙げられるのが「QCD」です。Quality（品質）、Cost（コスト）、Delivery（納期）の頭文字を取ったもので、プロジェクトの成否を測る3つの軸として知られています。
言葉としては多くの人が知っていますが、実際のプロジェクトでは「納期が最優先だから品質は後で何とかする」「予算が厳しいからテストを削る」といった判断が、十分な検討なしに行われることがあります。その結果、短期的には帳尻が合ったように見えても、後から大きな代償を払うことになります。
今回は、QCDのバランスとは何か、そしてどれか一つを犠牲にしてはいけない理由を、発注側の視点で整理します。11月は、品質・コスト・納期それぞれの管理についても順に取り上げていきます。
QCDとは何か
QCDの3つの要素は、それぞれ次のような意味を持ちます。
- Q（品質）：成果物が求められる要件や水準を満たしているか
- C（コスト）：予算の範囲内でプロジェクトを完了できるか
- D（納期）：決められた期限までに成果物を引き渡せるか
この3つは独立しているわけではなく、互いに影響し合います。品質を上げようとすればコストや期間が増え、納期を早めようとすれば品質かコストにしわ寄せが来ます。いわゆるトレードオフの関係です。
ここで押さえておきたいのは、品質には「どこまでの範囲を作るか」という要素も含まれるという点です。要求をどこまで実現するか（スコープ）を広げれば、コストも期間も増えます。品質の考え方については、次の記事で詳しく整理します。
「バランスを取る」とはどういうことか
QCDのバランスを取るというのは、3つを均等に扱うことではありません。プロジェクトの目的に照らして、どの水準で3つを成立させるかを決め、それを関係者で合意することです。
たとえば、法改正への対応のように期限が動かせないプロジェクトでは、納期の優先度が高くなります。その場合でも、納期を守るために品質やコストをどこまで調整できるのか、調整できない最低ラインはどこかを、あらかじめ決めておく必要があります。
逆に、基幹システムのように長く使い続けるシステムでは、多少の期間延長を許容してでも品質を確保すべき場面があります。
大切なのは、優先順位を「その場の空気」で決めないことです。プロジェクトの初期段階で、QCDのどれをどの程度優先するかをプロジェクト憲章（プロジェクトチャーター）などの文書に明記し、経営層・業務部門・ベンダーと合意しておくことをお勧めします。
どれか一つを犠牲にするとどうなるか
品質を犠牲にした場合
納期やコストを守るために品質を犠牲にすると、問題はリリース後に表面化します。
- 本番稼働後に不具合が多発し、業務が止まる
- 不具合対応のために、結局は追加のコストと期間がかかる
- 現場の信頼を失い、新しいシステムが使われなくなる
品質を削って守った納期は、多くの場合「見かけの納期」に過ぎません。稼働後の手戻りまで含めると、むしろコストも期間も膨らむことが少なくありません。基幹刷新の本当のゴールは「稼働」ではなく「定着」で触れた通り、システムは使われて初めて価値を生みます。
コストを犠牲にした場合
品質と納期を守るために、予算の上限を気にせず人員や工数を追加し続けると、プロジェクトの投資対効果が崩れます。
- 当初の投資判断の前提が成り立たなくなる
- 他のプロジェクトに回すはずだった予算が圧迫される
- 次のプロジェクトで経営層の承認が得にくくなる
また、遅れているプロジェクトに人を追加しても、立ち上がりの教育や調整の負担が増えるだけで、期待したほど進まないこともあります。基幹刷新の予算超過はなぜ起きるのかで整理したように、予算超過は一度始まると止めにくいものです。
納期を犠牲にした場合
品質とコストを守るために納期を延ばし続けると、プロジェクトの目的そのものが損なわれることがあります。
- ビジネス上の機会（新サービスの開始時期、繁忙期前の稼働など）を逃す
- 現行システムの保守契約やライセンスの延長が必要になり、別のコストが発生する
- 関係者の疲弊やモチベーション低下を招き、さらに遅れる
納期の延長は、それ自体がコスト増加の要因になります。延長を判断する際は、延長によって何が守られ、何が失われるのかを比較する必要があります。
よくある場面：「納期は動かせない」と言われたとき
実際のプロジェクトでよくあるのが、結合テストの終盤で不具合が多く残っているのに、経営層からは「稼働日は動かせない」と言われる場面です。このとき、発注側として整理すべき選択肢は次のようになります。
- 予定どおり稼働し、残った不具合は稼働後に対応する（品質を下げる）
- 人員を追加してテストと修正を急ぐ（コストを上げる）
- 稼働日を延期する（納期を延ばす）
- 一部の機能や業務を稼働対象から外す（スコープを絞る）
どれを選ぶにしても、それぞれの選択肢で何が起きるのかを並べて比較し、経営層に判断を求めることが重要です。「なんとかします」という現場の頑張りに頼って品質を黙って削るのが、最も避けるべき判断です。稼働の可否をどう判断するかはカットオーバー判定基準を事前に決めるでも整理しています。
発注側がQCDのバランスを保つためにやるべきこと
優先順位を事前に合意しておく
前述の通り、QCDのどれを優先するかは、問題が起きてから決めるのではなく、プロジェクトの初期に決めておきます。問題が起きた時点で議論を始めると、声の大きい人の意見や目先の都合で判断が決まりがちです。
トレードオフの判断を発注側が持つ
ベンダーはQCDのうち、自社の責任範囲を守る方向で判断しやすい立場にあります。たとえば請負契約であれば、追加コストを避けるために品質の作り込みを抑える方向に働くこともあります。
QCDのトレードオフを判断するのは、プロジェクトの目的を持っている発注側の役割です。ベンダーから「納期を守るにはこの機能を後回しにするしかありません」と提案されたときに、それを受け入れるかどうかを判断できる材料を、発注側が持っておく必要があります。
3つを同じ報告の中で見る
進捗報告では、納期（スケジュールの遅れ）だけが議題になりがちです。しかし、スケジュールが順調でも、品質指標が悪化していたり、工数の消化が想定を上回っていたりすることがあります。
「特になし」と書かせることに意味がある｜進捗報告フォーマットの作り方で紹介したフォーマットに、品質（不具合件数の推移など）とコスト（予算の消化状況）の欄を加え、3つを同じ報告の中で確認できるようにしておくことをお勧めします。
調整するときは「スコープ」も選択肢に入れる
QCDのどれかが厳しくなったとき、残りの2つで吸収しようとすると無理が生じます。その場合に検討したいのが、スコープ（作る範囲）の調整です。
- 優先度の低い機能を第二弾リリースに回す
- 一部の業務は当面、現行の運用で対応する
範囲を絞ることで、品質を保ったまま納期とコストを守れる場合があります。ただし、スコープを動かすときはスコープ変更の承認フローに沿って正式に合意し、何を後回しにしたのかを記録に残しておくことが重要です。
まとめ
QCDは、品質・コスト・納期という互いに影響し合う3つの軸です。どれか一つを犠牲にすれば、その影響は時間を置いて他の2つにも跳ね返ってきます。
発注側がやるべきことは、プロジェクトの目的に照らしてQCDの優先順位を初期に合意し、トレードオフの判断を自ら持ち、3つを同じ報告の中で継続的に確認することです。厳しい局面では、スコープの調整も含めて、無理のない落としどころを探ることが、結果的にプロジェクトを守ることにつながります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント