InsurTech企業のCTOが作る新たなエンジニア組織とは

株式会社justInCaseのCTOになるまでの道のりを教えてください。

CEOの畑との最初の出会いは、今から十数年前に私がクライアント、彼がコンサルタントという立場で顔を合わせたことでした。その後同じ業界や近い業界で数年に一度連絡取るという関係でしたが、最後の職場を退職した際に連絡したときに飲みに行き、私が専業主夫になると伝えたところ「それなら一緒にやろうよ」というノリでjustInCaseの立ち上げに参画しました。

CTOとしてのjustInCaseでの私の役割ですが、世間一般のCTO（特にテックベンチャーCTO）と違い、私はアプリ開発やインフラ構築等に強いわけではないため、主にビジネスロジックとそれをどう実現するかのブリッジの役割を担っています。また自分自身は古典的な分析、ベイズ推定、深層学習と幅広い経験があるためデータ分析についての最終責任を担っています。

株式会社justInCaseで働くエンジニア像はどのような方ですか？

justInCaseが求めるエンジニアの人物像は次になります。

1. 好奇心があり手を動かしつづける人
2. 自分の好奇心とビジネス優先度を分離できる人
3. 日本的組織の無駄な習慣にとらわれず自由な発言ができる人
4. 礼儀2.0のプロトコルにキャッチアップできる人

好奇心があり手を動かしつづける人

現代では学習しなければならないことが日々アップデートされていきます。例えばwebappフレームワーク一つを取っても、さまざまなフレームワークが乱立し、何を使うべきかという選択に迷うかもしれません。ここで私が重要視するのは、ともかく直感で良いので一つ自分で選択して手を動かし始めることです。それにより他の比較対象との差異を身体で覚えることになり、それが自分自身の経験値を高めていくことになると考えています。TensorFlowとPyTorchの両方使える必要はありません。一つの本質を押さえることができれば、もう一つの共通点と差異を認識できるので、キャッチアップは難しくないと考えます。AWSとFirebase, SwiftとKotlin, PyStanとRStanしかりです。

自分の好奇心とビジネス優先度を分離できる人

エンジニアはどうしても技術的な興味（最新 or 流行っている）を仕事に持ち込みたいという意欲に駆られます（私自身もです）。その際に、なぜそれを導入すると会社に利点があるのか。導入コストはどの程度なのか。長期的な方向性はどこにあるのか、を簡素に説明できる人は魅力的です。

日本的組織の無駄な習慣にとらわれず自由な発言ができる人

自発的な発言自体も求められますが、その発言となる根拠をシンプルかつ明確に説明できると望ましいです。justInCaseのエンジニアの大半はリモートワークかつ時差を抱えているので、slackでの連絡でも往復のやり取りをいかに減らすかが重要になってきます。（現在ニュージランド、カナダ、ドイツ、香港、和歌山、東京でのコミュニケーション）。意見なのか返答を求めるのか、deadlineはいつまでなのか、またその発言の背景となる自分の考えや、pros consを明確にすることが望ましいです。

礼儀2.0のプロトコルにキャッチアップできる人

文化や背景が異なる行動や発言に対して、その違いを理解できる人はチームとして大歓迎です。理解と同意は異なることを認識していることをチームとして認識しているメタ構造が非常に重要と私は考えます。違いを理解しようとすることは重要ですが、同意は必要ありません。人は一人一人違って良いのですから。礼儀2.0自体が重要なのでなく2.1, 3.0とアップデートでき、その際に1.0の人を理解する（同意の必要はない）マインドが大切と考えています。

CTOのお仕事のやりがいや魅力はそれぞれどんなことだと感じていらっしゃいますか？

CTOのやり甲斐は、いかにして自分たちが素晴らしいと思うサービス/プロダクトを世に広められるかだと思います。技術それ自体は目的ではなく、最終的にサービスを使って頂きそしてお客様が満足してもらうことが一番重要と考えます。CTOの発言として適切ではないかもしれませんが、技術を使わなくて解決できるのであれば、使わないのが一番と思っています。

使わないのが一番というのはどういった意味でしょうか？

