見出し画像

ドクターメイトの2年間の振り返りとこれからやりたいこと~プロダクト開発・チームの基礎作りからバトンタッチ、そして事業をテクノロジーで押し進める役割へ~

※この記事は、ドクターメイト Advent Calendar 2023 17日目の記事です。

昨日のあやかさんの記事はこちら!情報収集のコツ、参考になりますね!

というわけで今回は、ちょうど自分にとって節目の良いタイミングなので「ドクターメイトに入社してから2年間でやったことの振り返りとこれからやりたいこと」についてまとめてみようと思います!

  • 2022年1月に入社して今月末で丸2年になります

  • 今月から新設されたBizOpsグループに異動となりました

    • 入社以来所属していたプロダクト開発グループから離れました


TL;DR(要約)

好きに書いて良いとの事だったので好きに書いていたらえらく長くなってしまいましたので全体の要約です笑(12,000文字越え)

入社からの2年間で仲間に助けてもらいながらも色々と爪痕を残すことができました!

  • 自動テストの文化を浸透させてドクターメイトを品質を保ちながらアジリティの高いプロダクト開発ができる会社にしました!

  • 日中医療相談アプリを実証フェーズから導入拡大へ口火を切って取り進め全ての契約施設様にアプリ利用してもらう状態にしました!

  • 社内初の本格的にチーム開発を行う医療相談ユニットを立ち上げて社内の礎にできるプロダクト開発チームに育てることができて後進へバトンタッチ、ドクターメイトを持続可能なプロダクト開発ができる会社にしました!

  • オンライン診療ユニットを立ち上げて新規事業サービスを全ての契約施設様が実際に使って価値検証していけるようにしました!

  • サイドプロジェクトでデータ基盤を構築、技術基盤ユニットを立ち上げてデータ基盤を全社的な利活用もセットの意味のある基盤にして今後の展開に繋げられました!

2023年12月からの今後は新設のBizOpsグループへ異動し技術基盤ユニットから引き続き利活用とセットのデータ基盤の構築を行います!

  • 7期(2023年12月から)の会社全体のテーマは「顧客価値」、これが分かる・活かせる・司令塔になれるデータ基盤に育てて介護の世界をよりよくするためにドクターメイトをさらに飛躍させていきます!

  • それからBizOpsではデータのみならずツール活用や業務改善なども範疇になってきます。どうせならBizだけに限ることなくドクターメイト全体をテクノロジーの力も併せて全体最適に業務効率化していきます!

仲間も絶賛大募集中です!

要約は以上です。以下から詳細ですがだいぶ長めですのでご興味あればお読みくださいませ笑

ざっくり2年間でどんなことをやったのか?

まとめてみました。色々やりましたねー

ドクターメイトでの2年間の歩み(ざっくり)

ここからは印象に残っている3つのことを振り返ってみたいと思います!

やったこと1:テスト自動化のためのテスタブル化とアーキテクチャ改善、CICDなど

まず2022年1月に入社してからやりだしたこれ。アプリ開発を行っていた日中医療相談サービスに対して行いました。
アジリティの高いプロダクト開発を行うにあたってはプロダクトの頻繁な変化に対応できる必要があります。その際に基本として重要になってくるのが「安心して開発するためのガードレールとなるCICD+テスト」。ドクターメイトにきちんとした自動テストの文化を浸透できたのは大きいと思っています。おかげで今も安定した品質を維持しながらプロダクトの進化をどんどんできています!
不具合が多発して顧客に迷惑をかけるようなことがあったら良くないですからね。

上のスライド資料にも書いてますがオニオンアーキテクチャ+DDDスタイルの導入もしました。こちらは目的としてはDDDをしたい!というよりはテストを書きやすくするためでした。プログラムに何らかの構造がないとテスト書きづらいですからね。(指針となるものであれば構造は何でも良かった)

