ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「8つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。最初の習慣は次のブログで紹介してみた。Fast(早く失敗する)実験が推奨されている全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される非難や恐怖感の無い環境この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。Failed(惨めに失敗した)」という言葉を頻繁に使っていることだ。日本では「決して失敗は許されない」というプロジェクトが過去にも多々あった。人間なので、いくら失敗が許されない状況だろうが、どんなにしっかり準備しようが、「失敗」は発生するのだ。日本だと、例えばこってこてに炎上して、お客さんが激怒し、中身もボロボロなのに、納期と予算を守ったという理由で「成功」したということになっているプロジェクトをいくつも見てきた。文化的にも失敗したら「切腹」したり、「左遷」されたりと、悲惨な目にあうので、日本の社会では「失敗した」ということをとても言いづらい。多くの人は失敗しなさそうな無難な方に流れてしまう。本当にこれはもったいないことだ。インターナショナルチームで気づいたことだが、失敗とか、間違いとかで怒られたことは無いといっていい。失敗したり、間違いに気づいた後に、本社に「フィードバック」をすると、「フィードバックをありがとう!」と大変感謝される。誰がやってもうまくいくようなことを実施しても誰も評価してくれない。今、お客さんの本番環境をお客さんとハックして改善する「ハックフェスト」という取り組みをやっているが、そこでいつも言われていることは「お客さんの最も難しい問題を解いてこい」と言われている。この世のどこにも情報が落ちていないような問題解決をやること。これが評価されるのだ。誰かが失敗しても、黙ってることもないし、失敗しても「あいつはだめだ」とか言ってる人を見たことがない。すごくチャレンジしやすく感じる。難しいことへのチャレンジも大変気楽にできる。チャレンジしないほうが、将来が不安だ。成功しようが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく。全て共通する考え方だ。普通人間は間違うんだもの。恐ろしい事この「リスクや失敗」を恐れる性質は、生産性の面で劇的な問題をもたらしている。失敗したくないので、ともかく慎重になるのだ。慎重に時間をかけたから失敗を減らせるわけでもないし、時間をかけている間にライバルは次に進んでしまう。前にもブログに書いたことがあるが、私が米国でお客さんとディスカッションをしていて一番驚いたことがある。彼は私とDamienと1時間ぐらい話をしたあと。やろう」と言って、500人規模のハックフェストをその場で決定して帰っていった。日本で同じことが起こるとすると、まず、ベンダーが提案して、顧客がそれを見て、Excelで質問票を作り、、、といったやり取りを数か月行って、結局やっぱりやめたみたいなことがしょっちゅう起こる。これはベンダーにとっても顧客にとっても大きな損害だ。時間だけが過ぎて、工数を使って結局何も生み出せていない。1時間で物事が決まって、実際にハックフェストを実施すると、本番環境でいろいろ起こるような検証が数日で出来てしまう。今の時代はExcelで質問票を作っている場合ではないのだ。それをしている暇があったら、実際にハックをして確認したほうが100倍確実だろう。今の時代、いろいろ検討ばかりして、さっさと「やらない」ことが最大のリスクになってくる。いうことが起こると、恐ろしいことに失敗確率が増える。卓上でいくら検討しても、実際やってみないとわからない。卓上でやっていたら、結局市場に出したらどういう反応が返ってくるか、本当にそのテクノロジーは適切に動作するか?というフィードバックは、結局実施するまでわからない。少なくとも変更がやりやすいソフトウェアは、アジャイルのような早く実装して、早くフィードバックを得る方法が採用されている。機能しているものを変更して失敗するリスクがあるものを避ける傾向も強くなる。同じ失敗ばかり繰り返す人は?じゃあ、まったく進歩せず、同じ失敗ばかりを繰り返す人はどうするんだ?と思うかもしれない。その解答は「評価」だと思う。他の習慣で、「従業員への信頼」という習慣がある。人に対してごちゃごちゃ細かいことは言わない。最初に会社と合意したゴールつまり大まかなKPIを達成していたら、失敗しようが、人より不器用だろうが何だろうがいいのではないだろうか?その人を信用しよう。KPIが達成しないので、給料が下がったりクビになる。評価はそのタイミングでよくて、失敗は結果論であるので、それよりも「フィードバック」を得たかを気にしよう。私のパートナーのクロスカルチャーの専門家のロッシェルさんがこういう話をしてくれた。米国では、プロジェクトが中止になったら、プロジェクトが成功したのと同じようにパーティをする会社があるらしい。その失敗から「学ぶ」ことが出来たからだ。この「習慣」は生産性に非常に影響してくるものだ。逆にいうと、これを身に着ければ、簡単にライバルに差をつけることができる。この「習慣」を獲得するにはどういう方法があるだろうか?「リスクや間違いを快く受け入れる」プラクティス成功・失敗より「フィードバック」を歓迎するムードを作る「検討」をやめて「実証」する「早く失敗」できるように考えるそれぞれについて解説してみよう。上位マネジメントプロダクトオーナチームこれもほぼ全員だが、誰かが、誰かの「失敗」を責めるケースが多い順に考えてみた。成功・失敗より「フィードバック」を歓迎するムードを作る最初のプラクティスだが、チームメートや部下が成功したら当然喜んであげたい。失敗して、フィードバックしてくれたら、失敗する方法がわかったのでこれは大きな進歩なので、感謝しよう。失敗して「怒る」ということはあなたと対等である人を「子ども扱い」しているのと同等だ。いう気持ちはわかるが、「怒る」という選択肢はなくして、「フィードバック」を促進するようにムードを作ろう。メールで、成功の報告を見たら、みんなで「おめでとう」のメールを返そう。メールで、失敗とそのフィードバックをしてくれたら「感謝」のメールを返そう。マネージャなら、本人の評価はあくまで約束したKPIの達成の可否であり、小さな成功や失敗ではない。いうことを明確にしていこう。このムード作りは、上位マネージメントの方から仕掛けていただくほうがいいかもしれない。「検討」をやめて「検証」するあなたがユーザ企業や上司ならば、パワーポイントに書かれた大量の資料を要求したり、完全無欠の検証を期待するより、時間をかけず、さっさと「検証」してフィードバックを得るようにしよう。人間未来は予測できない。あなたがユーザなら、ベンダーに「提案」を依頼すると、例えば私が大手のSIに勤務しているときは、提案書を作るのに何人もの人が数週間もかけて作っていた。正直に言うと今の時代、大量に検証しても制度が低いし、マニュアルに「出来る」と書いてあっても実際作ってみるとできないなんてことはしょっちゅうある。その工数は、あなたがそのベンダーに発注したときにOnされてね返ってくる。Lose-Loseの関係だ。そんなのよりも、クラウドの時代でさらに加速したが、実際に作ってみるほうがよっぽど早い。過去と比べると圧倒的に早くできてしまう。ああでもない、こうでもないと検討するのではなく、実際に作ってみる「ハックフェスト」などを通じて、動くもので検証しよう。ほかにもあの機能を実装するべきか、この機能を実装すべきかと検討している暇があったら、実際に実装して、ベータテストで実際のお客様で試してデータを取ろう。思ってもない結果になるかもしれない。今の時代最もリスクなことは「何もしない」ことだ。検討している暇があったら、今すぐ実装して試してみよう。アーキテクチャやツールが数種類あってどれにするか決めあぐねているパターンがある。それを意思決定するのは簡単だ。答えは「どちらでもいい」ので趣味で選べばよい。圧倒的に差があるのなら、決めあぐねるはずがないので、どっちを選択しても大差ないということなのだ。昔と違って、ツールやサービスの単価は高くない。1つのツールで失敗したら次のにさっさと乗り換えればいい。それより早く前に進もう。実践の経験を積み重ねるほうがよっぽど貴重なことだ。「早く失敗」出来るように考えるこれも、2.に近いが、近代の開発では、「フィードバックが遅い」というのが致命的な問題になる。ウォータフォール時代だったら、要件定義をして、設計をして、実装して、テストをする頃になってやっと実物のアプリを作るので、ここで、いろんな問題が発覚することが多い。実際の「フィードバック」を受けるまでの時間が長い。早く試して、失敗して、フィードバックを受けて早く方向修正する。早く正しい方向性を見つけていく。最初から「正しい方法」がわかっている人は今の時代に存在しない。リスクがあったらさっさと手を付けて、失敗してフィードバックを得よう!いかがだっただろうか?もっといいプラクティスがあるかもしれない。私もまずは3つをピックアップしてみた。いいものがあれば是非シェアしていただければ大変うれしく思います。次回は「不確実性を受入れる」についてお話いたします。キャンパスで行われたマイク...2016-09-07英語鎖国で深刻なのは情報入手のスピードじゃないと思うエンジニアに英語が必要と言われて久しい。»プロフィールid:simplearchitectアジャイルコンサルタントの日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。勉強したり、留学したりすればするほど、英語のレベルが落ちている現象を考察してみたアメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法アメリカに住んで初めてわかった「最大級」の違いググるのをやめるとプログラムの生産性が上がるかもしれない月別アーカイブ参加グループプログラミングはてなブログをはじめよう!simplearchitectさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。