さて。ITの開発現場では「単独・単品」で作られ存在する仕様書が珍しくない、と思う。
関数仕様だけ、画面仕様だけ、シーケンス図だけ、みたいな。
確かに手分けして量産するにはこれがラクなのだけど、
本来それらは統合されて、大きなドキュメントの体裁になるものだ、と思う。
そして、その構成があって、流れがあってこそ、
システムとしての大きな「しくみ」や「成り立ち」が理解できるものになる、と思う。
単独・単品で用をなしている、十分、ってときも、もちろんあるとは思うけど。
大きなシステムの「一部のパーツ」をつくるだけ、みたいな仕事もあるとは思うけど。
単独な仕様書では、目的や用途がなおざりになることも。
なぜここ（この機能）はこうしているか、何のためにこうしたか、のような
背景や理由が説明されないまま*1「ここをこうした」という
思考の「結果・結論」だけが記述される。
そして、さらには、書き方や書く事柄だけが抽出され、「作業化」されてしまうので
「クラス図かいときゃいいや」みたいなことになる。いわゆる「手段が目的化」なのである。
だから前後関係がなく「単品」の「羅列」になりやすい。
ストーリーがないため、結果、意味が伝わらない。
そう、「構成はストーリー」なのだ。
初めに大きな事柄が書いてあり、
その中の要素を、ひとつひとつ順に解説していく。
オーバービューがあってこその要素、なのである。
全体の構成やある程度行く先が見えている上で、その見えているものに対して、
ひとつひとつ、順を追って、情報が補足され、詳細化されるから
わかっていくのだ。
そして、項目は大項目から小項目にブレークダウンされる。
それを書き表そうとすると、おのずと章立ては階層化され構造化されていく、はずだ。
何度か抽象化のことを書いているが、
設計って、抽象度の粗い／細かいをいったりきたりしながら
「俯瞰する視点」を変えてながら、ものごとを考えてまとめていく行為だと思う。
だから、仕様書にも、その観点が入っていてほしい、と思う。
大きな視点と小さな視点があるから、章立ては階層化される。
そう、「章立ての階層」は「抽象度のレベル」なのだ。
そういった構成の目を持つためにも、
技術書や論文のような「お堅い」文章にふれているほうがいいと思う。
そうすることで、技術的な書きもののルールや、お決まりの言い回し等を
知ることができると思う。
わかりにくい仕様書は、だいたい長い文章になっていることが多い。
また、ブツ切りで前後関係をあまり考えていない構成のものが多いと思う。
seichi23.hatenablog.com
seichi23.hatenablog.com
seichi23.hatenablog.com
seichi23.hatenablog.com
*1:備考欄でカバーとか、くふうはあるけど。
