メソッド屋のブログ

米マイクロソフト Software Development Engineer 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

「検討」は無駄である - リスクや間違いを快く受け入れる第2の習慣

仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「8つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。

f:id:simplearchitect:20170116001908j:plain

最初の習慣は次のブログで紹介してみた。

simplearchitect.hatenablog.com

リスクや間違いを快く受け入れる

f:id:simplearchitect:20170116002322j:plain

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

この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。ということは、この習慣が身につけば相当かっこいいかもしれない!

間違いや失敗に対するイメージの違い

マイクロソフトのインターナショナルチームで働いていて気づいたことだが、同僚や上司がよく「Miserably Failed(惨めに失敗した)」という言葉を頻繁に使っていることだ。日本では「決して失敗は許されない」というプロジェクトが過去にも多々あった。しかし、人間なので、いくら失敗が許されない状況だろうが、どんなにしっかり準備しようが、「失敗」は発生するのだ。日本だと、例えばこってこてに炎上して、お客さんが激怒し、中身もボロボロなのに、納期と予算を守ったという理由で「成功」したということになっているプロジェクトをいくつも見てきた。文化的にも失敗したら「切腹」したり、「左遷」されたりと、悲惨な目にあうので、日本の社会では「失敗した」ということをとても言いづらい。だから、多くの人は失敗しなさそうな無難な方に流れてしまう。本当にこれはもったいないことだ。

f:id:simplearchitect:20170116014642j:plain

 一方、インターナショナルチームで気づいたことだが、失敗とか、間違いとかで怒られたことは無いといっていい。失敗したり、間違いに気づいた後に、本社に「フィードバック」をすると、「フィードバックをありがとう!」と大変感謝される。そして、誰がやってもうまくいくようなことを実施しても誰も評価してくれない。例えば今、お客さんの本番環境をお客さんとハックして改善する「ハックフェスト」という取り組みをやっているが、そこでいつも言われていることは「お客さんの最も難しい問題を解いてこい」と言われている。つまり、この世のどこにも情報が落ちていないような問題解決をやること。これが評価されるのだ。誰かが失敗しても、黙ってることもないし、失敗しても「あいつはだめだ」とか言ってる人を見たことがない。だからすごくチャレンジしやすく感じる。

   だから、より難しいことへのチャレンジも大変気楽にできる。むしろチャレンジしないほうが、将来が不安だ。だから、成功しようが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく。この考えはアジャイルや、リーン、DevOps に全て共通する考え方だ。だって、普通人間は間違うんだもの。

最も恐ろしい事

この「リスクや失敗」を恐れる性質は、生産性の面で劇的な問題をもたらしている。失敗したくないので、ともかく慎重になるのだ。慎重に時間をかけたから失敗を減らせるわけでもないし、時間をかけている間にライバルは次に進んでしまう。

 前にもブログに書いたことがあるが、私が米国でお客さんとディスカッションをしていて一番驚いたことがある。リックを1つだけ背負ったにいちゃんが、私とDamien に会いに来た。彼は私とDamienと1時間ぐらい話をしたあと。「うん。やろう」と言って、500人規模のハックフェストをその場で決定して帰っていった。

f:id:simplearchitect:20160424220436j:plain

 日本で同じことが起こるとすると、まず、ベンダーが提案して、顧客がそれを見て、Excelで質問票を作り、、、といったやり取りを数か月行って、結局やっぱりやめたみたいなことがしょっちゅう起こる。これはベンダーにとっても顧客にとっても大きな損害だ。時間だけが過ぎて、工数を使って結局何も生み出せていない。ノーバリューなのだ。1時間で物事が決まって、実際にハックフェストを実施すると、本番環境でいろいろ起こるような検証が数日で出来てしまう。今の時代はExcelで質問票を作っている場合ではないのだ。それをしている暇があったら、実際にハックをして確認したほうが100倍確実だろう。今の時代、いろいろ検討ばかりして、さっさと「やらない」ことが最大のリスクになってくる。   f:id:simplearchitect:20170116015220j:plain

 そして、こういうことが起こると、恐ろしいことに失敗確率が増える。卓上でいくら検討しても、実際やってみないとわからない。卓上でやっていたら、結局市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーは適切に動作するか?というフィードバックは、結局実施するまでわからない。だから、失敗確率が高くなる。だから少なくとも変更がやりやすいソフトウェアは、アジャイルのような早く実装して、早くフィードバックを得る方法が採用されている。さらに、機能しているものを変更して失敗するリスクがあるものを避ける傾向も強くなる。現状維持だ。

同じ失敗ばかり繰り返す人は?

