詳細なドキュメントを維持できないから、しなくて良い方法を考える。

前置き

ここで言うドキュメントとは、システム仕様書や、技術使用書のこと。そして、ドキュメント書くのを怠けたい。

オレオレ頭の中、序盤

ドキュメントの内容が、必ず正しいようにすることがドキュメントの管理だ。実際の動きと全く違うようになった瞬間に、その書類は「１００害あって一理ぐらいはあるかな？」になってしまう。だってさ、信用できなくなるでしょ。

過去に、詳細に書類を書くようにTRYしてみたが、２週間も続かなかった。理由は、簡単。お客さんが必要なのは、書類じゃなくて、動いてるシステムだから。書類ばっかり書いてたら、システムを作れないんだよ！！！次の原因は、要求の不具合や、時間軸による要求の変化などの仕様変更が開発途中に入ってくるのは、デフォルトなので、書いたのが無駄になるんだよ！

オレオレ頭の中、横道

糞！ドキュメントなんていらん。大体なんでいるんだよ。オレ天才だから多分いらない。面倒だし。ああ、でも関数の使い方、ソース見るなんて泣けるなぁ。仕様をいちいち説明するのも邪魔臭いなぁ。やっぱ、いるかなぁ。だいたい、ドキュメント書け！って他のメンバーに言えるかよ。コーディングだけで一杯いっぱいなのにさぁ。

オレオレ頭の中、発見

ドキュメントには、３つの役割があるのがわかったぜ。

愛する上司がや、会社のルールで決まってるから、入らなくても作る必要があるんだよ。
情報を共有するため
忘れっぽい人間の脳みその仕様のため。

1

よし。まずは、１はクリーアだ。昔は、うるさいのがいたが、今は放置プレイ中だ。というか、プロジェクトのリーダだからな。おれが、１の立場だな。よし。クリア確定。

2

常に、3-5人規模での開発だからさ、分業は入らないとオレ思うんだ。仕様を書く人とか、コーディングする人とか、そんなのいらね。まぁ、仕様をまとめるのが得意な人、コーディングが得意な人がいるのは、もちろん必要さ。でも、分業はいらね。そうすればさ、基本的にみんなが関わるから、情報をドキュメントじゃなくて、チームの中で共有できると思うんだよね。例え、３人いて、一人やめても、二人が大体の情報もってるから、問題ないしさ。新人いれて、二人で教えて、同じレベルまで持ってくれば良いだけじゃん。

うーん。だけど放置プレイは良くないよなぁ。そうだ、朝礼と、夕礼をして、今日の作業とか、今日の問題とかを共有すればいいな。あぁ、後メーリングも作って、お客さんとか、すべてのやり取りはそこで全員が確認できるようにしよう。話す手間も減るしさ。ある意味、俺たちニュータイプだな。などの、見える化的なことが必要だな。

3

そうそう、人は馬鹿だからすぐ忘れるんだよ。「ああ、このフィールド入力制限何文字だったかなぁ。」おいおい、みんな別々にスクラッチからコーディングして、直接コードに指定してるよ。コードから、おえんーというか、どれが正解かわからねーよ。仕様書があれば、世界平和が訪れる！！大発見だ！

ってなるわけない。邪魔臭い。ていうか、このコード書いたやつ、埋めたい。
お！そうか、全員が同じようなコードをかいて、変数とかを共有できれば解決じゃん。何とかならない、ドラえもーん！

「コーディング規約〜」「フレームワーク〜」（ドラえもん風にお願いします。）

わーい。これで、３も結構クリアーじゃね？ちょっと、ソース見れば、すぐわかるからさ。

オレオレ頭の中、振り返り

これで、ドキュメント0だぜ。完璧。いや、待てよ、じゃぁ、あのかわいい、ドキュメン子さんが、いなくて過ごせるってことか？
いや、無理だろ。あの子がいる理由もあるはずだよ。ていうか、CPANでPODがなくて、ソースだけだと死亡じゃね？そうだよ、絶対必要不可欠な部分がある。危ない危ない。

共通ライブラリなどの技術書
名前定義書
詳細ではなく、大枠だけの仕様

1

perl使ってるなら、POD書く。JavaDoc, PHPDocとか、そういったのを使って、他の人がとりあえず、ソースを見なくても書けるレベルで書く。これは、必要だろぉ。

2

【ガンダム】壊れてるよ。早く直せよ。という会話。【ガンダム】とは、DB名なのだが、知らないと意味わからん。
こういった、プロジェクトで使ってる予備名はまとめておいた方がいい。ウンウン。

3

大枠なら、あまり変わらないから、書いといた方がいい。大枠しらないと、開発しにくいしね。それに、大枠だけなら、変更があっても、修正がそこまで手間にならんでしょ。

例

友達機能 - 男同士なら、友達帳に追加する。

変更後

友達機能 - 男同士なら、お風呂に入って友情を深める。

簡単だね。簡単に修正できるように、Wikiとか使うと良いね。気が楽だしさ。あと、PODも定期的に自動出力、テストとかしとけば良いしさ。やふうーーーー。あ、大枠無し用は、絵のほうがいいなぁ。UMLとかでもいいし、落書きでも良い。

オレオレ書類減らし１０か条

書類を減らしたければ、フレームワークを使え
書類を減らしたければ、コーディングルールを見張れ
書類を減らしたければ、書類をソースに書け
書類を減らしたければ、チームを大事にしろ
書類を減らしたければ、少し偉くなれ
書類を減らしたければ、大枠だけはきちんと書いとけ
書類を減らしたければ、正しい書類を常に持て
書類を減らしたければ、便利なツールを探せ
全体的な書類戦略を考えてないのに、書類書けというリーダは早く蹴落として、自分がその位置に行け。
金融系とか、命に関わるブロジェクとや、大人数でやるプロジェクトでは、書類を減らそうとするな。ケースバイケースだ。

オレオレリーダ書類論

書類戦略というのを存在を常に頭にいれて、ケースバイケースで実行しようと心がけることができるなら、
失敗もするやろうけど、あんたはリーダとしてやっていけると思うわ。
泣きたくなった時は、「お客さんが欲しいのは書類じゃないんじゃぁ！」この言葉があなたを勇気づけるでしょう。

眠い。もう、3:33や。寝よ。