この記事は MICIN Advent Calendar 2022 の25日目の記事です。
前回は阿部さんの業務アプリケーション開発にGoを採用する理由でした。

Head of Engineeringの塩浜です。
MICINには創業から関わり、さまざまな役割を担いながらも、組織のさまざまなフェーズを見てきていますが、一貫して関わってきたのがEngineering組織かなと思っています。今は、自ら手を動かすことはかなり少なくなってきており、組織の一人ひとりがやりがいを持って働ける環境を作ることをミッションに活動をしています。

Advent Calendarの大トリの大役を頂戴いたしまして、１ヶ月間気合いを入れてしたためた記事を公開させて頂きます。少々長めのものになってしまいましたので、読み飛ばしながら興味のある部分について読んでいただけると幸いです。

Advent Calendarで記事を皆で書こうと決まってから、どんなことについて書こうかなと悩んでいたのですが、先の通り自分自身が技術に触れる機会が減ってきておりますので、MICINで扱っている技術やチームの取り組みについてはここまでの記事にお任せするとして、僕は創業以来一貫して携わってきたエンジニア組織の変遷、特に、コロナ禍で急成長したこの数年の組織の変化や、その際の組織状態、僕自身が考えていたことについて書くことにしました。

~ 創業期（2015年末 - 2017年下期） ~

MICINの創業は2015年11月で、僕自身は12月初頭から業務委託として関わりを始めました。丸ビルにあるお洒落なバーで、代表の原、共同創業メンバーの草間と初めて出会った時のことは今でもよく覚えています。元々、金融業界にてエンジニアをしていた自分にとって、医療は未知の領域でその分野で技術を駆使して創業をしようとしている二人との出会いは、人生を大きく変えるような出来事の一つでした。

僕自身は、原体験として大学時代から父親の闘病を家族として支えるような経験を持ちながらも、医療領域において自分の培ってきたエンジニアとしての力は本当に無力だなという思いを常に抱えていました。そのような中で、医療領域に技術の力で変革を起こしていこうという二人の想いはとても新鮮で、そして魅惑的でした。業務委託として参画してからは、基本的にエンジニア二名体制で動いており、前職の業務の傍ら夜通しでオンライン診療サービスcuronの原型とも言えるプロダクトの開発をし、２ヶ月弱でベータ版を作り上げリリースするという短納期で、当時はエンジニア組織とも言えないような属人的な状態での開発を行っていました。

それから一年ほどで、今でもチームを支えてくれている、インターンから入社を決めてくれた次田さんや、大学時代の同級生だった酒井くんの参画があり、少しずつチームと呼べるぐらいの規模にはなってきました。ただ、その頃はまだやはり一人一殺と言った形でプロダクト/プロジェクトを持っており、お互いがお互いに背中を預けながら、それぞれの領域を開発するような動きで、ドキュメントもなく、デプロイフローや運用のルールなども決まっていない、組織とは呼べないような状態での開発が続いていたかなと思います。

~ 徐々に組織化するチーム（2018年上期 - 2020年上期） ~

MICINのエンジニアチームで初めて、リファラルではない採用が始まったのは、創業から二年半ほど経った2018年の春先だったと思います。

エンジニアチームにおける採用活動では、根幹に「ベンチャーとはいえ会社のビジョンに共感して長期的にご一緒出来る人と働きたい」という思いがありそれを強く意識して動いていました。一方で、技術レベルが高く、ビジョン共感がある方を探すことは、売り手市場のエンジニア採用においては藁山の中から針を探すような難しさです。そこで、長い目でみた組織成長を考えた際に、「エンジニア歴が短くてもビジョン共感を重要視した採用」をした上で、「MICINの文化やビジョンを知って頂きながら育っていって頂く」と言う形をベースに採用活動を実施していました。

その時点での技術力より、一人ひとりと長い時間会話をさせて頂き「ビジョンに共感頂けるのか」や、「技術的な成長を志す意志」などを確かめながら採用を進めていました。

エンジニア未経験で社会人インターンから入社を決め、今ではEngineering Managerとして頼りにしている外山さんや、当時はジュニアレベルのエンジニアとして入社いただき最も成長したエンジニアの一人でもある新宮さんなどが加わったのはこの頃で、エンジニア組織としては総勢８名の組織となりました。

組織の規模が大きくなり、関わるプロジェクトも多岐に渡るようになったため、今までの完全に属人的な動きではうまくプロジェクトを進めることが出来なくなったことや、より一人ひとりが成長をしていけるような仕組みを検討する中で、役割分担をしながら複数人での開発プロジェクトを企図したり、タスクを切り、ストーリーポイントをつけたりと、少しずつ組織だった開発を始めたのもこの頃でした。

当時の組織構造を振り返ると、機能組織（例えば、エンジニア組織、営業組織、など）から各プロジェクトやプロダクトに人をアサインする形で動いており、エンジニア組織に関しては、どのプロジェクトでも一旦僕が案件概要を聞いた上で適正をみてアサインをする形で動いており、今思えばですが非常に属人性に溢れる組織体制となっていました。

