Backlog・Redmine から移る

長く使ったツールほど、移るのは怖いものです。課題が何千件もあれば、なおさらです。

ぽんぽこ制作所の取引先、「アトリエ・ミナト」さんから相談が届きました。

引っ越しの計画は、次の順で立てます。この図では、「決める」ことが先で、「動かす」ことが後だとわかります。

なぜ移るか理由を 1 行で→何を持っていくか使うものだけ→いつ切り替えるか日を決める→試しに 1 つ移す→全体を移す

引っ越しの前に決める 3 つのこと

1. なぜ移るのか

理由があいまいだと、移ったあとに「前のほうがよかった」が出ます。「費用」「使いにくさ」「サポート終了」「お客様と共有したい」など、理由を 1 行で言えるようにします。それが、移行後に確かめる合格ラインにもなります。

2. 何を持っていくのか

3,000 件を全部持っていく必要はありません。

種類	持っていく？
進行中の課題	持っていく
終了した案件の課題	参照する可能性が高いものだけ。または元のツールを読み取り専用で残す
Wiki・ドキュメント	使われているものだけ
ユーザー	いま関わっている人。退職した人は、履歴の名前として残れば十分
ステータスや種別の設定	使われているものだけ。使っていない種別は整理する

3. いつ切り替えるのか

切り替えの日を決め、その日から「元のツールには書かない」と全員で約束します。両方に書く期間が長いと、どちらが正しいかわからなくなります。案件の区切り（公開の直後など）を狙うと、混乱が少なくなります。

ツール間で「そのまま移らない」もの

用語や仕組みは、ツールごとに少しずつ違います。たとえば「バージョン」という言葉ひとつでも、製品の版を指すツールと、期日つきの目標を指すツールがあります。移す前に、次を確認します。

• ステータスの数と意味: 相手のツールのステータスに、どう対応させるか
• 種別（トラッカー）: バグ・タスクなどの分け方が合うか
• カスタム項目: 移せない型がないか
• 権限: 元のツールの役割を、新しいツールのどの役割にあたるとするか
• 本文の書き方: 独自の記法（Textile など）が、きれいに変換されるか

移す側のツールの設定も、先に見ておくと安心です。たとえばステータスは、次のように並びます。

• 「本流」に、未対応から完了まで順に並ぶ。完了は本流の最後
• 「わき道」に、中止がまとまる

種別（バグ・タスクなど）の分け方も、あわせて見ます。

• 種別は、タスク・バグ・要望・その他
• 種別ごとに、使う項目と必須の項目を決められる

移したあとの確認リスト

引っ越しが終わったら、次を確かめます。

• 課題の件数が、元と合っている
• 課題の番号（キー）が、元と同じ。お客様に伝えた番号が使える
• 担当者・期限・ステータスが入っている
• 添付ファイルが開ける
• 親子関係が残っている
• 本文の見出しやリストが、崩れていない

件数は、全体と 1 案件の両方で数えます。抜けは、小さな案件のほうが見つけやすいからです。

試しに 1 プロジェクトだけ移す

いきなり本番ではなく、まず小さなプロジェクトで試します。うまくいかなければ消して、設定を直してやり直せます。1 件でも通れば、手順と所要時間が見えるので、全体の計画も立てやすくなります。

まとめ

• 移る理由・持っていくもの・切り替える日の 3 つを、先に決める
• 全部は持っていかない。いま使うものだけにする
• ステータス・種別・権限・本文の書き方は、そのまま移らないことがある
• 移したあとは、件数・番号・担当・添付・親子を確かめる
• まず小さな 1 プロジェクトで試す

akamine でやるなら

akamine には、Backlog と Redmine から、プロジェクトをまるごと移す「引っ越し」の機能があります。システム管理者が、システム管理の「ほかのツールから引っ越し」で、スペースの URL と API キーを入れてつなぎ、移すプロジェクトを選びます。課題の番号は、元のままで引き継がれます。詳しい対応は、マニュアルの記事で確かめてください。

• Backlog・Redmine からの引っ越し
• ユーザーの管理

関連する記事

• ツールの選び方
• Excel管理から卒業する
• 定着させるコツ