YOJOのエンジニア組織を全部見せます

開発のbonです。
前回Herokuを使ったサーバー(サービス)構成についてすべて語り尽くしましたが、今回は謎のベールに包まれているYOJOエンジニア組織について色々書いていきたいと思います。

YOJO Technologiesは名前に「Technologies」がついているくらいはエンジニアファーストな会社です。弊社CTO上野さんがこちらのnote記事でお伝えしているとおり、エンジニアリングの力で患者と医療者を滑らかにつなげることを弊社は目的としています。ですが、弊社に興味を持っていただいた方に「開発組織ってどんな感じなんですか？」という質問を何件かいただいており、弊社のアピールがまだまだ足りていない反省として今回の記事を書くに至りました。

エンジニア組織図

弊社のエンジニア組織を図示すると以下のような感じです。バックエンドのマネージャー・メンバー以外は業務委託の方で成り立っています。業務委託いただいているメンバーも、フルタイムとそうでないメンバーに分かれており、バックエンド1名、フロントエンド1名、BI(データ分析、データアナリストチーム)は1名がフルタイムです。

エンジニア組織の図

ザックリ説明すると組織としてはCTO管轄である「組織軸」と、PdM管轄である「事業軸」の2軸です。
組織軸の方にはすべてのエンジニア(14名)が所属していますが、事業軸は事業に応じて関わるメンバーが変わります。例えばBackendからは2名、Frontendから2名、BIから1名……というような感じです。

現在弊社で注力しているの事業としては漢方・サプリ事業というものがあり、新規事業の検討・検証以外ではこの事業に集中しているため事業軸は1つのみです。
ちなみに採用はどっちの事業でもやっているので0→1がやりたいんだ！とかプロダクトグロースに興味があるんだ！みたいな想いはどんどんぶつけてください。

開発体制

一部メンバーはフルリモートでの勤務を行っています。ちなみに都道府県分布だと甲信越1名、九州1名、関西1名、関東11名という感じです。朝10時の全社ミーティングに参加したあとは基本フレックスタイム制での勤務が可能です。副業も相談の上可能です。

実際のシステム開発においては上述したそれぞれのチームが連携して開発をしています。弊社ではスクラムを用いており、2022/2現在ではエンジニア組織においてはエンジニア組織全体のスクラムとBIチームのスクラムの2つが存在しています。スクラムは1週間スプリントで実施しており、毎週金曜日が締日となっています。そのため木曜日にスプリントレビューを実施、金曜日の午後にスプリントレトロスペクティブとスプリントプランニングを実施しています。

また、タスク管理にはJira Cloudを利用しており、バックログ整理や課題分割などは木曜日にリファインメントを実施しています。Jira Cloudのライセンスについてはリッチなロードマップを使うためにプレミアプランを契約しています。Jiraの課題はGithubのブランチ名と連動させることで課題から実装した内容を追えるようにしています。

Jira Cloudの課題画面

これ以外にもリリースブランチとJiraのリリース課題を手動連携させることで、リリース単位でどういうリリースがあったか、どのようなリリースをいつ行ったかを追えるようにしています。

開発の生産性についてはFour keysでもいいのですが、一旦今のところはバーンダウンチャートで消化できたSP(ストーリーポイント)をメインで見ています。

開発チームの特徴

YOJOのエンジニア組織はフルサイクルエンジニアを目指しています。フルサイクルエンジニアについてはリンクを参照いただけると詳細について記載がありますので、ここでは簡単に要件定義〜運用までできるエンジニアということのみをご説明します。

弊社の(僕以外の)エンジニアメンバー、マネージャーは基本的に弊社の患者コミュニケーション管理システムの機能追加や改修に至るまでの要件抽出や企画立案、根拠となるデータ集めや患者インタビュー(ユーザーインタビュー)などを行っています。これはフルサイクルエンジニアのうちの「要件」の部分になります。

また、弊社はSRE/インフラエンジニアがまだいないため、不具合時の対応や各種サービスのパフォーマンスダウンやエラー検知、アラート検知などの対応も弊社のエンジニアメンバーがやってます。(僕は要件をやらない分こっちをガッツリ見てます)
前回の記事でご紹介したHerokuのあれこれとカスタマイズしたりアラート設定したりログ追ったりするのもエンジニアメンバーです。これがフルサイクルエンジニアのうちの「運用」の部分になります。こちらは日替わりで担当するエンジニアを代えて対応しています。

