外注頼みのシステム開発を内製化したい、一人目のエンジニアを採用したい、事業成長のためにもっとテクノロジーを活用したい…。

近年、大手企業が続々とDX推進へと舵を切る中で、その波に乗り切れず、自社の状況にモヤモヤを抱いている方も未だ多くいるのではないだろうか。

2016年の創業から6年で、のべ1万2千人以上が受講した英語コーチングサービスを展開する株式会社プログリット。同社は、創業時より英語学習をアプリで完結させる世界観を描いていたものの、社内にエンジニアはおろか、テクノロジーの知見を持ったメンバーが誰もいない状態だった。

そこで、制作会社への外注という形でアプリ開発に踏み切ったものの、度重なるトラブルにより三度、白紙状態に。こうした背景から、開発の内製化を決意し、エンジニアの採用をスタートした。

「ブランドでは勝てないからこそ、狩りにいく」スタイルで採用活動を行った結果、2020年にプロダクト開発を担う正社員エンジニアとしては一人目となる、島本 大輔さんが入社。

現在はエンジニア・マネージャーを務める島本さんを中心に、正社員3名、業務委託3名のハイブリッドなエンジニア組織を編成。学習進捗をサポートする「PROGRIT-学習アプリ」等を自社開発で展開することで、受講者への新たな価値提供を実現しているという。

今回は島本さんと、同社の取締役副社長である山碕 峻太郎さんに、プログリットにおける開発内製化の歩みを振り返ってお話いただいた。

開発の内製化で「紙・写真・スプレッドシート」が「アプリひとつ」に

山碕　私は2016年にプログリットを共同創業し、現在は副社長を務めています。

ミッションとしては「世界で自由に活躍できる人を増やす」を掲げていて、今は人のポテンシャル発揮という意味合いで大きな壁になっている「言語」の領域に体当たりしています。具体的には、「プログリット」「シャドテン」という二つの英語コーチングサービスを展開しています。

島本　私は2020年7月にプログリットに入社しました。現在はエンジニア・マネジャーとして、開発チーム全体がうまく回るようにサポートする役割をしています。みんながハッピーに動ければ自分がハッピー、という感じですね。

プログリットの開発チームは、現在6名のエンジニアで構成されています。サーバーサイドとフロントエンド兼ねたメンバーが2名、iOSが2名、そしてAndroidが1名。私を含めて3名が正社員で、残り3名が業務委託です。

私が入社する前にも、業務委託のエンジニアや社内SE業務を担当する社員はいたのですが、プロダクトを作る正社員のエンジニアとしては私が一人目になります。

▼【左】山碕さん【右】島本さん

山碕　もともとプログリット創業初期は、エンジニアもいませんでしたし、テクノロジーの活用は全くできていませんでした。

紙に記録された学習データをお客様から写真で送ってもらったり、スプレッドシートで管理したり…かなりアナログな状態でした。

シマさん（※島本さん）が入社してくれてから、開発の内製化を進めていきました。現在は、プログリットのビジネス英会話における基本的な学習は、アプリひとつで完結できるようになっています。

▼同社が提供する「PROGRIT-学習アプリ」のイメージ

アプリ開発は三度「白紙」になった。苦い経験を経て内製化を決意

山碕　創業初期は、お客様には紙の教材をお渡ししていました。ですが、利便性を考えても、やはりアプリで完結する方がいいなと思っていて。そこで一期目が終わるタイミングで、学習も管理もすべてアプリに移行することを意思決定し、外部の開発会社さんに発注させていただいたんです。

ですが、実はその後1週間ほど経ったときに、その会社さんがいわゆる夜逃げをしてしまって。既に料金もお支払いしていましたし、突然そんなことになって当時はすごくビックリしましたね。

その後、その開発会社さんのお知り合いの方が開発を引き継いでくださり、なんとかリリースしたものの、これも1週間も経たないうちに閉じることになってしまって。実際にお客様に使っていただいたところ、データが消えてしまったり、送信した録音データが届かなかったり、致命的な事象が多発してしまったんです。

今改めて振り返ると、完全に自分たちのせいで起こった失敗でした。アプリの表側の「こういう画面を作りたい」といったスケッチだけを手書きで書いて、あとは完全に開発をお任せしてしまっていたんですね。

