とりあえず作る

受容の不確実性が低く、技術の不確実性が高いものに
ついては、技術ロードマップに則って開発していけば
いい。もちろん、それにしても非常に難しい。


一方で、受容性の不確実性が高く、技術の不確実性が
低いものについては、とにかく作ってみたらいい。
とりあえず作って、それでいいか悪いかの判断をして
みたらいいと思う。


でも...。


それだけでは不十分だ。やはり作った後に何が起きそ
うか、というのをきちんと仮説としてもっておかなけ
ればいけない。そうでないと、予想通りの答えだった
のか、予想外の答えだったのか、という判断ができな
い。


事業部にいたときに、とりあえずNW機器を作ったこと
がある。結局、誰もいいも悪いも言わなかった。悪い
と言えないのは、作った人に対する配慮からだろうが
、まぁ、作ったNさんも言われて作っただけだから。
その結果、ただ作っただけでそれで終わってしまった
。それのフィードバックもなければ他部署との情報共
有もない。何がよくて何がダメだったかのレビューも
ない。これはよくない例だ。


では、作った後のジャッジをどうするかだ。何をもっ
ていい、悪いというかだ。Nさんのときは、お客さんの
声がまさに判断基準だった。そう考えると、例えば、
20人に使ってもらって、「これはいい！」という人が
5人でもいたらOKにする、とかそんな判断になるのだろ
うか。ここについてはさらなる検討が必要だ。


困るのが、そうしたものを持たないとずるずるやり続
けることになる。Rのテーマなんていうのがまさにそ
れだ。そしてそれにしがみつくことになる。諦めると
しがみつく、というのは似て非なるものだと思ってい
る。そうならないような判断基準が必要なんだと思う
。


ユニクロが野菜事業をやめたときは、責任者自身がう
まくいかないと感じたことだった。でも、なかなかそ
うは言い出せない。


それを言える環境を作るのもリーダーの仕事だろう。


このまえ、Mさんが新しいテーマの提案をしたときに、
Fさんが、「だいたいうまくいきそうかどうか、ってい
うのはやってる本人が一番わかっているんですよ。な
んとなくこれはうまくいきそうにないなぁ、とか...。
で、どう思っています？」なんて聞いていたが、そこ
で「実はあまりよくないと思っています。」なんて言
えるわけがない。そんなこと言った日には、「だった
ら提案してくるな」となるわけだから。