アーキテクチャConference 2024 に現地参加しました！

アーキテクチャConference 2024とは

本カンファレンスでは、ご登壇者の方々に今一度システムの基盤となるアーキテクチャの思考法や手法といった全体像から、他社が実践した具体的な構築事例といった部分像までをお話しいただくことで、アーキテクチャに対する考え方を学び直し、発想を広げられることを目指しています。
https://architecture-con.findy-tools.io/2024/top

開催情報

• 開催日：2024年11月26日
• 会場：浜松町コンベンションホール
• 形式：オフライン・オンラインのハイブリッド開催

印象に残ったセッション

『Modern Trade-off Analysis for Distributed Architectures and Future Software Architecture』分散アーキテクチャにおける現代のトレードオフ分析と今後のソフトウェアアーキテクチャの展望

ソフトウェアアーキテクチャにおいて「最善の設計手法」というものは存在せず、すべてはトレードオフの問題です。しかし、それをどのように判断すべきでしょうか？
その答えは「時と場合による」です。
基調講演では、まず「何に依存するのか？」に答えます。そして、アーキテクトや他のチームメンバーがトレードオフを理解し、評価するためのさまざまな手法やツールを紹介し、サービスの粒度を反復的に設計する方法を解説します。 また、古くなったアーキテクチャを進化させるために必要なメカニズムと構造を明らかにし、適合度関数駆動のアーキテクチャが、どのようにしてコードを通じてアーキテクチャとガバナンスを確立するのかを紹介します。これにより、アーキテクチャの基盤を保ちながら、スケーラブルなアーキテクチャの構築を実現します。

https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/riPVcWaD

登壇資料：Modern-trade-off analysis - Speaker Deck

メモ

• ソフトウェアアーキテクチャの決定には必ずトレードオフが発生する
• トレードオフがない場合は何かを見落としている
• 何度も反復することは避けられない
• アーキテクチャを一回で決定することはできない
• アーキテクチャとデザインは違う
• アーキテクチャにベストプラクティスはない
• 組織として何を優先するか分からないとトレードオフ分析はできない

アーキテクチャのトレードオフの比較をなんとなくでやっていたが、もっと深く分析していこうと思った。

アーキテクトの誕生とこれから ー スタートアップ7年の成長と痛み

ゼロから始めた7年半前、そこにアーキテクトはいなかった。3年前、新プロダクトの開発から構造のリスクを見出し、リアーキテクチャのタスクフォースが始まった。そして、タスクフォースはチームとなり、「ソフトウェア設計のスペシャリスト集団」を目指し始めた。
教育系スタートアップ7年の、事業と組織とアーキテクチャの成長と、痛みをお伝えします。

https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/YpotnBnq

登壇資料: Findy アーキテクチャ Conference 2024/アーキテクト誕生とこれから　スタートアップ 7年の成長と痛み - Speaker Deck

メモ

• エンジニアとして向かい合った結果アーキテクトになった
• アーキテクチャの答え合わせはあとから来る
• コロナ期間になり、web対応が急務になったが、1週間で対応できた。アーキテクチャの力を実感した
• プロダクト多角化に合わせ、「学習体験」というコアモジュールを括りだすプロジェクトを1年がかりで実施
• アーキテクチャを継続的に改善するKibanチームを作った
• 他チームとの関係性が課題に
  • 気軽にコード相談タイム
  • leanアーキテクチャワークショップ
• 事業多角化に合わせ、2プロダクト3バリューストリームにした

社内でソフトウェア品質を上げていく活動をしているので、Kibanチームの取り組みはとても参考になった。
ぜひ社内でもやっていきたい。

4年で17倍に成長したエンジニア組織を支えるアーキテクチャの過去と未来

企業の請求書DXを加速するインボイス管理サービス「Bill One」では、エンジニア組織が4年間で17倍に急成長しました。Bill Oneでは開発の初期段階からマイクロサービスアーキテクチャを採用し、業務ドメインに基づくサービス分割や非同期メッセージングなどを活用することで、システムの規模を継続的に拡大しています。本セッションでは、これまでの成長の土台となったアーキテクチャの設計方針と、これからの成長に向けた課題を乗り越えるための取り組みについてお話しします。
https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/4FGedrgW

登壇資料: 4年で17倍に成長したエンジニア組織を支えるアーキテクチャの過去と未来 - Speaker Deck

メモ

• 基本方針
  • 静的型付けで保守しやすく
  • マネージドサービスを活用して運用負荷を下げる
  • マイクロサービスでチーム単位の開発をしやすく
• 初期からマイクロサービスにした理由
  • 初期メンバーにモノリスのメンテナンスで苦労した経験
  • プロダクトのピボットに伴いコードを大きく書き換える機会
  • Pythonから変えたいモチベーション
  • モジュラモノリスにしたうえで結合を阻止し続ける自信がなかった