こんな感じで、スタートアップあるあるだとは思いますが少ないメンバーで多くの役割を兼任しつつ様々なプロダクトの開発フェーズに関わりつつ、他部署や他社との打ち合わせなどを通して責任・決定権を行使しながら成長することができるのが弊社エンジニア組織の特徴です。逆に言えばそこら中にやることもやれることも放置されていることも転がっているので、自分からボールを拾いに行き誰かにパスするくらいの行動力は求められるとも言えるかなと個人的には思います。

その他取り組み

上述している以外にも弊社のエンジニア組織として様々な取り組みを行っています。

1. データ分析やKPIをみんなで見る会
毎朝その日の担当者が気になる統計やKPIのデータをピックアップしてもらい、それについて共有・議論する場です。例えば「先週の売上向上施策はA/Bテストの結果、効果があるとXXのグラフから判断できそうなので、今週中には全ユーザーに展開します」みたいなことです。まれにデータ異常に気づけることもあるのと、足りないデータは自分達で作ってしまおうという議論にも発展することがあります。

2. BI勉強会
データ分析をしようとしたとき、欲しいデータが存在ないこともあります。そういうときはBIチームに依頼することもありますが、定期的に他のエンジニアも自らデータ分析を行うことがあります。弊社ではBigQueryにデータを集約しているデータ基盤があるため、それをベースにSQLを書いたりGoogle Data Studioで結合したりして良い感じのデータをつくります。データそのものの収集が存在しない場合は、エンジニアがBigQuery上に新規でテーブルを作ることもあります。このときはBIチームにレビューを依頼します。

3. 読書会/勉強会
誰かが気になった本を持ち込み、読書します。1時間という短い時間の中でなるべく速読し、気になったポイントだけをかいつまんで議論するという仕組みにすることで時短かつ効率的に各メンバーの着眼点を共有できるため、効率よく学びが深いです。
勉強会では誰かの持ってきたネタをベースに公演形式で話を聴きます。弊社では薬剤師の方も勤務しているため、漢方や健康などの勉強会にも参加することができます。技術ネタの勉強会があまりないのでエンジニア主導でもっとやっていきたいなと個人的には感じています。

4. 開発合宿
月に1度くらいの頻度でエンジニア組織のメンバーだけで1、2日集まり、さまざまな課題やワークショップをします。最近では新規事業の戦略説明や、価値観・行動指針を明文化したり将来の目標をお互いに語り合ったりしました。なかなか時間が取れずに後手に回っていた改修や改善を1日かけてガッツリするというようなハッカソンぽいこともやりました。

5. ウィンセッション/ポストモーテム
ウィンセッションは全社で月に1度やっている「自分達が当月にやった成果」を発表する会です。エンジニアチームは大体はリリースした機能やプロダクト全体の改善とかをシェアしています。他部署からはコストダウンや生産性向上に起因するような施策取り組みの結果などをどんどんシェアされるので、あまり見えなかった努力の成果や各部署の取組内容が知れるためとても楽しい会だなと思います。
ポストモーテムはその逆で、問題やインシデントなどの対応が発生したときに、再発防止するための振り返り会です。なぜなぜ分析(5why分析)や仕組みの問題点の洗い出しなどを行い、それを全社にも共有することで失敗をもとに次なる成功に導くための施策になります。ツラいですが、失敗を通して学べることは多くあるため個人的には頻度高くやりたいですね。(たくさんの問題があるのは本末転倒ですが……)

6. 改善MTG
開発合宿の改善活動と同じようなものです。他社での20%ルールみたいな感じで、隔週2時間ほど時間を作ってやっています。ここでは各人がやりたいことに取り組んでいます。業務に集中できなかったからという理由でスプリントに積まれているタスクを実装するということもあります。基本的になにをやってもいいので、自分で「これだけはやりたいと思っていた」みたいなことも無条件で進めることができます。

エンジニア組織の課題

さて、ここからは現状のエンジニア組織の課題についてお話したいと思います。