細かい機能やUIUX面の議論は全くしておらず、外側のことだけを考えていた。つまり、自分たちにディレクション力が全くなかったんです。そもそも「要件定義が何か」といったことも知らないレベルでした。

その後、反省して社内でふりかえりをしていく中で、初めて開発をリードする「プロダクトマネージャー」という役割が必要なんだ、ということを理解しました。

そしてプロダクトマネージャーの採用を始めたのですが、すぐにはうまくいかなかったので、平行して別の制作会社さんにアプリ開発をお願いして進めていきました。

ちょうどそのアプリをリリースしようとしていたタイミングで、プロダクトマネージャーも採用することができたのですが…。引き継ぎを行う中で、彼から「一旦、ローンチを先延ばしにしてゼロから考えたい」という提案があったんです。

表面的にはなんとなく良さそうなアプリにはなっていたものの、バックエンド側が非常にまずいことになっていたんですね。

それでまた一回、開発を止めて、ほぼゼロに戻して…。こうした経験を重ねる中で、やはり自社の中にしっかりとエンジニア組織を作って、主体的に開発を進めていきたいという思いが一層増していきました。

エンジニア採用ブランドでは勝てない。ラブレターで「狩りに行く」

山碕　こうした背景もあり、エンジニア採用を進めていったのですが、僕たちの場合は「まず自分たちのことを知ってもらう、転職先の候補に入れてもらう」ことが最も大きな壁でした。

プログリットはいわゆる「労働集約的な」サービスと認知されていますし、経営陣にテクノロジーに強いメンバーがいるわけでもない。その上で、エンジニアの方にどうやってうちを選んでいただくか？ ということが大きな課題だったんです。

「これはもう、ただ待っていても絶対に誰も来ないだろう」ということで、「狩りにいく」ことに決めました。具体的にはエンジニア採用サービスの「LAPRAS SCOUT」を活用して、スカウトを打っていきました。

ブランドとしては他社に絶対負けているので、その分、スカウトを頑張る。数を打つというより、「この人」という人に本当にラブレターを書くようにメッセージを送っていくという方針でしたね。

島本　この数年、エンジニアはかなりの売り手市場なので、スカウトメールが日々飛び交っているような状態です。

実際に私も多くのスカウトをいただきましたが、その中でもプログリットのメールは、「一番ちゃんと人を見ているな」と感じられるものでした。レジュメだけではなくGitHubやTwitter、Stack Overflow等にある情報も全てきちんと見てくださっていたんですよね。

山碕　スカウトメールについては、実際にGitHubだけではなく、公開されている全てのSNSを確認した上で、その人の志向性やパーソナリティをイメージしながら送ることを意識していました。

また、スカウトを送る前に、プロダクトマネージャー含む採用チーム全員でレジュメを拝見し、その方の魅力ポイントをメモに記載するようにしていました。そうすると、メールを送る際に、様々な角度からその人にアプローチできる情報が揃っている状態になるんですね。

島本 　最終的にプログリット入社の決め手になったのは、まず「ほぼゼロの状態から物事に携われる」こと、そしてこのフェーズだからこそ「技術選定を柔軟に行えること」でした。

実は、私自身が「最初のエンジニア」として入社する会社はプログリットが3社目なんです。もともと、何もないところから作っていくことが自分の性格とも合っているんですね。加えて、働く環境という意味でもプログリットの雰囲気が自分に合っていると思い、入社を決めました。

足元から開発組織を立ち上げ。抽象的なアイデアも形になるように

島本　入社後は、エンジニアの開発効率を上げてスケールしやすい組織を作っていくために、大きく三つのことに取り組みました。

まずは、ドキュメントをちゃんとまとめていくこと。次に、GitHub、Slack、ドキュメント管理ツールといったコミュニケーションフローの確立、そして最後に、開発フローの整備です。

総じて、足元の通路をきれいに整備することで、みんなの開発効率が上がるような取り組みを集中的に行いました。

プログリットの場合は、私が入社する前から業務委託メンバーで開発を行っていたので、「仕様が合わない」「そもそも手元にコードがない」といった問題は少なかったんですね。どちらかと言うと、「人」や「考え方」の方に難しさがあったと思います。

▼プログリットで働く皆さま

