DeNA・Ubie・FiNCが明かす「とりあえず導入した施策」の失敗と対策とは

アーカイブ動画

【FiNC】サービスライフサイクルに応じた施策の振り返り

株式会社 FiNC Technologies　執行役員 CTO 篠塚 史弥氏

施策１：新規事業を新たなマイクロサービスとして実装

ビジネス側からの要望で、新規事業で利用するサービスを新たに開発することになった。既存のメインサービスはモノリシックなサービスであり、ここに実装すると開発スピードが落ち、その後の機能拡張もスピードが鈍ることは明確。他のサービスへの実装も検討するが、どこに実装しても収まりが芳しくない。そこで、新たなマイクロサービスとして、開発・実装することにした。

「想定していたとおり、既存事業や既存システム実装時の影響を受けないため、サービスの立ち上げはスピーディに行うことができました。また、サービス開始後のプロダクト施策のPDCAも素早く実行できました。結果として撤退した事業となりましたが、既存事業とは切り離していたので、撤退においてもスムーズでした」（篠塚氏）

一方で、課題もあった。マイクロサービスの運用フェーズでのコスト増である。そこで篠塚氏は改めて、マイクロサービスにおける運用フェーズでのコストを示した。

篠塚氏は自身が神資料と称賛する、リクルートの黒田樹氏が作成した資料「事業価値とエンジニアリング」を引用。開発時における意識しているポイントも合わせて紹介。その上で、運用フェーズのコストが上がったのは「他サービスとの依存の追加」「新規開発者の参加」が要因であり、マイクロサービスで切り出したことが問題ではないことを強調。対策についても説明した。

「開発段階から運用フェーズを考慮するように対策を講じました。アーキテクチャレビューやプロダクションレディチェックの導入です。SREチーム、エンジニア以外、事業サイドのメンバーも交えてアーキテクチャの検討を行いました」（篠塚氏）

設計の意思決定をドキュメンテーション化し、後から参加した人のキャッチアップが容易に行える対策も講じた結果、課題は解決された。早すぎるマイクロサービスがアンチパターンと言われることに対しては、次のような見解を述べた。

「事業の性質によっては、一概にアンチパターンとは言えない。先行者利益が大きいビジネスでは、早く出すことが重要だからです。運用コスト増の中身を洗い出し、検証することが重要です。システムやサーバー費が占めていることもあれば、生み出したビジネスによる成果が上回るケースもあるからです」（篠塚氏）

施策２：逆コンウェイ戦略に沿ったチーム分割

続いて紹介されたのは、システム（技術）設計に応じて組織を構成していく「逆コンウェイ戦略」を行った施策だ。アプリケーションの開発チームをマイクロサービスごとに、基盤系、コミュニティサービス、ライフログサービスと3つに分割した事例である。

開発チームの人数が増えるにつれて、ナレッジが溜まりづらく、アサインに時間がかかるという課題解決に向けた施策であり、並列化したことで開発スピードが高まるなどの成果はあった。

一方で、いわゆるサイロ化が起き、ドメイン知識の固定はもちろん、コミュニケーションが不活発となり、コミュニケーションの調整コスト増といった課題が生じる。そこで改めて対策を講じていった。

「当初はコミュニケーションの場を設けるといった対応をしていましたが、そもそもサービスごとにチームを分割したことが問題だと気づき、新たに対策を打ちました」（篠塚氏）

まず、サービスでチームを分けるのではなく、事業目標をベースに分けることとした。そうすることによって、いい意味で開発領域が曖昧になり、知識の冗長化や柔軟なアサインが実現できた。一方、相反するかたちで責任者が不明確となり、実装方針やメンテナンス基準などが統一されないとの課題が生じた。

そこで今度は、サービスごとにオーナー権限を持たせる開発チームとし、コード品質やメンテナンスの責任を課した。そうしたことにより先の課題は解決した。また、サービスオーナーの定例会を行うことで、プラクティスが共有されるといった効果が生まれた。

篠塚氏は取り組みならびに、生じた課題に対する施策を振り返り、次のようにまとめ、セッションを締めた。

「システム・組織どちらの設計や施策においても、最初から完璧な設計を目指さないこと。長い間携わる際は、定期的に振り返ると同時に新たな施策を実行するなど、バージョンアップしながらベストを目指していくことが重要だと思います」（篠塚氏）

【DeNA】ヘルスケアプロダクト「kencom」における失敗と改善策

続いて登壇したのは、DeSCヘルスケアの伊藤康太郎氏、福島誠大氏の2名が登壇した。 DeNAと住友商事により2015年に設立したDeSCヘルスケアは、ヘルスケアエンターテイメントアプリ「kencom（ケンコム）」を手がけている。

