みなさんこんにちは。
私はエンジニアの大平(おおひら) (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで 株式会社プレイド で勤務しています。
日々の活動内容(プログラミング・SaaS/SIer・デジタル人材・ロードバイク・減量など)をつぶやいたりしておりますので、本エントリを読んで興味を持たれた方は、twitterでフォロー、リプライ、メッセージなどをいただければと思います。基本すぐに回答します。
こちらの記事は
障害対応という花形
の続編となります。
今回は下記の本ブログのメインストリームである「年収1000万を手放した私」のスピンオフとして書いています。
www.taihey-blog.com
- 前回のあらすじ
前回はIT業界の人事のお二方の質問をきっかけに障害対応を題材に、ビジネスとエンジニアのハブになることのキャリアの考察を深めました。
今回は、SIer / 自社開発webスタートアップを経験した私から見える、2つのビジネス構造の違いを分析し、そこで自分をどう活かしていくかを考察していきたいと思います。
0. 今回の構成
本エントリをきっかけにさらに考察を深めたのですが、結論から言います。
私は自社開発エンジニアに向いていません。
そこに至るまでとその先どうするかを綴っていきます。
今回は下記の構成で考察を展開していきます。
- 1.受託開発と自社開発の違いを分析する - 2.ぼくは自社開発に向いていない - 3.汎用ソリューション＆プロダクト機能のマッチ力で勝負する
あくまでサンプルは私の観測範囲になります。
私のキャリアがSIer大企業→自社開発webエンジニアスタートアップのため、規模の差異 × 異業種 × 異職種のため対極といっていいほど離れた環境を歩んできました。
軸を混ぜすぎてしまうと混乱するので、規模の話は置いておいて、受託：SIer/PMキャリア→自社開発/webエンジニア軸で考察することにします。
1. 受託開発と自社開発の違いを分析する
■ ビジネスモデルの違い
- 受託は顧客のシステムを作る
まずはビジネスモデルの違いから見ていきましょう。
受託と自社開発はビジネスモデルが違います。前提としてここが差異が大きく、話のベースとなります。
まずはこの差異について考察していきましょう。
こちらの図を御覧ください。
図の登場人物は顧客、顧客が使うシステム、付加価値とお金を産むビジネスモデル、提供先のエンドユーザー、受託会社となります。
システムとはビジネスモデルを最大化する資産であると私は認識しています。
資産の所在は顧客会社にあり、これをどのように作るかでビジネスモデルを成長させていきます。
受託会社側はこのシステムを作らせてもらう形で業務を請け負います。
- 自社開発は自分たちのシステムを作る
自社開発の場合はどうでしょうか？
自社開発の場合も価値を生んでくれるプロダクトに労働力を注ぐことが重要となりますが、資産の所在が違うことに注目してください。
自分たちの事業の自分たちのシステムを作ることが前提となります。
これで前提条件が抑えられました。もう少し考察していきましょう。
■ 提供価値の違い
- 受託開発の価値はフローの最大化
次は提供価値の差異を見ていきましょう。
先程ビジネスモデルを紹介したので、もちろんそれに伴い私達が提供する価値も変わってきます。
併せて各々パワーを入れなければいけないスキルやスタンスが浮かび上がってきます。
顧客のシステムを構築する受託の会社は、ケースに合わせた労働力を提供することが重要です。
締結した契約期間内で、顧客を理解し、顧客だけでは構築できない戦略のコンサルティングや開発デリバリー、マネジメントなどの提供フローの価値を最大化することが至上命題となります。
モノではなくコトの提供です。
コンサルタントでいうお客さんに向いて働き value を出すのと同じですね。
- 自社開発の価値はストックの最大化
反対に自社開発では、フローの最大化ではなく、いかに自分たちのプロダクトを資産=ストックとして作り上げることが重要です。
プロダクトがマーケットにとって素晴らしいものであればあるほど、それ自体が生産してくれる付加価値が最大化されます。
自分たちが動かなくても、プロダクトが最大限価値を提供してくれる、最高の資産にすることが至上命題になります。
こちらはコトではなくモノの提供です。
弊社ではこれをプロダクトを「磨く」といいます。
■ 決定権の違い
- 受託はソリューションのプロ、コンサルタントチック
次に決定権の違いを見ていきましょう。
受託はお客さんが儲かることが正で、要件がどうなれば正しいか、儲かるのかは顧客が決めます。受託会社はそれをいかにして実現するのかが大事です。
自分たちがビジネスに対して持った違和感は、というのは提案やアドバイスができても決断ができません。
また事業自体の意味などを説明を受けたりすることはありますが、なんとなく自分ごとにさせることは難しいです。
私が前職でいたNRIは、長くお付き合いするタイプのSIerなので、何年か同じお客さんとプロジェクトをすすめることが多くなります。
ただ、お客さんの事業や業界に対して理解は深まるのですが、次このビジネス企画をしよう、とはなかなかなりません。
本番リリース後もなんとなくお客さんから効果や問題がないかどうかを見聞きすることのほうが多く、ビジネスを自分ごとのように体感することが難しいです。
あくまでビジネス企画は顧客スタート、決定も顧客側に裁量があります。
このようなことから、受託とはコンサル的な立場に近いことがわかってきたと思います。
ただ、そのおかげで伸びるスキルもあります。
会社間をまたぐからこそ、合意形成などのプロジェクトマネジメント力、分析や説明が必須なコンサルティング力は伸びます。ソリューションのプロと言えると思います。
反して自分たち発進の事業企画力はスキルとして経験が積みにくくもなります。
- 自社開発は、エンジニアもビジネス企画に裁量を持つ事業会社である
自社開発を経験してきましたが、SIer時代よりもプロダクトに対して自分たちで決定している = 責任を持っているように感じます。
自社開発は自分たちの事業を伸ばすことが至上命題のため、ビジネス企画/プロダクトのプランニングについても自分たちで裁量、責任を持ちますし、逆にそれをしっかりグリップしないとビジネス/プロダクトとしてぐらつくことになります。
技術選定も事業(内部的なスキルセットも含め)として最適なものを自分たちで選びます。
業務要件の深いところはビジネスサイドのプランニングをしているメンバーに確認することがありますが、エンジニアもビジネス企画がどのようにインパクトがあるのかもしっかり理解しなければならないと感じます。
機能リリース後も自分たちの事業のため、それがどうマーケットに響いたのかも近く感じるようになりました。
2. ぼくは自社開発に向いていない
■ 2年間のキャリアを自己否定する
- 受託に向いているのはフローを最大化することが好きな人
これらを踏まえ、約２年間エンジニアをしてきた経験を照らし合わせて考察していくと、私はある結論に行き着きました。
「メインキャリアとして、私は自社開発エンジニアは向いてない。」
あれほどなりたかったエンジニアに転職することができ、自社開発エンジニアとして全力で駆け抜けてきた2年間でしたが、思わぬ結論に至りました。
実際ちょっと落ち込みました。悩みました。
ただ、私のモチベーションをダイアログしてみると、プロダクトではなく、汎用的な理論やスキームを確立することにモチベートがあることに気づきます。
ビジネスサイドがやりたいことを100％、それ以上に実現することに喜びを感じます。
思い返してみると新卒で入った SIer、つまり受託スタイルは性格的に私には合っていたのでしょう。
私のキャリア像として、はじめのほうに提示した下記の図のように、本来は幅広いデジタルソリューションを提供できる人材が理想なのです。
過去を振り返ってみると、面接の時の発言を思い出しました。エンジニアになりたかったのは、エンジニア一筋でコードのみ書くのではなく、どんな顧客でも最適なソリューションを提供し、「フローの価値を最大化する」ことだったことなのです。
■ 自社開発とは：業界を想い、プロダクトを愛するということ
ちなみに自社開発に向いている人はどういう人物像なのかも考察してみました。
プレイドと他のいくつかの現場の自社開発のエンジニアを見ているのですが、向いている性格としては、
「プロダクトや業界に「愛」があること」
だと思います。
こういう技術だけを使いたいよりは、こういうプロダクトを作りたい、だったり、この事業/業界をこうしたい、などの想いを感じることが多いのです。
この思いがあれば優先順位がプロダクトや事業になりますので、障害対応や細かい改修であっても嫌な顔ひとつせずに対応できているように見えます。
土日もプロダクトのことを考えますし、試し開発をしてみたりします。
インタビューしたわけでもなく、アンケートを取ったわけでもないのですが、現場に2年間経験している中で、自社開発で活躍しているエンジニアは、言葉の節々にもそのような意思を感じるのです。
自社開発に向いている人はプロダクトやものを磨くことがとても好きだったり、業界や業務を好きになれる愛を持てることなのではないでしょうか。
プロダクトに対して親心・愛をもつということが子育てのように「磨く」という行為に反映されるのだと思います。
3. 汎用ソリューション＆プロダクト機能のマッチ力で勝負する
■ 私はソリューションの価値を最大化したい
このように私はプロダクトに対して「磨く」ということにあまりモチベートができないことがわかりました。
そうすると2つ疑問が湧いてきました。
- 前回のエントリのように、障害対応できるのだから自社開発向いてるんじゃないの？
- 向いてないならエンジニア辞めたらいいんじゃないの？
この質問に答えていきましょう。
- 汎用スキーム化/仕組み化が好き
1つ目の疑問についてです。
個々のプロダクトや機能を伸ばすイメージで開発することにモチベーションがわかないのですが、インシデントマネージャーはあくまで障害対応コンサルタント的に、自動化の仕組みや汎用的な基準を作っているのです。
このスキームはKARTEでなくても使えるので、汎用的なスキルなのです。
この行動自体は汎用的なのでそこにモチベートを感じていますし、向いていると思います。
- 多機能プロダクトを武器にソリューションを最大化する
次に2つ目の疑問についてですが、これについては図に表してみました。
自社開発は左のように複数顧客に対して一つのマーケットで、プロダクト特化 or 業界特化が普通です。
そのため、業界やプロダクトに深く入り込む愛が必要なのです。
マーケティングツールだと思っていたのでと業界特化・固定ではモチベートがあがらないと思っていました。
入社当初は業界特化型だとおもっていましたが、実はKARTEは、幸いにも業界問わず、一つのプロダクトで幅広いデジタルコミュニケーションのソリューション提供できることに気づきます。
上記の図のように、プロダクト開発に携わっていく中で理解を深めるほど、もしかしてKARTEはフローにレバレッジをかけて価値を最大化することができる。とても大きな武器になるのではと気づいたのです。
ここで思いついたのがプロダクト・アウトの自社開発企業で、汎用ソリューション＆プロダクト機能のマッチ力で勝負する、というデジタル人材キャリアの可能性でした。
■ 企業システムの医者を目指す
- KARTEの汎用性、多機能性
この章に入る前に、まず狙うポジショニングを説明するために、武器となるKARTEの機能汎用性を図で説明します。（本当にざっくりなのでHPを見てもらったほうがいいかもしれません。）
幸いにもKARTEは他のプロダクトよりも機能の汎用性がとても高いと感じます。
そこを目指していることが日々活用していく中でわかってきました。
いいかえるならインターネットのミドルウェアで、プロダクト分類では Horizontal/SaaS に分類されます。(ここの考察は別のエントリで述べます。)
KARTEマーケティングツールスタートであるものの、今や機能としては顧客のサイトでやりたいことは何でもできるものではないかと思います。
機能として顧客へのメール,LINE,ポップアップ,アンケート,トラッキング,ユーザー解析,外部データ連携...などなど数え切れません。
私はこの「どの業界でも通用する汎用性」にとても惹かれていて、これを使えば様々なソリューションが展開できると思っています。
プロダクトを「磨く」ことには熱量を込められませんでしたが、このプロダクトを使って「幅広くソリューションする、機能をうまく顧客にマッチさせる」ということを極めていきたい、そんな思いで進めています。
- 直近のポジショニングコンセプト
プロダクトの汎用力が理解できたところでポジショニングコンセプトに入ります。
プロダクトを磨くことが苦手な私でしたが、フローを最大化することは得意ですので、直近では、自社開発ではこのようにポジショニングをしようと思っています。
汎用プロダクトといっても、100％顧客にvalue出せるとは限りません。
実現したいビジネスに対して使う機能が正しい選択か、使い方のフォロー、(プロダクトのコアコンセプトを損なわないような前提で)特定のお客さんようにオーダーメイドしたり、足りない機能を拡張したり、ユースケースに合わせた「プロダクトのラストワンマイルの開発」などが必要だと思っています。
前回の「障害対応という花形」で述べたように、ビジネスとエンジニアのハブのなり、仕組みづくりをすること、開発力が必要であれば自力で突破できるポジショニングです。
まずはそこのポジショニングで開発力及びプロダクトソリューション力を深めていきます。
- 将来は、企業システムの医者
前節でKARTEの多機能性/汎用性を表現したところで、これを武器にした全体像を表現したいと思います。
このように企業システムの医者のように様々な視点からソリューションを提供する人材を目指します。
イメージができたところで、下記の5つの能力をメインとして身に着け、企業システム課題へ対抗する汎用力を伸ばしていきたいと思っています。
いきなりすべて習得するのは難しいので、いくつかステップを踏む必要があります。
こちらも工程別に必要なスキルを図で表現してみました。
左から上流のスキルになります。右に行くほど工程が進んでいき、主に4つのメインスキルに分解されていることがわかります。
SIer時代にPM/SEキャリアで習得済のスキルが黒枠になっています。
業務フローに関するスキルとPM推進力、開発要件定義は身につけられています。
赤は現在エンジニアとして奮闘中のスキルとなり、自分で実装したりKARTEの開発をメインで行っています。
開発を後数年は続けながら、ビジネスサイドに出つつ、KARTEのプロダクト自体の利用に携わっていきます。
KARTE関連のスキルが溜まってきたら、今度はお客さんのサイトの状況を見つつwebサイトやシステムのコンサルティング力を身に着けたいと思っています。(もちろんそこでKARTEを武器にしながら)
最終的には複数システムをグランドデザインできるような人材を目指しています。
このような手順で「汎用ソリューション＆プロダクト機能のマッチ力で勝負し」、「自社開発でフローを最大化する人材」というポジショニングを極めていきたいと思います。
おそらく10年〜15年ほどかかるかと思いますが、全力で邁進していこうと思います。
以上が、自社開発エンジニアに向いていない私が最終的に目指すキャリアの方向性となります。
最後に
お読みいただきありがとうございました。
今回は自社開発エンジニアに向いていないという自己否定をはさみながら、そんな中でどのようなポジショニングを取っていくか、という考察を深めていきました。
ハブ型デジタル人材を目指す人が増えてほしい。
エンジニアキャリアにはエンジニアアスリートとしてではなく、既存キャリアと掛け合わせることで、デジタル人材は様々な方向や可能性を見いだせる職業だと思います。
世間では、「自社開発でエンジニアになること = 幸せ」、「エンジニア一筋で生きていくことがキラキラで花形」と言われていますが、そこは学生や新卒からプログラミングが好きで始めていて、仕事で訓練されたエンジニアさんが既に沢山います。かなりのレッドオーシャンです。
そこで社会人になってからエンジニアだけで圧倒的に成果を出せるのは一握りでしょう。感覚的には甲子園に出るとか、プロ野球選手になるとかそのレベルかなと思います。
ただ、ビジネスとエンジニアを数年ずつやると、この圧倒的価値がでるあなたしかできない「役割の狭間」を見つけることができるのです。
ここも別途エントリで考察していきたいと思います。
【コードが書けるビジネスはベスポジ】
— Kaz_Shio / SIerと自社開発 エンジニアのリアル：デジタル人材の探究 (@Victoria_Peak_) 2020年5月7日
コード書けるようになって、これマジで推せるポジションだと実感してきた。
- エンジニアアスリートはみんななりたい。レッドオーシャン
- ビジネスではアプリ作るレベル、コード読み書きできる人が超レア。
- 狭間のタスク落ちがちで、両者が一番混乱する
みなさんエンジニアだけで頑張ろうとするんですが、才能と訓練を積んだエンジニアさんが密集してるのでバリューでない。
— Kaz_Shio / SIerと自社開発 エンジニアのリアル：デジタル人材の探究 (@Victoria_Peak_) 2020年5月10日
もともとのスキルと掛け合わせるだけでバリューめっちゃ出るんですよね。
この例だとエンジニアで医療現場知ってる人皆無ですし。
エンジニアの後医療現場やろうと思わない。
代表的な一つのキャリアに固執せず、自分だけのキャリア像の解像度をこのブログをきっかけに見つけ出していただければと思います。
P.S. 日々の活動の記録、デジタル人材としてどのようにしていくべきか、転職やその他仕事についてつぶやいていますので、ご興味があれば下記またはフォローをよろしくお願いします。
