新しいサービス開発を軌道に乗せるために最初にやるべきこと

はじめに

新しいサービスの案が出てきた。さあ、システムを構築していこう。

このステップに立った時、何を最初に考えますか？
この最初のステップで何を考えるかで、今後のシステム開発の負担が大きく変わってきます。
未来の自分に降りかかるリスクも回避できます。

---

1. 要件定義：サービスの本質を見極める

最も重要な問い

新しいサービス開発で最初に考えるべきこと、それは：

「最終的にサービスを経て、ユーザーに何を提供するのか」

この問いに明確に答えられない状態で開発を始めるのは、地図を持たずに航海に出るようなものです。

なぜこの問いが重要なのか

多くの開発プロジェクトは、「こんな機能があったら便利そう」「この技術を使ってみたい」という出発点から始まります。
しかし、それだけでは不十分です。

重要なのは：

• ユーザーのどんな課題を解決するのか
• ユーザーは最終的にどんな価値を得られるのか
• その価値を提供するために本当に必要な機能は何か

この本質が見えていないと、不要な機能の開発に時間を費やしたり、本当に必要な機能を見落としたりします。

要件定義が曖昧だと何が起きるか

1. 設計が定まらない

「後で機能追加するかも」「こっちのパターンもあるかも」と迷い続け、設計が決まりません。
結果として、過剰に抽象化された複雑な設計か、逆に拡張性のない硬直した設計になってしまいます。

2. 手戻りが頻繁に発生する

開発途中で「やっぱりこの機能も必要だ」「この仕様では足りない」と気づき、作り直しが発生します。

最悪の事態：データベース設計の作り直し

特に痛いのがDB構造の作り直しです。

例えば：

• 最初は「ユーザーは1つの組織にしか所属しない」前提で設計
• 後から「複数組織に所属できるようにしたい」という要件が出てくる
• テーブル構造を根本から変更（中間テーブルの追加など）
• 既存データのマイグレーション作業が必要
• 関連するコード全体に影響が波及

このような作り直しは、初期段階で要件を詰めておけば避けられたものです。

他にもよくあるパターン：

• 「削除機能」が後から必要に → 論理削除フラグの追加とクエリの全面修正
• 「履歴を保持したい」が後から出てくる → 履歴テーブルの設計と実装
• 「多言語対応が必要」に → テキストデータの正規化と関連テーブルの追加

3. 開発スピードが落ちる

手戻りが発生すると：

• 同じ箇所を何度も修正する時間的ロス
• モチベーションの低下
• 技術的負債の蓄積
• リリースの遅延

結果的に、「早くリリースしよう」と急いで始めたはずが、最も遅くなるという皮肉な状態に陥ります。

要件定義で明確にすべきこと

ユーザーストーリーを具体化する

• 誰が：ターゲットユーザーは誰か（ペルソナ設定）
• 何をしたくて：ユーザーが達成したいことは何か
• どうなる：サービスを使うことでどう変わるか

データモデルの骨格を決める

• 扱うデータの種類と関係性
• データのライフサイクル（作成・更新・削除・アーカイブ）
• データの所有権と権限設計

機能の優先順位を決める

• Must Have：これがないとサービスが成立しない
• Should Have：あった方が良いが、初期リリースではなくても良い
• Could Have：将来的にあると便利
• Won't Have (now)：今は絶対にやらない

要件定義のゴール

「このサービスは何をするもので、何をしないものか」をチーム全員が同じ認識で理解できている状態。

これが達成できていれば：

• 技術選定の方向性が定まる
• データベース設計が一発で決まる
• 開発中の迷いが減る
• 本当に必要な機能に集中できる

時間をかけるべきは、コードを書く前のこの段階です。

ここで1週間考え抜くことが、後の3ヶ月の手戻りを防ぎます。

---

2. 法律・規則の調査：後で困らないために

なぜこの段階で調べるのか

要件が固まったら、次にやるべきは法律・規則の徹底調査です。

多くの開発者は「とりあえず作ってから考えよう」と後回しにしがちですが、これは危険です。
なぜなら、法的な制約は技術選定やアーキテクチャ設計に直接影響するからです。

