ドキュメント設計を学ぶ意味
ビジネス（機能性）とエンジニア（保守性）両方の視点から価値の高いプロダクトを設計・開発するために、何を・どう考えるのか、「言語化されていない勘と経験」を体系化することで、再現性のある思考プロセスを習得する。
Point
- 1 から 3 では、「モデリング」を使って、機能性を高める
- 3 から 5 では、「実装パターン」を使って、保守性を高める
モデリング と 実装パターン
どのような設計スキルが身につくのか？
- 機能性 → 「モデリング」でビジネス要件を分析・調整
- そもそもの開発目的を明確にできる
- 要件定義の考慮モレに気づいてフォローできる
- 重要なビジネス知識/ルールを基本設計に反映できる
- 保守性 → 実装パターン、設計原則を使いこなす
- ビジネスとソースコードの構造が一致する
- 依存関係が少なくて、あとから追加/変更しやすい
- コードが読みやすくて、変更の影響範囲が見える
継続的なプロダクト成長を支えるビジネス並走型の設計スキルが身につく
WF開発 と アジャイル開発
確実性のあるウォーターフォール開発での設計
- 数か月から十数か月かけて、全体計画を決めてから各工程でテストを行い上から下に向かって一方向へ開発を進めていく方法。
- 実装段階の前に各設計初を作りきる。
- 追加・修正が発生した場合は、プロジェクト計画そのものの見直しが必要
メリット
- 完成像を見通してからスタートできる
- 工数管理がやりやすい
- 開発メンバーに高い自走スキルを求めない
デメリット
- 途中の追加変更が難しい
- 方針決定の負担が大きい（企画・設計書だけで全体GOの判断が必要）
- 完成まで動かない
柔軟性のあるアジャイル開発での設計
- 2～3週間の小さいリリースで仮設検証を繰り返す
- ニーズを探りながらプロダクトを成長させる方法
メリット
- 成果物ベースで判断できるので方針決定の負担が少ない
- 利用者ニーズを見つつ、後出しで追加修正できる
デメリット
- 開発メンバーの自走スキルが強く求められる
- チーム内の認識ずれ、俗人化、情報の発散が起きやすい
タスク
4ステップで求められるタスク
-
企画
価値が高いプロダクトを作るために、経営者・決済者から承認を得る
- 現状把握
- ビジョンや目指す経営上のゴール
- システムの大まかな完成像
-
要件定義
協力部署とのコミュニケーションやユーザのニーズを把握するためにモデリングの手法で、開発目的や重要なビジネス知識/運用ルールを明確化する
- ユースケース分析（コンテキスト図、ユースケース図）：各関係者の間で使われるシステムやツールと使われる目的を定義にする
- 業務フローの明確化（アクティビティ図、状態遷移図）：ユースケースの運用プロセスを設定してビジネスルールとして明確にする
- 関係性の体系化（ドメインモデル/オブジェクト図）：各フローの関係性を分析して、体系的に整理する
-
基本設計
モデリング内容を実装パターン（画面設計・機能設計・データ設計）に落とし込んで、ビジネス側との共通認識を作る
- 画面設計：ユースケース図、ドメインモデルを基にどのような画面が必要で表示すべき情報を明示する
- 機能設計：ユースケース図と画面設計を紐づけて、裏側で必要な処理を一覧化する
- データ設計（ER図、データフロー図）：DBのデータ構造といつどこでデータが発生するのか明確にする
-
詳細設計
プロダクトの保守性を高めるために、実装パターンを使って読みやすく、プログラマーに実装方法を伝える
- ロバストネス分析：責務を細分化して適切なクラスを割り当てる
- シーケンス図：クラスのメソッドを決める
- クラス図：クラスの依存関係を整理する