CTOの視点で選ぶ「最適な」アーキテクチャとは？ / What is the "optimal" architecture to choose from the CTO's perspective?

by KosukeAizawa

Slide 1

Slide 1 text

1 CTOの視点で選ぶ「最適な」アーキテクチャとは？ ~ROSCAFE TECH NIGHT#10~ ourly株式会社相澤宏亮 (@tigers_loveng)

Slide 2

Slide 2 text

2 自己紹介相澤宏亮 (あいざわこうすけ) 役割執行役員CTO 経歴 2016年：京都大学大学院理学研究科中退 2017年：株式会社PLAN-Bに新卒入社 2020年：株式会社ビットエーに転職 & ourly事業立ち上げ 2023年：ourly株式会社に転籍 # Ruby # PHP # Java # 新卒/中途採用 # 社内ハッカソンその他 # キングダム # ジョジョ # HUNTER×HUNTER # 刃牙 # 新規事業立ち上げ # 野球観戦 # 阪神タイガース好きと繋がりたい

Slide 3

Slide 3 text

3 会社概要 ourly株式会社（株式会社ビットエー100%子会社）東京都品川区西五反田一丁目5番1号 A-PLACE五反田駅前ビル５階 2022年4月代表取締役社長　坂本良介取締役COO 髙橋新平取締役吉田雅史取締役橋本和樹正社員20名、業務委託10名インナーコミュニケーションプラットフォーム「ourly」の企画・開発・販売「ourly」を用いた組織開発支援社名所在地設立年月役員構成従業員数事業内容

Slide 4

Slide 4 text

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

6 今日話すこと今日話さないこと CTOの視点で選ぶ「最適な」アーキテクチャとは？なぜ阪神タイガースは日本一になれたのか？娘が保育園入園した途端に隔週で体調不良を繰り返すようになった話大学時代に検定協会主催のグラップラー刃牙検定2級を受験して合格した話新卒1年目にクソミソにFBされて大号泣した話

Slide 7

Slide 7 text

7 「最適な」アーキテクチャとは？「最適なアーキテクチャ」とは、一概に特定の設計パターンやスタイルを指すものではな、プロジェクトの固有の要件や制約、目的に最も適したアーキテクチャを意味します。つまり、最適なアーキテクチャはプロジェクトごとに異なり、以下のような要素を総合的に考慮して決定されます。（中略）最適なアーキテクチャは、一連のトレードオフの結果として形成されるものです。全ての要件を完全に満たす完璧なアーキテクチャは存在しないため、プロジェクトの目的や優先順位に基づいて最も重要な要素に焦点を当てること重要です。適切なアーキテクチャ設計は、プロジェクトの成功に直結し、長期的なビジネス価値をもたらします。 ChatGPT o1-previewより

Slide 8

Slide 8 text

8 「最適な」アーキテクチャとは？「最適なアーキテクチャ」とは、一概に特定の設計パターンやスタイルを指すものではな、プロジェクトの固有の要件や制約、目的に最も適したアーキテクチャを意味します。つまり、最適なアーキテクチャはプロジェクトごとに異なり、以下のような要素を総合的に考慮して決定されます。（中略）最適なアーキテクチャは、一連のトレードオフの結果として形成されるものです。全ての要件を完全に満たす完璧なアーキテクチャは存在しないため、プロジェクトの目的や優先順位に基づいて最も重要な要素に焦点を当てること重要です。適切なアーキテクチャ設計は、プロジェクトの成功に直結し、長期的なビジネス価値をもたらします。 ChatGPT o1-previewより

Slide 9

Slide 9 text

9 「最適な」アーキテクチャとは？で、でた～wwwww要はバランスおじさん奴～wwwww

Slide 10

Slide 10 text

10 「最適な」アーキテクチャとは？で、でた～wwwww要はバランスおじさん奴～wwwww

Slide 11

Slide 11 text

11 「最適な」アーキテクチャとは？「最適なアーキテクチャ」とは、一概に特定の設計パターンやスタイルを指すものではな、プロジェクトの固有の要件や制約、目的に最も適したアーキテクチャを意味します。つまり、最適なアーキテクチャはプロジェクトごとに異なり、以下のような要素を総合的に考慮して決定されます。（中略）最適なアーキテクチャは、一連のトレードオフの結果として形成されるものです。全ての要件を完全に満たす完璧なアーキテクチャは存在しないため、プロジェクトの目的や優先順位に基づいて最も重要な要素に焦点を当てること重要です。適切なアーキテクチャ設計は、プロジェクトの成功に直結し、長期的なビジネス価値をもたらします。 ChatGPT o1-previewより

