リスクの話をした。技術的なリスクと、マネジメントリスクの話をした。
だいたいのエンジニアにとって、新しい先鋭的な技術と真剣に向かい合うのは楽しいことだと思う。あるいは自分からその新技術とやらに向かい合ったのではなく、向かい合わざるを得ない状況になり、それがリスクとなったとしても、それは技術を勉強し、理解すれば、リスクは減らすことができるし、そこで得られる知識は自信になり誇りになって、またエンジニアリングに向かい合う勇気をくれたりする。
でもなー、新しい技術を取り入れるとき、マネジメントのリスクは増える。このリスクを減らすのって、結構むずかしいなっておもう。じつはちょっと今強がり言ってて、このリスクを減らす方法あんましうまいの見つかってない。
先鋭的な技術を導入しようとしたとき、メンバはその技術を理解する必要があって、その理解って大体の場合、ゼロベースのところから理解をしてもらう必要がある。たとえぼくだけがその技術を知っていたところで、プロダクトってやっぱし作ることができなくて、それはやっぱり、メンバ全員がチームとして作り上げなくちゃいけない。そして、これはぼくの経験則だけれど、技術の理解の速さって人によってまるで違う。理解をする観点も、ステップも、その進捗も人によって違う。それらをうまくコントロールし、スケジュールに落とし、細かなリスクにヘッジをしていくのって、綱渡りにすらならない難易度の高さになる。
さらに言えば、そういう人を集めてチームビルドをしていくのも、リスキーになる。メンバがちゃんと確保できていればまだ良くて。だいたいの場合、こういうプロダクトを作りましょうって決まった段階で、チームメンバが定まっていない方が多い。そこから、できるだけ優秀な人を集めてチームビルドを行うことになって、もちろん一番良いのが「その技術」に対して造詣の深い人、経験者を集めるという方法になるのだけれど、先鋭的であればあるほど、そういうエンジニアを集める難易度はあがる。チームビルドを行う段になると、プロダクトのリリース時期が決まっていることがほとんどだから、ある程度妥協しないといけないときだってもちろんある。
規模が大きくなるほど、細かなリスクが命取りになるので、どうしたって保守的になる。いままで実績が十分あって、枯れていて、かつ経験者の集めやすい技術を使ったほうが良いと感じはじめる。そしてそこに、学びは少なくなる。
そういう、舵取りがむずかしくなって、シーソーみたいに揺れてるかんじが、いま現在で。そういう話をした。
