設計書が読めても“書けない”──ステップアップの分岐点

こんにちは、クラウン情報テクノロジー代表の増井です。
今回は、「設計書を読めること」と「設計書を書けること」の違いについて、特にウォーターフォール型開発の現場におけるステップアップの視点からお話ししたいと思います。

---

1. 読める＝書けるではないという現実

エンジニアとしてある程度の経験を積むと、設計書を読んで理解する力は自然と身についてきます。
しかし、「設計書が書ける」となると、話はまったく別です。
読む力と書く力には大きな隔たりがある──これは多くの若手エンジニアが感じる壁でもあります。

---

2. 詳細設計と基本設計──段階ごとに高まる設計力

ウォーターフォール型開発では、設計書にもレイヤーがあります。

• 詳細設計書：画面仕様や処理ロジック、変数名、分岐の条件などを具体的に記述
• 基本設計書：要件に基づき、業務フローや機能構成、システム間連携を全体視点で整理

この２つの設計書では、求められる視点と責任の重さがまったく異なります。
基本設計が書けるようになるということは、単なる技術力だけでなく、「業務理解」や「要件整理」の能力、さらには「クライアントとの調整力」までも必要になります。

---

3. 最初に任されるのは“修正”──そこから始まる設計の道

現場では、若手がいきなり設計書をゼロから書くことはありません。
多くの場合、すでにある設計書の一部を修正することからスタートします。

しかし、そこには多くの学びがあります。
「なぜこのように書かれているのか」「修正によってどこに影響が出るのか」「この表記は社内（またはお客様）の書式ルールに沿っているか」といった、設計者としての“視点”を身につけるチャンスなのです。

---

4. “書く”には細かい配慮も必要

設計書を書く際には、単に技術的な正しさだけでなく、フォーマットの統一や視認性といった細部への配慮も重要になります。

• 章立てのルール（1.1.、1.2.などの階層構造）
• 表や図の罫線やフォントの統一
• 社内や現場特有の業務用語の使い方
• 既存ドキュメントとの文体・表記の整合性

また、最近では設計書を紙に印刷する機会は減ってきましたが、それでも「印刷される前提」でレイアウトを整える必要がある場面もあります。
例えば、余白設定や改ページ、ページ番号、ヘッダー・フッターの記載など、細かい点も疎かにはできません。

---

5. 設計が書けるようになると、見える世界が変わる

設計ができるようになると、自然と仕事の“見え方”が変わります。
コードを書くことだけでなく、仕様を整理し、人に説明し、レビューに対応し、後輩を育てる──というように、業務の幅が一気に広がります。

つまり、設計が書ける＝上流工程に挑戦するスタートラインに立てるということ。
これができるかどうかで、エンジニアとしてのキャリアの分かれ道になります。

---

まとめ

クラウン情報テクノロジーでは、エンジニアの成長を「設計力」で見ています。

• 設計書を“読める”のは、実務レベルの第一歩。
• 設計書を“書ける”ようになることが、次のキャリアへの鍵。
• 最初は“修正担当”から始まり、そこから設計の意図や書き方を学ぶ。
• 書くことには、内容だけでなく、現場ごとの書式ルールや印刷配慮などの“見えない気配り”も含まれる。
• 設計が書けるようになれば、上流工程へのステップアップも可能になる。

設計力は、現場で鍛えられる実践知です。
日々の業務の中で「ただの修正」ではなく、「自分ならどう設計するか」という目線を忘れずにいれば、必ず次のステップが見えてくるはずです。