保育現場の業務負担を軽減する事を目的にIoTやAIを活用した保育支援サービス「ルクミー」シリーズなどを10,000件以上、保育施設に導入してきたユニファ株式会社。今回は、その開発チームを1から立ち上げ構築してきた取締役CTO 赤沼氏へキャリアや今後の展望についてお話を伺いました。
エムスリーやNubee Tokyoでの開発業務を経て、2015 年にユニファ東京オフィスの立ち上 げ時に入社。ユニファの開発体制を構築し 様々な新規サービスの立ち上げにも関与。 現在は CTO として、機械学習・深層学習をメ インとした研究開発チームを含むシステム開発チームを統括。また、外国人エンジニアも積極的に採用し、現在 10 を超える国籍 のエンジニアのマネジメントも担う。技術系カンファレンスにも多数登壇。
ユニファ株式会社について
ユニファは、IoTやAIを活用した保育支援プロダクトの開発およびサービスを通して新しい社会インフラを創出し、家族コミュニケーションを豊かにしていくことを目指しています。
具体的には、乳幼児の午睡（お昼寝）を見守る医療機器サービス「ルクミー午睡チェック」、子どもの写真・動画をオンライン購入できるサービス「ルクミーフォト」などの「ルクミー」シリーズを展開しているほか、各種サービスを統合することで子どもの安全や保護者の安心と保育業務の負担軽減を実現する次世代型保育園の「スマート保育園®」などを提供しています。
1人目エンジニアとしてユニファへ入社するまで
小さい頃からコンピューターへ興味を持っていて、学生の頃は自身でホームページを作成していました。このようにもともとプログラミング自体へ関心は高かったため、漠然と将来はコンピューター系の仕事に就きたいと思っていました。ただ当時はエンジニアという職種がどのようなことをするのかそこまで深く知りませんでした。
それから未経験でコンピューター関連の仕事ができる会社を探していたところ、株式会社タカインフォテクノを見つけたので入社しました。最初は携帯のメールシステムの運用保守の仕事からスタートし、それから開発の為のスキルを習得していきたいという思いを伝え、通信キャリアの法人向けの料金計算システム、自動車メーカーの業務向けシステムなどの開発を経験しました。しかし、運用メインの会社だったので、今後開発のスキルを上げていきたいという自身のキャリアとギャップを感じ2008 年 8 月、自社サービスの開発ができるエムスリー株式会社へ転職しました。
自社サービスの開発は、前職のSES常駐で入ってる時とは関与度が異なり、新しいスキルや視点が身に付きました。エムスリーは医療従事者向けのサービスを提供しており、もちろん意義はあるものの、身の回りに医療従事者がいなかったためあまり身近に感じることができませんでした。もっと幅広いユーザーに対してサービスを提供していき、ダイレクトに反応が分かるサービスに携わりたいという思いが強くなり、2012 年 9 月、ソーシャルゲームを提供している株式会社 NubeeTokyoへ転職しました。ここでは、サーバーサイドや一部管理画面などの開発を経験しました。担当する業務によって3人くらいのチームのリーダー的なポジションになることはありましたが、まだ本格的にマネジメントする側の人間ではありませんでした。
もっと裁量の大きい仕事を経験したいという思いが強かったですね。当時のユニファは、丁度東京支社（現在は東京本社）の立ち上げが決まりこれから本格的にサービスを展開していくという段階で、エンジニア組織もフリーランスの方数名に手伝って貰っているだけで正社員は1人もおらず、これから採用していかなければという状況でした。
技術的な面もそうですが、ユニファであれば開発プロセスやどう組織を構築していくかなど0から立ち上げていくという貴重な経験もできるのではないかと思い入社を決めました。
私が技術のスペシャリストだったら違ったと思うのですが、他のエンジニアと比べて技術が突出しているというわけでもないので、総合的に色々出来た方が良いなというところがあり幅広い業務に携わってキャリアを構築していきたいと思いました。
当時は、ドラッカーの本やコーチング関連の本を参考にしました。最近であれば「エンジニアリング組織論への招待」や「シリコンバレー式最強の育て方 ー人材マネジメントの新しい常識 1 ON 1 ミーティングー」などを参考にしています。
エンジニア組織拡大の裏側
入社当初は、統括マネージャーという肩書きでしたが、正社員エンジニアは私だけであとはフリーランス数名という体制で開発していました。既に本番のサービス自体は立ちあがっていましたが、まだユーザーは少なかったため運用や追加開発をする傍ら採用活動も行っていました。
採用活動は大変でしたね。転職市場を見ても、どこの会社でもエンジニア採用は苦労しているという状況でした。加えて当時のユニファは今よりも知名度がなく、会社規模も小さかったので中々応募が集まりませんでした。
また人事担当もいなかったので、自身で採用のプロセスを回していました。Green等の求人メディアへの登録から求人票の作成、面接、オファー面談、入社に向けた手配など全て一人でやっていましたね（笑）
それから事業のフェーズに合わせて段階的に採用を行っていき、現在は40名規模まで成長しました。
採用においては、「迷ったら採らない」という方針を貫いており、本当に納得行く人だけを採用しています。
弊社の事業内容がが特長的なので、共感してもらえているかというは一番大きなポイントだと思っています。実際、今弊社のメンバーは、サービスに関する共感具合は高い方が多い印象です。
そのうえで、熱量があるかどうかです。チームで開発していくのでお互いが尊敬しあって自分としてのスキルアップに取り組んでいこうとする熱量があるかを重要視しています。
チーム作りという点では、まずはツール面を整えることから始めました。もともとメールでやり取りしていたところをSlackに変えたり、社内のwikiツールとしてConfluence、課題管理ツールとしてJIRAを導入しました。
また、社内のエンジニア間のコミュニケーション活性化の取り組みとして、毎月“Beer Bash”という場を設けています。ここでは、業務とは関係なしに発表したいエンジニアがいれば発表しても良いですし、聞くだけでも良いというスタンスで、皆がエンジニアリングを楽しむ場になれば良いなという思いで開催しています。
その他、社内の技術を外へ発信する取り組みとして、開発者ブログを書いています。ある程度エンジニアの人数が増えてきて、そろそろ持ち回りでやっていけるかなというタイミングで始めました。こちらは強制ではなく、あくまで希望者のみでやっています。強制すると皆書くことが苦行になってしまってそうなると続かないと思っています。とはいえ積極的にプッシュはしています（笑）
１つは採用活動に役立っています。エンジニアが会社を探し、気になった会社を調べる時、求人票やコーポレイトサイトだけでは良くわかりません。たまにエンジニア向けの採用特設ページを設けているところはありますが、やはり具体的にどんな人達がどんな事をやっているのかというところまでは分からないです。そういった意味で、ブログはどんなメンバーがどんな開発をしているかが分かるので伝わりやすいというメリットがあります。
もう１つは、エンジニアの発信する場やスキルアップのきっかけができることです。普通に開発しているだけでは自分の技術を対外的にアピールする機会や棚卸しする機会があまりないので、そのような場を設けて自身のスキルアップへ生かして欲しいと思っています。
組織拡大で新しく取り入れた1on1や海外人材の採用
チーム作りをするうえで重要なのは、技術力ももちろんですが、チームメンバーとどのような関係を築くかだと思っています。
開発メンバーが数名しかいない頃は、皆で同じプロダクトの開発しているため、お互いのコードも見ますし、どんな事を思っているのか理解できているという状況でした。けれども人数が増えてくると、普通に仕事をしているだけではメンバーがどんなことを考えているか分からない部分も出てきたので、きちんとコミュニケーションできる場が欲しいなと思い1on1を導入しました。
基本週1回、1人15分です。各部門のマネージャー陣がその部下と1on1を実施し、私はマネージャーや直接見ている部門のメンバーと行っています。色々なやりかた方があって良いと思いますが、個人的に月１で1時間より、週１で15分の方がタイムリーに話ができて良いと思っています。わざわざ時間取るほどではないけど、そういう場があるならついでに話しておこうかな位の話はあると思っていて、そこまで重くならないうちに話して貰えるというのはメリットだと思いますね。また、メンバーが話をする時間としているため、こちらからの一方的な情報伝達や評価の場とはしていません。
日本人側も、極力英語を使ってコミュニケーションをするようにしています。チームによっては朝会を英語で実施しています。また、もともと日本語の環境だったので、ドキュメントも日本語のみでしたが、最近は必要なところから随時英語版を用意していく準備を進めています。
中には、英語が得意ではない日本人メンバーもいますが大変ながらも頑張ってくれています。一方で、日本に来てくれる外国籍のメンバーも我々のことを理解しようとしてくれているので、こちらがなんとか伝えようとすればそれなりにコミュニケーションは取れるのだなと感じています。
現在の評価と課題
評価システムは日々改善していますが、本人と上長だけではなく第3者の視点を入れた複数視点での評価を長らく仕組みに取り入れています。
評価項目は部門ごとに異なりエンジニアの部分だと技術力などが入ってきます。しかし、エンジニアの場合、例えば半年分の目標を立てても、終わってみたら会社の状況や事業の状況によってやることになってた開発をやらなくなっていたということもざらにあり、事前の目標が立てづらいところがあります。そのため、目標をしっかり立てるというよりは終わってみてどうだったかというところも含めてきちんと評価するようにしています。
評価にやや工数がかかりすぎてしまっているというのが現状です。そのため、今は工数をかけすぎずにエンジニアのスキルや貢献を評価できる仕組みを模索していきたいと思っています。
エンジニア組織拡大で自身の役割にも変化
それなりに社員もユーザーも増えてきたこともあり、会社としてプロダクトの重要性が高まってきていました。そのタイミングで、会社の経営体制を整えることになり、CTOに就任しました。
当時会社の規模は小さかったですし、代表とCOOとも良く話をしていたので経営陣になることへ抵抗はなかったです。どちらかというと、今の方が規模も大きくなってきて責任の重さを感じているところです。（笑）
初期は、ほとんど開発してました。機能開発についてはフリーランスの方も対応してくれるのですが、何か問題が起こった時はやはり正社員の私が対応するしかなかったので開発・運用が業務の中心でした。
一方で、今は本番プロダクトの開発は全くしてないです。採用については人事担当がいるので事務的な手配を自分でやるということはなくなりましたが、ここはある程度時間を割いていて、書類選考・1次面接も自ら担当しています。また外向けに開発チームの良さを伝えるための活動として技術ブログを書いたり、色々なカンファレンスのスポンサーをしたり登壇をしたりしています。あと、経営陣でもあるので経営関連の仕事もあります。
経営側の視点からすると、経営側がどう思っているのかをきちんと理解してくれてそれに向けてチームがどう動くべきかをメンバーに正しく伝えることができる人にマネジメントして欲しいと思います。
現在のマネージャーは入社した時はマネージャーとしてではなくエンジニアとして入っているので、技術力もありながらもメンバーのマネジメントができるといったメンバーです。
但し、技術に関してはある程度の理解は必要ですが突出している必要性はないと思っています。私自身もメンバーより技術力が高いのかというと、メンバーの方が技術力高い分野もあります。したがって、マネージャーとしてきちんとメンバーと話しができているか、メンバーの考えを理解できるかという方がはるかに重要だと思います。
今後について
弊社のサービスは、「ルクミー」シリーズを中心に10,000件以上の保育施設へ導入されていますが業界全体でみるとまだまだ導入余地は大きいと思っています。
そのような中で、CTOとして私が果たすべき役割は、「技術で経営にコミットしていくということ」だと思っています。具体的には、開発組織のアウトプットをどれだけ最大化できるかです。
そのために、まずはそのチーム作りへ注力して、我々のエンジニア組織の行動指針「保育をハックする」ことができる組織を目指していきたいです。
