ソフトウェアの持続可能性を考える

SDGs というキーワードが数年前から広がっていき、今ではどの業界・業種でも SDGs に関連する取り組みが行われています。
今回は SDGs と直接関係はしませんが、 Sustainability(持続可能性) を軸により良いソフトウェアについて考察していきます。

ソフトウェア開発の現場で起きていること

今の時代、どのような会社でも「IT」の専門部隊を持っている、もしくは、整えている最中だと思います。DX や 2025年の崖、といったキーワードから連想すると、当たり前の動向かと感じます。

しかし、非IT企業でなくても、自分たちでソフトウェア開発を完結する、いわゆる「内製開発」を実現している企業は少ないでしょう。
Sier, コンサルティングファームなどがそういった企業を支援することで、日本の DX は進んでいるのだと思います。

同時に、IT人材が足りない、などの言葉も目にする様になりました。

この様に、外部からエンジニアを調達(業務委託や派遣も含めて)し、少ない (と言われている) IT 人材の上で構築するソフトウェアは、
どうすれば 持続可能 なソフトウェアになるのでしょうか。
我々、システム・アーキテクトが気を付けなければならないことについて考えてみようと思います。

言語やフレームワークの動向と実態

今でも新しいプログラミング言語やフレームワークが誕生し続けています。
特にフロントエンド領域では、フレームワークの移り変わりは激しく、追いかけるのは大変です。（私も半ば諦めています...）

バックエンドは Java & SpringBoot という組み合わせは一般的かなと感じますが、最近は Go も伸びてきていると感じます。
また、スタートアップ系の Web 系企業だと Ruby on Rails で素早くフルスタック開発するのが主流でしょうが、
Python 関連のフレームワークも豊富なので選択肢は広がっていくでしょう。

システム・アーキテクトとして、この様な動向を把握しておくことは必要でしょう。
自分のチームにどの様なメンバーがアサインされるのか、次の案件のメンバーの技術スタックは何なのか、
蓋を開けないとわからないので、こういった動向を何となく追っておくと良いかと思います。

それと同時に、今のメンバーの技術スタックで開発を始める際は、トレンドを追うことよりも安定性を中心に検討した方が良いと感じます。
例えば、全員の技術スタックはバラバラですが唯一Java は共通で扱える場合、もちろんバックエンドはJava & SpringBootの選択肢が良いでしょう。

さらにこのチームでフロントエンドの SPA も開発するとなった場合、JavaScript よりも TypeScript の方が飲み込みが早いかもしれません。
そうなると、フレームワークは React, Vue.js, Nuxt.js が主流ですが、あえて Angular を利用するという選択でも良いと思います。
Angular は TypeScript スタンダードですし、フルスタックなため、SPA 開発の初心者には向いているかと感じます。

Vue.js でも TypeScript は利用可能ですが(Vue.tsとか言います)、開発中に困ったときに遭遇する Vue.js 関連のブログは大抵 JavaScript で書かれている印象なので、それらがノイズとなり逆に辛い思いをする可能性があります。

フレームワークの軽さと難易度

よく「このフレームワークは軽量だから扱いやすい！」という理由でフレームワークを採用するケースを目にします。React とかがそういうイメージです。
逆に「このフレームワークは覚えることが多くて大変そう」という理由で却下されるケースも目にします。Angularがそうでしょうか。

確かに AngularよりもReact の方が軽量なフレームワークだと思いますが、言い換えれば自由度が高いということだと思います。
自由度が高いのは良いことですが、それは「ある程度の技量を持ったプログラマ」にとっての話です。

SPA を始めて作る開発チームが、「軽量だから」という理由で React(もしくはVue.js) を選択し、年月が経つにつれて技術的負債を抱えるケースを何度か目にしてきました。

完全に個人的な意見ですが、初心者だからこそ「覚えることが多くて大変そう」フレームワークを選択することで、最初は大変かもしれませんが、覚えることさえ乗り越えれば、あとは型通りに実装すれば良いので大きく崩れることはないと思います。

フレームワーク依存とフレームワーク非依存