一方で、一人ひとりの特性やキャリアとして目指す方向性を把握しながら、アサインを決めている状態でしたので、当時の組織規模であれば最も効率の良い差配が出来る体制でもあり、かつ、流動性高く様々な人が一つのコードベースに触れる状態だったため、当時の凄くタイトな納期での開発を考えると、技術的負債も出来づらい状態で開発が出来ていたのかなと思っています。加えて、エンジニア組織からは創業５年目まで離職者が一人も出ない状況で、一人ひとりが納得感を持って業務に取り組むことが出来ている状態でもあったのかなと考えています。

~ コロナ禍における急成長期（2020年下期-2021年上期） ~

2020年は新型コロナウイルス感染症の蔓延の影響で、医療領域における規制の変化、医療従事者や患者の方々の心理面での変化などより医療のデジタル化・オンライン化へのニーズが大きく顕在化し、オンライン診療含めたMICINのプロダクト群は思わぬ急成長を遂げました。それら急成長を受け止めるべく、機能組織から事業部を中心とした組織にMICINが変貌を遂げたのもこの時でした。事業部化以前は、複数プロダクトやプロジェクトの開発が並列して行われることが多々あり、都度その責任者同士が優先順位の議論をしなければならない構造で判断に時間がかかっており、また、プロダクトやドメインのノウハウがチームに蓄積されていかないと言う問題も指摘されていました。

事業部化においては、当時のMICINの核となっていたプロダクトが事業として切り出され、事業部として活動を開始する動きをとることとなりました。その際エンジニア組織は、SREなどの一部の横断組織を残し、全てのメンバーがそれぞれの事業部の中に入り活動を続けることとなり、僕自身も利用者数の急拡大を遂げていたオンライン診療に事業部長として関わることとなりました。

今までは、全ての案件に一度僕自身が目を通してアサインをしていく動きだったところから、各事業部内でアサインを決める動きになったことで、事業部間での優先順位議論のステップがなくなり、また僕への相談からアサインというプロセスがボトルネックになってしまう事もなくなるため、開発のアジリティは非常に高まりました。

また、チーム毎に技術やプロダクトに関する勉強会をしたり、機能役割を超えたミーティングが定例で設定されるなど、プロダクト理解や、ドメイン理解も深まる活動も始まり、機能組織時代に抱えていた問題を概ね解決することが出来ました。

一方で、忙しいチームと緩やかなチームの差が生まれ全社で見た時の効率性は下がってしまうことや、アサイン可能なプロジェクトが減少することから、個々のメンバーの意志やキャリアに合わないアサインが増えてしまうという問題も発生し始め、望まない形での離職者が複数現れ始めてしまったのもこの時期でした。

それらの課題に向き合うため、このタイミングで初めてEngineering Managerの登用が行われました。Engineering Manager登用以前は、各プロダクトやプロジェクトにおいて技術選定やコード品質に責任を持つTech Leadがおり、暗黙的にTech Leadがチームのメンバーのマネジメントを兼務している状況でした。しかし、Tech Leadは基本的に技術的なレベルの高さにより任命されていたため、マネジメント業務におけるスキルや意識にバラつきがあり、課題の発見や対応が遅れてしまうなどの問題が発生していました。そこで、マネジメント部分の責務を分離しEngineering Managerの責務とすることで、スキルと意識の双方に適性のあるメンバーがその責務に向き合うことで、課題解決をする形としました。当時、具体的には以下の表のような形で責務を分離しました。

~ エンジニア組織の再構成（2021年下期-） ~

Engineering Managerの登用により、顕在化した課題の発見・対応の速度は改善し、足元組織の安定化を図ることが出来ましたが、また別のいくつかの問題が顕在化しました。

1. 近しい機能（e.g. ビデオ通話、問診、予約）を各事業部それぞれで開発

   1. 機能面でのばらつきが発生

   2. 技術ナレッジの点在、開発効率の低下

   3. 技術的な深度の低下

2. Tech Lead頼りの組織

3. 全社における優先順位の変化への柔軟な対応が困難

それぞれを詳しく説明すると

1. 近しい機能を各事業部それぞれで開発
   MICINでは、各事業部それぞれ取り組んでいる課題は異なるものの、同じ医療領域のデジタル化に挑戦をしているため、各事業部のプロダクトで共通して利用する機能がいくつか存在しています。一番わかりやすいものとしてはビデオ通話機能などがあるのですが、事業部制になりそれぞれのプロダクトチームでビデオ通話の実装を行う形になってしまい、提供できる機能（e.g. 画面共有機能、３名以上での通話機能、録画機能）が事業部によって異なる問題や、それらの開発・運用における技術的な知識が点在してしまう問題、またシンプルに同じことを複数チームで開発をする効率の悪さなどが目立つようになりました。また、事業部のチーム自体はプロダクトの中の機能開発の傍らでの実装となるため、一つの領域で技術的な深度を深めていくことも難しいなどの問題が発生しました。

