ゴールを80%に設定するということ。
公開日 : 2012-06-20 11:02:22
何ごとも100%はコスト高、トラブルのもと。70%のコストで80%の約束をして90%のサービスを提供するほうが、100%の約束して苦労したりトラブるより、結果として互いがハッピーになることが多い。不思議とそっちの方が利益があがるんだなこれが。
Web2.0の時(いつだよw)に、βでも良いからリリースして改良していくみたいな手法が取り上げられたけども、例えば受託開発案件なんかでβ納品なんかしたら問題ですよね。それでも80％をゴールに設定するような考え方も役に立つというか、使えるんじゃないかと最近思うんですよ。
CMSなんかのWebシステム構築の場合、顧客の要件を100％満たすことを前提に設計を行った場合、たいてい100%を実現するために壁になる部分、つまり、実現が困難な10％とか20％の部分が(大抵＝経験からね)出てきます。この10〜20％が実はやっかいで、要件(ボリューム)としては10〜20％だけど実現の敷居は高く工数も高い、つまりこの部分(実現のネックになりそうな10〜20％部分)を削るとコストはそれ以上に下がります。そしてトラブルの発生率も大きく下がります。
もちろん不完全なものを納品するわけにはいかないので、プロジェクトの設計や契約の際に、この部分を削ってスタートさせたらいいんじゃないの? ってことです。
ただでさえ仕様変更や要求の追加って日常茶飯事のように出てくるわけですから、そういう提案をすることも、アリだと思うんです。例えばパッケージ製品の標準機能で8割要件を満たせる場合、残りの20％のカスタマイズを仕様から一旦外してしまって比較的容易に実装可能な8割をゴールとする。トラブル発生や実現難易度の点から、8割の機能でも見積りはもっと下がるでしょう。
500万円の仕事だとして、20％以上、というと100万円以上売上げが減るわけで、こういった場合、多くの会社では100%、500万円で受注しようとするんじゃないかと思うんですが(そもそも顧客が望んでいることなんだから、それに極力応えようとする姿勢はある意味まっとう)、誰もトラブルを望んじゃいないし、デスマが好きな人なんていないですよね。
佐渡先生wも「百里の道を行くときは、九十九里をもって半ばとせよ」と言っていますが、受託開発なんかで最後の1割、納期前に最後まで残っているバグ潰しとかってたいがい無理をした部分、無理な実装、強引なカスタマイズとかってケースが多い。
ということで、冒頭のツイートのような考え方になるんですね。要件を80％に絞り、ネックになりそうな20％を思い切って削る、そして30％の予算を浮かす。この30％を以降の改善に回して行けばいいのです。その頃はやりたいことが変わっているかもしれないし、軌道修正の予知を残すといった観点からもこれは効果がある筈です。あるいはゆとりができた分10％の性能/信頼性向上をめざすこともできる。結果として満足度が高まるってこともあるはずです。
ザッカーバーグの Done is better than perfect
ハッカーはすぐに全てを良くしようとするよりはむしろ素早くリリースしたり、より小さな反復から学ぶことによって長期的に最高のサービスを作ろうとします。このことをサポートするために、我々は与えられた時間で何千というバージョンのFacebookを試すことのできる構造を作り出しました。我々は社内の壁に「完璧を目指すよりまず終わらせろ - Done is better than perfect -」と書いて仕事に取り組んでいます。
まず終わらせること。サクッとやっちゃえ! みたいなことですよね。受託でなくてサービスだからできる考え方だとも言えますが、受託の場合でもそもそも80％の仕様で契約して、そこをサクッとやっちゃいましょうよ、ということです。
ちなみに、この考え方はケースバイケースではありますが、他の考え方にも応用できると思います。
- 1日の仕事を100%目一杯でなく、80％程度に調整しておく。阻害要因となる部分について、そもそも断ったり役割分担するなどしてその日のタスクから外してしまう。
- 余裕を持った20％を品質や機能、信頼性向上のために充てる。もしくは不意のトラブルや仕事のバッファとしておく。
とかね。でも、一番難しいのは「捨てる」「断る」ってことなんですがね。少し勇気を持とうってこと。その方が結果的にハッピーになれることも多いんだよ。
