「完成度を高めること」ではなく「どこに完成度を求めるかを判断すること」
直近 システムチームに伝えた案件ですが、大事な考え方ですので皆さんにも伝えます。
この十数年 社内でいくつかのシステムがローンチしました。大きなカスタマイズ案件もありました。小さな案件も含めると沢山ありました。
またシステムとシステムを繋ぐような案件もあったかと思います。色々ありましたが半日止まってしまうような事故は一度も無かったかと思います。
そういう意味では非常に優秀で完成度を高めれる所まで高めてリリースしてくれていたのだと思います。一つ一つは毎回不具合が出ないように非常に優れた所まで精度を高めてくれていたということです。
パレートの法則：成果の80%は20%の労力で生まれ、残り20%に80%の労力がかかる
収穫逓減の法則：最初は少ない努力で大きな成果が得られるものの、完成度が上がるにつれて、同じ努力から得られる改善幅が小さくなる。
限界費用の逓増：完成度を1%上げるために必要な追加コストが、完成度の上昇とともに増えていく。
80点から98点にするために膨大な時間を使い、結果として他の重要な仕事が進まなくなる現象。完成度を高めるほど追加の労力が急激に増える現象。
トラブル無くやってこれた のは大変良かったですが
冒頭の話に戻ると例えば10回に1回くらい失敗があったほうが中小企業の我々にとっては良いと判断もあります。
社内の業務改善や新しい仕組みの試作なら80点で動かして改善する。
一方、勘違いしないで貰いたいのはヒヤリハットなど安全性は98点でも不十分な場合がある
リソースが限られてる中 すべてを98点にすることではなく、どこに98点99点を求めるかを判断する
コメント
コメントを投稿