レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

ゆでガエルの回避

ゆでガエルの法則をご存知だろうか。

以下、経営コンサルタントさんの事業計画についてのサイトより。

以下の日本企業が倒産する原因の統計グラフをみてほしいのですが。


注目すべきは「既往のしわよせ」。7%*1で2番目に多い倒産原因です。


この実態は「ゆでガエル」。


カエルを冷水からゆっくり熱していくと、命の危険を知覚できずに最後までジャンプせずにゆで上がってしまうという話です。
業績悪化が危機的レベルにも関わらず、具体的な数値を理解していないので、倒産してしまうケースです。
経験のある経営者は、

  • 具体的な経営指標を把握している
  • リスクトリガー(ジャンプするキッカケとなる閾値)を定義する
  • 速やかに対策を実行する

例えば、「この事業が失敗するのってどんな場合ですか?」
人生をかけて全力で事業をがんばっている社長さんに向かって、こんな失礼な質問をするのは心苦しいのですが、このような質問をあえてさせていただくことがあります。


経験のある経営者の答えは
「商品Aの単価が500円より低くなって、月に2万個以上売れなくなるとヤバイね。みんなでサービスBのバイトで稼がなきゃ。」
左脳に訴える経営指標と「これはヤバイ!」と右脳に残る危機感、なりふり構わずリカバリー策を実行する決意を持っているのです。

『今まで誰も教えてくれなかった事業計画の本当の考え方』〓リスク編〓

「ゆでガエルの法則」は、企業経営のみならず
自己管理を含めたすべての管理作業において、陥る可能性がある落とし穴だと思う。
定量的リスクトリガーを定義するという解決策は有用だと思うので、
現場でのプロジェクト管理に当てはめて考えてみる。


・仕様変更のリスク
 仕様変更は、あって当然のものなので、ある程度は許容するが
 全体のコストの10%を超える変更内容の場合、顧客と打ち合わせてコストの検討会を行う。

・バグ発生率のリスク
 単体テスト時に、テストケース数の10%未満のバグ発生率の場合、テストケースもしくはテストの方法に問題がある場合がある。
 テスト実施方法の見直しなどを行う。


各チームや各個人の自律に任せるほうが、チームは効率的に動く。

こういった閾値をいくつか設定していれば、リスクの回避も可能かもしれない。

*1:引用注:図では11%となっている、文中が誤記だと思われる