はい。技術が目的であればそれを提供し利益を上げる会社であれば良いと思います。一方で私達は保険業という業種なので、最終的には保険という商品を通じて不確実な危険から経済的損失を守ることができユーザーが満足してもらう、そして会社が同時に利益を得るということが目的になります。技術というのは問題のフレームが与えられた時に、それをどう解くかという手段になりますが、問題のフレームごと変更することで解決でき、より少コストな対応で解決できればそれが一番理想と考えます。

企業がCAOやCTOというポジションを設けることによるメリット、企業の成長スケーラビリティはどんなことだと思いますか？

会社の規模が変わってくると、求められる役割は大きく変わっていきます。justInCaseでも創業者だけの時代からすでに外部委託も含め十数人のチームになってきました。CxOの役割は単なる名刺の記号でなく、本質的に責任の所在（意思決定者という良い意味で）を表していくものと考えます。スタートアップ的なフレキシブルな組織ではボトムアップの意思決定が求められますが、ボトムアップ意思決定は危機時に方向性を明確にできないという弱点があります（日本のほとんどの組織はこれだと考えています。すなわち平常時/通常時は優秀な現場に支えられていて問題ないように見えますが、危機が訪れると無能な指揮官により舵取りができず沈没していく・・・）。したがってビジネスサイクルが加速化する現代において瞬間瞬間の舵取りが重要になっていくのでCxOの重要度はますます増えていくと私は考えています。

CTOの小泉さんはリモートワーク中心のことですが、実際どのように一緒に業務を行われているのでしょうか？

私は現在家族の都合で在宅をメインに仕事をしています。メンバーは時差を抱えていますが、私は 10:00 JST – 19:00 JSTをメインに作業しています。会社全員のメンバーは slack で情報共有し stock の情報については wiki にまとめる形態です。これはどの会社さんも試行錯誤されていると思いますが、flowとstockの情報の使い分けにいつも苦労しています。別途 remotty というサービスを導入し、2分ごとにカメラで作業中の表情のスナップショットを共有しています。remottyは表情が見れるということで好評でしたので採用しました。（一方で変顔も撮られるため油断は禁物ですが。）一方で情報が拡散するので業務内容についてはslackに統一し、場の共有感を得ることとvideo chatで今話せるかどうかという点で利用しています。タスク管理は正直なところまだ軌道に乗っていません。 jira, trello と試し今は notion.io というサービスを使用していますが、slack連携がまだ弱いため使い勝手はまだこれからという印象です。

開発手法や言語については、いかがでしょうか？

アプリ側はiOS開発が Swiftメインに私も含め4人です。現在は Swift3.2を用いてますがSwift 5.0が出たタイミングで Swift 4.2にアップデートを予定しています。MVCを用いて開発していますが、アーキテクチャーについてはプログラム最適化の第一法則/第二法則に従いこのまま継続していきます。Android Appは今年秋ごろから着手の予定ですのでKotlinおよびiOS開発(重要度低)の両方の経験がある方を探しているところです。

サーバ側はAWS上でデータ分析基盤、API、顧客データベース（顧客ポータル）等と業務対象が多岐に渡るため、適切な言語を使用しています。言語はあくまで目的ではなくビジネスを達成する手段と考えていますが、開発力の高さはビジネスそのものの成功度と直結するので、justInCaseはエンジニアの働きやすい＆魅力ある環境の提供に力を入れています。
– Angular/TypeScript, ES6, Python, R, Stan, C++, MySQL

なお、社内的にはプログラミング母語としてPythonを採用しており、エンジニア以外の人もPythonで通常の日常業務を自動化、最適化することを推奨しています。

国内含めニュージランド、カナダ、ドイツ、香港、グローバルな環境から、エンジニア大多数がリモートで開発を行っていらっしゃいますが、プロダクト開発のコツやオススメの方法はありますでしょうか？

良いコミュニケーションとは一体何かを具体的に落とし込み、それをチームで共有して実行していくことと考えています。justInCaseの掲げるコミュニケーションについては「求めるエンジニアの人物像」で述べたので再掲しませんが、その内容自体はチームによって異なっても良いものであり、それが徹底的に共有（メタ理解）してあることが重要と考えます。

