ウェブエンジニア問題集

BOOK / 全18

システム設計をちゃんと理解する

要件定義から詳細設計書・DB設計・API設計・設計レビューまで、Webアプリ開発で必要な設計の考え方と実務パターンを整理する入門書です。「なんとなく動くコード」から「設計されたコード」へ進むための土台を作ります。

18

153

読了目安

0円

すべて無料

目次(全18章)

  1. 01
    なぜ設計が必要なのか — コードを書く前に考えること
    4
  2. 02
    要件定義の進め方 — 機能要件と非機能要件を整理する
    6
  3. 03
    基本設計と詳細設計 — 2つの設計フェーズの違いと役割
    6
  4. 04
    詳細設計書の書き方 — 何をどこまで書くべきか
    10
  5. 05
    ER図とテーブル設計 — リレーションの考え方と正規化
    5
  6. 06
    API設計の基本 — RESTfulなエンドポイントの設計ルール
    6
  7. 07
    URL設計とルーティング — リソース指向のパス設計
    13
  8. 08
    認証と認可の設計 — セッション・JWT・OAuth
    5
  9. 09
    状態管理の設計 — サーバーとクライアントで何を持つか
    7
  10. 10
    エラー設計 — エラーコード体系・ユーザー通知・ログ戦略
    11
  11. 11
    バリデーション設計 — フロント・バックエンド・DBの3層で守る
    11
  12. 12
    伝わるコードとドキュメント — 命名・コメント・文章の技術
    8
  13. 13
    ディレクトリ構成 — 規模と責務で決めるファイル配置
    10
  14. 14
    頻出デザインパターン — Repository・Service・Factory
    10
  15. 15
    SOLID原則 — 変更に強いコードを書くための5つの指針
    14
  16. 16
    シーケンス図の書き方 — 処理の流れを可視化する
    5
  17. 17
    画面遷移図と画面設計 — UIとロジックの境界を決める
    10
  18. 18
    設計レビューの観点 — 何をチェックし、どう指摘するか
    12

この本で学べること

本書は、Webアプリ開発で必要な設計の考え方と実務パターンを整理する入門書です。要件定義から始まり、機能設計、DB設計(ER図・正規化)、API設計(RESTful設計)、詳細設計書の書き方、設計レビューの進め方までを体系的に解説します。「なんとなく動くコード」から「設計されたコード」へ進むための土台を作ります。

なぜ学ぶべきか

設計力はコードの品質と保守性に直結します。設計なしに書いたコードは機能追加や仕様変更に弱く、チーム開発で負債になりがちです。設計の考え方を身につけることで、複雑な要件にも対応でき、チームで共通認識を持って開発を進められるようになります。

前提知識

何らかのプログラミング言語でWebアプリケーションを作った経験があると理解が深まります。SQL(テーブル設計)とHTTP/APIの基礎知識があるとスムーズです。

学習トピック

要件定義と機能設計

要件の整理方法、機能一覧の作り方、ユースケースの洗い出し、MVPの考え方を学びます。

DB設計(ER図・正規化)

ER図の書き方、テーブル設計、正規化、リレーションの定義など、データベース設計の基本を理解します。

API設計(RESTful設計)

リソース設計、HTTPメソッドの使い分け、ステータスコード、エラーレスポンスの設計を学びます。

設計レビューと設計書

詳細設計書のフォーマット、設計レビューの観点、チームでの合意形成のプロセスを解説します。

こんな方におすすめ

  • 「なんとなく動くコード」から設計力を上げたい方
  • 要件定義やDB設計の基礎を体系的に学びたい方
  • チーム開発で設計レビューに参加する機会がある方
  • API設計やDB設計を実務で行うバックエンドエンジニア

よくある質問

設計の経験がなくても読めますか?
はい。設計の概念が初めての方を想定して、要件定義の基本から順に解説しています。何らかのWebアプリを作った経験があると、具体的なイメージが湧きやすくなります。
この本を読めばシステム設計面接に対応できますか?
本書はWebアプリ開発の実務設計に焦点を当てています。大規模分散システムの設計面接には別途の学習が必要ですが、設計の基本的な考え方は共通して活きます。
DB設計とAPI設計のどちらを先に学ぶべきですか?
本書の順番通り、DB設計(データモデル)を先に固めてからAPI設計に進むのがおすすめです。データ構造が決まらないとAPI設計もぶれやすくなります。