【コラム】失敗を中心とした戦略

失敗は敵ではなく友達。

失敗は確かに損失だが、それを活かすも殺すも本人次第。
失敗を考慮に入れたマネジメントについて整理したので、下記にまとめる。
似たような話はそういう本でいくらでもあるが、重要なのは気付き。


専門用語は一番下に説明を入れた。

※この話は大企業などの既にブランドを確立した企業・事業には当てはまらない場合も多い。その場合はブランド戦略となるので、本記事では割愛。あと、カスタマイズ戦略も関係無し。

※失敗はここでは「イマイチ成功しなかった＝予算を満たせなかった」ものも含める。要するに、イマイチ成功しなくても、次に挑戦できるかどうかということ。

※タイミング的に誤解の恐れがあるので書いておくと、一般論的/経営/マネジメントな話であって、えびのプロジェクトやゲーム開発とは一切関係有りません。

■失敗≠リスク

失敗「した」事実自体は損失だが、計画段階では単なる「リスク」の半分にすぎない（もう半分は成功とそれによる利点）

日本だと「リスク」＝「損失」というイメージだが、「損失」の可能性と同じくして「利点」の効果もでかくなる。
（でなければ行動する意味がない。損失を発生させるために挑戦している人間など居ない。）

問題は「どのように上手く失敗するか」と考えている。
要するに、「継続性のある失敗に留める」ことが、リスクヘッジの基本概念である。

■失敗を中心とした戦略

失敗は「起こしてはいけないもの」ではなく、「起こるかも知れないもの」である。
よって、「失敗を恐れて挑戦しない」のは中小・自営としては悪手となりやすく、「失敗が来ても継続できるように挑戦を計画＆施行する」ことが大事。

継続しないのはただの蛮勇。
アメリカやグローバル企業、外資企業は性質上挑戦しないと生き残れないため挑戦しまくってるが、稀に当たるからあそこまで発展したと言える。
その足元には、潰れまくった企業や事業が無数に転がっている。（日本の起業数に比べての話。）
そして成功している企業でも、それなりに失敗は多い。問題は「失敗しても存続できるか」にある。外資だって、売り上げが見込めない要求には応じない。

なぜ挑戦しないことが悪手かは「事業戦略」に絡むため、今回は割愛。
（前どっかで書いた。要するに「弱小事業者はスキマ産業を狙え」であるとか、ブルーオーシャンとかそういうアレである。）

1.どんな挑戦も、失敗はあり得る

どんなすばらしい事業や研究も、最初は当たるも八卦、当たらぬも八卦。
予想など不可能に近い。（逆にこれが出来るスーパーマンやスーパー企業も存在する。勝てない。）

問題は「やってみること」が出来るかどうかである。

「そういう部署」を用意できるかどうかが、企業が「生き残れるか」に繋がる（「成功できるか」とはまた別。事業や市場にも、成熟期や衰退期というものが存在する。）

例を挙げれば、N社のイカゲームも、「なんでもやってみる部署」から産まれたのは有名。これは通常の部署では不可能。なぜなら「前例がない」ため、予算配分の説明が困難であるから

「売り上げに繋がるかどうか」というのは、目の前の利益、ぶらさがったニンジンに過ぎない。ニンジンが大きい間はすがった方が良いが、ニンジンは時間が経つと枯れていってしまう。

別の道にも馬を走らせ、その中の一頭が成功する、あるいは今いる馬が将来的に強くなる…そういう考えの最たるものが「研究所」である。研究所はお金を生み出さないと割り切った存在はGoogleが有名か。

2.失敗したことの後悔より、今どうリカバリーすべきか、次活かすためにどう管理するかを考えるべし

これは開発に限定しない。
失敗は失敗でナレッジDBに押し込めて、今はこの苦境をどう回避するか、どう生き残るかを考えた方が良い。
人間の処理能力や行動力、権限、あるいは脳みその容量には限りがある。

当然次回同じ失敗しないように、DBはちゃんとメンテナンスするべき。人間の記憶力なんてたいしたことないです。

3.失敗とそのリカバリを考慮して計画を立てるべし

計画を立てて実行に移すとき、失敗を全く考慮しなければ、足が出て残業確定。
そして不足の出費を考慮しなければ、首が回らなくなったり、マイナスになったりで上から文句を言われたり。

まず、ボトルネックを考慮して見積もりを立てるべきだし、予算も多めにしておいて損は無い。
もちろん限度はあるから、糸目は付けるしかない。その良い塩梅を導き出せるマネージャが強い。

4.失敗時の説明は私情（想いや言い訳）を入れない。行動の根拠に着目して客観的に説明する。

失敗したときに、言い訳は言う意味が無い。
失敗は起こるべくして起こったことが大半なので、客観的事実だけを述べるだけでいい。
そこから「じゃあどうするか」に繋がる。

皆「成功させたい」のは同じ想いなので、いちいちそれを曖昧にする必要は無い。
「～させたかったが、○○が不足して/○○が上手くできず失敗した」となれば、その○○をどうにか調達するのがマネージャの仕事である。

■最後に

内容は企業向け研修のそれっぽくなったが、もちろん自営業やソフト開発全般にも当てはまる。
失敗は恐れるものでも無視するものではない。如何に対処するかにある。

（あと、これは経営の話なので、製品の品質保証は別の問題。製品のデバッグとかチェックは今後もがんばります…はい…）

■おまけ：用語解説

・リスク

端的に言うと「失敗と成功の振れ幅」である。けして損失ではない。
「リスクが大きい」というと、「大きく失敗するか、大きく成功するか、どちらかの可能性を孕む」ということになる。

・コスト

必要なリソース。日時や労働力も含む。
これも「損失」ではなく、「必要なリソース」でしかない。成功のためには必須の要素であり、上手く使えるかどうかが問題となる。

・リスクヘッジ

リスクの損失時に備えて、用意する工数、資金、その他リソースのこと。
開発期間に余裕を持たせる、資金を用意しておく、人員を余らせておく（普段は別のチームに所属）などなど、やりようはいくらでも有る。

「1日8時間で工数見積もり」というのが工数の定番だが、はっきり言って雑務が3～5時間ある日本の企業社員では確実に足が出る。

・ナレッジDB（データベース）

知識やノウハウ、事例や失敗例をまとめたデータベース。
いちいち先輩や年配者に聞かなくても、これを引けば勝手に若者でも対処出来るようにするもの。
熟練者や先輩には、そんな手間かけさせるより、彼らにしか出来ないより素晴らしい仕事に専念して貰おう。

・ボトルネック

複数の人間で実行する場合、必ず「足止め」「待ち状態」は発生する。
例え各人の遅れが0でも、前工程が終わらなければ発注もできない。
問題は「「どこで止まっているか」「どこが遅れているか」を議論すること」ではない。
「どの工程をどういう順番で進ませればボトルネックを潰せるか」が重要。（人ではなくコト。）

よほど遅れてるとかいうのはまた別の問題となる（そのレベルになると契約などの話になるので割愛。外資はそういうのキツイ。）