Slide 12

Slide 12 text

12 「最適な」アーキテクチャとは？アーキテクチャビジネスアーキテクチャビジネスアーキテクチャとビジネスは別物ではな、ビジネスを構成する要素としてアーキテクチャある

Slide 13

Slide 13 text

13 「最適な」アーキテクチャとは？そもそも「アーキテクチャ」ってなんだ？

Slide 14

Slide 14 text

14 「最適な」アーキテクチャとは？「アーキテクチャ」（architecture）は、一般的に「構造」や「設計」を意味する言葉です。以下のような分野で使われます： 1. 建築分野：建物や構造物の設計やデザインを指します。 2. 情報技術分野： a. ハードウェアアーキテクチャ：コンピュータや電子機器の物理的な構造や設計。 b. ソフトウェアアーキテクチャ：ソフトウェアやアプリケーションの構造、モジュール間の関係性やデータの流れ。 c. システムアーキテクチャ：システム全体の構成要素やそれらの相互作用。 3. 組織・ビジネス分野：組織の構造や業務プロセスの設計。「アーキテクチャ」は、複雑なシステムや構造を整理し、全体像を把握するための概念として使われます。 ChatGPT o1-previewより

Slide 15

Slide 15 text

15 「最適な」アーキテクチャとは？会社事業プロダクトアーキテクチャアーキテクチャはプロダクトの一要素であり、プロダクトは事業の一要素、事業は会社の一要素である

Slide 16

Slide 16 text

16 「最適な」アーキテクチャとは？

Slide 17

Slide 17 text

17 「最適な」アーキテクチャとは？事業を要素分解していと、営業/マーケ/CS/開発/コーポレート...etc のどこにボトルネックある分る例） ● リード数に対するアポ率業界平均と比較して著し低い → IS ボトルネック ● 機能差分ない状態でコンペに負けること多い → 営業ボトルネック ● 逆に失注理由として機能面の理由多い → プロダクトボトルネック

Slide 18

Slide 18 text

18 「最適な」アーキテクチャとは？プロダクト成長のボトルネックになる時、（PMFしているプロダクトであれば）プロダクトそのものではな、構成する要素ボトルネック化していると考えられる例） ● 技術負債貯まり、見積もりと実績の差分大い → コード品質ボトルネック ● インフラ貧弱で負荷に耐えられない → インフラアーキテクチャボトルネック ● CI/CD 頻繁に止まりデプロイでない → 自動化アーキテクチャボトルネック

Slide 19

Slide 19 text

19 「最適な」アーキテクチャとは？では逆の状態最適というと...？

Slide 20

Slide 20 text

20 「最適な」アーキテクチャとは？ミクロな視点で見れば最高ではあるが、事業/会社視点で見た時に最適ではない。なぜなら単一の視点であり、それ自体売り上げを1円も生み出すことはないため。例） ● 技術負債な、見積もりと実工数の差分少ない ○ 1機能あたりの提供リードタイム長期化しやすなる可能性大 ● インフラ強靭でどんな負荷にも耐えられる ○ コスト爆増するので、サービス規模に対してtoo muchの可能性大 ● CI/CDはいつでも動いてデプロイ可能になっている ○ デプロイ対象となる実装物多なければ意味ない

Slide 21

Slide 21 text

21 「最適な」アーキテクチャとは？逆の状態までいずとも、ボトルネックになっていなければ良いのでは？

Slide 22

Slide 22 text

22 「最適な」アーキテクチャとは？ボトルネックは、どの役割の視点で見るによって変わることあり、そもそもプロダクトではないこともあるメンバー EM, TL CTO コード品質低い！リファクタしないと！！そもそも設計よない！リアーキテクチャしないと！！しばらは営業/CS ボトルネックになりそうだな。今のうちにプロダクトのボトルネックを特定して優先順位つけよう。

Slide 23

Slide 23 text

23 「最適な」アーキテクチャとは？ボトルネックは、どの役割の視点で見るによって変わることあり、そもそもプロダクトではないこともあるメンバー EM, TL CTO コード品質低い！リファクタしないと！！そもそも設計よない！リアーキテクチャしないと！！会社/事業目線事業/ プロダクト目線プロダクト目線しばらは営業/CS ボトルネックになりそうだな。今のうちにプロダクトのボトルネックを特定して優先順位つけよう。

