kintoneを残す段階移行

「kintoneをやめる」と決めなくても、移行は始められます。実際には、全部を一度に切り替える計画より、つなぎながら少しずつ移すほうが、止められない業務を抱えた会社には現実的です。

ただし段階を分ければ楽になる、という話ではありません。段階を分けると、つないでいる期間の設計と、費用が重なる期間の扱いという別の仕事が増えます。この記事では、その2つを含めて手順を並べます。

いま乗り換えなくていい条件は何か？

kintoneで完結している業務があり、外とデータを行き来させる必要がないなら、その範囲は残して構いません。

段階刷新の出発点は「どこを残すか」を決めることです。次に当てはまる業務は、移す対象から外して考えてください。

• 入力と参照がkintoneの中で完結し、他のシステムに同じ数字を持っていない
• 使っているのが特定の部署だけで、他部署の処理を止めていない
• 標準機能の範囲で運用でき、改修の依頼が発生していない
• 紙やメールで受けていた業務を置き換えたもので、置き換え自体はうまくいっている

これらを無理に移すと、移行の範囲だけが広がって、確認する項目が増えます。段階刷新の価値は「移さない範囲を明確にできること」にあります。移す理由が説明できない業務は、そのまま残すのが原則です。

連携の方法は、何がどう違うのか？

3つあります。kintoneから外へ知らせるWebhook、外から読み書きするREST API、人が操作するCSVです。

それぞれ、きっかけを作る側と、失敗したときの扱いが違います。

Webhookで何が送られるかは公表されています。kintoneヘルプのWebhook通知内容によると、レコードの追加はADD_RECORD、編集はUPDATE_RECORD、ステータスの変更はUPDATE_STATUS、削除はDELETE_RECORD、コメントの書き込みはADD_RECORD_COMMENTという種別で、JSON形式の通知が送信されます。レコードの追加・編集・ステータス変更の通知には、レコードの情報を表すオブジェクトとレコードのURLが含まれます。

一方、削除の通知に含まれるのは、アプリの情報、レコード番号、削除したユーザー、削除日時です。削除される前のレコードの中身は含まれません。外部システム側で削除を反映する設計にする場合、この違いが効いてきます。

REST APIの枠は制限値一覧に記載があります。kintoneヘルプの制限値一覧によると、REST APIの同時アクセス数は1つのドメインにつき100までで、上限を超えるとHTTPステータスコードが429のレスポンスが返ります。1日に実行できるAPIリクエスト数は契約コースによって異なり、日本時刻で毎日午前9時にリセットされます。リクエストボディのサイズは50MBまでです。

段階を分ける進め方は？

4段階です。参照だけつなぐ、二重入力をなくす、機能を切り出す、必要なら移す、の順に進めます。

1. 参照だけをつなぐ。 外部システムのデータを、kintoneの画面から見られるようにします。この段階では書き込みを行わないため、失敗しても既存の業務は止まりません。連携の仕組みが安定して動くかを、実データで確かめる期間として使います
2. 二重入力をなくす。 同じ数字を両方に手入力している箇所を特定し、片側を自動で埋めます。どちらを入力元にするかを業務ごとに決め、もう片方は入力できないようにします。ここで初めて、現場の手が空きます
3. 機能を切り出す。 在庫、原価、請求のように、計算の型が決まっている処理を外部システムへ移します。kintoneは入力と参照の窓口として残します。切り出す単位は、部署ではなく処理の単位で決めてください
4. 必要なら残りを移す。 ここまで進めた時点で、kintoneに残っているのは標準機能で足りている業務です。移す理由が説明できないなら、移さないという結論で構いません

多くの会社は3番目で止まります。そして、止まって問題ない状態です。段階刷新を「全部移すまでの途中経過」と定義すると、3番目で止まったことが失敗に見えてしまいます。各段階の終わりに、次へ進む理由を書き出して判断してください。

