本記事は、Professional Scrum Trainer (PST) の Sander Durさんによる「Scrum: Dealing With Fixed Date, Fixed Budget Work」の翻訳です。翻訳・公開は、Sander さんの許諾を得ています。誤字脱字・誤訳などありましたらぜひご指摘ください。
はじめに
多くの組織がスクラムのフレームワークのメカニズムを理解している今日とはいえ、プロダクトのデリバリーに対するアプローチにおける変化は、なかなか理解されにくいものです。つい先日も、「プロダクトXをこの期日までに予算内で提供できますか」という従来的な質問が出たばかりです。
嗚呼、昔から信頼されている鉄の三角形(アイアントライアングル)ですね。なかなか共に仕事ができなさそうですね。でも、実は可能なのです。固定期日、固定予算のプロジェクトは、これからも存在し続けます。特には、ある期日までに提供しなければならないことがあります。顧客がやってきて、「X日までに提供できますか、いくらかかりますか?」と訊いてきます。もちろん、何かを提供することができるのです。さぁ、見ていきましょう。
価格帯の予測づくり
次のような新規プロダクトの開発があるとします。1人のスクラムマスタースター、1人のプロダクトオーナー、そして7人の開発者が必要で、納期は、今から6か月後です。議論のために、平均時給が100ドル(14,000円: 以下、1ドル=140円)だとします。全員がフルタイム(週40時間)で働きます。6ヶ月間はおよそ130日の稼働日数とします。
- 1日の作業 = 8時間 × 100ドル = 800ドル(112,000円)
- 総作業日数130日 × 800ドル = 104,000ドル(14,560,000円)
9人のチーム編成なので、104,000ドル×9人 = 936,000ドル(131,040,000円)、これが純粋な人件費になります。これにライセンシングなどのリソースを加えると100万ドル(1億4千万円)ほどになります。
さて、開発作業中に、複雑さを過小評価していたり、持ち合わせていると思っていたスキルが不足していたり、その他の理由でより多くの人員が必要だとわかったらどうするでしょうか。最悪の場合、3人の開発者を追加しなければなりません。先ほどの計算によると、312,000ドル(43,680,000円)が追加で必要となるのです。これに伴い、コミュニケーションパスも増えていきます。特に、最良のシナリオでは、一桁増えると、実に難しいことをやっているのです。残念なことに、費用面が人においてよくない部分を引き出してしまうことがあまりにも多いことをみてきました。
ステークホルダーの皆様、提供することは可能ですが、費用は、上記の議論に基づき、100万ドル(1.4億円)から1,312,000ドル(131万ドル / 1.8億円)の間となります。
わかりましたが、120万ドル(1.68億円)の予算で固定なのです。どういうことですか。
細部に落とし穴がある
スコープは、変更すべきものであり、変更がされるものでもあります。
予算と期日が決まっているところで、スコープを固定してしまうと、品質の低下を招きます。急ぎすぎて、気がついたらテストが疎かになっていたということもありがちです。「問題が出てきたら修正します」というスタンスになります。実は、このことが却って大きなコストになっているのです。未テストの作業結果は、期待通りに動作するかどうかわからないため、意思決定が甘くなる可能性があるのです。誤った意思決定の上に積み重ねていくと、質的に劣る作業になっていきます。
問題が発生してから修正するのでは、プロダクト全体が不安定になる可能性があるのです。リリースを急いだためにテストが疎かになり、プロダクトの大部分を作り直すことになりかねないのです。
予算内や期日内に提供しなかった場合、最初に耳にする言葉とは何でしょうか。「でも、契約では…」ですね。そして、そこに行き着く必要もあるのです。この開発を始める前に、契約にいくつかの条項を追加する必要があるのです。
- まだ顕在化されていないプロダクトバックログアイテムは、比較的同じサイズのものと交換することができる
- プロダクトバックログの並び順は、いつでも変更可能である
- 追加のリソースが必要となった場合、追加の時間およびリソース費用が発生することがある
- プロダクトが満足できる価値を提供した時点で、未開発部分の費用の20%で契約を解除できる
契約書にこれらの条項を追加することで、スコープに柔軟性を持たせ、全スコープを提供するのではなく、価値により集中できるようになります。一方、期日前に期待される価値が達成された場合は、顧客は開発を終了させることができるのです。
固定期日、固定費でプロジェクトを実施できる
しかし、契約にいくつかの条項を追加する必要があります。私がこれまで共に仕事をしてきたステークホルダーの大半は、常にひとつの要求を、できるだけ安価で、すぐに提供することを求めていました。もちろん、品質レベルは最上級であるべきなのはいうまでもありません。
私は子供達にユニコーンをプレゼントしたいのですが、それは叶いません。ウマをユニコーンに見立てるには、オモチャのツノをウマの頭にテープで貼り付けるのが一番です。透明性は高くはないのですが、鉄の三角形を保ち、顧客に提供していくとは、だいたいそのようなものです。
契約書にこれらの条項を加えることで、より現実的なシナリオを提供することができるのです。ユニコーンが本当に必要なのでしょうか。ウマで十分なのではないでしょうか。「尊敬」は一方通行ではありません。スクラムチームは、現実的なスコープで価値を生み出すために顧客に敬意を払うべきです。顧客は、実現してくれるスクラムチームに敬意を払うべきです。「我々は、時間通り、予算通り、そしてスコープ通りに提供できる」と、おそらくできないことがわかっているのであれば、それを言ってはいけません。
今まで見た中で、一番大きな組織的なユニコーンを教えてください。
本記事の翻訳者:
長沢 智治 – アジャイルストラテジスト
サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。
『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。