kintone移行で失敗するのはなぜか？発注前に潰す5つの抜け

移行の失敗は、本番の日に突然生まれるわけではありません。発注書に「現行同等」とだけ書いた日、CSVを1つ出してデータ調査を終えた日、受入テストを開発会社へ任せた日に、すでに種が入っています。

この記事は、失敗談を並べるものではありません。手元にある提案書、見積書、移行計画書を開き、発注前または切り替え前に抜けを見つけるための記事です。見るのは5点。業務の目的、現行の作り込み、移すデータ、受入れと切り戻し、社内と委託先の役割です。

乗り換えなくていい条件は、計画書のどこで分かるのか？

5つの抜けを成果物で説明できないなら発注を急がず、kintoneを使いながら調査を続ける段階です。

提案書に新しい画面の絵はあるのに、現行アプリの一覧がない。見積書には「データ移行一式」とあるのに、添付ファイルの件数がない。切り替え日は決まっているのに、戻す判断を誰が下すかが書かれていない。こうした計画なら、乗り換えないほうが安全です。

反対に、次の5つが文書で確認できれば、移行を進める土台があります。

ここでいう「乗り換えなくていい」は、kintoneに問題がないという意味ではありません。調査不足のまま別の仕組みに移すより、今の環境を止めずに不足を埋めるほうが、後戻りできるという判断です。段階的に進める方法は、kintoneを捨てずに移行できるか？API連携から始める段階刷新で整理しています。

失敗パターンは、提案書のどの言葉に現れるのか？

「現行同等」「一式」「別途協議」という短い言葉に、対象・完了条件・追加変更の境目が隠れます。

曖昧な言葉があること自体は問題ではありません。調査前なら、決められない項目もあります。危ないのは、未確定だと明記せず、確定した見積のように扱うことです。

IPAの情報システム・モデル取引・契約書（第二版）は、ユーザー企業とITベンダーが契約時に、仕様、プロジェクト管理方法、検収方法について共通理解のもとで対話することを期待すると説明しています。見直しの論点には、双方のプロジェクトマネジメント義務と協力義務、複数契約の関係、再構築対応が含まれます。

契約書のひな形をそのまま使えば足りる、という話ではありません。自社の提案書で、誰が何を決め、何を渡し、何をもって終わりとするかを読める状態にすることが先です。

現行画面をそのまま作ると、なぜ目的が抜けるのか？

画面は入力の形しか示さず、その後の判断、例外処理、締め作業までは映していないからです。

たとえば営業担当が案件画面に受注日を入れた後、経理が月末に請求対象を選び、未回収だけをExcelへ出して確認しているとします。画面を写すだけなら受注日の欄は作れます。しかし、誰が請求対象を確定し、差し戻しをどう扱い、未回収をどこで追うかは残りません。

画面ごとに、次の4つを確認してください。

• この画面を開く人は、入力後に何を決めるのか
• 通常と違う案件が来たとき、誰へ渡すのか
• 日次、月次、年次で行う締め作業は何か
• この画面の数字を、次にどの帳票やシステムが使うのか

この答えが出ない項目は、新しい画面に置かない選択もあります。「今あるから残す」ではなく、「次の判断に使うから残す」と説明できる項目だけを要件にしてください。

JavaScriptやExcelの作業は、どう棚卸しするのか？

設定一覧だけで終えず、朝・月末・例外時に人が行う操作を、入力元と出力先まで追います。

cybozu.com共通管理者は、利用中のプラグインを一覧にできます。kintoneヘルプのプラグインの一覧をCSV形式でダウンロードするによると、一覧にはプラグインのID、名称、バージョン、説明、利用しているアプリのIDと名称が含まれます。ここを起点に、各アプリのJavaScript／CSS、Webhook、外部サービス連携を続けて確認します。

ただし、設定画面だけでは人の作業が残ります。午前9時に担当者がCSVを書き出し、共有フォルダのExcelへ貼り、赤くなった行だけを別部署へメールする。この一連のうち、kintoneに記録されるのはCSVを書き出すところまでです。

棚卸し表は、機能名ではなく操作で書きます。

アプリ名だけの棚卸しは、棚に置かれた箱を数えた状態です。箱から出して人が何をしているかまで追って、初めて移行対象が見えます。

データ移行を「読み込み」で終えると、何が残るのか？

添付・関連・履歴の扱いと、移行前後の照合、差分時に再実行する手順までが残ります。

kintoneヘルプのレコードのデータをファイルに書き出す際の注意事項では、標準のファイル書き出しで出力できないものとして、添付ファイル、関連レコード一覧、変更履歴を挙げています。閲覧権限のないレコードやフィールドも出力できず、書き出すファイルが100MBを超えると失敗すると記載されています。コメントはレコードとは別のCSVで出力できる一方、そのCSVをアプリへ読み込むことはできません。

つまり「CSVを移す」は、移行全体の一部です。アプリごとに、少なくとも次を決めます。

• 元の項目と新しい項目を結ぶ対応表
• 添付ファイル、コメント、変更履歴を残すか、保管だけするか
• 書き出しを行うアカウントと、その閲覧権限
• 移行前後で比べるレコード件数、金額合計、添付件数
• 差分が出たときにデータを戻し、同じ手順を再実行する方法

