なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド

最近、もともと所属していたチームをはなれて外で開発をしていた。
久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。
（今現在も解決していない）

ほかのチームでRedmineを展開してそこそこ上手くいっていたので、
なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。

個人的なメモ。

個人的に思うところは以下の３点

・マイルストーンの役割を誰も理解していない
・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない
・求められる機能とTracの機能に乖離があった

「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて
ITS使ってる人には常識。

これはプログラマの思索であきぴーさんが再三指摘されていることなので、
理論的な部分についてはそちらを見てほしい。

この理解がないとチケットの収拾がつきにくく、want fix していいのかどうかの判断もできない。
結果、関係者に話を聞いてまわることになり、ITSを使う意味がなくなる。

この辺は導入者の啓蒙に責任がある。
責任者はどこか。

僕である。

Redmineを導入したプロジェクトでは事前にRedmineによるタスクマネジメント実践技法を読んでいたし、
チームのリーダーと一緒に見ながら導入したりしたので、マイルストーンを立てる人間の意識を作ることが出来ていた。
この違いは大きい。

教訓：最低でもマイルストーンを立てる人にはマイルストーンの役割をきちんと説明する。

これもまた啓蒙の問題。

バグ表を作る人は大抵プロジェクトのリーダーだ。

彼らにITSを使うようにさせない限り、日付付きExcelのバグ表を量産し、そちらに記入しろと強制してくる。
二重起票は面倒臭いし、うるさいことを言われないITSは徐々にメンテされなくなる。

しかも大抵の場合、プロジェクトのマイルストーンを決定するのは彼らだ。
だから、何がなんでもプロジェクトのリーダーにはITSを使わせる必要がある。

社内でITSを展開している場合、社外からアクセス出来ないことを理由にITS利用に及び腰になる人は多い。
先回りしてExcelのインポート・エクスポート機能を提示し、どうしてもアクセス出来ない場合は
Excelをメールでやりとり出来ることを教えれば多少は安心する可能性はある。

教訓：プロジェクトリーダーの退路を断ってITSを使わせる

僕の所属していたプロジェクトはいわゆるソリューション開発というやつで、リリースするお客さんごとに
微妙にカスタマイズするのが常である。

SCMについてはメインラインモデルを利用した管理で十分だったが、ITS側でもカスタマイズごとに
プロジェクトを分けて管理した方が、視覚的にも整理されたのではないかと感じる。

TracでもTraMで複数プロジェクトが管理できるが、Redmineの「プロジェクトの親子関係」の方が
直感的で分り易く、やりたいことがすぐに実現できたのではないか。

事実、Redmineを導入したプロジェクトもソリューション開発であるが、早期からプロジェクトの親子関係を
使って顧客ごとにプロジェクトを分割したため、要件の整理に大変役立った。

教訓：ITSによって向き不向きがある。１W程度試用して、やりたいことができるのか確認するべき。

他にもブランチマネジメントが微妙だったとか、CIあるのに一時の速度を求めてメンテしないとか
いろいろ問題はあるけど、「ITSで何ができるのか」をきちんとメンバーに教えるのが導入者の役目。
そこをサボってしまったことに、今回の問題の本質があるように感じる。