アーキテクチャConference 2024に参加しました。非常に得るものが多く有意義なカンファレンスでしたので、実プロジェクトに活かしていくためにここで学んだ内容をまとめていきます。
1. カンファレンス情報
- カンファレンス名：アーキテクチャConference 2024
- 開催日時： 2024/11/26
- 場所：浜松町コンベンションホール
architecture-con.findy-tools.io
2. どんなカンファレンス？
ホームページから抜粋します。
システムの基盤となるアーキテクチャの思考法や手法といった全体像から、他社が実践した具体的な構築事例といった部分像までをお話しいただくことで、アーキテクチャに対する考え方を学び直し、発想を広げられることを目指しています。
組織、アーキテクチャ、ソフトウェアと様々なレイヤでのセッションがあり学びが多いカンファレンスでした。
3. 参加の目的
私の今の現場は以下のような状況です。
- 使用しているフレームワークが古く年々知ってる人が少なくなりメンテナンスが難しくなってきている
- テストコードがない
- フレームワークに強く依存しており、そもそもテストが書きにくい
- 共通のコードが複数の箇所から呼ばれておりバグを生まずに改修するのが難しい
これらの状況を改善するためにリアーキテクチャ、リファクタリングが必要だと思っています。 リアーキテクチャやリファクタリングの際のアプローチの仕方や、そもそも良いアーキテクチャを構築するためには何を押さえるべきなのかを情報収集する目的で参加しました。
4. セッションの内容と学んだこと
組織やプロジェクトが求める要素の特定が先、アーキテクチャは後
いきなりですが、アーキテクチャの検討の前に、組織のことを分析することが先ということに気付けたのが今回の参加の一番の収穫でした。
それぞれのセッションでも、まず最初に組織やプロジェクトの分析をする重要性が語られる場面が多かったです。
Keynoteの Neal Ford氏(ThoughtWorks) による「Modern Trade-off Analysis for Distributed Architectures and Future Software Architecture」では、アーキテクトの陥りやすい罠として「文脈に沿わない判断をしてはいけない」ことに挙げており、
組織として重視することを決めないうちにソフトウェアアーキテクトのトレードオフはできない
と述べていました。また、最後のパネルディスカッション 「原 トリ・matsさんが語る システム設計の勘所」 では
- システム設計をする上で今後も変わらず重要な点というのはなく、全てのものは変わりうる、変化に対応できることが重要
- 何にインパクトを与えるかを念頭に、手段はなんでもよいと自分に言い聞かせる
と語られており、アーキテクチャや設計のような技術的な手段にとらわれるのではなく、目的が何かを定めて情勢の変化に追従できるように手段を講じ続けることの重要性が語られていました。
アーキテクチャ検討のための技術
では、アーキテクチャを検討していくためにどんな方法があるのでしょうか？やはりここでも参考になるのがNeal Ford氏によるKeynoteの内容でした。
Keynoteの中で、ソフトウェア設計に対してアーキテクチャの検討は時間も労力もかかるものだと述べています。ではそうやって決めたアーキテクチャは変更不要なのでしょうか？
Ford氏はアーキテクチャもアジャイルのように反復的に改善させることはできる、そのために構成要素を分解、結合して改善しやすいアーキテクチャを構築することが重要であると述べました。そのためのツールがDisintegratorsとIntegratorsです。
Disintegratorsはコードを分割するための観点で、たとえば以下です。
- Service Functionality:機能単位にサービスを分解する
- Code Volatility:コードがよく変わる、変わらないものを区別して分ける
- Scalability and Throughput:運用に応じてスケールする必要がある、高いスループットが求められているものとそうではないもの
このように変えるべきところ、変えなくてもいいところを区別して設計しておくことで、その後のアーキテクチャや設計変更が容易になります。
Integratorsはコードをまとめておくべきという観点で、以下などが紹介されていました。
- Database Transactions: ACIDトランザクションが必要なところはサービスを分けない方がいい
- Data Dependencies: データに依存性、複数のソースが同じデータにアクセスしている場合など
- Workflow and Choreography: 密なまま分離するとサービス間の通信が多くなって性能が劣化する、一つ死んだら他が動かないということが起きる
なんでも分解するのが良いわけではなく、まとめるべきところはまとめておくことで保守性やコードの可読性向上が期待できます。
もう一つ興味深かったのは 鵜飼 一平氏(atama plus) の「アーキテクトの誕生とこれから ー スタートアップ7年の成長と痛み」 です。チームトポロジーの考えを参考に、事業成長とともに、事業構造とアーキテクチャを合わせて設計する逆コンウェイ戦略を意識して推進していった事例が紹介されていました。
atama plusではもともと塾向けの既存事業を一つの開発組織で取り組んでいましたが、事業拡大に伴いオンライン塾の新規事業が追加、またそれぞれに共通する学習体験という要素が存在する状況でした。
そこで、事業構造に合わせて開発組織を塾向けストリーム、オンライン塾ストリーム、学習体験ストリームに分け、プロダクトもそれぞれのストリームで開発する方針としました(バリューストリームマップ)。
また、それぞれの事業とプロダクトの依存関係も、新規->既存->共通という方向性に揃えて、変化のしやすさや全体への影響を適切にコントロールできるようにしています。
これにより開発チームの認知負荷を下げ、事業拡大にスピーディに対応できたそうです。
ソフトウェアと組織構造を一緒に考えるのは、アーキテクトにしかできない仕事
と語られており、良いソフトウェアアーキテクチャを構築するには、アーキテクトとしての責務を組織構造まで拡大して捉えることの重要性を学ぶことができました。
リアーキテクチャ・リファクタリングのためのアプローチ
リアーキテクチャ・リファクタリングのためのアプローチについては、 辻井 福嗣氏(オープンロジ) の 「物流システムにおけるリファクタリングとアーキテクチャの再構築〜依存関係とモジュール分割の重要性〜」 が私としてはドンピシャな内容でした。
オープンロジでは「重要なサービスクラスが肥大化」「ロジックが一極集中」「依存関係が複雑化して変更が困難」「変更が困難なので廃止されたコードが残存」という課題を抱えていました。それに対して以下のようなアプローチを取りました。
- 目的の明確化
- 安定性の向上、長期的な開発効率向上、安全なリリースの実現
- リアーキテクチャの方針決め
- 依存の方向性を揃える
- MVCからモジュールを意識した構造へ
- リファクタリングの実施
- テストの拡充
- スコープを狭くして始める
- 抽象から具象へ
ここでもやはり、リアーキテクチャを始める前に「目的の明確化」を挙げられていたのが印象的でした。
アーキテクチャに良し悪しはなく、「目的を達成できるかどうか」が重要
と述べられていました。オープンロジではあえてフレームワークは生かす方針をとっています。私の組織でも古いフレームワークを使い続けておりやりにくさを感じています。つい新しいフレームワークに飛びついてしまいそうですが、それがプロジェクトの特性にどう関係してるのか整理して取捨選択するべきです。
また、リファクタリングにおいて今回はDDDなどで使われている手法は、チームの認知負荷を鑑みてあえて採用しなかったそうです。リファクタリングを実施するのはチームなので、新しいことを盲目的に取り入れるのではなく、このチームにとって最適なのかどうかを意識する必要があります。アーキテクトの仕事は、アーキテクチャを挟んで、組織の特性と、チームの特性の重点とバランスをとり続けていくものであると感じました。
リファクタリングを実施するにあたって「テストの拡充」が最初に来ているのは、そうだよなぁと感じました。 そもそも私のプロジェクトではテストコードがないので、この活動のスタートラインに立てていないとわかりました。
リアーキテクチャ・リファクタリングに向けて、「組織特性の分析」「目的の明確化」「テストの作成」をまずは推進するべきということが分かりました。
意思決定の記録を残す
アーキテクトの仕事は、「組織として重要な点を決める」「トレードオフしてアーキテクチャを決める」「チームの開発方針を決める」と意思決定の連続です。
現代のソフトウェア開発ではアジャイル開発に代表されるように、インクリメンタルに、継続的に改善していくことが重要です。しかし、意思決定の経緯が汲み取れないと、後々の開発者はソフトウェアがなぜこのような動きをしているのか、変更しても良いのか判断できず継続的な改善ができません。そこで重要になってくるのがADR(Architecture Decision Record)です。
瀬尾 直利氏(ZOZOTown) の 「ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史をADRから振り返る」 では、まさに会社の意思決定を反映したADRの実例を知ることができました。
ADRの構成要素は一般的には以下のようなものがあります。
- タイトル
- ステータス
- 文脈・背景（要求仕様を記述することが多い）
- 決定
- 結果・影響（意思決定をした後の結果）
ADRを導入する動機は「意思決定の背景を理解し後から軌道修正できるようにするため」、いつ書けばいいのかについては「小粒でもいいので設計を決めた時はいつでも」とされていました。
私としてはADRは以下の点が重要であると感じました。
- 「文脈・背景」に、採用しなかった案についても記載する
- 「結果・影響」に、決定が与えた「成功点」「欠点」を記載する
採用しなかった案について記載することで、後に見直す際にもともと気づいていたデメリットを踏まずにすみます。また、時代が変われば当時はデメリットだったものが変わっていることもあります。その時に、当時の決定の経緯がわかれば自信を持って変更することができます。
アーキテクトの仕事はトレードオフです。常に完璧な決定はできません。そのため、意思決定の結果が与えた「成功点」に加えて「欠点」も明記することが重要と感じました。これも継続的に改善していくことを前提にすると、この「欠点」の記載が次の改善のきっかけになるはずです。
セッションの中では、会社としての意思決定から、フロントエンドで採用するフレームワークの作新まで、様々な意識決定レイヤでのADRが解説されており、これを参考にすることでADRを導入する際のハードルを下げることができると感じました。
5. まとめ
今回のカンファレンスはアーキテクチャにまつわるさまざまな情報収集をすることができて得るものが非常に大きい一日でした。
特に、技術的な点やリアーキテクチャを進めるにはどうすれば、といったリアーキテクチャの実行に関するところだけに意識があった私としては、「組織特性の分析」「目的の明確化」といった、組織や目的を知りその上でアーキテクチャを設計するべき、ということを知れたのが非常に大きかったです。
また、今回のカンファレンスでは運営側が非常に工夫されていると感じました。最近私はカンファレンス後に感想をまとめるようにしているのですが、その際に初めに行うのは当日の発表資料の収集です。この点、今回のカンファレンスでは発表資料を集約するページが開設されており、発表の当日から資料がアップロードされていました。これは非常に画期的でした。他の人にカンファレンスを紹介する際にも、このページはとても役に立つと感じました。
会場に各企業のアーキテクチャの特集が展示されていたのも非常に興味深かったです。特に、アーキテクチャの選択の意図や背景が載っていたのが印象的でした。私のプロジェクトは息が長く、また開発用のネットワークで開発していることもあり、クラウドでの環境等最新のアーキテクチャについては疎いのですが、このアーキテクチャをなぜ選択したのかという意思決定の話はどのプロジェクトでも共通の話であり参考になるものが多くありました。
自分のプロジェクトに活かせそうな情報がたくさん仕入れられた良いカンファレンスでした。