• Monorepo構成で複数サービスを管理
  • 複数のサービスにまたがる変更が一つのPRですむ
• 共通ライブラリ
  • 当初はコピペを許容
  • 1年後に共通で使いたいものがかたまってきたので、ライブラリ化
• 適応度関数
  • レイヤー間の依存ルール違反を検知
  • レイヤごとにテストカバレッジを変える。コントローラは統合テストを中心。ドメインは単体テスト重視

最初はモジュラモノリスからがよいという定石がありつつも、プロダクトやチームの環境を考えてマイクロサービスを選択しているのがよかった。

「ソフトウェア開発の複雑さに立ち向かう」

あらゆるところでソフトウェアが使われる時代になり、ソフトウェアを開発する機会が増え続けています。
しかし、時間や予算という制約条件の中で、複雑で高品質なソフトウェアを生み出し発展させていくことは、簡単な仕事ではありません。
ソフトウェア開発にあらかじめ決まった答えはありません。ソフトウェアを開発するために、私たちエンジニアは探索と発見を繰り返します。つまりソフトウェア開発とは継続的で終わりのない学習活動です。
このセッションでは、次の４つの視点から、エンジニアの学びと成長について考えてみます。

• 解決すべき課題を大きな文脈から理解する
• 多数の小さな一歩を効果的に積み重ねる
• 設計原則を深く理解し、目の前の課題解決と関連づける
• 学びの実践共同体に主体的に参加する

https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/zSXG-jUP

登壇資料: ソフトウェア開発の複雑さに立ち向かう - Speaker Deck

メモ

• VUCA
• 予測しづらくなった
• 限られた時間の中で因果関係の特定が難しくなった
• 事業活動とソフトウェアシステムの変化が一体化
• 事業活動は昔から予測しづらいもの
• ソフトウェアエンジニアが事業活動の当事者になった
• 事業の中核課題=競争優位の獲得と維持を理解する
• ソフトウェアを事業視点で捉える
• OODAループを参考
• 4つのソフトウェアの品質特性で考える
  • 変更容易性
  • 合目的性
  • 経済性
  • 相互運用性
• 事業視点でソフトウェアを設計する

事業視点で設計するというところの意識が低かったと思った。
事業視点を意識しながら設計をしてみて、変わってくるか試してみる。

偶有的複雑性と戦うためのアーキテクチャとチームトポロジー

ログラスでは、開発の複雑性に対応すべく「Enabling & Platform」領域を立ち上げています。さらに、事業やプロダクトの成長に伴い、自己組織化を重視したアジャイルフレームワーク「FAST」を導入し、マルチプロダクト開発に対応すべく自律的なスケールを目指しています。しかしそれに伴って組織とアーキテクチャをどのように整合させるかが課題になりました。今回のセッションでは、Enabling&Platformが開発の高度化に伴う偶有的複雑性にどう対応してきたか、自律的な組織で持続的なアーキテクチャ刷新とケイパビリティ向上の取り組みについてお話いたします。
https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/NK5FQ5v5

登壇資料 : 偶有的複雑性と戦うためのアーキテクチャとチームトポロジー - Speaker Deck

• 本質的複雑性と偶有的
• チームトポロジー
• チームファースト思考
• チームが機能していれば複雑さも上手く扱える
• スクラムからFASTへ
  • スプリントごとにチームを組成するようなイメージ？
• オニオンアーキテクチャ
• パフォーマンス問題があるところをノンコア層にする。プレゼンター、インフラアーキテクチャ
• decompose - reintegrate パターン
• アーキテクチャトポロジー

FAST、アーキテクチャトポロジーなど知らない単語が出てきて学びがあった。
FASTのコレクティブの形成で、まず「自己組織化していて自己管理できる人たちの集まりをつくる」のところがハードル高そうだと感じた。
アーキテクチャの選択肢を広げるという意味でも、メンバーのスキルアップを組織的にやっていく必要があるのかなと思った。

物流システムにおけるリファクタリングとアーキテクチャの再構築〜依存関係とモジュール分割の重要性〜

本発表では、10年の歴史を持つ物流システムにおけるリファクタリングとアーキテクチャ構築の戦略について紹介します。システムのパフォーマンス向上を目的に、変更容易性と拡張性を重視したシンプルなアーキテクチャを構築。従来の複雑な依存関係を整理し、モジュールの分離と役割分担を明確化することで、システムの柔軟性を高め、効率的なリファクタリングを実現しました。適切なモジュール化と、依存関係の整理がアーキテクチャ設計においていかに重要かを、実例を通じて詳述します。
https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/XGHyJ9qU

• 膨大なソースコードと肥大化した重要クラス
• 変更がしづらい
• 引当処理のパフォーマンス課題があった
  • SQL改善などしたが、要求されるパフォーマンスに達していない
  • 数百倍のパフォーマンスアップが必要で、構造の見直しが必要
