この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2017 の投稿記事です。
どうも、エンジニアマネージャーをやっているモノです。
色々あってエンジニアからマネージャーになり、そして現在マネージャーもやりつつ事業責任者も兼務する事になったので、キャリアチェンジに関して思う所を吐き出しておきます。
この記事の目的
特に最近、エンジニアからマネージャーへのキャリアチェンジに関しては世間の関心も高く事例も多くなってきた気がするのですが、エンジニアから事業責任者へのキャリアチェンジというのはまだ少なかろうと考え、知見や感想を纏めておきます。
尚、対象読者はエンジニアを想定した視点で書かれた文章になっています。
注意
事業責任者といっても事業のフェーズによって必要とされるスキルや業務内容は様々ですが、当エントリーは、 0 > 1の立ち上げ時にフォーカスした内容となっております。
また、また、特定の会社と事業ならではの背景やバイアスが掛かっている所もあるかとは思いますが、ご了承ください。
どうしてこうなった？
今の会社にエンジニアとしてジョインした後、エンジニア組織の改革を発案しマネージャーに登用され、マネジメントと組織づくりをメインミッションに動いていました。そこでの主張が、
- エンジニア（全員ではない）も事業にコミットするべきである
- 具体的にいうと事業目標であるKPIを、個人の数値目標としてエンジニアも持つべきである
- その目標数値を達成するために何をするべきかは、エンジニア自身が考えて自ら手を動かすべきである
というモノで、上記の主張を実際に制度や仕組みとして実施していました。必然的にグループや部の枠組みを超えて、自分自身がまず先陣をきって事業開発にコミットしていく必要がありました。
以上のような背景があり、私自身が積極的に口出し手出しをしていたら「もうお前がやっちゃえよ」という流れで、ある事業を任せて貰える事になりました。
業務内容
現在は、営業や事業開発を行っているグループのマネージャーと、開発マネージャーと、事業責任者の兼務という状態になっています。それぞれのグループでどういうミッションやタスクがあるのかザッと列挙してみます。繰り返しになりますが、これは0 > 1の新規事業フェーズの話です。
- 事業開発
- とにかくファクトを集める
- カスタマー調査の為、営業同行、電話営業、現場見学、接待など本当に社会性が必要とされる業務
- 拾ってきたファクトを整理し、ビジネスモデルに落とし込む作業
- 国内外の市場調査
- システム開発
- 事業開発で当たりをつけたビジネスモデルで必要になるサービス設計
- マネジメント
- エンジニアと事業開発メンバーのマネジメント
兼務が多いと業務も多くなるのは必然だと思うのですが、現状だと事業開発の業務で一杯一杯になってしまっています。幸いにもシステム開発は、信頼を置けるメンバー達に全力で任せる事ができる状況ですし、マネジメントも自律的に動けるメンバーばかりなのでチームとしてはギリギリ破綻せずにやっていけてる状況です。本当に良いメンバーに恵まれていて、彼らでなかったらまた違った問題や苦労があったのかなと思ったりもします。
就任してみて困った事
正直「全部」と言いたいくらい知らない事、初めてやる事の連続なのですが、一つ一つ振り返ります。
PLの書き方が分からない
PL（=損益計算書）を書くのが、最初に直面した謎業務なのです。全く書いたことなかったので全部周りの人に聞きながら、9割くらい助けてもらってなんとかなっています。
とはいえ、昔から有価証券報告書を読む趣味があり基礎の基礎は知識としてあったので、ギリギリなんとかなったのかなとも思います。将来事業責任者をやるつもりがないエンジニアでも、ストックオプションとは何なのか、いくらくらい手に入るものなのか、自分の会社は上場するまでどれくらいかかりそうなのか、などなど色々身になる事が多いので、JPXの新規上場会社情報をたまに覗いたりするのをオススメします。
営業のイロハが分からない
「…こ、このアポってスーツで行くんですか…？」と、32歳にもなるオッサンがまるで新卒のような質問をメンバーにするという恥ずかしい状況からのスタートでした。「オフィスカジュアルでいいですよ」、と言われたものの、それっぽい服装が無いのでユニクロに買いに行ったにも関わらず、接待や営業に ダメージジーンズ + Tシャツ という舐めた格好で行ってしまうというハプニングなどもありました。
また、普段電話が嫌い過ぎるあまり、嫁に歯医者の予約の電話とかもお願いしているくらいの状況であるにも関わらず、電話営業をメンバーが書いてくれたトークスクリプトでやるという業務も発生しました。書いてて思ったのですがコレに関しては本当にただの新卒ですね。
とは言えここで得られた成果と体験は非常に大きく、やっぱり現場やカスタマー・クライアントの声を直接聞けて、尚且つインタラクティブにやり取りが出来るというのは、貴重な物でした。当たり前だとは思うんですけどね。
圧の掛かるプレゼン発表
新規事業ですので、会社の偉い方々にプレゼンをする機会があります。投資家に資金調達のプレゼンを行うのと同じです。これが恐らく最も精神的にタフじゃないと務まらない所で、大体毎回開始3分で「ちょっと待って」と止められ、残り57分はロジックの甘さを激詰め（※誇張表現です）される流れになります。全てにおいて自分たちの詰の甘さが招く結果ではあるのですが、やっぱり人間起案を持っていく時はウッキウキで自信満々の状態で行くわけです。
毎回プレゼン前はお花畑、プレゼン後はお通夜みたいな流れを繰り返し、良くわからない心の筋肉（でも多分大事な筋肉）が鍛えられていくという事を経験できました。何よりもこれが一番貴重な経験になっていると実感しております。
ただし、これは事業の起案だけでなく本来ある程度エンジニアもKPIに責任を持って仕事をしていく上で経験するべき流れだと私は考えています。私自身エンジニアでありながら、そういう経験を積んでいたので、ある程度シームレスにキャリアを移行できたのかなと感じています。
エンジニアを経て事業責任者になる事に関して
エンジニアから事業責任者になる人が増えるべきかどうかとか、事業責任者も技術を理解するべきだ、という論争に対しては、今は中立であり特に強い意見は持っていません。ただ、最近特に若いエンジニアに「将来どういうエンジニアになりたいの？」と聞いてみると、事業を創れるエンジニアになりたいです、と返ってくる事が非常に多いです。まぁ若いかどうかはともかくとして、事業を創っていくエンジニアになりたいと考えている方に一つ、 「エンジニアも事業責任者も根本的には何も変わらないですよ」 というアドバイスがあります。事業責任者の全てを知った上で語るワケではないので（むしろほんの一部しか知らない）、このアドバイスは仮説込みでの話にはなりますが…。
さて、どういうアドバイスなのかというと、ここまででも何度か触れていますが、「エンジニアもKPI目標を個人の目標として持ち、それを達成するために何をやるかは自分自身で考えるべき」という主張が私にはあります。もちろん全てのエンジニアがそう有るべきだという主張ではないです。
そしてその担当するKPIというのは個人のスキルによって抽象度を調整するべきだと考えています。例えば新卒だったら、「あるボタンのCVRを0.5%上げよう」、それなりにレベルの高いエンジニアだったら「有料会員登録率を上げよう」といった具合です。逆にそのKPI目標を割り振る側としては、「誰にそのKPIを割り振れば一番上手くいくか」を考えるべきです。もし達成出来そうなメンバーがいないのであれば、事業の目標と抱えているメンバーの力量の差異が人材採用要件です。
担当しているKPIに応じて、必要とされるスキルや、やらなければならない事は全く変わってくるというのは想像に難くないでしょう。色々な意見があるかとは思いますが、私は事業責任者とは単純にこのKPIツリーの頂点にある目標を自ら設定して責任を持つ人格だと考えています。
私はこのKPI達成を目標とする仕事を、タスクベースの仕事と対比させて、ミッションベースの仕事と便宜上呼んでいます。このミッションベースの延長線上に事業責任者の仕事もあるんじゃないかと思う訳です。弊社は（全てではないですが）このミッションベースの仕事を体系化し、仕組みとして展開している会社でもあります。もしこの話に興味を持ったエンジニアの方がいらっしゃりましたら、是非 @soplana あたりにお声掛けください！ カジュアル面談でもご飯食べながらでもお話しましょう。
最後に
これは蛇足だと思うのですが、ぼんやり思っている事に関して。
エンジニア上がりの事業責任者とかPMですが、「エンジニア上がり」というブランドの賞味期限は1-2年くらいなんじゃないかなと思ったりします。自分が持っている技術の陳腐化が早いというのもあるのですが何より感じるのは、思考回路の変化が強烈でした。
当然の事かもしれないし、極論かもしれないけれど、「開発の事情よりも、事業の事情を優先」してしまいガチです。ただこれは事業に寄った事で起こった変化なのか、開発メンバーに対して「彼らならなんとかしてくれる」という全幅の信頼を寄せているから、なのかはちょっと良く分かっていません。スーツ vs ギークという話ではありませんが、ギークのボスだった自分が、いつの間にかギークから見た時のラスボスみたいにならないように気をつけて生きていきたい所です。
