再びimai78でございます。
前回は「サービス開発における要件定義」と題して、FURPSとQCDについて簡単に触れたので、今回は引き続きQCDについて掘り下げてみます。
前段
弊社のように複数のプロダクトを持っている企業の場合、サービスに対して機能を開発してローンチする工程のスピード感は、ケース・バイ・ケースで大きく異なります。
特に弊社では、「ご利用頂くユーザー様に与えるインパクト」や「ソリューションがどれだけ市場に求められているか」といった観点でこのスピード感を考えることが多いです。
表現方法としてのQCD
ただ、アクセルを全開にするのか控え目に踏んでいくのかは別として、スピード感が変わる事による影響というものは必ずある訳です。
その一例として、前回
品質を良くしようとすれば費用か納期を犠牲にせざるえず、費用を抑えようとすれば品質か納期が犠牲に、納期を早めようとするなら品質を犠牲にするかより多くの費用の投下が必要になる、と極めて分かりやすい作用が発生するからです。
といった事を書きました。
ビジネス上の課題に対していかなるスピード感を出すべきかどうかということを、このQCDという3つのパラメータで表現してみると、こういった感じになります。
ローンチを急ぐ場合のQ:C:D
- Q：ローンチ重視
- C：人を増やして並列開発
- D：ローンチ急ぐ
ユーザー様に与えるインパクトを与えたくない場合のQ:C:D
- Q：壊れない事が重要
- C：ローンチ前検査が十分できる人数と期間
- D：検査が終わるまでローンチしない
両極端な例を2つあげましたが、こんな感じ。
様々なケーススタディ
もちろん、理想に対して現実はそうはうまくいきませんので、これをベースラインに様々な調整を行うことになります。
ローンチ重視、動けばOK、人は増やせないなら
- Q：機能を限定
- C：増員なし
- D：ローンチ急ぐ
壊れたら困る機能があるなら
- Q：特定の機能のみを集中検査
- C：増員なし
- D：検査が終わるまでローンチしない
こんな感じ。
それはそれとして
これらはただの一例で、実際はB2BなのかB2Cなのかで大きく異なりますし、収益化に向けて発展途上のサービスなのか既に踊り場に乗っている状態なのかによっても、求められるサジ加減が劇的に変わります。その上、プロダクトの性質とプロダクト・オーナーの持つビジョンなどを踏まえて意思決定していかなくてはなりませんので、QCDという側面だけを見て簡単に「コウダ！」言えないところです。
ただし、実際に作るべきものを固めたあと、「さあ作ろう！」と複数人で立ち向かうことになった場合、開発プロジェクトが目指すゴールと方向性がどういうものなのか、端的に表現しておくことはとても重要です。
おやくそく
Allied Architectsは日々お客様のビジネス上の課題と向き合い、Webサービスという形態での解決策をご提案し続けております。
その中で我々開発者は、このQCDに代表されるような様々な視点やフレームワークを組み合わせて、サービス開発に向き合っております。
そんなダイナミックなサービス開発をに興味がある方、ぜひご連絡下さい！！
