この記事は MICIN Advent Calendar 2024 の最終日の記事です。
前回は阿部さんの GitHub ActionsでGoのコンテナイメージをビルド・プッシュする際のベストプラクティスを考える でした。

はじめに

MICINのエンジニアリングヘッドの坂本です。

皆さま、メリークリスマス！いかがお過ごしでしょうか。

今年のMICINに関するプレスリリースからプロダクト開発に関するトピックのご紹介と、プロダクト開発の生産性について個人的に考えていることを書いてみます。

2024年のプロダクト開発のトピック

2024年も引き続きMICINに関する多くのプレスリリースが発信されていますが、その中からプロダクト開発のトピックを2つご紹介します。

なお、今回ご紹介するトピック以外にも、生成AIのプロダクト機能への取り込み、年間数百万円規模のクラウド費用削減対応、開発環境の自動作成の仕組み化、ホームページ関連の非機能面の改善、複数プロダクトでのテスト自動化など、今年も多くのエンジニアリング的な取り組みやチャレンジがなされています。

プロダクトや事業への生成AIの活用が進んだ「AIクイック会計機能」

今年は、特にオンライン医療事業部で生成AIの活用が進み、これまでアセットとして有効に利活用できていなかった各種画像データから構造化されたデータを取得できるようになりました。データが構造化されることでアプリケーションで処理可能になり、業務効率の飛躍的な改善に繋げることができます。その1つの例がこのクロンスマートパスに追加された「AIクイック会計機能」です。AIクイック会計機能により、医療機関の関係者が紙の情報を見て目でシステムに打ち込むという負担が軽減されるようになりました。

この機能の実現にあたっては、クロンスマートパスのプロダクトの処理はアプリケーションエンジニアが行い、非構造データから構造データの抽出については抽出精度の改善まで含めてデータソリューションチームのMLエンジニアが行うという、エンジニア組織内でそれぞれの高い専門性を発揮した見事な連携がなされました。MICINでは1チームとなって高い成果を挙げる「Engage」というバリューがありますが、従来はアプリケーション開発とデータソリューションはそれぞれ独自に成果を創出していたことが多かったこともあり、今回、こうした形でEngageが発揮されたことは大きな収穫になりました。

また、この記事では、オンライン資格確認システムを利用することで、過去3年間の薬剤情報等を参照できるようになって重複投薬や併用禁忌の確認もできるようになるという電子処方箋への対応についても触れられています。これまでもオンライン診療とオンライン服薬指導では実装されていましたが、今回、クロンスマートパスを利用している患者さんも、電子処方箋を希望されれば、診察後会計待ちすることなくすぐに帰ることが可能になりました。

医療のサービスに安心・シンプルにアクセス〜パスキー認証の実現〜

この12月には、クロンサービスにおける患者さん向け機能として「パスキー」に対応しました。このパスキーはMICINのミッションにもある「医療をもっと身近に」を技術力で実現した取り組みであり、更に医療に安心＆シンプルにアクセスできるようになりました。なお、このリリースの記事内にも記載がありますが、クロンサービスの医療者向けの二要素認証については、医療業界のガイドラインに対応の必要性が明記されていることもあり、医療機関の判断により利用できるよう以前から実装されています。

MICINでは、患者さんや医療者の認証の機能は、再利用性等を高めるために共通基盤として切り離して開発・運用されており、同じような認証ロジックを複数プロダクトで開発しなくても良いようになっています（関連記事：MICINのID基盤の取り組み）。今回のパスキー対応は、この切り出された共通基盤でパスキー認証の業務ロジックを実装し、それをクロンのユーザ設定メニューとして組み込む形で実現しています。このパスキー対応もクロンのプロダクトチームと共通基盤チームの協力体制で実現しており、チーム間のEngageが発揮された取り組みになっています。

プロダクト開発の生産性について考えたこと

私個人としては、昨年の秋にエンジニアリングヘッドを拝命して以来、MICINのエンジニアが事業へのコミットとそれぞれの自己実現を両立できる環境づくりを進めてきています。特に今年の夏場あたりからは、プロダクト開発の当事者を含む社内外の様々な方々にヒアリングを行いながら、MICINが提供する各々のプロダクトの開発における課題を整理し、そこから本質的な解決策を策定し、クイックにできる一部の施策は改善の実行までやることをミッションとして取り組んでいます。また、今年は秋ごろにMICINの全社の生産性について経営陣や各事業部等のキーマンと議論をする機会もありました。こうした流れを受けて、プロダクト開発の生産性が高いチームの状態とはどういう状態なのかと考えてみたことを書きます。

