過去の失敗からリアーキテクチャをやらないと判断した理由

Transcript

1. 過去の失敗からリアーキテクチャをやらないと判断 した理由 @nyo_taro
2. 井上 翔太朗(@nyo_taro) セールステックのPM/EM 特徴 ・JOB理論/DDD ・好きなエディタはVSCode ・コーヒーは最近浅煎りの酸味系 自己紹介 @nyo_taro
3. スタート期に大規模なリアーキテクチャの判断の事例として、失敗を共有させ ていただきます。 ※リファクタリングなどの取り組みや負債解消をやらない話ではありません 前提 @nyo_taro
4. @nyo_taro
5. @nyo_taro
6. @nyo_taro
7. @nyo_taro
8. @nyo_taro
9. 私の過去のリアーキテクチャで失敗 BALES CLOUDの歴史的な技術的負債 リアーキテクトするかの判断 今回のはなすこと @nyo_taro
10. 私の過去のリアーキテクチャでの失敗 @nyo_taro
11. このような開発があった 作っているプロダクト 予約管理システム 使用している技術 JQueryとCoffeeScriptの組み合わせ 泥団子化したPHP 体制 PM：1人 エンジニア：2人 @nyo_taro
12. このときのプロダクトの技術的負債 スパゲッティコード 仕様書やテストがないので、挙動がわからない etc... とはいえ、プロダクトはユーザーから求められる機能は多くあったので、新機 能追加は必要だった @nyo_taro
13. 当時の決断： リアーキテクトをする 新たな機能追加がしやすいようにドメインを整理する 現在の機能を新しい技術に移行し、保守性をあげる JQueryとCoffeeScript = > AngularJS 泥団子化したPHP => ASP.NET MVC @nyo_taro
14. 開発生産性は上がったが.. プロダクト価値の向上につながるリアーキテクトにならなかった @nyo_taro
15. 失敗した理由 プロダクトの状態を理解していない コアドメインとして今後アップデートするものはなにか？ プロダクトはどのフェーズか？でどの立ち位置か？ 課題や解決した先の価値を理解していない どんな技術的な課題を解決したいのか？ 理想の構造とはどんな構造なのか？ @nyo_taro
16. リアーキテクチャの定義 既存のシステムやプログラムの内部構造を変更すること。 外部から見たシステムの動作には影響を与えない。 コードの内部構造のみを変える。 @nyo_taro
17. リアーキテクトの目的(個人的な解釈) 取得したドメイン知識と現状のシステムとの構造的な乖離の解消 現アーキテクチャの構造変化による、新たな価値への挑戦が可能な状態に 開発生産性、体験の向上 @nyo_taro
18. 当時のBALES CLOUDの技術的負債 @nyo_taro
19. @nyo_taro
20. プロトタイプ時期の技術的負債 初期はまだ市場理解などのドメイン理解も浅かったため、誤った抽象度での設 計や機能開発が行われていていた 様々な場当たり的な機能追加による負債 その場対応のコードにより複雑性が増し、新機能追加やバグ修正が困難になっ ていた @nyo_taro
21. スタート期に何をもってリアーキテクトすると判断するか？ @nyo_taro
22. プロダクトの状態を定量/定性で計測する プロダクト価値 ユーザーインタビュー/NPS ノーススターメトリクス プロダクト品質・信頼性 SLI/SLO/エラーバジェット コード品質(循環的複雑度,認知的複雑度,保守的複雑度) プロダクトチーム FourKey、SPACE @nyo_taro
23. コアドメイン周りがその場実装により複雑度が高くなっている この複雑度の高さにより下記が発生していた テスト容易性の低下 バグが発生しやすい状態 全体の開発速度の低下 @nyo_taro
24. 計測結果からやったこと 再度ドメインの整理とリファクタリング より負債を解消しやすくするためののupdate @nyo_taro
25. @nyo_taro
26. 今後 構造的複雑度の計測により、依存関係の問題を可視化する 依存を剥がしつつモジュラーモノリスへの移行を段階的に行っていく @nyo_taro
27. まとめ プロダクト価値や技術的課題の理解が曖昧だとリアーキテクトは失敗する 可能性が高い 計測することで、リアーキテクトするかの判断材料は増える 定性と定量をもとに改善すべき場所とその価値を見極める @nyo_taro