リモートワークの普及が後押しとなり、SaaSプロダクトの需要が一気に高まっている。しかしその一方で、自社でSaaSプロダクトを運営するスタートアップ側は、導入社数や契約アカウント数の増加に伴い、向き合うべき大きな課題に直面している。

例えば、ユーザーの利便性をより高めるための開発プロセスの最適化やエンジニア組織の体制構築、アーキテクチャの変更などが求められているのだ。中でも、将来的な拡張性を踏まえると特に鍵となるといえるのが、「開発の内製化」だ。

2019年2月よりLINEを活用したマーケティングツール「MicoCloud」を提供するMicoworks（ミコワークス）株式会社は、2022年から外部パートナーへの依存度を減らし、プロダクト開発の内製化に取り組み始めた。

具体的には、シリーズAの18億円（累計20億円）の資金調達を機にエンジニアの採用を加速し、内製化へと舵を切ったという。

同社でVPoE 兼 SRE Engineer Managerを務める竹田 昌男さんは、開発組織自体がなかったゼロベースから内製化の推進を担い、特に採用面での工夫によって1年で26名の開発組織を構築することに成功。

月1回のミートアップ実施などを通じてチームビルディングにも力を入れると同時に、外部パートナーとも協働しながら徐々にプロダクトの内製化比率を高めているそうだ。

今回は、同社が開発の内製化を進める上での課題をどのように乗り越え、内製化を推進してきたかについてお話を伺った。

スピード感を持ったプロダクト開発の必要性から内製化に踏み切る

私は新卒でSIerに入り、その後Linux技術が世の中で広まり始めたタイミングで、仲間3人と一緒に京都で起業しました。

自分の会社で12年ほど事業を行ったあとは、クラウド型の経費精算システム「楽楽精算」などのSaaSを提供するラクスへ入り、SREやプロダクト全体のインフラ責任者を担いました。

その後、2022年6月にMicoworksにジョインし、現在は「MicoCloud」といった自社プロダクトの企画・開発・運用と、開発チームの組織づくりを担っています。

▼同社が提供するLINE特化型マーケティングシステム「MicoCloud」

弊社は1年ほど前まで社内のエンジニア組織がなく、若手の技術メンバー3名が外部パートナーさんとやり取りする形で、プロダクト開発をアウトソースしていました。

そうした外注依存の体制から内製化へと踏み切った背景は、経営陣が「さらなる事業成長を見据えたときに、よりスピード感をもってお客様の声をプロダクトに反映できる開発体制が必要だ」と決断したからです。

そして、2022年2月にシリーズAで12億円、同年9月に追加で6億円の資金調達を実施したことで、開発をスピーディーに行っていく新体制の構築へと舵を切りました。

ゼロから開発組織を作る難しさ。「自分たちが何を目指すか」から整理

私はMicoworksへの入社前から業務委託で採用活動に参加していて、2022年6月にSRE Engineer Managerとして正式に入社したのですが、その時点では6名のエンジニアが在籍していました。

そこから、いざエンジニア組織づくりに着手しようとした際、一番の課題は「何も決まっていない」ことでした。

最低限の開発方針やテックポリシーは存在していたものの、新しいメンバーが続々と入り、組織体制が日々変化していたため、誰がどのタスクを担当しているかが見えにくい状況だったんです。そのため、まずは現場の仕事を一つひとつ細かく見ていく必要がありました。

そこで、まずは私の専門領域であるインフラ面から見ていき、「誰も気づいていない、放置したらリスクになる」ことを拾い上げ、自分で管理することから始めました。

例えばドメイン管理は、放っておけば期限切れでシステム停止を起こして復旧作業に追われることになるので、そういったものをピックアップして、ひとつずつルールを整備しながら解決していった形です。

また、外部パートナーさんと連携する際も、当然ながら自分たちがプロダクト開発の状況を正しく理解した上で依頼しないといけません。なので、「まずは自分たちが何をすべきか、何をしたいのかを言語化していく必要がある」と思ったのが、私がジョインしたときの第一印象でしたね。

そして、社内外の開発チームの関係性づくりも最初は苦労しました。

外部パートナーさんも社内のメンバーも、集まった人たちは初めて会った状態だったので、お互いのことを理解するのに手探りでコミュニケーションしていく必要がありました。まずは「誰が何をできるのか」を把握し、役割を分担することから着手しましたね。

ただその一方、フルリモート環境下ということと、各人の業務タスクがあふれ返っていることもあり、常に社内外のメンバー同士でコミュニケーションができる状況ではありませんでした。

つまり、私が率先してコミュニケーションの機会を作らなくてはならず、このような環境でどう関係性を作っていくかが難しく感じましたね。

私自身も、リモートで組織を立ち上げるような役割を担った経験がなく、これは時間をかけて取り組んでいく必要があるなと感じたので、現在も社内外のチームの関係性づくりは継続して取り組んでいます。

採用候補者と「リアルで会って話すこと」で内定承諾率の向上に

Micoworksは全社的に「人」への投資をすごく重視していますし、内製化を進めるためには人材の採用が必要不可欠になってくるわけで、ここ1年間は何よりも採用にプライオリティを置いて動いてきました。

とりわけスタートアップだと、「アトラクト要素」や「付加価値」が何になるのかを押さえておかなければなりません。

ただ、採用活動を始めて1〜2ヶ月は正直アトラクトにつながるポイントが掴めませんでした。そのため、カジュアル面談を組んでも次の選考に進む候補者が少なく、苦戦を強いられていました。

その頃は会社資料などを投影しながら説明していましたが、ある時ふと「毎回同じような話をしてもつまらないな」と思いまして。

じゃあ、思い切って変えてみようということで、普段通りの自分で「何も装っていない接し方」で候補者と話すやり方に変えたところ、うまく回り始めました。