島本　組織の立ち上げフェーズでは、何をやるのかも明確には決まっていませんから、まずはとりあえず同じ方向を向く、ということに意識的に取り組むようにしていて。

例えば、まず業務委託の方も含めて全員と話をする場を作りたいと思い、1on1を定期的に実施するようにしました。

この目的は二つで、まずは純粋に困ってることを聞いて改善できるように動くことで、みんなの信頼を勝ち取っていくこと。もうひとつは、いわゆる「ガス抜き」です。

特に業務委託の方の場合、契約によってある意味きれいな「主従関係」ができてしまうので、自発的にこちら側に踏み込んできていただくことはなかなか難しいと思います。

ですが、プログリットはまだまだ初期フェーズだったこともあり、協力し合う必要性を感じていたため、まずは意識を溶かし、互いに信頼関係が築けるようにコミュニケーションしていきました。

実際に私が入社して4、5ヵ月後に、以前からお願いしていた業務委託の方に「島本さんはわかってくれているので助かります」というひと言をいただいたときには、すごく嬉しかったですね。

こうした活動と平行しながら採用活動も進め、社内に開発チームを立ち上げていきました。

山碕　開発が内製化されたことで、以前とは全てが変わりましたね…。

私目線で言うと、もともと「こういうことをやりたい」という抽象的な世界観やアイデアを色々と持っていたのですが、それがしっかりと形になっていくんです。これはすごいなと思いました。

やはり同じ組織の中で、同じ目標を見ながらコミュニケーションをとって開発を進めていくことで、齟齬が起こらないんですね。また、エンジニアメンバーが社内の営業管理等のシステムについても熟知していることで、そういった部分の抜け漏れも起こりません。

実際、内製化をしてからはアプリのバグも大幅に減りましたし、お客様から致命的なフィードバックを頂戴することもなくなりました。

島本　社内のコミュニケーションは重要ですね。エンジニアに限らずですが、専門家って「周囲が自分と同じ知識を持たない」ということを忘れがちだと思っていて。

専門用語を使ってしまったり、「これってこうするもんだよね」という暗黙の前提を説明しなかったり。そうではなく、相手がそれを知らないという前提に立ってきちんと伝えなければ、良い判断はできないと思います。

特に私のような立場の人間は、口頭でのコミュニケーションに限らず、きちんと見える形で、非エンジニアの人にもわかるように情報をまとめることが求められます。ここは、自分自身にとってのチャレンジでもありますね。

「スキルだけではない誠実さ」「エンジニアを信じること」も重要

島本　これから開発組織を内製化したい方に向けてアドバイスさせていただくとすると、大きく二点あるかなと思っています。

まずは、エンジニアの採用においては、スキルを大前提にしつつ、人柄や誠実さをしっかり見ていくことが大事だと感じています。

スキルや技術は多少バラバラでもカバーできますが、人間性はそうはいかないので。特に組織の立ち上げフェーズでは、技術力に固執しすぎず、一緒に同じ方向を向いていけるかどうかを見るといいのかなと思います。

そしてもうひとつ、これは非エンジニアの方に向けてですが、エンジニアを信じてあげてください、ということを伝えたいです。

エンジニアの世界って、やっぱりちょっと特殊ですよね。ビジネス側とエンジニア側はどうしても別々に見がちですし、非エンジニアからすると、エンジニアってよくわからない存在だと思います。

ですので内製化をスタートした段階では、うまくコミュニケーションできないことも多いかもしれません。ですが、しっかりと同じ方向を向いてさえいれば、ちゃんとそれに見合った見返りがあります。最初は我慢することもあるかもしれませんが、エンジニアを信じてあげてほしいなと思います。

プログリットの開発組織としては、引き続き、プロダクトとユーザーにしっかり向き合って考える組織でありたいと思っています。また、今後は各個人の専門性を高めることも目指していきたいですね。

山碕　プログリットとしては、現状は社会人向けに英語学習のサービスを展開していますが、今後はより若年層をターゲットに広げていきたいと思っています。また、現状のサービスは短期集中型ですが、より長期的に取り組んでいけるスキームも提供していきたいですね。

さらに、より大きなところで言うと、事業領域として英語以外のスキルセットにもチャレンジしたいと思っています。人のポテンシャルを最大限に発揮するために、これまで以上にデータやテクノロジーを活用していきたいですね。（了）