重要だけど軽視されるタスク
プロジェクトにおける ドキュメント作成というタスクの位置付けについて。
たいていは、忙しいという理由で、ドキュメント作成は後回しになります。
後回しでも最終的に着手されるならいいんですが、着手されないまま、プロジェクトがのびのびになって忘れられるとか、そうこうするうちに新しいプロジェクトが始まる、なんてことは、実はよくある話です。
でもこれ、数年単位で考えると、自社（あるいはチーム）の首を締めることになります。
既存の設計資産などに関する適切なドキュメントがないと、
・知見が属人化してしまう
・新人の立ち上げに非常に時間がかかる
・分かる人は、毎回聞かれるの精神衛生上よくない
といったことが起こります。
ドキュメント化で品質向上の相乗効果？
ソースコードがあっても、それだけでは意図がよくわからないことも結構あります。もちろんそれはソースコードの可読性がよくないということがありますが。
勝手な印象ですが、
ドキュメント化がしっかりなされていないプロジェクトは、ソースコード自体も可読性が悪い
という気がしています。
ドキュメントがしっかりしているプロジェクトは、ソースコード単体でも可読性が高くて、ドキュメントとソースコードが合わさることで、第三者がとても理解しやすくなっているように思えます。ちなみに、ドキュメントを書くとき、どういう候補を検討したうえでそれを選択したのか、どういう問題があったのかといった、そのときの設計に関する思考の流れみたいなのが書かれていると、あとで見る人にとってはとても助けになるものです。
誰のためにドキュメントを書くのか？
誰のために書くかを考えてみると、
・チーム/組織への知見共有のため
・引き継ぎを想定
・将来の自分のため（半年後は自分でもわからなくなってる可能性がある）
といったところでしょうか。
マネジメントからみたドキュメントと、あるべき姿
いま目の前のプロジェクト完遂という視点でみると、ドキュメント化は
余計なタスク
に見えます。現プロジェクトにおいて、「きっちりドキュメント作りました」は評価対象にならず、きちんと動くものを作るというのが当然の目標になります。
でも、会社（組織）を中長期的にみたときには、
・ドキュメント作成タスクはプロジェクトに必ず含まれるもの
・ドキュメントがないものは過去の資産とみなさない
というくらいの強い意識が必要でしょう。
ドキュメント作成が中長期で効いてくる
結局のところ、ドキュメントがしっかりしているプロダクト/サービスは、その中身も良いような気がします。ドキュメントに気が回る余裕があるということで、色んな点に配慮が行き渡っているように感じるのです。
派生品の開発がある場合でも、きちんとドキュメントがあれば、着手しやすくなります。
ドキュメントがないと、二度手間なことも増えますし、結局、過去の担当者を駆り出さなくてはいけなくなることもありますし、そもそもその人がもう在籍してなくて、詳しく分かる人がいないということもあり得ます。で、誰も分からないんなら、過去の資産はすててスクラッチからやるか、ということにもなりかねません。
ドキュメント化のメリットは中長期で活きてきます。
自身の存在価値を高めるために、自分だけが知っている知見はできるだけドキュメント化しないで属人化しておく、という戦略も個人レベルではもしかしたらあるのかもしれませんが、そういうのもなんだかちょっと時代遅れというか、カッコ悪く感じますね。
