結論
- QCDSは、エンジニアだけ知っていればいいものではない
- 関係者は知っておく必要がある。周囲に知らない関係者がいれば、根気強く伝えていく
- 無意識に固定化しがちのDeliveryとScopeは、やむを得ない状況を除き厳格に固定化しない
-
QCDSはトレードオフ
- 最高品質(Quality)、最低予算(Cost)、最短納期(Delivery)、最大範囲(Scope)すべてを兼ねることはできない
- Qを再重視する
そもそもQCDSとは
生産管理における主要な要素、
- Quality(品質)
- Cost(予算)
- Delivery(納期・スケジュール)
- Scope(範囲)
の頭文字を取ったものです。
元は製造業でQCDとして定着し、その後業界や状況によってQCDF(Frequency)QCDS(SがService)等、多くの派生が生まれたようです。
現在は製造業以外でもあらゆる場面で利用されています。
例えば郵便の速達をQCDで例えると
- 速達で頼んだからといって郵便物が乱暴に扱われることはないでしょうから、品質はそのまま(Quality→)
- 他の郵便物より優先的に早く届けるので、速達料金がかかる(Cost↑)
- 早く届けたいというニーズに応えるために納期は早まる(Delivery↓)
となります。
品質下げず速達を同じ料金で！と言っても当然無理ですよね。
QCD(S)とはこういったものです。
QCDSは、エンジニアだけ知っていればいいものではない
一定規模以上であれば、エンジニア100%で構成されているWeb系自社開発企業は基本的にありません。
エンジニアが0から全て考え、開発し、運営している…というケースは少ないはずです。
つまり非エンジニアが企画や新機能や改善点をissueとし、エンジニアに依頼するケースが多くなります。
そこで、依頼者である非エンジニアがQCDSという言葉を全く知らない、品質管理等の概念を理解していない状態で仕事を続けるとどうなるでしょうか？
無意識に固定化しがちのDeliveryとScopeは、やむを得ない状況を除き厳格に固定化しない
- 「8月31日までに、機能Aを実装してほしい」
とてもありふれた依頼のようですが、依頼者にQCDSの理解が無い、かつ対応者のエンジニアもQCDSを調整する観点が抜けていると、これだけで地獄になる可能性があります。
- 依頼時点の機能Aは、目的を達成するのに必要な要件を全て満たしているでしょうか？
- 着手後に初めて気付くような、技術的な壁が隠れていた場合のバッファは考慮されているでしょうか？
- 対応者のタスクに、急遽緊急性の高いタスクが入ってきても期日は守れるでしょうか？
- 等々…
- 要するに、機能Aの実装に対して、8月31日という期日は妥当なのでしょうか？
実はそれに明確な答えを出すのは、以下理由により非常に難しいです。
不確実性コーン
不確実性コーンは、プロジェクトが進行するにつれて見積もりのバラツキがどのように推移していくのかを表しています。横軸はマイルストーンを、縦軸はそれぞれの時期に見積もったプロジェクト規模（工数・スケジュール）を示しています。このグラフを基にプロジェクトが持つ不確実性の特徴を見ていきましょう。
まず一つめの特徴となるのが「バラツキの幅」です。プロジェクトの初期には、見積もりは非常に高いバラツキを持っています。例えば「初期コンセプト」の段階では、最も大きい見積もりで4倍、最も少ない見積もりで0.25倍となっています。つまり、16倍もの開きがあることになります。
二つめは「不確実性の減るタイミング」です。グラフを見ると、時間の経過とともに不確実性が自然に減っていくように見えます。しかし、実はそうではなく、不確実性は各フェイズで意思決定が行なわれることにで小さくなります。製品コンセプトや仕様が明らかになるコミットメントを得ることで、不確実性は小さくなるのです。逆にいえば、意思決定をしなければ、大きな不確実性を抱えたまま、プロジェクトが進んでしまうということになります。
引用：プロジェクトの本質とはなにか | 日経クロステック（xTECH）
この記事から、そもそも「正確な見積もり」というのが幻想であり、特に初期の見積もりは最終的な工数と大幅にブレる可能性が高いことが分かります。
そのため、こういった知識を知らないで会話をしていると、非エンジニアから見ると
- 見積もりと同じ期間を開発に充てたのに、
- 不具合だらけで使い物にならない！(Qualityへのしわ寄せ）
- 追加で何人もアサインしないと間に合わない！(Costへのしわ寄せ）
- リリース日を遅らせることになった！(Deliveryへのしわ寄せ）
- 機能削減をして、当初より機能が少ないリリースになった！(Scopeへのしわ寄せ）
といった印象を与えてしまう可能性があります。
それでは、どうすればこうした事態をできるだけ回避できるでしょうか？
- Quality(品質)：下げて不具合だらけのシステムを出してもトラブルの元なので下げれない
- Cost(予算)：追加人員はそうそう出してもらえないし、仮に出してもらっても『人月の神話』にあるように、2人になったら半分の納期になるわけでもないので、効率が悪い
と考えると、QCDSにおけるコントロールがしやすいものはDeliveryとScopeです。
ですので、本来コントロールしやすいはずのDeliveryとScopeの片方、もしくは両方が最初から固定化されているとQCDSは崩壊しやすくなります。これら2つは可能な限り可変とすべきです。
でないと、対応者の残業というCostへのしわ寄せで負荷が増します。
QCDSはトレードオフ
ここまで読んでいただければもうお分かりの通り、QCDSはトレードオフの関係にあります。
- 最高品質(Quality)
- 最低予算(Cost)
- 最短納期(Delivery)
- 最大範囲(Scope)
すべてを兼ねることはできません。
また、どれかが固定化されていると、別の要素にその分のしわ寄せが必ずきます。
Qualityは最重視すべし
「この日までにこの機能を、この人員だけで必ず完成させるんだ！」=CDSが固定化
となると、Qualityにしわ寄せが来ます。
例）テスト不十分なままに、スパゲッティコードを量産して無理にスケジュールに合わせる
ですが、これは最も避けるべきことです。
そういったシステムは出来上がっても不具合で使い物にならないことがありますし、その場合はユーザーの信頼を失うことになります。
また、奇跡的に問題が起きなかったとしても、保守性が低いシステムのため改修に必要以上のコストがかかります。
そして、技術的負債を計画的に返済し続ける仕組みが無い限り、そのシステムが改善することはありません。
「開発が終わるとどうなる？」「知らんのか」「開発が始まる」
状態であり、出来上がった保守性の低いスパゲッティコードはずっとそのまま、どころか後日改修を重ねて更なるスパゲッティコードに進化します。
そのため、とにかくQualityを突き詰める必要はありませんが、最低限守るべきQualityはしっかり守る意味で固定化をすべきです。
再度結論
- QCDSは、エンジニアだけ知っていればいいものではない
- 関係者は知っておく必要がある。周囲に知らない関係者がいれば、根気強く伝えていく
- 無意識に固定化しがちのDeliveryとScopeは、やむを得ない状況を除き厳格に固定化しない
-
QCDSはトレードオフ
- 最高品質(Quality)、最低予算(Cost)、最短納期(Delivery)、最大範囲(Scope)すべてを兼ねることはできない
- Qを再重視する
これらを関係者全員の共通認識としておき、QCDSのどれを優先として可変とするか、その案件ごとに合意をしておきましょう。