注：あくまで私の私見であり、生産性について客観的・体系的にまとめたものではないことをご了承ください。

生産性が高い例①フィードバックサイクルを通して狙い通りにKPIを伸ばし続けられている

事業やプロダクトが達成したい売上などの目標に対して、市場やユーザのニーズをうまく把握した上で効果のあるKPIを選択でき、プロダクトの改善がそのKPIに効いていることを数字で実感できている状態です。これは開発チームの当事者もそうでない人も非常に開発生産性が高いと実感できる状態ではないでしょうか。

開発チームとして事業目標の達成に直接貢献できていると感じられ、この成功体験が関係者に共有されることで自然にチームとしての一体感も生まれやすくなりますので、レトロスペクティブなど学習する機会の確保や適切にKPIを設定し続けることといった開発活動のメンテナンスができていれば、メンバにさらなる挑戦意欲も生まれてくるといったような好循環に入っていける状態です。

MICINの場合だと、患者、医療機関、薬局などのユーザからツールを実際に使ってもらった生の声が一定数ありますが、こうした生の声の改善要望を踏まえてプロダクト機能改修をすることで、苦情が減ったりポジティブなフィードバックが増えるといった反応が継続的に得られ、プロダクトがより使われるようになって、収益も伸びている状況が該当します。もちろん、ユーザが増えると、中にはネガティブなフィードバックもあり、時にはそれには凹むこともあるかもしれませんが、開発チーム関係者は、自分たちの成果物がユーザに使われ、反応をもらえていることにやりがいを感じながら仕事に励むことができるように思います。

生産性が高い例②開発効率性に関する測定可能な指標が明確で、継続的に改善している

前提として、有用なゴールやKPIが設定されているという条件付きですが、高い開発効率性で成果物が生み出されている状態で、やることの狙い等がズレてなければ、成果も必然的に高まります。

具体的には、プロセスが整備されて各工程での無駄が少ない、コミュニケーションの精度が高くて開発時の戻りが少ない、コードベースの技術的負債が少なく機能追加をする際などのオーバーヘッドが最小限になっている、リグレッションテストが自動化されてビジネス要求以外のライブラリバージョンアップ対応等にかかるQA工数が最適化されている、といったような状況が該当します。

こうした開発効率性を測る指標として、詳細は割愛しますがFour Keys（DORAメトリクス）、SPACE、DevEX、DX Core 4あたりがよく知られています。こうした公開されている指標が自分たちにとって有用であればその全部または一部を採用してモニタリングしても良いですし、既存の公開指標が自分たちの課題の解決に向けた指標としてピンとこなければ、自分たちで独自に指標やそのロジックを決めても良いと思います。大事なのは、測定した数値の改善によりプロダクト開発の問題が解消あるいは軽減されていくことを関係者が実感できることであり、効果的と感じられれば、成功体験を共有しながら開発効率性を高めていけるようになります。

MICINの場合だと、開発のステータスの変化にかかる日数をモニタすることにより、チーム内のコミュニケーションの課題が明確になり、それを改善することによりリリースサイクルや開発環境までの平均日数のベースが短くなる、あるいは、テストの自動化が進むことによってQAのリグレッションテストにかかる人的工数が一定削減され、より大きな規模の開発もボトルネックなく回せるようになるといったことが例として考えられます。

一方で、それぞれの組織のフェーズや体制等に対して不相応な指標を導入したり、課題の解決にはあまり関係ない指標を導入してしまうと、効率性が高まるどころか日頃の活動の足かせになってしまったり、また、指標の測定ロジックが担当者にハックされて、数字は良くなったが本来解決したい問題の改善が全然進まないといった事態を招くこともありますので、留意する必要があります。

生産性が高い例③プロダクトへの愛着やチームの連帯感等に支えられて大変な時でも踏ん張れる

これまでにあげた2つの例のように、必ずしも明確な数値の改善などが見られない状態でも、プロダクトへの愛着、チームメンバの連帯感といった、チームの内側にあるモチベーション要因により、仮に事業環境などが非常に厳しい状況等においてもチームや個人に高いコミット力が発揮されている状態です。

これに関する動きとして、最近では多くの企業でミッション、ビジョン、バリューを掲げています。元々は、これらは自分たちがなすべき事業などの選択と集中の判断基準として有用でもありますし、企業に集まる仲間が結束して同じ方向に向かえるようにする効果も期待できます。これらに本当に共感・共鳴して集まったメンバは、自分たちのプロダクトが今後提供していく価値を想像しながら開発に打ち込み、成果が出る途中で思うように目標達成に向けた進捗が得られない状況でも結束し、仕事をやり切り、その結果としての成果を享受します。

