なぜビジネスにおいては「失敗」の繰り返しが重要なのかを解説します（写真：Mills／PIXTA）

加速化するグローバル化にともない、ビジネスの世界でいっそう求められるようになってきた「スピード感」のある判断。実はそうした「スピード感」を実現するためには「失敗」が欠かせないといいます。グローバルな市場で勝ち抜くために必要な「失敗を正しく生かすための思考法」について、アメリカのマイクロソフトエンジニアの牛尾剛氏が解説します。

※本稿は牛尾氏の新著『世界一流エンジニアの思考法』から一部抜粋・再構成したものです。

リスクや間違いを受け入れることが生産性を加速

生産性を加速するうえで重要なマインドセットの1つとして、「リスクや間違いを快く受け入れる」というのを挙げたい。

リスクとの向き合い方は、われわれ日本人にとってかなり難易度の高いものかもしれない。リスクを受け入れるとは、欧米のビジネスシーンにおいて次のことを意味する。

・間違いを厳しく批判したり懲罰したりしない
・失敗から学ぶ態度
・Fail Fast（早く失敗する）
・実験が推奨されている
・全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される
・非難や恐怖感のない環境

これらの習慣の大切さは、私自身、渡米前から言葉ではわかっているつもりだったが、実際に現地で働いてみると、想像の範囲をはるかに超えていた。

間違いや失敗に対するイメージが根本的に違うのだ。

インターナショナルチームでまず気づいたのが、同僚や上司が「Miserably Failed（惨めに失敗した）」という言葉を頻繁に使っていることだった。

日本では「決して失敗は許されない」プロジェクトが多々あった。しかし、人間なので、いくら失敗が許されない状況だろうが、どんなに準備しようが、失敗は発生する。

奇妙なことに日本では、ネットでもお客さんが激怒し、炎上して中身も売れ行きもボロボロなのに、納期と予算を守ったという理由で「成功」したことになっているプロジェクトをいくつも見てきた。

組織で失敗すると、左遷されたり詰め腹を切らされたりして悲惨な目にあうので、失敗を認めづらいのだ。だから、ビジネスにおけるあらゆる選択肢は、個人としても組織としてもつねに無難なほうへと流れてゆく。

失敗の報告には「フィードバックをありがとう！」

一方、アメリカでは、失敗や間違いで怒られることが皆無だ。失敗に気づいた後に、本社に報告すると、「フィードバックをありがとう！」と大変感謝される。

もっと言うと、誰がやってもうまくいくようなことを無難に実施してミスがなくても、それは評価の対象にならない。

例えば、私は本番環境をお客さんとハックして改善する「ハックフェスト」という取り組みをやっているが、そこではいつも「お客さんの最も難しい問題を解いてこい」と言われる。

つまり、世の中のどこにも情報が落ちていないような問題解決に取り組むことが評価されるのだ。

誰かが失敗したところで「あいつはダメだ」とネガティブに言っている人は見たことがない。だから、より難しいことへのチャレンジがすごく気楽にできるのだ。

社内のイベントのハッカソンでもその主導者が「今日はたくさん失敗しよう！」と掛け声をかけていたのが印象的だった。

まずはやってみる「Fail Fast」の精神

むしろチャレンジしないほうが、会社の将来のリスクを高める。だから成功しようがしまいが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく――Fail Fastの精神だ。


（出所：『世界一流エンジニアの思考法』）

この考えはアジャイルやDevOpsなどすべてのモダンな開発手法に共通する思想だ。人間は間違う生き物だということを出発点にしている。

「リスクや失敗」を恐れる体質は、生産性の面で劇的な低下をもたらしてしまう。失敗したくないと、ともかく慎重になってしまうからだ。

時間をかけたからといって失敗をゼロにできるわけでもないし、時間をかけている間にライバルはどんどん次に進んでしまうのに。

私がアメリカであるお客さんとディスカッションをしていて驚いたことがある。リュックを1つだけ背負ったその兄ちゃんが、私と上司のダミアンに会いに来て1時間ぐらい話をしたあと、「うん。やろう」と言って、500人規模のハックフェストをその場で決定して帰っていった。

これが日本なら、まずベンダーが提案して、顧客がそれを見てExcel で質問票をつくり……といったやり取りを数カ月行って、結局はやめたみたいなことがしょっちゅう起こる類の案件だ。

これはベンダーにとっても顧客にとっても大きな損害で、工数を使って結局は何も生み出せていない「ノーバリュー」の仕事なのだ。

机上の検討を積み重ねても現実に即応できない

でも1時間で物事が決まって、実際にハックフェストを実施すれば、本番環境の検証がわずか数日でできてしまう。

Excel でいちいち質問票をつくっている時代ではない。そんな暇があったら、実際にハックして確認したほうが100倍確実な成果に結びつく。

今の時代、検討ばかりして、さっさと「やらない」ことのほうが最大のリスクだということを肝に銘じてほしい。やらないほうが必ず失敗する確率が増えるのだ。

机上でいくら慎重に検討しても、実際市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーが適切に動作するかは、実施するまではわからない。

だから少なくとも変更がしやすいソフトウェアの世界は、アジャイルのように早く実装して、早くフィードバックを得る方式のほうが合理的だ。

でも、「早くやるのはいいけど、ちっとも進歩せず、同じ失敗ばかりを繰り返す人（チーム）もいるじゃないか」と思う人もいるかもしれない。ごもっともな指摘だ。

そこへの回答は「評価」だと思う。

基本的なスタンスとして、「従業員への信頼」を慣習とする多くのアメリカ企業では、普段の業務において細かいことを言わない。

最初に会社と合意したゴール、つまり大まかなKPI（重要業績評価指標）を達成していたら、途中で失敗しようが、人より不器用だろうが何だろうがとくに問題にはならない。まずはその人を信用する。

KPIが達成できなければ、1年の評価のタイミングで、給料が下がったりクビになったりする。ただそれだけの話だ。

自分との戦いに勝つことが高報酬への道

マイクロソフトの場合は、「何ができるか」でエンジニアとしてのランクは明確に定義されており、自分のランクによって給与は決定される。

給与を上げたかったら1つ上のランクの仕事をしてKPIを達成する。するとマネジャーがプロモート（ランク上げ） しようとノミネートしてくれる。


ちなみにGAFAM（Google、Amazon、Facebook、Apple、Microsoft）のソフトウェアエンジニアの年収は、新卒1〜2年目で約15万〜19万ドル、入社数年で19万〜27万ドル、シニアエンジニアクラスで27万〜40万ドルだ。

他人との比較ではなく、自分との戦いでレベルアップしていく仕組みだ。

フェイスブックのベテランエンジニアに至っては100万ドル近い報酬を得る（ボーナス等含む。年収が上がるにつれ自社株での支払い比率は高くなる）。

元アマゾンのプロダクトマネジャー・ゆうさんのブログ（https://honkiku.com/gafa-salary/）も参考になるので、興味のある人はチェックしてみるとよいだろう。

ランクが上がるごとに給与レンジが跳ね上がるため、スピーディーにチャレンジを重ねてKPIを達成したものが相応に報われる仕組みとなっている。

（牛尾 剛 ： マイクロソフトエンジニア）