公開日：2025-01-28
こんにちは、システム開発グループの田邊です。
皆さんはkintoneへデータ移行をされた事はありますか？
kintoneでシステムを再構築した場合、旧システムからデータ移行される事が多いですよね。
昨年、掲載させていただいたトークネット様の再構築の事例は、
弊社のSI案件の中では大規模プロジェクトであり、初期構築に約1年半をかけました。
データ移行では、なんと全アプリでトータル80万レコードを約30時間かけてデータ移行を行いました。
（大半が移行用バッチプログラムの実行時間です）
この貴重な経験を踏まえ、今回は、主にこれから初めてkintoneへデータ移行をされる方向けに
kintone特有のリスクや準備におけるポイントなどをご紹介したいと思います。
1.データ移行の必要性を検討する
「とりあえず全部のデータを移行したい」。
これはどなたでも最初に考えがちな事かと思います。
ただ、本当に全部の移行が必要かどうか一度踏みとどまって考えてみたほうがいいかもしれません。
「移行したけど使わなかった」なんてことになったら、データ移行にかけたコストがもったいないですよね。
最近の別の再構築プロジェクトの事例ではデータ移行自体が不要になりました。
以下の運用で問題なかったからです。
- 仕掛中や終わった案件レコードは、旧システムで運用
- 新規の案件は、新システムで運用
要件次第では、仕掛中のレコードだけ移行する方法もあります。
レコード数を減らせれば以下のようなデメリットも軽減できます。
- セキュリティ上の目的で保護が必要なデータが増える事
- レコード数が増える事による性能への影響（※）
再構築される機会に一度データの整理をしてみることをおすすめします。
（※）気になった方は、kintoneサインポストの性能上の考慮点を参照ください。
2.フィールド名はユニークにしておく
データ移行をする場合は、CSVインポートを利用される場合が多いかと思います。
突然ですが、以下のアプリにCSVでレコード更新をしたいとします。
以下のCSVで意図通り取込みができると思いますか？（CSVのフォーマットは問題ないと考えてください）
この例ではB列をお客様情報、C列を請求先に取り込みたいとします。
CSVインポートに慣れている方は分かるかと思いますが、
「取り込める場合と取り込めない場合がある」が正解です。
「ユニークにするためにフィールドコードに変える必要がある」、
と思われた方もいるかもしれませんが、CSVインポートではフィールドコードは使用できません。
この例ではアプリ設定で最初に項目として追加したのが請求先のほうだった場合、
取込み先が逆になっていた可能性があります。
どういう事か説明します。
さきほどのCSVで以下のように正しく登録できたとします。
次のように注文情報というグループを上側に追加してみました。フィールド名は他のグループと全て同じです。
どのような順番でCSVに入力すればよいか想像できますか？
答えは以下の通りです。
画面の項目の順番通りに入力すればよいというわけではないんですね！（※）。
いかがでしょうか。
このように列の順番を気にしながらCSVファイルを作成していたらいつかトラブルが起きそうですよね。
このようなトラブルを防ぐためにも、データ移行期間中だけでもフィールド名はユニークにしておく事をおすすめします。
（※）一見、フィールド名が同じでもアプリ設定で項目を追加した順に入力すれば問題なさそうにも見えます。
ただし、私が探してみた限りサイボウズさんの公式サイトではこの仕様についての情報はありませんでした。
今は内部的にそのような動きになっていても、変わる可能性がないとも言えないのでご注意ください。
3.CSVインポートで移行できないフィールドタイプについて
CSVインポート機能では、一部のフィールドタイプの項目は登録、更新ができません。
以下の項目もそうです。
- プロセス管理のステータス、作業者
とは言え、仕掛中の案件などのステータスが初期のステータスのままだと困りますよね。
トークネット様の事例では以下の2案を検討しました。
- 手作業でステータス更新する
- 移行用のバッチプログラムをフルスクラッチで作成する。
「え？手作業で?」と思われた方もいますが、
移行用のプログラムを作ろうと思ったらそれなりに開発コストがかかります。
手作業で登録するコストと比較した場合に
データ入力用のバイトさんを雇ったほうが安くなるかもしれません。
トークネット様の事例の場合、件数が多い事もあり移行用バッチプログラムを作成する事になりました。
４.データ移行における負荷のリスクを考える
皆さん、kintoneを使っている時に何か画面が重いな、とか感じた経験はありませんか？
これにはネットワークなど不確実性のある外部要因も多いのですが、想定可能な要因もあります。
例えば、定期的に特定のアプリに対してバッチ処理を行っている場合などです。
データ移行についても負荷を与える要因になる事があります。
また、データ移行と別業務のバッチ処理が重なってしまうと、予定よりデータ移行に時間がかかってしまうかもしれません。
これらのリスクを考慮して、事前にデータ移行の日時を各アプリ管理者と調整しておくことをおすすめします。
５.予期せぬネットワークの不調やサーバーの負荷に備える
kintoneはクラウドサービスである以上、
データ移行中に起きる外部要因のトラブルを想定しておいたほうがいい場合があります。
ほとんどのケースではここまで気にする必要はないかと思いますが、
夜間に移行プログラムやRPAなどを実行中のまま放置される場合は注意が必要です。
トークネット様の事例では
移行前のテストで夜間に移行用のプログラムが異常終了する問題が起きました。
状況から見てネットワークの不調かサイボウズさん側のサーバの負荷が要因ではないかと考えています。
結局、途中から再開しても不整合が起きないように移行プログラムを工夫して本番に備えました。
６.サイボウズさんに事前連絡を入れておいたほうが良いケースもある
kintoneではアプリごとに一日に実行できるAPIリクエスト数の制限があります。
契約ごとに違うので詳細はサイボウズさんのページをご確認ください。
サイボウズさんの制限値に関するページでは
「APIリクエスト数を減らすことが難しい場合はサポートまでご相談ください」
とあります。
APIリクエスト数を超過したからすぐにkintoneが使えなくなるような事はないと思いますが、
データ移行の日程が決まっており、一時的に超過する日が増えるようなことが想定される場合は、
事前に連絡を入れておいたほうが無難でしょう。
７.サイボウズさんのメンテに注意する
毎月第2日曜日、午前1時～午前7時（JST）に定期メンテナンスが行われています。
夜間もデータ移行を行う場合は事前に日程を調整しておいたほうが安心です。
まとめ
いかがでしょうか？ご参考になりましたら幸いです。
カスタマインのJobRunner等もご紹介したかったのですが、
私個人のデータ移行での実績がないので今回は省きました。
いずれ機会がありましたらご紹介させていただきます。
弊社のSIサービス「キミノマホロ」ではデータ移行支援に関するメニューもあります。
お困りの場合は一度問い合わせ頂ければと思います。
投稿者プロフィール
-
アールスリーでは古株のエンジニアです。
今まではAWSを扱った案件が多かったですが、最近はkintoneやCustomineのみの案件も徐々にさせて頂くようになりました。"
最新の投稿
kintone2025年1月28日kintoneへのデータ移行前に準備したほうがいいこと7選
kintone2020年9月7日プロセス管理に力を入れたアプリで起きた事