この他の例として、オフィス出社を週3日以上にしたり、週5日にしている企業の例も見かけますが、これは単純接触効果によるメンバ間のつながりの醸成、チームメンバが集まることで生み出される熱量アップ（熱量のあるメンバから周囲のメンバへの熱量の伝播も含む）といった効果があると考えられ、成功体験という動機がない状況でも、チームとして成果を出せるようにするための有用なマネジメント方法の例であると私は思います。一方で、これはあくまで私見であり、これをMICINの組織に適用していくかどうか全く別の話です。

ちなみにMICINのエンジニア組織では、毎日の出社強制はしていませんが、月に一回オフラインで集まるEngineer Meetupを開催しており、その中で他のチームのプロダクトを触り合って理解を深めたり、過去に発生した各チームでのインシデントの原因などを共有しあったり、エンジニア以外の職種のクロストークを聞いて職種をまたがった相互理解を深めるなどしています。また、オンボーディングの一環として、新しくジョインしたメンバの歓迎会等もこの毎月のMeetupの場を活用して行なっています（関連記事：MICINでのエンジニア向け社内イベントの紹介　運営の小泉さん、野里さん、山崎さん、本当にありがとうございます）。こうした施策を通して、中長期的な目線でエンジニア組織の単純接触効果と相互理解の深まりによるメンバ間のつながりを強化していければと考えています。

最後は「やり切る」がものを言う

上記のような例を挙げましたが、こうしたチームにおいても、最終的には「やり切る」かどうかが重要だと考えています。例えば、80点以上が合格のテストで、80点と79点をとった人がいたとします。この場合、二人の点差は1点ですので、点数の分布ではすぐ隣の位置になり、スキルの成熟度としては79点の人も80点の人に準ずるものはあると判断されます。が、最終的な「合否」の評価については、片方は合格（やり切った）、片方は不合格（やりきれなかった）という形で明確に分かれます。

プロダクトにおいても、この一つ一つのちょっとした「合否」の積み重ねが、最終的にプロダクトが伸びていくか淘汰されていくかを分ける一つの要因になるのではと思うこともあります。もちろん要因はこれだけではなく、外部環境要因など沢山ありますが、私は重要な要因の一つだと思います。

「やり切る」といえば、MICINでは5つのバリューを掲げており、その1つに、最後まで粘り強くやり切るという「Persist」があります。この2024年は、年初の全社会で代表の原さんから「今年はPersistをMICINの全社的なテーマとします」というお話があり、これまで1年運営してきました。

MICINもそうですが、多くのスタートアップは、事業環境の変化に適応しながら非連続的な成長を遂げようとしますが、必ずしも体制や環境が十分でない状況、場合によっては圧倒的に不十分という状況で目標を達成しなければならないことも多いのではないでしょうか。こうした不十分な条件の中で、目標達成のために色々と工夫しながら、ここ一番の勝負時には心や体の健康を壊さない範囲ではありますがハードワークも厭わず期限内に求められていることをやり切ることで、ようやく事業の成長という成果を掴み取れるものなのかなと思う事もありました。

2025年に向けて

と、ここまで色々書いておきながらですが、私自身の一年を振り返ると、MICINが提供する各々のプロダクトの開発における課題の整理と本質的な解決策の提示と実行という今年のミッションについて、問題点の整理や重要と考えられるアクションアイテムの選定など進めてはいますが、主要なアクションアイテムのうち現時点で仕掛かり中（つまり未完了）のものもあり、やりきれていないなと猛省しています。ただ、年内はまだあと数日あるので、なんとか目標達成に持っていくべくラストスパートしたいと思います。

そして、2025年は、この自分の反省の弁を踏まえて、私個人もチームも目標に対してアドバンテージを作りながら安定的に目標達成させられるよう取り組んでいきたいです。

最後に

MICIN Advent Calender、2022年から取り組みが始まっていますが、今回も無事走り切れました。日々の開発や運用等の業務で多忙を極める中、本企画に投稿していただいたエンジニア、PdM、デザイナーの皆さん、執筆ありがとうございました！そして、運営面では、毎年この企画を全面的にリードし、特に今年は初日のアドベントカレンダー始めますの投稿も含めて対応いただいた阿部さん、Advent Calenderを会社の発信施策として位置付けていただき、会社の公式のNoteやX（旧Twitter）での日々の発信、記事のバナー作成といった運営に多大なご協力をいただいた広報の篠原さん、デザイナーの小橋さん、本当にありがとうございました！

今年も大変お世話になりました。皆さま良いお年をお迎えください。

2025年もMICINはより多くの方により良いサービスを提供すべく、全力で邁進していきます！

MICIN ではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！