こちらの記事はカケハシ Advent Calendar 2024の21日目の記事になります。

こんにちは、株式会社カケハシのエンジニアリングマネージャーの鳥越です。

本日は、今年の5月にデータサイエンティスト、機械学習エンジニア、ソフトウェアエンジニアの混成チームのエンジニアリングマネージャーとして入社した私の、半年間の取り組みについてのお話しをしていこうと思います。
「機械学習エンジニア」や「データサイエンティスト」は会社によって中身がだいぶ異なると言われますし、事業領域やフェーズ、その際に抱えている課題によっても異なると思いますので、あくまで1ケースとして受け止めて頂き、何かの参考になれば幸いです。

カケハシのDS / MLエンジニアチームについて

まず、チームの紹介からさせてください。カケハシは、シリーズCの社員数300名超の薬局SaaSを中心としたヘルスケアスタートアップです。私のチームはその中でも、業務委託を合わせて約20名程度と、現在のフェーズにしては、あるいは社員数全体に対する比率としても、比較的大きなチームなのではないかと思います。

取り組んでいる問題領域としては、医薬品のサプライチェーンマネジメント、患者さんと医療の関わりの効果的なサポート、フェーズとしてもリリース済みプロダクトの開発運用 (AI在庫管理)、プロダクト化前のトライアルフェーズ、パートナーと一緒に検討中のもの等々、これからのものから既に多くのお客様を抱えているものまで、様々なものを取り扱っています。また、後述しますが、最近では生成AIを活用した既存プロダクトのエンハンスメントも開始いたしました。

このチームのEMは、今年の5月まで、弊社CTOの湯前さんが兼務する形でEM職を担っていましたが、そのバトンを引き継ぐ形で入社しました。

機械学習エンジニアリングマネージャーとは

前置きが少し長くなりますが、エンジニアリングマネージャーと機械学習エンジニアリングマネージャーは何が違うのでしょうか。

共通点のほうが多い/多くあるべきだと思いますが、私見では一般的なエンジニアリングマネージャーとちょっと異なるポイントがあるとすれば、それはデータサイエンスや機械学習という汎用性が低い(しかしうまくはまれば高精度なアルゴリズムを書き下せたり、複雑さを秘匿できる) 技術を取り扱うチームのマネージャーであるため、少しでも技術が活きるようにするために、適用先への拘りが強いということです。どんなに高度で複雑な技術や沢山のデータを使っても、うまくいかないケースは多々あります。うまくいく確率を上げるために、PJ開始後はもちろん、PJそのものを立てるフェーズや事業部自体のビジネスの方向性まで、改善できる点があれば取り組めると良いと考えています。結果として、プロダクト/ビジネスドメイン知識をより深ぼるというわかりやすい行動から、チームが直接的/間接的に影響を受けたり与える事業部や会社全体の前提に対しての改善活動など、力のかけどころがすこし変わるのかなと思っています。

なお、生成AIは汎用性が高いではないか、という声が飛んできそうですが、プロダクトユースにおいては「汎用性の高さを活かす」こと自体が価値につながる適用先の見極めは難しく、適用先への拘りは必要だと感じています。

取り組んだこと

入社前

多くのチームメンバーとの面接

本件は、自ら取り組んだことではなく、取り組ませてもらったことですが、振り返ると非常に効果的だったと思います。「パラシュート人事」という、外から知らない怖い、えらい人が降ってくるというネガティブな文脈で使われる例が多い言葉があります。あえてその言葉に載って例えると、パラシュートを待つ側は何が降ってくるかわからず怖いですし、パラシュートで降り立つ側も何が待っているかわからず、不安なものです。

半数以上のメンバーと入社以前に面接/面談させて頂いたおかげで、チームの雰囲気や考えの理解が進み、不安が和らいだ状態で入社できたのはとても有り難かったです。CTOであり前任の湯前さんによる配慮だと思いますが、次回、私が受け入れ側になった場合は、同じようなことをしていきたいなと思っています。

