NotesのDB設計ができる人はチケット管理システムのプロジェクトへの適用にアドバンテージを持っている
WF型開発できちんと変更管理するやり方も、色んなSIを渡り歩きながら、学んでいた。
SIer特製の障害管理Webシステムへの障害票の書き方、コミットする時には障害管理番号を記載すること、CVSのコミットログに変更理由を記入すること、などの運用ルールはある程度分かっていた。
だから、Redmineを障害管理からタスク管理へ発展させて使う方法はマッチできた。
このブログを読んでいて、今ではもう一昔前のプロジェクトを思い出したんですね。多分、以前にネタとしてブログに書いているかもしれないですけど。
ウォーターフォールでのシステム開発手法も理解していたし、開発プロセスの組み立てもよくわかっていたんです。当時のメンバが中心となって開発チームを作り、ウォーターフォールもどきでプロジェクトを回していたところ、モドキと書いたとおりシステム開発手法も、開発プロセスの設計もあまり洗練されていなくて、トラブルシュートに手を取られはじめると次第に進捗が芳しくなってきたんですね。
当時、問題だと思ったことは、作業負荷が見えない、進捗が管理されている状態にない、情報がリポジトリなどに集中管理されていない、などなどがあったような気がします。トラブルも記載した課題管理も十分ではなかったような。
そのときはexcelで進捗管理をしていたような気がします。べつにexcelが悪いわけじゃないんですけどね。で、監督というか開発責任者の立場としては、上述の問題を解決させないといけないんだけれど、今のまま「何とかしろ」といっても何も解決しないと思ったんです。
当時、スクラムを個人的に調べて、スクラムの開発プロセスはこれまで経験してきたウォーターフォールの時間軸的な短縮版と解釈し(ご意見はあるでしょうが個人的な見解です)、開発テーマも仕様変更管理や追加開発管理などのプロセスが応用すればそのままスポンっと適用できると思ったんです。
でね、じゃあその上で、課題の情報の集中管理をどうすればいいかと思ってやっぱり調べていたらチケット管理システムに辿り着いたんです。ちょうど、知り合いがチケット管理システムを良く知っていたので個人的に導入したいんだけどどうすればいいかを教えてもらって、家のPCにwindows版を入れていろいろと弄ってみたんですね。そのソフトウェアはバージョン管理システムの機能もあったので、それで情報の集中管理は解決のめどをつけて。
そうすると、のこりは可視化なんですね。誰が何をやっているか、どのくらいのタスク数を抱えているか、1人に集中して過負荷状態になっていないか、とかとか。
ところで、Notesってあったでしょう。あ、今もあるか。アレのDBの設計を経験したことがある人は、チケット管理システムのビューやフォームの設計のハードル皆無だと思います。
ラベルをもったデータ項目を追加するか、標準のデータ項目を使いまわすことで、システム開発手法で管理したい情報を持たればいいとか、開発プロセスごとで見たい情報をビューで見せることができるとか、そういったことがわりとすんなりイメージできます。
そんなことを会社じゃなくて家のPCでフィージビリティを検証するなんてなんて社畜かもしれませんがそうでもしないと、なかなか考える時間が取れなかったのでしょう、当時のワタシは。
そのときのワタシの頭の中にあったことは「問題解決をするためにツールの導入を考えていたのか」と聞かれれば答えは「ノー」です。問題はプロセスにあると見切り、その問題のあるプロセスままだと潜在化したままで進行してしまうので「可視化」が問題解決の決め手と思った、と当時判断したと思います。今でもそうすると思いますが。
そこには、そう判断した根っこにはチケット管理システムはプロセス管理システムとして使える、と思ったんですね。そのおおもとを辿るとNotesもその1つの要素なのかもしれません。
実際は、プロセスが確立されたイメージを持ってツールを導入していたのだろう。
その点から言えば、確立した開発プロセスのイメージを持っているから、適用するプロジェクトの課題解決のための1つの手段としてツールを導入することを判断した、のではないかと思うのです。
