昨日、RedmineとBacklogについて書きましたが、プロジェクト管理ツールの移行について書いてみます。昨日の記事はこちら

スクラップアンドビルドしよう

　移行時に話題になったのは、

・ユーザ管理
・プロジェクト整理
・フレームの見直し
・過去のチケットの移行
・滞留しているチケット類の整理および場合によって移行

あたりですが、下記の順でtodo化して順番に整理していきました。

　前提として、マネージャー間では「スクラップアンドビルドしよう」と決めていました。基本システム移行はせず、段取りを踏んで整理していきました。大変ですが、うまくいけば仕事が減るはず！

プロジェクトオーナーを明確にする

　プロジェクトについては、今定常的に運用しているものは元のままでいく前提にしました。運用もそれなりに出来上がっていたので、これを変えないためです。

　ここでは、すべてのプロジェクトについてオーナーを明確にしました。今まで管理者を大量に設定し、情シス社員の結構な数の人間がプロジェクトを自由に作れる状態でしたが、頼まれて作って放置とか、管理者がいない（部署同士、ユーザ部門と情シスでお見合い状態になっていたものがありましたので、プロジェクトを一覧化し、管理者、責任者を明確にして、新規のプロジェクト作成についてはワークフロー申請させてサポートデスクで作るというフローにしました。

プロジェクトの選別

　このプロセスでは一定の選別を行いました。人よりプロジェクト数がはるかに多い状態が続いていましたので。稼働をやめたシステムや枯れていて運用もほぼ発生しないシステムについてはメンバーで話して移行対象外とし、問い合わせがあればすべてサポートデスク対応としました。

　これは情シス内部でも結構な反応（文句）がありました。

・プロジェクト統合で関係ないチケットが見えるのがいやだ
・チケットで全部連絡が来る方がいい
・管理できないのなんか問い合わせてくるユーザの責任だ
・サポートデスク経由なんてめんどうくさい、ワンストップでやりたい
・つべこべ言われるなら俺はBacklogなんか抜けるぞ！

 最後の部分は会議で言われたのですが、マネージャーなったばかりだったこともあり焦りました。。。

　しかし、当時のマネージャー間の共通した考えとして、管理手法やルールを共有化して、少しずつ管理を強めて管理コストを減らしたいという思いがありましたので、ここは譲りませんでした。最初は若干ぎくしゃくしましたが、今はみんな慣れて普通に使っています。

運用系プロジェクトのテンプレ化

　この機会に運用用プロジェクトのチケットについては機能横断でチケットの種別、カテゴリーなど複数の項目をテンプレ化しました。

　これは少人数で話し合って、カテゴリについてもシステムの呼び方、分類をそろえたり、種別を（見た目も含めて）そろえたりといったことをやりました。こういったことは新規設定するタイミングでやるタイミングでないとできないのでやってよかったと思っています。

不具合チケットのテンプレ化

　課題のテンプレ化もやりました。エンドユーザの不具合って「〇〇がおかしいです」くらいしか書いていないことも多かったのですが、発生時刻、発生したテスト環境など、基本的なことをテンプレート化してそこを埋めてもらうようにしました。

これは最初はユーザから抵抗がありました。「おかしいんだから見ればわかるだろう！」というよくあるやつですね。これは、リーダークラスの方から少しずつ説明しながら浸透していきましたが、今でも項目を全部埋められない人が多いので、まだ課題があるなと思ってます。

新しく入った人に管理運用しやすい世界

　今回めざしたのはこれです。この成果として一番びっくりしたのは、SIerから転職された方などが、説明なしでそのまま不具合チケットの項目や運用のルールなどに入っていけたことです。自分が使えるのはもちろん「これはこういった意味です」みたいなことを事前説明なしですらすら説明している。なんと素敵な世界。惚れてしまいます。

　さらに、ユーザ側も、不具合チケットの起票などで文句たらたらでしたが、後になってから「状況が整理されてみやすい」ということを言い始めました。最初文句を言っていた人たちが「テンプレートを守りなさい」とお互い言い合うようになりました。

まだまだ課題はありますし、個人差もありますが、できるだけ管理の「無駄」をなくして、俗人化を減らしていきたいと思っています。

移行について書ききれなかったので、別の機会で、移行時のチケット整理について書きたいと思います。