こんにちは、阿久梨絵です！
「他社の 設計書 、何が書いてあるのか全然わからない…」
「このフォーマット、どこに何があるの？」
そんな経験、IT業界で働く人なら一度はあるのではないでしょうか。
この記事では、なぜIT企業間で設計書のフォーマットが統一されていないのか？
そして「読めない＝スキル不足」なのか、それとも「前提知識の違い」なのかを掘り下げていきます。
なぜ設計書のフォーマットはバラバラなのか？
1. 企業文化・開発スタイルの違い
・SIer系企業では「詳細設計書」「テスト仕様書」などを厳密なテンプレートで作成する文化が根強い
・一方、Web系企業ではFigmaやNotion、Markdownベースで柔軟に設計を共有するケースが多い
2. プロジェクトの規模や性質による差
・基幹系システムや官公庁案件では、ドキュメントの網羅性と形式が重視される
・スタートアップやアジャイル開発では、スピードと柔軟性が優先され、設計書も“必要最小限”に
3. 「設計書＝社内向け」の前提
・多くの設計書は社内の開発者やテスター向けに書かれており、他社の人が読むことを想定していない
・そのため、用語・略語・背景知識が共有されている前提で書かれていることが多い
他社の設計書が“読めない”のはスキル不足？
必ずしもそうではありません。
むしろ「その会社の文脈を知らないと読めない」というケースがほとんどです。
例：設計書に出てくる略語やコード名
・「UCM」「BPR」「F01」など、社内でしか通じない略語や命名規則が多用されている
・仕様の背景や業務フローが共有されていないと、設計書だけでは理解できない
スキルよりも“前提知識”の壁
・設計書は「何をどう作るか」だけでなく、「なぜそうするのか」が書かれていないことも多い
・その“なぜ”を知らないと、設計の意図や判断基準が読み取れない
解決のヒント：設計書を“読める”ものにするには？
1. 前提知識を明文化する
・設計書の冒頭に「用語集」「背景」「業務フローの概要」などを添えるだけで、他者の理解度が大きく変わる
2. 設計書の“目的”を明確にする
・「誰が」「何のために」読むのかを意識して、読む人に合わせた粒度と構成にする
3. 共通テンプレートや記述ルールを整備する
・社内での統一はもちろん、外部と連携するプロジェクトでは共通フォーマットを事前に合意しておくとスムーズ
まとめ
設計書 が読めないのは、スキルの問題ではなく、前提が共有されていないことが原因であることが多いです。
だからこそ、設計書は「書くこと」よりも「伝わること」を意識して作るべき。
他社との連携が増える今こそ、“読める設計書”の文化を育てていきたいですね。
阿久梨絵でした！
