kintone担当者の引き継ぎ、何を残せばいい？

22 時間前
読了時間: 6分

「アプリの一覧と操作マニュアルは渡した。でも、後任からの質問が止まらない。」

kintoneの引き継ぎを考えるとき、こんな場面を想像してみてください。入力方法は分かっても、「この項目は変更してよいのか」「エラーが出たら誰に相談するのか」が分からなければ、日々の運用で手が止まってしまいます。

引き継ぎで残したいのは、操作手順に加えて、業務の目的、設定の理由、困ったときの確認先です。この記事では、後任が運用を続けるために整理しておきたい情報を6つにまとめます。

1．何のために、誰が使うアプリなのか

まずは、アプリの名前とURLに「業務の説明」を添えましょう。アプリ名だけでは、使われ方や重要度までは伝わりません。

アプリ名・URL・アプリID
目的と対象業務
利用する部署・担当者、業務上の責任者
使うタイミングと、止まると困る業務
設定を管理する人と問い合わせ先

例えば「案件管理」だけでなく、「営業担当が商談後に更新し、営業責任者が毎週月曜の会議で受注見込みを確認する」と書くと、利用場面が具体的になります。

アプリが多い場合は、毎日使うもの、締め処理に関わるもの、外部サービスと連携するものから整理すると進めやすくなります。

2．業務の流れと例外対応

通常の入力手順に加えて、誰から誰へ仕事が渡るのかを残します。プロセス管理を使っているなら、各ステータスの業務上の意味と、次に対応する人を説明しましょう。

登録から完了までの流れ
承認・差し戻し・取り消しの扱い
担当者が不在のときの対応
月末・年度末などに必要な作業
入力ミスや重複登録があったときの修正手順

画面のスクリーンショットだけでなく、「どんな場合にこの操作をするか」を一言添えるのがポイントです。普段と違うケースほど、前任者の頭の中に対応方法が残っていることがあります。

3．設定の内容と、その理由

フィールドや通知、アクセス権の設定については、「現在どうなっているか」と「なぜそうしたか」をセットで残します。

例えば「受注確定後は営業担当が金額を変更しない運用」とだけ書くより、「請求額との不一致を防ぐため。修正が必要な場合は経理担当へ依頼する」と添えると、後任が変更を検討するときの判断材料になります。

重要なフィールドの用途と入力ルール
計算や集計の前提
アクセス権を分けている理由
通知の条件と送信先を決めた理由
変更前に確認が必要な設定

すべての設定を文章に書き直す必要はありません。設定画面だけでは読み取れない背景や、間違えると影響が大きい箇所を優先しましょう。

4．ほかのアプリ・外部サービスとのつながり

アプリ単体の説明では、連携先への影響が見えにくくなります。関連するアプリや外部サービスを洗い出し、「どのデータが、どこへ、いつ渡るか」を整理します。

参照・転記するアプリと対象項目
利用中のプラグインやカスタマイズの目的
JavaScript・CSSの元ファイルの保管先と変更履歴
外部連携の実行タイミングと管理担当
契約・更新の確認先、障害時の問い合わせ先

「顧客マスター → 案件管理 → 請求処理」のように関係を書き出し、矢印ごとに受け渡す情報と方法を添えると、変更前に確認すべき範囲が分かりやすくなります。

図：アプリ間のつながり（例）

顧客マスター

顧客情報を管理

↓ 顧客情報を参照・転記

案件管理

商談・受注情報を管理

↓ 請求に必要な情報を受け渡す

請求処理

請求内容を確認・処理

※構成の一例です。実際の連携方法・タイミング・担当者を矢印ごとに記録します。

認証情報については、パスワードやAPIトークンの値を引き継ぎ資料へ直接貼り付けず、社内で定めた保管先、管理責任者、利用目的、更新手順を記載します。

5．日常の管理作業とトラブル時の確認先

後任が困るのは、アプリを変更するときだけではありません。「毎月誰かが手作業で行っていた処理」が抜けないよう、定期作業も一覧にしましょう。

日次・月次・年次の作業と実施時期
実行結果を確認する場所と正常な状態の目安
よくあるエラーと、最初に確認する箇所
再実行してよい条件と、重複処理を避ける注意点
復旧を依頼する窓口と、その際に伝える情報

問い合わせ時に必要な「発生日時、対象アプリ、対象レコード、操作内容、エラー表示」を決めておくと、状況を伝えやすくなります。ログや画面を共有する際は、共有先に応じて個人情報や認証情報が含まれていないか確認しましょう。

6．未対応の課題と、これまでの変更履歴

引き継ぎ資料には、完成した仕組みだけでなく、保留中のことも残しておきます。

現在分かっている不具合と回避方法
利用者から受けている改善要望
対応の優先順位と判断した理由
過去の主な変更内容・変更日・確認した人
今後見直す予定の時期

「検討したが採用しなかった案」とその理由も、繰り返し議論しそうなものは残しておくと役立ちます。未確認の情報は推測で埋めず、「未確認」と確認先を記載しましょう。

記入例：まずは1アプリ分を整理する

以下は架空の「案件管理アプリ」の記入例です。自社の業務に合わせて項目を調整してください。

目的：商談状況と受注見込みの共有
アプリURL・ID：対象アプリのURL・IDを記載
利用者：営業部。商談後に担当者が更新
業務責任者／設定管理者：営業責任者／情報システム担当
重要な運用：受注確定後の金額修正は経理へ相談
設定の理由：営業と経理で扱う金額の不一致を防ぐため
関連アプリ：顧客マスター、請求管理。受け渡す項目と方法は連携資料に記載
定期作業：毎週月曜の会議前に未更新案件を確認
障害時：対象レコードとエラー表示を確認し、情報システム担当へ連絡
資料の保管先：社内共有フォルダーの「案件管理／運用資料」
未対応の課題：失注理由の選択肢を見直し予定。営業責任者へ確認
最終確認日・確認者：確認した日付と担当者名を記載

引き継ぎは、後任が実際に確認して完了にする

資料を渡したら、後任に読んでもらいながら、代表的な作業を一緒に確認します。特に、資料の閲覧権限と実際の管理作業に必要な権限は分けて確認しましょう。アプリの設定変更とJavaScript・CSSのカスタマイズでは、必要な管理権限が異なるためです。詳しくはkintone公式ヘルプ「ユーザーがアプリでできる操作」で確認できます。

図：引き継ぎを進める4ステップ

① 情報を整理する

目的・設定の理由・確認先

↓

② 後任と一緒に確認する

通常作業と例外対応

↓

③ 後任が実際に確かめる

操作・権限・問い合わせ先

↓

④ 資料を更新する

確認で分かった不足を追記

引き継ぎ完了前のチェックリスト

対象アプリと資料の保管先を開ける
通常の作業と例外時の対応を説明できる
必要な管理画面を開ける
変更前に確認すべき連携先が分かる
定期作業の実施時期と担当者が決まっている
困ったときの連絡先と未対応の課題が分かる

更新や承認などデータに影響する操作は、テスト用の環境・データや、合意した確認方法で実施します。

最初から立派なマニュアルを作るより、まずは重要なアプリを1つ選び、「目的」「設定の理由」「困ったときの確認先」を書き出してみてください。その記録を日々の変更に合わせて更新していけば、次の引き継ぎでも使える運用資料になります。