軽く見がちなドキュメントの工数

これまでのシステム開発のプロジェクトでエンジニアのメンバと会話していると、何を作ればいいかを聞かれるケースがある。聞かれないエンジニアは、指示されるのを待っていたりする。何すればいいかと会話をしてくるのは、自分から仕事を把握しておかないと仕事のボリュームを把握できないとか、五月雨な仕事になって自分で仕事のペースを組み立てられないど、経験からそうしているのかもしれない。

プロジェクトの特性でシステム開発手法を選ぶ。それが契約として提案されている場合やRFPで指定されている場合もあった。そうしたスケジュール概要に紐づけて成果物やアウトプットを区切りの（指定されているか、こちらの都合で）設定する場合がある。

そのような場合は、マイルストーンを決め、そこまでにアウトプットするスケジュールを組み、メンバと共有してきた。

こうしたアウトプットは、作らなければならない＝契約上義務のあるもの以外は作業としてする必要がない。

ただそれは、アウトプットのタイトルとして名前がつけられていればよく、ほとんどのケースでは中身まで指定されていない。

ここに、納入しなければならないものと、作らなければならないものと、あったほうがいいものは作りたいという問題が出てくる。

本来、見積もり時点で、何を（タイトルとして）納入するのか、中身のサンプルはどれか、どのくらいのボリュームを作るのか、前提を置いて見積もる必要がある。ところが見積もりでは、コードは気にするが作るドキュメントは全くもってケアされない。

この仕様を残すことに対するコストの振れ幅のインパクトを理解しているプロマネやリーダのエンジニアなら、プロジェクトが立ち上がるときにスケジュールのマイルストーンやフェーズで仕様をどのレベルまでブレークダウンするか、そのときどの手法で仕様を残すかを先に提示してしまう。で、それ以上はない、として合意する。

そうすることで、それ以外の仕様に関するドキュメントはチーム内のものになる。

どう残すかは、チームメンバの出入りがあるかないかで変わる。アジャイルのチームのように、変更しないことを念頭におくなら最小限で良いし、フェーズで労働集約的にエンジニアの数を変更するなら、意思決定の経緯をあとで調べられるように、少なくともチケットシステムにいれておきたい。

そんなことは知っていると言われるだろうが、作業をする前に、予め決めて、チームに浸透するまで落とし込むことをしているプロジェクトはそうそうない。人が入れ替わったり、掛け持ちで情報が散逸し、自ら手戻りを発生させているようなチームが多いのではないか。

最初に何でもかんでも揃えるのは大変だからと言い訳したくなるが、それをしたら、将来につけを自分で山積みするようなものであるから避けたい。