エンジニアはビジネス開発がもっと得意になっても良いはず！

技術開発を行うエンジニアは、もっと事業開発ができるようになれるはずだし、もっと二刀流みたいな人が現れても良い気がしてるんですよね！！という話です。

だって、どっちも「開発」だし、というシンプルな理由だけなのですが。

いろんな人と話していると、技術開発と事業開発を分けたがる人が多い気がします。もちろん、餅は餅屋というように専門領域で勝負した方がより良いものができるようのは事実かもしれませんが、もっと技術屋から事業開発側に踏み込んでも良い気がしています。

基本的には、どちらも「仮説」と「検証」の繰り返しだと思うわけです。そして、技術屋というのは、ある意味ではこの仮説検証をずっとやり続けて、身体に染み付いている職種とも言えるはず。

仮説と検証というのをもう少し分解すると、
・問題の確認
・仮説の構築
・仮説検証の方法検討
・仮説の検証
・検証結果の解析
・仮説の更新
という大きなプロセス全体を仮説検証のプロセスとも呼べますし、それぞれのプロセスの中にも小さな仮説検証が存在しています。（もしくは、大量の小さな仮説検証プロセスが存在しているという表現でも良いかも）

このように分解しても、技術開発であっても事業開発であっても、基本的なプロセスとしては同じだと思うのです。

もちろん、違いもあります。
例えば、仮説の種類が、技術的な内容であるのと市場や顧客に関する内容であるとか、データの集め方も機械などからセンサーを使って計測するのが多いのに対して、市場や顧客の定量データやヒヤリングなどによる定性データも集めていくとかです。

ざっくり言えば、仮説を立てる対象がモノになることが多いのが技術開発で、対象が人とか組織になるのが多いのが事業開発なるのもしれません。そういう意味では、最初のキャリアを医療福祉というヒトを対象とした技術開発だったのは良い経験になっているのかもしれません。

いずれにせよ、違いもあるので、どんな仮説を置くべきかとか、どうやって検証すべきかというのを効率良くできるようになるためには、ある程度の慣れが必要かもしれません。

が、やっぱり基本の型としては同じだと思います。

そして、マーケットの声や顧客の声を自分で直接浴びることは、どんな技術を開発すべきかと技術開発そのものにも当然活きますし、技術開発が行き詰まった時の頑張ろう！というモチベーションにもなります。

慣れが必要な部分にどのように慣れていくべきかというのはよくわってないですが、特に多くの技術者にとっては人間から意見を引き出すというのには慣れが必要かもしれませんが、まずは事業開発に対する苦手意識をなくすこと、興味を持つことから始まるんだと思われます。

というわけで、是非技術屋の皆さんにも事業開発を完全にシャットダウンせずし、自身の仮説検証スキルをたまには技術以外の開発業務で使ってみるのも面白いと思いますっ！！
（もちろん、技術開発に全精力を捧げ続ける人も素敵です！）

Let's BizDev!!笑

では、また来週～！！
「フォロー」や「ハートマーク（スキ）」を押して頂けると喜びますので、どんどんマークを押しちゃってください。笑
安藤健(@takecando)
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Twitterでは気になった「ロボット」や「Well-being」の関連ニュースなどを発信しています。よければ、フォローください

Tweets by takecando