個人開発の技術選定を小さく始める
技術選定の目的は、流行している道具を当てることではありません。作りたいものを完成させ、公開後に自分で直し続けられる構成を決めることです。
初めての個人開発では、候補を増やすほど安心できるように見えます。しかし、フレームワーク、データベース、認証、ホスティングを同時に比較すると、判断だけで疲れてしまいます。最初に必要な能力を整理し、変更しにくい部分から順に決めると、選択肢を小さくできます。
この記事では、読書記録アプリを例に、要件から最小構成を作り、候補を比較し、選定理由を残すところまで説明します。
1. 利用者の操作から必要な能力を出す
最初に書くのは技術名ではなく、利用者が行う操作です。読書記録アプリなら、中心となる一周は次のようになります。
画面を開く → 本の題名を入力する → 保存する → 一覧で確かめるこの一周を、技術に必要な能力へ置き換えます。
| 利用者がすること | 必要な能力 | まだ決まっていないこと | | --- | --- | --- | | 画面を開く | Webページを表示する | 特定のフレームワークは未定 | | 題名を入力する | フォームを扱う | 複雑なUI部品は不要 | | 保存する | データを保持する | 端末内かサーバーかは要判断 | | 後で一覧を見る | 保存済みデータを読み出す | 検索や共有は初回範囲外 |
次に、要件を変える質問だけを確認します。
別の端末からも同じ記録を見る必要があるか
複数人で同じデータを使うか
ログインが必要か
個人情報や決済情報を扱うか
オフラインでも使う必要があるか
自分の一台の端末だけで使うなら、ブラウザ内の保存から始められる場合があります。複数端末で同期するなら、サーバー側の保存と利用者を識別する仕組みが必要です。この違いを決めずにデータベース製品を比較しても、適切な候補は選べません。
2. 標準機能で作れる部分を先に使う
必要な能力が分かったら、HTML、ブラウザ、利用中の言語やフレームワークが標準で持つ機能を確認します。
フォームなら、required、type="email"、minlengthなどのHTML属性で基本的な入力条件を表せます。MDNは、まず堅牢なHTMLの機能を使い、必要に応じてJavaScriptで体験を改善する流れを説明しています。ただし、ブラウザ側の検証は回避できるため、サーバーへ送るデータはサーバー側でも必ず検証します。
標準機能から始める利点は、コードが短いことだけではありません。
公式資料から動作を調べやすい
独自部品よりキーボードや支援技術へ対応しやすい
依存パッケージの更新箇所を減らせる
別の構成へ移るときに、データや画面の意味を残しやすい
独自実装が必要になったら、「標準機能では満たせない要件」を一文で書きます。理由を書けない追加技術は、いったん候補から外します。
3. 候補を同じ条件で比較する
候補は多くても二つか三つに絞り、同じ小さな課題で比べます。製品サイトの機能数ではなく、自分が運用する場面を採点します。
| 比較項目 | 確認する質問 | | --- | --- | | 完成しやすさ | 公式の手順だけで最小画面を起動できるか | | 調べやすさ | エラーの発生箇所と確認方法が分かるか | | 公開しやすさ | 開発環境と本番環境を分けて設定できるか | | 維持しやすさ | 一年後に依存関係を更新できそうか | | 撤退しやすさ | データを書き出し、別の環境へ移せるか | | 費用の読みやすさ | 無料枠を超えた後の単価と上限を説明できるか |
比較用の試作では、見た目を整えません。「一件を保存し、再読み込み後にも表示する」など、最も不確かな一点だけを動かします。三十分から半日など試作の上限時間も決めます。短い試作で公式資料にたどり着けない、エラーの意味を確認できない、データの取り出し方が分からない候補は、個人運用では大きな負担になります。
4. 未経験の要素を一度に増やさない
新しい技術を使うこと自体が問題なのではありません。問題が起きたとき、原因候補が同時に増えることが難しさにつながります。
初めてのフレームワークを使うなら、慣れた保存方法を選ぶ。初めて認証を扱うなら、画面側は慣れた構成にする。このように、今回学ぶ中心を一つにします。
次の要素は、必要になるまで追加しません。
利用者が一人なのに、複数組織向けの権限管理を作る
数十件のデータなのに、複雑な分散処理を入れる
手動で十分な作業に、先にジョブ基盤を用意する
公開予定がない試作へ、決済や通知を接続する
一方、秘密情報の分離、入力値の検証、バックアップ手段の確認は、後回しにすると作り直しや事故につながります。「機能を増やす準備」と「安全に運用する最低限」を混同しないことが大切です。
5. 中心経路を端から端まで通す
画面を作り込む前に、入口から結果までを一度つなぎます。読書記録なら、実際に一冊を入力し、保存し、画面を閉じてからもう一度表示します。
正常時だけでなく、次も確認します。
題名を空のまま保存しようとする
想定より長い題名を入力する
保存先へ接続できない状態にする
データが一件もない状態で開く
同じ操作を続けて二回行う
ここで直せない問題が出たら、別の技術を足す前に原因を一つに絞ります。入力、画面、処理、保存のどこまで期待通りだったかを記録すると、調査する範囲が分かります。
6. 決定と見直し条件を一枚に残す
選定後は、長い設計書ではなく次の内容を一枚に残します。
選んだ構成:
解決する要件:
選ばなかった候補と理由:
最大の不確実性:
データを書き出す方法:
月額費用の想定範囲:
見直す条件:見直す条件は「利用者が増えたら」ではなく、「保存件数が上限の80%に達したら」「月額費用が予算を二か月連続で超えたら」のように観察できる形にします。
技術選定は未来をすべて予測する作業ではありません。現在の要件を満たす小さな構成を選び、どの事実が変わったら見直すかを決める作業です。中心経路を一周でき、選んだ理由と撤退方法を説明できれば、最初の開発へ進めます。