本連載では、第一線でご活躍されているエンジニア組織のリーダーをお招きして、対談形式でこれまでのキャリア、組織のリーダーとして大切にしていること、組織課題などを語っていただきます。ナビゲーターは元DMM.comのCTOで、現在は株式会社デジタルハーツでCTOを務める城倉和孝氏です。

第6回目は、ユニークな少額短期保険と保険会社向けSaaSを提供している、株式会社justInCaseTechnologiesでCTOを務める大畑貴裕氏にお話を伺いました。

同社は、InsurTech（インシュアテック）業界をリードする企業として、スマホの加速度センサーと連動して保険料を割引する「スマホ保険」や加入者で保険料をわりかんする「わりかん がん保険」などユニークな保険をリリースしてきました。さらには、同社のシステムやノウハウを他社に提供するSaaS型保険システム「joinsure」も好調で、レガシーで保守的だと思われている保険業界に新しい風を吹き込む存在として注目されています。

株式会社justInCaseTechnologies CTO 大畑貴裕氏
2011年、ワークスアプリケーションズに新卒入社。技術研究部門でAWSの技術調査や運用サービス立ち上げに従事。その後、ヘルスケアスタートアップ2社のプレイングマネージャとして、Webサービス開発・運用やエンジニア採用を推進。2019年、justInCaseに入社し、プロジェクトマネージャや新規事業の開発・運用を担当。現在はCTOとして組織・プロダクトの成長に尽力する日々。

ヘルスケアスタートアップで感じた、社会インフラをつくる魅力

城倉さん（以下、「城倉」）：まずは、大畑さんのキャリアについてお伺いできればと思います。最初からエンジニアを志望されていたわけではないんですよね？

大畑さん（以下、「大畑」）：はい。実はエンジニアという職業に興味を持ったのは、大学3年生のときにITベンチャーでインターンを経験したからでした。

大学は文系でしたが、インターンでプログラミングをやって「おもしろいな。自分に向いているな」と感じたんです。4年生のときには、友人とWebサイトを作成して、その気持ちがさらに強くなりました。

城倉：なるほど。やってみておもしろいというのは一番いいきっかけですよね。

大畑：インターンをした企業に新卒でエンジニアとして入社し、クラウド運用サービス事業では、立ち上げメンバーとしてシステムの開発・運用から、お客様への提案・導入まで、ひととおり経験しました。

ただ、ベンチャーといっても規模は大きかったので、もっと小さい組織でWebサービスを作りたいと考え転職しました。その後はヘルスケアスタートアップ2社で、プレイイングマネジャーとしてエンジニアチームの立ち上げから、開発・運用までフルスタックにやってきました。

城倉：新卒で入った企業とはまったく異なる領域である、ヘルスケア系に移られた理由はなんですか？

大畑：1社目のきっかけは、友人からITで薬局業界を変えたいという薬局経営者を紹介してもらったことです。2社目は、医療つながりで医療サービスのスタートアップに転職しました。

エンタメやメディアよりは、社会インフラに近い業界をITでよりよくしていくことに興味がありました。justInCaseTechnologies（以下、当社）を選んだのも同じです。

城倉：事業領域が近いと、一度経験したことが次に応用できる面があるんでしょうか？

大畑：ドメイン知識はほとんど使えないですが、セキュリティの観点は近いですね。たとえば、業法的に避けるべき表現があったり、個人情報やセンシティブ情報の扱いが厳しかったり。

城倉：なるほど。次に大畑さんが今の会社に入ってからのことを詳しく伺えればと思うのですが、事業内容も含めて教えていただけますか。

大畑：当社には3年ほど前に入社しました。最初はプロジェクトマネジャーや新規事業の立ち上げに携わりました。2020年夏に開発部長としてチーム全体を見るようになり、現在はCTOとしてプロダクトや組織をスケールさせていくために、何でもやっていく感じです。

事業は、大きく2つあります。まず、「コロナ助け合い保険」や「わりかん保険」、「歩くとおトク保険」といった少額短期保険の提供。もうひとつは、自社の保険のシステムやノウハウを生かして、保険会社向けのSaaS型保険システム「joinsure」を提供しています。

城倉：名称を伺っただけでもユニークでおもしろいですね。

自社の保険システムをSaaS化するために、エンジニア採用が急務に

城倉：つづいて、エンジニア組織についてお聞きしたいと思います。大畑さんがジョインされた当初はどのような状況でしたか？

