久しぶりの大きいチーム。
今までは少人数で、アジャイルなチームだった。

次のところは大きいチームではあるが割と安定して定期的にプロジェクトをリリースしているようだ。
ガチガチに固まってんのかなーとかドキュメントどんだけ書いてるんだろうなーめんどくさそうだなーとか考えてた。

違った意味で面倒だった。

見ててこない全体像

それなりに歴史のあるシステムなのでいろいろ負債もありそうだなーと思ってドキュメントを探しにいった。
が、出てこない。
サーバ構成はおろか、サブシステムがいくつあるのかも把握できなかった。

いや、ドキュメントはある。
最近の案件のスケジュールやら体制図、詳細な仕様書なんかはたくさん出てくる。
だが一向にシステム構成や機能一覧といったドキュメントが出てこないのだ。

いろいろな人に聞きに行くことで、ようやく全体像が見えてきた。
細かいドキュメンテーションが面倒そうだと思ったら、まさかまずシステム構成を書き起こすところから始まるとは・・・

何故こんな事になっているのか。
長く続くと「ソースコードと仕様の乖離が」という話はよくあるが、そんなレベルではない。

アジャイルなドキュメンテーション

これまでのチームではどんなドキュメントだったかを振り返ってみる。
（アジャイルはドキュメントを書かない、なんて謎の誤解はもう無いと信じつつ）

これまでもドキュメントだけで全体像を把握できたとは言わないが、
ある程度の理解はできたし、後で「アレどうなってたっけ？」となった時に見に行く先のあたりを付けることはできていた。

工程で言う下流に当たる部分、これはソースコードから読み解きやすいので重視されない。
逆にソースコードから読み取れない上流に当たる部分、こちらが重視される。

また、アジャイルなチームではより横断的・自律的な動きを求められる、というのも
上流よりのドキュメントが重視される理由の一つだろう。

一方ウォーターフォールやプロジェクト型と言われる方ではどうか。
経験が浅いので正確ではないかもしれないが、考えてみた。

現工程では前工程での成果物を元に次の工程で必要なものを作るのが目的となる。
そのため、今の工程よりも下流の工程で必要なドキュメントを作ることが重視される。

極端に言えば、仮に今の工程の内容に若干の修正が入ったとしても、
下流に向けてのドキュメントが正しく書かれていれば問題ない。

これによって、下流工程を実施するメンバは上流工程をそこまで気にしなくても良くなる。

ウォーターフォールの方は、明らかにリリースまでをゴールとしたドキュメントとなっている。
ウォーターフォールプロジェクトのゴールはリリースなのだ。

困るのは、このドキュメンテーションが保守や改修時にも継承されていくこと。
一度作ったものはなかなか捨てられないもので、下流重視のドキュメンテーションは引き継がれてしまう。

最初に作る時に必要なドキュメントと、保守や改修時に必要なドキュメントっていうのは違うと思うのだが
プロジェクトを繰り返し実施するようなチームだと、そこがあまり意識されないのだろうか。

アジャイルな場合は、最初からアップデートする前提で活動を行っている。
もちろんすべてのドキュメントをアップデートしていくのは難しいため、
今作るために必要な一時的なドキュメントと、今後のためにアップデートしていくためのドキュメントは
明確に分けていたことが多かった気がする。

今までのチームでは、あまり役割が固定化されていないことが多かった。
ある程度の役割が振られていることもあるが、明確に入れ替えがあったこともある。

そのため、役割関係なくいろいろ知っておく必要がある。
システムに関して知らくても良いことなんて、ない。

ウォーターフォールなチームでは、役割が固定されがちだ。
少なくともプロジェクト中に見る範囲が大きく変わることはないだろう。

逆に見える範囲を絞ることで自分の範囲に集中しろ、ということな気もする。

なのでいきなり全体を拾う必要はないので、そういったドキュメントも必要ない。
作業をしていく上で、なんとなく全体像を理解していくのだろう。

自分を納得させようと思ってたんだけど、最近ちょっと状況が変わった。

だいぶ細かい、今でもバリバリ使ってるドキュメントもだいぶ雑だった。
作業する人の暗黙知に頼りまくっている感じ。

うーん。