詳細設計(内部設計)の進め方 – クラス設計からモジュール分割まで

「基本設計が終わったけど、ここから先のクラス設計やモジュール分割がよくわからない…」

そんな不安を抱えていませんか?

45歳のあなたは、長年プログラマとして実装に携わってきました。しかし、**「詳細設計書を書く」**という上流工程の経験は、意外と少ないのではないでしょうか。

「基本設計までは何となく理解できるが、そこから実装レベルに落とし込む詳細設計が書けない」「クラス図やシーケンス図をどう描けばいいのかわからない」「モジュール分割の基準が曖昧で、設計レビューで指摘される」——そんな悩みは、決してあなただけではありません。

実は、詳細設計こそが「実装者が迷わず開発できるか」を左右する最重要工程です。ここを押さえることで、あなたは「設計ができるエンジニア」として、年収650万円以上の上流工程職に転職できる可能性が高まります。

この記事では、詳細設計の基本的な進め方から、クラス設計・モジュール分割の実践テクニックまでを、実務で即使える形でお伝えします。完璧を目指す必要はありません。まずは「今日から使える基礎知識」を身につけましょう。

---

詳細設計とは何か? – 基本設計との違いを理解する

結論

詳細設計は、**「実装者が迷わずコードを書ける状態まで仕様を具体化する」**工程です。

理由

基本設計(外部設計)が「何を作るか」を定義するのに対し、詳細設計(内部設計)は**「どう作るか」を定義**します。

具体的には、以下のような違いがあります:

基本設計(外部設計)

• 画面レイアウト、帳票フォーマット、外部IFの仕様
• ユーザーから見える振る舞いを定義
• 「何を表示するか」「どんなデータを受け渡すか」

詳細設計(内部設計)

• クラス構成、メソッド定義、データ構造
• プログラム内部の処理ロジックを定義
• 「どのクラスがどのメソッドを持つか」「どう処理を分割するか」

つまり、詳細設計は「実装者への設計図」であり、ここが曖昧だと実装者が迷い、品質が低下し、手戻りが発生します。

具体例

詳細設計が不十分だった失敗例

あるプロジェクトで、基本設計書には「ユーザー情報を取得して画面に表示する」とだけ書かれていました。しかし、詳細設計書がなかったため、実装者は以下の判断を迫られました:

• データベースから直接取得するのか、APIを経由するのか?
• 取得したデータはどのクラスに格納するのか?
• エラー時の処理はどうするのか?

結果、実装者ごとにバラバラな実装となり、レビューで大量の修正指摘が発生。開発遅延と品質低下を招きました。

詳細設計が適切だった成功例

別のプロジェクトでは、詳細設計書に以下が明記されていました:

• UserServiceクラスのgetUserInfo()メソッドでAPI経由取得
• 取得データはUserDTOクラスに格納
• エラー時はCustomExceptionをスローし、呼び出し元でハンドリング

この結果、実装者は迷うことなくコードを書け、レビュー指摘もほとんどなく、予定通りリリースできました。

まとめ

詳細設計は、実装品質とプロジェクト成功を左右する重要工程です。基本設計との違いを理解し、「実装者が迷わない設計書」を書くことが目標です。

---

クラス設計の基本 – オブジェクト指向の3原則を押さえる

結論

クラス設計の基礎は、オブジェクト指向の**「カプセル化」「継承」「ポリモーフィズム」**の3原則です。

理由

詳細設計では、プログラムをどのようなクラスに分割し、どのようなメソッドを持たせるかを決めます。この際、オブジェクト指向の3原則を理解していないと、以下のような問題が発生します:

• 1つのクラスにすべての処理を詰め込んでしまう(神クラス)
• データとそれを操作する処理が分離してしまう
• 同じような処理が複数箇所に重複する

これらは保守性を著しく低下させ、「変更に弱いコード」を生み出します。

具体例

カプセル化 – データと処理を1つにまとめる

カプセル化とは、データ(属性)とそれを操作する処理(メソッド)を1つのクラスにまとめ、外部から直接データにアクセスさせない設計原則です。

// 悪い例：データと処理が分離
public class User {
    public String name;
    public int age;
}

public class UserService {
    public boolean isAdult(User user) {
        return user.age >= 20;
    }
}