大畑：入社当時の事業は、ユーザー向けの「スマホ保険」の事業のみで、エンジニアは5人ほどでした。モバイルアプリエンジニアと、バックエンドとインフラを見れるフルスタックエンジニア、業務委託でSREやデザイナーも何人かいました。

城倉：その後、toB事業にも取り組むことになったんですよね。

大畑：はい。事業会社様の販促サイトに当社の保険加入を組み込む保険API事業や、当社のデジタルマーケティングやUXの知見を活かして他の保険会社様の保険募集や保険金請求を支援する事業をはじめました。

これまでテックカンパニーとして当たり前に実現していた自社のシステムやノウハウですが、いろいろな会社と議論したり、いくつか事例を出したりすることで、世の中に求められているんだと実感してきましたね。コロナ禍でのDX推進やエンベデッドファイナンスの盛り上がりもありますし。

城倉：なるほど。でも実際作るとなると人が足りなかったんではないですか？　新しい事業がまるまるひとつ増えたということですよね。

大畑：そうなんです。現状のメンバー数では、開発スピードが間に合わないので、昨年から採用活動を強化しました。毎日レジュメを見て、いろんな方と会って……を繰り返しましたね。

城倉：前職までに採用を担当されたご経験はあったんですか？

大畑：多少ありましたが、本格的には現職からですね。最初は試行錯誤でしたが、どういったところに興味を持ってもらえるかなども分かってきました。

城倉：採用強化のおかげでチームを大きくすることができたんですね。ただ、まだ充足したわけではないんですよね？

大畑：はい、「joinsure」の開発を加速させるために、機能横断的なスクラムチームを増やしていきたいです。しかし、チームメンバーのスキルに偏りがあるのでチームの分割が難しい状況です。そのため、今まで以上に採用を強化していきたいです。

城倉：成長に採用が追いつかないというのはやはりよくお聞きする悩みですね。ちなみに今は何人ぐらいまでスケールできたんですか？

大畑：今は業務委託の方を入れて、エンジニアは30人ぐらいです。この1年で2倍になっています。

城倉：レッドオーシャンなエンジニア採用において、成果を出されているほうだと思いますよ。採用で何かコツがあれば教えてほしいです。

大畑：そうですね…… コツはむしろお伺いしたいくらいなんですけど（笑）。

ひとつ思い当たるとすれば、当社はサーバサイドをKotlinで書いているんですが、従来の金融・保険のシステムはJavaを使っている場合が多いんですね。それで現職であまりやりたいことができていないという方は、スタートアップでモダンな環境で開発ができる、しかも自分がやってきた業界の知識を生かせるというのが魅力かと思います。

実際、paizaさん経由でも、SIerでJavaを書いていたエンジニアの方にご入社いただきました。

編集部：ありがとうございます！

保険システムをモダンな技術で提供するという挑戦

城倉：技術の話が出たので、もう少し詳しくお聞きできればと思います。

大畑：サーバサイドはKotlinで、フロントサイドはReactとTypeScriptを採用しています。インフラはAWSを利用しており、Dockerコンテナをサーバレスで運用しています。

城倉：モダンな技術を採用されていますね。しかもチャレンジングでありつつ、課題解決のための技術選定で、エンジニアとしてもやりがいがありそうだと感じました。

大畑：そうですね。保険を扱うので、セキュリティを守るというのは大前提として、チームメンバーが生産性をあげるためのモダンな技術を積極的に取り入れるようにしています。

城倉：これまでの金融業界のやり方と違うことで苦労される点もあるんじゃないでしょうか？

大畑：そうですね、特にお客様からセキュリティチェックを受けるときは、いくつか疑問や指摘をいただくことがあります。

たとえば、「サーバにウイルス対策ソフトを入れているか」という項目があるのですが、コンテナのサーバレスなので当社での対応ではなく、AWS社の対応やコンテナイメージスキャンの説明が必要です。また、「サーバ内の操作」に関する項目は、そもそも当社ではサーバ内の操作はしないようにしている、なぜならば、デプロイやインフラ構築を自動化しており、システムネットワークと業務ネットワークを分断しているから、などのていねいな説明が必要です。

これらは一例に過ぎませんが、お客様がセキュリティに対して不安に思う点は、対応の目的と手段の認識をすり合わせながら解消しています。

