記事の背景

SkillnoteVPoEの安藤です。
前回（https://note.com/daisuke_ando/n/ne3b1d573e84d）はX1の核となっている各技術の選定理由について記載しました。
今回は、その続きとなる、検討・検証したが採用に至らなかった技術たちの不採用理由について記載します。（これをもって供養・・という類いの記事です笑）

技術選定の背景（前回のおさらい）

前回と同じ内容となり恐縮ですが、X1で採用した技術の選定背景については、以下のような点を挙げました。
・B2BのSaaSシステムであること
・オンプレを要求するお客様が一定数いること
・既に本番稼働して数年経過しているプロダクトが存在すること
・10年間の保守運用に耐えられる設計とすること

不採用技術とその理由

今回は採用に至らなかった可愛そうな子たちということもあり、淡々と記載していきたいと思います。。

Java

技術選定の背景ともマッチする、非常に優れた言語ではあるものの、前回記載の通り（Kotlinを選択した背景になっている通り）スタートアップの新プロダクトが採用するプログラム言語としては、人材の採用面を後押しする力が弱い、という判断です。

React/Angular

こちらも前回記載のVue.jsを採用した背景の通り、Angularは重厚すぎ、Reactは比較的大規模なアプリケーション、SPAにより向いているため、不採用となりました。（X1は完全なSPAは採用していません。）
また、Vue.jsの「Progressive」という考え方、エンジニアとシステムが成長していく考え方にマッチしていた点も採用の理由の1つです。

MySQL/Oracle

MySQLは十分に実績のあるRDMBSですが、「よりPostgreSQLの方が商用向け機能が充実している」という理由で不採用となりました。Oracleは・・・（ご存じの通り高価すぎて）手が出せない・・・

マイクロサービス

マイクロサービスを採用するかどうか、は非常に悩ましかったです。特にこの領域については判断材料が乏しく、技術検証についても環境準備に手間がかかるなど（特にローカル環境をどうするか、など）検証しきれず意志決定した、という側面があります。
当時不採用とした大きな理由として、ビジネス面から見ると「オンプレ導入を行う可能性がある」という点、技術面からは「採用のメリットがあまり見いだせない」という点が大きく挙げられます。
オンプレ導入は、現在の実績から見ると結論ナシですが、未だに営業段階で要望として上がることも多いです。技術的にはオンプレに展開可能なマイクロサービスのフレームワークで世界的に実績のあるものがない（見つけられなかった）こともあり、当時採用に踏み切ることができませんでした。

これに付随して良く出てくる概念として「CQRS」（コマンドクエリ責務分離）があり、マイクロサービスは不採用でもCQRSの考え方はシステムにマッチしそうということで、技術検証を行いました。（Axon Frameworkにて）
こちらも最終的にイベントストアをオンプレでどう導入していくか、例えばお客様の情シス部門の方が首を縦に振るものかどうか、という観点から、リスクが高いと判断し不採用となりました。
※ 事実、オンプレリリースの効率化を狙ってdockerの導入を提案したが断られてしまった、ということも。

Azure/GCP

インフラとしてどのクラウドサービスを利用するか、もかなり悩みました。
人数が少ない状態でシステムの運用保守を行っていく必要があるため、なるべく低レイヤーの運用はベンダーお任せにしたい、お金を払ってでもマネージドサービスを利用する方針としていたため、最終的に各種マネージドサービスが充実しているAWSを採用する、となりました。
Azureも最後まで検討対象で、特にActiveDirectoryとの親和性の高さは捨てがたい（お客様がADを採用していて、システム連携を求められることも多い）ところでしたが、まずはシステムが出来上がる方が優先、ということで立ち上がりが早く、運用保守もある程度楽ができる方向に向いた、というところです。

その他

その他、細かく挙げるときりがありませんが、例えばフロント（Vue.js）とサーバー（SpringBoot）間の通信はどうしよう、gRPCにしてSpringIntegrationと組み合わせて利用しようか、（マイクロサービスを採用した場合）トランザクションの範囲はどう管理しようか、セッションやキャッシュの管理をどうするか、バッチをどう組むか、などなど、様々な技術を調査・検証しては選定する、ということを短い期間で繰り返し実施しました。
このあたりは記事として記載すると細かくなりすぎてしまうため、興味のある方は話を聞きに来ていただけると嬉しいです。

まとめ

いかがでしたでしょうか。
技術選定は前回記事にも記載したとおり、短い時間で意志決定する必要がありました。そのため、いま考えれば「もっとこれを調べておけば良かった」や「これを選んでおけばこの機能はもっと楽に実装できた」「運用コストをもっと抑えられた」といった点もあると思います。
常に最善を選択することは難しいですが、日々の開発の中で学びブラッシュアップしながら、今後やってくるであろう次世代プロダクトのアーキテクチャ選定や設計において、それを活かしていくことができればと考えています。

X1の技術不採用理由に共感した、今後の可能性についてもっと突っ込んで聞いてみたいなど、興味を持っていただけた方、カジュアル面談を随時受け付けていますので、是非気軽に話しにきてください！