// 良い例：データと処理をカプセル化
public class User {
    private String name;
    private int age;
    
    public boolean isAdult() {
        return this.age >= 20;
    }
}

継承 – 共通処理をまとめる

継承とは、共通する属性やメソッドを持つ基底クラス(親クラス)を定義し、個別の特性を持つ派生クラス(子クラス)がそれを引き継ぐ仕組みです。

// 基底クラス
public abstract class Employee {
    protected String name;
    protected int baseSalary;
    
    public abstract int calculateSalary();
}

// 派生クラス
public class RegularEmployee extends Employee {
    public int calculateSalary() {
        return baseSalary;
    }
}

public class ContractEmployee extends Employee {
    private int hourlyRate;
    private int workedHours;
    
    public int calculateSalary() {
        return hourlyRate * workedHours;
    }
}

ポリモーフィズム – 同じインターフェースで異なる振る舞い

ポリモーフィズムとは、同じメソッド名やインターフェースを使いながら、オブジェクトの種類によって異なる処理を実行できる仕組みです。

List<Employee> employees = new ArrayList<>();
employees.add(new RegularEmployee());
employees.add(new ContractEmployee());

for (Employee emp : employees) {
    // 同じメソッド呼び出しでも、各クラスの実装が実行される
    int salary = emp.calculateSalary();
}

まとめ

オブジェクト指向の3原則を理解し、クラス設計に反映させることで、保守性が高く変更に強いコードが実現できます。

【おすすめ学習教材】

Udemy – オブジェクト指向設計講座 実務で使えるオブジェクト指向設計を体系的に学べます(セール時1,200円〜)

Kindle Unlimited – オブジェクト指向でなぜつくるのか 通勤時間に読める名著。月額980円で技術書が読み放題

---

モジュール分割の基準 – 単一責任の原則と凝集度

結論

モジュール分割は、**「1つのクラス/モジュールは1つの責任だけを持つ」**という単一責任の原則(SRP)に従います。

理由

1つのクラスに複数の責任を持たせると、以下の問題が発生します:

• 変更時の影響範囲が大きくなる
• テストが困難になる
• コードの可読性が低下する

単一責任の原則を守ることで、**「変更に強く、テストしやすく、理解しやすい」**設計が実現できます。

具体例

悪い例：複数の責任を持つクラス

public class UserManager {
    // データベースアクセス
    public User getUserFromDB(int userId) { ... }
    
    // ビジネスロジック
    public boolean validateUser(User user) { ... }
    
    // 画面表示用データ整形
    public String formatUserInfo(User user) { ... }
    
    // メール送信
    public void sendWelcomeEmail(User user) { ... }
}

このクラスは、データアクセス・ビジネスロジック・表示整形・外部連携という4つの責任を持っています。

良い例：責任ごとに分割

// データアクセス層
public class UserRepository {
    public User findById(int userId) { ... }
}

// ビジネスロジック層
public class UserService {
    private UserRepository userRepository;
    
    public boolean validateUser(User user) { ... }
}

// プレゼンテーション層
public class UserFormatter {
    public String formatUserInfo(User user) { ... }
}

// 外部連携層
public class EmailService {
    public void sendWelcomeEmail(User user) { ... }
}

各クラスが1つの責任だけを持つため、変更時の影響が局所化され、テストも容易になります。

凝集度を高める設計

凝集度とは、クラス内のメソッドやデータがどれだけ関連しているかを示す指標です。凝集度が高いほど、良い設計です。

凝集度が低い例

public class Utility {
    public int calculateAge(Date birthDate) { ... }
    public String formatCurrency(int amount) { ... }
    public boolean validateEmail(String email) { ... }
}

関連性のない処理が1つのクラスに混在しています。

凝集度が高い例

public class AgeCalculator {
    public int calculateAge(Date birthDate) { ... }
    public boolean isAdult(Date birthDate) { ... }
}

public class CurrencyFormatter {
    public String format(int amount) { ... }
    public String formatWithSymbol(int amount, String symbol) { ... }
}

関連する処理が1つのクラスにまとまっています。

まとめ

単一責任の原則と高凝集度を意識することで、保守しやすく変更に強い設計が実現できます。クラス設計で迷ったら、「このクラスの責任は1つだけか?」を自問してください。

---

レイヤーアーキテクチャの設計 – 責任の階層化