どんなフレームワークを選択したにしろ、完全にフレームワークに依存したアーキテクチャでは 持続可能性 を失ってしまうと思います。
Java & SpringBoot でバックエンドを開発しているチームに Java しかできないエンジニアが途中参加した場合、完全にフレームワークに依存したアーキテクチャでは、そのエンジニアは何も貢献できないでしょう。
ソフトウェアのアーキテクチャを「フレームワーク依存」と「フレームワーク非依存」で明確に分けることで、上記の様な事例にも対応できる様になります。

そのヒントになるのは、DDD を中心とした 3層+ドメインモデルアーキテクチャ や オニオンアーキテクチャ です。

上記は3層+ドメインモデルアーキテクチャ の簡略図ですが、左側の一般的な 3層アーキテクチャはフレームワークに依存しています。
SpringBoot の場合は @RestController, @Service, @Repository を利用するクラスが集まると思います。

DDD を設計・実装として利用する場合、業務ロジックは「ドメインモデル」として整理し、1つ1つのドメインモデルに業務ロジックを記述します。
(DDDに関する詳しい話は割愛します)

業務ロジックなので、例えば「金額の計算」や「予約可否の判定」などが挙げられると思いますが、
これらはフレームワークに依存せずに記述できる場合はほとんどです。

そのため、わざわざフレームワークに依存する必要はなく、Javaあれば POJO(Plain Old Java Object) で十分に表現可能だと思います。

こうすることで、フレームワーク依存とフレームワーク非依存をアーキテクチャとして分離することができるので、
冒頭のJava しかできないエンジニアが途中参加した場合でも、まずはフレームワーク非依存の部分から業務に参加してもらい、
徐々にフレームワークへの理解を深めてもらうという戦略がとれる訳です。

つまり、受け入れられる IT 人材が広がり、それは自然とソフトウェアの 持続可能性 の向上に繋がるでしょう。

イベントソーシングで業務処理と汎用処理を分離

Amazon SQS や RabbitMQ などのおかげでイベントソーシングは手軽に実現可能になりました。
DDD の文脈の場合は「ある集約へのコマンドをきっかけに別の集約のコマンドを発行する(結果整合成)」という場面でイベントソーシングが１つの解決策になっていますが、単純に「メールを送る」や「キャッシュを更新する」などの処理を非同期に実施するためにも利用できます。

後者の様に汎用的な処理（メールを送る、キャッシュを更新するなど）をイベントソーシングのサブスクライバーとして実装することで、
業務処理と汎用処理を分離して開発することができます。

これにより「ニッチな業界のソフトウェア開発」や「20%しか参加できないメンバー」に対して、汎用処理の実装をアサインすることがし易くなるでしょう。
どんなドメインでも「メールを送る、キャッシュを更新する」などの汎用処理は、そのドメインを深く理解していなくても、実装可能なことが多いです。

イベントソーシングを利用することで、パブリッシャーとサブスクライバーの開発を完全に分離できれば、ドメインを深く理解していない(もしくはその時間がない)メンバーにタスクをアサインできる様になるでしょう。

最後に

システム・アーキテクトは「設計」することだけが責務ではないと思います。

• このメンバーで開発するために最適な言語やフレームワークは何か
• フレームワーク依存とフレームワーク非依存に分離できないか
  を考えることで、自ずと「持続可能な」ソフトウェアに近づくと考えます。

今回は Backend 中心の話になってしまいましたが、フロントエンドでも同じことは考えられると思います。
HTML+CSS といったテンプレート要素とロジックを分けることや、業務ロジックとルーティングなどのフレームワーク依存の処理を分けることも考えるべきでしょう。

そうすれば、「プログラミングスクールでHTMLとCSSを勉強してきました！」という今後増えそうな IT 人材も、可能な限り案件にアサインし易くなり、それなりのタスクをアサインすることはできるでしょう。

つまり、システム・アーキテクトや開発リーダー、テックリードの方々の、この様なタスクアサイン業務を楽にするためにも、
「持続可能な」ソフトウェアへの意識は高めておいて損はないかと思います。