プロジェクト特性とドキュメンティングルール

 

 

 いいこと書いてあったので一言何か言おうと思っていたのですけど、すっかり忘れていた。。。

ドキュメントって使い方次第では毒にも薬にもなるのですけど、プログラミングほどお作法や考え方がまとまっていないと常々感じております。

コーディングルールならぬドキュメンティングルールって案外重要なのですが、いろんなプロジェクトの様子を聞いたところ、なんとなくの過去踏襲って事例が多く、きちんと定めてないチームも多いんですよね。

 

プロジェクト特性とドキュメンティングルール

機能仕様書を読みやすくするためのテクニックはどれも納得いくもので、参考にすべき内容と思いますが、一点だけ補足しておきたい項目があります。

 

【2】仕様書テンプレートは作らない

　企業や組織内で、「機能仕様書に書くべき項目を定型テンプレートにまとめておきたい」という誘惑に駆られるかもしれませんが、一般論として筆者はお勧めしません。

　開発プロジェクトにはそれぞれに異なる事情があります。機能の規模やシステムのアーキテクチャもそれぞれ異なるでしょう。必然的に仕様書に記載すべき項目の種類や粒度も変わってきます。従って、その都度項目を洗い出すことが設計作業としてむしろ重要です。

（中略）

　テンプレートが可能なのは、システムの対象分野や規模を限定できる場合だけだと思います。

 

常々感じていることで、「プロジェクト特性に開発工程や成果物は準じる」ってのがあります。

 

プロジェクトが、受託か内製か、バッチかオンラインか、モノリシックアーキテクチャか分散アーキテクチャか、みたいな感じの様々な要因があるかと思いますが、それらの特性は成果物であるプログラムに影響を与えますが、同時にドキュメントにも影響を与えます。

 

受託や内製の違いはドキュメントの納品の有無の違いにより、記述レベルの注意が必要となります。

バッチかオンラインかの違いは、利用ユーザに対する外部仕様が異なりますので、仕様の考え方が異なります。

モノリシックアーキテクチャと分散アーキテクチャの違いは、システム境界と公開仕様の考え方が違います。

 

とまあ、つくろうとするものが違えば当然必要となるドキュメントも違うということなんですけど、PMOとかそういった実働部隊じゃない人に限って「会社の標準フォーマットに従ってない」とかミョーな指摘をもらうハメになるんですよね。

 

なので、プロジェクトが開始されたら、真っ先にドキュメントの標準化（テンプレ化）、ドキュメント規約を定めてしまい、「我々のチームでは今回のプロジェクトに合わせて社の標準フォーマットを参考にドキュメント規約を作成した」って宣言してしまうのが個人的には楽かな、と思います。

外部からの余計な声に惑わされずに済むだけでなく、チームのメンバーもドキュメントを書きやすくなり、「個々の考えを形式知化し、共有する」というドキュメントの目的を達成しやすいので。

 

プロジェクトをまたいでのテンプレ化は参考程度にしかならないと思いますが、プロジェクトに特化したテンプレ化はお役立ちになると思います。

 

個人的に感じるプロジェクト特性とドキュメントの関係

以下、個人的に感じたドキュメントとプロジェクト特性の関係。

 

粒度（右ほど粒度が細かくなる）

1. 保守期間（短　＜　長）
2. 契約形態（内製　＜　その他企業　＜　公共　＜　銀行・銀行関連）
3. 開発形態（社内　＜　ニアショア　＜　オフショア　）

 

量（右ほど作成するドキュメントが増える）

1. アーキテクチャ（モノリシック　＜　分散アーキテクチャ）
2. 開発特性（バッチ　＜　オンライン）

 

ただの個人的な感想なので、代表的なものだけ。

 

 

まとめ

取り留めもなく色々書きましたが、一番肝心なことは、成果物として、どのようなものを作成するかの定義は、プロジェクトを成功させるためには重要なファクトであり、マネージャの腕の見せどころでもあると思うわけです。

 

以上