結論

詳細設計では、システムをプレゼンテーション層・ビジネスロジック層・データアクセス層の3層に分割します。

理由

レイヤーアーキテクチャ(階層化アーキテクチャ)は、システムを責任ごとに階層分割する設計パターンです。これにより、以下のメリットが得られます:

• 各層の変更が他層に影響しない
• テストが層ごとに独立して行える
• 開発の分業がしやすい

特にWeb アプリケーションでは、この3層構造が標準的な設計パターンとして広く採用されています。

具体例

3層アーキテクチャの基本構成

プレゼンテーション層(Presentation Layer)

• 役割:ユーザーインターフェースの制御
• 含まれるもの:画面表示、入力値の受け取り、表示用データ整形
• 例:Controller、View、Presenter

ビジネスロジック層(Business Logic Layer)

• 役割:業務ロジックの実装
• 含まれるもの:計算処理、検証、業務ルールの適用
• 例:Service、UseCase、Domain Model

データアクセス層(Data Access Layer)

• 役割:データの永続化と取得
• 含まれるもの:データベースアクセス、外部API連携
• 例:Repository、DAO、Gateway

実装例:ユーザー登録処理

// プレゼンテーション層
public class UserController {
    private UserService userService;
    
    public void registerUser(UserRequest request) {
        User user = new User(request.getName(), request.getEmail());
        userService.register(user);
    }
}

// ビジネスロジック層
public class UserService {
    private UserRepository userRepository;
    
    public void register(User user) {
        // ビジネスルールのチェック
        if (!user.isValidEmail()) {
            throw new ValidationException("Invalid email");
        }
        
        // 重複チェック
        if (userRepository.existsByEmail(user.getEmail())) {
            throw new BusinessException("User already exists");
        }
        
        // 保存
        userRepository.save(user);
    }
}

// データアクセス層
public class UserRepository {
    public void save(User user) {
        // データベースへの保存処理
    }
    
    public boolean existsByEmail(String email) {
        // メールアドレスの存在チェック
    }
}

依存関係のルール

レイヤーアーキテクチャでは、上位層は下位層に依存できるが、下位層は上位層に依存してはいけないというルールがあります。

プレゼンテーション層
       ↓(依存OK)
ビジネスロジック層
       ↓(依存OK)
データアクセス層

このルールにより、データベースを変更してもビジネスロジック層には影響せず、画面仕様が変わってもビジネスロジック層には影響しません。

まとめ

レイヤーアーキテクチャによる階層化は、変更に強く保守しやすいシステムを実現する基本パターンです。詳細設計では、各クラスがどの層に属するかを明確にしましょう。

---

データ構造の設計 – DTOとエンティティの使い分け

結論

詳細設計では、DTO(Data Transfer Object)とエンティティ(Entity)を明確に使い分けることが重要です。

理由

データを扱うオブジェクトには、役割に応じて複数の種類があります。これらを混同すると、以下の問題が発生します:

• ビジネスロジックが画面表示用のデータに依存してしまう
• データベース構造の変更が全体に波及する
• テストが困難になる

役割ごとにデータオブジェクトを分けることで、各層の独立性が高まり、変更に強い設計が実現できます。

具体例

エンティティ(Entity) – ビジネスロジック層のデータ

エンティティは、業務の概念を表現するオブジェクトです。ビジネスルールや計算ロジックを持ちます。

public class User {
    private Long id;
    private String name;
    private String email;
    private LocalDate birthDate;
    
    // ビジネスロジックを持つ
    public boolean isAdult() {
        return Period.between(birthDate, LocalDate.now()).getYears() >= 20;
    }
    
    public boolean isValidEmail() {
        return email.matches("^[A-Za-z0-9+_.-]+@(.+)$");
    }
}

DTO(Data Transfer Object) – 層間のデータ受け渡し

DTOは、層間でデータを受け渡すためのオブジェクトです。ロジックを持たず、データの入れ物に徹します。

// プレゼンテーション層からビジネスロジック層へのデータ転送
public class UserRegistrationRequest {
    private String name;
    private String email;
    private String birthDate;
    
    // getter/setterのみ
}

// ビジネスロジック層からプレゼンテーション層へのデータ転送
public class UserResponse {
    private Long id;
    private String name;
    private String email;
    private boolean isAdult;
    
