アーキテクチャConference 2024に行ってきました

今年に入ってIT系カンファレンスによく参加するようになりました。
目的は少しでも自分自身が携わる開発をよりよいものにしたいというざっくりとしたもの。

毎回、参加してはX（旧Twitter）に散文的に感想を流すのみでしたが、
少しでもインプットとアウトプットの好循環を作りたいと初ブログ投稿です。

今回は、浜松町コンベンションホール & Hybirdスタジオで開催されたアーキテクチャConference 2024についてとなります。

architecture-con.findy-tools.io

私の頭の中のまとめ

・時代の変化に追随するためにはアーキテクチャは進化していく必要がある。

・進化させていくのはだれか一人の優秀な開発メンバーではなく開発チーム。

・開発チームは誰かが決めたことに盲目的に従うのではなく、時代に影響を受けて流動する事業を意識する必要がある。

・気付いたことは言語化し、外部から見える状態にする。一度言語化したものも成長に合わせ肥大化する場合、稼働度を上げて分割する。

・開発チームのミッションは価値のあるインクリメントを作り続けることであり、それに付随する課題の認知負荷は外部から適切に取り除く。

・開発チームが自律した状態を持続するために、ウェルビーイング（ゆらぎ・ゆだね・ゆとり）は重要。

聴講したセッション

今回のカンファレンスで参加したセッションです。

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

speakerdeck.com
現場に向かう間の電車内でオンライン聴講。
名詞管理のためのプロダクトsansanとは別の請求管理のためのBillOneのお話。
開発を進めるにあたる戦略の重要性を改めて学びます。
勉強になると同時に、最後のWell-Beingの話に、
この思想があるから開発チームが難易度の課題も解決していけるのかもと思いました。
「共創するアーキテクチャ～チーム全体で築く持続可能な開発エコシステム～」

speakerdeck.com
一番現場メンバーと話したくなる内容でした。
BDDはできているけど、その立体化とチーム内で共通認識とするところに課題を思っていたため、イベントストーミング、モブプロで改善が見える内容かも知れない。
何より誰かに依存しないチームの強さの確立を意識したいと引き締まりました。
「ソフトウェア開発の複雑さに立ち向かう」

speakerdeck.com
増田さんのファンです。
今までの事業→ソフトウェア→設計書→エンジニアという距離感が、事業→エンジニアの距離感となることが求められていると感じました。
アプリケーション間連携を事業の優位性で考えたことなく目から鱗でした。
ソフトウェアと事業は同じサイズぐらいのほうが良いのかもしれないと無邪気に思う。
「偶有的複雑性と戦うためのアーキテクチャとチームトポロジー」

speakerdeck.com
ログラスさんのファンです。
FASTの取り組みもQAの活躍の仕方も一方的にとても刺激を受けています。
そのうえで、Platform&Enablingチームも凄すぎる。
X-as-a-serviceとコレボレーションの経過の実例はチームトポロジーに対する解像度があがりました。
これ実現したいけど、なんとなく意識しただけではできない。考える。
「複雑なCI/CDから脱却したアーキテクチャ：NTTグループの内製プラットフォーム事例を通して」

speakerdeck.com

先日のDeveloperXSummitでもお話お聞きしたQmonus生誕秘話のように聞きました。
現在担当している案件はDevOpsを開発チームのみで回しているので
改めて認知負荷の高い状態をなんとかせねばと思いました。
Platformエンジニアは大事。
「物流システムにおけるリファクタリングとアーキテクチャの再構築〜依存関係とモジュール分割の重要性〜」

speakerdeck.com

10年ぐらい前に自分が設計したMVCモデルではどうなったのだろうとヒヤッとしました。
改めて、アーキテクチャは進化前提で考えないと負債になる。
そのうえで、古いアーキテクチャもモデルを分解して最適化していくことが重要。
「システム設計の勘所」

設計は事業背景も大事。
リアーキテクチャは新しい変化に追随するため、
もしくは負担が大きいことでリスクが見えてきたらやる。
直感は大事。直感を言語化して整理して推進するのが重要。