CSV移行の手順｜列の食い違いをどう吸収するか
CSV移行の手順を調べている人の多くは、書き出しと取り込みのボタンの位置を知りたいわけではありません。書き出しはすぐ終わります。詰まるのはその次で、いまの表にある列と、移す先が受け取れる列が噛み合わないところです。担当者の欄が2人分入っている、期限が空のまま何年も放置されている、備考に改行が5行入っている。この記事では、CSVで表のデータを別の道具へ移すときに実際に詰まる箇所を、列の食い違いをどう吸収するかという一点に絞って手順の形で整理します。読み終えたときに、自分のチームのどの列が危ないかと、移行の日をいつに置けばよいかが決められる状態を目指します。
移行は技術の作業に見えて、実際は決めごとの作業です。文字コードも改行も日付も、正解はすでに決まっていて、迷うところはほとんどありません。迷うのは、この列を移すのか捨てるのか、この担当者名は誰と誰を同じ人とみなすのか、期限が空の行をどう扱うのかという判断です。判断を先に済ませてから手を動かすと、移行は1回で終わります。手を動かしながら判断すると、何度もやり直すことになります。
移行で本当に詰まるのは列の名前ではなく列の意味
CSVでデータを移す作業は、表面上は単純です。いまの道具から書き出す。列の名前を移す先に合わせる。取り込む。この3段階しかありません。実際に多くの解説記事もこの3段階で書かれています。ところが現場でつまずくのは、この3段階のどれでもなく、その間にある「列の意味を揃える」という工程です。
たとえば、いまの表に「状態」という列があり、移す先にも「状態」という列があるとします。名前は完全に一致しています。しかし中身を見ると、いまの表には「未着手」「着手」「確認中」「先方待ち」「保留」「完了」「取り下げ」の7種類が入っていて、しかも「着手」と「作業中」と「進行中」が混在しています。移す先の板は列（レーン）が4つしかありません。この時点で、名前の対応だけでは移せないことが確定します。
同じことが担当者にも起きます。表計算ソフトの担当者欄は自由入力なので、「田中」「田中さん」「田中太郎」「TANAKA」「田中／佐藤」が同じ列に並びます。人間が読めば同じ人だと分かりますが、取り込む側は文字列として比較するので、別人として5人分のアカウント候補が生まれます。あるいは、招待されていないという理由で全部が未割り当てになります。
期限も同じです。「2026/9/1」「2026-09-01」「9月1日」「9/1（月）」「9月上旬」「未定」「なるはや」が同じ列に共存します。前の4つは書式の問題なので機械で直せますが、後ろの3つは書式ではなく意味の問題で、機械では直せません。
つまり、CSV移行の難所は文字列変換ではなく、いまの運用がどれだけ言葉を揃えずに回ってきたかの棚卸しです。表計算ソフトは何を書いてもよいので、揃えないまま何年も回ります。移す先の道具は入力を制限するので、揃っていない部分が全部そこで表に出ます。移行のときに急に問題が噴き出したように見えますが、問題はずっと前からあって、見えていなかっただけです。
この視点を持つと、移行の準備が何をする作業なのかがはっきりします。データを加工する作業ではなく、チームで使う言葉を決める作業です。だから、移行の作業を1人で黙々とやろうとすると必ず止まります。状態の言葉をいくつにするか、この案件の担当は誰なのか、この空欄は何を意味しているのかは、進行を預かる人が決めるか、関係者に確認するしかありません。手を動かす前に決める時間を取ってください。
現場でよく聞くのは、移行そのものは半日で終わったのに、その前の言葉を揃える相談に2週間かかったという話です。これは失敗ではなく、正しい配分です。逆の配分になっているとき、つまり相談なしで移して後から直しているときは、たいてい取り込みを何度もやり直すことになります。
手を動かす前に作る、1枚の対応表
移行の準備でいちばん効くのは、対応表を1枚作ることです。表計算ソフトの新しいシートで足ります。ここに、いまの列と移す先の受け皿の関係を書き出します。この1枚があると、取り込みでエラーが出たときにどこを直せばよいかがすぐ分かり、誰かに確認を取るときも話が早くなります。
対応表に書く6つの欄
対応表に必要な欄は多くありません。次の6つで足ります。
1つ目は「いまの列名」です。書き出したCSVの1行目をそのまま貼ります。ここで「同じ意味の列が2つある」ことに気づくことがよくあります。「担当」と「担当者」が両方あるといった状態です。
2つ目は「移す先での置き場所」です。カード名にするのか、説明文に入れるのか、期限にするのか、ラベルにするのか、それとも移さないのかを書きます。板型の道具では受け皿の種類が限られているので、この欄を埋める段階で「入る場所がない列」が浮かび上がります。
3つ目は「値の種類」です。日付なのか、選択肢なのか、人の名前なのか、自由な文章なのか、数値なのかを書きます。種類が決まると、次にやるべき変換が自動的に決まります。
4つ目は「値のばらつき」です。その列に実際に何種類の値が入っているかを数えて書きます。表計算ソフトなら、その列だけ別シートにコピーして重複を削除すれば数分で出ます。10種類以内なら手で揃えられます。100種類を超えたら、それは自由入力の列なので、揃えるのではなく文章として丸ごと移す判断になります。
5つ目は「空欄の数」です。全体の何行が空なのかを数えます。この数字は後で効いてきます。空欄が半分を超える列は、実質的に使われていない列です。
6つ目は「決めたこと」です。誰と相談して何を決めたかを1行で書きます。移行が終わったあとに「なぜこの列を捨てたのか」を聞かれたとき、ここを見れば答えられます。
この対応表は、移行のあとも残しておいてください。半年後に「昔のあの項目はどこへ行ったのか」という質問が必ず出ます。
移さないと決めた列の扱い
対応表を作ると、移さない列が必ず出ます。ここで大事なのは、移さない判断を後ろめたく思わないことです。使われていない列を移すと、新しい道具の上でも使われないまま画面を占領します。むしろ移行は、たまった不要な列を落とす数少ない機会です。
ただし、捨てる前に元のファイルを保管してください。書き出したCSVそのものを、日付を付けて保存しておきます。移行後に「あの数字が必要になった」となったとき、元のファイルさえあれば探せます。保管の場所は、チームの誰もが分かるところにしてください。作業した人のパソコンの中だけにあると、その人がいない日に困ります。
ここで注意点があります。書き出したCSVには、たいてい人の名前やメールアドレスが入っています。案件によっては取引先の担当者名も入ります。作業用に机の上のパソコンへ置いたまま忘れると、そこが管理の外に出た個人データの置き場になります。
個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。 出典: ppc.go.jp
個人情報の保護に関する法律が事業者に求めている安全管理措置は、移行作業中の一時ファイルにもそのまま及びます。移行が終わったら、作業用のコピーを消す日を決めてください。取り扱いの詳しい判断が必要な場合は、所管の窓口や社内の担当部門に確認するのが確実です。道具を選ぶ側の考え方については安全性の考え方に、どこにデータが置かれ、誰が見られるのかという整理が載っています。移行の相談を社内で通すとき、この観点を先に押さえておくと話が早くなります。
文字コードで最初の関門が来る
CSVを開いた瞬間に文字が化けるのは、移行作業でいちばん最初に起きる問題です。そして、いちばん簡単に直る問題でもあります。ここでつまずいて移行そのものを諦めるのはもったいないので、仕組みを短く押さえておきます。
なぜ化けるのか
CSVは中身がただの文字の羅列で、どの文字コードで書かれているかという情報を持ちません。だから開く側が推測します。推測が外れると化けます。日本語のデータでは、主に2つの流儀があります。ひとつは日本語圏の表計算ソフトが長く使ってきた流儀、もうひとつは世界中の道具が標準にしている流儀です。前者で書き出したファイルを後者の前提で読むと、日本語が全部おかしな記号になります。逆も同じです。
さらに厄介なのが、ファイルの先頭に付く目印です。この目印があると、表計算ソフトは正しく開けますが、取り込む側の道具では1列目の名前の先頭に見えない文字が付いた状態になり、「その列名は存在しません」という素っ気ないエラーで弾かれます。列名は合っているのにエラーが出るときは、まずこれを疑ってください。
実務での回し方
順番はこうです。まず取り込む先の道具が求める文字コードを確認します。多くの道具は世界標準の側を求めます。次に、表計算ソフトから書き出すときに、その文字コードを指定して保存します。名前を付けて保存の画面で、ファイルの種類を選ぶ欄の近くに文字コードの選択肢があります。既定のまま保存すると日本語圏の流儀になることが多いので、ここは必ず明示的に選んでください。
書き出したら、取り込む前に必ず確認します。確認の方法は簡単で、そのファイルをメモ帳のような素朴なテキストエディタで開くだけです。表計算ソフトで開き直すと、開いた側が勝手に解釈するので確認になりません。素朴なエディタで開いて日本語が読めれば、その文字コードで正しく書かれています。
もうひとつ、行の終わりの記号にも2つの流儀があります。こちらは取り込む側がたいてい両方受け付けるので、実務で問題になることは多くありません。ただし、改行を含む値がある場合だけは影響が出るので、次の節で扱います。
化けたファイルを無理に直そうとして、置換を繰り返す作業に入るのは避けてください。元のデータから書き出し直したほうが速く、確実です。移行では「作り直せるものは作り直す」が原則になります。加工したファイルを何段階も重ねると、どれが正しいのか分からなくなります。
改行を含む値が行を壊す
文字コードの次に来るのが、値の中に改行が入っている問題です。これは見た目に分かりにくく、取り込んだあとに「行数が合わない」という形で気づくことが多いので、事前に対処しておく価値があります。
なぜ行が増えるのか
CSVは、1行が1件を表す形式です。ところが備考欄や説明欄には、箇条書きが改行入りで書かれていることがよくあります。この改行がそのまま出力されると、1件のはずのデータが複数行に分かれて見えます。
この問題には正しい対処法が決まっています。値を引用符で囲むことです。引用符で囲まれた中の改行は、行の区切りではなく値の一部として扱う、という取り決めがあります。表計算ソフトの書き出し機能も、取り込む側の道具も、ほとんどがこの取り決めに従っています。だから、素直に書き出して素直に取り込むぶんには壊れません。
壊れるのは、途中で人が手を加えたときです。テキストエディタで開いて一部を書き換えたとき、引用符を消してしまう。あるいは、値の中にもともと引用符が入っていて、そのエスケープが崩れる。値の中の引用符は2つ重ねるという取り決めがありますが、手作業ではここが崩れやすい。
壊れた行の見つけ方
取り込む前に、壊れていないかを確かめる方法があります。書き出したCSVを、表計算ソフトで新規に読み込み直してください。上書き保存はせず、読み込むだけです。行数が元と同じなら、引用符は正しく機能しています。行数が増えていたら、どこかで囲みが崩れています。
崩れている行を探すときは、いちばん右の列に何か入っている行を見ます。列がずれていると、本来空のはずの右端に文字が入ります。表計算ソフトで右端の列を並べ替えれば、ずれている行がまとまって出てきます。
事前の予防としていちばん確実なのは、書き出す前に改行を別の記号に置換しておくことです。表計算ソフトの置換で、改行の文字を「／」や「・」に変えてしまいます。読みやすさは少し落ちますが、行が壊れるリスクはゼロになります。備考欄が長文で、かつ移す先では説明文として1つの塊になるなら、この方法で困りません。逆に、改行の構造そのものを残したい場合は、置換せずに引用符の仕組みに任せて、取り込んだあとに数件を目で確かめる進め方にします。
もうひとつ、値の中にカンマが入っている場合も同じ理屈です。引用符で囲まれていれば問題ありません。囲みが崩れると、そこで列がずれます。金額に桁区切りのカンマを入れている列は特に危ないので、書き出す前に桁区切りを外しておくと安全です。
日付の書式が揃わない
日付は、移行でもっとも高い確率で問題が出る列です。理由は3つあります。書き方が何通りもあること、表計算ソフトが内部で日付を数値として持っていること、そして「日付ではない何か」が日付の列に書かれていることです。
書式のばらつきをどう畳むか
まず、書き方の違いです。年月日の区切りに斜線を使うか短い横線を使うか、月日を2桁で揃えるかどうか、年を4桁で書くか2桁で書くか、曜日を括弧で添えるかどうか。この程度の違いは機械で揃えられます。表計算ソフトの表示形式を、年4桁と月2桁と日2桁を短い横線でつないだ形に統一してから書き出せば、たいていの道具が受け付けます。この形は国際的な標準の書き方でもあり、迷ったらこれにしておけば外しません。
次に、表計算ソフトの内部の持ち方です。表計算ソフトは日付を、ある基準日からの通し番号として持っています。だから、書式の設定によっては書き出したCSVに「45901」のような数値が並びます。これを見て慌てる必要はなく、書き出す前に表示形式を日付にしておけば解決します。逆に、日付として認識されていないセル、つまり文字列として入力された日付は、表示形式を変えても変わりません。左寄せになっているセルが文字列、右寄せが日付というのが見分けの目安です。
日付ではない値をどうするか
問題は3つ目です。日付の列に「未定」「なるはや」「9月上旬」「先方確認後」が入っている場合、これは書式の問題ではありません。実務でよくあり、そして機械では直せません。
対処は2択です。ひとつは、日付として意味のあるものだけを日付にして、それ以外は空にする方法です。「9月上旬」を9月10日と決めて入れる、といった置き換えは、勝手に決めると後で困ります。もうひとつは、これらの言葉を別の場所に移す方法です。期限の列は空にして、説明文の側に「期限は先方確認後」と書き残します。情報は失われず、期限としては空になります。
実務では後者を勧めます。空の期限は「まだ決まっていない」という正しい状態を表しているからです。仮の日付を入れると、その日が来たときに遅れとして表示され、遅れていないものが遅れて見えます。この誤検知が数十件たまると、遅れの表示そのものが信用されなくなります。
時刻も確認してください。表計算ソフトで日付を入れたつもりが、内部では時刻を持っていることがあります。移す先が日付だけを扱う場合、時刻部分の切り捨てや繰り上がりで1日ずれることがあります。移行後に数件を目で確かめる対象として、期限の列は必ず入れておいてください。
空欄の意味は1種類ではない
空欄は、移行のときにいちばん軽く扱われて、いちばん後で問題になる箇所です。空欄には少なくとも3つの意味があり、どれなのかを決めないまま移すと、移した先で意味が変わります。
1つ目は「まだ決まっていない」です。期限が空なら、まだ期限を決めていない。担当が空なら、まだ誰にも振っていない。この空欄は、そのまま空で移すのが正しい扱いです。
2つ目は「この案件には関係がない」です。たとえば納品日の列があって、社内作業の行では常に空になっている場合がこれです。この空欄も空のまま移して構いませんが、対応表の段階で「そもそもこの列は一部の行にしか関係ない」と分かるので、移す先ではラベルで区別するといった別の設計が見えてきます。
3つ目は「入力されなかった」です。運用が回っていない列の空欄がこれで、いちばん多い。この空欄を空のまま移すと、新しい道具の上でも空のまま残り、しかも今度は目立ちます。板型の道具は空の項目を画面に出すので、埋まっていないことが常に見えます。ここで「移行に失敗した」という印象が生まれます。
対処としては、3つ目に該当する列は移さないか、移すなら移行の前に埋めるかを決めます。埋めるのは重い作業なので、現実的には移さない判断になることが多い。移さないと決めた列は、元のCSVを保管したうえで対応表に理由を書いておきます。
もうひとつ注意点があります。空欄とゼロと空白文字は違います。表計算ソフトで見ると同じに見える3つですが、CSVにすると別物です。半角の空白が1つ入っているセルは、機械から見れば空ではありません。移す先で必須項目のチェックに引っかからず、しかし表示は空という状態になります。書き出す前に、対象の列で空白文字だけの値を空に置換しておくと、この面倒がなくなります。
必須項目の扱いも先に確認してください。移す先が「カードの名前は必須」としている場合、名前の列が空の行は取り込みで弾かれます。1件でも弾かれると、取り込みが途中で止まる道具もあります。書き出したあと、名前にあたる列で空の行がないかを並べ替えで確かめて、あれば仮の名前を入れておきます。
担当者名の表記ゆれをどう畳むか
担当者の列は、表記ゆれがいちばん激しく出る列です。そして、移す先では「誰に割り当てるか」という重要な情報になるので、雑に移すと後で全件を手直しすることになります。
名寄せは機械ではなく人がやる
まず、その列に何種類の値が入っているかを数えます。重複を削除するだけで一覧が出ます。30人のチームなのに80種類の値が入っている、というのはよくあることです。差分は表記ゆれと、退職した人と、複数人が入った欄です。
この一覧を作ったら、横に「正しい名前」の欄を作って、人が埋めます。ここを機械でやろうとして、部分一致で寄せるような処理を書くのは勧めません。同姓の別人を1人にまとめてしまう事故が起きます。80種類なら、人が見て埋めても30分かかりません。埋めたら、元の表に対して置換をかけます。
正しい名前を何にするかも決めておきます。移す先の道具では、たいてい招待したアカウントの表示名かメールアドレスで人を特定します。だから、正しい名前はその道具に登録されている表示名か、メールアドレスに揃えるのが確実です。日本語の氏名で揃えたつもりが、道具の側ではローマ字の表示名になっていて全部一致しない、という食い違いは頻繁に起きます。移行の前に、メンバーの招待を済ませて、表示名の一覧を手元に置いてから作業してください。
1つの欄に2人以上いる行
「田中／佐藤」のように、1つの欄に複数の名前が入っている行があります。表計算ソフトでは自然にできてしまう書き方です。移す先が複数人の割り当てに対応していれば、区切り文字を道具の仕様に合わせるだけで済みます。対応していない場合は、主担当を1人決めて、もう1人は説明文に書き残すことになります。
ここで、そもそも複数人が入っているのはなぜかを一度考える価値があります。工程が違う2人が同じ行に乗っているなら、その行は本来2行に分けるべきです。移行は行の粒度を見直す機会でもあります。ただし、全件を見直すと移行が終わらないので、複数担当の行だけを抜き出して、その中で分けるべきものだけを分けるのが現実的です。
退職した人と外部の人
もう1つ、避けて通れないのが、いま在籍していない人の名前です。過去の完了案件の担当欄には、退職した人の名前が残っています。この人を移す先に招待するわけにはいきません。
対処は、完了済みの行をそもそも移さないか、担当を空にして説明文に元の担当者名を残すかのどちらかです。完了案件を移すかどうかは、後から検索する必要があるかで決めます。年度の実績を振り返る運用があるなら移す価値があり、無いなら元のファイルを保管しておくだけで足ります。
外部の協力者も同じ論点です。取引先の担当者を移す先のアカウントとして招待すると、そのぶんの人数枠を使い、見える範囲の設計も必要になります。人数で区切られる料金の考え方は料金に整理されているので、招待する人の範囲を決める前に一度見ておくと、移行後に想定外の人数になる事態を避けられます。
ステータスと優先度は言葉を減らしてから移す
状態と優先度の列は、移行のときに必ず整理が必要になります。表計算ソフトでは自由に書けるので言葉が増え続け、板型の道具では列やラベルとして固定されるからです。
まず、状態の値を一覧にして数えます。数えると、意味が同じ言葉が並んでいることに気づきます。「着手」「作業中」「進行中」「対応中」は同じ状態です。「保留」「ペンディング」「一時停止」も同じです。この重複を畳むだけで、種類はかなり減ります。
次に、残った状態を「板の列にするもの」と「ラベルにするもの」に分けます。板の列は、作業が前に進むにつれて左から右へ動く道筋です。だから、道筋の上にある状態だけを列にします。「未着手」「作業中」「確認中」「完了」のような並びです。
一方、「先方待ち」「保留」「差し戻し」は、道筋の途中で起きる状況であって、道筋そのものではありません。これを列にすると、板の列が横に増えすぎて、どこに何があるか分からなくなります。こうした状況はラベルで表すほうが扱いやすい。「作業中」の列にありながら「先方待ち」のラベルが付いている、という表し方ができます。
列は5つ前後が扱いやすい上限です。それを超えると、画面を横にスクロールしないと全体が見えなくなり、板を見渡せるという利点が薄れます。移行の準備で列を減らしておくと、移した直後の見え方が大きく変わります。
優先度も同じです。「高」「中」「低」の3段階で運用していたはずが、実際には「最優先」「急ぎ」「至急」「特急」が混ざっている表をよく見ます。これは段階が増えたのではなく、その都度の気分で書かれた結果です。移行の前に3段階へ畳んでください。段階が多いほど正確になるように見えますが、実際には使う人が迷い、結局は全部が上位に寄ります。
畳んだ結果は、対応表の「決めたこと」の欄に残します。移行後に「以前あった保留はどこへ行ったのか」と聞かれたとき、ラベルに変えたと説明できます。板の考え方や、どの単位で区切るのが素直かについてはできることに整理があるので、列とラベルの分け方を決めるときに参照すると判断が早くなります。
CSVでは移らないものを先に把握する
CSVは表の形をしたデータしか運べません。だから、いまの道具に入っている情報のうち、表の形になっていないものは移りません。ここを移行の前に把握しておかないと、移した直後に「あれが無い」という声が出ます。
移らないものの代表は次の4つです。
1つ目は添付ファイルです。CSVにはファイルの名前しか書けません。実体は別に運ぶ必要があります。運び方は、共有の保存領域にまとめて置いて、説明文にその場所を書くのが現実的です。ファイル数が多い場合は、移すのは進行中の案件の分だけにして、完了案件の添付は元の場所に残す割り切りをします。
2つ目はコメントややり取りの履歴です。1件のカードに何十件も付いたやり取りは、CSVの1つのセルには入りません。無理に入れると、改行を含む巨大な値になり、読めなくなります。過去のやり取りは元の道具に残す前提で移行の計画を立ててください。移行後しばらくは元の道具を読み取り用に残しておくのが安全です。
3つ目は変更の履歴です。誰がいつ状態を変えたかという記録は、表として書き出せる道具と書き出せない道具があり、書き出せても移す先が受け取れないことがほとんどです。実務では、履歴は移さないと決めて問題ありません。
4つ目は通知や自動化の設定です。これは移行というより作り直しになります。いまの道具で動いている自動処理が何をしているかを書き出しておいて、移す先で同じことができるかを確かめます。自動化と外部サービスとの連携を強く使っているチームでは、ここが移行判断の分かれ目になります。板1枚に集約する道具は、そこを主戦場にしていません。この点をどう考えるかはmonday.comとの比較に整理されています。自動化を軸に選ぶなら、そこを得意にしている道具のほうが合う場合があります。
ここまでを踏まえると、移行の計画は「全部を移す」ではなく「進行中のものを移し、終わったものは元に残す」という形になります。全件移行にこだわると、準備が長期化して移行そのものが実行されません。
移行の手順を通しで並べる
ここまでの内容を、実際に進める順番に並べ直します。
第1段階から第3段階：決めて、書き出して、確かめる
第1段階は、移す範囲を決めることです。進行中の案件だけか、今年度の分か、全件か。範囲が決まると作業量が決まります。範囲が広いほど良いということはありません。
第2段階は、対応表を作ることです。いまの列を並べて、移す先の置き場所、値の種類、ばらつき、空欄の数、決めたことを埋めます。この段階で関係者に確認が必要なものが出るので、確認を投げます。
第3段階は、書き出しです。文字コードを指定して保存し、素朴なテキストエディタで開いて日本語が読めるかを確かめます。同時に、この書き出したファイルを元データとして日付付きで保管します。
第4段階から第7段階：整えて、試して、本番に入れて、確かめる
第4段階は、整形です。日付の書式を揃える。担当者名を正しい名前に置換する。状態と優先度を決めた値に置換する。空白文字だけの値を空にする。必要なら改行を置換する。この作業は元データのコピーに対して行い、元データには手を触れません。
第5段階は、試し移行です。ここを飛ばさないでください。全件をいきなり入れず、20件ほどを抜き出して取り込みます。抜き出すときは、普通の行だけでなく、期限が空の行、担当が複数の行、備考が長い行、状態が珍しい値の行を意図的に混ぜます。問題が起きる行を先に通すのが試し移行の目的です。
試し移行の結果は、画面を目で見て確かめます。件数が合っているか。日付が1日ずれていないか。担当者が正しい人に割り当たっているか。改行入りの備考が読める形で入っているか。ここで見つかった不具合を第4段階に戻って直し、もう一度試します。2回から3回繰り返すのが普通です。
第6段階は、本番の取り込みです。試し移行で入れた分は先に消してから入れます。消し忘れると重複します。取り込みが終わったら、件数を数えて元と一致するかを確かめます。
第7段階は、切り替えの宣言です。ここが実は最重要です。「今日からこちらに書いてください」と明確に言い、元の表を編集できない状態にします。読み取り専用にするか、名前に「参照用」と付けて分かるようにします。この処置をしないと、両方に書かれる期間が生まれ、どちらが正しいのか誰にも分からなくなります。移行が失敗する原因の多くは、データではなくこの宣言をしなかったことにあります。
なお、道具によっては特定のサービスからの取り込みが自動化されていることがあります。取り込み元がその条件に当てはまるなら、CSVを経由せずに済むぶん、ここまでの整形作業の大半が不要になります。どのサービスから自動で取り込めるのか、その場合に何が移って何が移らないのかはTrelloからの移行に書かれています。自動で取り込めるのは限られた1つのサービスからで、それ以外はCSVを経由することになるので、この記事の手順が必要になります。取り込みの前に、自分の状況がどちらなのかを確かめてください。
移したあとに使われ続けるか
移行が成功したかどうかは、取り込んだ件数では決まりません。2週間後に、全員が新しい場所を更新しているかで決まります。この観点で見ると、移行の設計は取り込みの前から始まっています。
使われなくなる原因は、移行の前と同じです。入力する項目が多い。何を書けばよいか迷う。書いても何も返ってこない。この3つは道具を替えても消えません。むしろ、移行のときに「せっかくだから項目を増やそう」と考えると、確実に悪化します。移行の直後は、いまより項目を減らして始めるくらいがちょうどよい。
もうひとつ、移行直後に必ず起きるのが「元の表のほうが見やすい」という声です。これは慣れの問題である場合と、本当に見えなくなっている場合があります。見分け方は、その人が何を見たかったのかを聞くことです。全件を一覧で見たかったのなら、板の形では確かに見にくく、一覧表示に切り替える必要があります。自分の担当分だけを見たかったのなら、絞り込みを教えれば解決します。この対話を移行の直後にやるかどうかで、定着が変わります。
そして、移行から1か月後に、対応表を見返してください。移した列のうち、実際に使われている列はどれか。空のままの列はどれか。ここで使われていない列を消すと、板が軽くなります。移行は1回で終わる作業ではなく、1か月後の見直しまでが1セットです。
現場でよく聞くのは、移行そのものは終わったのに、元の表を消せないまま両方が残っているという状態です。この状態が続くと、更新はどちらも中途半端になります。元の表を消す日を、移行の計画の中に最初から入れておいてください。
移行先を選ぶときに見る観点
最後に、CSVの手順そのものからは少し離れて、どの道具に移すかを決める段階の観点を整理します。移行の作業量は、移す先の受け皿の形でかなり変わるからです。
受け皿の種類が多い道具は、いまの列をほぼそのまま持ち込めます。そのかわり、持ち込んだあとに設計が必要になり、その設計を誰かが引き受けます。受け皿の種類が少ない道具は、移行の前に列を畳む作業が要りますが、畳んでしまえば設計の余地が少なく、そのぶん運用が始めやすい。どちらが良いかはチームによります。設計を引き受けられる人がいるなら前者、いないなら後者が現実的です。
いま使っている道具ごとに、比べるときの論点は変わります。板の形で進行を見てきたチームが移す場合、データの持ち方が近いので移行は比較的素直に進みます。この場合の論点は移行のしやすさより、料金の区切り方と、機能をどこで制限しているかに移ります。この整理はTrelloとの比較にあります。
工程や依存関係を細かく管理してきたチームでは、移行のときに持ち込めない情報が出ます。何を捨てて何を残すかの判断が要るので、Asanaとの比較で扱われている、管理の粒度をどこまで細かくするかという論点を先に見ておくと、対応表を作る段階で迷いが減ります。
自由に組める道具から移す場合は、そもそも列の設計が各チームで違うため、対応表の作業量がいちばん大きくなります。作り込みの自由と、その作り込みを維持する手間の関係はNotionとの比較に整理されています。
課題管理とコードの管理を近づけて運用してきたなら、Backlogとの比較を見てください。リポジトリの機能を含む道具から、含まない道具へ移すと、その部分は別の場所に分かれます。コードまで1か所にまとめたいなら、含む側に残るのが素直な判断です。
日本語で作られた板型の道具どうしを見比べるなら、Jootoとの比較があります。似た方向の道具の違いは、機能の一覧よりも、料金の区切り方と実際の画面に出ます。
どこから見るか決めきれない場合は、比較の一覧にまとめて並んでいるので、いま使っている道具の項目から入るのが早い。なお、料金や上限は変わるものなので、この記事に書かれた一般論ではなく、各サービスの公式のページで移行を検討する時点の内容を確かめてください。
区切り方の考え方として、機能の有無でプランを分ける道具と、そうでない道具があります。機能で絞らず、区切るのは人数とボードの数だけという区切り方をとる場合、移行の検討では「この機能を使うにはどのプランか」を調べる手間が減り、代わりに「何人を招待するか」だけを決めればよくなります。前の節で触れた、外部の協力者を招待するかどうかの判断が効いてくるのはここです。
一方で、板1枚に集約する形の道具には、はっきりした割り切りもあります。リポジトリの機能は持たず、自動化と外部サービスとの連携では勝負せず、画面は日本語のみで、自動で取り込めるのは限られたサービスからだけです。この割り切りが合わないチームは、別の道具を選ぶほうが幸せになります。移行の手順を丁寧に踏んでも、そもそも合っていない道具に移せば戻ることになるので、最初の見極めに時間をかける価値があります。
移行にあたって出やすい疑問、たとえば途中で人数を増やしたらどうなるか、データを取り出せるかといった点はよくある質問にまとめられています。移行を社内で提案する前に、聞かれそうな質問への答えを一通り持っておくと、話が一度で通ります。移行は道具の乗り換えである以上、いつでも出ていけることが確認できているかどうかが、決裁を通すときの説得力を左右します。
Q1. CSV移行の手順で最初にやるべきことは何ですか？
書き出しではなく、対応表を1枚作ることです。いまの列名、移す先での置き場所、値の種類、値のばらつきの数、空欄の数、決めたことの6欄を並べます。この段階で「入る場所がない列」と「関係者に確認が必要な列」が浮かび上がるので、手を動かす前に判断を済ませられます。移行の失敗の多くは、判断しながら作業した結果です。
Q2. CSVを取り込むと文字化けします。どう直せばよいですか？
書き出す側で文字コードを明示的に指定して保存し直してください。多くの道具は世界標準の文字コードを求めます。保存したファイルは、表計算ソフトではなくメモ帳のような素朴なテキストエディタで開いて日本語が読めるかを確かめます。列名は合っているのに存在しないと言われる場合は、ファイル先頭の見えない目印が原因です。
Q3. 期限の欄に「未定」や「なるはや」と書かれた行はどう移せばよいですか？
期限の列は空にして、その言葉は説明文の側に書き残してください。仮の日付を入れると、その日が来たときに遅れとして表示され、遅れていないものが遅れて見えます。この誤検知が数十件たまると、遅れの表示そのものが信用されなくなります。空欄は「まだ決まっていない」という正しい状態を表しています。
Q4. 移行するとき、全件を移すべきですか？
進行中の案件を移し、完了した案件は元のファイルを保管して残す進め方が現実的です。全件にこだわると準備が長期化し、移行そのものが実行されません。添付ファイル、過去のやり取り、変更の履歴はCSVでは運べないため、移行後しばらくは元の道具を読み取り用に残しておくと安全です。