プロダクト成長とともに変化に強くする方法

【株式会社カケハシ　横田 直彦】
サービスの成長とともに、開発当初の設計が変更に迫られることはよくあると思います。 皆さんは実現できる選択肢が複数あった場合、どうやって判断しているでしょうか？今回の発表では暫定対応・恒久対応の二つの判断をどのように行ったのか、リアルな事例を紹介します。
・変化に強いシステムとは
・システム変更をする際の判断基準、ポイント
・長期的な（本質的な）課題と短期的な課題解決はどちらを優先すべきか

Transcript

1. プロダクト成長とともに システムを変更に強くする方法 横田 直彦
2. 自己紹介 • 株式会社カケハシ ◦ ミッション： 日本の医療体験を、しなやかに。 ◦ 事業：薬局向けにSaaSを提供したり、患者さん向けにアプリ開 発などを行う ◦ 2016年設立 ◦ 社員数200名ぐらい • 発表者 ◦ BIツールチームで、テックリードを担当 ◦ ソフトウェアエンジニア経験 8年 ◦ テックリードとしては 1年目 • カケハシでの経歴 ◦ Musubi（業務システム）のバックエンドエンジニア ◦ MusubiInsight（BIツールのWebサービス）の立ち上げ ◦ データ基盤の構築
3. カケハシでのテックリードについて • 役割 ◦ アーキテクチャの決定など、チームの技術について責任を持つ ◦ 開発ロードマップ作成について PdMのサポート ◦ チームメンバーの技術サポート ◦ など • やりがい ◦ 技術選定などの意思決定を経験できる ◦ 事業成長に合わせて、プロダクトやチームを成長させる経験ができる ◦ ユーザーからの生の声を聞くことができる
4. チームの開発体制について • チーム体制 ◦ エンジニア5名 ◦ プロダクトマネージャー（ PdM）2名 ◦ デザイナー1名（PdMと兼務） ◦ ドメインエキスパート（薬剤師） 1名（PdMと兼務） ◦ スクラムマスター1名 • 開発方法 ◦ リーン開発 ▪ α版：MVP（Minimum Viable Product）を簡易的に作ってリリース ▪ β版：α版でPMF（Product Market Fit）を確認できた後開発し、一部顧客に提供 ▪ GA(正式)版：顧客の声を反映し機能を改善し、全顧客に提供 ◦ スクラム開発 ▪ 2週間=1スプリント ▪ プロダクトオーナーは、プロダクトマネージャーという名前で運用
5. 変化に強いシステムにするには？
6. 変化に強いシステムにするには • 一度対応した変化に耐性をつける • 暫定対応・恒久対応の二つをフレームワークとして考えると良い ◦ 暫定対応: 少ない工数で、短期的に課題を解決できる方法 ◦ 恒久対応: 長期的に（本質的に）課題を解決できる方法 → 変化への耐性をつける手段 • 成長中のプロダクトでは、常に優先度の高いタスクが積まれるため、恒久対応のた めの時間が取れないことも多々ある • テックリードは、今どこまで本質的な課題の解決をすべきかを取捨選択し、PdMとコ ミュニケーションしながらプロダクトを改善していく必要がある 暫定・恒久フレームワークを使って、本質的な課題を特定し、 PdMと対話を通して システムを変更に強くしていく方法を紹介
7. アジェンダ • BIツールの概要 • 暫定・恒久フレームワークを使って本質的な課題を探る事例 • 暫定・恒久フレームワークを使ったPdMとのコミュニケーション
8. BIツールの概要
9. アーキテクチャ概要 データ集計・移動 リクエストされた期間で さらにデータ集計
10. 本質的な課題について事例で考える
12. 事例: 業界ルール変更 • 課題 ◦ 新型コロナの影響で、コロナ加算が新設された ◦ コロナ加算に関する指標を追加する必要が出た • 判断 → 恒久対応 ◦ コロナ加算は臨時措置だったが、よくよく確認したところ、算定ルールは 2年に1度更新されるという こともわかったため • 本質的な課題についての気づき ◦ 課題の本質は、ドメインエキスパートとの対話の中で新たに明らかになることもある 暫定 恒久 本質的な課題 集計スクリプトに書いてある算定コー ドにコロナ加算に関するものを追加 算定コード一覧を csvで管理し、 csvデータのデプロイによって変更で きるようにする 変更頻度の高い情報を変更しづらい 設計にしてしまっていた
13. • 課題 ◦ バッチ集計でエラーが発生 ◦ バグで、数値型と文字列型が混在していることが分かった • 判断 → 暫定対応 ◦ 基本的には、データの問題はデータソース側で対応した方が良い ◦ ソース側のチームに確認したところ、今回のバグは対応できるが、今後も同種のバグが発 生しないようにするには時間がかかるとのことだった ◦ 一旦、暫定対応でしばらく運用することにした ◦ 恒久対応に繋げる施策として、集計ミスをソース側にも連絡するようにした • 本質的な課題についての気づき ◦ 将来的な事象の発生が読めない場合や、課題がチーム外にある場合、本質的な課題に対 応できないこともある 事例: データ不具合 暫定 恒久 本質的な課題 バッチ集計の前処理で、数値型に変換 データソース側で対応 データソース側のバグ
14. 事例:データ取得APIのレイテンシ問題 • 課題 ◦ ユーザー数増加に伴い、データ量が増え、バックエンドの集計時間がレイテンシに影響 • 判断 → 暫定対応案 → 恒久対応案② ◦ Auroraのスケールアップについては、 ReservedInstanceによる縛りなどを考慮し、一旦スルー。 ◦ まずはindexを使って改善できるところは暫定対応を行った ◦ 暫定対応を一通り行いある程度改善はみられたが、数ヶ月後にさらにデータ量が増えて、問題が再発してしまった ◦ データ量はまだ増えることが想定されたため、恒久対応をした方が良いという話になった ◦ 恒久対応案① , ②について工数を見積もったところ、案①の工数的余裕はなくレイテンシ改善の保証もなかったため、 UI側で、ユーザーの操作を止めずに集 計リクエストをできるようにした • 本質的な課題についての気づき ◦ 長期視点で解決の見込みが立たない場合は前提を変えて（今回の場合だとレイテンシが悪いことを前提にして）、別の長期的な解決策を考えることも大事 暫定 恒久 本質的な課題 SQLのパフォーマンスチューニング ① Athenaなど、データ量が多くてもレイテンシ が下がりにくいクエリエンジンの採用 データ量増加に対して 計算リソースのスケーラビリティがないこと ② レイテンシ悪化が、ユーザーのストレスになら ないようにUIを改善 集計中にユーザーの操作を待たせてしまっていること
15. 本質的な課題とは • システム変更が必要になった根本原因 ◦ 根本原因を解決できれば、変化への耐性をつけることができる • どうやって特定する？ ◦ 課題の発生頻度・影響範囲・変化の範囲について整理する ◦ 問題領域のモデリングも特定に有効 • 暫定・恒久のフレームワークを使う意味 ◦ 時間軸で考えることで、長期的な視点を考慮に入れやすくなるため、問題の本質について考える きっかけになりやすい ◦ 少なくとも二つ以上、選択肢を考える癖がつく ◦ 注意 ▪ 暫定・恒久は相対的で、元々の恒久対応が他の選択肢と比較すれば暫定対応になり得る
16. PdMとのコミュニケーション
17. PdMとのコミュニケーションについて • 目的 ◦ 限られた工数の中で、ビジネスとしても成立させ、変化に強いシステムを維持する必要がある。恒 久対応は工数がかかることも多いため、独断で進めてしまうと、ビジネスチャンスを逃してしまうか もしれない。そのバランスを取るために、 PdMとの情報共有が重要。 • 暫定・恒久対応の２案を提案し、どちらか判断してもらう ◦ 目的：ビジネス・システムの両視点を加味して、意思決定をしてもらう ◦ メリット：トレードオフの判断の議論がシンプルになる ◦ 暫定対応を選んだ時のリスクについて説明しておくことが大事 ◦ 暫定対応になった場合は、いつ恒久対応をするか？の条件について合意しておくと、恒久対応を始 めやすい • 複雑化してきた時は、ペイオフマトリックスで可視化して判断してもらう ◦ 重要度 x 工数の二次元に解決策を並べ、対応の優先順位を決めてもらう
18. その他の工夫 • 自分の経験だと、恒久対応案は大体バックログに残り続けている • ビジネス要件が優先され、負債の解消は後回しになるため • スプリントの中で、恒久対応を進める時間をもらっておくことも大事 • チームの半期目標などに組み込むことも有効 • 恒久対応案が思い付かない時は、一旦暫定対応で進めて、恒久対応をバックログ に調査タスクとして積むのも良い
19. まとめ • 変化に強いシステムを作る時の考え方について紹介した • 暫定・恒久のフレームワークは、課題の本質を考えるときや、PdMとのコミュニケー ションの際に役立つことを話した • ビジネスと変化に強いシステムのバランスを取りながら、プロダクトを成長させると きの参考になれば幸いです
20. カケハシは仲間を募集中です！ ・テックリードに興味がある方 ・TypeScriptで開発したい方 ・データエンジニアを目指している方 カジュアル面談も気軽にご相談ください！ テックブログも定期配信しておりますので、是非ご覧ください！ エンジニア採用サイト 最後に・・
21. ご静聴ありがとうございました