健診・検診結果、薬の処方履歴、健康状態に応じた情報のレコメンデーション、そして歩くことを競うといったエンタメ機能などを実装。健康保険組合や自治体といった各種健康機関など約100団体がアプリを導入しており、登録可能ユーザー数は480万人以上になる。

（左から）
DeSCヘルスケア株式会社　取締役 システム部長 株式会社DeNAライフサイエンス　取締役
日本テクトシステムズ株式会社　取締役　伊藤 康太郎氏
DeSCヘルスケア株式会社　システム部 プラットフォーム開発グループ　グループリーダー　福島 誠大氏

施策１：バックエンドアーキテクチャ刷新における失敗と学び

kencomでは新しいアプリを開発し、新たな市場やユーザーを広げたい。新アプリ開発においては、UIや機能のベースは、既存と共通にしたいというニーズがあった。

プロジェクトに取り組む際は、技術的負債の解消を目標に掲げ、GCP環境でバックエンドアーキテクチャを刷新することになった。そして、アーキテクチャの構築や新しいアプリがローンチされた後、既存プロダクトも新たなプラットフォームに段階的に移行する構想を掲げた。

2019年6月に「kencom×ほけん」のローンチに至るが、当初考えていた既存プロダクトの移行は中止となった。そのため、移行を前提に構築された過剰な設計や実装が残されることとなってしまった。端的に言えば、必要以上にリッチなプラットフォームを構築してしまったのである。

「要因は大きく2つありました。1つは、利用者の属性が異なることによる、登録時の個人認証、ポイント獲得上限といったアーキテクチャの前提条件が合わないことでした。共通化を推し進めれば、仕様の自由度の低下や、開発時間が増大するとのデメリットが考えられました」（伊藤氏）

もう1つの要因は、座組や法令に起因する制約だ。たとえば個人情報。既存アプリを利用していた顧客Xに関する検診結果などのデータを、新規サービスのYに流用してもいいのか、といった問題である。

ユーザーから個人情報提供に関する同意を得る法令に則った業務が発生し、それなりの作業ボリュームとなることは明白であった。

技術的な観点から見ても、共通のバックエンドサービスに同設計を組み込むことは簡単ではなかった。総合的に鑑み、移行することにより、問題がさらに複雑化する可能性が高いとの判断に至る。

「今回の施策を通して、開発効率や技術的な側面だけではアーキテクチャの設計は決められない。市場、組織、契約・法令など外的環境に依存することを学びました。またこのような考えは、ソフトウエアシステムのアーキテクチャ記述のための推奨指針であるIEEE1471でも環境との関係性を包含すると定義しています。」（伊藤氏）

伊藤氏は改めて技術だけを考えたシステムを設計ではない、組織面から考えるコンウェイの法則、法令などを重視する姿勢を改めて明確化。専門知識を持つリスクマネジメントチームと、日常的に連携する体制に刷新した。

施策２：20％ルールを効果が出るように刷新

2つ目の施策は、いわゆる20％ルールの導入だ。最低20％の工数を、負債改善などの事業継続の基盤を整える活動に割り当てるルールを、組織全体として掲げた。

組織全体で掲げたことで、ビジネスやPMへの共有や理解はスムーズに進んだ。一方で、いつ20％を充てるのか。シンプルに5分の1、週1日では重いテーマに取り組みづらく、当初イメージしていた成果が出ず、ルールの形骸化が否めなかった。

個人の1週間の20%ではなく、チームの半期の20%と捉え直すことで、重いテーマに取り組めるよう配慮した。また、大きなテーマは個人が自主的に取り組むには負担が大き過ぎるという配慮から、技術的責任者がフォローするなどの支援も行った。

このような取り組みの結果、数年間保留されていた社内ツールの環境が、AngularからReactに刷新されることとなった。

施策３：マイクロサービスで生じた課題とその対応

kencomのシステムは、機能ごとにマイクロサービスで切り分けており、アーキテクチャの概念はスライドのようになる。だが、サービスのリリースから6年経つと、当時はベストだと思っていた施策が、ネックとなってきた。

業績、ビジネスモデル、組織体制、開発メンバーなど、さまざまな変化により、マイクロサービスの利点が反映されたシステムではなくなってしまったのだ。伊藤氏からバトンを受け取った福島氏はこう語っている。

「コンポーネント間で依存関係が多数存在しているため、1つの機能を開発・修復する際、複数コンポーネントに同時に対応する必要があります。リリースに関しても同様で、単独でリリースすることができません。障害時も同じく、すべてのコンポーネントを調査する必要があるなど、問題は山積みでした」（福島氏）

コンポーネントごとにチームを構成する体制ではなく、少人数ですべてのコンポーネントを管理しているため、エンジニア1人の負担が大きいことも問題だった。ほぼ使っていないコンポーネントも放置状態となっており、技術負債が徐々に溜まっていった。