開発が進んでから「実はこの方法は違法でした」となれば、大規模な作り直しが必要になります。
最悪の場合、サービス自体が成立しなくなることも。

調査すべき法律・規則の例

サービスの性質によって調べるべき内容は変わりますが、代表的なものは以下です：

データ取得・利用系：

• スクレイピング：利用規約違反、著作権法、不正アクセス禁止法
• 個人情報保護法：何が個人情報に該当するか、取得・保管・利用の要件
• Cookie規制：GDPR（EU）、ePrivacy指令、改正電気通信事業法（日本）

商取引系：

• 特定商取引法：販売者情報の表示義務、返品・キャンセルポリシー
• 景品表示法：誇大広告の禁止、比較表示のルール
• 資金決済法：前払式支払手段、暗号資産の取り扱い

コンテンツ系：

• 著作権法：引用の要件、二次創作の扱い
• 商標権：サービス名・ロゴの使用可否
• 肖像権・パブリシティ権：人物画像の利用

調査内容の活用：3つの視点

1. 安全な方法の特定

「どうすれば合法的にサービスを提供できるか」を明確にします。

例：スクレイピングの場合

• robots.txtの確認
• 利用規約の確認（API提供の有無）
• アクセス頻度の制限設計
• User-Agentの明示

2. グレーゾーンの見極め

法律の「抜け穴」というより、許容範囲を正確に把握することが重要です。

例：個人情報の扱い

• 匿名化・仮名化すれば個人情報に該当しない場合がある
• 統計情報として処理すれば利用目的の制約が緩和される
• オプトイン/オプトアウトの設計方針が決まる

これにより、過度に保守的にならず、かといってリスクも回避できる設計が可能になります。

3. 技術選定の判断材料

法的要件が技術選択を制約することがあります。

例：データ保管場所

• GDPR対応が必要 → EUリージョンのサーバーが必要 → AWS/GCPのリージョン選択に影響
• 医療情報を扱う → HIPAA準拠が必要 → 対応しているクラウドサービスに限定される

例：認証方式

• 金融系サービス → 二要素認証必須 → 認証サービスの選定に影響
• 未成年を対象 → 年齢確認の仕組みが必要 → 本人確認APIの組み込み

調査の進め方

1. 公式情報を確認：関連する法律の条文、官公庁のガイドライン
2. 判例を調べる：過去に同様のケースでどう判断されたか
3. 必要なら専門家に相談：弁護士、行政書士（初期投資として考える）
4. ドキュメント化：調査結果をまとめ、チーム全体で共有

この段階を怠るとどうなるか

• リリース直前に法的問題が発覚し、大幅な仕様変更
• サービス開始後に訴訟リスク、行政指導のリスク
• ユーザーの信頼を失う
• 最悪の場合、サービス停止

法律調査は面倒ですが、後から修正する方が何倍も面倒です。
この段階でしっかり調べておくことが、結果的に開発スピードを加速させます。

---

3. 技術スタック・アーキテクチャの選定

3つの優先順位

法律・規則の調査で得たナレッジをもとに、技術スタックとアーキテクチャを決めていきます。
このとき、私が常に意識している優先順位は以下の3つです。

1. 早いこと - 開発・市場投入スピード
2. 安いこと - コスト効率
3. スケールしやすいこと - 将来の成長に対応

1. 早いこと：スピードが全てを決める

新しいサービスはスピード勝負です。

勉強目的でない限り、バックエンドのインフラを全てゼロから構築するべきではありません。
サーバー設定やCI/CD環境の構築に数週間かけている間に、競合がリリースしているかもしれません。

具体的には：

• マネージドサービスを活用（Firebase、Supabase、AWS Amplifyなど）
• フレームワークは枯れた技術で実績のあるものを選ぶ
• ボイラープレートやテンプレートを積極的に使う

本当の目的は「サービスをユーザーに届けること」であり、インフラ構築ではありません。

2. 安いこと：機能の多さではなく、必要十分性

高機能で高価なサービスより、自分が求めている機能が使える最も安いサービスを選びます。

判断基準：

• 必要な機能だけに絞る（使わない機能のために高額プランを選ばない）
• 無料枠・スタータープランから始める
• 従量課金の上限設定ができるか確認する

