Real_World_Replacement_PJ.pdf

Transcript

1. Real World Replacement PJ 2023年 8月24日 株式会社カラダノート　堀内 栄一 ー アーキテクトの視点から ー
2. About
3. 自己紹介 名前 堀内 栄一 出身地 和歌山県　のとても山奥 役割 プロダクト本部長兼VPoE 経歴 ・A社（SIer, SES） ・B社（自社開発系のベンチャー） ・C社（スタートアップ） ・株式会社カラダノート（現職） → 4社中3社でリプレースを経験しました SNS https://twitter.com/horiuchie1 https://www.wantedly.com/id/eiichi_horiuchi 得意分野 アーキテクト、宣言的 /関数型、データ分析、 Vim、泥臭さ、...etc
4. カラダノートについて 会社名 株式会社カラダノート 代表 佐藤　竜也 ビジョン 家族の健康を支え 笑顔をふやす バリュー 仕事もプロ　家族もプロ 成長が生む幸せ 全てはビジョンに向けたストーリー 設立 2008年 12月 24日 従業員数 49名（2023年1月時点） 証券コード 4014（東京証券取引所グロース市場）　 2020年10月27日 上場 エンジニア向け資料 https://bit.ly/3sCE3c8
5. 事業概要
6. ビジネスモデル
7. それは3年前・・・
8. ３年前のシステム
9. 最後に残った箇所（赤枠の部分）の問題点・・・ • 当社ビジネスのメイン部分のアプリケーション • 「機能追加の改修スピードが遅い」或いは「急ぐと事故になる」 ◦ 要件 ~ 外部設計： ▪ 現仕様を把握して改修内容をFixさせる工程に時間がかかっていた ▪ 想定外の負荷（非機能要件）による障害 ◦ 詳細設計 ~ 実装： ▪ 多くのハードコード ▪ 組み合わせのパターンが多い ▪ バッチの個数42個（いずれも3 ~ 5分おきに動く） ◦ テスト面 ▪ 他の仕様を壊さないように
10. 参考）多くのハードコード および 42個バッチの抜粋
11. アプローチ
12. どうやってリプレースするか = アーキテクトの出番 ソフトウェアアーキテクトには主に次の 8つが期待される。 1. アーキテクチャ決定を下す 2. アーキテクチャを継続的に分析する 3. 最新のトレンドを把握しつづける 4. 決定の遵守を徹底する 5. 多様なものに触れ、経験している 6. 事業ドメインの知識を持っている 7. 対人スキルを持っている 8. 政治を理解し、かじ取りする 出典：ソフトウェアアーキテクチャの基礎より ▪ リプレースにあたっての泥臭いこと 問題を言語化したり、解決方法を導き出したり、意思決定したり、事業への影響を洗い 出したり、ドメインを整理したり、 ...etc ８つの期待（役割）と一致する
13. 事業ドメインの知識を持っている • 既存のコードを隅から隅まで読む ◦ パターンが256個あるなら全部マトリクスにまとめる ◦ マジックナンバー・識別子などをすべてピックアップしていく ◦ ドメインに関するルール（=不変式）を抽出してまとめていく • なぜこういう仕様なんだろう？既に担当者がいない場合は？ ◦ 不明な点として書き出しておく • 事業に関連する書籍を読む ◦ 営業に関すること ◦ マーケティングに関すること ◦ 法律に関すること ◦ …etc
14. 事業ドメインの知識を持っている • 事業ドメインの知識を身につけると・・・ ◦ ビジネスチームとより突っ込んだ会話・深掘りができる ◦ ビジネスチームさえ気づけない構造や概念に気づくことができる ◦ 書き出していた不明点の解像度が上がる 本屋に行って、端から端まで本を買う 自分の課題に関連する業界の本を端から端まで買うことをお勧めしま す。たとえば飲食業のSaaSビジネスをしたいのなら飲食ビジネスに関連 する本屋を端から端まで買います。 出典：解像度を上げる
15. 政治を理解し、かじ取りする • 前提として 政治 = 社内政治 ではない ◦ コミュニケーションの仕方である ◦ 意思決定の構造を理解して決裁者に最適な提案をすること • 問題を生み出している原因を言語化・蓄積しておく ◦ 決裁者にレポートする前提で ◦ e.g. 組み合わせが複雑、職人しか対応できない、動作確認に時間がかかる、 ...etc • コストや時間は最後の手段 それは最後の手段として使用すべきで、もっと重要な他の正当性や合理的な理由を先に試すべきだ。 コストと時間が交渉の重要な属性であるならば、一旦合意に達したあとでそれを考慮できる 出典：ソフトウェアアーキテクチャの基礎より
16. 問題点の書き出しメモの抜粋 泥臭くコツコツ
17. 多様なものに触れ、経験している 多くのハードコードやバッチは、 マッチングアルゴリズムで表現できることに気づく
18. アーキテクチャ決定を下す オニオンアーキテクチャ ▪ リプレース領域を切り分け e.g. インフラ層で吸収すればDBに変更を食わずにリプ レースできる 影響を及ぼさない （影響範囲の切り分け）
19. アーキテクチャ決定を下す EC2 ECS RDS
20. その他：プロジェクトには名前をつける • 改善余地あり ◦ XXシステムリプレースPJ • Good ◦ XXシステム YY問題改善PJ ◦ XXシステム YYリスク対応PJ ◦ XXシステム ZZモデル反映PJ スコープがはっきりする・ブレない・オーナーシップ
21. 技術まわり Before After • PHP • Laravel • EC2 • Vue2 • JavaScript • テストコードなし • … • Python 3.10（当時） • Fast API • 型検査やLintの強制およびpre-commit連携 • テストコードおよびCI/CD連携 • 循環的複雑度の解析および CI/CD連携 • 脆弱性解析およびCI/CD連携 • TypeScript • Nuxt3 • VS Code Dev Containers • ECS • …
22. 最後に
23. 明日はすぐに変えられない 1年後は必ず（置き）変えられる
24. ありがとうございました 本日の発表、当社についてや個人的なキャリア相談など TwitterからDMくださいませ