はじめに
個人開発プロジェクトを始める際、技術選定はプロジェクトの成功において大きく影響します。
この選定プロセスで、開発スピード、メンテナンスの容易さ、そして最終的なプロダクトの品質が大きく左右されるためです。
個人開発では、限られたリソース（時間、予算、技術スキルなど）の中で最大限の成果を出す必要があります。
そのため、自分自身のスキルセットやプロジェクトの目標に最適な技術を選定することが、非効率な作業を避け、プロジェクトをスムーズに進める上で欠かせません。またその時々で毎回技術選定がガラリと変わってしまうと毎回学習コストが発生してメンテナンスも大変になります。
この記事では開発効率の向上、学習コストの削減、そして最終的な継続的なプロダクトの品質向上のために考えた視点での技術選定について記載します。
正解を見つけようとしない
まず前提として、技術選定において「正解」というものを見つけ出そうとする姿勢を諦めます。
なぜなら、技術の世界では、時間が経つにつれて新しいツールが登場し、既存のツールは改善され続けるため、今日ベストと思われる選択肢も明日にはそうでなくなる可能性が高いからです。この不変の変化を受け入れる姿勢で技術選定を行います。
技術選定は一度きりの決断ではなく、プロダクト開発の継続的なプロセスとして捉えています。
技術構成は組み替えることができる前提で考える
この変化を受け入れた上で、技術選定を行う際には「将来的に切り替えることが可能である」という前提で考え審査します。
これは、特定の技術に固執しすぎず、将来的により良い選択肢が現れたときに柔軟に移行できるように、システムの設計をある程度抽象的に保つことを意味します。
プロジェクトにおいて技術選定を行う際、依存関係を最小限に保つことは長期的なメンテナンス性や拡張性を確保する上で悩むところです。
特にフレームワークやライブラリを選ぶ場合、将来的にその選択を変更したくなる状況が生じ得ること可能性は経験上高いです。
そこで一つのフレームワークやツールに深く依存するのではなく、浅いフレームワークを組み合わせて複数の構造で柔軟に切り替えできるような設計を心がけることが重要です。
このようなアプローチは、個人開発プロジェクトだけでなく、大規模な企業プロジェクトにおいても同様に有効です。
技術選定においては、現在の「ベスト」ではなく、「将来的にも対応可能な柔軟性」を重視することが、長期的な視点での成功につながります。
一つのフレームワークを使わなくなったときに他のものは残せるようにする
このアプローチを実現するには、アプリケーションのアーキテクチャを慎重に計画し、フレームワークに依存する部分とそうでない部分を明確に分離する必要があります。
具体的には、ビジネスロジックやデータモデルなどのコアな部分はフレームワークとは独立して設計し、フレームワーク特有の機能は薄いラッパーを介して利用することで、後からの変更が容易になるようにします。
イメージとしてはコアロジックがVueからReactに変わるときにフレームワークに依存しないファイル分割などで分離できるコードはどういうものかを意識してして関数や型を分けるなどです。
また、アプリケーションの各コンポーネント間の通信はオープンスタンダードや広く採用されているプロトコルを使用することで、特定のフレームワークに縛られることなく、柔軟性を高めることができます。
これにより、将来的に新しいフレームワークやツールに移行したい場合でも、全体を書き換えるのではなく、必要な部分だけを更新することが可能になります。
このように依存関係を薄くすることは、技術の進化に対応しやすくするだけでなく、プロジェクトの持続可能性を高める上で欠かせないアプローチです。
将来的に技術選定の選択肢を広げることができるように、初期段階から慎重な設計と計画を行うことが大切だと考えています
長く使う覚悟を持つ
技術選定においては、採用する技術に長期間コミットする覚悟を持てないと選定自体が無駄になりかねません。
新しい技術やツールに飛びつくことの誘惑は強いかもしれませんが、頻繁に技術スタックを変更することは、プロジェクトの進行を大幅に遅らせ、学習コストや移行コストを増加させることになります。そのため、新しい技術を選定する際には、以下の点に注意を払います。
すぐに乗り換えるような判断はしない
技術選定を行う際には、その技術がプロジェクトにとって長期間にわたって価値を提供し続けるかを慎重に評価する必要があります。
一時的なトレンドや表面的な魅力に惑わされることなく、その技術がプロジェクトの目的、スケール、将来の方向性に合致しているかをじっくりと考慮するべきです。
最初に時間をかけて使ってみて判断をする
新しい技術をプロジェクトに採用する前に、実際にその技術を使ってみてちゃんと判断しましょう。
プロトタイピングや小規模なテストプロジェクトを通じて、技術の特性、開発者の学習曲線、生産性への影響などを詳細に評価します。
この過程を通じて、技術の長所と短所を深く理解し、プロジェクトに対する適合性を判断することができます。この時間な中で得る勘所の経験は将来役立つものだと実感しています。
長く使う判断ができなければ、保留という判断をする
すべての技術選定が明確な「はい」か「いいえ」で答えられるわけではありません。
長期間にわたってその技術にコミットする自信が持てない場合は、選定を保留にするという選択肢も有効です。
代替案の検討、さらなる情報収集、あるいはプロジェクト要件の見直しなどを行い、より確信を持てる判断ができるように努めるべきです。
長く使う覚悟を持つことは、技術選定におけるリスクを最小限に抑え、プロジェクトを安定した基盤の上で発展させるための鍵です。
その技術がプロジェクトにとって本当に価値あるものであるかを見極め、長期的なパートナーとして迎え入れる準備をして開発をしたいものです。
最近良く使う技術
2024年の今、下記のようなフレームワーク・ライブラリで開発をしています。
フロントエンド
バックエンド
関連記事
- 2024年からはTailwindを使い続けると決めた理由
- WordPressをHeadlesCMSにしてブログをAstroを使ったSSGにした
- Headless UI Libraryとデザインシステム
最後に
技術選定の話は定期的にインターネット話題になりがちで、自分も関心のある話題です。
長年、技術選定や構成に向き合ってくるとリスクを減らす方向の考え方に落ちつきました。
決めた技術選定に固執しすぎると、世間の普通の技術スタックから置いてけぼりを食らってしまうのでそのあたりは注意が必要ですね。