僕のお気に入りの［梅田望夫・英語で読むITトレンド］のある日本のベンチャー経営者の本音という記事を読んで考えたことをメモする。れんちゃんでトラックバックかけて、ごめんなさい。でも、この記事に関してはどーしても気になることがあったんで。

以前からず～っと疑問に思っていて、やっぱり疑問が解決してないんですけど。

「もちろんIPOは素晴らしいとか、そういうことは日本のエンジニアも皆、理解しているんです。でもそれをカネに還元して考えない。充実感とちょっとのボーナスでいい。その代わり、リスクは社長が全部とってくれと。俺たちにはわからないから。そういう感じなんだな。これは日米の両方を経験してみないとなかなかわからない違いでした」

この文章についての疑問。特に、

リスクは社長が全部とってくれと。

の部分。
逆に言ってしまえば、リスクは社長が全部とるのではなく、エンジニアもリスクを取ることができる。
「エンジニアが取ることができるリスク」って何だ？
これって僕にとってすんげぇ曖昧なんですよ。
一応僕の中ではぼんやりと定義はあるんですが、どうもこの部分、経営者と（一介の）エンジニアでは大きな隔たりがある気がしてならないんです。
いついつまでに、これそれのものを作ります。
これができるかできないかはやってみなければわからない。できるかもしれないし、できないかもしれない。できる可能性はXX%でしょう。
これってエンジニアが取れるリスクの定義として正しいでしょうか？
開発に対してのリスクを以下の点から見積もります。
期間と難易度と完成度
期間が長ければ難易度が高くてもこなせます。期間が長ければ完成度を上げることができます。難易度が高ければ期間が足らないかもしれませんし、期間が足らないことによって、完成度が落ちるかもしれません。完成度は多少低くてもいいから期間を優先してしなければならないのか、それとも逆なのかも考えます。難易度にも程度があって、今の技量で可能なのか、どれくらいの期間で可能なのか、などなど考えます。
以上の事柄を総合的に判断して、見積もります。
正確に見積もることができるエンジニアは優秀なエンジニアだとされます。
これはすなわち、誤差の少ない見積もりが作れるエンジニアは優秀だということになります。
例えば、
あるプロジェクトを見積もったとして、10ヶ月で終わるだろうという見積もりができたとします。
優秀なエンジニアが見積もった場合、10ヶ月丁度で終わる確率が50%。1ヶ月早く終わって9ヶ月で終わる確率が10%、1ヶ月遅く終わって11ヶ月で終わる確率が10%になりました。
ちょっといまいちなエンジニアが見積もった場合、10ヶ月丁度で終わる確率が40%、1ヶ月早く終わって9ヶ月で終わる確率が20%、1ヶ月遅く終わって11ヶ月で終わる確率が20%になりました。
10ヶ月で終わるだろうという見積もりはどちらも同じです。違いはその正確さです。優秀なエンジニアが見積もった場合、その見積もりはより正確なものになるので、10ヶ月で終わる確率が高くなります。また1ヶ月前後する確率も下がっています。
この10ヶ月という見積もりのプロジェクトを9ヶ月で終わらせるという挑戦を考えた場合、
優秀なエンジニアが9ヶ月で終わらせるという見積もりの確率は10%
いまいちなエンジニアが9ヶ月で終わらせるという見積もりの確率は20%
これでは、優秀なエンジニアであればあるほど、見積もりが正確になり、見積もりが正確であればあるほど、リスクが取れないことになってしまいます。
以上のことから、どうも先のこれってエンジニアが取れるリスクの定義として正しいでしょうか？は間違っているという答えになりそうです。
では、この先を考えます。
優秀なエンジニアが考えた見積もりに、9ヶ月で終わらせる見積もりの確率は10%とあります。この10%という確率を50%に引き上げることができるかっていうのが、考えられます。
いろいろ考えた末に、無駄な要素を省いたり効率化したりして、9ヶ月で終わる確率が上がるということが考えられます。
これもひとつのリスクと考えることができます。
10%を50%に引き上げる確率が10%
10%を20%に引き上げる確率が30%
これならば９ヶ月で終わることにより、１か月分の金銭を得することになりますからなんとなく「経営者」が期待しているリスクと一致している気がします。
でもこの話って、なんか矛盾してます。
優秀なエンジニアであればあるほど、見積もりが正確になっていきます。
でも優秀なエンジニアであればあるほど、見積もりよりも短い期間で終わる確率が高くなっていきます。
見積もりよりも短い期間で終わる確率が高くなるってことは、見積もりが正確じゃないってことになります。見積もりが正確じゃないってことは、優秀なエンジニアじゃ無いです。
自己否定になっています。
次に9ヶ月で終わらせる確率を10%から50%に引き上げる確率を上げる「方法」について考えて見ます。
無駄な部分を省く。
効率化する。
などなどいろいろ考えられますが、一番簡単なのは、無駄な部分を省くという方法です。
この無駄な部分という定義は実はエンジニアにとってはすごく難しいところでして、無駄な部分を省こうとして、必要な部分まで省かれてしまうという問題がすぐそばに待っています。
例えば、テスト期間を省く、構造の作りこみを省く、コメントを横着する、などなどです。調査の時間を省いて一気に作成にとりかかったり、十分なデザインの検討をしないまま、作業に入ったりするのも同様のことです。ときにはユーザーの便利さを差し引いても、「機能は実現されているからええか。」ってな無茶苦茶な論理で進められたりします。「期間」を縮めるために「難易度」と「完成度」を下げてしまうわけです。
「難易度」に関してはエンジニアの都合ですから直接顧客には影響を与えません。しかし「完成度」は影響が大きいです。「期間」という項目をとったばっかりに顧客の信用を失いかねません。
これは言ってみればひとつのリスクです。「完成度」が下がる可能性が上がるにつれて「顧客の信用を失う」確率を上げているわけです。このリスクに関してはエンジニアは明確に認識することができます。またこれ以外にも「将来この製品をメンテナンスするための手間」を借金している場合もあります。完成度を下げたことによってメンテナンス性が悪くなり、機能拡張や修正に膨大な時間を必要としてしまう危険もあります。これらのリスクを取ってでも「期間」を優先しなくてはならない場合もあれば、逆に「顧客の信用」を優先して「期間」を犠牲にするのか、と、リスクとそのバランスを取りながら進めることができます。これに関しては、なんとなく理解できているつもりです。
もうひとつの9ヶ月で終わらせる確率を10%から50%に引き上げる確率を上げる方法は、「デスマーチ」を繰り広げるということです。
残業バリバリ、２４時間営業でプログラムを書き上げる方法です。これにはリスクがあります。健康を害することもありますし、集中力を下げ、効率を下げる可能性もあります。自分自身がデスマーチを繰り広げる場合、さまざまな問題が簡単に想像できます。自分がマネージャで、メンバーに「デスマーチ」を要望する場合には、メンバーのモチベーションを下げる、メンバーが体を壊す、退職する。その他、メンバーがスキルをあげるための時間をそぐ。などなどの問題も考えなくてはなりません。これも、リスクとバランスを取りながら進めることが可能です。しかし、これって最終的には「根性」とか「気合」って話になってしまってどうにも、しっくりきません。
どうにもこうにも僕にはこのあたりがわかっていないようなんです。
このあたりの感覚が経営者とエンジニアとの間にあるずれなのか、それとも僕が思っている「エンジニアが取るべきリスク」という定義が間違っているのか。
エンジニアがリスクを取ってその損害が出た場合、その損害はエンジニアにとってどのようなものなのか。またその損害を挽回するにはどのような手を打つことができるのか。というのがどうにもよく理解できていない気がします。「金銭的損害」もそうですし、「デスマーチが発生する」というのもひとつの損害ですし、「会社の信用を落とす」だったり、もっと直接的に会社がたちゆかなくなったりすることも考えられます。
何をやっても結局「デスマーチ」に突入するかしないかを考えるわけで、これじゃ「リスクを取る」イコール「デスマーチをやる」になってしまいます。
どうにもこうにも僕の「リスク」の考え方が間違っている気がしてならないんです。
僕は「リスクを取らない限り利益を得るのは難しい」と考えています。
しかし、僕自身、なんとなくエンジニアとして「リスクを取る方法」または「リスク」そのものがよくわかって無いように感じるんです。
ということは「利益を得る方法」もわかって無いってことになるので、とっても悔しいんです。
このあたりが、自分自身、すんげぇ未熟者のエンジニアだと感じるところであったりして。
これを理解するために「リスク」の定義がわかりやすい「投資」を考えてみました。
「投資」においての「リスク」とは、期待される（予想される）リターンのぶれの大きさです。例えば、９０％の確率で100万円損します。でも１０％の確率で900万円得します。この期待値は確率的には０です。長期に続ければ損もしなければ得もしません。10%が11%にできる方法があれば、それを実践すれば1%分有利です。逆に100万円の損ではなくて200万円の損であれば、期待値が負になるので、この投資は損であることがわかります。このように結構明確にやらなければならないことを考えることができます。
実際に「株式投資」をかじるようになって、このような数学はなかなか難しいということがわかってきました。確率を明確に決められないし、損得の予想値も、そこから導き出される期待値もうまく定義できないんです。
このような「リスク」の定義をエンジニアリングに対応しようとしても、なんとなくピンとこない。
やっぱり「デスマーチ」に直結しちゃって、どうにもこうにも頭悪過ぎます。そのうえ、期待値が正なのか負なのかが明確に定義できないので、明らかに負の期待値であっても、突撃して行って「デスマーチ」の出来上がり、挙句に玉砕というパターンが多く見られます。案外、経営者が気がつかないところで、エンジニアには負の期待値になっていることが見えていて、負の期待値に突撃できねぇと考えているのかもしれません。
まぁ金銭的にパンクすれば経営者だろうがエンジニアだろうが「デスマーチ」するわけですから、それはそうゆうもんだと考えたほうがいいのかな？
もしそうならば、普通にやっていてもデスマーチは普通に発生するので、エンジニアがデスマーチを嫌がるってのは、そのままリスクを嫌がるってことにつながるので、気持ちはわかるな。
俺って「デスマーチ」にトラウマがあるのかな？
考えてみると、リスクを取ったことによってこうむる被害（デスマーチ）は明確にイメージできるけど、得られる利益がぼんやりとしかイメージできてないところに、僕のリスクに関する考え方の曖昧さがでてるのかもしれない。
逆に「リスクを取る」イコール「デスマーチをやる」っていう定義はシンプルで安直だけれども正しいことなのかな？
「エンジニアがリスクを取りたがらない」と感じる経営者は多いはず。
是非とも経営者側のご意見を教えてください。（ご教授ください。）

スーツとギークは永遠に相容れない存在だが、それぞれ相手が何を考えているのかは知っておいたほうがいい。