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

【AI要約】
ourly CTO相澤宏亮氏がROSCAFE TECH NIGHT #10で示した「最適なアーキテクチャ」とは、技術的に最良でも最新でもなく「会社・事業成長のボトルネックにならない構造」。

コード→プロダクト→事業→会社と俯瞰し、営業やCSを含む全体フローで詰まりを特定する視座がCTOには不可欠だと説く。ボトルネック化を防ぐ五つの観点は①可視化と分析（CloudWatch・Datadog・Sentryで定点観測）②プログラミング原則の徹底（YAGNI／DRY／KISS／SOLID）③変更の可逆性と不可逆性を見極める判断軸④チームのケイパビリティと採用市場を踏まえた技術選定⑤事業領域ごとの特性（型安全要求、クラウド可否、マルチテナンシーなど）。

“要はバランス”が結論で、CTOは複合的トレードオフを判断し続け、成長を阻害しないアーキテクチャを維持する責任を負うと締めくくった。

Transcript

1. 1 CTOの視点で選ぶ「最適な」アーキテクチャとは？ ~ROSCAFE TECH NIGHT#10~ ourly株式会社 相澤 宏亮 (@tigers_loveng)
2. 2 自己紹介 相澤 宏亮 (あいざわ こうすけ) 役割 執行役員CTO 経歴 2016年：京都大学大学院理学研究科中退 2017年：株式会社PLAN-Bに新卒入社 2020年：株式会社ビットエーに転職 & ourly事業立ち上げ 2023年：ourly株式会社に転籍 # Ruby # PHP # Java # 新卒/中途採用 # 社内ハッカソン その他 # キングダム # ジョジョ # HUNTER×HUNTER # 刃牙 # 新規事業立ち上げ # 野球観戦 # 阪神タイガース好きと繋がりたい
3. 3 会社概要 ourly株式会社（株式会社ビットエー100%子会社） 東京都品川区西五反田一丁目5番1号 A-PLACE五反田駅前ビル５階 2022年4月 代表取締役社長　 坂本 良介 取締役COO 髙橋 新平 取締役 吉田 雅史 取締役 橋本 和樹 正社員20名、業務委託10名 インナーコミュニケーションプラットフォーム「ourly」の企画・開発・販売 「ourly」を用いた組織開発支援 社名 所在地 設立年月 役員構成 従業員数 事業内容
6. 6 今日話すこと 今日話さないこと CTOの視点で選ぶ「最適な」アーキテクチャと は？ なぜ阪神タイガースは日本一になれたのか？ 娘が保育園入園した途端に隔週で体調不良を繰 り返すようになった話 大学時代に検定協会主催のグラップラー刃牙検 定2級を受験して合格した話 新卒1年目にクソミソにFBされて大号泣した話
7. 7 「最適な」アーキテクチャとは？ 「最適なアーキテクチャ」とは、一概に特定の設計パターンやスタイルを指すものではな 、プロジェ クトの固有の要件や制約、目的に最も適したアーキテクチャを意味します。つまり、最適なアーキテク チャはプロジェクトごとに異なり、以下のような要素を総合的に考慮して決定されます。 （中略） 最適なアーキテクチャは、一連のトレードオフの結果として形成されるものです。全ての要件を完全に 満たす完璧なアーキテクチャは存在しないため、プロジェクトの目的や優先順位に基づいて最も重要な 要素に焦点を当てること 重要です。適切なアーキテクチャ設計は、プロジェクトの成功に直結し、長 期的なビジネス価値をもたらします。 ChatGPT o1-previewより
8. 8 「最適な」アーキテクチャとは？ 「最適なアーキテクチャ」とは、一概に特定の設計パターンやスタイルを指すものではな 、プロジェ クトの固有の要件や制約、目的に最も適したアーキテクチャを意味します。つまり、最適なアーキテク チャはプロジェクトごとに異なり、以下のような要素を総合的に考慮して決定されます。 （中略） 最適なアーキテクチャは、一連のトレードオフの結果として形成されるものです。全ての要件を完全に 満たす完璧なアーキテクチャは存在しないため、プロジェクトの目的や優先順位に基づいて最も重要な 要素に焦点を当てること 重要です。適切なアーキテクチャ設計は、プロジェクトの成功に直結し、長 期的なビジネス価値をもたらします。 ChatGPT o1-previewより
9. 9 「最適な」アーキテクチャとは？ で、でた～wwwww要はバランスおじさん奴～wwwww
10. 10 「最適な」アーキテクチャとは？ で、でた～wwwww要はバランスおじさん奴～wwwww
11. 11 「最適な」アーキテクチャとは？ 「最適なアーキテクチャ」とは、一概に特定の設計パターンやスタイルを指すものではな 、プロジェ クトの固有の要件や制約、目的に最も適したアーキテクチャを意味します。つまり、最適なアーキテク チャはプロジェクトごとに異なり、以下のような要素を総合的に考慮して決定されます。 （中略） 最適なアーキテクチャは、一連のトレードオフの結果として形成されるものです。全ての要件を完全に 満たす完璧なアーキテクチャは存在しないため、プロジェクトの目的や優先順位に基づいて最も重要な 要素に焦点を当てること 重要です。適切なアーキテクチャ設計は、プロジェクトの成功に直結し、長 期的なビジネス価値をもたらします。 ChatGPT o1-previewより
12. 12 「最適な」アーキテクチャとは？ アーキ テクチャ ビジネス アーキ テクチャ ビジネス アーキテクチャとビジネスは別物ではな 、ビジネスを構成する要素としてアーキテク チャ ある
13. 13 「最適な」アーキテクチャとは？ そもそも「アーキテクチャ」ってなんだ？
14. 14 「最適な」アーキテクチャとは？ 「アーキテクチャ」（architecture）は、一般的に「構造」や「設計」を意味する言葉です。以下のよ うな分野で使われます： 1. 建築分野：建物や構造物の設計やデザインを指します。 2. 情報技術分野： a. ハードウェアアーキテクチャ：コンピュータや電子機器の物理的な構造や設計。 b. ソフトウェアアーキテクチャ：ソフトウェアやアプリケーションの構造、モジュール間の関 係性やデータの流れ。 c. システムアーキテクチャ：システム全体の構成要素やそれらの相互作用。 3. 組織・ビジネス分野：組織の構造や業務プロセスの設計。 「アーキテクチャ」は、複雑なシステムや構造を整理し、全体像を把握するための概念として使われま す。 ChatGPT o1-previewより
15. 15 「最適な」アーキテクチャとは？ 会社 事業 プロダクト アーキ テクチャ アーキテクチャはプロダクトの一要素であり、プロダクトは事業の一要素、事業は会社の 一要素である
16. 16 「最適な」アーキテクチャとは？
17. 17 「最適な」アーキテクチャとは？ 事業を要素分解してい と、営業/マーケ/CS/開発/コーポレート...etc のどこにボトル ネック ある 分 る 例） • リード数に対するアポ率 業界平均と比較して著し 低い → IS ボトルネック • 機能差分 ない状態でコンペに負けること 多い → 営業 ボトルネック • 逆に失注理由として機能面の理由 多い → プロダクト ボトルネック
18. 18 「最適な」アーキテクチャとは？ プロダクト 成長のボトルネックになる時、（PMFしているプロダクトであれば）プロダ クトそのものではな 、構成する要素 ボトルネック化していると考えられる 例） • 技術負債 貯まり、見積もりと実績の差分 大 い → コード品質 ボトルネック • インフラ 貧弱で負荷に耐えられない → インフラアーキテクチャ ボトルネック • CI/CD 頻繁に止まりデプロイで ない → 自動化アーキテクチャ ボトルネック
19. 19 「最適な」アーキテクチャとは？ では逆の状態 最適 というと...？
20. 20 「最適な」アーキテクチャとは？ ミクロな視点で見れば最高ではあるが、事業/会社視点で見た時に最適ではない。 なぜなら単一の視点であり、それ自体 売り上げを1円も生み出すことはないため。 例） • 技術負債 な 、見積もりと実工数の差分 少ない ◦ 1機能あたりの提供リードタイム 長期化しやす なる可能性大 • インフラ 強靭でどんな負荷にも耐えられる ◦ コスト 爆増するので、サービス規模に対してtoo muchの可能性大 • CI/CDはいつでも動いてデプロイ可能になっている ◦ デプロイ対象となる実装物 多 なければ意味 ない
21. 21 「最適な」アーキテクチャとは？ 逆の状態までい ずとも、ボトルネックになっていなければ良いのでは？
22. 22 「最適な」アーキテクチャとは？ ボトルネックは、どの役割の視点で見る によって変わること あり、そもそもプロダク トではないこともある メンバー EM, TL CTO コード品質 低い！リファクタしないと！！ そもそも設計 よ ない！リアーキテクチャしないと！！ しばら は営業/CS ボトルネックになりそうだな。 今のうちにプロダクトのボトルネックを特定して優先順位つけよう。
23. 23 「最適な」アーキテクチャとは？ ボトルネックは、どの役割の視点で見る によって変わること あり、そもそもプロダク トではないこともある メンバー EM, TL CTO コード品質 低い！リファクタしないと！！ そもそも設計 よ ない！リアーキテクチャしないと！！ 会社/事業目線 事業/ プロダクト目線 プロダクト目線 しばら は営業/CS ボトルネックになりそうだな。 今のうちにプロダクトのボトルネックを特定して優先順位つけよう。
24. 24 「最適な」アーキテクチャとは？ つまり、CTOの視点で選ぶ「最適な」アーキテクチャとは、 会社/事業目線で成長のボトルネックになっていないアーキテクチャ のことである
25. 25 以上、ご清聴あり とうございました！
26. 26 現地 限定 )6/5&3ʷ)6/5&3ΑΓ ύʔϜ͕ΰϯʹʮ͸ʁԿ
    ݴͬͯΜͷʁʯ ͱϚδΪϨ͢Δγʔϯ
