システム開発に用いるドキュメントに関する考察

　システム開発にはさまざまなドキュメントが必要になりますが、SIerなどが作成したドキュメントを見ると、これは本当にいるのだろうか？　とか、形式に囚われ過ぎじゃないの？　と思うことがよくあります。
　例えば提案書。PowerPointなどのアプリケーションで作成したであろうドキュメントをよく拝見しますが、メモ書きで数行あれば足りてしまうようなことを、グラフィカルで色鮮やかにお化粧している場合が多いようです。
　ドキュメントの品質を内容品質と形式品質に分けた時、多くのドキュメントは内容品質よりも形式品質の比重が高いように感じます。言い換えると、中身が薄い（あるいはまったくない！）。

　開発関係の技術ドキュメントになると、形式品質への比重がさらに高まります。過日、こんなエピソードがありました。

• 「このプロジェクトIDって、何？」。SEの回答「………」。
• 稼働中のシステムで障害を発見。この画面のこの項目はDBのどこを参照しているんだっけ？　設計図書がありながら、どこ見ればいいのか迷ったり、「解析しないと…すぐにはわかりません…」。

　意味も分からず項目があるから記入する。どこを参照してよいかわからないドキュメントや解析しないとわからないドキュメント。いや、これはドキュメントとはいえません。これらの「もの」を作成するための対価を我が社が支払っていると思うと、非常に悲しい気分になってきます。

　どうしてこのようなことになるのか？　ひとつは、開発標準に対する間違った認識と、そこから生じる開発標準の間違った運用が原因でしょう。WBSを定め、必要となるアウトプットをテンプレート化する。こうすることで作業効率は本来向上するのですが、プロジェクトやプロダクトの特性を考えず、とにかく決められたテンプレートの項目を全部埋めればいい、こんな風に思いこんでしまっているようです。
　さらに、近年の品質マネジメントやリスクマネジメントの要求事項が、ドキュメントの種類と量を増やし、形式品質を満たすことに目が奪われてしまっていると考えられます。

　いうまでもなく、ドキュメントにとって大切なことは中身です。内容品質が、そのドキュメントの価値を決めるのです。では、内容品質とは何か？　私は次のように考えます。

• ドキュメントを作成する意味は、まず、自分自身が理解するための記録をとること。
• ドキュメントの本質的価値は、未来の自分を含む読み手に情報伝達し、コミュニケーションできること。

　内容品質が満たされているのであれば、手書きだろうと、ワープロだろうと、厚化粧だろうと、何でもよいということであり、よって、形式品質を追求することにシフトできるのです。

　価値あるドキュメントとは何か？　意味のあるドキュメントとは何か？　価値や意味は誰にとって重要か？　そうしたことを十分に考えたドキュメンテーションを私は期待します。