しかし、このままの状態を放置しておくわけにもいかず、組織全体として改革を推進していくことを決定。メンバーが集まり、改善に向けた中長期のロードマップを作成。専任エンジニアも立て、今まさに改革を行っている最中だという。

一方で、マイクロサービスによるメリットも紹介した。kencomは当初オンプレで開発されており、昨年AWSに移行した。ただ多くのシステムの規模が大きく、単にクラウドに乗り換えただけで、EC2が提供するマネージドサービスが利用できていなかった。

「それが今回、新しいコンポーネントを開発するタイミングで、ゼロベースでクラウドネイティブなアーキテクチャで設計し、構築を行うことができました。システム全体ではなく、一部の機能のみを試すことができる、マイクロサービスならではのメリットだと感じています」（福島氏）

【Ubie】先を見据えたMVPのフロントエンド開発

医師とエンジニアが2017年に設立したUbie。医療機関向けのサービスなども開発するが、今回のセッションでは一般ユーザー向けアプリ「ユビーAI受診相談」における取り組みについて、開発担当者である小谷優空氏が紹介した。

Ubie株式会社　ソフトウェアエンジニア　小谷 優空氏

施策１：共通使用していたコードベースをステークホルダーごとに分割

「ユビーAI受診相談」は、症状をアプリの質問に答えるかたちで入力していくと、参考病名や近隣の医療機関が調べられるサービス。月間のアクティブユーザー数は450万にもなる。

「2019年からMVPを開発し、検証をスタートしました。正式公開は2020年の4月ですが、その後症状チェッカーとしてPMFを迎え、急激に増える利用者に対応する中で技術的負債が爆発。2021年4月から5月にかけて、フロンエンドを作り直すことになりました」（小谷氏）

技術的負債が爆発した要因は、1つのコードベース上で、患者（利用者）、医療機関、製薬企業と、すべてのステークホルダーにサービス提供をしていたことだと小谷氏は分析する。

というのも、医療機関の事前問診として提供している場合は、すでに医療機関の問診業務に組み込まれているので、サービスレベル目標（SLO）は高い。それに比べると、患者主体で利用する場合のSLOは高くない。実際に医療機関向けのSLOを気にして患者向けの施策スピードが落ちてしまったり、患者向けの機能変更が医療機関側の障害に繋がってしまうこともあった。

そこで、現在はステークホルダーごとに3つのコードベースに分割することで先の課題は改善された。また、パフォーマンスが求められる患者向けの部分は Next.js で実装するなど技術選定の柔軟性も得られた。

「多少のデメリットはありますが、マイクロフロントエンドのような複雑な実装をしなくても、フロントエンドのコードベースは分割できる仕様となりました」（小谷氏）

ちなみに、リプレイスの内容をまとめた資料はこちらにまとまっている。

施策２：クリーンアーキテクチャの導入失敗からの学び

2つ目の施策は、中途半端なクリーンアーキテクチャの導入である。MVPを高速に立ち上げる代償として、アーキテクチャが無秩序になってしまった。そこで、無秩序を改善すべく、クリーンアーキテクチャを段階的に導入した。

しかし、何が正しい秩序なのかを明確に定義することなく、“とりあえず”クリーンアーキテクチャを導入してしまう。その結果、以前より開発効率が低下し、新メンバーのキャッチアップコスト増といった課題まで生んでしまうことになる。

改めて秩序をしっかりと定義し、アーキテクチャを整理することにした。大きくはレイヤーの分割とインターフェースの定義であり、スライドのように整ったアーキテクチャに改修された。

「クリーンアーキテクチャのような大きな施策ではなく、中長期含めてさまざまな面でメリットのある、コスパのよい施策を行うこと。また、短期的に品質を妥協する際には、近い将来取り返すことを計画しておくことが重要だと学びました」（小谷氏）

施策３：「とりあえずフロントエンド」にビジネスロジックを大量に実装

同アプリでは年600回のリリースの多くを、フロントエンドに詰め込んでいた。理由はシンプル、コードベースはひとつで済むことと、動作検証が楽だからだ。しかし、あまりにもフロントエンドのビジネスロジックが肥大化してしまった。

フロントエンドの動作環境はハンドリングできないため、環境依存のエラーが止まらず、監視が機能しない。バンドルサイズが膨らみパフォーマンスが低下、ログの担保が怪しい、SEOにも影響をおよぼすなど、さまざまな課題が生じていった。

そこで現在は、徐々にバックエンドに移行している。流れとしては、GraphQLスキーマ上に、バックエンドで行いたいビジネスロジックを整理するところから着手。現在、まさに取り組み中とのこと。また、モノリスの解体、基盤系マイクロサービスの整備など、バックエンド実装をしやすくする整備も始まっているという。

MVP開発はさまざまな要素において不確実性があるため、すべてを読み切って設計することは難しい。一方で、不確実性に対応するための施策として、プロダクトやサービスレベル、ステークホルダーなどの境界を持つことだ、と小谷氏は語る。

