「設計書」と一言でいっても、これだけ違う

「基本設計書の作成経験あり」
「詳細設計を担当」
「設計～テストまで一貫して経験」

一見すると、どれも「設計経験がある」と判断できそうです。

たとえばWebシステムを開発するとします。

設計工程では

・システム構成図
・機能一覧
・画面一覧
・画面遷移図
・画面レイアウト
・画面項目定義書
・API仕様書
・IF仕様書
・テーブル定義書
・ER図
・CRUD図
・バッチ処理設計書
・シーケンス図
・クラス図
・エラー処理設計
・権限設計
・ログ設計
・ジョブ設計

など、さまざまなドキュメントが登場します。

しかも、これはあくまで一例です。

会社によって名称も違えば、基本設計と詳細設計の境界も違う。

同じ「画面設計書」でも

「画面の項目をExcelに記載するだけ」

というプロジェクトもあれば

「業務要件を理解したうえで、画面遷移、入力制御、権限制御、バリデーション、DBとの関係、APIとの連携まで考える」

というプロジェクトもあります。

大切なのは「何を書いたか」より、「何を考えたか」

「画面設計書を作成していました」

それは

既存画面を参考に設計書へ転記していたのか。

上位者が決めた仕様をドキュメント化していたのか。

それとも

「この業務では、誰が、いつ、何の情報を入力する必要があるのか」

から考えていたのか。

さらに

「この項目は必須なのか」
「誰に編集権限を与えるのか」
「入力値がおかしかったらどうするのか」
「登録済みデータとの整合性をどう担保するのか」
「APIが失敗した場合はどうするのか」
「ユーザーが二重送信したらどうするのか」

まで考えていたのか。

同じ1枚の画面設計書でも、そこに至るまでの思考量はまったく違います。

設計経験には「濃度」がある

たとえば、設計経験を4段階に分けて考えてみます。

Level 1｜書く

決められた内容を、決められたフォーマットに落とし込む。「この仕様を設計書に反映してください」と指示を受け、ドキュメントを更新する仕事です。

この段階では「仕様を決める」というより、決められた仕様を正確に文書化する力が中心になります。

Level 2｜読み解いて書く

既存システム、ソースコード、DB、既存設計書などを調査し、「現在どういう仕組みになっているのか」を理解したうえで設計書を作る。

単純なドキュメント作成ではなく、調査・理解・整理する力が必要になります。

Level 3｜考えて設計する

要求や要件を受け取り、「では、システムとしてどう実現するのか」を自分で考える。画面、API、DB、バッチなどの関係を整理し、正常系だけでなく異常系や例外処理まで考える。

「設計書を書く人」というより、システムの構造を考える人になってきます。

Level 4｜問いを立てる

さらに上流になると、渡された要件そのものを疑います。「そもそも、この機能は本当に必要なのか？」「なぜ、この業務フローになっているのか？」「この処理をシステム化することで、誰の何が改善されるのか？」「この要件のまま作ったら、3年後の保守はどうなるのか？」

ユーザーや業務部門と会話しながら、要求そのものを整理していく。

「どう作るか」の前に「何を作るべきか」を考える。

「基本設計3年」だけでは、本当の経験はわからない

要件を理解する。業務を理解する。制約条件を理解する。データの流れを考える。例外を考える。変更されたときの影響を考える。実装するエンジニアが迷わない状態をつくる。

そして、その思考の結果を、他のメンバーにも伝わる形に落としたものが「設計書」。

設計書を書くことと、設計することは、似ているようで少し違う。

これまで何年設計したかだけではなく、これからどこまで考える仕事をしたいか。

が大事なんですね🐈