1. リリースタイミング
最近発生したインシデントで特徴的だったのが弊社のリモート薬剤師の方々が利用している患者コミュニケーション管理システムの機能にダイレクトに影響のある改修・機能追加を金曜日に行ったときでした。エンジニアチームは土日祝日は休日なのですが、弊社のリモート薬剤師の方々はシフト制勤務となっているため、土日も数人の薬剤師さんが出勤しています。そのため、そこで不具合やシステム異常により患者さんとのコミュニケーションに支障が出てしまうと、休日のアラート対応をエンジニアがすぐにできません。そのため、エンジニアメンバーは一部オンコールで待機している必要があります。
そのため、大きな改修や機能リリースがある場合は木曜日までにリリースすることと言うルールが最近明確にできあがりました。それ以外にも薬剤師の方に「何が変わるのか」を把握してもらったうえでオペレーションや対応方法の変更を事前にマニュアル化したり実際に触ってもらったりしないと仕事の生産性に影響が出るという意見もありました。
現在進行形でリリースの手順やフローを明確化と認識合わせを進めています。

2. エンジニア仕事多すぎ
フルサイクルエンジニアを見ていただくと分かるように、エンジニアのカバー範囲が広すぎるという課題が出てきます。もちろんエンジニアが上段の要件やユーザーインタビューをすることでプロダクトの方向性を自分で決めることができるのも大事ですが、それと同じくらいにコードを書いてモノを作ることも重要です。ここをどれだけ高速にやれるか、あるいは分業できるかはそれなりの課題かなと感じています。
現在ではPdM専任のかたも参画していただいているのですが、それでもまだまだスピードという点では改善することが出来るのではないかと思っています。

3. 技術的負債
これはもう言わずもがなですが、エンジニアリングたるものどうしても生まれてしまう技術的負債が弊社にも残っています。DBの定義がドメインと合っていなくて、機能改修したいのにDBの構造自体をいくつも変更しなければならずコードの改修とかそれどころじゃない…という問題や、いくつかの機能がエンジニアの入れ代わり立ち代わりによる継ぎ接ぎで作られたことで、現在メンバーでは全体のシーケンスを把握できずに変更を加えるためには一連の処理をすべて追っていかなければならない…などが一例としてあります。特にフロントエンドにおいては、BFF層の存在意義と、Reactコンポーネントの切り出し方あたりの雑さが目立っているのですが、人不足で全然解消できてないかつダイレクトに薬剤師の仕事に影響するためサクッと改善することができないという現状があります。
他にもセキュリティリスクや脱Heroku、GCPのもっと上手い連携あるんじゃないかとかそういうインフラ面での課題もあります。

4. 人いない/育成
すでに至るところで話に挙げているように圧倒的に人が足りていません。そして今後も弊社流フルサイクルエンジニアを大量に増やしていくためには教育や育成も必要になってきます。現状ではその土壌が整備されておらず、各人の持つスキルや特性を最大限に活かしながらマンパワーで乗り切るみたいな戦略しか有りません。今いるメンバーで事業を回すにはまあまあ限界が来ているかなというところもありつつも、メンバー全体の生産性を今以上に上げつつ新しいエンジニアも採用するという攻めと守りのどちらもやっていかなければならないフェーズです。

まとめ

長々と赤裸々に現在のYOJOエンジニア組織について語りましたので、以下にざっくりとまとめます。

■ バックエンドメンバー以外は業務委託の方々のパワーで支えられています
■ Jiraを使ってスクラムに取り組んでいます
■ 組織がありそれが事業で分かれるチーム編成を取ってます
■ 要件定義〜運用まで主担当はありつつもなんでもやります
■ 学びを大事にし、インプットとアウトプットのバランスを大事にしています
■ 課題はたくさんありますので一緒になってプロダクトを前進させてくれる方を募集しています

弊社ではミッションに掲げているように、「患者満足度世界一」を目指すメンバーが既存の薬局事業にとどまらないことを前提にエンジニアリングをしています。医療Techにおいて薬局はこれまであまりにもDXが進んでこなかった領域だと個人的には思っております。例えば多くの方は、「オンライン服薬指導(厚生労働省のpdf)」をご存じないと思います。それくらいには知名度も注目度も低いのですが、ここが変わらない限りいくらオンラインでお医者さんの診療ができたとしても、自宅近くの薬局に出向いて「薬くれ」という体験は変わることはありません。薬局事業といえば電子お薬手帳もありますが、それだけでは結局電子お薬手帳を実店舗の薬局に持っていくだけです。弊社の狙う薬局DXは、これらの体験を根本から変えるためのチャレンジをしていくこととなります。それらについて要件から考えることのできる経験は、エンジニアとしてはなかなかないのではないかと思います。強いチャレンジ精神を持ったエンジニアの方がいらっしゃれば、ぜひ一緒にやっていきませんか。(ついでに組織課題の対応も……)