開発文書管理の憂鬱

ドキュメント隊長に任命？されて早一ヶ月近くが過ぎようとしている。

プロジェクトの今回のマイルストーンの中のミッションの一つに開発ドキュメントの品質向上が掲げられていて、そのお題目を同実現するかの旗振りをする役目をおおせつかっているのだが、どうもうまくいかない。

例えばプロジェクトの品質管理が流行のISO 9001(？)に準拠して運用されているのであれば、そのプロジェクトの定める品質マニュアルで規定される文書をプロジェクト必須文書として管理し、それ以外は参考文書としてある程度自由に任せるなど管理方針が立つものだが、そういうポリシーがプロジェクト内で採用されていないので、どうしたもんだか悩んでしまう。
#以前いたプロジェクトではISO 9001のせいで、見かけだけの本質的には意味のない文書を大量生産するという不毛な作業を経験しただけに、縛りだけあるのもどうかとは思うのだが…。

チーム内の意見を聞いてみたところ、関心は品質云々というよりは、自分が開発で必要とする技術トピック(情報)をいかに効率よく集められるかという点に集まっているようであった。それこそ情報収集の観点のみで言えば、Googleに代表されるようなキーワード検索によるフィルターを通じて、必要な文書を見つければいいと思うのだが、文書の品質を管理していく上ではある程度の構成管理を行う必要があって、その兼ね合いが難しい。

基本的に開発者はコードを書くのは好きだが、文書となると途端にモチベーションが下がる人たちが多い。文書を書くことは基本的にやったことを焼きなおす作業(しかも不得意な言語を使って翻訳し直す作業)の色彩が濃く、いまいち創造的ではないからかもしれない。
#ロジカルな人ほど作業の重複を嫌がる傾向にある。

このような性質の文書を拡充し品質を上げていこうとするには相当なエネルギーが必要となる。好きな作業は黙っていてもやるとおもうが、嫌な作業に対してモチベーションを上げるには「ご褒美」が必要。しかし手持ち無しといった状態にある。
もともと整理整頓が苦手な性質であるのに、このような宿題が手元に残っているとそれだけで、憂鬱な気分になる。

どうしたものかな…。