カジュアル面談から次の選考に進んでくれる候補者が増え、ようやく採用活動が軌道に乗り始めたんです。

その次に出てきた課題は、「内定承諾がもらえない」ということでした。

最終面接後に内定を出すものの、候補者から「Yes」をいただけない状況が続き、どうすれば打破できるのかを考えた末に、「候補者と実際にお会いし、腹を割って話すこと」を徹底するようにしました。

それこそ日本中どこにでも飛んでいって、食事や時にはお酒を酌み交わしながら、「一緒に働くと楽しそう」と思ってもらえるまで会話をしていく。こうした人と人としてのコミュニケーションをしっかりと重ねたことが、内定承諾率の向上につながりました。

その結果、内定を出した方の70〜80％ほどが入社してくれるようになり、約1年で26名のエンジニア組織へと拡大させることができました。

ここまでは一気にメンバーが増えたわけではなく、毎月コンスタントに採用し、その積み上げの結果として今のチーム体制につながったという感じですね。

「プロダクトを作る組織」から「人を育成できる組織」へ

エンジニア採用の体制としては、カジュアル面談、1次・2次面接までは現場のエンジニアにも入ってもらっています。

現場の人たちには「一緒に働きたい人は、自分たちで選んでいい」というスタンスで進めてもらっているので、入社後に一緒にチームで働くイメージを持ってもらいやすい良さがあります。そういったカルチャーフィットのすり合わせができているのは、現在の体制の良い部分ですね。

また、採用における給与面に関しても、成果に応じた正当な報酬をオファーするという方針で、良い条件を提示しています。しかし、スタートアップならではのハードシングスを乗り切る気合いやマインドがあるかどうかは採用面接時に確認していますね。

そういう意味では、給与軸と人軸の両面を大事にしながら、エンジニア採用に取り組んでいます。

その上でチームビルディングにおいては、「人」が集まらないとそもそも採用も回らないので、今後は採用活動にも興味があり、「自分のチームは自分で作っていく」ような気持ちを持っている人にもオファーしていきたいと考えています。

ここ1年、本当にゼロからの立ち上げだったので、カルチャーマッチする即戦力の人材を優先して採用してきましたが、さらに組織を拡大していくためには、育成が必要な若手人材も採用することが肝になると捉えています。

もちろん、育成コストもそのぶん上がるわけですが、ポテンシャル人材を育成できる組織にならなければ、事業も絶対に伸びないし、会社も成長しない。人を育成できる組織を目指すのが、今のフェーズですね。

ある程度の規模の組織になり、横並びだったところから階層構造に徐々に変えていき、スムーズに組織運営ができる体制づくりを、目下進めているような状況です。

幸いにも、リモート環境下での社内のチームビルディングについては、カルチャーマッチした人材を採用できていることもあって、お互いオープンに会話できるような雰囲気が醸成されていると思っています。

また、チーム同士でコミュニケーションを円滑化させる取り組みとして、月1回のペースで「月次プロダクトMeet Up」というリアルでのミートアップを行っています。

弊社は東京と大阪の2拠点にオフィスを構えていますが、そこにチーム全員が集まってきて、仕事の進め方や考え方などをすり合わせるようなワークショップを実施している形です。

将来のさらなる内製化に向けて、運用面の基本方針の策定に取り組む

組織全体を俯瞰してみると、内製化の切り替えの中で苦しんでいることもあります。それは、今まで外注依存の開発体制だったために、全社的に技術面への理解が薄かったことです。

全社でプロダクト開発における共通言語化がなされていなければ、開発チームとCS・営業チームがうまく連携することはできません。

特にSaaSのプロダクトは、いわばお客様のペインを解決するものであり、ユーザーからの要望をもらった時に共通言語を作れていないと、本当の解決策や必要とされる機能が作れないと思っています。

なので、まだまだ開発サイドとビジネスサイドの膝を突き合わせたコミュニケーションが足りてないと感じていて。今後は他の組織に対してしっかりと開発チームの存在価値を出し、「ペインを解決していけるチーム」としての立ち位置を確立していきたいと考えています。

現状だと、ビジネスサイドが求める機能開発ができていないので、そこを「こういうことが解決できるから、もっと相談してください」という風に社内のプレゼンスを高めることができれば、自ずと「お客様がどんな課題を持っているか」などの情報も集まってくるはず。

そのためにも、CSや営業との連携をさらに強化し、よりお客様の方を向いて会話できるような組織体制を作っていければと思っています。

そして現在はさらなる事業成長に向けて、開発の内製化と同時並行でマルチプロダクトで事業も進めていく方針に転換しています。全てのプロダクトに関わるメンバーは、社内と外部合わせて90名を超える人数にまで増えているフェーズです。

▼同社のプロダクト企画・開発体制​​（2023年3月時点）

社内の開発リソースが十分にあるわけではないので、現在も完全に内製化しているわけではなく、外部パートナーさんと協働して新たなプロダクトを作りながら、いずれ内製化できる準備を並行して行っているという形ですね。

また、社員でも業務委託でも、エンジニアのコストが高騰している背景もあり、CFOとコスト面の認識合わせをしながら、将来の内製化に向けて粛々とエンジニア採用も進めています。

加えて、プロダクトによって機能面やUI/UXは異なりますが、共通のポリシーやルールを策定しておくと運用面が安定するので、まずは全プロダクトでデファクトスタンダードとなる基本方針を定めることに取り組んでいます。

「外部の業務委託の方に協力いただいてプロダクトを一気に作り、アジャイルで開発していきながら運用に回ったフェーズで、社内で巻き取っていく」

このような青写真を描きながら、「開発」も「育成」もできる内製化組織を作っていきたいです。（了）