例えば、フロントエンドの肥大化。WebAPIをインターフェースとしてフロントエンドとバックエンドを分けることが理想だが、最速で開発するために、小谷氏たちは、意図的に境界を越えてきた。

「境界を越える際には、境界の役割を考え、別の境界を設け担保することが重要です。フロントエンドアプリケーションの中に、レイヤードアーキテクチャを構築して代替の境界を引くことで、インターフェース実装の可換性を担保することができるからです」（小谷氏）

【Q＆A】参加者からの質問を紹介

セッション後、登壇者たちが参加者から寄せられた質問に答えた。

Q．インフラアーキテクチャではIaCテンプレートを使い共通化しているか

篠塚：IaC（Infrastructure as Code）を使っています。インフラも含め、すべてコード管理しようと宣言していますので、Terraformを使い、実現しています。

Q．BFF (backend for frontend)導入について

篠塚：導入したところ、複雑さが減ったり、実装スピードが上がるといった効果が生まれています。メイン言語とは異なるサーバーサイドKotlinで実装しているため、クライアント/サーバーサイド両エンジニアが勉強会を実施するなど、スキルアップにも寄与しています。

福島：kencomでは導入していません。ただ、導入しようかとの議論は上がっていて、サーバーサイド言語のRailsで作るか、クライアント側が開発しやすいKotlinにするかといった意見が交わされています。

小谷：Ubieでは、GraphQLを使った通信向けドメインサービスとBFFが兼務状況となっており、BFFとして独立させる動きがあります。言語においては、引き続きKotlinでいくのか、Node.jsで行うかといった議論が交わされています。

Q．BFFエンドポイントの設計基準や概念

篠塚：画面単位やひとつのリクエストで分ける思想です。たとえば、プロキシAPIなど。そのためアプリはOS・クライアント別で分ける設計にはしていません。

Q．“打ち手”を負債にしないための振り返りの場や体制について

伊藤：大きく3つあります。1つはスクラムチームにおけるレトロスペクティブ、2つ目は月一で実施しているライトニングトーク、3つ目はシステム障害の報告会です。DeNA全体ではこれらについて明確にルールがあるわけではなく、各チームに任されている状況です。

福島：kencomについては、毎週金曜日の夕方に振り返りを行っています。また、合宿なども、普段から思っていた課題を共有し、解決に向けて議論する場となっています。振り返りの内容としては、負債の改善だけでなく、開発効率向上など全般的な課題解決について話しています。

小谷：Ubieはホラクラシー組織体制を構築しており、各メンバーは役職ではなく、ロールと呼ばれる役割で動く特徴があります。ホラクラシーでは、関連するロールが集まる会議体が規定されており、各ロールの活動に歪みが生じている場合は、その会議で歪みの共有から改善の打ち手決めまでを行う仕組みになっています。その中で技術的負債の振り返りなども行われています。

篠塚：3年前から、振り返りを行うことが全社的な文化として根付いてきました。具体的な仕組みやタイミングとしては、スクラム開発でのレトロスペクティブ。プロジェクト終了後のポストモーテム。そのほか、評価の際やインシデントが発生したときには、それぞれフォーマットに準ずる形で行っています。

Q．相反するチャレンジと振り返り、どのようにバランスをとっているのか

福島：最近取り組んだ施策では、半年間という期間を設け、攻め・守りの施策を担当するエンジニアのリソースを、最初に決めました。どちらの問題も改善し、良い結果を得ました。

篠塚：ホームラン的な施策を打つよりも、ヒットを重ねながら、適宜、修正・フィードバックする振り返りを行っています。中でも顧客からのフィードバックを第一に考えています。

小谷：採用要件の段階から、探索的な課題検証を得意とする Holon と、最適な方法での課題解決を得意とする Focus に人材タイプを分けていて、それぞれが得意なことにコミットする体制となっています。

Q．設計の意思決定のドキュメント化において、現場から反対の声はなかったのか

篠塚：以前はドキュメントを書く文化がなかったため、情報が欲しい際に苦労していました。SREチームが積極的にドキュメント化の重要性を言い続け、書くことが評価・称賛される体制に変わったことで、多くのメンバーが気持ちよく書けるようになりました。

Q．ドキュメンテーションで使っているツールや管理方法など

篠塚：ツールはもちろん、変更する際の心理的ハードルが低いScrapboxを使っています。一方で、検索については現状の課題となっていて、今まさに取り組んでいる最中で、GitHubのwikiで整備しようと考えています。

株式会社ディー・エヌ・エー
https://dena.com/jp/

株式会社ディー・エヌ・エーの採用情報
https://dena.com/jp/recruit/

Ubie株式会社
https://ubie.life/

Ubie株式会社の採用情報
https://recruit.ubie.life/