お世話になってます。開発基盤チームの桝井です。
11/26に開催されましたアーキテクチャConference2024に参加しました。
今回の記事は、当イベントに参加した小椋・三品・桝井の3名が、それぞれの視点でレポートと感想をお届けします！
事業を止めずに変化し続けること by 小椋
事業会社ではプロダクトの開発・改修を行いながらビジネスを成立させ続けなければなりません。 走りながら変化を続けるためにどのように取り組んでいったかという視点で「ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史をADRから振り返る」「コンパウンド戦略に向けた技術選定とリアーキテクチャ」のセッションに参加しました。
レポート
ZOZO社では既存システムがビジネス要求の限界を超えられないために刷新を決断し、ADRを通して採用技術の意思決定の変遷を紹介されていました。 ADRを継続運用することにより過去の意思決定とその背景を端的に振り返ることができています。また、結果・影響（Consequences）の評価をPros, Consそれぞれの面で残すことによって次の課題を発見することにつながります。長く続くサービスにおける持続的な開発戦略の流れを感じることができました。
ナレッジワーク社はプロダクト成長に伴って進化するプロダクト戦略を見据えて漸近的なリアーキテクチャを進める事例を紹介されました。 移行自体は力技という話はリプレイス進行中である当社には身につまされます。
感想
かたや20年ビジネスを続けながら育ててきたプロダクト、かたや立ち上がって数年のスタートアップと属性は全く異なりますが、ビジネス要求から課題を抽出し、その時点での適切な意思決定に基づいて開発を進めているところは通ずるところがあると感じました。 当社のプロダクトも新たな価値を創出しながら既存機能の改善や刷新に取り組んでいる最中ですが、経緯を紐解くことが難しいところがハードルになっていることもあります。 今後に備えて今からでも始められるプラクティスを導入していきたいと思いました。
イベントソーシング・CQRSでドメイン駆動開発を加速させる by 三品
「イベントソーシング・CQRSについて聞いたことはあるが実装経験は無い」私が「イベントソーシング・CQRSでドメイン駆動設計をシンプルかつ柔軟に実践する」のセッションを聞いて、学習の基礎として非常に良かったので共有します。
レポート
はじめにイベントソーシング(以下ES)・CQRSについて定義の説明から、おすすめする理由、デメリットとしてよく挙げられている(が実際はデメリットにならない)ことなどが紹介されていました。
ESとは 現在の状態をデータとして保存するのではなく、イベントをデータとして保存する手法です。 一方でCQRS(Command Query Responsibility Segregationの略)は、データを保存する際にコマンドを使って書き込み、読み取る際にはクエリを使うことで責務を分割するアーキテクチャ(の一部)になります。
ES・CQRSをおすすめする理由については、制約がはっきりしていることが良い設計になりやすい点やイベントストーミングで定義されたイベント、コマンドをそのままシステムに適用しやすい点などがありました。
反対にデメリットとしてよく挙げられている(が実際はデメリットにならない)ことは基本データの削除が無いので、データ量が多くなる＝コストが高くなるということでしたが、実際はキャッシュやスナップショットを駆使して費用の効率化ができていることなどがありました。
また、よくある質問も紹介されており、その中で「ES・CQRSはスタートアップや中小企業向けのシステムにもマッチするのか？」の質問に対して「マッチする」とのことでした。 小規模なアプリケーションでもESの履歴のアクセスのしやすさ、CQRSによる責務の分離の利点が活かせるとのことで弊社のプロダクトに組み込んでみたくなりました。手段が目的になっているのはさておき、、
感想
私は今までこれらの概念を棲み分けできずに「何か壮大な概念だな」と漠然としていましたが、「CQRSを採用してデータの保存手法としてESを使う（使わない）」といった設計の判断ができるようになると私は解釈でき、とても解像度が上がりました。 講演の中でも、ESとCQRSは必ずしもセットではないと話されていてとても腹落ちしました。 「ESは新しいパラダイムなのでわからなくて当然」と話されていた高丘さん自身、「良さそう」から「わかってきた」の状態になるまで一年かかったそうで、それだけの概念であるからこそ非常に有力な選択肢となるのだなと刺激を受けました。
はじめてのテックイベント参加でしたのでとても緊張しましたが、学びや刺激を多くもらったとても有意義な一日になりました、本当にありがとうございました。
ソフトウェア・アーキテクチャ設計をする前にすべきことがある by 桝井
「ソフトウェア開発の複雑さに立ち向かう」（増田亨さん）についてのレポートと気づき・感想です。
レポート
はじめに、なぜソフトウェアが難しく複雑になってきているのか？についての分析がありました。ずっと以前から『事業活動は予測しづらいもの』で、現代ではソフトウェアを中心に事業活動を展開するようになっているため『事業活動とソフトウェアシステムの変化が一体化』し『ソフトウェアエンジニアが事業活動の当事者になった』ため難しく複雑になったという解釈がありました。
そして、事業活動の変化・複雑さについていくためには「事業活動の当事者として（ソフトウェアを）設計する』ことが大事でそういった設計をするための4つのアプローチの紹介がありました。
感想
4つのアプローチのうち1つ『競争優位分析とソフトウェア設計』についてを取り上げます。
簡単にまとめると根幹の課題に焦点をあてて設計をするアプローチです。そうすることで利益を生むことができるというわけです。
このアプローチと似た内容がNeal Ford氏の基調講演でも言及されていました。
それはアーキテクチャのトレードオフの『陥りがちな罠』という話のなかで組織として何を優先すべきかそもそもわかっていないと正しくトレードオフできないというものです。
それぞれの主張でフォーカスするものが同じだと気づきました。
「組織としてなにを優先すべきか」＝「根幹の課題（自分たちの競争優位を伸ばすためにすべきこと、または維持するためにすべきこと）」 ということです。この軸があってこそソフトウェア設計（設計のためのトレードオフ分析）がうまくできるんだろうなと思いました。
この大事にすべきものは当たり前のことではあると思います。 しかし、いざ設計を始めるとシステムレイヤーの概念（AWSのサービスの繋げ方やソフトウェアのデザインパターンなど）の中で思考を巡らせてしまって視野狭窄に陥り、その一段上の自分たちの事業はどうしたいのか？を忘れてしまうことに覚えがあるな…と反省する次第でした。
私たちのサービス：OfferBoxでは企業にマッチした学生に出会える（見つけられる）ことが競争優位＝コアドメインです。いま現在、私はこの見つけられる機能つまり学生検索機能の改善に取り組んでいます。学生検索は弊社サービス開始からずっと存在しているため巨大で複雑になってしまっている機能です。よって一筋縄ではいかない改善です。
そんな状況でしたが、今回のアーキテクチャカンファレンスで聞いた・知ったことで正しい改善に向かっているという確信と困難な改善に立ち向かうモチベーション、早く改善して価値提供をしたいというモチベーションが高まりました。
運営のみなさま、スピーカーのみなさま、協賛企業のみなさま、ありがとうございました。
会場にて
弊社データ基盤アーキテクチャの掲載がありました！うれしいですね！
