今回は、ドキュメント標準化ってどこまで効果あるのか？というニッチな生産技術ネタです。

　以下に書きましたが、


　ドキュメントのWBS（ワークフロー）みたいなモノのテーラリングは、プロジェクトによって結構、カスタマイズの余地はあるかと思いますが、

　ドキュメント・フォーマットについては、標準を弄る余地は、あまり無いかと思います（逆にプロジェクト毎に、ケース・バイ・ケースでテーラリングしていく事はある）。

　知り得る範囲のドキュメント・フォーマットに関するテーラリングは、UIの「権限・状態制御」の設計をどう書くか程度でしょうか？コレに関しては、以下の、ページの「権限・状態制御テーブル」が参考になると思います。


　また、以下に書いた諸事情（環境の変化）で、ドキュメントのWBS（ワークフロー）自体を、イベント仕様書で止めるケースが多く、そうすると、設計書の項目自体も、あまり、重要では無くなってきます。


　ただし、情報システムの複雑性は増しており、逆に、「方式設計書」、「実装レベルの標準化」などの非機能要件に関する情報は、ぶ厚くなっている傾向があると思います。


　コレら非機能要件（システム・サイド）を、機能要件（業務サイド）の要となる「画面・帳票定義書」、「イベント定義書」とガッチャンコすることで、大規模プロジェクトのアプリケーションの実装フェーズが立ち上がります。

　また、小規模のアプリケーションをアジャイル的なシステム開発ライフサイクルで開発する場合は、また、別の方法論が採用されると思います。


　優先順位的には、その後（ドキュメント標準の策定後）、以下の様な、プロジェクトで利用する「開発環境、ツール、ライブラリ」を検討されると良いかと思います。

---

　...この情報は、「誰向けの、ドウ言った目的の情報か？」と言う話ですが、端的に言って、生産技術界隈の「ポートフォリオ・プログラム・マネジメント」のための情報。ということでしょうか？

　...と言うのも、効果の無い施策の二番煎じ、三番煎じを数十年に渡って繰り返しているケースが散見されるため。

　適切な「ポートフォリオ・プログラム・マネジメント」を行うには、これらの判断に必要となる「組織のプロセス資産（OPA）」が重要になるかと思いますが、このようなリポジトリは、現時点の企業の中には、なかなか、存在しないようです（故に、二番煎じ、三番煎じが発生するのも "必然" と言う事でしょうか？）。

　また、何か目に付く施策（プロジェクト）があったら、「組織のプロセス資産（OPA）」的に、某弊部会ブログに覚書をして行きたいと思います。