【スタートアップにおける良い開発者体験とは】アーキテクチャと組織を両軸に。Ubieが実践する開発生産性を最大化する2つのアプローチ

「テクノロジーで人々を適切な医療に案内する」をミッションに掲げるヘルステップスタートアップ「Ubie」。生活者向けの症状検索エンジン『ユビー』（toC）と、AI問診などの医療機関向け診療支援サービスパッケージ『ユビーメディカルナビ』（toB）という2つのサービスを提供している同社では、開発者体験の向上を通して、開発生産性の最大化に取り組んでいる。セッションでは、ソフトウェアエンジニアの田口 信元氏から、エンジニアリングと組織構造へ向けた2つのアプローチが紹介された。

• keyboard_arrow_down 良いものを素早く世の中に出したい。開発生産性を最大化する必要性
• keyboard_arrow_down 開発生産性を最大化するための2つのアプローチ
• keyboard_arrow_down 見つかった課題に優先度を上げて取り組む
• keyboard_arrow_down 組織構造によるアプローチ

「ビジネスがスケールしたことで、ステークホルダーとのコミュニケーションが複雑化したり、サービスのユーザー数が急増して運用負荷が上がったりと、さまざまな要因で最初はできていた『良いものを素早く世の中に出す』ことが、難しくなっていました」

そこでUbieが目指したのは、プロダクトがスケールしても、開発者のアウトカムを引き続き高い状態に保つこと。さらに、事業拡大のスピードを落とさずに開発ができる体制と環境をつくること。これらを合わせて、「開発生産性最大化」と定義しているという。

「開発生産性が低下すると事業の成長スピードが低下するだけでなく、開発者自身のエンゲージメントが下がります。その結果、退職リスクや採用力の低下に繋がる可能性が高いのです」

逆に開発生産性が上がると、仮説検証を高速で回せるようになるだけでなく、運用改善にも手が回せるようになり、障害が少なくなる。さらに、新しい技術に投資する時間が生まれ、たくさんのアイデアが生まれるなど、好循環が期待できるのだ。

では、具体的にどのような手段で開発生産性を最大化するのか。Ubieは2つのアプローチで実現を目指した。

1つ目はエンジニアリングによるアプローチだ。

Ubieでは開発生産性を計測する指標として「Four Keys」を採用している。ソフトウェアのデリバリーパフォーマンスを表すFour Keysは、ビジネス成果と強い相関関係にあり、Four Keysを改善することで開発生産性の向上に寄与し、最終的なアウトカムの向上につながる。

具体的な取り組みとしては、GitHubのイベントログやプロダクトのリリース情報、インシデント管理SaaSの情報を収集し、BigQueryに保存。これらを使ってRe:dashでチームや組織が今どういう状態にあるかを見えるようにしているという。

「デプロイ頻度がEliteではあるものの段々と下がってきていることや、変更のリードタイムが長くなっていることなど、客観的に可視化して初めて気づいたことが多くありました。そこで、なにがデプロイ頻度や変更のリードタイムを悪化させているのか要因を調査したところ、現段階で解消すべき一番大きな問題かつ、中長期的に改善に向き合わないといけないのが、アーキテクチャ（技術的負債）であることがわかりました」

こうしてアーキテクチャの改善に着手したUbie。具体的な改善事例として、症状検索エンジン『ユビー』（toC）と、医療機関向け『ユビーAI問診』（toB）のサービスから共通して参照される質問機能の存在を挙げた。

当初はひとつの共通した機能だったものが、ビジネスが大きくなるにつれて徐々に“toBしか使わない”、“toCしか使わない”、“両方で使用する”ものが複雑に絡み合うようになってしまった。そのため、コード変更による影響範囲の検証やレビューも難しい状態に陥ったという。

また、このシステムには別の問題もはらんでいる。それは、『ユビーAI問診』（toB）は医療機関向けのサービスという性質上、事前に機能のリリース日程が決まっており、柔軟な調整が難しい。その上、QAのプロセスもより時間をかけたりする必要があったりと、『ユビー』（toC）の変更のリードタイムには大きく影響を与えてしまっている。このように、toBプロダクトのスケジュールにtoCプロダクトが引きずられてしまい、高速な仮説検証ができない、という構造になっていたのだ。

