1週間でチームを1つのツールに移行する方法

3つや4つのツールを1つに統合するというと、四半期かかるプロジェクトのように聞こえます。しかし、そうである必要はありません。実際の作業――データのエクスポート、構造の再構築、習慣の再教育――の大半は、正しい順序で進めれば、集中した1週間に収まります。ここでは、どのチームにも使えるプレイブックを、Promanを例に紹介しますが、この手順はどのツールに移行する場合にも当てはまります。

Day 1：現状のスタックを洗い出す

何かに手をつける前に、実際に何を使っているのかを書き出しましょう。

現在使っているすべてのツール ― 誰も正式に承認していないもの（誰かがひっそり運用しているシャドーTrelloボードなど）も含めて。
すべての稼働中プロジェクト ― その中で本当に稼働しているものと、休眠状態のものを見分けます。正直に判断しましょう。60日間動きのないプロジェクトには、きれいな移行ではなくアーカイブが必要です。
ツール間で現在つながっているすべての連携 ― PMツールからのSlack通知、請求ツールに流れる時間データなど。それぞれを再構築するか置き換える必要があります。
誰が何を所有しているか ― 各ツールの管理者は誰か、課金権限を持つのは誰か、後で解約を承認する必要があるのは誰か。

Day 1の成果物は、短いリストであるべきです。どのプロジェクトを移行するか、どれをそのままアーカイブするか、どの連携に置き換えが必要か。このステップを飛ばすことが、移行が何か月も長引く最大の原因です。重要な作業と一緒に、古びた未完成の作業まで移行することになってしまいます。

Day 2：プロジェクトのエクスポートとインポート

Day 1で挙げた稼働中のプロジェクトだけから始めましょう。

必ず先にエクスポートする。 ほとんどのPMツールはタスク、プロジェクト、コメントのCSVまたはJSONエクスポートを提供しています。他の作業をする前にこれを取得しておきましょう。生データを結局使わなかったとしても、安全網になります。
まず1つのプロジェクトを移行する。 一度に全てを一括インポートしないこと。最も活発なプロジェクトを選び、その構造（列、優先度、期限）を手作業で再現し、残りのテンプレートとして使います。これにより、うまくマッピングできないカスタムフィールドやワークフローの段階といった構造的な不一致を、影響範囲が1プロジェクトだけの段階で早期に発見できます。
タスクだけでなく、コンテキストも保持する。 タスクのタイトルと期限は簡単にインポートできます。コメント履歴やファイルの添付は、うまくいかないことが多いです。その履歴を移行する必要があるのか、それとも旧ツールを参照用に読み取り専用で残しておくのか（Day 5参照）を、事前に決めておきましょう。
その場で担当者を再割り当てする。 タスクを未割り当てのままインポートして後で整理しようとせず、誰が何をやっていたかまだ覚えているうちに、インポート時に担当者を割り当てましょう。

Day 3：チャットの切り替え ― 削除せずアーカイブする

チャットの移行が失敗する理由は予測可能です。チームが初日に一気に切り替えようとし、結局誰もが慣れた習慣で古いチャンネルをこっそり使い続けてしまうのです。

まず新しいチャットスペースを立ち上げる。 よく使うチャンネル（general、プロジェクト別、チーム別）をミラーリングします。
具体的な切り替えタイミングを告知する。 「今週中のどこかで」ではなく、具体的な時刻を告知しましょう。曖昧さが利用の分裂を招きます。
古いチャンネルは削除せずアーカイブする。 数週間後に、コンテキストを確認するために古いチャット履歴を検索する必要が出てきます。アーカイブしておけば、新しいチャンネルの注目を奪うことなく、検索可能かつ読み取り専用の状態を保てます。
催促ではなく、誘導する。 古いチャンネルに新しいチャンネルへの案内を固定表示し、旧ツールが対応していればボットメッセージも併用しましょう。何度も催促するより効果的です。

Day 4：時間管理とテンプレート

これはチームが最もスキップしがちな日であり、1か月後に古い習慣が忍び寄ってくる原因でもあります。

まず時間管理のカテゴリーを設定する。 以前使っていた請求やレポートのカテゴリーをミラーリングし、過去との比較が意味を持つようにします。
繰り返し発生するプロジェクトタイプ用のテンプレートを作る。 同じ種類の案件（月次のリテイナー契約、標準的なスプリントなど）を繰り返し行うなら、ボードやタスクのテンプレートを一度作っておけば、新しいプロジェクトは常に統一された状態で始められます。
現在の請求期間分の時間データだけを移行する。 旧ツールがエクスポートに対応していればの話です。過去の時間履歴は、再入力するのではなく、参照用として旧ツールに残しておくのが一般的です。
請求プロセスを最初から最後までテストする。 実際のクライアント請求に使う前に行いましょう。テスト用の時間エントリを記録し、テスト請求書を発行し、想定通りの金額になっているか確認します。

Day 5：旧ツールを廃止する

すぐに解約せず、決められた期間だけ旧ツールを読み取り専用で残す。（一般的には2〜4週間）。エクスポートで見落としたものがあった場合の安全網になります。
「確信が持てたら」ではなく、今すぐ具体的な解約日をカレンダーに設定する。 期限のない読み取り専用期間は恒久化しがちで、結局、旧スタックと新スタックの両方に永遠に料金を払い続けることになります。
すべての連携が移行済みか、明示的に廃止されているかを確認する。 課金され続けている放置されたZapier連携や、誰も読んでいないチャンネルに投稿され続けるSlack Webhookは、何か月も気づかれずに残りがちなものです。
設定した日に解約する。 これが実際にコスト削減を実現するステップです。それ以前はすべて準備段階に過ぎません。

よくある落とし穴

2つのシステムを長く並行運用しすぎること。 これが最大の失敗パターンです。旧ツールと新ツールの両方が数週間以上「稼働中」だと、チームの一部は使い慣れた方をデフォルトで使い続け、結局両方に断片化した非同期なデータが残ることになります。

古びたプロジェクトを移行すること。 動いていないプロジェクトに、稼働中のプロジェクトと同じだけの移行の手間をかけないこと。2か月間誰も触れていないなら、旧ツールにアーカイブしてそのままにしておきましょう。Day 2でそのボードを再構築するのに時間を使う必要はありません。

切り替えの責任者を一人に決めないこと。 「全員の責任」である移行は、結局「誰の責任でもない」ものになります。この1週間を主導し、日ごとの判断を下し、Day 5で実際に旧サブスクリプションを解約する人を、一人任命しましょう。

テスト請求書をスキップすること。 時間管理と請求のバグは、実際のクライアント請求に触れるまで見えません。最初の本番請求を送る前に、ダミーデータでプロセス全体をテストしましょう。

正しい順序で進めれば、1週間はこれをきちんとやり遂げるのに十分な時間です。移行する前に監査し、全部より先に1プロジェクト、削除より先にアーカイブ、そして実際に何かを解約する前に確定した日付を設定する。移行先のツールが何であるかよりも、この5つを順番通りに行うことの方が重要です。