Slide 24

Slide 24 text

24 「最適な」アーキテクチャとは？つまり、CTOの視点で選ぶ「最適な」アーキテクチャとは、会社/事業目線で成長のボトルネックになっていないアーキテクチャのことである

Slide 25

Slide 25 text

25 以上、ご清聴ありとうございました！

Slide 26

Slide 26 text

26 現地限定 )6/5&3ʷ)6/5&3ΑΓ ύʔϜ͕ΰϯʹʮ͸ʁԿݴͬͯΜͷʁʯ ͱϚδΪϨ͢Δγʔϯ

Slide 27

Slide 27 text

27 現地限定 ஍໘ࢣͨͪΑΓ ϐΤʔϧ୍ԋ͡Δΰτʔ͕ʮ΋͏͑͑Ͱ͠ΐʯ ͱݴ͍ͬͯΔγʔϯʹ ʮΩϨΠΰτ͸΋͏͑͑Ͱ͠ΐ͏ʁʯ ͱ͍͏ηϦϑΛೖΕͨը૾

Slide 28

Slide 28 text

28 現地限定 ஍໘ࢣͨͪΑΓ ϐΤʔϧ୍ԋ͡Δΰτʔ͕ʮ΋͏͑͑Ͱ͠ΐʯ ͱݴ͍ͬͯΔγʔϯʹ ʮ࣮ࡍͷͱ͜ΖͲ͏ͳͷ͔ ݟͤͯ΋ΒΘͳ෼͔Γ·ͤΜΘʯ ͱ͍͏ηϦϑΛೖΕͨը૾

Slide 29

Slide 29 text

29 ということで、アーキテクチャボトルネック化しないための観点を事例とともにいつ紹介します。

Slide 30

Slide 30 text

振り返ってみて大事だなと思った5つの観点をピックアップ✍ ● 可視化と分析 ● プログラミング原則の理解と徹底 ● 変更の可逆性/不可逆性の考慮 ● チームのケイパビリティ ● 事業領域ごとの特性 30 ボトルネック化しないために

Slide 31

Slide 31 text

31 ボトルネック化しないために ~可視化と分析~ ピックアップ観点 ● 測定でないものは改善でない ● 各種ログや負荷を可視化して分析することでボトルネック化することを事前に気づいて対策を打つことでる ● また、不具合調査の際に根本原因を特定でることで調査、対応工数を減らすことでるボトルネック化した時のリスク例 ● 「動作重い」「表示遅い」という問い合わせに対応/回答でない ● 不具合の原因ユーザー側の操作なの、自社側のシステム欠陥なの切り分けでない

Slide 32

Slide 32 text

32 ボトルネック化しないために ~可視化と分析~ 現地限定 ourlyではCloudWatch/Datadog/Sentryを導入して可視化し、スプリントレビューの時にエラーログとサーバー負荷の定点観測(分析)を行っている εϓϦϯτϨϏϡʔͰ෼ੳ಺༰ͷεΫγϣ

Slide 33

Slide 33 text

33 ボトルネック化しないために ~プログラミング原則の理解と徹底~ ピックアップ観点 ● モノリス/モジュラモノリス/マイクロサービスなど、どんなシステムアーキテクチャも元を辿ればソースコード(プログラミング)に行き着くので、原理原則(YAGNI, DRY, KISS, SOLID…)の徹底大事 ● コード品質高ければ後で改修を加える時にもボトルネック化しにいボトルネック化した時のリスク例 ● スパゲティ化したコードにより、開発時の工数肥大化 ● リアーキテクチャ時にコード分離の難易度爆増

Slide 34

Slide 34 text

34 ボトルネック化しないために ~プログラミング原則の理解と徹底~ 現地限定 usersテーブルに関連するデータの更新用メソッド ● メール送信有無の判定 ● 送信するメールの種類の判定 ● ログインIDにメアド or 任意文字列を割り当てる判定 ● … 単一責任の原則をガン無視 ߦҎ্͋Δ ߋ৽ϝιουͷ ιʔείʔυ

Slide 35

Slide 35 text

35 ボトルネック化しないために ~プログラミング原則の理解と徹底~ 現地限定 usersテーブルに関連するデータの更新用メソッド ● メール送信有無の判定 ● 送信するメールの種類の判定 ● ログインIDにメアド or 任意文字列を割り当てる判定 ● … 単一責任の原則をガン無視 ߦҎ্͋Δ ߋ৽ϝιουͷ ιʔείʔυ ੹೚ΛҰͭʹߜΓ ϦϑΝΫλͯ͠ ߦఔ౓ʹͳͬͨ ߋ৽ϝιουͷ ιʔείʔυ

