アーキテクチャカンファレンスとは
Findy株式会社様が主催していたアーキテクチャに関するイベントです。一番初めの基調講演には『ソフトウェアアーキテクチャ・ハードパーツ』などの著者であるNeal Ford氏が登壇。よくあるシステムアーキテクチャの間違いや、そもそもアーキテクチャとは？といった内容をスライドを用いて解説されていました（詳細は後述）。
会場全体の雰囲気については、当日はスポンサー企業様のブースも多数あり、通路を歩けなくなるほど大盛況でした。
入口近くには人と同じくらいの高さがある大きなガラポンが置いてあって、スタンプを集めるとガラポンを回せるという面白い企画もされていました。プレゼントの中にはHHKBもありましたが、誰か当たったのかな？
そもそもアーキテクチャってなんだっけ？
よく耳にするアーキテクチャという言葉ですが、そもそもどういう意味だっけ？というところに立ち戻ってみます。Wikipediaでは以下のように説明されています。
システムアーキテクチャ（英: system architecture）は、システムの構成要素（コンポーネント）として何があるか、各構成要素がどのような機能・役割を与えられ、相互にどのように連絡をして全体としてひとつのシステムとして機能するか、に関する記述や取り決めのこと。
なお、システムアーキテクチャの「システム」が指しているのはコンピュータシステムに限らない。（後述）
引用：https://ja.wikipedia.org/wiki/システムアーキテクチャ
複数の要素が一つのシステムとして動いている際、それぞれの要素にどのような責務を持たせるのか？通信経路はどうするのか？などを定義するルールのようなものと理解できます。
いざカンファレンスへ
アーキテクチャis何という話は終わりにして、ここからは私が実際に見てきたセッションの中から、興味深かったものや勉強になったものをいくつか抜粋してご紹介します。
『Modern Trade-off Analysis for Distributed Architectures and Future Software Architecture』分散アーキテクチャにおける現代のトレードオフ分析と今後のソフトウェアアーキテクチャの展望
『ソフトウェアアーキテクチャ・ハードパーツ』のNeal Ford氏が来日していました。本物だぁー！という驚きとともに英語を聞き取れるか一抹の不安がありましたが、Findy様が用意してくれていたイヤホン付きの端末で同時翻訳の音声が聞こえ、おかげで内容を理解できました。
学びの多いセッションで書きたいこともたくさんありますが、このセッションで特に大切だと感じたのはNeal Ford氏が何度も口にしていた 「アーキテクチャ設計はトレードオフであり、トレードオフ分析は常に行いつづける必要がある」 ということ。それから、「アーキテクチャにベストプラクティスは無く、いつも調整しカイゼンしていく必要がある」 といったことです。
どうしてもベストプラクティスやテンプレートを探しがちな私からすると耳が痛い言葉でもありました。
他にも、トレードオフ分析を行う際によく表やリストを作って「いくつの項目が〇になっているか？〇が多い選択肢を取った方がいいのではないか？」という判断をしがちですが、そもそもトレードオフ分析の際の項目には重みがあり、すべての項目を同じ重さで扱うことは間違いだと話していました。
A案は〇が5個ある、B案は〇が3個ある・・・といったケースで安易にA案を選んではいけないということですね。
イベント当日、一番最初のセッションでありながらとても学びが多く、ぜひ書籍も読みたいと思っています。積読の山に追加される日は近い。。
3社と語るAWS Architecture レビュー会
AWSのチーフテクノロジストの方と、AWSを利用している3社との対談でした。それぞれの企業が、アーキテクチャをスライド化して解説し、より改善できる点をAWSのチーフテクノロジストに解説してもらう企画です。
まず感じたのは「これだけ大勢の人の前でアドバイスされるの緊張しそうだなぁ」というしょうもない感想でしたが、内容はとても面白いセッションでした。というのも、現在使われている実際のシステム設計が見られる のがとても興味深かったこと。それに加えて、AWSの社員の方から リアルタイムに改善点を教えてもらえる（のを傍から見ている） という、普段ならなかなか体験できないシチュエーションだったからです。
内容を少しだけ抜粋しますと、
- 処理時間や待機時間がかかりそうなものはPoolしてあらかじめデータの払い出しを行っておく（ただし課金が発生するケースもあるので、ケースバイケース）
- 開発スピードを上げるためにはマネージドサービスをガンガン使って、設定やメンテナンスのためにつかっていた時間を削減していく。また、CI/CDを活用して自動化を進める
- ワークフローは正常系と回復系（障害時に復旧するようなもの）がある。障害はだんだんパターン化していくので、パターン化した回復系のワークフローは自動化してしまうと良い
といったことを話されていました。
ある程度設計が固まってきた段階で、「もっとカイゼンしたいことがあるんだけどなぁ」と悩んでいるとき、こういったアドバイスを受けられるのはとても良い体験だよなぁと感じます。本セッションは会場のみとのことで、もう一度見られないのが残念で仕方ありません。
複雑なCI/CDから脱却したアーキテクチャ：NTTグループの内製プラットフォーム事例を通して
NTTコミュニケーションズ様のセッションで、デプロイ時に抱えていた課題をどう解決していったか？という体験をお話されていました。当時のチーム（現在も同じ体制かは不明です）ではインフラチームとアプリ開発チームが分かれており、デプロイに関してはインフラチーム、アプリケーションの中身についてはアプリ開発チームと明確な役割分担があったそうです。
役割がきちんと分かれているのはよさそうだけど・・・と私的には思いましたが、いざデプロイ作業を効率化させようとしたときにその距離が課題だったとのこと。そのため、インフラチームはアプリチームに（もちろん逆も同様にだと思います）歩み寄り、相手の作業内容を理解しようとし始めました。
その結果、アプリケーション内で解決できることはアプリケーションに委ね、インフラ側のコードから削除できるようになったとのこと。こういった働きかけによってデプロイ作業をシンプル化していったとのことです。
他にも
- アプリケーションエンジニアにクラウドの学習コストを持たせすぎない
- とはいえデプロイはアプリケーションエンジニアに主体的に行ってもらう
- クラウドの知識が深くなくてもデプロイが簡単に行えるようにChatOpsを導入する
- プラットフォームはできるだけ統一し、プラットフォームごとの独自ルールが発生しないようにする
- マネージドサービスを使えるところはどんどん使い、運用の負担を減らす
などのお話がありましたが、結局この流れができるためにはインフラチームとアプリ開発チームのコミュニケーション・協働があってこそだったんだろうなと感じます。
本セッションはオンライン配信もあったようなので、アーカイブ配信がくるかもしれません。むしろあって欲しい。
まとめ
Neal Ford氏の言葉に倣うと、アーキテクチャに正解は無いそうなので永遠に悩み続けたいと思います。ベストプラクティスに逃げずに、自社にとってより良いアーキテクチャを考えられるようになれると良いな・・・。
あとマネージドサービスはエンジニアの負担を減らしてくれるようなので、バンバン活用していきたいです。
最後に
全体的に学びが多く、他社さんのアーキテクチャや悩みが知れる良いきっかけになりました。このイベントでは「課題をどのように解決するか？もしくは解決したか？」という話がメインでしたが、現状悩んでます！みたいな話もちょっと聞いてみたかった・・・と欲をいだきました。
あと、お弁当とても美味しかったです。貝が苦手なので、アサリの佃煮？は残しました。ごめんなさい。
「ワークスタイルの未来を切り拓く」を理念に掲げ、リアルとデジタルの2つの働く場に向けた事業展開に留まらず、自社が率先して新しいワークスタイルに挑戦し、発信を行うことでワークスタイルの未来を切り拓いていきます。
Discussion