・設計書を統一すると不便が多い。どこかの業務・機能に合わせて設計書を作ると、他の業務・機能には合わないものとなる。同じ画面でも、入力項目が少ないものと多いものでは適切な設計書は異なる。アップロード・ダウンロードがある画面と、そうでない画面では最適な設計書は異なる。DB参照しかない画面と、DB更新もある画面では、最適な設計書は異なる。DBしか扱わない画面と、ファイルも扱う画面では最適な設計書は異なる。その業務・機能の特性や採用するアーキテクチャによって設計書のフォーマットは分けた方がよい。表紙、ヘッダー、余白、フォント等の統一であれば問題は少ない。
・採用するアーキテクチャをもとにプログラムが作成できることを確認できた上で、設計書フォーマットは考えるべき。フレームワークが吸収してくれる要素（エラー処理等）は設計の必要がない。余計な設計をすることでフレームワークとの整合性が取れなくなってしまう。またフレームワークを利用するために必要な検討要素が漏れてしまうと実装ができない。そのためフレームワーク、アーキテクチャ等を考慮・検証した上で設計書フォーマットは考える。
・開発標準は、体制、スケジュール、技術者スキルなどを考慮した上で検討しなければならない。工程、アクティビティ、タスクを定義し、その順番、依存関係、ボリュームなども定義する。またそれぞれのタスクに登場するロール、組織なども定義する。設計書はタスクの成果物であり、設計書を作ることが（本来の）タスクではない。
・設計書は順番に作成するものではなく、作成後、他の設計書の影響を受け、修正されるものである。シリアルに成果物が作成されるわけではなく、相互に補完しながら成長するものである。「〇〇設計書がないから△△設計書が作れません」という言い訳には、相互に補完することを説明する。
・設計書フォーマットはステークホルダーによって、求める観点が異なる。業務・機能によって最適な設計書フォーマットが異なる。それ以外にも、設計者にとっての最適（量が少ない）、実装者にとっても最適（プログラムに落としやすい）、レビューアにとっての最適（読みやすい）は相反するので全員が満足することは難しい。そのため設計書フォーマットを推進する人は、影響力を行使できる人がのぞましい。設計経験があるという程度では、設計書フォーマットを普及させるのは難しい。