プロダクト成長とともに システムを変更に強くする方法 横田 直彦

自己紹介 ● 株式会社カケハシ ○ ミッション： 日本の医療体験を、しなやかに。 ○ 事業：薬局向けにSaaSを提供したり、患者さん向けにアプリ開 発などを行う ○ 2016年設立 ○ 社員数200名ぐらい ● 発表者 ○ BIツールチームで、テックリードを担当 ○ ソフトウェアエンジニア経験 8年 ○ テックリードとしては 1年目 ● カケハシでの経歴 ○ Musubi（業務システム）のバックエンドエンジニア ○ MusubiInsight（BIツールのWebサービス）の立ち上げ ○ データ基盤の構築

カケハシでのテックリードについて ● 役割 ○ アーキテクチャの決定など、チームの技術について責任を持つ ○ 開発ロードマップ作成について PdMのサポート ○ チームメンバーの技術サポート ○ など ● やりがい ○ 技術選定などの意思決定を経験できる ○ 事業成長に合わせて、プロダクトやチームを成長させる経験ができる ○ ユーザーからの生の声を聞くことができる

チームの開発体制について ● チーム体制 ○ エンジニア5名 ○ プロダクトマネージャー（ PdM）2名 ○ デザイナー1名（PdMと兼務） ○ ドメインエキスパート（薬剤師） 1名（PdMと兼務） ○ スクラムマスター1名 ● 開発方法 ○ リーン開発 ■ α版：MVP（Minimum Viable Product）を簡易的に作ってリリース ■ β版：α版でPMF（Product Market Fit）を確認できた後開発し、一部顧客に提供 ■ GA(正式)版：顧客の声を反映し機能を改善し、全顧客に提供 ○ スクラム開発 ■ 2週間=1スプリント ■ プロダクトオーナーは、プロダクトマネージャーという名前で運用

変化に強いシステムにするには？

変化に強いシステムにするには ● 一度対応した変化に耐性をつける ● 暫定対応・恒久対応の二つをフレームワークとして考えると良い ○ 暫定対応: 少ない工数で、短期的に課題を解決できる方法 ○ 恒久対応: 長期的に（本質的に）課題を解決できる方法 → 変化への耐性をつける手段 ● 成長中のプロダクトでは、常に優先度の高いタスクが積まれるため、恒久対応のた めの時間が取れないことも多々ある ● テックリードは、今どこまで本質的な課題の解決をすべきかを取捨選択し、PdMとコ ミュニケーションしながらプロダクトを改善していく必要がある 暫定・恒久フレームワークを使って、本質的な課題を特定し、 PdMと対話を通して システムを変更に強くしていく方法を紹介

アジェンダ ● BIツールの概要 ● 暫定・恒久フレームワークを使って本質的な課題を探る事例 ● 暫定・恒久フレームワークを使ったPdMとのコミュニケーション

BIツールの概要

アーキテクチャ概要 データ集計・移動 リクエストされた期間で さらにデータ集計

本質的な課題について事例で考える

No content

事例: 業界ルール変更 ● 課題 ○ 新型コロナの影響で、コロナ加算が新設された ○ コロナ加算に関する指標を追加する必要が出た ● 判断 → 恒久対応 ○ コロナ加算は臨時措置だったが、よくよく確認したところ、算定ルールは 2年に1度更新されるという こともわかったため ● 本質的な課題についての気づき ○ 課題の本質は、ドメインエキスパートとの対話の中で新たに明らかになることもある 暫定 恒久 本質的な課題 集計スクリプトに書いてある算定コー ドにコロナ加算に関するものを追加 算定コード一覧を csvで管理し、 csvデータのデプロイによって変更で きるようにする 変更頻度の高い情報を変更しづらい 設計にしてしまっていた

● 課題 ○ バッチ集計でエラーが発生 ○ バグで、数値型と文字列型が混在していることが分かった ● 判断 → 暫定対応 ○ 基本的には、データの問題はデータソース側で対応した方が良い ○ ソース側のチームに確認したところ、今回のバグは対応できるが、今後も同種のバグが発 生しないようにするには時間がかかるとのことだった ○ 一旦、暫定対応でしばらく運用することにした ○ 恒久対応に繋げる施策として、集計ミスをソース側にも連絡するようにした ● 本質的な課題についての気づき ○ 将来的な事象の発生が読めない場合や、課題がチーム外にある場合、本質的な課題に対 応できないこともある 事例: データ不具合 暫定 恒久 本質的な課題 バッチ集計の前処理で、数値型に変換 データソース側で対応 データソース側のバグ