    // getter/setterのみ
}

使い分けの実践例

// プレゼンテーション層
public class UserController {
    private UserService userService;
    
    public UserResponse register(UserRegistrationRequest request) {
        // DTOからエンティティへ変換
        User user = new User(
            request.getName(),
            request.getEmail(),
            LocalDate.parse(request.getBirthDate())
        );
        
        // ビジネスロジック層で処理
        User savedUser = userService.register(user);
        
        // エンティティからDTOへ変換
        return new UserResponse(
            savedUser.getId(),
            savedUser.getName(),
            savedUser.getEmail(),
            savedUser.isAdult()
        );
    }
}

なぜ分ける必要があるのか?

悪い例:エンティティを直接使う

// プレゼンテーション層で直接エンティティを使う
public UserEntity register(UserEntity userEntity) {
    return userService.register(userEntity);
}

この場合、画面で必要な項目が増えるたびにエンティティを変更する必要があり、ビジネスロジックへの影響が避けられません。

良い例:DTOで分離

// 画面専用のDTOを使う
public UserResponse register(UserRegistrationRequest request) {
    User user = convertToEntity(request);
    User savedUser = userService.register(user);
    return convertToResponse(savedUser);
}

画面仕様が変わってもDTOだけ変更すれば良く、エンティティやビジネスロジックには影響しません。

まとめ

DTOとエンティティを適切に使い分けることで、各層の独立性が高まり、変更に強い設計が実現できます。詳細設計では、データオブジェクトの役割を明確にしましょう。

---

エラーハンドリングの設計 – 例外処理の階層化

結論

詳細設計では、例外処理をどの層で行うかを明確に定義します。

理由

エラー処理が曖昧だと、以下の問題が発生します:

• 同じエラーが複数箇所で処理され、コードが重複する
• エラーメッセージが統一されず、ユーザーに混乱を与える
• エラーログが不十分で、障害調査が困難になる

詳細設計で例外処理の方針を決めることで、一貫性のあるエラーハンドリングが実現できます。

具体例

例外の階層化

// ビジネス例外(回復可能なエラー)
public class BusinessException extends Exception {
    private String errorCode;
    
    public BusinessException(String errorCode, String message) {
        super(message);
        this.errorCode = errorCode;
    }
}

// システム例外(回復不可能なエラー)
public class SystemException extends RuntimeException {
    public SystemException(String message, Throwable cause) {
        super(message, cause);
    }
}

層ごとの例外処理

データアクセス層:技術的な例外をシステム例外に変換

public class UserRepository {
    public User findById(Long id) {
        try {
            return jdbcTemplate.queryForObject(sql, rowMapper, id);
        } catch (EmptyResultDataAccessException e) {
            // データなしは業務例外として扱う
            throw new BusinessException("USER_NOT_FOUND", "User not found");
        } catch (DataAccessException e) {
            // その他のDB例外はシステム例外として扱う
            throw new SystemException("Database access error", e);
        }
    }
}

ビジネスロジック層:業務ルール違反を業務例外でスロー

public class UserService {
    public void register(User user) {
        // 業務ルールチェック
        if (!user.isValidEmail()) {
            throw new BusinessException("INVALID_EMAIL", "Invalid email format");
        }
        
        if (userRepository.existsByEmail(user.getEmail())) {
            throw new BusinessException("DUPLICATE_EMAIL", "Email already exists");
        }
        
        userRepository.save(user);
    }
}

プレゼンテーション層:例外をキャッチしてユーザーに適切なメッセージを表示

public class UserController {
    public Response register(UserRequest request) {
        try {
            User user = convertToEntity(request);
            userService.register(user);
            return Response.success("User registered successfully");
        } catch (BusinessException e) {
            // ビジネス例外はユーザーに説明可能なエラー
            return Response.error(e.getErrorCode(), e.getMessage());
        } catch (SystemException e) {
            // システム例外はログ記録して汎用エラーメッセージを表示
            logger.error("System error occurred", e);
            return Response.error("SYSTEM_ERROR", "An unexpected error occurred");
        }
    }
}

まとめ

例外処理を層ごとに明確に設計することで、一貫性のあるエラーハンドリングと適切なログ記録が実現できます。

【おすすめツール】

Sentry エラー監視ツール。本番環境のエラーをリアルタイムで通知・分析できます(月額課金)

