OpenProjectからデータを移す｜持ち出せるものと、手で作り直す部分
OpenProjectからデータを移す相談で最初に食い違うのは、「控えは取れます」という言葉の中身です。管理画面から取れる控えと、他のサービスへ渡せる形のデータは、まったくの別物です。前者は同じ製品に戻すためのもので、後者は列と行に開いたものです。この2つを混ぜたまま段取りを組むと、移し終える直前になって「読み込めない」と分かります。
この記事では、公式の説明ページで確認できる持ち出しの経路を先に並べ、そのうえで運べないものを名指しします。運べないものが分かれば、手で作り直す量が見積もれます。見積もれれば、いつ止めていつ切り替えるかを決められます。
なお、この道具は自分のサーバーに入れて使う形と、提供元が運用するクラウドの形の2つがあります。持ち出しの手順は共通している部分が多いのですが、決定的に違う点が1つあります。そこから話を始めます。
自分で持っている環境か、預けている環境かで、出口の数が変わる
自分のサーバーに入れて動かしている場合、データはPostgreSQLのデータベースと、添付ファイルを置いているディレクトリの2か所にあります。サーバーに入れる人が居るなら、データベースのダンプを取るという最も原始的で確実な出口が常に空いています。公式のシステム要件のページでは、16以降のPostgreSQLを正式に対応としており、13から15は動く可能性はあるが正式対応ではないと明記されています。つまり、どのバージョンで動いているかを知っていれば、ダンプを取って中身を読む手段は自分の側にあります。
預けている側、つまり提供元が運用するクラウドを使っている場合は、サーバーの中に手は入りません。出口は管理画面とAPIの2つに絞られます。ここが自ホストとの決定的な違いです。契約を終える予定があるなら、どの経路で何を持ち出せるかを、解約の話を始める前に確かめておく必要があります。
どちらの形であっても、共通して効いてくるのが「運ぶ範囲を先に決める」という作業です。全部運ぼうとすると、終わった案件の履歴やコメント、削除されずに残っている古いプロジェクトまで対象に入ります。移行の作業量は、運ぶ件数ではなく、運ぶ種類の数で決まります。作業パッケージだけなら1つの型に整えれば済みますが、そこにWikiと会議と時間記録が加わると、整える作業が3種類増えます。
現場でよく聞くのは、「過去の案件は元の環境を数か月残して読めるようにしておき、動いているものだけ運ぶ」という分け方です。過去分を運ばないと決めた瞬間に、作業量は目に見えて落ちます。読み返す頻度が年に数回なら、残しておくほうが安く済む場合があります。
管理画面から取れる「まるごとの控え」には、専用の鍵が要る
管理画面から取る控えは、設定の中の該当項目から要求します。特徴的なのは、ここに専用の鍵を先に作らせる作りになっている点です。公式の説明では次のように書かれています。
To be able to create a backup, a so called backup token has to be generated first. This is supposed to add another level of security since backing up the whole installation includes sensitive data. 出典: openproject.org
要約すると、環境まるごとの控えには機微な情報が含まれるので、通常のログインとは別にもう1段の鍵を置く、という考え方です。この鍵は生成したときに一度だけ表示されると明記されているので、控え忘れると作り直しになります。
作り直すと、管理者全員にメールで通知が飛ぶ仕様です。誰かが勝手に環境まるごとを持ち出そうとしたときに気づけるようにするための作りで、運用としては正しいのですが、移行の当日に慌てて鍵を作り直すと、他の管理者に不審に思われます。段取りの中に「鍵を作る日」を1行入れておいてください。
控えの要求後は、ダウンロードのリンクがメールで届きます。ダウンロードの時点で、ユーザー名とパスワード、二要素認証を有効にしているならその認証も改めて求められると説明されています。ここも当日にやろうとすると、二要素認証の端末を持っていない担当者が詰まります。
もう1つ、自ホスト限定の注意があります。パスワードを持たない利用者、たとえば外部のアカウントでログインしている管理者が鍵を作り直した場合、その鍵は一定の待ち時間が過ぎるまで有効にならないと書かれています。急ぎのときは、サーバー側でその待ち時間を飛ばすコマンドが用意されていますが、サーバーに入れる人が要ります。クラウドを使っている場合はこの逃げ道がありません。
定期的に控えを取りたい場合は、APIの第3版から控えを引く手順が用意されています。APIの鍵と控え用の鍵の両方が要る作りで、公式にはこれを日次の定期実行に組み込む例が示されています。移行のためだけでなく、預けている環境の中身を自分の手元にも置いておく運用として使えます。
表として取り出せるのは、作業パッケージの一覧
他のサービスへ渡す目的で実際に使うのは、まるごとの控えではなく表形式の書き出しです。公式の説明では、複数の作業パッケージをPDF、XLS、CSVで書き出せること、単体の作業パッケージをPDFとAtomで書き出せることが整理されています。
手順は、作業パッケージの一覧を開き、表示したい列とフィルタを整えてから、右上の設定から書き出しを呼ぶ流れです。ここで重要なのは、書き出されるのは「いま画面に出している列」だという点です。移行先が必要とする項目を先に洗い出し、その列を表に出してから書き出さないと、後から足りない列に気づいて取り直すことになります。
PDFは3種類に分かれています。表をそのまま紙面にしたもの、表紙と目次と説明文を含む報告書の形のもの、ガントチャートを紙面にしたものです。移行の用途で使うのはXLSとCSVですが、移行の記録として当時の計画を残したいなら報告書の形が向きます。
書き出しには権限が要ります。公式には「Export work packages」の権限をロールに割り当てる必要があると書かれています。移行の担当者が管理者でない場合、この権限が付いていないと書き出しのメニューが出ません。作業の当日に気づく人が多い項目です。
もう1点、見落とされやすい仕様があります。生成されたファイルは一定時間しか保持されないと明記されており、ダウンロードのリンクを使い回すことはできません。書き出しを夜に走らせて翌朝に取りに行く、という段取りは組めない前提で考えてください。
書き出しの設定は、保存済みのビューに紐づけて保存できます。毎月同じ条件で書き出す運用があるなら、ビューを作って設定を保存しておくと取り違えが減ります。ただし公開のビューは他の人が編集できるので、書き出しの条件を固定したいなら非公開のビューにする、と注意書きがあります。
まるごとの控えは運べても、他のサービスには渡せない
ここが冒頭で述べた食い違いの正体です。まるごとの控えは、データベースの中身と添付ファイルを、その製品が読み戻せる形で固めたものです。別のサービスがその中身を直接読み込む仕組みは、一般には用意されていません。
したがって、移行の実務は次の2本立てになります。他のサービスへ渡すデータは表形式で作る。まるごとの控えは、あとから「あの情報も要った」と気づいたときのために保管しておく。この2本立てを最初に宣言しておくと、途中で経路を切り替える無駄がなくなります。
保管する側にも段取りが要ります。控えには利用者の情報も添付も入っているので、置き場所と保管の期間、誰が開けるのかを先に決めてください。移行が終わった直後は誰も見ませんが、半年後に「あの案件の経緯を確認したい」と言われたときに、開ける人が居ないと意味がありません。
なお、クラウドを使っていて控えの作成でつまずいた場合、公式の説明では提供元に連絡すれば現在または過去の控え、つまりデータベースと添付を提供できると書かれています。利用をやめる決断をしたときにもデータを受け取れる、という趣旨も同じ箇所に明記されています。困ったら自力で粘るより、先に問い合わせたほうが早い場面です。
手で作り直すことになりやすい5つ
表形式で運べるのは、作業パッケージの行と列です。運べないものを先に名指ししておきます。
・型とワークフロー。どの型がどの状態からどの状態へ進めるか、という定義は表に出てきません ・ロールと権限。誰が何を見られて何を編集できるか、という設計は作り直しです ・カスタムフィールド。値は列として出せますが、項目そのものの定義は移行先で作り直します ・Wiki、会議、フォーラムの中身。作業パッケージとは別の場所に溜まっています ・時間とコストの記録。誰がいつ何時間付けたかは、別の入れ物です
この5つのうち、移行後にいちばん揉めるのは2つ目のロールと権限です。前の環境で見えていたものが見えない、という指摘は移行の翌週から出ます。移す前に、誰がどのプロジェクトで何をしていたかを一覧にしておくと、作り直しの精度が上がります。
1つ目の型とワークフローは、実は減らす好機でもあります。長く使った環境ほど、誰も使っていない型や、通らなくなった状態が残っています。移行を機に、実際に使われている型だけを数えて、そこから作り直す。この整理をしておかないと、使われない設定をそのまま新しい環境に持ち込むことになります。
3つ目のカスタムフィールドは、階層を持つ形式が使われていると厄介です。この形式は上位のプランで使える追加機能として案内されており、移行先に同じ構造を作れるとは限りません。階層を1つの文字列に潰すか、2列に分けるかを、書き出す前に決めてください。
入ってくる方向には、専用の道具が用意されている
出す話だけでなく、入れる話にも触れておきます。この製品には、Jiraからデータを取り込むための専用の道具が公式に用意されています。案内ページでは、取り込める対象が具体的に列挙されています。
プロジェクト、プロジェクトの識別子、課題、課題の識別子、課題の説明、課題の履歴、コメント、添付ファイル、一部のカスタムフィールド、関係する利用者とグループ。ここまでが対象です。裏を返すと、これ以外は対象外だと読めます。取り込みの道具が用意されているのはこの1つで、他のサービスからの取り込みについては同じ形の案内が見当たりません。
自分の環境へ他のサービスからデータを入れる場合、一般にはAPIを使うか、表形式のファイルを整えて流し込むことになります。APIは公開されており、Communityの機能として案内されています。ただしAPIを叩くには書く人が要るので、社内に手が空いているかを先に確認してください。
この点は、移行を検討するときの判断材料になります。取り込みの道具が特定の相手にしか用意されていない場合、移行の作業量は「相手が誰か」で大きく変わります。乗り換え先を比べるときは、料金や機能より先に、いま使っている道具からの取り込み経路があるかを確かめたほうが、見積もりの精度は上がります。取り込みの経路を明示している製品の例としては、Trelloからの移行のように対応する相手を限って書いているものがあります。何でも取り込めると書いてある案内より、対象を絞って書いてある案内のほうが、見積もりには使えます。
自分のサーバーに入れている場合の、もう1つの出口
自ホストで動かしているなら、管理画面を経由しない出口があります。データベースのダンプと、添付ファイルを置いているディレクトリのコピーです。この2つを揃えれば、環境まるごとの控えと実質的に同じものが手元に残ります。
ただし、この経路を使うにはサーバーに入れる人が要ります。導入の方式によって置き場所が変わるからです。公式のシステム要件のページでは、コンテナでの導入を推奨としつつ、パッケージでの導入も案内されています。どちらで入れたかによって、データベースの接続先も添付の置き場所も変わります。導入した人が社内に居ないなら、この経路は最初から選択肢から外して、管理画面の控えで進めるほうが速いです。
ダンプを取るときに気をつける点が1つあります。この製品は、いくつかの拡張機能をデータベース側に要求します。公式には、文字の類似を扱う拡張、B木の振る舞いを持つ索引の拡張、発音記号を落とす辞書の3つが挙げられています。加えて、版の並び順のための独自の照合順序を作ろうとする、とも書かれています。取ったダンプを別の環境に戻すなら、戻す先のデータベースにも同じ拡張が入っている必要があります。ここを確かめずに戻そうとして、復元の途中で止まる例があります。
また、データベースのダンプは、そのままでは中身を人が読める形ではありません。他のサービスへ渡す目的で使うなら、結局は表に開く作業が要ります。自ホストの利点は、「取りこぼしが無い控えを、誰の許可も要らずに自分で取れる」という点にあります。渡す形に整える作業は、預けている場合と変わりません。
サーバーの資源についても、控えを取る前に確認しておくと安心です。公式には、利用者が200人までの構成で空きディスクを20ギガバイト、500人規模で40ギガバイトという目安が示されています。控えはこのディスクの上に一時的に作られるので、残り容量が薄い状態で走らせると途中で失敗します。
本番の前に、試しに一度通しておく
移行の段取りで抜けやすいのが、試しに通す回です。本番の日に初めて書き出しと読み込みを行うと、かならずどこかで止まります。
試す範囲は全件でなくて構いません。プロジェクトを1つ選び、作業パッケージを20件ほど含む状態で、書き出しから読み込みまでを一度通します。この1回で分かることは多いです。列の名前が移行先と噛み合わないこと、日付の書き方が違うこと、担当者の欄が空になること、改行を含む説明文が1行に潰れること。どれも本番の日に気づくと痛い項目です。
試した結果は、そのまま手順書になります。どの列をどの列に対応させたか、どこで手を入れたかを1枚に書いておけば、本番はその通りに動かすだけです。移行の作業を1人で抱えないためにも、この1枚は作っておいてください。担当者が当日に休んだ場合の保険にもなります。
試すときに一緒に確かめておきたいのが、文字の扱いです。日本語の説明文に丸数字やローマ数字が混ざっていると、移行先で化けることがあります。作業パッケージの件名に半角と全角が混ざっている場合、並び順が変わることもあります。この手の崩れは件数が多いほど直すのが辛いので、試しの段階で気づいておく価値があります。
読み込む側の上限も、このときに確かめます。一度に読み込める行数に制限がある場合、全件を1つのファイルで渡そうとすると弾かれます。分割が必要なら、どの単位で分けるか、分けたときに親子の関係が崩れないかを、試しの回で確認してください。
移した先で入力が続くかどうかが、本当の成否
データが移り終わっても、移行は終わりません。新しい環境で入力が続かなければ、1か月後には表が嘘になります。
移行の直後に起きやすいのは、前の環境の癖が持ち込まれることです。前の環境で必須だった項目を新しい環境でも必須にしようとしたり、使っていた型をそのまま作り直したりします。作り直した設定のうち、実際に使われるものはそれほど多くありません。移行は、使われていない設定を捨てる数少ない機会です。
進行をとりまとめる立場から見ると、移行後に確かめるべきは3つです。入力する人が減っていないか。更新が止まっている作業パッケージが増えていないか。報告のために誰かが表を作り直していないか。この3つのどれかが崩れているなら、道具ではなく運用の設計に原因があります。
前の環境では入力されていたのに新しい環境では入力されない、という差が出た場合、原因の多くは入力の手数です。同じ情報を登録するのに画面を何回開くか、必須の項目がいくつあるか。ここが増えていると、人は入力をやめます。移行の設計では、運ぶデータより先に、入力の手数を前の環境と同じか少なくすることを条件にしてください。
そしてもう1つ、移行の直後は報告の形も一度見直す好機です。前の環境で毎週作っていた報告の表が、新しい環境の標準の画面で代用できるかもしれません。代用できるなら、その報告を作る時間がまるごと浮きます。
人の対応付けと添付ファイルが、いちばん時間を食う
移行の見積もりが外れる原因は、だいたいこの2つです。
人の対応付けは、前の環境のアカウントと新しい環境のアカウントを紐づける作業です。退職した人、外部の協力者、すでに使われていないアカウント。この3種類が必ず混ざっています。担当者として名前が入っている作業パッケージを新しい環境へ運ぶとき、その人のアカウントが無いと担当者の欄が空になります。
この製品では、メールアドレスを持たない利用者を作って作業を割り当てられる仕組みが上位のプランで案内されています。移行先にも似た仕組みがあるかどうかで、対応付けの手間は変わります。無い場合は、担当者の欄を文字列の列として持たせるか、作業パッケージの説明文に元の担当者名を残すかの判断になります。
利用者の数え方についても、公式のよくある質問に説明があります。数えるのは名前を持つ利用者であり、使わなくなった利用者をロックすれば枠を空けて別の人を招待できる、という作りです。移行の前後で人数の枠をどう使うかは、この仕様を前提に計画してください。
添付ファイルは、量が読めないのが問題です。作業パッケージに付いた画像や書類は、表形式の書き出しには含まれません。まるごとの控えには含まれますが、そこから個別のファイルを取り出して新しい環境の対応する場所に付け直す作業は、件数だけ発生します。
現実的な落としどころは、全部を運ばないことです。動いている案件に付いている添付だけを運び、終わった案件の添付は元の控えの中に置いておく。運ぶ対象を絞ると、この作業は数日で終わります。絞らないと、数週間かかることがあります。
止める日を、契約の区切りに合わせる
最後は日程の話です。移行の日をどこに置くかは、技術ではなく契約で決まります。
有料のプランを使っている場合、公式のよくある質問には、利用者を増やすことはいつでもでき5人単位で日割りで課金されるが、減らすのは契約期間の終わりにしかできない、と書かれています。プランを短くしたり小さくしたりする変更も、現在の期間が終わったときに効く、という説明です。
これが意味するのは、移行を期の途中で終えても、支払いはその期の終わりまで続くということです。だとすれば、切り替えの日を期の終わりの少し前に置くのが合理的です。終わりの直前に切り替えれば、両方を払う期間が最短で済みます。
もう1つ、新しい側の契約の始まりも同じ考え方で見ます。移行の作業中は両方が動いているので、その期間は二重に費用がかかります。この重なりを何日にするかを先に決め、その日数を見積もりに入れてください。重なりをゼロにしようとすると、切り替えの当日に問題が出たときの逃げ場が無くなります。1週間から2週間の重なりを見ておくのが無難です。
そして、切り替えの日を決めたら、その日の何時以降は新しい側にだけ書く、という線を全員に伝えます。線が曖昧だと、両方に書かれた作業パッケージが生まれ、どちらが正しいのか誰も分からなくなります。この混乱は、データの移し損ないよりもたちが悪く、収束に時間がかかります。
移行の見積もりを、道具選びの側から見直す
ここまでの整理を、移行される側ではなく、移行する先を選ぶ側の視点に置き換えます。
移行の作業量は、運ぶデータの量では決まりません。運ぶ種類の数と、作り直す設定の数で決まります。作業パッケージだけを運ぶなら表形式の書き出しで足りますが、型とワークフローとロールと権限を作り直す必要があるなら、そちらのほうが時間を食います。
ということは、移行先の道具に設定できる項目が多いほど、移行の作業は重くなります。設定できる項目が少ない道具は、機能としては物足りなく見えますが、移行のときには軽い。この逆説は、道具を入れ替える判断のときに見落とされがちです。
区切りを人数とボードの数だけに寄せて、機能で絞らず、区切るのは人数とボードの数だけという形にしている道具なら、移行のときに作り直す設定はほぼボードの構成だけになります。何が使えて何が使えないかをプランごとに覚え直す作業が発生しません。どの形が自分のチームに合うかは、できることで扱える範囲を確かめ、料金で人数の区切りを見比べると判断できます。
移行先を絞り込む段階では、いま使っている道具との距離を先に測ってください。板の形で管理しているならボード型の道具へ、工程表で管理しているならガントを持つ道具へ移すほうが、作り直しは少なくて済みます。個別の比べ方は比較の一覧にまとめてあり、板の形からの移行ならTrelloとの比較、課題の一覧からの移行ならBacklogとの比較が近い題材です。工程表を中心に回してきたチームはmonday.comとの比較も判断材料になります。
最後に、預けたデータをどう扱われるかは、移行する前に確かめる項目です。控えの取り方、保管の場所、解約したあとの扱い。この3つを先に聞いておけば、次に移るときの段取りは今回より楽になります。考え方の整理には安全性の考え方が使えます。移行の実務でよく出る疑問はよくある質問にも並んでいます。
移行は一度きりの作業に見えますが、実際には数年おきに繰り返されます。今回の移行で「何が運べて何が運べなかったか」を1枚の記録に残しておいてください。次の移行のときに、その1枚が見積もりの土台になります。
記録に残す項目は多くなくて構いません。書き出しに使った経路、書き出した列の一覧、読み込みで手を入れた箇所、運ばないと決めたものとその理由。この4つがあれば、次に同じ作業をする人は、ゼロから調べ直さずに済みます。理由を書き残すのが特に効きます。「終わった案件は運ばない」と決めた理由が残っていないと、次の担当者は同じ議論を最初からやり直します。
そしてもう1つ、移行が終わったあとに前の環境をいつ止めるかも、記録に日付で書いておいてください。止める日を決めずに残した環境は、たいてい数年残ります。残っている間は費用がかかり、機微な情報も残り続けます。移行の計画を立てる段階で、止める日まで含めて1本の線にしておくのが、いちばん確実です。
Q1. クラウドで使っていますが、サーバーに入れなくてもデータを全部持ち出せますか？
管理画面から環境まるごとの控えを要求できます。事前に専用の鍵を作る必要があり、その鍵は生成時に一度だけ表示されます。ダウンロード時にはログインの認証が改めて求められます。控えの作成でつまずいた場合は、提供元に連絡すれば現在または過去の控えを提供できると公式に案内されています。
Q2. 書き出したファイルを、そのまま別のサービスに読み込ませられますか？
環境まるごとの控えは、他のサービスが直接読み込める形ではありません。他のサービスへ渡す場合は、作業パッケージの一覧をXLSやCSVで書き出し、移行先が求める列に整える作業が必要です。まるごとの控えは、あとから中身を確認するための保管用と考えてください。
Q3. 移行のときに作り直しになるのはどこですか？
型とワークフロー、ロールと権限、カスタムフィールドの定義、Wikiや会議やフォーラムの中身、時間とコストの記録です。表形式で運べるのは作業パッケージの行と列だけなので、この5つは移行先で作り直す前提で見積もってください。中でもロールと権限は、移行の翌週から指摘が出やすい項目です。
Q4. 有料プランを使っています。移行の日はいつに置くのが得ですか？
利用者を減らしたりプランを小さくしたりする変更は、契約期間の終わりにしか効かないと公式に案内されています。したがって切り替えは期の終わりの少し前に置くのが合理的です。ただし当日の不具合に備えて、1週間から2週間は両方を動かす期間を見ておいてください。