この課題を解決するために、システムやデータベースを分離させるというアーキテクチャ改善を実施した。これにより、toCチームが自由にデプロイできるようになり、サービス改善のリードタイムが短縮されたという。

田口氏はアーキテクチャ改善のロードマップについて、次のように説明している。

「こうした開発生産性を最大化するためのタネはたくさんあるんです。全部やろうと思うと、全然リソースが足りない。そのため、とくにインパクトが大きいアーキテクチャ改善に着手しています。ただ、中長期的な取り組みで組織が開発生産性最大化の恩恵を享受できるよう、優先度をつけて少しずつ改善を進めています」

改善したいタネはまだまだあるという田口氏。現在は定量の可視化と定性のヒアリングをもとに、全社目標に組み込んで組織全体で取り組んでいるそうだ。

開発生産性を最大化する2つ目の取り組みは、組織構造によるアプローチだ。田口氏は「生産性を改善するための文化を醸成することが、持続可能な開発体制をつくる上で重要だ」と前置きし、次のように述べた。

「最初はプロジェクトチームが主導して、アーキテクチャ改善や開発プロセス改善をしていました。組織が大きくなるにつれて、トップダウンでの改善のみでは限界があります。そこで重要になるのが、プロダクト開発チーム含め、開発者全員が自立的に開発プロセスやアーキテクチャを改善するという、ボトムアップなアプローチです。どちらか一方ではなく、トップダウンとボトムアップの両輪で改善が行われる体制づくりを目指していきたい」と語った。

しかし、ビジネスのスケールに伴って、システムの複雑性は増していく。ステークホルダーの増加や、施策・改善を行う場合に考えるべき変更、影響範囲が広がるという認知負荷が増大していく。そのせいで、構造的且つ高速で仮説・検証をするのが難しくなりつつあったという。

開発者の認知負荷を下げ、チーム間のコミュニケーションを最適化することで開発生産性の向上を目指したい。その解決手段として、UbieはTeam Topologies（チームトポロジー）の導入を行った。

「基本的にアーキテクチャと組織は両軸で、まず理想のアーキテクチャがある。それに沿って、チーム設計を行“逆コンウェイ戦略”を取るのがよいのかなと考えています」

Team Topologiesの導入にあたり、まずソフトウェアエンジニアやデータエンジニア、機械学習エンジニア、SREが横断的に集まり、読書感想会を開催して交流を深めた。書籍を購入して読むほか、分かりやすい事例やすでにまとまっているものを参照して議論していったという。その上でUbieでは、どのようにTeam Topologiesを取り入れていくと効果的なのか話し合いを重ねた。

例えばPoCを行う医療機関事業の組織では、開発者に続きカスタマーサクセスや各チームのプロダクトオーナー、BizDevのメンバーがTeam Topologiesについて学び始め、組織設計の課題について一緒に議論。それから業務フローやカスタマージャーニーを改めて整理。フローの境界はどこかを洗い出し、結果的にユビーのバリュー・ストリームを再定義した。

Team Topologiesを採用したことでどのような成果をもたらしたのか。田口氏は次の効果を挙げた。

• ・自然とシステムやドメインに対するオーナーシップをもてるようになった
• ・「中長期の課題へ取り組むこと」や「ドキュメント化などのアセットを蓄える活動」が合目的的になった
• ・属人化していたタスクが適切なチームの責務として再定義できるようになった
• ・開発者に限らず、運用に関する解像度が高まった
• ・認知負荷が高くなってきた状態を自覚し、組織構造の改善というアプローチを取れるようになった

「掲げていた『開発生産性最大化』の目標が開発者だけのものではなく、組織全体の関心事として認知できるようになりました」と田口氏。この成果をもとに、UbieではTeam Topologiesの適用範囲を拡大。全社に取り入れていくことで、より価値提供にフォーカスできるようになることを期待しているとして話を締めくくった。