なお、どの段階でも共通して必要になるのは、現行の仕様を確かめる作業です。IPAはシステム再構築を成功に導くユーザガイド 第2版を公開しており、その概要では、システム再構築の失敗の原因として、時間が経過して不明瞭になっている現行システムの仕様があいまいなまま新システムの開発に着手してしまうことが挙げられています。同書は再構築手法の選択と計画策定を扱う構成になっています。kintoneは設定画面で仕様を確認できる分だけ有利ですが、JavaScriptやプラグインで作り込んだ部分は同じ問題を抱えます。

標準のCSV移行だけでは引き継げないものは何か？

添付ファイル、関連レコード一覧、変更履歴は、標準のCSV入出力だけではそのまま移せません。

kintoneの標準ファイル入出力はCSV形式で行います。kintoneヘルプの入出力できるデータの一覧によると、フィールドの種類ごとに入出力の可否が決まっており、次のような違いがあります。

同じページには、作成者・作成日時・更新者・更新日時は新規登録するレコードの場合のみファイルからデータを入力でき、その際はファイル読み込みの権限だけでなくアプリの管理権限が必要だと記載されています。

移行計画で見落としやすいのは、変更履歴とコメントです。「誰がいつ何を直したか」は、監査や取引先とのやり取りで参照されることがあります。コメントは出力できますが、移行先で同じ形に戻せるとは限りません。移す前に、これらを移行対象とするのか、kintoneを参照専用で残して過去分を見られるようにするのかを決めてください。

添付ファイルはCSVと別の工程で取得・登録する方法を設計します。関連レコード一覧は表示条件を移行先で作り直す必要があり、変更履歴を同じ形で再現できない場合は、kintoneを参照専用で残す案も比較します。制限値一覧では添付ファイルは1ファイル1GBまでとされており、量が多い場合は移行作業そのものの期間に影響します。ファイル数と合計サイズを、計画の早い段階で数えておいてください。

並行稼働と切り戻しは、どう決めておくのか？

先に3つを決めます。並行させる範囲、どちらを正とするか、そして元に戻す条件です。

並行稼働は「両方動かしておけば安心」という状態ではありません。両方に数字がある期間は、どちらを見て判断するかが決まっていないと、現場が混乱します。次の順で決めてください。

並行させる範囲を決める。 全業務ではなく、切り替えた処理だけを並行させます。範囲が広いほど、突き合わせの手間が期間中ずっと続きます。

どちらを正とするかを業務ごとに決める。 並行期間中も、正は片方だけです。もう片方は確認用と位置づけ、食い違ったときは正の側に合わせる、と先に決めておきます。両方を正にすると、どちらに合わせるかを毎回議論することになります。

元に戻す条件を数えられる形で書く。 「うまくいかなかったら戻す」では判断できません。突き合わせで一致しないレコードの件数、業務が止まった時間、現場から上がった不具合の件数のように、数えられる指標で条件を書きます。誰が戻す判断をするかも同時に決めます。

切り戻しは、期間が長くなるほど難しくなります。新しい側にだけ入ったデータが積み上がるためです。切り戻しを現実的な選択肢として残したいなら、並行期間を短く区切り、区切りごとに続行するか戻すかを判断する形にしてください。

停止時間は、どのくらい見ておくのか？

前提を置かずに答えられる数字はありません。データ量、添付ファイル、切り替え範囲の3つで変わります。

移行の停止時間を一律に示すことはできません。同じ業務でも、次の前提が違えば結果が変わります。

制限値一覧には、CSV・TSV・TXTファイルの読み込みが1ファイル100MBまで・10万行まで、Excelファイルの読み込みが1ファイル1MBまで・1,000行・500列まで、ファイルの書き出しが1ファイル100MBまでと記載されています。10万行は読み込み側の制限で、書き出し側に公表されているのは100MBの上限です。移行先へ出す場合は書き出し容量を、kintoneへ戻す切り戻し手順では容量と行数の両方を確認してください。