• DDDは学習コストが高いので使わなかった
• シンプルな設計を目指すために
  • 言葉をむやみに増やさない
  • 不要なパターンや概念を取り入れない
  • 明確な目的を定義する
• 意識したこと
  • モジュールを独立した機能に分割する
  • インターフェイスの明示
  • 依存の方向性を維持する
• リクエストなどの既存のデータを分析し、テストのパターンを網羅した
• 抽象と具体の間を埋める
  • 抽象的な方針を実際のコードで表現し、PRでやりとりして具体の実装のイメージを持ってもらった
• 使われていないコードの削除も大事

DDDなどの考え方を導入せず、シンプルな言葉やプラクティスでアーキテクチャの方向性を示していくのはとても参考にしやすくて良かった。

原 トリさん・matsさんが語る、システム設計の勘所

AWSに在籍されていた際に、数多くの企業やプロダクトのシステム設計に携わり、現在は事業会社で活躍している株式会社カミナシのCTO・原　トリさん、チューリング株式会社のテックリード・matsさんをお招きし、「システム設計の勘所」について語っていただきます。お二人の豊富な知見を、どのように現職において活かしているかを中心に、システム設計において今も昔も変わらない重要なポイントについてディスカッションしていただきます。
https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/2FO71CHw

メモ

• システム設計において今後も変わらず重要であると考えていること
  • 明日リリースだったらAWSではなく、superbaseとかで簡単にできないか考える
  • いつまでに何のために作るか？そのチームがどれだけ運用できるのか？自分たちを取り巻く環境があったうえで、最後に継続可能な開発ができるかを考える
  • 将来を予測するけど分からない。無駄になることはある
  • 違和感、変化を見つけたときにそこに追従する、無視しない
  • システム設計において、全てのものは変わると考える
  • 変化し続けるものだけが生き残る
• もし自社でリアーキテクト、リプレイスをするなら
  • データレイクのリデザインしている
    • 動画を20秒単位で持っているが、欲しい最小単位がフレームになることがわかってきた
    • このままだと将来的なアジリティが下がりそうなことがわかってきて変えている
  • 4年もののプロダクトがひとつある
    • バッチ処理が結構な頻度で落ちる
    • その復旧がシニアエンジニアが毎度秘伝のタレでやっていて、そのエンジニアの作業が止まっていた
    • 運用上のコストが高くなっていたので作り変えた
  • わかりやすくメリットがあるか、デメリットがあれば意思決定がしやすい
  • もしお金があればまるっと作り変えると思う
  • データがあるものは変えづらい
• サービスが伸びていくタイミングにおいて、いつリアーキテクチャをするのがいいのか
  • サービスが伸びてるなら、採用が増やしてリアーキテクチャ専門チームとか作るかも
  • プロジェクトチームではなく、プロダクトチームでリファクタリングできそうな方法を探る
  • 退職リスクを考えて、ビジネスのアクセルを踏み続けるか、ビジネスを緩めてプロダクトを改善するか
  • 開発を止めて改善して、生産性戻りませんでしたは良くない
  • 課題が特定できてれば良いと思う
  • フルスクラッチしたいという時はだいたい何か間違っている
  • 実現したいことをちゃんとトップに据える
• 最後
  • 直感で良さそうだと分かる時があるが、それを説明するのがとても大変
  • それを適切に言語化できるようにちゃんとやる必要がある
  • 最初の直感が70%ぐらいしかあってないことがある
  • 自分でドキュメントに起こして、論理的に間違ってないことを確かめる
  • 言語化大事

学びのまとめ

Q.どうやってアーキテクチャを決めるのか

アーキテクチャにベストプラクティスはなく、アーキテクチャには必ずトレードオフがある
トレードオフからどれを重視するかは時と場合による
アーキテクチャを決めるための環境は事業方針やプロダクト戦略、チームのスキルセットなど多岐にわたる
環境からトレードオフを分析し、今選択できる最適なアーキテクチャを決める

Q.いつリアーキテクチャするのか

将来に向けてわかりやすくメリットがあるとき（例：データの持ち方を変えることで今後の分析のサイクルの速度を維持できる）
もしくは今わかりやすくデメリットがあるとき（例：事業の成長に合わせてプロダクトをスケールさせていくには今のアーキテクチャではパフォーマンスがボトルネックになり間に合わない）
リアーキテクチャするなら課題が明確になっていることが大事
課題が明確でないリアーキテクチャは、アーキテクチャは変えたけどメリットが出ないということがありうる

最後に

「アーキテクチャにはトレードオフがあり、どれを重視するかは時と場合による。目的や課題を持ってアーキテクチャを変えていく。」ということを1日通して感じた日でした！
現地参加したのですが、アーキテクチャへの熱気を感じてとても刺激的でした。
もっとアーキテクチャ力を高めていきたいと思います！