ちなみに脱線。この時はDDD化したロジックをnpmパッケージ化してクライアントサイド(ネイティブアプリとWebアプリ)で動作する構成はそのままにしました。開発メンバーにはなぜ当時API化してロジックをサーバーサイドへ移すことまでしなかったのですか?と良く聞かれますが単純に工数がなかったためだけです笑

  • まずはテスタブル化が目的だったのでモジュール化にフォーカスしてその他の対応は清く捨てました

    • 理想の状態を目指しつつも現実ラインを見極めて手戻りを恐れず目的志向で進めることが大事だと思っています

  • 当時の状況だと対応工数や運用工数など含めて考えたらAPI化しない判断に間違いはなかったと思います

    • 工数が許せば自分もアーキテクチャ的にはAPI化したかったです

  • 冷蔵庫にある食材をベースに工夫して美味しい料理を作っていくスタイル

    • 次にもっと美味しい料理を作れるようにするための改善点も考慮しながら

この辺り、自分の手を離れた今はAPI化やRust化などだいぶ変わっていってます。その時々の状況・チームメンバーによって最適な状態にしていく方がうまくいくのでドクターメイトではガンガン変えていくことを推奨してます!(自分も変えていくことに賛成です)

この時期にした座談会が記事になってますねー(感謝)

やったこと2:日中医療相談アプリを実証からプロダクトへ、Chatwork相談利用の介護施設様への導入拡大

そして2022年7月ごろからやりだしたこちら。
日中医療相談サービスは元々、Chatworkでの相談として提供していました。これを開発中のアプリへ切り替え、新規契約施設様へは最初からアプリ導入にするなどを口火を切ってCSの方々と協力して行いました。ここから本格的なアプリの利用が始まった!!
(この時期までアプリは協力施設様2施設に限定して実証での利用をお願いする形で開発を進めていました。)

  • この当時、自分は実証期間が思った以上に長引いていて我慢できなくなっていてより多くの施設様に使ってもらってフィードバックをもらいながら検証・開発したいと騒いでいたことを覚えています笑

    • それが功を奏したのか?導入拡大の方針になりました笑

  • 実際に導入拡大を考えたときには色々とハードルもありました・・・

    • その1つが既に入居済みの施設利用者様の情報登録で科学的介護情報システム(LIFE)とのデータ連携に対応したりもしました

      • Webアプリ版を作ったのも確かこの流れだったと思います

  • その他、CSと連携させてもらったのもこの辺りから!

    • CS向けにプロダクトの説明、CSと施設導入マニュアル作成プロジェクト、施設導入訪問同行、etc

      • 導入直前に動かない不具合が色々見つかってエクストリーム修正しまくったりもしたなー、あれは焦ったけど懐かしい

      • 前職でプロダクトマネージャー(以下、PdM)していた時の経験と重なってこの辺は楽しかった

    • 日々施設様とのやりとりをして顧客価値を提供してくれているCSには感謝

この時期にしていただいたインタビューが記事になってますねー(感謝)

やったこと3:プロダクト開発チーム作りとバトンタッチ、新規事業や技術(とデータ)基盤との掛け持ち

最後は2022年11月からやりだしたこちら。
ついにここからドクターメイトで初となるプロダクト開発チームの組織化複数ユニット(ドクターメイトではチームをユニットと呼んでいます)の立ち上げからリードを任せていただきました。初とかゼロイチとかって痺れますね。

簡単なあらましをざっと

まず2022年11月からの体制がこちら!

2022年11月から12月末までの体制

