こんばんは。
PCのパーツをそろえつつ、ふるさと納税の駆け込みをしてるので来月のカードの請求が怖いです。
少し遅くなってしまったんですが、11/26(火)に開催されたアーキテクチャConference2024に参加してきたので簡単にレポートです。
『Modern Trade-off Analysis for Distributed Architectures and Future Software Architecture』分散アーキテクチャにおける現代のトレードオフ分析と今後のソフトウェアアーキテクチャの展望
いわゆるキーノートってやつですね。
A会場に入れなかったのでサテライトとしてB会場で聞きました。
B会場では同時通訳機の貸し出しはありませんとのアナウンスがあって、英語のみかなと怯えていたらちゃんと翻訳音声が流れて助かりました。
朝から英語力を試されるB会場#アーキテクチャcon_findy
— にゃご (@nyago_d) 2024年11月26日
アーキテクチャにはトレードオフがあるというのはそうだよなとは思っていたのですが、アーキテクチャとデザインの対比というのは考えたことがなかったので、そのグラデーションという視点がなかなか面白かったです。
アーキテクチャにはデザインと違ってケイパビリティの制限があるっていうのは重要な視点で、それがトレードオフに繋がるわけですね。
そしてそのトレードオフ分析は組織が何を優先しているのかに左右されるというのはとても納得感があります。
「ビジネスの成長を加速するB2B SaaSのスケーリングアーキテクチャ」
B2Bのコンテキストにおけるクラウド（AWS）のアーキテクチャの話なのでB2Cな頭には正直いまいちピンとこない話が多かったのですが、パッケージよりもSaaSという時代のような気はするのでクラウドのコストっていうのはかなり大きなファクター。
セッションではアプリケーションプレーンとコントロールプレーンという分け方をしていましたが、確かにコントロールプレーンの方はしっかりとコード化、自動化していかないと管理って本当に大変ですよね。
そもそもテナント管理って同じ会社の中で部署とかサービスごとにどうやって分けようみたいな視点しかなったので、顧客にテナントを割り当てるって考えると確かに大変そうだよななんていうぼんやりとした感想…。
ユーザに価値をもたらす部分はアプリケーションプレーンなので、時間をかけて頑張るじゃなくていかに省エネでっていう視点を忘れないようにしないと。
4年で17倍に成長したエンジニア組織を支えるアーキテクチャの過去と未来
ランチセッションだったのであまりメモができていない…。
Sansanさんはすごく人が増えているイメージがあるので、組織が成長に追いついていくのは本当に大変そうだなと思ってしまいます。
静的型付け言語を使うとか、クラウドを活用するとか、マイクロサービス化を進めるとか全体的にやっていることはそんなに珍しいことではないと思うのですが、だからこそこういった手堅い戦略は大切ですよね。
持続可能なアーキテクチャを考えるならばそれを評価するために観測できる必要があって、それと未来への戦略をどうコーディネートしていくかといった実に地に足の着いた取り組みを着実に進めている印象でした。
出前館のマルチプロダクト戦略を支えるアーキテクチャ ～技術的負債を解消しながら事業を多角化する～
最近はマルチプロダクトは増えてきているものの、相乗効果を得るとか、相乗りして開発コストを大きく削減するとか夢はあってもその実現はすごく難しいですよね。
ドメインの違いによってユースケースや機能が違ったので共通化できなかったっていうのは一見すると残念な感じではあるのですが、逆に言えば共通化できないものをちゃんと共通化させずに作り始められたっていうのは大きい。
やっぱりドメインの解像度が高いっていうのは最強で、マイクロサービスとイベント駆動ですんなり作っていけたというのは結構すごいことだと思います。
ただまぁこの辺りはじゃあなんでもマイクロサービスにすればいいかっていうとそういうものでもないので、サービスに合った仕組みを選べるだけの引き出しをちゃんと準備するしかないのかなと思ったりも。
「ソフトウェア開発の複雑さに立ち向かう」
アーキテクチャの話なのかというと若干疑問はあるものの、話の内容としてはとても面白いセッションでした。
事業活動とソフトウェア開発が一体化してきており、事業活動自体は今も昔も不確実っていうのは確かにその通りです。
エンジニアもビジネス視点を持つべきって話はどこでも聞くような話ですが、ソフトウェア開発者が事業活動の当事者になった、だから事業視点で設計判断もしなければならないというのはシンプルでとても分かりやすいです。
事業戦略の中心には競争優位があって、ソフトウェアはそれに追随しないといけない、うーん改めてエンジニアって大変な仕事ですよね。
偶有的複雑性と戦うためのアーキテクチャとチームトポロジー
本質的複雑性と偶有的複雑性ってなんとなくは知っていても、あまりしっかりと分離して考えられていなかったなと聞きながら思っていました。
確かに偶有的複雑性はなるべく回避すべきものであってタイトルにも「戦う」って入ってはいるものの、むしろいかにして戦わないでそれでもどうしても戦わないといけないときにどう戦うかを考えねばならんなと。
チームトポロジーの考えで逆コンウェイ戦略みたいなのはよく聞く話ですが、トポロジーを変遷させていくという発想はあまりなかったので参考にしたいです。
イネーブリング→コンプリケイテットサブシステム→分離→再統合、使える機会があるかわからないけど覚えておこう。
コンパウンド戦略に向けた技術選定とリアーキテクチャ
単一プロダクト時代からコンパウンド時代に変遷していくにあたっての歴史みたいなものを見ることができてGoodでした。
アーキテクチャって結局完成形を見て良いとか悪いとかって話になってしまいがちなので、どう変わっていくかっていう視点で見るのも良いですね。
フロントとバックをそれぞれ一番技術がある人に全権を預けて、スキーマだけCTOの責任で決めるというのはなかなかにワイルドではあるもののすごく効率は良さそうだなと思ったり、マイクロサービス50個を3チームでやるかっていう話はマイクロサービスを選ばない理由としてすごくわかりやすいなと思ったりなど。
それにしたって3年で10個のプロダクトって恐ろしい。スピード感がえぐい…。
マルチプロダクト戦略におけるデータ分析プロダクトのアーキテクチャ
物流業界がまだまだアナログっていうのはなんとなくイメージは湧いたのですが、消極的な意思決定が非効率、高コストになるというのはなかなかない視点でした。
トラック3500台っていうと大したオーダーじゃないなって思ってしまうんですが、その数で5秒ごとにデータが飛んでくるって考えると掛け算って恐ろしい。
やっぱりこういうリアルタイム系はしっかりとバッファリングしておかないとデータロストとか怖いので、Web系とはまた違った大変さがありそうだなと。
原 トリさん・matsさんが語る、システム設計の勘所
最後はトークセッション的な感じ。
システム設計の勘所というタイトルではあるものの、このセッションも経営視点のエンジニアの見ている世界みたいな印象は強かったです。
「明日リリースしないと会社がつぶれるってなったら何を選ぶか」みたいな話も、大きな会社のエンジニア部門みたいな意識で働いているとそもそも気にもしない視点だよなと思ったり。
課題を明確にしないと改善しても生産性は上がらないとか、手段を目的化しないとか、説明できることが大事とかよく聞く言葉ではあるけどこういう場で聞くとまた違った印象ですね。
最後の締めがちゃんと言語化してちゃんと説明するのが大事っていう、エンジニアスキルというよりはビジネススキル的なところなのもよかったです。
全体を通して
イベントを通して感じたのは、サービスや組織といったビジネス面とアーキテクチャをどのように繋ぎこんでいくかというテーマが多かったことですね。
登壇者にスタートアップの経営層の方が多かったりするのも関係しているのかもしれないですが、個人的にも直近はマネジメントポジションと技術ポジションの兼任という感じなので、この辺りの視点は大切にしていきたいところです。
純粋にアーキテクチャを見たいって人にはちょっと違うって思ったところもあったのかもしれないですが、個人的にはどのセッションも楽しく聞くことができました。
来年も開催するらしいので、また行けたらいいな。
でもやっぱり一日イベントは腰とかのダメージが…。