---

詳細設計書のドキュメント構成 – 実装者が迷わない書き方

結論

詳細設計書は、実装者が読んで迷わないことを最優先に書きます。

理由

詳細設計書の読者は実装者です。設計者の意図が伝わらなければ、実装者は推測で実装せざるを得ず、結果として品質低下や手戻りが発生します。

「詳細設計書を読めば、コードがほぼ書ける状態」を目指すことが、詳細設計の成功条件です。

具体例

詳細設計書の基本構成

1. クラス構成図

• システム全体のクラス関係を俯瞰できる図
• 各クラスの責任と依存関係を明示

2. クラス仕様書(各クラスごと)

• クラス名と責任
• 属性(フィールド)一覧
• メソッド一覧(引数、戻り値、処理概要)

3. シーケンス図

• 主要な処理フローをオブジェクト間のやり取りで表現
• どのクラスのどのメソッドがどの順番で呼ばれるかを明示

4. データ構造定義

• DTO、エンティティの詳細仕様
• 各フィールドの型、制約、説明

5. 処理詳細仕様

• 複雑なアルゴリズムは擬似コードやフローチャートで表現
• 条件分岐やループ処理の詳細

6. 例外処理仕様

• 発生しうる例外とその処理方法
• エラーメッセージ一覧

実装者が迷わないクラス仕様書の書き方

悪い例:曖昧な記述

クラス名:UserService
責任:ユーザー関連の処理
メソッド:registerUser()

これでは実装者は何をすればいいかわかりません。

良い例:具体的な記述

クラス名:UserService
責任:ユーザー登録に関するビジネスロジックの実行

【メソッド】registerUser
引数:User user(ユーザーエンティティ)
戻り値:User(登録後のユーザーエンティティ、IDが設定される)
処理概要:
  1. メールアドレスの形式チェック(正規表現)
  2. メールアドレスの重複チェック(UserRepository.existsByEmail)
  3. 重複がある場合はBusinessException("DUPLICATE_EMAIL")をスロー
  4. UserRepository.save()でDB保存
  5. 保存後のUserオブジェクトを返す
例外:
  - BusinessException("INVALID_EMAIL"):メール形式不正
  - BusinessException("DUPLICATE_EMAIL"):メール重複
  - SystemException:DB接続エラー等

実装者はこれを読めば、ほぼそのままコードに落とし込めます。

ツールの活用

詳細設計書は、以下のツールで効率的に作成・管理できます:

Notion 設計書、仕様書、タスク管理を一元化。無料プランでも十分使えます

Confluence チーム向けドキュメント管理ツール。バージョン管理が容易(月額課金)

まとめ

詳細設計書は、実装者が迷わずコードを書ける状態を目指して書きます。曖昧さを排除し、具体的に記述することが成功の鍵です。

---

設計レビューのポイント – 品質を高める相互チェック

結論

詳細設計は、必ず第三者によるレビューを受けることで品質が高まります。

理由

設計者自身では気づかない問題が、必ず存在します。特に以下のような問題は、レビューによって発見されることが多いです:

• 処理の抜け漏れ
• 例外処理の不足
• 不適切なクラス分割
• パフォーマンス上の問題

レビューを通じて、設計品質を向上させるだけでなく、チーム全体の設計スキルも向上します。

具体例

詳細設計レビューのチェック観点

1. 完全性の確認

• すべての機能要件が詳細設計に反映されているか?
• 非機能要件(性能、セキュリティ等)も考慮されているか?

2. 一貫性の確認

• 命名規則が統一されているか?
• クラス分割の基準が一貫しているか?
• 例外処理の方針が統一されているか?

3. 実装可能性の確認

• この設計で本当に実装できるか?
• 曖昧な部分はないか?
• 実装工数は妥当か?

4. 保守性の確認

• 将来の変更に強い設計か?
• クラスの責任は明確か?
• テストしやすい設計か?

5. パフォーマンスの確認

• ループ処理で性能問題は起きないか?
• データベースアクセスは最適化されているか?

レビュー指摘の例

指摘1:単一責任の原則違反

指摘:UserServiceクラスがDB接続も担当しているため、
    責任が過大です。UserRepositoryクラスに分離すべきです。

対応:UserRepositoryクラスを新設し、DB操作を移動しました。