本を読む

突然ですが、私の前職であるmerpayの元CTOのnozaqさんが書かれた「Fintechサービス開発を10倍楽しむ読書習慣」という記事が好きです。中身は、金融ネットワーク、業法やコンプライアンス、セキュリティ/システムリスクという一見するとこってりして難しそうな領域の話が並んでいますが、これらを並べつつ「幅広い専門領域が集まってはじめて開発・運営できることがFintechサービスに関わる醍醐味の一つ」と評する点にとても共感しますし、タイトルを「開発を10倍楽しむ」としている精神が最高です。弊社も歴史深く、法律が重要とされ、ミッションクリティカル性が高い業界を支援する企業であり、一見すると全然違う業界ではありますが、抽象的に捉えると共通項も多いなと思っています。そんなことを考えつつ、業界本、技術本等々を入社前にいろいろ読みました。これについては、地図を作るべく入社以降も続けています。

入社後

マネージャーとしてのREADMEを書く

何はともあれ、自分を知ってもらうところからスタートです。個人としての自己紹介はもちろんですが、マネージャーの考え方を知ってもらうために、マネージャーとしてのREADMEを書きました。内容的には、チームパフォーマンスの最大化という目標に対し、チームやメンバー個人とどのような形でアクションを行うか、その目的は何か、メンバーに意識して欲しいことを、書き下しています。一見わかりづらい、マネージャーの考え方や姿勢が伝える手段としてはもちろんですが、加えてこれからやっていくぞという自分の心の帯を締め直すような効用もあったりしました。おすすめです。

社内の人の話をしっかり聞く

社外の先輩 / 友人から話を聞くと、何はともあれ焦らず、話を聞けということだったので、まずたくさん話を聞きました。今数えたら、ピークは週31人、トータル70人くらいの方々と1か月以内にお話しさせていただきました。いろいろ脱線する会もありましたが、会社内の視界を広げるとともに、私のチームにどういう期待がかけられているのかを様々な角度から知りたかったため、以下のアジェンダで臨みました。

(話相手の) チームのミッション
直近の注力課題
私のチームへの期待、リクエスト

ありきたりではありますが、今の会社にどんな課題が広がっているのか、課題間の関係性と特に当事者から聞くことでその温度感が見えたことと、声掛けがしやすい関係性作りができたことが一番の資産かなと思います。一方、チームへの期待は、多くを得られず、なかなか初回から聞くのは難しかったかなーというところです。得られた期待は、チームに要約して還元したところ、喜んでもらえたのはよかったです。

プロダクト/事業を理解する (自社オンボーディング、薬局訪問、政策を読む)

弊社はtoBのマルチプロダクトを提供しており、自身がプロダクトのユーザーではありません。toCプロダクトの場合は、自身でよく使い、自身をヘビーユーザーにすることで理解度を深め、重要な細部の課題抽出や問題設定に活かすといったことをしていたのですが、それができず、どうしようかなと思っていました。幸い、会社や事業部で様々なオンボーディングプログラムが、驚きのボリュームで整備されているので、それらを活用しつつ、時にはお客様である薬局に訪問しヒアリングや利用状況の見学をさせていただきながら、業界、プロダクト、アーキテクチャ、市場理解を深めました。

その他、ヘルスケア領域は、政策が目指す方向性を理解することもとても重要だと思います。読書に比べて、なかなか取っ付きづらかったですが、省庁出身の社員にサポートをしてもらいつつ、原文書を読み、簡単にまとめて勉強会という形でシェアしました。その道うん10年の業界エキスパート社員にも参加頂き、勉強会というよりは指導会に近かったですが、おかげさまでリアルな状況含めた理解が深まり、少しだけ地図ができた感じがします。

チームパフォーマンス強化に向けた取り組み

