とても大きなテーマなので、完全とは言えないと思います。
フロントエンド開発を通じて学んだ「設計」を概念だけ自分なりの解釈でまとめてました。
ご意見、ご指摘などあればコメントください。
ソフトウェア開発における「設計」
要件を明確にし、チームが迷わずシステムを実装・テスト・運用できるレベルまでシステムの構造と振る舞いを具体的にする為に、検討すること
一言でまとめると 実装の道筋を立てる
その成果物として以下のものがある
- 仕様書（設計書）
- ワイヤーフレーム
- プロトタイプ
また仕様書（設計書）を作ることによって、チーム間の共通理解を作ることも設計の重要な目的です。
仕様
製品の寸法や材質、性能、動作条件、決まりごとなど製品のあるべき姿
仕様書
ソフトウェア、機能を実現する為に必要な画面、動き、それを実現するために必要なデータ、処理フローなどをまとめたドキュメント（プラモデルの組み立て説明書、料理のレシピに近い）
大きくは以下2つの項目に分けて書く
- 何をするかを決める 仕様（What：機能仕様 / 要求仕様）
- それをどう実現するかを示す 方式（How：設計／実装方針）
ソフトウェア開発フロー
この流れはウォーターフォールでもアジャイルでも基本となる構造です。
- 要件定義（クライアントやビジネスサイドからの要求を明確にする、ここが甘いと設計できない）
- 設計（画面、データ、DBテーブル、API、など仕様を検討する、ここが甘いと製造できない）
- 製造（開発）
- テスト
- リリース
- 保守・運用
設計方法
設計の方法には「基本設計」と「詳細設計」があります。
基本設計（外部設計/機能仕様）
- 仕様の設計
- UI(画面)の設計（ユーザー視点）
- どういう情報を表示するのか？
- どういう操作をユーザーにさせるのか？
- どういう単位でまとめるか？既存ページに載せる？新規ページに切り出す？
詳細設計（内部設計/実装方式）
- プログラム設計（基本設計を実際にどうコードに落とし込むのか）
- どういうフローで行うのか、処理の流れを設計
- データベーステーブル設計
- どんなデータが必要か？
- APIの設計
- 新しく立てる？既存を改修？
- フロントで欲しいデータの構造、リクエストをBEと相談
- どのタイミングでどんなリクエストを投げるのか？
会社によって異なるところも多いと思いますが、基本設計、詳細設計を同時に行うケースも多いと思います。
設計の粒度について
設計は「どこまで細かく書くか」が悩みどころです。
→ 画面設計はFigmaで済ませるのか、APIはOpenAPIで定義するのか、DBはER図まで書くのかなど、ツールや粒度の選択も設計の一部です。
ベテランエンジニアの設計に関しての考え
先輩方から聞いてきた言葉をまとめの代わりに。
きちんと設計して、仕様書ができていないと実装できない
一番シンプルで無駄のない、かつ拡張性の高い方法を事前に計画するのが設計
いい設計できないといい実装できないし、いい拡張ができない
設計と実装はセット
どういうデータを持って、他システムとの連携含め、どういう仕組みで機能を実現するかを考えること
どこまで考慮するかを決めることも設計
不要なバグが起きない様にするにはどう組み立てればいいか考える事
XXXXにならない様にという視点を持って作る事
可読性をあげてメンテナンスしやすく、汎用性高く作る事
システムの設計＝先を考えて、柔らかく作れるか？
設計力（システムの先をかんがえる力）が上がって、考慮点が増えると 見積もりが昔より下手になったと感じるが実際は 見積もり力が設計力の向上に追従できていないだけ
最後に余談
構造という概念が存在するものに設計が必要になる。
構造とは
いくつかの要素が依存して組み立てられるもの（例：ソフトウェア、建物、文章など）
言葉としての設計の意味：
設：前もって条件などを定める
計：計画を立てる
設計＝前もって、条件を定め、計画を立てること