マインドマップをドキュメント地獄から抜け出す糸口とする
むかしの話ですが
「もうすぐA案件と類似のB案件が始まるから、まずはA案件のキャッチアップしといて。」
みたいな話があってドキュメント地獄にハマりました。
今日はそのことについて。
SI業界で働いていると割りとよく聞く発言で
「ここの現場はよくドキュメント化されている方だと思うよ。」
というのがあります。
つまりソースコードを補完する十分なドキュメントがあるのでここは出来た現場だ、ということです。
・・・果たしてそうでしょうか？
こんな構成のディレクトリ、よく見ますよね。
これだけ見ると確かにきちんと整理されていそうな気もします。
ですが実態はたぶんこんな感じではないでしょうか？
03_基本設計ディレクトリ配下には当然のように「基本設計書以外のもの」が格納されています。
これを見て「別に普通じゃない？」と思ったそこのあなた！！
あなたはかなりSI業界に毒されていますw
SI業界では各フェーズにおいて、そのフェーズで起こった事象は全て証跡を残し、全て資料化するのが美徳とされています。
そのため「量」的には十分なドキュメントとなりますが、同時に２つの問題と密接に関わることになります。
それは
- 鮮度の問題
- 見通しの問題
です。
＜鮮度の問題＞
どんな情報にも鮮度があります。
通常、案件はどれほどの期間をかけて実施されるでしょうか？
3ヶ月？6ヶ月？1年？
いずれにしても、案件開始当初に作成した資料なんて案件終了時には確実に陳腐化しているものです。（これは経験則として分かりますよね？）
そしてそのドキュメントはメンテナンスされるどころか2度と開かれることすらないのです。
「ソースコードを書く＝技術的負債を抱える」というのは良く知られたことですが、まずは「資料を作成する＝負債を抱える」という感覚を持つことが大事だと思います。
そんな2度と開かれないすぐ陳腐化してしまう資料を作成するのに時間をかけるくらいなら
プロダクションコードを洗練する時間を取ったり、テストコードを書いたりする方がよっぼどマシです。
なぜなら資料は陳腐化してゴミとなりますが、コードは生き続けるからです。
＜見通しの問題＞
これはとても単純な問題です。
あるドキュメントを探したい場合に
だったらどっちの方が見つけやすいかは明白ですよね？
つまりドキュメントを作れば作るほど見通しを悪くしているということです。
＜そして困ったこと＞
この2つの問題にどハマりしてましたw
まず、どの資料が「生きた／活きた」資料なのか？が全く分かりませんでした。
つまり資料の鮮度が不明なため、陳腐化している情報なのかどうか切り分けが出来ませんでした。
次に、資料の数が膨大すぎてどんな資料があるのか？どんな内容がまとめられているのか？を掴むことが出来ませんでした。
よって全体像が全く見えませんでした。
＜で、どうしたのか？＞
こんな状況を嘆いてばかりはいられないので・・・
どうしたら良いものかとしばらく考え、思い付いたのが「マインドマップを書いてみる」でした。
たとえば上記の例では
のように資料を整理し、まずは案件フォルダ配下のどの資料が「生きた／活きた」資料なのかを知ることにしました。
つまり
「100のディレクトリ内に300のファイルがある場合」
から
「10のディレクトリ内に30のファイルがある場合」
という状況を論理的に創り出すことにしたのです。
もちろん私一人では選定なんて出来ないので、当時の案件担当者を巻き込んで作成してました。
選定基準は「鮮度の高いもの」とし、鮮度の問題にも同時に対応していきました。
（当時の案件担当者もどれが「生きた／活きた」資料なのかなかなか判断ついていないようでしたがw）
＜さいごに＞
まずはマインドマップを作成することを入り口に、以後これを洗練していきながら理解を深めていくという手法はなかなか使えるのではないだろうかと思っています。
（いつもうまくいくかは分かりませんが、この案件の時はうまくいきました。）
あと・・・がむしゃらに資料を作成し続けるとこういう負債を抱えてしまうので良くないですね。
一体、われわれは1つの案件を通してどれだけの時間（ムダな）資料作成に当てているのでしょうか？
その時間をコードに注げば、もっと全うなシステムが増えるのにな〜と思う今日この頃でした。