例えば、認証機能が必要なだけなら、Auth0やSupabase Auth、Firebase Authenticationなどの無料枠で十分なケースが多いです。
フルスペックのユーザー管理システムを自前で構築する必要はありません。

3. スケールしやすいこと：小さく始めて、大きく育てる

初期リリースは60〜70点で出すものだと考えています。

最初から完璧を目指すと、リリースが遅れるだけでなく、ユーザーの本当のニーズとズレたものを作ってしまうリスクがあります。
むしろ試験的に運用し、ユーザーのフィードバックをもらいながらブラッシュアップしていく方が成功確率が高い。

そのために必要なこと：

• 最初は最小スペック（小さいインスタンス、低いプラン）でスタート
• ユーザーが増えてきたらCPU/メモリを垂直スケール（スケールアップ）
• さらに必要なら水平スケール（スケールアウト）できる設計にしておく

具体例：

• データベース：最初はPostgreSQLの小さいインスタンス → 必要に応じてスペックアップ → リードレプリカ追加
• サーバー：Vercel/Netlifyの無料枠 → Pro プラン → Enterprise
• ストレージ：S3やCloudflareR2のような従量課金サービスなら自動でスケール

この順番を守ることで、初期コストを抑えながら、素早くリリースし、成長に合わせて拡張できる理想的な開発サイクルが回せます。

---

4. 設計：未来の自分を助ける設計をする

設計の目的：変化に強く、理解しやすいシステムを作る

要件が固まり、法律を調べ、技術スタックを選んだ。次はいよいよ設計です。

ここで重要なのは、「今動くコード」を書くことではなく、「未来も変更しやすいシステム」を設計することです。

新しいサービスは必ず変化します。ユーザーのフィードバック、新機能の追加、スケールに伴う改修。
この変化に耐えられる設計をしておくことが、開発スピードを維持する鍵になります。

設計で意識すべき3つの原則

1. シンプルであること

複雑な設計は悪い設計です。

初期段階で最もやってはいけないのが、「将来こうなるかもしれない」という想像だけで過度に抽象化・汎用化すること。

よくある失敗パターン：

• 使うかどうか分からない機能のために拡張ポイントを大量に用意
• 「いつか複数パターンが必要になるかも」と抽象クラスや複雑な継承構造を作る
• 結局使わない設計パターンを無理やり適用

シンプルな設計の基準：

• 3ヶ月後の自分が読んで、すぐに理解できるか
• 新しいメンバーが見て、何をしているか分かるか
• 1つの機能が1箇所にまとまっているか

初期段階では、具体的でシンプルな実装の方が遥かに価値があります。
複雑さは必要になってから追加すればいい。

2. 疎結合であること

モジュール間の依存を最小限にすることで、変更の影響範囲を限定します。

なぜ疎結合が重要か：

例えば、メール送信機能を考えてみましょう。
最初はSendGridを使っていたけど、後からコストの問題でResendに変更したくなった。

このとき、システムのあちこちでSendGridのAPIを直接呼んでいたら？
全ての箇所を修正する必要があります。

しかし、「メールを送る」という抽象的なインターフェースを定義しておけば、実装を差し替えるだけで済みます。

疎結合を実現する考え方：

• レイヤー分け：画面、ビジネスロジック、データアクセスを分離
• 抽象に依存：具体的な実装ではなく、「何をするか」のインターフェースに依存
• イベント駆動：直接呼び出しではなく、イベントを介して連携

これにより、外部サービスの変更、データベースの変更、UIライブラリの変更などが局所的な修正で済むようになります。

3. テスタブルであること

テストしやすい設計 = 変更しやすい設計です。

テストが書きにくいコードは、たいてい以下の特徴があります：

• 外部依存（DB、API）が直接埋め込まれている
• グローバル状態に依存している
• 1つの関数が複数の責任を持っている

逆に、テストしやすい設計にしておけば：

• リファクタリングが安全にできる（テストが壊れたらすぐ分かる）
• バグの影響範囲が特定しやすい
• 新機能追加時の既存機能への影響を検証できる

