こんにちは、ふくちです。
2024年11月26日にFindyさん主催のアーキテクチャConferenceに行ってきました。
このイベントの狙いとしては、以下の通りです。
システムの基盤となるアーキテクチャの思考法や手法といった全体像から、他社が実践した具体的な構築事例といった部分像までを(登壇者の方から)お話しいただくことで、アーキテクチャに対する考え方を学び直し、発想を広げられることを目指すこと
私自身、ハッカソンでしか1からアーキテクチャを考えたことはないのですが、今後のキャリアで挑戦したい領域であることは間違いないため、参加することにしました。
その中で学んだことについてこのブログで共有していきます。
結論
・本当のソフトウェアアーキテクトの仕事は、トレードオフ分析をどれだけ上手く行うか
→その意思決定は一度だけでなく、何度も継続的に実施する必要がある！
・優れたアーキテクチャとは、何かの要件や目的に対して最適化されたアーキテクチャ！
・リファクタリングをする理由は、システムの性能などが組織で定めた要件を満たすようにするため！進め方は様々ある！
1.ソフトウェアアーキテクトの本当の仕事
まずは基調講演でニール・フォード氏が話されていた内容です。
「本当のソフトウェアアーキテクトの仕事は、トレードオフ分析をどれだけ上手く行うか」 だと話されていました。
トレードオフとは、「ある目的を達成するためには、他の目的を失わなければならない」というような、競合関係のことを指します。
例えば、「パフォーマンスを向上させるために、少し値段の高いEC2を使用(=コストが高くなる)する」など。
したがってトレードオフ分析とは、「どの目的を優先するべきか、様々な角度から推し測る」 というような意味になります。
この背景には、ソフトウェアアーキテクチャにおいて、ベストプラクティスは存在しないという考えがあります。
ベストプラクティスがない中で、「優れたアーキテクチャ」と評されるものの考え方は、常にアップデートされていきます。また、組織の方針や価値観によって、何を優先するかは変化します。
したがって、ベストプラクティスがないからこそ、アーキテクトたちは何度もトレードオフ分析を行って意思決定を重ね、その時に応じた最も優れたアーキテクチャを更新し続けなければならない、と話されていました。
仮に今日、最も優れたアーキテクチャを組んでいたとしても、明日にはそれが負債になっている可能性もあります。
それを避けるためにも、継続的なキャッチアップとトレードオフ分析に基づいた素早い意思決定が必要なのだ、ということを学びました。
2.「優れたアーキテクチャ」に対する共通認識
1.の話を踏まえた上で他のセッションを聴講していると、登壇者の「優れたアーキテクチャ」に対する認識が共通していることに気がつきました。
例えば、「3社と語るAWS Architectureレビュー会」においては、このような発言がありました。
優れたアーキテクチャとは、明確に定義されているわけではないが、「プロダクト」という組織の成果物に対して最適化されているものだ、とのことでした。
他にも、株式会社アンチパターンの「ビジネスの成長を加速するB2B SaaSのスケーリングアーキテクチャ」セッションにおいては、意思決定の際にビジネス的な優先順位などを元にする必要がある、としていました。
また、JAXAさんの「宇宙機の監視アーキテクチャの進化と小型月着陸実証機SLIMへの適用」セッションにおいては、探査機を監視するレガシーなシステムを刷新した際の話をされていました。
このJAXAのシステムは、一般的なWebシステムとは利用ケースが大きく異なっていました。
このシステムにおいては、過剰なスケーラビリティも、可用性も不要。細かいアプリケーションロジックやCI/CDパイプラインによるデプロイ自動化も不要。
ただし、機器障害は想定するし、データ表示のリアルタイム性は確保する。
もし仮に上記のアーキテクチャのみがAWSの試験などで選択肢として出てきた場合、多くの人は誤っている(=ベストプラクティスではない)と考えることでしょう。
しかし、このJAXA特有の要件に最適化されたアーキテクチャである以上、これは「優れたアーキテクチャ」 なのです。
この辺りは実務で経験しなければ理解できない部分だと思うので、事例として聞くことができて本当によかったです。
続いて、東京ガス株式会社の「140年の歴史あるエンタープライズ企業の内製化×マイクロサービス化への航海」セッション。
モノリスなサービスを作り直して、マイクロサービス化を実現しようとする中で、「リアーキテクトするのはあくまで手段。事業への貢献が求められる」と話されていました。
続いて、株式会社オープンロジの「物流システムにおけるリファクタリングとアーキテクチャの再構築~依存関係とモジュール分割の重要性~」。
大規模な本番稼働中アーキテクチャをリファクタリングする際、このように意思決定したと述べられていました。
アーキテクチャに良し悪しはなく、目的を達成できるかどうかが重要である、と。
ただ綺麗でモダンでリッチなアーキテクチャを作ったとしても、目的達成に繋がっていなければ意味がないのです。
JAXAにはJAXAの目的があったため、普通のWebサイトなどとは異なる構成にしていました。
同様に、オープンロジにはオープンロジの目的があり、それに沿ってリアーキテクトしていったのです。
そして最終セッションとして聴講した「原 トリさん・matsさんが語る、システム設計の勘所」。
「システム設計において今後も変わらず重要なこと」について、お2人がこのように話されていました。
まず大前提として、IT技術はツールであり、組織/会社としてそのツールをどう活かして誰にどんな価値を届けたいのか、があります。
ここはいつになっても変わらないので、その背景をまずは認識する。
その上で、システム設計においては変わらないものはない。なので、その変化を見過ごさず/見逃さず、追従できるようになっておく必要がある、と。
上記のように、ここでは、ビジネス上の目標を達成するためにエンジニアがいて、テクノロジーを使用している、といういわゆるBizDevOps的な話がなされていたように認識しています。
以上を踏まえて、多くの登壇者が
「優れたアーキテクチャとは、何かの要件や目的に対して最適化されたアーキテクチャである」
と述べられていたのが個人的には非常に印象的でした。
私はどうしても技術者目線で色々考えてしまいがちなのですが、実際のサービスを運用するとなると、ビジネス的な価値を考える必要が出てきます。
そのビジネス上の目的を達成するために、色々な要件が決まっていく。どんな目的を達成するためにどんな要素を優先するのか考え、意思決定し、構築し、いずれは作り替えていく。
これらのセッションを聞いていて、ビジネスから技術まで、一気通貫で考えられる人材が今まさに求められているのだ、と改めて認識しました。
3.リファクタリングやリアーキテクトについて
ここからは少し話が変わります。
他の企業がレガシーなシステム・ソースコードをどのように再構築しているのかについて興味があったので、まとめてみました。
Q.なぜリファクタリングやリアーキテクトをした？
A.組織で定めた要件を満たしていなかったから。
A1. 一部処理でパフォーマンスが出ていなかった
A2.大きな市場変革があり、よりお客様体験を向上するためにアジャイル開発を進められるようにしたかった
A3.よりリアルタイムに、即座の判断が求められるミッションを遂行する
A4.開発や運用に影響が出て、ビジネス価値提供の障壁になりそうだったため
Q.どうやってリファクタリングやリアーキテクトを進める？
1つの解があるわけではないですが、話に上がっていたものを記載します。
A1.リアーキテクト用の専門チームを作る
A2.一定期間開発を止めて、開発者環境を整えるのに時間を使う
→その際は課題を言語化しておくことと、リファクタリングする目的がビジネスとして実現したい何かのためであることを説明しておく必要がある。
A3.スコープを細かく区切って進める
A4.抽象と具体でイメージを揃えるために、方針をコードで表現する
A5.エンジニアチームだけではなく、ビジネスチームも巻き込んで動く
まとめ
丸一日セッションを聴き続け、非常に多くのインプットを得ることができました。
正直私は全くビジネス的な観点で考えられていないので、非常に勉強になりました。そして世の中のエンジニアたちすげー…となっていたのですが、自分も早くそこへ追いつけるようになりたいと、気が引き締まりました。
ただ、これを聞いただけでは意味がなくて、きちんとチームに持ち帰って今後の活動に良い影響を与えていくことが重要です。
業務において、リファクタリングが1つのミッションとしてあるので、チーム内に今日の知見を共有するところから始めてみます!
2025年も開催が決まっているそうなので、その時にはまたインプットしにいきたいと思います！