デジタル庁のDS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブックは、移行をシステム移行、データ移行、業務移行の3種類に分けています。データ移行では、元データ、実施方法、項目の対応、変換、クレンジングを検討対象にしています。CSVの投入結果だけでなく、移行後に人が業務を続けられるかまでが対象です。

データ量や添付の扱いで費用が変わる理由は、kintone移行の費用はいくらか？費目の分解と見積書の比べ方で扱っています。

移行判定の目安は、どの数字で決めるのか？

重大障害0件、照合差分0件、全量リハーサル1回以上を、発注時の出発線に置きます。

この3つは、株式会社ヘイグッド編集部が中小企業の移行計画を読むために置いた線引きです。法令やkintoneの公式基準ではありません。業務を止めたときの影響に合わせて、厳しくするか、例外を承認する手続きを加えてください。

同ガイドブックは、本番移行を始める「移行判定」と、新しい業務を始める「稼働判定」を分けています。移行判定の条件例には、計画したテストの消化、残る障害の対処方針、移行計画とリハーサル結果、切り戻し基準と手順、稼働後の運用準備が挙げられています。また、移行結果はレコード件数やハッシュ比較のような機械チェックで検証すると説明しています。

「予定日になったから移す」は判定ではありません。数字と証拠を見て、進む、延期する、戻すのどれかを責任者が選べる状態を作ります。

受入テストは、誰が何を確かめるのか？

実際の利用者が業務シナリオを通し、発注者が合否を決め、委託先は修正と証拠提出を担います。

開発会社が行うテストは、作った機能が設計どおり動くかを確かめます。受入テストで見るのは、納品された仕組みで自社の業務を最後まで実行できるかです。両者は同じではありません。

デジタル庁の同ガイドブックでは、受入テストは発注者が主体となり、実際の利用者が参加して、サービス・業務を円滑に実施できるか確認するものと説明しています。テストシナリオ、使用するデータ、合否判定基準は実施前にまとめ、日常業務だけでなく月次、年次、例外時の業務も扱います。

受入テストの1行は、操作名ではなく仕事の終わりまで書きます。「案件を登録できる」では足りません。「営業が受注案件を登録し、上長が承認し、経理が請求対象を確定し、差し戻された案件を営業が修正できる」までを1つのシナリオにします。月末の締め担当者が席に座り、普段の資料を横に置いて操作できる粒度です。

社内と委託先の役割は、どう分ければよいのか？

業務の決定と受入れは社内、設計・実装・技術検証は委託先とし、共同作業を別に置きます。

丸投げを防ぐには、「社内」「委託先」の2列だけでなく、「共同」の列を作ります。要件の確認、データ変換の承認、障害時の優先順位づけは、片方だけでは決められません。

IPAのモデル取引・契約書（第二版）が、プロジェクトマネジメント義務と協力義務を見直しの論点にしているのは、片方だけではプロジェクトが進まないためです。役割表には担当部署だけでなく、最終的に承認する人の氏名または役職を入れてください。

抜けた作業の費用は、見積書でどう見抜くのか？

「一式」を成果物と回数に分け、旧契約を残す月数も加えてから見積総額を正しく比べます。

見積書では、現状調査、データ移行、受入支援、移行リハーサル、切り戻し支援を別の行にします。データ移行なら「項目対応表1式、試行移行1回、本番移行1回、照合結果表1式」のように、何が残り、何回行うかまで書きます。回数を超えたときの単価も確認してください。

旧環境を残す費用もあります。サイボウズの料金ページによると、スタンダードコースは1ユーザーあたり月額1,800円（税抜）で、最小ユーザー数は10人です。スタンダードコースを10人で残すなら月額18,000円（税抜）で、3か月の並行稼働なら54,000円（税抜）になります。これは編集部による単純な掛け算で、オプションや契約形態は含みません。

安い見積が、必要な作業を少ない金額で行うとは限りません。受入支援とリハーサルが0円なのではなく、範囲に入っていないだけかもしれない。総額を見る前に、5つの抜けがどの行に含まれているかを確認します。

発注前の確認は、どの手順で進めるのか？

現行の操作から始め、データ、判定条件、役割、見積の順に同じ文書を揃えて発注します。

1. 現行業務を1日追う。 朝、月末、例外時に誰が何をしているかを、画面外のExcelやメールまで含めて記録します
2. 作り込みを一覧にする。 アプリ、JavaScript／CSS、プラグイン、Webhook、外部連携と、担当者の手作業を1枚に並べます
3. 移行データを決める。 項目対応、添付、コメント、変更履歴、保管だけするデータを分け、照合する数字を決めます
4. 受入れと切り戻しを先に書く。 業務シナリオ、合否、移行中止、切り戻し、稼働開始の条件を発注書へ入れます
5. 責任表を作る。 社内、委託先、共同の作業を分け、承認者と障害時の連絡順を決めます
6. 同じ資料で見積を取り直す。 各社へ1から5までを同じ形で渡し、成果物、回数、対象外を横に並べます

途中で対象が広すぎると分かったら、全面移行へ戻る必要はありません。kintoneの限界はどこか？レコード数・連携・改修費で判断するへ戻り、困っている業務だけを切り出してください。

手元の提案書に5つの抜けがあるか一緒に確認したい場合は、お問い合わせからご相談ください。製品選びの前に、成果物と判断条件が読める状態へ整えます。