2. Tech Lead頼りの組織
   MICINエンジニアチームでは、非常に有り難いことにシニアメンバーに長く在籍いただいており、それが故にTech Leadが技術的にはもちろんのこと、ドメイン知識的にもチームで最も頼りにされている状況が出来ていました。これは、チームの開発効率や、技術品質を担保する上では非常に良い側面を持っていることでもあるのですが、同時に以下のような悪影響も存在をしていました。

   1. Tech Leadの多くの時間がレビューや相談に割かれてしまう

      1. 最も開発力のあるメンバーであるTech Leadが開発に時間を使えない

      2. Tech Lead自身の技術的成長の時間が確保しづらい

   2. Tech Leadに聞けばわかるためドメイン知識などがチームメンバーに蓄積されづらい

3. 全社における優先順位の変化への柔軟な対応が困難
   これは、事業部制となった利点の逆説という側面も多いのですが、事業部内でのアサインメントの高速化が図れた一方で、MICINのようなベンチャーでは、外的要因の変化や、内的要因によっても全社における優先順位が大きく変わることがあります。それらに対応しようとした時には、優先順位が高い事業部に、相対的に低い事業部から人員を送ることとなるのですが、それらのコミュニケーションコストも非常に高く、準備にも時間がかかってしまい、なかなか柔軟な動きが取れないという課題が存在しました。特に、大きく優先順位に変化があった時に動かしたいのは、先の課題に上がっていた、Tech Leadのような一人で状況を大きく変えることができる人材となるので、より一層その異動は難しいという状況でした。

こうした課題に向き合うために、2021年末頃から、エンジニア組織全体の再構成を検討し以下の二つのチームを、横断組織の中に組成しました。

• 共通基盤（Platform）チーム

• SWATチーム

それぞれのチームの役割ですが

1. 共通基盤（Platform）チーム
   先に挙げた課題の一つ目である、「近しい機能を各事業部それぞれで開発」を解決することを目的に組成されたチームです。
   「近しい機能を各事業部それぞれで開発」に対しては、各事業部のプロダクトマネージャーと対話をしながら、それぞれのプロダクトロードマップを鑑みて、共通的に実装される予定がある機能を開発するチームで、足元ではビデオ通話機能の開発を行い、それらを各プロダクトへ導入するサポートをしています。

2. SWATチーム
   SWATという名前は、「アメリカ合衆国の警察など米法執行機関に設置されている特殊部隊のSWATチーム」からとってきており、その名前の由来の通り、全社の中で優先順位が高く、同時に技術的な難易度が高い課題に向き合い、それらを解決をすることで全社の成長に影響を与えることを目的としたチームです。
   このチームを設置した理由として、先の課題であげた「Tech Lead頼りの組織」、「全社における優先順位の変化への柔軟な対応が困難」への対応があります。また、副次的にシニアメンバーの技術力やモチベーションの向上なども期待をしておりました。当時、「SWATチーム発足の目的」として起案をした内容は以下でした

   1. シニアエンジニアがお互い近くで働くことによってお互い刺激をし合う環境を用意することで
      - シニアエンジニアの技術力向上
      - シニアエンジニアのモチベーション向上

   2. シニアエンジニアのみで構成されたチームでの開発により
      - コミュニケーションやレビューにかかるコストを低減し、時間効率を最大化
      - プロダクトの品質も向上

   3. シニアエンジニアを定常開発から離すことでチームに次なるリードを生み出させる

２名のシニアエンジニアを全社から選抜し、SWATチームに移すことで、ドメインノウハウの引き継ぎや、残されたメンバーの意識が向上するなど期待した効果をまさに生み出すことができており、かつ、SWATチームの活躍により本年内でも二つの重要なプロジェクトを短納期かつ高品質で完成することが出来ました。

このような形の二つのチームの組成により、2021年初期に顕在化してしまった課題の解決は進み、現在に至るという状況です。

~ まとめ ~

だいぶ長文になってしまいましたが、最後までご覧になって頂きありがとうございました。このように、MICINのエンジニア組織は2015年の創業から様々な形に変化を続けてきています。特に、2020年のコロナ渦以降の変化は非常に大きく、組織の拡大と共に様々な問題に向き合いながら、事業やプロダクトと向き合い続けてきました。組織には様々なフェーズがありますし、またそこにいる仲間、一人ひとりの特性によっても全くもって違う形になり得るものだと思っています。MICINでの事例がそのまま適用できるチームはあまりないのかもしれませんが、我々がぶつかってきた課題、そしてそこに対する対応などが、もし少しでも、組織に関して悩んでいる方の参考になれば嬉しいです。

2023年はMICINにとって非常に大きなチャレンジが待っている年で、まだ見えない中ですがまた新たな課題がきっと見つかることと思います。我々は常に、変化を続けながらより良い組織を目指してこれからもビジョンである

「すべての人が、納得して生きて、最期を迎えられる世界を」

の実現に向けて、尽力し続けて参りますので是非興味を持っていただけた方、組織のことなどで質問がある方などいらっしゃいましたら、Meetyなどでカジュアル面談を受け付けておりますので気軽にお声がけいただけたらと考えています。

長いようで短かったAdvent Calendar期間もこれで終了ですね。記事を書いてくれたMICINの皆さん、そして記事をご覧になっていただいた皆様、本当にありがとうございました。

MICINではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
MICIN採用ページ：https://recruit.micin.jp/