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

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

2 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。本日お話しすること FiNCで「とりあえず行った施策」について紹介しますどのような背景でそれぞれの施策が行われたのか、いったん成功に見えた施策で運用時に起きた問題はなんだったのか、を振り返りますそれぞれに対して行った対策についても紹介します

3 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。自己紹介篠塚史弥 @shinofumijp 2014年3月に株式会社FiNC Technologiesに入社
2020年4月、CTOに就任趣味はギターとワイン

4 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。 CONFIDENTIAL © FiNC Technologies Inc. 4

5 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。アプリケーションはRailsを利用したマイクロサービスで構築

6 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。 CONFIDENTIAL 施策の紹介と振り返り

7 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。施策1 マイクロサービスとして新規事業の立ち上げ行なったこと既存事業とは別チームで新規事業チームを作り、新規事業で利用するサービスを新しいマイクロサービスとして実装した背景
新機能の追加、既存機能の拡張を止めることなく、新規事業の立ち上げを早く行いたいという要求があった課題新規事業で利用するサービスをどこに実装するか？メインとなるサービスは初期からあるモノリシックサービスここに実装すると既存機能の拡張も新規サービスの立ち上げも遅くなるその他いくつかのサービスがあるがどこに実装するにしても収まりが悪い

8 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。マイクロサービスとして新規事業の立ち上げの振り返り Good • 既存事業や既存実装の影響を受けないため、サービスの立ち上げは素早く行えた • サービスイン後もプロダクト施策のPDCAを早く行えた
• 事業の業績不振時の撤退もサービスを落とすだけでスムーズに行えた Bad • 一定のグロースが終わった運用フェーズでは運用コスト増につながった

9 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。運用フェーズにおけるコストとは？ • 新規実装の際の開発速度の低下 • アーキテクチャ起因による企画の制限 •
メンテナンスの対応コスト • メンテナーの維持コスト、採用コスト • 障害リスクの向上、障害時の対応コスト • サーバー、インフラ費用何のコストかを正確に把握しようとすることが重要開発速度の低下など機会損失につながるなら影響は大きいサーバー、インフラ費用の増加は事業計画次第では許容できる

10 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。 (参考)エンジニアリングを事業価値につなげるための施策の4種類「事業価値とエンジニアリング」Recruit Technologies 黒田樹 https://speakerdeck.com/rtechkouhou/shi-ye-jia-zhi-to-enziniaringu
より引用

11 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。なぜ運用フェーズのコストが上がってしまったのか • 他サービスとの依存の追加 • 新規開発者の参加

12 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策 • 開発時点で運用時の考慮を入れる対策 => アーキテクチャレビュー、プロダクションレディチェック •
運用時のメンテナンスコストを下げる対策 => ドキュメンテーション、ADR

13 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策：アーキテクチャレビュー SRE、エンジニア以外の事業側の人も交えてアーキテクチャの検討とレビューを行う達成したこと • 開発時の視点だけでなく運用時の視点からの検討が行えるようになった •
事業計画から許容できる運用コストも計算できるようになった • 3省2ガイドラインなど必要なガイドラインへの準拠確認

14 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策：プロダクションレディチェックサービスがプロダクションで稼働する際のチェックリストを用意達成したこと • 開発時点でサービス運用に必要なことがわかるように •
サービスの運用レベルの基準が揃った

15 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策：ドキュメンテーション、ADR 設計の意思決定をドキュメンテーションとして残す達成したこと • メンテナンスコストを下げる •
後からサービス開発に関わるようになった人のキャッチアップが容易になった

16 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。早すぎるマイクロサービス化はアンチパターンか？事業の性質によっては一概にアンチパターンとは言えない許容される性質の例 • 先行者利益が大きいビジネス •
サービスが独立しており、運用コスト増の中身がシステム、サーバー費中心 • サービスイン後の運用コスト増、リアーキテクチャも対応コストが見合う

17 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。 ※注質とスピードのトレードオフの話ではない質とスピードはトレードオフではなく内部品質を下げる判断をすることは基本的に悪手「質とスピード（2020秋100分拡大版）」和田
卓人 https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition より引用

