仕様書に本来求められるものとそれを作るツールにはまだギャップが大きいという話
また、とんでも系のツールの話かそれとも奇跡でも起きたのかと思って読んでみたら…べつにそれwikiでドキュメント作ればいいじゃん、みたいな。確かに、出だしのページなんかは同意すんるんだけどねぇ。
仕様書に求められる機能
仕様書というアウトプットの形態になるまでには、幾つかの形態をたどるんですよね。第一形態は、仕様検討としてのドキュメント。要件定義のセッション資料であったり、方式検討での比較検討資料であったり。第二形態は、それをアウトプット二するまでの補助資料的な中間生産物としてのドキュメント。そして契約書に記載されている成果物名の記載がされている最終のアウトプット。
上流工程での第一形態はプロジェクタなどで映しやすさからPowerPointが使われるし中間生産物はExcelやwordが使われるし。下流工程というか焼酎でもデータ設計やUI設計なども含まれるけど、開発支援ツールに置き換わったりしているけれど、Excelやwordだって健在だし。
成果物の形式指定がないのであれば、そこはだいぶデリバリサイドがプロジェクト開始時の成果物の作成フォーマットを指定することで開発者がフォーマット変換する手間と重要なのはフォーマット変換することで生じる転記ミスを防止するために極力少ないツールに集約することが必要なんですよねぇ。
ただ、ついつい開発チームはドキュメントの作成だけの都合でツールを選ぶから、ドキュメントのライフサイクルを考えると運用まで考量されない、ということが多々あるんだけど。
少なくともシステムがサンセットするまでは作成したツールでメンテできないとダメなんですよねぇ。例えば構成図を作成するのにvisioがいいという人もいるけれど、それ、お前が好きなだけで、維持管理する人は新たにライセンス購入したり覚えないといけないコスト発生するんだぞ、とか「全く考えていないだろう！』って言いたくなりますよ。
第一形態から第三形態になるまでに様々なツールを使って最終的には普通のドキュメントができるわけです。はい。結局、システムの今の姿を表しているドキュメントが仕様書の機能なわけです。
仕様書の構成要素
その仕様書を構成する要素ですが、
- 文字
- 図
- 表
です。これで構成されます。ドキュメントなので。電子媒体でブラウザやビューアを使うなら動画や3Dモデルもあるんでしょうけど。
なので、これらを作成できるツールでないといけないわけです。
仕様書に本来求められるもの
仕様書のドキュメントの作成って、実は、そうした構成要素を編集しているんですよ。組版しているんです。だって、文字と図と表を画面に割り当てているんですから。
それを紙でも画面でも収まるようにしようとするから体裁が必要になるわけです。もうですね、巨大なシステム開発なんて、実は出版会社のようなものです。各システム単位がブランドの違う本を作っているようなものです。
で、それはそれで人が読むので必要な作業なのでしょうが、本来、
「仕様書に求められるものって何？」
って思ったことないですか。なければ、「じゃ、あなに？」ってお尋ねするわけですが。
システムというかプログラムをつくるための中間生産物でしかないんですよね。なら最初からプログラム作ればいいじゃん、となるんだけど、規模が大きいと作り手を労働集約して生産性を高めたいのでバラバラに作らないように標準化するとか出てくるし、その前に、作りたいものが発注者側自身が発注時に固まっていないからこそ要件定義や基本設計という名の「システム要件定義」をやったりしているんですよね。
そうしたことの工程をいくつも経てプログラムになるわけで。
結局、仕様書に本来求められるものはプログラムの仕様を記述することなんですよねぇ。それを様々なツールを使っている時点でアレなわけです。理想なのは、文字や図表をあるツールで表現したらプログラムに変換されることなんですよねえ。そうしないと機械側でトーレスできないじゃないですか。
元記事の３ページ目だったかな、markdownで書いて、CIしてデプロイするなんて何も変わっていないんですよ。だって、図表描きたいように書けないでしょ。いろいろ素材を作ってからmarkdownで書くんだから。
そこまでいかないと新しい時代が来た、みたいなタイトルはつけられないなぁ。そんな時代が来るのかなぁ。来て欲しいけど。