城倉：今お聞きしたような技術選定や設計は大畑さんが考えられたんですか？

大畑：いえ、現場のチームから提案してもらっています。どんな課題があって、そのために必要な技術は何か、どんなアーキテクチャが適しているか、といったことを一番分かっているのは現場ですし、マネジメントの立場になるとどうしても最新の技術を追うのは難しくなるので。優秀なメンバーが集まっているので、頼りになります。

メンバー発信でスクラムを導入し、ビジネスサイドとの溝を解消

城倉：はたから見ていると、変化もしつつ、うまく機能しているように感じますが、チームの課題はなにかあったのですか？

大畑：今はある程度改善できていますが、以前は事業と開発のコミュニケーション不足が課題でした。

わたしがプロジェクトマネジャーをしていたときは、わたしが事業と開発、お客様の間に入って、要件や段取りの確認を取りまとめていました。全体を見るようになり、また複数のプロジェクトが走るようになると、各案件でプロジェクトマネジャーが不在となり、うまく前に進まないことが多くなってきたんですね。一人ひとりが忙しいということもあり、開発メンバーと事業メンバーのコミュニケーション、要件や段取りの確認が不足しがちで、優秀なメンバーのスキルや行動指針だけでは解決できなさそうで、とても悩みました。ちなみに、このときは、バックエンドやフロントエンドといった職能チームがベースになっている、スクラムはイベントに時間が取られるので導入しづらい、などの理由で我流アジャイルだったんですよ。

しかし、開発の進め方として、機能横断的なプロダクトチームに体制を変えて、「スクラム」の導入を進めました。きちんとスクラムのイベントに則ることで、事業と開発がお互いの確認、フィードバックの機会を適切に持てるようになり、状況確認や意思決定がスムーズになってきましたね。

城倉：事業側のメンバーとエンジニアの距離が縮まって、お互い事情が理解できるようになったということですかね？

大畑：そうですね。定期的に目に見える成果物を一緒に見ながらフィードバックしあったり、毎日状況や困っていることを話したりして、何ができた・できていない、何がわかる・わからない、といったチームやメンバーの状況や、次の1週間でやることの認識合わせがしやすくなりました。「これを見ておいてね」「わからなかったら聞いてね」だと、みんな忙しくてコミュニケーション不足になりがちですが、そういった課題が減りました。

また、どの機能がより魅力的で優先度が高いか、どういった見せ方をしていくか、など、事業側と密に連携してお客様への提案もできるようになりました。

城倉：すごくいいですね。スクラムを自律したチームにして、それを維持させていく工夫はなにかされていますか？

大畑：チームを信頼して、お任せすることですね。スクラムと、当社の優秀なメンバー・行動指針は相性がよく、自発的に振り返りで改善案を出し合ったり、チームをまたいで情報交換や課題解決を進めたりしています。わたしがスクラムマスターも兼ねており、最初の立ち上げこそはイベントの徹底や体制整備をリードしましたが、前に進みだしてからはほとんど口出しをしていません。チームで解決できないような課題は、未熟な体制やメンバー不足など組織的な課題に行き着くので、その解決に注力しています。

また、プロダクトチームとして機能横断的なスキルを備えるためにチームの意思決定を尊重する、チームでメンバーの状況やスキルをオープンに話し合うことで、技術的な挑戦もしやすくなったのではないかと思います。バックエンドエンジニアがReactに挑戦してみる、バックエンドの言語はKotlinに縛られずTypeScriptを選択する、より生産性のあがる技術や手法を導入するなど。

城倉：スクラムの導入は誰かがコーチされたんですか？

大畑：いえ、社内のメンバーと話し合って決めていきました。

そもそも、スクラム導入に踏み切ったのは、メンバーが自発的に「スクラムでやりましょう」と提案してくれたのがきっかけです。当初の我流アジャイルだと、プロジェクトマネジャーやテックリードの経験に依存して負荷もかかるのでうまくいかない、加えて、面談で開発の進め方を説明するときに正直恥ずかしい、と話してくれました。教科書的なスクラムを導入することで、チームで開発管理の手法をキャッチアップしやすいし、スクラムをやっているときちんと言えることは採用的にも魅力になる、と気づきました。

経営陣とも、当初の開発の進め方の課題や、今後のスケールにはプロダクトチーム体制やスクラム導入が必須であること、そして、そのためには採用の強化が必要など、と提案して導入に至りました。

