設計も担当する場合

この役割の特徴

• 詳細設計書の作成に関わる：自分で設計を考え、ドキュメント化する仕事が加わる
• 設計内容を理解して実装する：自分で書いた設計に基づいて、すぐに実装に移る
• 設計レビューに参加する：先輩エンジニアから設計の品質について指摘を受ける機会がある

よくある1日の流れ

毎日の活動パターンを図で見てみましょう。

flowchart LR
    A[9:00
朝会] --> B[9:30
設計作業]
    B --> C[12:00
昼休み]
    C --> D[13:00
設計レビュー]
    D --> E[14:00
設計修正]
    E --> F[16:00
実装作業]
    F --> G[18:00
退勤]

朝は設計の進捗確認、午前中に設計書を作成、午後に設計レビューを受けて修正し、その後実装に移るという流れです。以下はより詳しいタイムスケジュール例です。

最初の1ヶ月で覚えること

第1週：設計書の読み方を学ぶ

最初の1週間は、既存の設計書を読み込み、プロジェクトのフォーマットやUML記法に慣れることが目標です。

第2週：簡単な設計を書いてみる

環境に慣れたら、簡単な設計から書き始めます。最初は先輩の指導を受けながら進めます。

第3〜4週：設計と実装をつなげる

簡単な設計が書けるようになったら、その設計に基づいて自分で実装し、設計と実装のつながりを理解します。

1ヶ月後の目標状態

1ヶ月を通じて、設計と実装の両面での基礎を身につけることを目指します。

flowchart TB
    A[1ヶ月後の目標] --> B[既存の設計書を読んで理解できる]
    A --> C[簡単な設計書を作成できる]
    A --> D[設計レビューで指摘を受けて改善できる]
    A --> E[設計と実装のつながりを意識できる]

設計で意識すること

実装者の視点で書く

設計書で最も大切なことは「実装者が迷わないこと」です。その視点で設計書を評価しましょう。

flowchart TB
    A[設計書を書く] --> B{実装者が読んで}
    B -->|迷わない| C[良い設計書]
    B -->|迷う・質問が出る| D[改善が必要]

良い設計書のポイント

• 入出力が明確
• 処理の条件分岐が網羅されている
• 例外ケースの扱いが書かれている
• 関連する他の機能との関係が分かる

設計書チェックリスト

設計書を書いたら、以下を確認しましょう。

• 機能の目的・概要が書かれているか
• 入力データと出力データが明確か
• 正常系の処理フローが書かれているか
• 異常系（エラー時）の処理が書かれているか
• 他機能との関連が分かるか
• 実装者が迷うポイントはないか

この経験で身につくスキル

技術スキル

ビジネススキル

目指せる人材像

設計も担当する経験を通じて、将来のキャリアパスがいくつか見えてきます。

flowchart TB
    A[設計担当からのキャリア] --> B[SE/システムエンジニア]
    A --> C[アーキテクト]
    A --> D[テックリード]
    A --> E[プロジェクトリーダー]

    B --> B1[要件定義から設計まで担当]
    C --> C1[システム全体の構成を設計]
    D --> D1[技術的な意思決定を主導]
    E --> E1[プロジェクト管理も担当]

各キャリアパスの目安期間と説明です。

成長を感じられるポイント

あなたが成長しているかは、以下のチェックリストで自己評価できます。各時期で「できるようになったこと」を意識することで、モチベーションにつながります。

3ヶ月後

• 設計書のフォーマットに慣れる
• レビュー指摘が「分かりやすくなった」と言われる
• 実装者から「設計書通りに実装できた」と言われる

6ヶ月後

• 機能単位で設計を任せてもらえる
• 「なぜこの設計にしたか」を説明できる
• 他の人の設計をレビューできる

1年後

• 複数機能をまたぐ設計ができる
• 設計の選択肢を複数提示できる
• 後輩に設計のアドバイスができる

本編で特に重要な章

このカリキュラムの他の章のなかで、設計担当として特に参考になるものを挙げます。

追加で学ぶと良いこと

優先度：高

優先度：中

よくある悩みと対処法

設計担当として働く中で、多くの新人が同じような悩みにぶつかります。各悩みに対する対処法を、アコーディオンで確認できます。

成長のためのアドバイス

実装者の視点を持つ

設計者として最も大切なのは、実装する側の視点を持つことです。

• 「この設計で実装できるか」を考える：書いた設計を読み直し、実装者になった気持ちで「本当に迷わないか」を検証する
• 自分で実装してみて確認：自分が書いた設計に基づいて実装してみることで、設計の過不足が見える
• 実装者からのフィードバックを活かす：「ここが曖昧だった」という指摘を、今後の設計に反映させる

既存の設計を学ぶ

優れた設計書を読むことで、設計の引き出しが増えます。

• プロジェクトの既存設計書を読む：実際に動いているシステムの設計書を研究する
• なぜその設計になっているか考える：「なぜこの構造なのか」「なぜこの方式なのか」を理解しようとする
• 良いパターンを吸収する：「こういう場面ではこの設計パターンを使う」という知識を蓄積する

設計の引き出しを増やす

仕事として与えられた設計だけでなく、様々な知識を取り入れることが長期的な成長につながります。

• デザインパターンを学ぶ：「Observerパターン」「Adapterパターン」など、よく使うパターンを体系的に学ぶ
• 他のシステムの設計を参考にする：オープンソースプロジェクト等の設計を読む。業界標準のパターンに触れる
• 「こういう場合はこうする」を蓄積：経験を通じて「並行処理はこう設計する」「大量データはこう処理する」という選択肢を増やす