18 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。 (余談)アーキテクトが会計、事業について学ぶのはコスパがいい説 • 事業サイドの人がアーキテクチャやエンジニアリングについて学ぶのは時間がかかる • エンジニアが会計の触りを学ぶ分についてはそこまで時間がかからない(「完全に理解」で留めるものとする) •
技術以外の観点からの判断もできる

19 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。施策1のまとめマイクロサービス化それ自体が運用コストを増やしたわけではなく、その後の安易な依存追加とキャッチアップへの障壁が運用コストを上げた運用コストも分解すると、事業として許容できるコストもあれば機会損失につながるコストもある一口に運用コストといってもその中身を把握することが大事

20 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。施策2 逆コンウェイ戦略に沿ったチーム分割行ったことアプリケーションの開発チームをマイクロサービスに合わせて以下の3つに分割 • ライフログサービスを中心に担当するチーム
• コミュニティサービスを中心に担当するチーム • 基盤系サービスを中心に担当するチーム背景開発チームの人数が増えていた(20人 => 30人 => 40人) 元々は案件に対して人をアサインしていたが、チームとしてのナレッジが貯まらないことやアサインに時間がかかる問題が発生していたそのような状況下で関心の分離をし、開発を並列化して素早く進めたいという要求があった

21 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。逆コンウェイ戦略に沿ったチーム分割の振り返り Good 当初の目的である開発の並列化は達成し、開発自体は早く進むようになった Bad しばらく運用している間に事業部内でのサイロ化が発生ドメイン知識の固定化、責任範囲の限定、チームを超えたプラクティスの共有がされなくなった

22 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策 • 横断的な情報共有の場の設定 • 事業目標に応じたチーム分割 •
サービスオーナー制とチームの役割の定期的な見直し

23 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策：横断的な情報共有の場の設定ないよりはマシだったが、情報共有の場も形骸化した根本的な原因は機会がないことよりも構造の問題から発生する無関心

24 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策：事業目標に応じたチーム分割マイクロサービスをベースにチームを分けるのではなく、事業目標をベースにしたチームの分割に変更達成したこと • 各チームで新しくドメイン知識を獲得する必要はあったが、知識の冗長化が行えた
• 開発を担当するサービス領域がいい意味でファジーになり、柔軟にアサインが行えるようになった一方で、チームとチームの間で責任者が不在となるサービスが生まれ、メンテナンス基準、実装方針が1サービス内で統一されない問題が起きた

25 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。対策：サービスオーナー制とチームの役割の定期的な見直しサービスごとにオーナーとなる開発チームを設定し、メンテナンスやコード品質の責任を負うようにした半年に1度、事業目標の見直しに合わせてオーナーチームの見直しを行うようにした達成したこと • 責任者不在サービスはなくなった
• サービスオーナーの定例を通してプラクティスが共有されるようになった

26 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。施策2のまとめ施策の実施前後で見ると最初の施策は合理的な判断だったが、長期で運用するにあたり問題が発生した最初から事業目標に沿ったチーム分割をしていたら当初のアサイン調整の問題が解決できておらず学習コストもかかってしまうため
「チームに案件をアサインする」こと自体が頓挫していた可能性もある組織も最初から完璧な設計を目指さずに都度都度バージョンアップを行っていくことが大事

27 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。システムの設計も組織の設計も判断力をつけるには、「自分で設計したシステムを長い間メンテナンスすること」、、、と考えています「質とスピード（2020秋100分拡大版）」和田卓人 https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition
より引用「一番重要で一番やっかいなスキルはシステムを設計するための判断力」

28 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。まとめ • 技術面/組織面における「とりあえず行った施策」を紹介した • 技術的な施策実施にも事業戦略との整合という観点を入れると可能性が広がることがある •
施策の良し悪しは実施前後だけでなく長期で振り返ってわかることがある

29 CONFIDENTIAL 本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。 We’re hiring ! FiNCではエンジニア/プロダクトマネージャーを積極採用中です！ iOS/Android/Flutter/Rails/SaaSプロダクトにピンときたらご応募ください https://www.wantedly.com/companies/finc/projects

本資料は株式会社FiNC Technologiesの許可なく複製・配布しないようお願いいたします。 CONFIDENTIAL END

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

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

Shinozuka Fumiya

More Decks by Shinozuka Fumiya

Other Decks in Technology

Featured

Transcript