Slide 36

Slide 36 text

36 ボトルネック化しないために ~変更の可逆性/不可逆性の考慮~ ピックアップ観点 ● 変更の意思決定を行う際に、その変化可逆的、不可逆的を見極め、不可逆的な変化の場合は慎重に！ ● 可逆的であっても時間経過とともに難易度があがり、実質不可逆になりうることもあるボトルネック化した時のリスク例 ● 間に合わせで入れたライブラリに依存したコード量産されてしまい、リプレイスでない ● 既存クラスの影響範囲大すて手を入れられない

Slide 37

Slide 37 text

37 現地限定ボトルネック化しないために ~変更の可逆性/不可逆性の考慮~ (不可逆になりやすい例として思いついた)インフラアーキテクチャとテスト文化に関してやっていてよったことインフラアーキテクチャ ● 初期構築時に社外のインフラ専門家に設計レビューとIaC導入をリードしてもらった ○ ある程度強靭なアーキテクチャを構築してもらったげでインフラ周りの運用工数をグッと減らせた ○ 一旦最低限のインフラで構築して後ら増強していこうはそらでなった ● セキュリティチェックシートの記入の際にも良いことありました！テスト文化 ● 恥ずしなら前職はテスト文化な、元々は後で書けばええやろという精神だった ● ourly立ち上げ時に、テックリードテスト書ことを強制してれたげでデグレの心配な開発スピードを担保でている ● もし後でテスト拡充しようという考えだったらそら今もテスト一部し書いてないと思われる

Slide 38

Slide 38 text

38 ボトルネック化しないために ~チームのケイパビリティ~ ピックアップ観点 ● 技術選定は、自分たちが扱える技術と採用市場を考慮に入れて行わないとボトルネック化する可能性が高くなる ● 特に1人エンジニア自分の好みで技術選定したものの辞めてしまい誰も触れないシステムになってしまったなんて例も多々... ボトルネック化した時のリスク例 ● 採用難易度の高い技術選定を行った結果、リソース不足に陥る ● 使いこなせない技術を組み込んだ結果、問題解決に必要以上に工数を取られてしまう

Slide 39

Slide 39 text

ourly立ち上げ時の技術選定軸 39 ボトルネック化しないために ~チームのケイパビリティ~ ● FE, BEともに既存メンバー扱える技術であること ● 採用難易度高ないこと ● スピーディに開発でること ● コミュニティ活発でバージョンアップ定期的になされていること

Slide 40

Slide 40 text

40 ボトルネック化しないために ~事業領域ごとの特性~ ピックアップ観点 ● 事業領域ごとにプロダクトの特性があり、開発上の留意点がある ● 例えばSLAガチガチに固める必要ある事業領域に対しては、一旦出してみて改善していこう！は通用しにいボトルネック化した時のリスク例 ● 営業時にそもそも検討のテーブルにすら乗せてもらえない ● プロダクトへの信頼損なわれて解約、競合への乗り換えに繋る

Slide 41

Slide 41 text

41 現地限定ボトルネック化しないために ~事業領域ごとの特性~ 事業領域によってはボトルネック化する可能性あるもの静的型付け言語 or 　動的型付け言語 ● 厳格なパフォーマンス性能要求されるような事業だと静的型付け言語の方有利に働こと多い ● ourlyでは、同時編集などの機能は不要と判断し、パフォーマンス性能に関してはある程度妥協でること分っていたので動的型付け言語(Ruby)を選択クラウド or 　オンプレ ● 保管するデータの秘匿性要件厳しいと、クラウドNGのところもある ● ourlyでは、社内報にそこまで秘匿性要件厳しい内容を記載する会社は少ないと踏んでクラウド(AWS)を選択専有サーバー or 　マルチテナンシー ● データの秘匿性に加えて高い可用性を求められる場合、専有サーバー必要なところもある ● ourlyでは、同じHR領域のSaaS(SmartHRなど)の事例を調べてマルチテナンシーを選択

Slide 42

Slide 42 text

42 ボトルネック化しないためにそれぞれの観点を複数組み合わせて意思決定していこと「最適な」アーキテクチャには必要である ● 可視化と分析 ● プログラミング原則の理解と徹底 ● 変更の可逆性/不可逆性の考慮 ● チームのケイパビリティ ● 事業領域ごとの特性