ここで医療相談ユニットを立ち上げてリードになりました。このユニットは、それまで開発者全員で対応していた医療相談アプリの開発をちゃんとチーム化しようというコンセプト。ちなみに既存メンバーは自分のみで他4名はチーム結成前後に入社されたばかりの方々でした(入社直後から皆さんありがとうございましたmm)
そしてデータ基盤etcという別枠にも自分の名前が!?こちらは2022年5月くらいから自分が構築を進めていたデータ基盤のタスクなどをこなすため掛け持ちになりました。こちらは業務委託で手伝っていただいている方と2名体制。(データエンジニアリングもできるぞ、わーい)
あとリード不在のオンライン診療ユニットという謎のユニットが気になるけど(お楽しみ、これは伏線です

そして2023年1月からの体制がこちら!


2023年1月から3月末までの体制

なんとここでオンライン診療ユニットのリードにもなりました。ついに3人に多重影分身やばいですね。(さっきの伏線回収done)
オンライン診療サービスは新規事業のPoCとしてまずは価値検証しようぜということでノーコード主体でライトに進めるとして本格開発が始まるまでは1人ユニット!!(CSやセールスや医療などとの部署横断プロジェクトなので1人で全て実施という訳ではありませんが)

2023年4月からは体制に一応PdMもいますよと明示された。(それまでもPdM対応はしていただいておりましたが)

2023年4月から6月末までの体制

最後に2023年7月からの体制がこちら!

2023年7月から11月末までの体制

ようやくここでコミュニケーションパスが多くかなりの割合を占めていた医療相談ユニットからは退きました後進にうまくリードをバトンタッチできてよかったー(引き受けていただいてありがとうございましたー)
かわりに技術基盤ユニットを立ち上げてリードになりました。これはデータ基盤etcであった枠にユニット横串での技術支援を足してチーム化しようというコンセプト。チームが増えて横串で見るチームがあった方が良いとの判断。当初はTeam Topologiesのイネイブルメントチームをイメージしていたけどデータ基盤も責務に含むので技術基盤ユニットというあえてフワッとした名称にしました笑

ざっとはこんな感じでした。
これも3つに分けて振り返ってみたいと思います!

トピック1:日中医療相談アプリ開発のチーム化と後進へバトンタッチ

まずは2022年11月から2023年6月末までのこれ。
ここでのミッションは「ドクターメイトの今後のチーム開発のリファレンスとなるプロダクト開発チームを作ること、開発は止めない、自分がいなくてもプロダクト開発が機能する状態にしてできるだけ早く自分から後進へバトンタッチすること」とだいぶチャレンジングなものでした。

  • ドクターメイトの今後のチーム開発のリファレンスとなるプロダクト開発チームを作る

    • 会社初のプロダクトアジャイル開発チーム

      • 今後、開発チームを増やしていく時にコピー元にできるチームにしたい

        • 社内に参考にできるチームがあると今後の組織拡大が楽になる

      • それまでの開発はだいぶゆるくスクラムぽくやっていただけでそれぞれが思い思いに動くスタイルのチーム開発ぽくない感じだったのでチーム開発を根付かせたい

        • 1人親方の集まりからチーム開発へ

      • 同時期に立ち上がった夜間オンコールユニットはまだ1人チームだったのでチーム開発はしばらくあとのお話

  • 開発は止めない

    • 医療相談アプリの導入・利用が拡大していくタイミングでもあり対応待ちのバックログも多数ある状態

  • 自分がいなくてもプロダクト開発が機能する状態にしてできるだけ早く自分から後進へバトンタッチする

    • 自分や誰かに依存している状態ではたとえ成果を出せていてもチーム開発とは言えない

    • この時点で自分はデータ基盤だけでなくオンライン診療ユニットも掛け持ちで受け持つ事が決まっていて自分のキャパを大幅に超える事は明白だったので自分からできるだけ早く手放せないとそもそも現実的に無茶な状況だった・・・

当時は、前職で開発責任者として採用や初期構築やチーム立ち上げなどのゼロから半年ほどかけて機能するチームを作った事があったので何とかできるとは思っていましたが、「短期間」で「色々掛け持ち」しながら「未知のチームメンバー」と「あまり詳しくない既存の開発」を取り持って「動いているサービスを壊さず止めずむしろ改善」しながら「正解」にしていく必要があり本当にチャレンジングな始まりだったのでどのような着地になるかは全くイメージできていなかったことを覚えています笑

  • 自分の経験上、ちゃんと機能するアジャイル開発チームをゼロから作るには半年〜は欲しいところ

    • チームは生き物、人間関係・信頼関係もある中で各メンバーがチームになっていくためには丁寧に時間をかけた方が良いと思っています

      • アジャイル開発はウォーターフォール開発などと比べても特に繊細で壊れやすいと思っているので丁寧に進めたい

        • 開発者目線だとよくあるなんちゃってアジャイルでやるとすぐ破綻するイメージ

    • チームは育てていくもの

    • 自分がいなくても機能させるということを考えるとさらに難易度はあがる

  • チーム立ち上げ時、チームメンバー4名は全員がほぼ初めましての状態で入社直後のこれからOBDのメンバーもいて自分も各メンバーにお会いするのが初めての状態からだった

    • 自分はそれまで採用に絡んでなかったので事前にお会いしておらずメンバーがどんな方々かも知らない状態・・・

    • 入社OBDも同時にやらなければならない

      • 住んでいる場所も各々バラバラなので全てリモートです

        • 半分は関東以外の方

  • チームメンバー皆さん、本格的なチーム開発やアジャイル開発は経験が浅くこれからキャッチアップしていくぜ!な方々ばかりだった

    • 技術面は大丈夫そうとは聞いている(全然大丈夫でしたが!)けど開発の進め方どうしようかな・・・

    • チーム運営を丁寧にして空中分解しないようにしたいな・・・

  • それまでプロダクトバックログの管理など開発を回す部分は別の開発者が対応していて自分は裏方対応がメイン、唯一の既存メンバーの自分がプロダクト面を把握し切れていなかった(サボってました、すみません

    • 頼りきりだったので自分自身がよくわかっていない状態でした笑

    • そもそも自分はそんなにスクラムくわしくないし

      • どちらかというとスクラムより経験もあるエクストリームプログラミングの方が好き笑

    • よくわからない不具合や積み残しがたくさん残っている状態だったのもしんどみがあった・・・

  • 掛け持ちによる自身のキャバ不足

    • 言わずもがななので(略)

等々等々ありましたが無事にミッション達成!半年という短期間で軌道に乗せて後進にバトンタッチして自分は退く事ができました!頑張ってくれたメンバーの皆さんには本当感謝!このチームは今でもドクターメイトのメインの開発チームとしてプロダクト開発に貢献してくれています!

  • とにかくアジャイルなチーム開発の型に慣れていだだくよう進めました

    • みなさんこの観点ではこれから経験を積む感じだったので・・・

    • 持論ですがアジャイルなチーム開発って理屈が分かっていればできるものでもないと思います

      • すでにきちんとできている環境に身を置いてこういうものなんだと体験することが一番手っ取り早いです

      • 基本ですがスプリント単位でゴールを決めて毎日DailyScrum(以下、DS)で顔合わせ・困ってることの即解決・レトロで振り返ってプランニングし次のスプリントへ進める開発のリズムとかとか

    • 自分は前職でアジャイルな原則に沿ったプロダクトチーム開発の経験があったのでそれらしいフローを整えて進めました

      • ただしとにかく時間がない。。なので既にあった開発スタイルからは劇的に変えずにアジャイルの原則をできるだけ取り入れたハリボテでしたが

        • スクラムも変えなかった

      • 近い未来に自分がいなくなることも考えると何でも良いので守破離できる開発の型・リズム・ガードレールを用意してからバトンタッチするのが良いと思っていた

        • 細かいところはあとからチームで変えていければ良い

  • モブプロ・ペアプロ主体の進め方にしました

    • 少しモブプロをした経験のあるメンバーがやりたいと提案してくれたので乗っかりました笑

      • 助かりました!これがなければ短時間でのチーム化は不可能だったと思います笑

    • 前職で1年ほどペアプロのみの生活(リモート・英語のみでしたが)を経験していたのでモブプロ・ペアプロのメリデメは理解していたのでやりやすかった

      • チームがコミュニケーションを日常的にしてお互いフォローし合う体制になるので開発者視点だけでなくマネジメント視点でも少し楽ができるメリットがあります

      • ちなみに自分は開発者としてはペアプロに向いていないタイプ(できるけどそこまで得意でない、自分のペースで考えをまとめる時間を取りたくなるタイプ)です。向き不向きのある開発手法ですが今回のチームにはあっていたようです。良かった!チームにあった方法にすることが大事。

    • 実際、入社OBDや情報共有などの面で良いことが多かったです

      • 最初の方は自分も開発者としてモブプロ・ペアプロに参加して色々な共有がやりやすかった

      • 離れた後も必要な時はモブプロ・ペアプロに入って情報キャッチアップしやすかった

  • 小さな失敗で済む変化は積極的に、フィードバックを拾って改善の繰り返し(OODA的な)

    • 開発フローはチームやメンバーの特性にあわせてやりやすいように改善・最適化していきました

      • とにかくみんなのフィードバックを拾うことを意識しました

        • 自分1人で分かることには限界があるのでみんなの目を借りる

        • DS、モブ・ペアセッション中、リファインメント、プランニング、プロダクト会、レトロ、1 on 1、不定期の雑談会、etc

        • リモートだったりもしたので空気を軽くして発言しやすくなるようにかなり賑やかし・meetリアクション芸人に徹しさせていただきました笑

          • ※※※普段はだいぶ寡黙で真面目な人間です※※※

      • あとは各メンバーのことを知るため交流やチームビルディングも兼ねて「開発バックグラウンドを紹介しあう社内LT大会」を開催してみたり

        • みんなの得意領域や興味ある分野やキャラクターなど知れて面白かった

        • oVice開催にしてプロダクト外からも観客としてガヤを入れてもらったりと楽しみました

    • 何かあってもDSでフィードバックを得られて1日以内には小さな失敗として解決できるので積極的にいろいろやってみてチームに適度な揺さぶりを加えてみたり

      • なのでフィードバックは大事

    • とにかくフィードバックもらって改善に努めてみんなにあったフローに最適化していきました!

  • 全員リーダー体制!と宣言してみた

    • 自分が体制上のリーダーという役割ではありましたがリードはみんながやるものと思っているので

    • 近い未来に自分がいなくなることも考えると自分がいない体制で回る必要があるのでみんなに諸々移譲しつつ自分は徐々にスクラムイベントのみの最低限の関わりにフェードアウトしていきました

      • 最初はモブプロに参加しつつ一緒にハンズオンで進めていましたが途中から少しずつ自分は極力手を動かさなくしていきました

      • もちろん体制上の役割としてのリードは自分なので説明責任・何かあった時には自分が対応する覚悟が持てるラインを見極めながら徐々に離れるようにしましたが

        • 手は動かしてなかったですが何もしてなかった訳ではないすよ笑

        • とはいえ特に何も問題になることなく回りました。みんなの頑張りには本当に感謝!

  • みんなの頑張りもありコンスタントに機能を出していけるプロダクト開発チームになりました!

    • 目につくクリティカルな不具合は全て潰せた!

    • ステージングやテスト環境など開発環境を整えられた!

    • Webアプリの正式版もリリースできた!

    • コンスタントな施策の対応もできた!

    • 念願のQAフローも組み込めた!

  • 無事メンバーに任せられると確信できる状態にもなり(あと自分の大幅なキャパオーバーにより本格的に回らなくなってギブアップ寸前なのもあり・・・)めでたくバトンタッチ!

    • 最後の1ヶ月はスクラムイベントも全く参加せず問題なさそうという感じなのを見届けて正式にバトンタッチ

    • あとはよろしくお願いします〜

    • このチームは今でもドクターメイトのメインの開発チームとしてプロダクト開発に貢献してくれています!

      • 現在は施設アプリ開発ユニットとチーム名が変わった

  • この時期の心残りは、あまり顧客に突き詰めた向き合い方ができなかったこと。プロダクト面はPdMに頼り開発チームに向き合った半年でした

この振り返りのためにnotionを漁ったら懐かしい当時の「開発の流れ(wip)」を発見しました、手作り感満載ですね笑
永遠のwip(Work In Progress)としてフローを変えるときは都度更新してました。(今はここから変わっているはず)

懐かしの開発の流れ(wip)、永遠のwip
開発の流れ(wip)詳細バージョン

あとチーム運営していて嬉しかったことをもう1つ。ドクターメイトでは定期的に社員のエンゲージ(帰属意識・愛着)を定量的に計測しているのですが、この時期にプロダクト開発グループの職場推奨度がチーム結成前よりも大きく伸びました。プロダクト開発グループの半数以上が医療相談ユニット所属だったので満足してもらえてるのかなと思い嬉しかったです!

職場推奨度が爆上がり!

ここに関連するエンジニア座談会が記事になってますねー(感謝)

トピック2:新規事業オンライン診療サポートの検証と開発

次は2023年1月からのこれ。
オンライン診療ユニットのミッションは「オンライン診療サービスPoCのオペレーションフローの確立と価値検証、本格開発への道筋をつけること、可能ならここも後進へバトンタッチする」でした。

途中、PdM+開発対応を自分1人で行う困難な感じになりましたが色々な人の協力のおかげで施設様導入や価値検証を無事に行うところまでできました
自分のBizOpsへの異動に伴って2023年11月末でオンライン診療ユニットは廃止になりました。以降は他の方へバトンタッチ予定ですが実は引き継げず異動後の今も自分が対応やってます笑(体制が整ったらプロダクト開発グループへ引き継ぐ予定)

  1. できるだけ工数をかけずノーコード主体で構築してユーザーに使ってもらいフィードバックを得たい

  2. 最初に当時のPdMが即席でGoogleフォーム+スプレッドシート+BigQuery(以下、BQ)でMVP(Minimum Viable Product)を作成してくれました!(感謝)

    1. これでええやんとなる

      1. これでしばらく検証を実施しました

    2. ここでMVPもあるしということでPdMがプロジェクトから離れてPdM的な対応も自分がすることに!?

      1. 自分も前職でPdMはしていたので対応は可能です、時間さえあれば・・・

    3. しかしこのMVPではオペレーションが耐えられなくなってきてどうしようとなる

  3. MVPの次の段階はだいぶ難航

    1. 自分が医療相談ユニットなどとの兼務で手が付けられない状態にしばらく陥ってました・・・

    2. 医療相談ユニットを手放した2023年7月ごろからキャッチアップも兼ねた要件定義などをようやく開始

  4. 途中でオンライン診療プロジェクト体制変更、途中交代でジョインしてきた事業オーナー(kintoneやGASの魔術師!)が超速でkintoneとじぶんページでプロトタイプを構築してくれました!(感謝)

    1. これでええやんとなる

    2. 2023年9月ごろのこと

  5. 事業オーナーと2人3脚でkintoneとトヨクモ(問題がありじぶんページから変更)+GASでの新MVPを構築しました

    1. 事業オーナーのプロトタイプ提案に乗っかりました笑

    2. 2023年10月ごろからはこちらに切り替えて仮説検証を継続実施中

    3. 利用も順調に拡大中!

トピック3:技術(データ)基盤の整備

最後はこれ。データ基盤の対応は2022年5月から、技術基盤ユニットが2023年7月からになります。
技術基盤ユニットのミッションは3つありました。

  • データ基盤を整えて全社での利活用に広げる

    • 2022年5月ごろからプロダクトの利用状況をモニタリングするためにそれまで自分が半ば片手間で内職のようにBQで構築保守していたデータ基盤を全社で活用するようにしていきたい

  • QAフローを医療相談ユニット以外にも組み込む

    • ユニット横串の第1弾として医療相談ユニットと同じように他のユニットにもQAフローを組み込んで品質の底上げをしたい

  • ユニット横串での技術支援を行う

    • ストリームアラインドに集中しているユニットのために横断・全体最適の視点で連携による底上げができることは何でもしたい

データ基盤は全社での利活用につなげられるところまで持っていけました!あとは実際に全社で使い倒していくのみ!

  • 元々、医療相談アプリの利用状況をモニタリングするためにFirestoreのデータをBQへストリーム同期して利用していました

    • SQLやスプレッドシートのコネクテッドシートで利用

  • データソースを増やすためにtroccoを導入しkintoneや教育サービスのAWSデータも扱えるようにしました

  • BQをレイヤ分け(データレイク層、データウェアハウス層、データマート層)するなど利用拡大を見据えた設計を行いました

    • 業務委託で手伝っていただいている方がデータ管理に強くてほぼ助けていただきました(超感謝)

    • ワークフローはDataform、SQLもGitHub管理の構成

  • 併せて利活用につなぐ取り組みも行いました

    • 利用されないデータ基盤は電気代がかかるだけのただの箱、意味のある基盤にするためには利活用とセットが超重要

    • CSのCSOpsユニットと連携してデータ基盤から取り出した指標をLooker Studioを用いてダッシュボードにして可視化していきました

    • 経営も巻き込んで全社に対して事業分析ユースケースをヒアリングして全社に利活用ニーズがあることが確認できました

2023年7月ごろに描いた全社データマート構想に向けた落書きは実現に向けてまだまだがんばっているところです。(内容に少し変わっている部分があるのでアップデートしないとなぁ)

だいぶ前に描いた全社データマート構想に向けた雑な落書き(wip)

QAフローについては夜間オンコールユニットとオンライン診療ユニットの開発フローにも組み込めました!サービスの品質が盤石な体制になりました!
QAの方が自律的に動いてくれたおかげなので自分はほぼノータッチ(感謝)

ユニット横串の技術支援で唯一やれたのは夜間オンコールサービスと医療相談サービスの連携アーキテクチャ方針提案。いくつかアーキテクチャ候補出してメリデメ評価の結果からできるだけ疎にできるPub/Subでの連携を提案させていただきました。
方針提案だけして実際の具体的な中身の対応については各ユニットで動いてくれました(感謝)

提案したサービス間の連携アーキテクチャ方針(提案部分を抜粋)

ちなみに自分のBizOpsへの異動に伴って2023年11月末で技術基盤ユニットは廃止になりました。データ基盤のミッションは異動先のBizOpsに移管されることになりました。

まとめると

  • 色々とやってやったぜ!

    • 社内初の本格的にチーム開発を行う医療相談ユニットを立ち上げて社内の礎にできるプロダクト開発チームに育てることができて後進へバトンタッチできたぜ!

      • 持続可能なプロダクト開発をできるようにしてやったぜ!

    • オンライン診療ユニットを立ち上げて新規事業サービスを全ての契約施設様が実際に使って価値検証していけるようにできたぜ!

      • 後進へのバトンタッチにも目処をつけることができたぜ!

    • 技術基盤ユニットを立ち上げてデータ基盤を全社的な利活用もセットの意味のある基盤にして今後の展開に繋げられたぜ!

  • プレイングマネージャーの兼務・掛け持ちは持続的ではないことを知る(余白が重要!)

    • 頭の切り替えコスト、それぞれに振り分けられる自分の時間などを考えると限界を超えた掛け持ちは非効率であることを実体験として感じました

      • 頭の切り替えコストは加齢とともに年々上がってきているのを感じているのでこれからは自分がさばけるレベルに保っていきたいなと思いました

    • 今回は常にキャパ越えでいっぱいいっぱいだったのでそれぞれの対応も結局は今までの貯金の取り崩しでそれらしい対応ができていただけと思います

      • とにかく最低限の抑えるべきところの帳尻を合わせる事だけに必死な日々でした笑

      • 新しいことを吸収したり考えたりするための余力を持てなかった

      • 余白なく開発のhow寄りな部分が主だったので短期思考に陥りがち、whyや顧客のことを考えるために頭を切り替えることが少々困難でした

        • 顧客のことをもっと深く考えたい!

    • 自分の強みは瞬発力よりも持久力だと思っています

      • 深く考えて中長期目線で全体最適に全体構想を考えてアクションしていくこともしていけるほうが力を発揮できると思います

    • 今後はもっと余白を作っていこうと思いました!

これから:そしてBizOpsグループへ

2023年12月から現在は新設のBizOpsグループへ異動になりました。
(元々ドクターメイトにはプロダクト開発・マネジメントをしたくて入社したので異動は寝耳に水でしたが)
自分が異動になったのはBizOpsグループがそれまであった3部署(セールスの事業企画、CSのCSOps、プロダクトの技術基盤の主にデータ基盤部分)が統合してできたためと思います。

BizOpsグループはマーケ、SMB(セールス・CS)、ENP(セールス・CS)などBizとともにOpsとして伴奏するグループです。

BizOpsはBizを支え伴奏するグループ

BizOpsグループの詳細は立石さんの記事がわかりやすいです。

自分の直近のミッションは技術基盤ユニットから引き続き利活用とセットのデータ基盤の構築です。
7期(2023年12月から)の会社全体のテーマは「顧客価値」、これが分かる・活かせる・司令塔になれるデータ基盤に育てて介護の世界をよりよくするためにドクターメイトをさらに飛躍させていきます!(AIにデータ基盤を食わせるとかもやりたいですね)
それからBizOpsではデータのみならずツール活用や業務改善なども範疇になってきます。どうせならBizだけに限ることなくドクターメイト全体をテクノロジーの力も併せて全体最適に業務効率化していきます!

We are hiring!

まだまだやれることはたくさんあります!
ドクターメイトでは一緒に持続可能な介護の実現に取り組んでいただける仲間を募集中です!
カジュアル面談などもしてますのでお気軽にお声がけくださいませー

BizOpsも絶賛募集中です!


この記事が気に入ったらサポートをしてみませんか?