Slide 1

Slide 1 text

Real World Replacement PJ 2023年 8月24日 株式会社カラダノート 堀内 栄一 ー アーキテクトの視点から ー

Slide 2

Slide 2 text

About

Slide 3

Slide 3 text

自己紹介 名前 堀内 栄一 出身地 和歌山県 のとても山奥 役割 プロダクト本部長兼VPoE 経歴 ・A社(SIer, SES) ・B社(自社開発系のベンチャー) ・C社(スタートアップ) ・株式会社カラダノート(現職) → 4社中3社でリプレースを経験しました SNS https://twitter.com/horiuchie1 https://www.wantedly.com/id/eiichi_horiuchi 得意分野 アーキテクト、宣言的 /関数型、データ分析、 Vim、泥臭さ、...etc

Slide 4

Slide 4 text

カラダノートについて 会社名 株式会社カラダノート 代表 佐藤 竜也 ビジョン 家族の健康を支え 笑顔をふやす バリュー 仕事もプロ 家族もプロ 成長が生む幸せ 全てはビジョンに向けたストーリー 設立 2008年 12月 24日 従業員数 49名(2023年1月時点) 証券コード 4014(東京証券取引所グロース市場)  2020年10月27日 上場 エンジニア向け資料 https://bit.ly/3sCE3c8

Slide 5

Slide 5 text

事業概要

Slide 6

Slide 6 text

ビジネスモデル

Slide 7

Slide 7 text

それは3年前・・・

Slide 8

Slide 8 text

3年前のシステム

Slide 9

Slide 9 text

最後に残った箇所(赤枠の部分)の問題点・・・ ● 当社ビジネスのメイン部分のアプリケーション ● 「機能追加の改修スピードが遅い」或いは「急ぐと事故になる」 ○ 要件 ~ 外部設計: ■ 現仕様を把握して改修内容をFixさせる工程に時間がかかっていた ■ 想定外の負荷(非機能要件)による障害 ○ 詳細設計 ~ 実装: ■ 多くのハードコード ■ 組み合わせのパターンが多い ■ バッチの個数42個(いずれも3 ~ 5分おきに動く) ○ テスト面 ■ 他の仕様を壊さないように

Slide 10

Slide 10 text

参考)多くのハードコード および 42個バッチの抜粋

Slide 11

Slide 11 text

アプローチ

Slide 12

Slide 12 text

どうやってリプレースするか = アーキテクトの出番 ソフトウェアアーキテクトには主に次の 8つが期待される。 1. アーキテクチャ決定を下す 2. アーキテクチャを継続的に分析する 3. 最新のトレンドを把握しつづける 4. 決定の遵守を徹底する 5. 多様なものに触れ、経験している 6. 事業ドメインの知識を持っている 7. 対人スキルを持っている 8. 政治を理解し、かじ取りする 出典:ソフトウェアアーキテクチャの基礎より ■ リプレースにあたっての泥臭いこと 問題を言語化したり、解決方法を導き出したり、意思決定したり、事業への影響を洗い 出したり、ドメインを整理したり、 ...etc 8つの期待(役割)と一致する

Slide 13

Slide 13 text

事業ドメインの知識を持っている ● 既存のコードを隅から隅まで読む ○ パターンが256個あるなら全部マトリクスにまとめる ○ マジックナンバー・識別子などをすべてピックアップしていく ○ ドメインに関するルール(=不変式)を抽出してまとめていく ● なぜこういう仕様なんだろう?既に担当者がいない場合は? ○ 不明な点として書き出しておく ● 事業に関連する書籍を読む ○ 営業に関すること ○ マーケティングに関すること ○ 法律に関すること ○ …etc

Slide 14

Slide 14 text

事業ドメインの知識を持っている ● 事業ドメインの知識を身につけると・・・ ○ ビジネスチームとより突っ込んだ会話・深掘りができる ○ ビジネスチームさえ気づけない構造や概念に気づくことができる ○ 書き出していた不明点の解像度が上がる 本屋に行って、端から端まで本を買う 自分の課題に関連する業界の本を端から端まで買うことをお勧めしま す。たとえば飲食業のSaaSビジネスをしたいのなら飲食ビジネスに関連 する本屋を端から端まで買います。 出典:解像度を上げる

Slide 15

Slide 15 text

政治を理解し、かじ取りする ● 前提として 政治 = 社内政治 ではない ○ コミュニケーションの仕方である ○ 意思決定の構造を理解して決裁者に最適な提案をすること ● 問題を生み出している原因を言語化・蓄積しておく ○ 決裁者にレポートする前提で ○ e.g. 組み合わせが複雑、職人しか対応できない、動作確認に時間がかかる、 ...etc ● コストや時間は最後の手段 それは最後の手段として使用すべきで、もっと重要な他の正当性や合理的な理由を先に試すべきだ。 コストと時間が交渉の重要な属性であるならば、一旦合意に達したあとでそれを考慮できる 出典:ソフトウェアアーキテクチャの基礎より

Slide 16

Slide 16 text

問題点の書き出しメモの抜粋 泥臭くコツコツ

Slide 17

Slide 17 text

多様なものに触れ、経験している 多くのハードコードやバッチは、 マッチングアルゴリズムで表現できることに気づく

Slide 18

Slide 18 text

アーキテクチャ決定を下す オニオンアーキテクチャ ■ リプレース領域を切り分け e.g. インフラ層で吸収すればDBに変更を食わずにリプ レースできる 影響を及ぼさない (影響範囲の切り分け)

Slide 19

Slide 19 text

アーキテクチャ決定を下す EC2 ECS RDS

Slide 20

Slide 20 text

その他:プロジェクトには名前をつける ● 改善余地あり ○ XXシステムリプレースPJ ● Good ○ XXシステム YY問題改善PJ ○ XXシステム YYリスク対応PJ ○ XXシステム ZZモデル反映PJ スコープがはっきりする・ブレない・オーナーシップ

Slide 21

Slide 21 text

技術まわり 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 ● …

Slide 22

Slide 22 text

最後に

Slide 23

Slide 23 text

明日はすぐに変えられない 1年後は必ず(置き)変えられる

Slide 24

Slide 24 text

ありがとうございました 本日の発表、当社についてや個人的なキャリア相談など TwitterからDMくださいませ