Blog、Wiki、ITS/BTS（と呼ばれるチケット管理システム）それぞれの役割について

本当はALMiniumのインストールが終わって一息ついてから書こうと思っていたネタなんだけど、
インストールに思いのほかてこずっているので・・・

元々このBlogは、当時興味を持っていたSMSやPHP、Webデザインの勉強のために作った。
その後、備忘録のように色々な情報を記録する事に用しているが、
Blogでまとめている内に、情報によってはBlogにまとめづらいものがあることを実感した。
別にBlogがいい、悪いと言うよりは、情報には管理の仕方に種類があり、
それぞれ適した管理システムがあるよ。と、いうお話。
えらそうに言っているが、別に目新しい話ではなく、わかりきった話なんだけど
自分で実感した内容を備忘録として纏めただけ。

さて、本題。
まず、システム開発をしていて、日々記録しておきたい情報としては以下のようなものがある。

仕様、規約、ルール

日々成長していく情報で、頻繁に更新される。
参照する時は常に最新情報が知りたいもの。
過去、どうだったかはあまり気にしない。
いつ追加されたなどは気になるが、
それは以前見た時からなにが変わったかが知りたいため。

バグ、タスク、課題（イシューっていったほうがかっこいいのか？）

粒度は異なるが、日々追加されていく情報。
一つ一つの状況や担当がが刻一刻と変わる。
また、いったんクローズとなれば後は（滅多に）参照されない情報。

記録

何かをやったと言う記録を残しておきたいだけ。
よっぽどの事がないと参照されないが、ないと不安だし、怒られる。

で、ここまで読んだらもうおわかりだろうと思うが、
上記をWeb上で纏めるにはそれぞれ適したシステムがある。

仕様、規約、ルール　→　Wiki

体系的に情報をまとめられ、関連情報も紐づけられる。
更新情報をニュースの形でみる機能を持っているシステムも多い。

バグ、タスク、課題　→　ITS/BTS

ITS（Issue Tracking System）、BTS（Bug Tracking System）、バグ管理システムと呼ばれるもの。
「チケット」と呼ばれる単位で情報を管理し、
そのチケットを誰がいつまでにどうするか、現在はどういった状況かを管理できる。

記録　→　Blog

別にBlogでなくともいいのだが、元々が記録用のシステムの代表ということで。

で、別にこんな事は言われなくてもたいていの人はわかっている。
ただ、いちいち情報の種類によってそんなに仕組みをたくさん作りたくないというのも事実。
じゃぁ、上記のくくりを無視して情報を管理した結果どうなるか？

例１：仕様、規約、ルールをBlogで管理すると・・

どの情報が更新されたかがわからない。
コメントでやり取りすると、そのやり取りを追いかけなければ結論がわからない。
後から参加したメンバーは過去の記事を全部（不要な記事も）読まないと話についていけない。

例２：バグ、タスク、課題をBlogで管理すると・・

担当者がわからない。
状況がわからない。
やらなければいけないことが埋もれてしまう。

例３：仕様、規約、ルールをITS/BTSで管理すると・・

クローズできないチケットが増え、管理すべきチケットが埋もれる
担当者以外にはどんなチケットがあるのかが見えづらい

例４：バグ、タスクをWikiで管理すると・・

状況がわからない。
優先度の管理がしづらい。

例５：記録をITS/BTSやWikiで管理すると・・

とっておけばいいだけの情報が増えていき、管理すべき情報が埋もれていく。

と、言うわけで結論。
サボらずに、適した仕組みを用意しましょう。
さて、ALMiniumのセットアップの続きをせねば。