本記事の対象読者と前提

本記事は、システム開発や技術選定に関わる実務者、エンジニア、技術責任者を対象としている。

ただし、本記事は特定の技術やフレームワークを推奨するものではない。

DataLinerがどのような考え方で技術を選定し、なぜその判断を行っているのか、

その背景となる思想を整理することを目的としている。

そのため、本記事で述べる内容は、DataLinerという小規模事業者の立場から導き出した判断であり、

全ての組織に当てはまることを保証するものではない。

はじめに

技術選定は、しばしば宗教論争になりやすい。

どの言語が優れているのか。

どのフレームワークが優れているのか。

どのクラウドが優れているのか。

しかし私は、その問い自体に違和感を覚えている。

なぜなら、

技術選定の目的は、優れた技術を見つけることではないからである。

重要なのは、

事業目的を実現するために、どの技術が最も適しているか

である。

DataLinerでは、技術選定を目的ではなく意思決定の一つとして捉えている。

技術もまた手段である

前回の記事では、

AIは目的ではなく手段である

という考え方を紹介した。

実は、技術そのものについても同じ考え方を持っている。

Rustを採用することが目的ではない。

Astroを採用することが目的ではない。

AWSを利用することが目的ではない。

重要なのは、

事業として持続可能な仕組みを構築できるか

である。

技術は、そのための手段に過ぎない。

DataLinerが重視する技術選定の基準

DataLinerでは、技術選定において以下の観点を重視している。

事業目的への適合性

どれほど優れた技術であっても、事業目的に適合しなければ意味がない。

技術は目的達成のための手段である。

まず最初に考えるべきなのは、

その技術が何を実現できるか

ではなく、

その技術によって事業目的を実現できるか

である。

持続可能性

個人開発や小規模事業において最も重要なのは継続できることである。

導入できることよりも、

運用できること。

運用できることよりも、

継続できること。

を重視している。

技術的負債の抑制

短期的な開発効率だけを追求すると、後から大きな負債として返ってくる。

そのため、

  • 保守性
  • 可読性
  • テスト容易性
  • 移行容易性

を重視している。

スイッチングコスト

DataLinerでは、移行可能性を重要な設計要件としている。

特定ベンダーや特定技術への過度な依存は避ける。

将来的な選択肢を残すことも技術戦略の一部である。

国家リスク

技術は中立ではない。

開発元企業や主要コミュニティの所属国家によって、

  • データ規制
  • 国家干渉
  • 検閲
  • 地政学的リスク

を受ける可能性がある。

そのため、DataLinerでは技術そのものだけでなく、その背景にあるリスクも評価対象としている。

ここでいう国家リスクとは、特定の国や地域を一律に排除するという意味ではない。

DataLinerでは、技術やサービスの採用時に、少なくとも以下の観点を確認する。

  • データ保護・個人情報保護に関する規制
  • 国境を越えたデータ移転に関する制約
  • 情報提供義務に関する法制度
  • 輸出管理・安全保障貿易管理
  • 経済制裁・取引制限
  • サービス提供主体の所在国と準拠法
  • 将来的な利用停止・制限・調達困難の可能性

これらは、技術そのものの優劣とは別の判断軸である。

例えば、クラウドサービス、AIサービス、SaaS、開発ツールを選定する際には、必要に応じて公的機関や規制当局が公開する一次情報を確認している。

例として、

  • 個人情報保護委員会（個人情報保護・越境移転）
  • 経済産業省 安全保障貿易管理（輸出管理）
  • European Commission Data Protection（GDPR）
  • 中華人民共和国国家情報法（情報提供義務）

などを参照する場合がある。

これらは特定の国や企業を否定するためではなく、事業継続性や法令遵守の観点から確認するものである。

採用技術は結果である

DataLinerでは、

  • Rust
  • Python
  • PostgreSQL
  • TypeScript
  • Astro
  • React
  • AWS
  • Pulumi

などを採用している。

しかし、これらの技術を先に決めたわけではない。

先に存在したのは、

  • 持続可能性
  • 保守性
  • 型安全性
  • 移行容易性

という判断基準である。

採用技術は、その結果として選ばれたものである。

例えば、

  • Astro + React は、DataLinerホームページや語り部の座のような情報発信基盤において、静的配信と必要最小限の動的UIを両立するため
  • TypeScript は、長期運用時の保守性、型安全性、バグ検知性を高めるため
  • Pulumi は、インフラ構成の再現性と変更履歴の追跡性を確保するため

といった理由で採用している。

つまり、採用技術は単なる好みではなく、

持続可能性、保守性、移行容易性、再現性といった基準に照らした結果である。

不採用技術にも理由がある

技術選定において重要なのは、

何を採用するかだけではない。

何を採用しないかも同じくらい重要である。

例えばDataLinerでは、

  • Kubernetes
  • GraphQL
  • Flutter
  • Terraform

などを現時点では採用していない。

ただし、これは恒久的な不採用を意味しない。

事業規模、運用体制、要求される可用性、開発チームの人数、顧客要件が変われば、

再評価の対象になる。

例えばKubernetesについても、現時点では運用負荷に対する効果が見合わないと判断しているが、

将来的に複数システムの運用や高い可用性が求められる段階になれば、採用を再検討する可能性がある。

技術選定は固定された結論ではない。

事業環境や要求条件が変化すれば、技術選定も見直される。

そのため、DataLinerでは採用・不採用を永続的な判断ではなく、

現時点における最適解として捉えている。

これは、それらの技術が劣っているから不採用なのではない。

現在の事業規模や運用体制に対して、導入コストや運用コストが見合わないと判断したためである。

例えばKubernetesは非常に強力な技術である。

しかし、小規模事業においては複雑性そのものが負債になる場合がある。

DataLinerは、

勝てる場所で戦う

ことを重視している。

技術選定は未来への投資である

技術選定の影響は数年単位で残る。

今日の判断が、

未来の開発速度や保守コストを決める。

だからこそ、

短期的な効率だけではなく、

長期的な持続可能性を考慮する必要がある。

DataLinerでは、

技術選定を単なる開発上の判断ではなく、

事業運営そのものに関わる意思決定として捉えている。

おわりに

技術選定とは、優れた技術を探すことではない。

自分たちの目的と制約の中で、最適な技術を選ぶことである。

DataLinerは、流行を追うために技術を選定しているわけではない。

持続可能な事業運営を実現するために技術を選定している。

これからも、

事業目的への適合性、

持続可能性、

技術的負債の抑制、

そして長期運用の観点を重視しながら、

技術選定を行っていきたいと考えている。