入社1か月経過したあたりから、チーム内の幾つかの伸び代が見えてきました。経験から、なぜやるか？もさることながら、なぜそうなっているのか？といった過去の経緯や歴史が重要であったケースが多かったため、丁寧にメンターに確認しつつ、幾つかのアクションをしていきました。実施したものは以下のとおりです。

開発プロセスの見直し (sprint goalの厳密化など)
コミュニケーションパス整理、極力全ての公開化
NSM、KPI、精度指標、コスト構造の整理
事業部のOKR設定ルールと運用の見直し
PdMとデータサイエンティスト/エンジニアの責任分界点の変更

ちょっと変わったものとしては、最後の5.PdMとデータサイエンティスト/エンジニアの責任分界点の変更です。具体的にはPdMの分析や開発の現場関与を引き下げ（DSやMLEは引き上げ）を行いました。データサイエンス、機械学習関連プロジェクトは、通常のソフトウェア開発プロジェクトと比較すると、プロセスや不確実性が異なり、プロセス管理や調整に一定の技術的な理解や経験が求められるため、全てのPdMに求めることは中々難しいです。変更前にはたくさんの努力が注がれながらも、どうしても確認が多くなったり、認識ズレが起こったり、手戻りが発生したりと苦労やコミュニケーションが増えている状況がありました。採用や育成も手段としてはあったものの、短期的に解消する必要があったため、PdM責任者などに説明の上理解をしてもらいまして、上記整理と実行をしました。PdMとしては役割の変更による気持ち悪さ、エンジニアとしては責務が少し増えることにもなり一定のチャレンジもあり、受け入れてくれたメンバーに不安も多々あったかと思いますが、結果としては前よりスムーズになったとの声があり、ホッとしています。

また、4.事業部のOKR設定ルールと運用の見直しについては、もともとOKRの運用に課題意識がある事業責任者から声をかけていただき、OKR関連の著作もある同じくEMである小田中さんと一緒に進めさせてもらっています。私自身はしっかりとOKRを学んだことがなく、前職での現場経験のみの人間ですが、ほとんどのポイントで小田中さんと考えが同じで、スムーズに楽しく進めさせてもらっています。大まかには、KRの個数を選択し(絞り)、定量的に評価定義を行い、トラッキングは議論が起こるメンバーで実施する等により、一定の改善はできたのではないかとは思いますが、まだまだ発展途上の段階です。OKRというフレームワークと、エンタープライズビジネスの特性ですれ違うポイントがあると思っており、言語化できたら、また筆を取りたいなと思っています。

生成AI研究開発チームの設立

最後に、生成AIについてです。これまでも部分的に取り組みはしていたものの、ギアを上げた生成AI活用の機運が高まり、夏頃から生成AI専属の研究開発チームを立ち上げました。音声認識や自然言語処理を活用した、既存プロダクトのエンハンスメントなど、様々な仕込みを行っており、トライアルプロダクトであるAI薬歴機能を先日11月の日本薬局学会学術総会で共有させていただいています。来年以降も、業務のさらなる効率化、コミュニケーションの充実化などの文脈でいろいろなことをやっていこうと思っており、現在力を入れて取り組んでいるところです。

今後取り組みたいこと / さいごに

カケハシは薬局SaaSビジネスからスタートしましたが、現在はミッション達成に向けて、次の階段を登る様々なチャレンジをしているフェーズです。医薬品流通における社会課題の解決、患者さま医療体験の向上といった事業課題はもちろん、生成AIやデータ活用起点でのプロダクトアウトアプローチの模索、最近ではマルチプロダクトで抱えるデータ連携課題やDWHデータアーキテクチャにも利活用者として関わらせてもらっており、とても面白いフェーズだと思っています。いろいろと取り組みたいこともあり、エンジニアリングマネージャーを含む各種ポジションの募集をしておりますので、もしご興味がある方は、ぜひカジュアルにお話しをさせていただけると嬉しいです。