設計書はどれくらいの粒度で書くべき？

エンジニアとしてプログラム開発の仕事をするとき、プログラムを作り始める前に、まずはプログラムの設計書を作成します。
設計書を作成するときに、どれくらい細かく書くべきかについての私なりの考えについてです。

プログラマーのレベルや性格に合わせて書く

私の考えとしては、実際にプログラムを作るプログラマーのレベルや性格に合わせて、設計書の細かさを変えてくのが良いと思っています。

仮にプログラマーの人が技術的に優秀な人だとすれば、設計者が考えていたロジックよりも更に良いロジックでプログラムを作ってくれる可能性が高いです。そのため、プログラマーが優秀であれば、設計書は、プログラムがやるべき目的をメインで書いて、具体的なロジックはあまり書かない方が良いでしょう。

プログラマーのレベルが未熟だとしたら、設計書は細かく書いた方が良いです。ただし、どの程度細かくするかはプログラマーの性格によっても変えたほうが良いかもしれません。

例えば、プログラマーの中には、複雑なロジックを自分で1から考えるのが好きな人がいます。そういう人がプログラムを作成する場合、設計書の中にロジックが細かく書かれていると、自分でロジックを作成する機会が減ってしまうので、モチベーションが下がってしまったり、成長の機会がなくなってしまう可能性があります。

逆に、自分でロジックを考えるのが苦手なプログラマーや、サンプルをたくさん見て知識を吸収していくタイプのプログラマーに対しては、設計者が考えているロジックを設計書に書いてあげた方が良いでしょう。
ただし、あまりに細かく書きすぎると、プログラマーの考える力を育てる機会がなくなるので、どこまで書くかは加減が難しいところです。

以上が私が設計書を書くときに気を付けていることです。
ただ、ここで書いた内容は、誰がプログラムを作るのかが事前に分かっていることが前提の話です。
つまり、設計書を作る人とプログラムを作る人が同じ組織にいることが前提となっています。

プログラム開発では、1次請け、2次請け、、と、仕事を下請け会社に依頼することは多く、設計書を作る組織とプログラムを作る組織が異なることはよくあることです。
そういった環境の場合、プログラムを作るのは見ず知らずの人の可能性が高いので、プログラマーに合わせて設計書を作ることはできません。
仮にプログラマーと面識があったとしても、他の組織に所属する、プログラマーを育てるメリットはあまりないので、プログラマーにどこまで考えさせるかを考慮する必要性はないです。

プログラム開発を他の組織に依頼する場合は、リスクを軽減するという意味で、できるだけ細かく書く方が無難だと言えます。

おそらく会社的にはNGな書き方

私の設計書の書き方は、プログラマーの視点で見た場合の優先度を高く設定した書き方です。

プログラムを利用するユーザーの視点から考えれば、プログラムはバグが少ない方が良いので、そのためには設計書も細かい方が良いと考えるかもしれません。

また、その開発部門の管理者の立場の視点で考えると、プログラムをリリースした後のメンテナンスのしやすさを考慮に入れて、設計書は細かく書いた方が良いと考えるかもしれません。
特に、CMMI、PMBOK、ISOなどといった、プロジェクト管理のフレームワークを導入している組織であれば、成果物は一定の品質を保つために、設計書の粒度は統一した方が良いと考える人もいます。

なので、私の設計書の書き方は組織全体で見れば良くない書き方だと思います。あくまで私自身がプログラマー目線で考えていて、他の立場の視点は優先順位を落として考えています。

まとめ

設計書に、どんな書き方が良いか、絶対的な答えはないように思います。
誰の視点を優先するか、によって書き方が変わるので、設計書を作成するときに、全体を見て柔軟に粒度を変えて書けるようになるのがベストではないかと思います。