じゃあ、まったく進歩せず、同じ失敗ばかりを繰り返す人はどうするんだ?と思うかもしれない。それはごもっともだ。その解答は「評価」だと思う。他の習慣で、「従業員への信頼」という習慣がある。人に対してごちゃごちゃ細かいことは言わない。最初に会社と合意したゴールつまり大まかなKPIを達成していたら、失敗しようが、人より不器用だろうが何だろうがいいのではないだろうか?その人を信用しよう。

 できないのなら、評価のタイミングで KPIが達成しないので、給料が下がったりクビになる。ただそれだけの話だ。だから、評価はそのタイミングでよくて、失敗は結果論であるので、それよりも「フィードバック」を得たかを気にしよう。私のパートナーのクロスカルチャーの専門家のロッシェルさんがこういう話をしてくれた。米国では、プロジェクトが中止になったら、プロジェクトが成功したのと同じようにパーティをする会社があるらしい。なぜなら、その失敗から「学ぶ」ことが出来たからだ。

 この「習慣」は生産性に非常に影響してくるものだ。逆にいうと、これを身に着ければ、簡単にライバルに差をつけることができる。 じゃあ、この「習慣」を獲得するにはどういう方法があるだろうか?

「リスクや間違いを快く受け入れる」プラクティス

  1. 成功・失敗より「フィードバック」を歓迎するムードを作る
  2. 「検討」をやめて「実証」する
  3. 「早く失敗」できるように考える

それぞれについて解説してみよう。マネジメント、チーム、プロダクトオーナ(チームに出すリクエストをきめる人)のロールがある場合、どういった順番で重要なプラクティスだろうか?

対象者

  • 上位マネジメント
  • プロダクトオーナ
  • チーム

 これもほぼ全員だが、誰かが、誰かの「失敗」を責めるケースが多い順に考えてみた。

1. 成功・失敗より「フィードバック」を歓迎するムードを作る

 最初のプラクティスだが、チームメートや部下が成功したら当然喜んであげたい。失敗して、フィードバックしてくれたら、失敗する方法がわかったのでこれは大きな進歩なので、感謝しよう。失敗して「怒る」ということはあなたと対等である人を「子ども扱い」しているのと同等だ。そういう気持ちはわかるが、「怒る」という選択肢はなくして、「フィードバック」を促進するようにムードを作ろう。  たとえば、メールで、成功の報告を見たら、みんなで「おめでとう」のメールを返そう。メールで、失敗とそのフィードバックをしてくれたら「感謝」のメールを返そう。マネージャなら、本人の評価はあくまで約束したKPIの達成の可否であり、小さな成功や失敗ではない。そういうことを明確にしていこう。このムード作りは、上位マネージメントの方から仕掛けていただくほうがいいかもしれない。

f:id:simplearchitect:20170116015629j:plain

2. 「検討」をやめて「検証」する

 あなたがユーザ企業や上司ならば、パワーポイントに書かれた大量の資料を要求したり、完全無欠の検証を期待するより、時間をかけず、さっさと「検証」してフィードバックを得るようにしよう。人間未来は予測できない。例えば、あなたがユーザなら、ベンダーに「提案」を依頼すると、例えば私が大手のSIに勤務しているときは、提案書を作るのに何人もの人が数週間もかけて作っていた。しかし、正直に言うと今の時代、大量に検証しても制度が低いし、マニュアルに「出来る」と書いてあっても実際作ってみるとできないなんてことはしょっちゅうある。その工数は、あなたがそのベンダーに発注したときにOnされてね返ってくる。Lose-Loseの関係だ。

f:id:simplearchitect:20170116015435j:plain

 そんなのよりも、クラウドの時代でさらに加速したが、実際に作ってみるほうがよっぽど早い。そして、過去と比べると圧倒的に早くできてしまう。だから、ああでもない、こうでもないと検討するのではなく、実際に作ってみる「ハックフェスト」などを通じて、動くもので検証しよう。  ほかにもあの機能を実装するべきか、この機能を実装すべきかと検討している暇があったら、実際に実装して、ベータテストで実際のお客様で試してデータを取ろう。思ってもない結果になるかもしれない。  今の時代最もリスクなことは「何もしない」ことだ。検討している暇があったら、今すぐ実装して試してみよう。データをとろう。

f:id:simplearchitect:20160403015344j:plain

 例えばアーキテクチャやツールが数種類あってどれにするか決めあぐねているパターンがある。それを意思決定するのは簡単だ。答えは「どちらでもいい」ので趣味で選べばよい。なぜなら、圧倒的に差があるのなら、決めあぐねるはずがないので、どっちを選択しても大差ないということなのだ。  また、昔と違って、ツールやサービスの単価は高くない。1つのツールで失敗したら次のにさっさと乗り換えればいい。つまり比較検討など無駄だ。それより早く前に進もう。実践の経験を積み重ねるほうがよっぽど貴重なことだ。

3. 「早く失敗」出来るように考える

 これも、2.に近いが、近代の開発では、「フィードバックが遅い」というのが致命的な問題になる。例えばウォータフォール時代だったら、要件定義をして、設計をして、実装して、テストをする頃になってやっと実物のアプリを作るので、ここで、いろんな問題が発覚することが多い。つまり、実際の「フィードバック」を受けるまでの時間が長い。これが問題だ。早く試して、失敗して、フィードバックを受けて早く方向修正する。早く正しい方向性を見つけていく。最初から「正しい方法」がわかっている人は今の時代に存在しない。リスクがあったらさっさと手を付けて、失敗してフィードバックを得よう!

いかがだっただろうか?もっといいプラクティスがあるかもしれない。私もまずは3つをピックアップしてみた。もしもっといいものがあれば是非シェアしていただければ大変うれしく思います。次回は「不確実性を受入れる」についてお話いたします。