ソフトウェア・アーキテクチャの正解と妥協
理想はあるけど、正解はない
これはRetailAI Adventurers Advent Calendar 2023の記事です。シリーズ２ということで、気楽に思うところを書いてみようと思います。
極めて優秀な人であっても、未来を完璧に見通すことはできませんよね。でも、ソフトウェア・アーキテクチャを考えていると、なんだか自分が考えているアーキテクチャが唯一無二の正解という気がしてきます。
『オレの考えた最強のアーキテクチャ』とか、ついつい言いたくなっちゃう気持ちもわかりますが、大抵の場合、それはほとんど誰かが考えてくれたテクノロジーを組み合わせて、いい感じに（無難に）並べただけ、そんなふうにも感じられるんですよね。
コンウェイの法則なんて有名ですね。
コンウェイの法則（Conway's law）とは、組織がシステム開発を行う際、その組織のコミュニケーション構造と同じ構造の設計を行ってしまうという法則のこと。 1967年にアメリカのコンピュータープログラマーのメルヴィン・コンウェイ（Melvin Edward Conway）が提唱した。
そりゃ、グーグルさんだとかAppleとか、今だとOpenAIとかでしょうか、優れた開発メンバを揃えた組織であれば、理想的なプロダクトを構築できる可能性も高まるでしょう。しかし、多くの場合、そういうわけには行きませんし、世界のTOP企業である彼らでさえ、何一つ不自由なく開発を進められる組織などないんじゃないかな、それがぼくの思うところです。
それでなくても不確実な未来、ましてやChatGPTの登場以来、エンジニアリングの在り方そのものが、根本から揺らぎそうな現状です。
その前提を踏まえても尚、全てにおいて１００点のプロダクトを１０年以上サービス提供し続ける。それは、プロダクト単体において一つの理想ですが、果たしてそれが正解であるとも限らない。
スナップショット的に時間を切り取って考えれば、この技術よりもこちらの技術を選定すべきとか、こちらのサービスよりも、こちらのサービスの方が優れているなど、プロダクトを構成するソフトウェア・アーキテクチャに文句の付け所はたくさんあります。
でも、それは今という時間を切り取ったスナップショットに過ぎなくて、来年、あるいはつい来月のことであっても、それは正解を保証するものではないと思うんです。
つまり、理想はあるけど、正解はない世界が、プロダクト開発の本質であって、それにどのように抗って、不確実な未来の変化に追従するか、それこそがソフトウェア・アーキテクチャとして、検討し続けられるべき課題だよなぁって感じたりします。
これもまた、別に正解というわけではないですが、多少なりともソフトウェア・アーキテクチャを検討する上で、テクノロジー以外で普遍的な要素として金・時間・人が関連してくると思いますので、その軸での視点でもってちょっと議論してみたいと思います。
金・時間・人
まずは、何と言っても金（予算）が必要です。予算を度外視していては、どんなに優れたソフトウェア・アーキテクチャであっても、実現する確率は低いです。
当たり前のことなんですけど、意外とテクノロジーの観点で議論しているとぽっかり検討要素から抜けやすいですね。
特に、プロダクト開発やサービスが、まだ世に出回っていない最中には、予算は手物にある原資を使っていくしかありません。原資が底をつけば、プロダクト開発を継続することは出来ませんし、継続したければ、別途原資を調達してくるか、初回リリースするプロダクトの規模を小さくして、機能数や機能そのものを制限してでもなんとかリリースし、そのプロダクトの利用するユーザから使用料を支払ってもらうなど、何かしらの妥協が必要になります。
時間（期間）もそうですね。同じく妥協が必要です。明日までにプロダクトをリリースしたい、とむちゃを言ったって、そんなことが実現できるはずもなく、ある期限内にプロダクトを開発したいのであれば、当然のことながらその分の予算と人の確保が必要になります。
１０年後にこのサービスをリリースしたいんだ、という話なら、サグラダ・ファミリアじゃないですが、のんびり細々進めて行けば、妥協する場面も少なくて済むかもしれません。しかし、なかなかそんなのことは現実世界では難しいことです。
また、人に関しては、個々のスキルがとても重要な要素になります。人月の神話のように、１０００人いれば、１００人体制のときより、開発がスムーズに進むか、あるいは、ソフトウェア・アーキテクチャもより良く進化できるかといえば、そんな保証はどこにもありません。それよりむしろ、個人のスキルの方が確実ですし、優秀なエンジニア１人とあまり優秀じゃないエンジニア１００人と、どちらが生産的か、案外分からなかったりしますしね。
スキル面に関しては、ChatGPT登場以前と登場後とで、大きく変わってしまうんじゃないかと、個人的には想像していますが、どちらにしても、何らかのスキルを磨いた個人が有用であることには変わりがないと思っています。
この辺りについては、別の機会にまたつらつら書きたいと思います。
structured chaos理論
濱口秀司さんのstructured chaos理論は、先程の金・時間・人における視点を、プロダクトの開発フェーズ毎に整理するのに有効な手段だというふうに感じています。
かつて、CloudNativeじゃなかった時代、ハードウェアに対する投資は、不可避な上、柔軟性に欠く判断を強いられていました。
データベースのリレーション構造も、開発の初期フェーズで、ある程度確実な状態を求められ、導入したハードウェアと設計したデータベースとを初期前提として、各種機能の実装が強いられていました。
しかし、現在では、Cloud環境やコンテナ環境など、不確実な状況に対して柔軟に対応できるインフラ手段があり、ソフトウェア・アーキテクチャを考える上での自由度は高まっています。
仮に、『オレの考えた最強のアーキテクチャ』を完璧を求め続けるためには、収益性の高いサービスが他に存在していて、潤沢な予算と期間、優秀なスキルを持つエンジニアを抱えているのであれば、苦労は要らないでしょう。
しかし、多かれ少なかれ、何かが不足している開発体制の中では、フェーズにおいて状況において、structuredを重視すべきなのか、はたまた、chaoticに検討しておかないと、後々の変化に対応できなくなるのか、様々な観点からの判断が必要となってくると思います。
まとめ
妥協というと、何となく耳障りが悪く、負けたような気分になりますが、出来もしないことをやろうとして、単に無謀でメリットも少ない選択をするよりも、ソフトウェア・アーキテクチャに関しては、１００点満点中５１点の及第点をコンスタントに取り続け、より良い状況をコンウェイの法則に照らし合わせつつ、金・時間・人に対して、structured chaos理論における、どの視点で考えるべきか、定期的に立ち止まって、ぼんやり俯瞰してみることも、大事なんじゃななかろうか、最近はそんなことを考えています。
この記事が気に入ったらサポートをしてみませんか？