指摘2:例外処理の不足

指摘:外部API呼び出しでタイムアウトが発生する可能性がありますが、
    例外処理が定義されていません。

対応:例外仕様に「APITimeoutException」を追加し、
    リトライ処理を実装する旨を記載しました。

指摘3:パフォーマンス問題

指摘:ループ内でDB検索を実行すると、N+1問題が発生します。

対応:バッチ取得に変更し、処理効率を改善しました。

まとめ

設計レビューは、品質向上とチーム成長のための重要なプロセスです。指摘を恐れず、積極的にレビューを受けましょう。

---

今日から始める3つの行動

結論

この記事を読んだ「今」が、詳細設計スキルを身につける第一歩です。

理由

詳細設計は、上流工程エンジニアへの転職において最も重要なスキルの1つです。基本設計までできても、詳細設計ができなければ「設計者」とは呼べません。

しかし、詳細設計は実践を通じて身につくスキルです。理論を学んだら、すぐに手を動かしましょう。

具体例

ステップ1:Udemy講座で体系的に学ぶ(所要時間:2週間)

まずは詳細設計の全体像を理解しましょう。おすすめの講座:

Udemy – オブジェクト指向設計講座 クラス設計の基礎から実践まで学べます(セール時1,200円〜)

Udemy – UML設計講座 クラス図やシーケンス図の書き方を実例で学べます

ステップ2:既存のコードから詳細設計を逆引きする(所要時間:1週間)

あなたの会社の既存コードを読み、以下を抽出してみてください:

• どのようなクラスに分割されているか?
• 各クラスの責任は何か?
• どのような依存関係があるか?

これをクラス図に書き起こすことで、実践的な詳細設計の感覚が身につきます。

ステップ3:小さなアプリの詳細設計書を書いてみる(所要時間:2週間)

ToDoアプリなど、シンプルなアプリケーションの詳細設計書を実際に書いてみましょう。

設計すべき項目

• クラス構成図
• 主要クラスの仕様書(UserService, UserRepository等)
• シーケンス図(ユーザー登録処理等)
• データ構造定義(User, UserDTO等)

GitHubにポートフォリオとして公開すれば、転職活動でも強力な武器になります。

まとめ

詳細設計スキルは、上流工程エンジニアへの必須スキルです。今日から学習を始めれば、3ヶ月後には実務レベルに到達できます。

【今日から始める学習セット】

Udemy – オブジェクト指向・UML設計講座 セール時なら1,200円〜。詳細設計の基礎から実践まで体系的に学べます

Kindle Unlimited無料体験 30日間無料。通勤時間に設計の名著を読めます

Notion 詳細設計書の作成・管理に最適。無料プランでも十分使えます

---

まとめ

詳細設計習得ロードマップの全体像

第1-2週:基礎理論の学習 →オブジェクト指向の3原則、単一責任の原則、レイヤーアーキテクチャを理解

第3-4週:UMLの習得 →クラス図、シーケンス図の書き方を学び、既存コードを図に起こす練習

第5-6週:実践演習 →ToDoアプリ等の詳細設計書を実際に作成

第7-8週:レビューと改善 →作成した設計書をレビューしてもらい、改善点を反映

3ヶ月後:実務適用 →実際のプロジェクトで詳細設計を担当

最後に:45歳のあなたへ

「詳細設計なんて、若い人がやることだ」——その思い込みは、今日で捨ててください。

あなたには20年の実装経験があります。その経験こそが、「実装しやすい詳細設計」を書ける最大の武器です。若手設計者が理想論で設計している間に、あなたは実装の現場を知っているからこそ、実践的な設計ができるのです。

詳細設計スキルを身につければ、あなたは「要件定義から詳細設計まで一貫して担当できるエンジニア」として、年収650万円以上のオファーを手にできるはずです。

その第一歩を、今日、踏み出しましょう。

【最後のご案内 – 今日から始める学習セット】

Udemy講座 オブジェクト指向設計からUML、クリーンアーキテクチャまで網羅(セール時1,200円〜)

Kindle Unlimited 30日間無料体験。通勤時間が学習時間に変わります

Notion 詳細設計書の作成・管理に最適。学習ログと進捗管理も一元化

GitHub 設計ポートフォリオを公開して、転職活動の武器に

---