具体的に落とし込むという部分をお話できる範囲で共有いただいても宜しいでしょうか？

リモート業務において必要なことは、誰がどの業務を担当しどの程度まで進んでいるかの可視化を徹底することだと思っています。そこで、私達は試行錯誤しながら結果的に次の方法に落ち着きました。

●slack上の #status_update のチャネルで、前回までのtaskの進行具合と、今日のtaskのリストを提示する

●作業を開始する人は毎日slack上の #working_room の channel で作業開始を宣言し、作業プロセスをスレッドとして書き込んでいく。終了時には

Also send to #working_room

にチェックを入れ終了する

これにより、誰がいつ、どのような作業をしているかが可視化され、お互いが何を考え何を実行しているかをリモートでも把握できるようになってきました。

今回のプロダクトにかける思い

スタートアップは全く新しいサービスを提供する/既存の効率化の二つの役割があると思います。justInCaseは保険業という分野にとらわれず、身近にあったらいいなと思えるサービスを次々に出していける組織に会社にしていきたいと思っています。2018年7月にローンチしたスマホ保険は実際に自分達自身であったらいいなを実現したものであり、今後もこのような自分も入りたいと思えるプロダクトを出し続けるよう努力して行きます。全ての保険はリスク細分型（自動車保険のように運転者のリスクに応じて保険料が変わる）になっていくと考えいますので、今後も「あったらいいな」的な保険を提供できるよう開発を続けて行きます。

テクノロジーの力を使い保険をより効率的に行う際の、ビックデータ活用手法を具体的に教えてください。

開業したばかりなので分析するデータはビッグデータではありません（ビッグデータも人によっては RAMに乗らないサイズ～テラバイト・ペタバイトと隔たりあり）。したがって、ビジネスステージに応じて必要な技術を使えるように準備していくことが大切と考えています。データの活用手法という観点で言えば、定量的な分析に基づく意思決定および次への行動は不可欠な時代になっています。保険という観点から言えば、保険料を決定する際のモデル内のハイパーパラメータに関して、ビジネス開始時は広い分布を持ちえますが、いかにアップデートを効率化しタイトな分布を推計できるかが鍵となり、そこがビジネスの収益の源泉となると考えています。

なお、深層学習は分野によって得意不得意があるので、なんでもかんでも深層学習という幻想はjustInCaseには無いですし、AI使っていますというマーケティング用語には大反対しています（が、CEOに押し切られましたw）。個人的にはAIという単語は人/文脈によって意味が全然異なるので、初見の人にはAIとはどのような定義かを聞くように心がけています。

今後のデータ活用や解析、ディープラーニングの活用方法の展開について

ディープラーニングの幻想に飽き飽きしている人こそ、justInCaseの求める人だと思っています。一方で既存の論文やarXivの動向をキャッチアップし実装およびビジネスに応用したい人も大歓迎です！私は、外部の研究室や研究所に出向き日々知識を更新するよう心がけています。フルスタックデータサイエンティストの存在は幻想だと私は思っています。自分がやりたいこととjustInCaseが目指す方向がマッチしている方、ぜひ一緒に働けたらと思います！ご連絡お待ちしております！

小泉 洋夫

CTO, Co-founder

経済学部、理工学部卒のdual degree。26歳からサラリーパーソン生活をはじめるも好奇心（飽き易い性格）から保険業界、資産運用業界、ヘルスケア分野にてモデリング、シミュレーション、データ解析に従事。「機械学習の95%は前処理」が持論。 いろいろな縁がありjustInCaseに参画し、持ち前のゼロからキャッチアップの精神により現在もアプリ開発、インフラ構築の修行中。 趣味：街猫観察
プログラミング: SAS / R / SQL / Stan / WinBUGS / Python / Swift/ C# / VBA / Matlab / Scheme / Julia / Haskell

ジャストインケースグループでは、さまざまな職種を採用中です。

ご興味がある方はぜひ、採用ページよりお気軽にご応募ください！

https://justincase.jp/careers