初期段階では完璧なテストカバレッジは不要ですが、「テストを書けるような設計」にしておくことは重要です。

データベース設計：最も慎重に

データベース設計は後から変更するコストが最も高い部分です。

なぜデータベース設計が重要か

セクション1でも触れましたが、データベース設計のやり直しは悲劇的です。

• テーブル構造の変更
• 既存データのマイグレーション
• 関連する全てのクエリの修正
• アプリケーションコードへの波及

この手戻りを避けるために、最初に考えておくべきことがあります。

データの関係性を見極める

1対1、1対多、多対多の関係を明確にする

よくある失敗例：

• 「ユーザーは1つの組織にしか所属しない」と決めつけて設計
• 後から「複数組織に所属できる**ようにしたい」という要件が出る
• 中間テ**ーブルを追加し、関連コード全体を修正

要件定義の段階で、このような関係性を洗い出しておくことが重要です。

拡張性を考慮した基本設計

最初から決めておくべきこと：

• 削除の方針：論理削除か物理削除か

  • 論理削除なら全てのクエリに「削除されていない」条件が必要
  • 最初に決めないと後から全クエリを修正する羽目に

• タイムスタンプ：作成日時・更新日時は必須

  • デバッグ時に絶対必要になる
  • 後から追加すると既存データに遡れない

• 履歴管理：データの変更履歴が必要か

  • 後から「履歴を見たい」と言われても過去のデータは復元できない

正規化の判断

基本は正規化（データの重複を避ける）が原則ですが、パフォーマンスとのトレードオフがあります。

初期段階では正規化を優先し、パフォーマンス問題が実際に発生してから非正規化を検討する。
「将来遅くなるかも」という想像だけで最適化しない。

ドキュメント：設計の意図を残す

設計で決めたことは、必ず記録に残します。

なぜドキュメントが必要か

3ヶ月後、あなたは今の決定理由を忘れています。
6ヶ月後、新しいメンバーが「なんでこんな設計にしたの？」と聞いてきます。

そのとき、記録がなければ：

• 「たぶんこういう理由だったと思う...」と曖昧になる
• 同じ議論を何度も繰り返す
• 過去の失敗を知らずに同じ過ちを繰り返す

最低限残すべきもの

• ER図か何か、DB構造がわかるもの：テーブル構造と関連（今後の拡張判断に必須）
• アーキテクチャ図：システムの全体像、データの流れ
• ADR（Architecture Decision Record）：なぜその技術・設計を選んだか

特に重要なのが最後の「なぜ」です。
「何を選んだか」は後からコードを見れば分かりますが、「なぜそれを選んだか」は記録しないと永遠に失われます。

設計のゴール：変更が怖くない状態を作る

良い設計ができていれば：

• 新機能の追加が局所的な変更で済む
• バグの影響範囲が限定される
• 新しいメンバーがコードを理解しやすい
• リファクタリングが安全にできる

「変更が怖くない」

これが良い設計の証明です。

逆に、「このコード触りたくないな...」と思う設計は、開発スピードを確実に落とします。

設計に時間をかけることは、未来の開発スピードへの投資です。
急がば回れ、最初にしっかり設計しておくことが、結果的に最速のリリースにつながります。

---

まとめ

新しいサービス開発で開発スピードを軌道に乗せるためには、最初の4つのステップが重要です。

1. 要件定義：ユーザーに何を提供するのか、本質を見極める
2. 法律・規則の調査：法的リスクを事前に潰し、技術選定の判断材料にする
3. 技術スタック選定：早い・安い・スケールしやすいを優先順位に選ぶ
4. 設計：変化に強く、未来の自分を助ける設計をする

これらのステップを丁寧に進めることが、結果的に最速のリリースと持続的な開発スピードにつながります。

どんなに実装が簡単に見えても自他の、「簡単でしょ」「すぐできるでしょ」という言葉に騙されて、これらの工程を省いてはいけません。

最初の手抜きは、必ず後で数倍の苦労となって自分に返ってくる。

舐めてかかった分の代償は、手戻り、バグ、スケジュール遅延という形で、未来の自分が支払うことになります。
そして、その責任は誰も取ってくれません。逃れることはできません。