2つのSaaSをフルスクラッチで開発して分かった、開発スピード向上を実現するアーキテクチャ選定の勘所

【23-A-8】ドメインを分析し、設計に落とし込むには？ 2つのSaaSをフルスクラッチで開発した経験から学んだこと

ロジック層の複雑化がもたらす問題と解決への模索

　PMFを達成するためには多くのことを迅速に実行する必要がある。スタートアップでは時間をかけていられないため、スピード感が非常に重要である。プロダクトが一定のシェアを獲得した後も、その優位性を保ち続けるためにスピード感が不可欠なのだ。

　ただし、創業当初からのスピード感と、その後のスピード感は大きく異なると感じた。それは同社がDDDを導入するきっかけにもなった。「プロダクトとしての優位性を保つためには仕様変更や新機能の追加を迅速に行うことが求められる。重要なのはスピード感の維持であると感じています」（畠中氏）

　仕様変更と改善のスピードを高めるには、コードの変更が容易であることが欠かせない。どこを変更するべきかが明確であり、変更によって何が起こるかが予測できる状態であれば、スピードを保つことができるだろう。さらに詳しく見ると、仕様変更においては、各関数やクラスの責務が明確で、見通しの良いコードであることが重要だ。変更の影響範囲が明確であるためには、依存関係がはっきりしており、依存の向きや範囲が限定的であることが求められる。

　「結局のところ、よく言われる『高凝集・低結合』が非常に大切であるという結論に至りました。ただし、それを通常のアーキテクチャで実現するのは難しいと感じています。特に、私たちが取り組んでいるような大規模なバーティカルSaaSを構築する際、従来の3層アーキテクチャ（プレゼンテーション層、ロジック層、データアクセス層）では、コードが複雑になりがちで、これをどのようにきれいに保つかが今後の課題と感じています」

　例えば、2つのロジック、AとBがあり、ロジックAでロジックBの一部を使用したい場合、それをロジックAに直接組み込むと、本来ロジックAが行うべきではない処理が増え、凝集度が低下する。また、ロジックAからロジックBを参照すると結合度が高くなり、高凝集・低結合から遠ざかってしまう。

改修・改善活動ではロジック層が複雑になりがち

　畠中氏は、具体例として、薬品の在庫アラートを実装したケースを紹介した。例えば、在庫が10個以下になったらアラートを通知する機能を追加しようとした際、在庫の仕入れや在庫使用のタイミングで在庫の減算ロジックを呼び出す必要があった。しかし、在庫アラートのロジックを在庫管理のロジックに組み込むと、在庫が増えたにもかかわらず、アラートが出るという意図しない動作が発生した。また、在庫関連のロジックは複数存在し、在庫アラートのロジックをあちこちに書かなければならない状況が生じた。

　さらに、カルテの名寄せ（複数存在する同一人物のカルテを統合する処理）のケースでも問題が起きた。会計情報や予約情報などを統合する必要があり、名寄せロジックが各所に散在することで、コードの可読性や品質が低下した。いずれのケースでも、DRY原則（Don't Repeat Yourself：同じコードやロジックを複数箇所で繰り返し記述するのを避け、コードの再利用性や保守性を高めること）が守れなくなっていた。