さて今回はテンプレートの功罪の３回目です。
前回までは、テンプレートのメリット、デメリットを考えて正しく利用しないと困った問題がおきかねないという指摘をしました。皆さんはいかがお考えでしょうか。
では、テンプレート化したほうがいいものとそうでないものをどう見分けるか？について少し考えて行きたいと思います。解りやすいのは、書き手が誰か？を考えることです。そしてどういうシチュエーションで何を期待されているドキュメントかがはっきりすると、自ずと明確になります。
縦軸に書き手＜PM－PL－メンバー－その他＞で、横軸にルーティンワーク～非提携業務とすると、各ドキュメントが何処に位置するかですね。例えば、メンバーからPLに対する進捗報告書（ルーティン／メンバー）は左下の象限に、同じ進捗報告でもPMからオーナーに対する報告書は（ルーティン／PM）で左上の象限に、という具合です。
で、象限的には①左下、②左上、③右下、④右上 とあり、テンプレート化が有利な度合いは番号順となります。このとき、例に示したPMからオーナーへの進捗報告書は、決まったフォーマットで決まった基準を持って、進捗を表現するがPMがサマリーとして全体の状況を正しく報告しないといけない。ということになります。サマリーということは、サマライズのための意思がそこに入ります。つまり、PMが何を伝えたいのかをそのサマリーに盛り込むことになります。一定のフォームで、一定の基準が必要ですが、状況を的確に表現しないといけないわけです。ドキュメントに込める意思の量で決まるということだと思います。かえって分かりにくくなりましたか？
もちろん、プロジェクトの特性やPMの考え方でドキュメントが位置する象限が変わるかもしれません。プロジェクト開始時によく考えることが必要です。
テンプレート化に馴染むドキュメントであっても、必ず自由に記述できる項目を一つは儲けるというのもいい手です。また、テンプレートといいながら、大きな記述項目だけを配置して自由記述を多く取るという場合もあるかもしれません。先程のどの象限に属しているかから、いろいろなバリエーションが考えられると思います。
と、ここまで書いて気づいたことが。同じ立場の書き手であっても、その経験やスキルによってテンプレートの内容が異なってくる場合があるかもしれませんね。新人プログラマーとベテランとでは、記述の正確さや、表現力に違いがあるかもしれません。そうすると、新人に対してはより細かく指示されたテンプレートが必要になります。
かように、テンプレートといっても考慮すべき点は多く、使い方を間違うとかえって生産性を落とすことにもなりかねません。でも、うまく使うと確かに便利です。PMには落とし穴に気をつけて運用する気構えが問われますね。
次回からは、目的と目標とは何か？について考えて行きたいと思います。