はじめに
こんにちは！今年新卒で入社した@tetsuwoです！今回はLolipop! for gamersチームを含む社内のパートナーと、2024 年 11 月 26 日 (火)、浜松町コンベンションホール & Hybird スタジオで開催されたアーキテクチャConference 2024に参加してきました！ 本記事ではアーキテクチャカンファレンスに参加した感想や、気になったセッションのご紹介をブログにまとめました！特にアーキテクチャに興味のある方や、弊社のカンファレンス参加に対する視点や活用に興味のある方に見ていただけると幸いです！！
アーキテクチャ Conference 2024 について
本イベントではシステムの基盤となるアーキテクチャについて議論されました。アーキテクチャの知見や思考法から実践事例や具体的な構成まで、さまざまな角度の発表がされたカンファレンスでした。この記事では参加したパートナーが特に面白かったセッションをピックアップして、それぞれの視点での面白みポイントを書いてます！
スポンサーブース巡り
執筆者：@tetsuwo
今回のアーキテクチャカンファレンスでは、多くの企業がスポンサーブースを出展しており、カンファレンスの魅力をさらに引き立てていました。
各ブースでは、アーキテクチャに関するクイズやミニゲームがあり、参加するともらえるノベルティがどれも魅力的でした。ゲーム感覚で学べる内容も多く、技術に関するトリビアや新しい知識を得ながら、気軽に楽しむことができました。
特に嬉しかったのが、オライリージャパンのブースで技術書を20％引きで購入できたことです。普段から欲しいと思っていた本をお得に手に入れることができ、非常に満足感がありました。購入した本は、これからの学びにしっかり活かしたいと思います。
また、カンファレンス全体で行われていたスタンプラリーも素晴らしい企画でした。全30ブースを巡ると巨大ガラポンに挑戦できる特典があり、私もすべてのブースを巡った結果、銀賞のアーキテクチャレゴを景品として手に入れることができました。このレゴはデスクに飾り、日々の業務へのモチベーションアップに役立てようと思います！！
銀賞のアーキテクチャレゴ当たりました！
— tetsuwo (@tetsuwo0717) November 26, 2024
findyさんありがとうございます🙇♀️🙇♀️ #アーキテクチャcon_findy pic.twitter.com/VNPTCWMW6A
さらに、ブースを出していない企業のアーキテクチャ図も数多く展示されており、普段は知ることのできない他社の取り組みや課題解決の方法に触れることができました。実際のプロジェクトで活かせそうなアイデアをたくさん得ることができたのも、大きな収穫でした。
特に印象的だったのは、参加者がアーキテクチャの課題を書いて貼っていく掲示板です。そこには多くの付箋が貼られており、「みんな同じ悩みを持っているのか〜」と共感するものが多くありました。こうした悩みやアイデアを共有する場があることで、参加者同士の交流が深まり、さらに有意義な時間となったと思います。
スポンサーブース巡りは、単なる展示以上に、学びや交流、そして遊び心が詰まった素晴らしい体験でした。来年のカンファレンスでは、今からどのようなブースが出展されるのか、とても楽しみです！
印象に残ったセッションのご紹介
フロント・バック・エッジのどこで計算するか。フルスタック・プロダクトエンジニア的問題解決の事例
執筆者：@nacal
私は普段Webフロントエンドを中心に開発をしているのですが、計算の責務について社内でディスカッションをすることもいくつかあり、講演前から非常に興味をそそられる内容でした。
株式会社Helpfeelさんでは、プロダクトごとにいくつかエッジ、フロントエンドでの計算を取り入れているポイントがあり、いくつか紹介をしてくださった中で特に印象的だったのは、検索SaaSであるHelpfeelにおいて、検索をフロントエンドのWeb Workerで行っているところでした。
サーバーサイドに負荷をかけずにインクリメンタルサーチ（逐次検索）を実現するために、サーバー側では形態素解析などを済ませた情報をJSONとして返却し、フロントエンドではそのJSONをもとに検索を行っているところが、発想になかったので非常に学びになりました。
この選択は、検索SaaSであるHelpfeelが提供する価値として、「高度で高速な検索」があり、それを実現するための選択として非常に合理的な選択であると感じました。
このセッションを聞いて、普段から検索の責務についてなんとなく考えていたことが、より深くなった気がしました。
また、近年ではNext.jsなどのフレームワークによって、フロントエンドのサーバーサイドにおける計算という選択肢もあるため、それぞれの特徴を理解し、プロダクトの優先・大切にするべきことを実現できる最適なものを選択することが重要であると強く感じました。
出前館のマルチプロダクト戦略を支えるアーキテクチャ 〜技術的負債を解消しながら事業を多角化する〜
執筆者：@yoshio
株式会社出前館さんにおける、既存のフードデリバリー事業をノン・フード領域へと拡大するためのマルチプロダクト化に関する発表でした。
ドメインの違いからユースケース/機能が大きく異なることで、既存の機能をうまく共通化しつつ新規開発する必要がありました。
アーキテクチャとしては、コンポーネントごとに分割しマイクロサービス化し、Event Sourcingを採用することで疎結合な設計を実現させていました。
Event Sourcingによる設計は担当プロダクトでも採用しており、また自分にとって新しい概念だったため非常に興味深かったです。
ユースケースのロジックをマイクロサービス化することで、「agilityを向上すること」や「障害時でもシステムが完全に止まらない」という点は、競合優位性へも影響する点で非常に学びになりました。
このセッションを聞いて、機能開発をする際には、ただ実現するだけではなく技術的観点以外にも恩恵を与えられるような設計を心掛けたいなと強く思いました。
イオングループ全体を支えるクリティカルシステム解体新書
執筆者：@tetsuwo
特に印象的だったのは、クラウドインフラとしてMicrosoft Azureを採用している理由の部分です。競合企業との関係性を踏まえた戦略的な選択だけでなく、既存システムとの親和性やエンタープライズソリューションの活用といった視点での判断があり、単なる技術的選択ではない深い背景があることが理解できました。
また、システム全体をSystem of Engagement、System of Record、System of Managementの3層に分割し、それぞれが責務を持ちながらも密接に連携して情報をやり取りするアーキテクチャ設計も非常に興味深かったです。特に、信頼性向上のためにPagerDutyやNewRelicを活用して、監視とアラートの統合を実現している取り組みは、自分のプロジェクトでも活かせる学びが多いと感じました。
このセッションを通じて、技術的選択をする際には、組織の文化やビジネス戦略とどう結びつけるべきかを改めて考えさせられました。
イベントソーシング・CQRSで、ドメイン駆動設計をシンプルかつ柔軟に実践する
執筆者：@yukyan
もともと、私は新規事業開発においてイベントソーシングのようなアーキテクチャを採用している部分があり、学習の難しさも感じつつも、金銭に関わる処理やアカウントの状態の変遷など、複雑なルールを持つシステムの記録を残せたりと、そのアーキテクチャの良さを感じていました。
そのため、その難しさをどう克服していくか、またその難しさを持った上でもこのアーキテクチャを選択していく利点は何か、という点が非常に気になりました。
イベントソーシング・CQRSの難しさについてはセッション内でも言及されており、そこは設計者から実装者まで、トレードオフとして学習コストを払う必要がある、とのことでした。具体的にどのように学習していけば良いかですが、「ドメイン駆動設計を始めよう」や、「関数型ドメインモデリング」、「データ指向アプリケーションデザイン」などの書籍にイベントソーシングを含めた説明が書かれているため、ここからキャッチアップを進めていくと良いとのことでした。
また、私が知らなかった部分なのですが、イベントソーシングにはOSSのフレームワークが存在するらしく、それを活用することでイベントソーシングの使い方についてある程度制約を設けたり、メンテナンスコストや学習コストを抑えられるのではないかと感じ、実際に触ってみたいと思いました。EVENT STOREというフレームワークが公式でGoをサポートしているようなので、触ってみた記事を書いてみたいと思います。
ソフトウェア開発の複雑さに立ち向かう
執筆者：@どすこい
本発表は、予測しづらい状況の詳細な状況整理から始まりました。 ソフトウェア開発の現場は、VUCAと言われるような予測しづらい状況にあります。しかし、事業活動そのものはずっと昔からVUCAが当たり前でした。その事業活動のデジタル化によって、ソフトウェアエンジニアが、事業活動の当事者になりました。つまり、エンジニアが事業活動の主体となったことが本質的な原因であると紹介されました。
僕の働いているチームでは、エンジニアやデザイナーが、事業活動の戦略を決定する会議に出席していることを思い出しました。たしかに、僕らの技術や能力によって戦略の方向や選択肢が大きく変わるなと思いました。自分らは開発者"ガワ"などではなく、事業活動をする主体であり、その主体の中で開発を担当しているに過ぎない。事業活動や事業の方向に対しての責任があるんだと考えました。しかし、そんな事業の主体である僕らは、どうやって予測しづらさにアプローチすればいいんでしょうか。そういうことを考えて続きを聞いてました。
その答えの一つで特に印象的だったのは予測しづらい状況下の行動モデルでした。
予測しづらい中での行動モデルについて紹介していました。それは、"①経験知を取り出す＆状況の判断→②仮説の立案→③行動→④状況が変化＆経験知が増える→再度①へ…"というサイクルを回すことです。未来の状況は予測しづらいので、現在の状況と過去からの経験知を集約することから始めるということでした。これに基づいた仮説を立案し、行動することで、状況が変化し経験知が増えます。そうすることで、質の良い仮説と行動が取れるようになっていき、予測しづらい未来について少しずつ対処できるという話でした。
この話は最後の方に説明されていた"事業視点のソフトウェア設計の学び方"にも通じる話でした。決まった答えがない状況なので、探索と発見を繰り返すという学習活動こそがソフトウェア設計であるという話をされてました。
ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史をADRから振り返る
執筆者：@ugo
このセッションでは、ADR（Architecture Decision Record）1の導入メリットや、実際のADRを用いてアーキテクチャに関する意思決定を振り返る内容が紹介されました。
リプレイスに伴う技術選定について、以下の2つのADRが取り上げられていました。
- Javaの採用: 息の長い言語を選ぶというなどの、再リプレイスのリスクを抑えるためにJavaを採用。
- Goの採用: 高トラフィックなシステムにはJavaより軽量、高速なGoを採用。
これらの技術選定は、当時の時代背景やその後の結果も含めて振り返る形となっており、新たに開発に参加したメンバーでも納得感を持ちながら開発を進められることができるなと感じました。
その他にも、特殊要件を満たすものがないので「API Gatewayを内製化する」、人気商品の販売時の障害をなくすために「カートシステムにキューイングシステムを導入」などといったADRが紹介されていました。
ADR導入のメリットとしては、特に以下の2点が挙げられていました。
- プロジェクトの透明性が向上し、方針を維持できる。
- 新入社員のオンボーディング資料としても有用である。
私自身、「なぜこの仕様なのか？」と気になった時に、当時のPRを探したりドキュメントを追ったりする必要があります。しかし、どのPRを見ればよいのか、どこにドキュメントがあるのかが分からないことも多いです。
また、ADRでは意思決定当時の背景やその振り返りが記録されているため、「今ではどうするのが最適か」を判断する材料が得られ、とても役立ちそうでした。
参加したエンジニアの感想
tetsuwo
初めてアーキテクチャカンファレンスに参加しましたが、各社の取り組みやアーキテクチャの戦略を学べる非常に有意義な時間となりました。特に、多くのセッションを通じて、「アーキテクチャは進化し続けるもの」という考え方に触れ、自分自身もこのテーマに一層関心を持つようになりました。 また、ZOZOTOWNさんが紹介していたADRの活用事例などは僕らもすぐに導入できる一つだと思うので早速実践していきたいです。
カンファレンス会場ではオライリージャパンさんのブースもあり、ついつい技術書を二冊も購入してしまいました。購入した本は、今後の学びをさらに深めるための良いスタートとなりそうです。これも、今回のカンファレンスで受けた刺激のおかげだと感じています。
また、クロージングで発表された来年の開催情報では、倍の規模での開催が予定されていると聞き、今から非常に楽しみです。来年はさらに深くアーキテクチャについて学び、より積極的に参加できるよう準備をしていきたいと思います。自信を持てるアーキテクチャを構築できるようになり、それをアウトプット、ご意見をいただくという形で登壇にもいつかチャレンジしたいです！！
nacal
今回アーキテクチャカンファレンスにはじめて参加をして、多くの企業のアーキテクチャに関する取り組みを聞くことができて非常に刺激になりました。
特に多くのセッションで言及されていた、「ソフトウェアアーキテクチャにベストプラクティスはない」や「良いアーキテクチャとは継続的にチームで進化させ続けること」などの言葉から、自身も常にアーキテクチャについてもっと深く考える必要があると感じました。
また、今回のアーキテクチャカンファレンスへの参加によって、自身およびチームとして、アーキテクチャについてより向き合う非常にいい機会になったと感じます。
来年も開催が決定していることをクロージングで発表されていたので、アーキテクチャへの理解をより深めて、来年も参加したいと思います。
yoshio
今回アーキテクチャカンファレンスに参加を通じて、さまざまなアーキテクチャについて学ぶことができました。
また、プロダクト成長を踏まえたアーキテクチャ設計、とくにドメイン知識を踏まえたマルチプロダクト化に応用したアーキテクチャ設計にとても関心を持ちました。
現在担当しているプロダクトはまだまだ成長途中のシステムであり、システム設計によってプロダクトの成長に大きく貢献できると思います。
プロダクトの拡張性や開発スピードを両立できるようなシステム設計ができるようなエンジニアになりたいと思いました。
yukyan
初めてアーキテクチャカンファレンスに参加したのですが、多くの企業のアーキテクチャに関する取り組みを聞くことができ、またアーキテクチャに関心のある方がこんなに多くいるんだということを実感しました。
普段は実装者として開発していることもあり、アーキテクチャの意思決定の部分に多くは参加していなかったのですが、最近は設計に関わることが多くなったので、今後もアーキテクチャのキャッチアップを続けていき、社会に価値を提供できるように精進していきたいと感じました。
改めて、今回はイベントを開催してくださった皆さん、登壇していただいた皆さん、ありがとうございました。
どすこい
前述した知見と似たようなもので、本カンファレンスの別の発表では、「答え合わせは後からやってくる」という話がありました。ソフトウェア開発の予測しづらい状況では、絶対の正解を現在見つけるのはそもそも不可能で、それまでの情報を総合して考えて行動するしかない、いわゆる銀の弾丸はないということを知りました。
僕ら新人エンジニアは"経験知"が比較的少ない立場であるので、書籍やテックカンファレンス、技術ブログなどで経験知を増やさなければいけない。それは正解を見つけるためじゃなくて、質の良い仮説を立てて質の良い行動をするためなんだなぁと知りました。また、その仮説と行動のサイクルをとにかく回すしかないことを知りました。月並みな感想にはなっちゃうのですが、勉強と行動をがんばろうと、脳の底から思いました。また、具体的なアクションとして、チームの方針決定について、何が経験知で何が状況分析なのか、何が仮説で何が行動なのかを明確に見分けようと思いました。
ugo
リプレイスやリアーキテクチャを経験したことがないため、自分のアーキテクチャに対する理解がまだ十分ではないと感じ、このアーキテクチャカンファレンスに参加しました。
セッションを通じて、技術選定に関する知見や、サービスの可用性や耐障害性（フォールトトレランス）を高めるためのアーキテクチャ設計など、普段アプリケーションコードを書く中では得られない考え方を知ることができました。
まとめ
執筆者：@yoshio
今回、Architecture Conference 2024に参加させて頂いたことで、さまざまなシステム設計に触れることができとても良い刺激をもらうことができました。
われわれが担当するプロダクトはローンチして間もなく、プロダクトの成長を支えるための新機能開発を日々行っております。
開発スピードと理想的なアーキテクチャを両立するのが難しいのが課題ですが、本イベントで多種多様な事例を学ぶことができ、業務に活かせることがたくさんあるかと思います。
プロダクトの成長を踏まえたシステム設計をし、今度は発表する側になれるように精進したいなと思いました。
来年のカンファレンスも参加したいなと思います。ありがとうございました！
-
アーキテクチャに関する重要な意思決定を記録するための文書 ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史をADRから振り返る p.7から引用 ↩