見積を受け取ったときは、停止時間そのものより「どの前提で計算したか」を確認してください。前提が書かれていない見積は、比較の材料になりません。

障害時の責任は、どこで分かれるのか？

3か所で分かれます。kintone側、連携の仕組み、移行先システムのそれぞれに担い手を置きます。

段階刷新では、動いているものが増えるぶん、止まったときに「どこが原因か」がすぐには分かりません。稼働前に、次の切り分けと連絡先を決めておいてください。

「連携の仕組み」は、契約上の担い手が決まっていないことが多い区分です。kintone側のベンダーと移行先のベンダーが別なら、どちらが連携部分を持つかを契約時に明記してください。ここが空席だと、障害のたびに双方が相手側の問題だと主張する状態になります。

あわせて、どこまでを誰が復旧させるかも決めます。データの不整合が起きたとき、原因調査は連携の担い手、データの修正はkintone側の管理者、というように役割を分けておくと、復旧の手が止まりません。

次の段階へ進む判断の目安は？

業務ごとに合格条件と観察期間を決め、突き合わせ、二重入力、問い合わせの実績で判定します。

「30日一致したら次へ進む」という共通基準はありません。月末締めがある業務と毎日完結する業務では、必要な観察期間が違うためです。稼働前に、通常処理と締め処理を少なくとも1回ずつ含む観察期間を決め、次の欄を自社の数値で埋めます。

満たしていない段階で先へ進むと、後の段階でまとめて問題が出ます。特に2段階目の「二重入力をなくす」が中途半端なまま3段階目へ進むと、切り出した処理の入力元が定まらず、数字が合わなくなります。

どこまで移すべきかを、改修頻度や年間の総コストの側から確かめたい場合は、kintoneの限界はどこか？レコード数・連携・改修費で判断するを参照してください。在庫と原価を先に切り出すかどうかは、在庫・原価管理をkintoneで続けられるか？向く条件と限界で扱っています。

契約が重なる期間の費用はどうなるのか？

重なります。kintoneの契約はすぐには軽くできず、移行先の費用が先に立ち上がります。

サイボウズのライセンスに関するご案内（クラウド版）によると、月額サービスの最低利用期間は1か月で、契約ユーザー数の追加は任意のタイミングで行えますが、削減は新規発注月およびユーザー数を追加した月を除いて申し込め、変更発注日の翌月1日から適用されます。年額サービスでは、サービス期間の途中にできるのは契約ユーザー数の追加とコースのアップグレードのみで、削減とダウングレードは契約更新時に限られ、期間途中の解約はできないと記載されています。

つまり、年額契約のまま段階刷新を進める場合、kintoneの費用は契約更新日まで下がりません。移行先の費用が立ち上がるタイミングと、kintoneの契約更新日が離れているほど、重なる期間は長くなります。計画を作るときは、更新日を先に確認してください。

金額の目安も同じページから確認できます。サイボウズの料金ページでは、スタンダードコースが1ユーザーあたり月額1,800円（税抜）、年額契約では1ユーザーあたり21,600円（税抜）と公表されています。最小ユーザー数は10ユーザーです。同じ案内には、年額サービスの期間途中にユーザー数を追加する場合の費用が「サービス期間の終了日までの残月数 × 月額サービスのライセンス料金 × 追加ユーザー数」で計算されることも示されています。

重なる期間を短くする方法は2つあります。1つは、切り替えの時期を契約更新日に合わせること。もう1つは、移行先の費用が段階的に立ち上がる契約にすることです。どちらも、計画の初期でなければ選べません。移行の見積を取る前に、kintone側の契約形態と更新日を確認しておいてください。

判断の入口に戻る場合は、kintoneから乗り換えるべきか？限界・費用・移行方法を判断するを参照してください。自社でどこまで段階を分けられるか整理したい場合は、お問い合わせからご相談ください。