事例:データ取得APIのレイテンシ問題 ● 課題 ○ ユーザー数増加に伴い、データ量が増え、バックエンドの集計時間がレイテンシに影響 ● 判断 → 暫定対応案 → 恒久対応案② ○ Auroraのスケールアップについては、 ReservedInstanceによる縛りなどを考慮し、一旦スルー。 ○ まずはindexを使って改善できるところは暫定対応を行った ○ 暫定対応を一通り行いある程度改善はみられたが、数ヶ月後にさらにデータ量が増えて、問題が再発してしまった ○ データ量はまだ増えることが想定されたため、恒久対応をした方が良いという話になった ○ 恒久対応案① , ②について工数を見積もったところ、案①の工数的余裕はなくレイテンシ改善の保証もなかったため、 UI側で、ユーザーの操作を止めずに集 計リクエストをできるようにした ● 本質的な課題についての気づき ○ 長期視点で解決の見込みが立たない場合は前提を変えて（今回の場合だとレイテンシが悪いことを前提にして）、別の長期的な解決策を考えることも大事 暫定 恒久 本質的な課題 SQLのパフォーマンスチューニング ① Athenaなど、データ量が多くてもレイテンシ が下がりにくいクエリエンジンの採用 データ量増加に対して 計算リソースのスケーラビリティがないこと ② レイテンシ悪化が、ユーザーのストレスになら ないようにUIを改善 集計中にユーザーの操作を待たせてしまっていること

本質的な課題とは ● システム変更が必要になった根本原因 ○ 根本原因を解決できれば、変化への耐性をつけることができる ● どうやって特定する？ ○ 課題の発生頻度・影響範囲・変化の範囲について整理する ○ 問題領域のモデリングも特定に有効 ● 暫定・恒久のフレームワークを使う意味 ○ 時間軸で考えることで、長期的な視点を考慮に入れやすくなるため、問題の本質について考える きっかけになりやすい ○ 少なくとも二つ以上、選択肢を考える癖がつく ○ 注意 ■ 暫定・恒久は相対的で、元々の恒久対応が他の選択肢と比較すれば暫定対応になり得る

PdMとのコミュニケーション

PdMとのコミュニケーションについて ● 目的 ○ 限られた工数の中で、ビジネスとしても成立させ、変化に強いシステムを維持する必要がある。恒 久対応は工数がかかることも多いため、独断で進めてしまうと、ビジネスチャンスを逃してしまうか もしれない。そのバランスを取るために、 PdMとの情報共有が重要。 ● 暫定・恒久対応の２案を提案し、どちらか判断してもらう ○ 目的：ビジネス・システムの両視点を加味して、意思決定をしてもらう ○ メリット：トレードオフの判断の議論がシンプルになる ○ 暫定対応を選んだ時のリスクについて説明しておくことが大事 ○ 暫定対応になった場合は、いつ恒久対応をするか？の条件について合意しておくと、恒久対応を始 めやすい ● 複雑化してきた時は、ペイオフマトリックスで可視化して判断してもらう ○ 重要度 x 工数の二次元に解決策を並べ、対応の優先順位を決めてもらう

その他の工夫 ● 自分の経験だと、恒久対応案は大体バックログに残り続けている ● ビジネス要件が優先され、負債の解消は後回しになるため ● スプリントの中で、恒久対応を進める時間をもらっておくことも大事 ● チームの半期目標などに組み込むことも有効 ● 恒久対応案が思い付かない時は、一旦暫定対応で進めて、恒久対応をバックログ に調査タスクとして積むのも良い

まとめ ● 変化に強いシステムを作る時の考え方について紹介した ● 暫定・恒久のフレームワークは、課題の本質を考えるときや、PdMとのコミュニケー ションの際に役立つことを話した ● ビジネスと変化に強いシステムのバランスを取りながら、プロダクトを成長させると きの参考になれば幸いです

カケハシは仲間を募集中です！ ・テックリードに興味がある方 ・TypeScriptで開発したい方 ・データエンジニアを目指している方 カジュアル面談も気軽にご相談ください！ テックブログも定期配信しておりますので、是非ご覧ください！ エンジニア採用サイト 最後に・・

ご静聴ありがとうございました