本当は楽しいドキュメント作成：システム開発プロジェクトの現場から（23）（2/2 ページ）

規約・標準文書を作ろう

　もう1つ、認識共有の文書として作成するものが、規約・標準に関する文書です。

　規約・標準と聞いてITエンジニアが真っ先に思い浮かべるのは、コーディング規約ではないでしょうか。ほかにも、セキュリティ規約、議事録作成規約、文書情報管理規約などさまざまな規約があります。これらの文書作りも開発プロジェクトのあるべき形を定義するものとして重要であり、作成優先度は非常に高いと考えています。

　数ある規約・標準文書の中で、私が1人の開発者として最も作成に慎重になり、かつ最も作成の醍醐味を感じるのが、以下の3つです。

• データベースアクセス標準
• ログ出力規約
• 例外処理標準

　なぜそのように考えるかの理由を挙げます。

• 開発者の癖を封じるため

　どれだけ優れた開発者であっても、その人固有の癖というものが存在します。その人がプログラム言語を習得する際に使用した教材、その時期に流行していた実装方式、得意なデータベース製品。これらの要素により、プログラミングの作業には開発者固有の癖というものがどうしても出てしまいます。

　プログラム言語の技術進歩は早く、さまざまな実装方式が絶えず生まれ続けています。そのため、プログラム言語を習得した時期が、開発者の実装スタイルに大きな影響を及ぼしてしまうのです。

　データベースの実装に関しては、上記のように開発者固有の癖が出やすいということに加え、システム全体の性能に強い影響を与える部分であり、障害発生時のインパクトも大きいものです。よって、データベースアクセス標準の整備が非常に重要であると考えます。

　なお、ユーザーインターフェイスの実装も上記と似たような傾向にあるため、余力があればユーザーインターフェイスの実装標準の作成も推奨します。

• 保守効率を向上させるため

　例外処理やログ出力の実装は、開発者の勘や経験が大きく影響する部分です。さまざまな経験をした開発者だからこそ、きめ細かい対策を事前に行えるのです。具体的には実装上起こり得る問題点を事前に予測して例外処理を実装すること、デバッグをする際に問題の原因を突き止めやすいログ情報の出力をすることなどです。

　経験値の高い開発者が行った例外処理やログ出力の実装と、そうでないものを比べると、システムの保守性の点で大きな差が出ます。経験値の低い開発者は、まず目の前の仕様を実装することに集中しますが、経験値の高い開発者は、仕様そのものの実装に加えて、テストやデバッグ、さらには本番稼働時の保守までを意識したプログラムを書くことができます。

　経験値の低い開発者の成果を経験値の高い開発者のものと同等に引き上げるため、例外処理の標準とログ出力の標準を作成すべきであると考えます。

　今回は、計画書、規約・標準文書に注目し、私が普段作成しているものの一部を紹介しました。次回以降は、基本設計文書編、データベース設計成果物編、プログラム詳細設計書編、テスト成果物編に分けて、システム開発プロジェクトで作成されるべき文書が作成されなかった際のトラブルや、作成の際に気を付けるべき点に触れたいと思います。