メンバーがパフォーマンスを出せる環境を作ることがCTOの役割

城倉：これまでは、大畑さんご自身はエンジニアとしてフルスタックにお仕事をされてきて、今はCTOとして組織やチームづくりをメインにされていますよね。そこに行き着くまでのマインドの変化について教えてください。

大畑：マインドが変わったのは、開発部長になったときですね。

いままでは多くて5人前後のチームだったので、プレイングマネジャーでよかったんです。しかし、10人を超えた開発部長となれば複数のチーム、プロジェクトを見なければなりません。

ひとつひとつの案件でWBSやチケットの管理をして、プルリクエストのレビューもして…というのはどう考えても厳しいです。思い切ってチームメンバーを信じて任せていかないとスケールしない、メンバーが最大限の力を発揮できるように整備していくのが自分の役割だと考えました。

城倉：「人を信じて任せる」を実現するためのポイントはありますか？

大畑：ひとつは、1on1で一人ひとりの状況や考えを聞き、できる限りパフォーマンスを発揮しやすい体制や機会に配置すること。もうひとつは「信じて任せられる」「高いパフォーマンスを安定的に出せる」のはどういう人なのかを定義し、評価基準や行動指針を見直したことです。

たとえば、現場の提案を尊重する裁量や新規プロダクトのリードをお任せするには、進化のために、役割を問わずに全力で前進する「Move Forward」、現状を把握し、未来を想像し、思慮深くアクションする「Think Forward」、といった当社の行動指針が伴っていること前提です。

城倉：なるほど、コンピテンシーが明確になって、メンバーたちも腹落ちできたという感じですね。大畑さんが、CTOとして一番大切にしていることや心がけていることがあれば伺ってもよろしいでしょうか。

大畑：やはりメンバーが楽しく、集中して開発できる環境をつくることですね。

わたしは裁量を持って開発に取り組むこと、ユーザーのフィードバックを得ながら改善したり、課題に対してより良い手法や技術を試行錯誤したりするのがエンジニアリングやデザインの楽しみだと思っています。自分が手掛けたサービスや機能をリリースして、ユーザーに使ってもらう、世の中に価値を提供していく、その結果、報酬があがることもやりがいです。そのような機会をできる限りメンバーに提供していくことが自分の役割だと考えています。

城倉：チームメンバーに裁量を持たせることを非常に大切にされていますよね。

大畑：そうですね。自分自身が裁量を持って働きたいというのもありますし、事業が成長して、会社が大きくなっていく過程に主体的に携わるのって楽しいだろうなと思うんです。

城倉：なるほど、冒頭でおっしゃっていた大畑さん自身がスタートアップを選んで転職されてきたのとつながる気がしました。

良い保険を提供する、プラットフォーマーを目指して

城倉：それでは、最後に今後の目標や展望についてお聞かせください。

大畑：まずは、「joinsure」をきっちりと作り込んでいきたいですね。保険会社の方々は、システムがレガシー化していて新しい保険商品のリリースやサイト改善がしづらい、開発には費用と時間もかかる、という悩みを抱えています。当社のシステムを利用いただくことで、迅速・柔軟に時代に即した新しい保険商品を提供できるようにしていきたいです。

ひとくちにSaaS型の保険システムといっても、さまざまな保険会社が持つ多様な保険商品に対応させるのは大変で、難しくもエンジニアリングしがいのある面白い領域だと思います。ドメインモデルやユーザーストーリーの整理、システムの抽象化・設計など、日々議論を続けています。また、終身の生命保険のように100年以上続く保険もあるので、どう継続的に改善していくかも考える必要があります。

城倉：社会的意義が大きいですね。これまでは、いち保険事業者という立ち位置だったと思いますが、お話を伺っていると、今後はプラットフォーマーを目指していくのでしょうか？

大畑：はい、自社の保険も、プラットフォーマーのいずれも進めていきます。

当社のミッション「あらゆる不安に寄り添う、良い保険を発明する」を実現するために、自社で良い保険を作っていくのはもちろんですが、他社様が持っている会員の接点やデータも活かしたほうが良いです。そのために、社会や技術が移り変わるなか、時代に求められる良い保険を迅速・柔軟に提供できるプラットフォームを提供し、「助けられ、助ける喜びを、すべての人へ」を実現させていきたいです。

城倉：なるほど、非常に興味深い内容でした。ありがとうございました。