増 3．設計書・仕様書考
●今回の発端
前回のコラムで、あえて「設計」、「仕様」という言葉を使わず、「正しいこと」という言葉で統一しました。それには理由がありました。
●「設計書」・「仕様書」
以下の言い方は、文書名の細かい差異を無視して、一般的に考えれば妥当だと思います。
「正しいこと」は、（第一義的に）「設計書」や「仕様書」に書く。
しかし、
「設計書」や「仕様書」に書くのは、権限が必要な（と筆者が思っている）「正しいこと」(のみ)である。
となると非常に困ります。もっと違うことも書きたいからです。
●設計書・仕様書に書きたいこと
いろいろ書きたいことがあります。
1．正しいこと
これは間違いなく書いて問題ないことだと思います。
2．否応ないこと
技術的などうしようも無い制限などで、正しいことと相違し、しかもこちらを優先しないとならなそうなことです。
たとえば、
- 依存関係が思わぬ方向にあり、思っていた様にプラガブルにできない
- 規約で、ソースがない変換モジュールをかます必要があり、思っていたソフトが使えない
といった感じのことです。
また、次項の補足すべき事よりもこちらがふさわしいのではという事項に
- コード体系が決まっているのに、そのコードの利用者の要望により、追加・変更を余儀なくされること
もあると思います。あるコードが「1、2、3」で決まっていたのに、「4」を追加してくれと言われることなどが、該当します。
筆者は前から、“データの意味は利用者の総意である”のではないかと考えていました。もちろん、「総意」という言葉は代議制を否定するものでは無く、DB管理者をdisる意図も有りませんが、かといってDB管理者というのは、わりかしコードなどは「自分としては何でもよく」、「えいや」で決めるように見えます。
そう考えると、利用者の要望というのは、技術的にはどうしようもないことと同等の重さと考えます。
これらの事は、尊重され、その線で記述を変えるべきです。
3．補足すべきこと
個別のプログラムのみで使うテーブルレイアウトやコード体系です。特に項目転送関係のごく
細かいことは、プログラムができてみないと分からないので、当然後からということになりますし、それを書く権限は、プログラムを作る当人に委嘱してもらわないととても間に合わないと思います。
前項の否応ないことと違い、こちらは正しいことと相違するものでなく、別文書（基本設計と詳細設計の様な）で共存するのだと思います。
4．聞いたこと
末端のプログラマにとっては、もっともなじみ深い事項だと思います。
要するに、正しいことなどとして文書化されていないが、個別のプログラム限りかと言うとどうかという決め事を、リーダなどに相談して得た知識のことです。
何気ない小さな決め事ですが（そうでなければリーダ止まりで判断はできないです）。プロジェクトを進めていく音頭取り上、要石となるようなことが多々あります。
しかし、この手のことは残りません。要するに、
- 聞いた末端のプログラマには設計書・仕様書を更新する権限が無い。有っても広く頒布する権限がない
- 聞かれたリーダは、即興の判断で、聞いた側は一心に墨守するつもりでも、仮置きだと認識してしまい、文書化しない
- 正しいことだと正式には認められていないことでも、組織運用的には、リーダの発言は極力通しきる傾向にある。しかしながら、それは不文律に過ぎず、なにか文書化しづらい
と言った複合的な要因により、うやむやになってしまうのです。
この場合、末端のプログラマが文書化を担当するのがもっとも忘れにくいと思います。末端のプログラマでも、文書のどこかしかるべき枠に、聞いた事を注記できるだけの権限を与えられるべきだと思います。
5．意見
あまりに“やばそうな”ことに出くわした際、注意を促す文句を付記します。大事になってから暴露されるより、ましかと思います。
たとえば「ここはMaxだから何とかなっているが、もし将来Sumとかに変えたら目も当てられないことになるだろう」といったことです（もっとも、その様な事は、プログラムのソースに注記すべきことかもしれません）。ｌ
●「正しいこと」にどう抗していくか
特に、「否応ないこと」を、正式な「正しいこと」にしていくフォーマルな根拠がないと思います。根拠がないので、表立って言えず、リーダの腹芸だよりになってしまいがちです。
しかも、残念なことに、筆者のやっている仕事の範囲では、まず100％「アジャイル」的な
進め方にしてもらえる可能性がありません。「アジャイル」的な進め方の場合、その様な点に対し、プロフェッショナル的な寛容さがあるのだと（本やインターネットで見た限りですが）認識して
います。
筆者は、「ウォーターフォールの局所的な逆流、または渦」を制度としてもらえるとよいと思います。
必要な場合、プログラマの理解や整理を「正しいこと」の中に取り入れたらいいなという趣旨です。
もちろん、そんな事ばかりやっていたら、仕事が終わらず大変ですので、1つ起動条件を加えるといいと思います。それは、「仕事のその部分が全く進まず、それが末端の人間の能力のせいでない場合」です。
現在でも、リーダの見識の1つとして当たり前の様に行われているとは思いますが、それらは、絶対に公式ルール上のものではないと思います。それを公式ルールにすると良いはずです。
しかももしかすると、こちらの方が粒度が小さいので、「アジャイル」的なプロジェクトの進め方
より、さらに俊敏な進め方になる可能性すらあると思います。（もちろん「アジャイル」が酸っぱいと主張している訳では有りません。）
まぁ、今回はこんな所です。
●コラムのコメント欄の方針
コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。
ですので、このコラムで、
・わたしは基本的にコメントに答えない
・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。