27. 27 現地 限定 ஍໘ࢣͨͪΑΓ ϐΤʔϧ୍ԋ͡Δΰτʔ͕ʮ΋͏͑͑Ͱ͠ΐʯ ͱݴ͍ͬͯΔγʔϯʹ ʮΩϨΠΰτ͸΋͏͑͑Ͱ͠ΐ͏ʁʯ ͱ͍͏ηϦϑΛೖΕͨը૾
28. 28 現地 限定 ஍໘ࢣͨͪΑΓ ϐΤʔϧ୍ԋ͡Δΰτʔ͕ʮ΋͏͑͑Ͱ͠ΐʯ ͱݴ͍ͬͯΔγʔϯʹ ʮ࣮ࡍͷͱ͜ΖͲ͏ͳͷ͔ ݟͤͯ΋ΒΘͳ෼͔Γ·ͤΜΘʯ ͱ͍͏ηϦϑΛೖΕͨը૾
29. 29 ということで、アーキテクチャ ボトルネック化しないための観点を 事例とともにい つ 紹介します。
30. 振り返ってみて大事だなと思った5つの観点をピックアップ✍ • 可視化と分析 • プログラミング原則の理解と徹底 • 変更の可逆性/不可逆性の考慮 • チームのケイパビリティ • 事業領域ごとの特性 30 ボトルネック化しないために
31. 31 ボトルネック化しないために ~可視化と分析~ ピックアップ観点 • 測定で ないものは改善で ない • 各種ログや負荷を可視化して分析することでボトルネック化することを事 前に気づいて対策を打つこと で る • また、不具合調査の際に根本原因を特定で ることで調査、対応工数を減 らすこと で る ボトルネック化した時の リスク例 • 「動作 重い」「表示 遅い」という問い合わせに対応/回答 で ない • 不具合の原因 ユーザー側の操作なの 、自社側のシステム欠陥なの 切 り分け で ない
32. 32 ボトルネック化しないために ~可視化と分析~ 現地 限定 ourlyではCloudWatch/Datadog/Sentryを導入して可視化し、スプリントレビューの時 にエラーログとサーバー負荷の定点観測(分析)を行っている εϓϦϯτϨϏϡʔͰ෼ੳ಺༰ͷεΫγϣ
33. 33 ボトルネック化しないために ~プログラミング原則の理解と徹底~ ピックアップ観点 • モノリス/モジュラモノリス/マイクロサービスなど、どんなシステムアー キテクチャも元を辿ればソースコード(プログラミング)に行き着くので、 原理原則(YAGNI, DRY, KISS, SOLID…)の徹底 大事 • コード品質 高ければ後で改修を加える時にもボトルネック化しに い ボトルネック化した時の リスク例 • スパゲティ化したコードにより、開発時の工数 肥大化 • リアーキテクチャ時にコード分離の難易度 爆増
34. 34 ボトルネック化しないために ~プログラミング原則の理解と徹底~ 現地 限定 usersテーブルに関連する データの更新用メソッド • メール送信有無の判定 • 送信するメールの種類の 判定 • ログインIDにメアド or 任 意文字列を割り当てる判 定 • … 単一責任の原則を ガン無視 ߦҎ্͋Δ ߋ৽ϝιουͷ ιʔείʔυ
35. 35 ボトルネック化しないために ~プログラミング原則の理解と徹底~ 現地 限定 usersテーブルに関連する データの更新用メソッド • メール送信有無の判定 • 送信するメールの種類の 判定 • ログインIDにメアド or 任 意文字列を割り当てる判 定 • … 単一責任の原則を ガン無視 ߦҎ্͋Δ ߋ৽ϝιουͷ ιʔείʔυ ੹೚ΛҰͭʹߜΓ ϦϑΝΫλͯ͠ ߦఔ౓ʹͳͬͨ ߋ৽ϝιουͷ ιʔείʔυ
36. 36 ボトルネック化しないために ~変更の可逆性/不可逆性の考慮~ ピックアップ観点 • 変更の意思決定を行う際に、その変化 可逆的 、不可逆的 を見極め、 不可逆的な変化の場合は慎重に！ • 可逆的であっても時間経過とともに難易度があがり、実質不可逆になりう ることもある ボトルネック化した時の リスク例 • 間に合わせで入れたライブラリに依存したコード 量産されてしまい、リ プレイスで ない • 既存クラスの影響範囲 大 す て手を入れられない
37. 37 現地 限定 ボトルネック化しないために ~変更の可逆性/不可逆性の考慮~ (不可逆になりやすい例として思いついた)インフラアーキテクチャとテスト文化に関して やって いてよ ったこと インフラアーキテクチャ • 初期構築時に社外のインフラ専門家に設計レビューとIaC導入をリードしてもらった ◦ ある程度強靭なアーキテクチャを構築してもらった げでインフラ周りの運用工数を グッと減らせた ◦ 一旦最低限のインフラで構築して後 ら増強していこうは そら で な った • セキュリティチェックシートの記入の際にも良いこと ありました！ テスト文化 • 恥ず しな ら前職はテスト文化 な 、元々は後で書けばええやろという精神だった • ourly立ち上げ時に、テックリード テスト書 ことを強制して れた げでデグレの心 配な 開発スピードを担保で ている • もし後でテスト拡充しようという考えだったら そら 今もテスト一部し 書いてないと思 われる
38. 38 ボトルネック化しないために ~チームのケイパビリティ~ ピックアップ観点 • 技術選定は、自分たちが扱える技術と採用市場を考慮に入れて行わないと ボトルネック化する可能性が高くなる • 特に1人エンジニア 自分の好みで技術選定したものの辞めてしまい誰も 触れないシステムになってしまったなんて例も多々... ボトルネック化した時の リスク例 • 採用難易度の高い技術選定を行った結果、リソース不足に陥る • 使いこなせない技術を組み込んだ結果、問題解決に必要以上に工数を取ら れてしまう
39. ourly立ち上げ時の技術選定軸 39 ボトルネック化しないために ~チームのケイパビリティ~ • FE, BEともに既存メンバー 扱える技 術であること • 採用難易度 高 ないこと • スピーディに開発で ること • コミュニティ 活発でバージョンアッ プ 定期的になされていること
40. 40 ボトルネック化しないために ~事業領域ごとの特性~ ピックアップ観点 • 事業領域ごとにプロダクトの特性があり、開発上の留意点がある • 例えばSLAガチガチに固める必要 ある事業領域に対しては、一旦出して みて改善していこう！は通用しに い ボトルネック化した時の リスク例 • 営業時にそもそも検討のテーブルにすら乗せてもらえない • プロダクトへの信頼 損なわれて解約、競合への乗り換えに繋 る
41. 41 現地 限定 ボトルネック化しないために ~事業領域ごとの特性~ 事業領域によってはボトルネック化する可能性 あるもの 静的型付け言語 or 　動的型付け言語 • 厳格なパフォーマンス性能 要求されるような事業だと静的型付け言語の方 有利に働 こと 多い • ourlyでは、同時編集などの機能は不要と判断し、パフォーマンス性能に関してはある程 度妥協で ること 分 っていたので動的型付け言語(Ruby)を選択 クラウド or 　オンプレ • 保管するデータの秘匿性要件 厳しいと、クラウドNGのところもある • ourlyでは、社内報にそこまで秘匿性要件 厳しい内容を記載する会社は少ないと踏んで クラウド(AWS)を選択 専有サーバー or 　マルチテナンシー • データの秘匿性に加えて高い可用性を求められる場合、専有サーバー 必要なところもあ る • ourlyでは、同じHR領域のSaaS(SmartHRなど)の事例を調べてマルチテナンシーを選択
42. 42 ボトルネック化しないために それぞれの観点を複数組み合わせて意思決定してい こと 「最適な」アーキテクチャに は必要である • 可視化と分析 • プログラミング原則の理解と徹底 • 変更の可逆性/不可逆性の考慮 • チームのケイパビリティ • 事業領域ごとの特性
43. 43 ボトルネック化しないために 要はバランスですね
44. 44 改めてご清聴あり とうございました！