kintone運用保守の外注範囲と費用｜見積で確認する点

「あのアプリ、誰が直せるんだっけ」。kintoneを作って1年ほど経つと、こんな会話が出てきます。作った担当者が異動した、頼んだ開発会社と連絡が取りにくくなった、現場から「項目を1つ足したい」と言われたが触れる人がいない。保守の線引きを決めないまま動かし続けると、こうした場面が続きます。

この記事は、運用保守の作業を4つに分けて、内製と外注のどちらに置くかを判断するための整理です。費用の見方と、見積書で確認する点もまとめました。上司に「この保守契約はなぜこの範囲と金額なのか」を説明する材料として使ってください。

作って終わりにならない：kintoneの運用保守で起きること

kintone（サイボウズ株式会社のクラウド業務アプリ作成サービス）は、現場の担当者がアプリを組み替えながら育てていく使い方ができます。そのぶん、作った後に手を入れる場面が出てきます。たとえば次のような場面です。

• 現場から「承認の担当者が変わったので設定を直してほしい」と頼まれる
• 「先週から一覧が開かない」という問い合わせが、担当者の席に直接届く
• 担当者が異動し、フィールドの意味や、アプリ同士のつながりが分かる人がいなくなる

建設業の例で考えてみます。工事台帳のアプリを、現場監督の1人が夜な夜な整えて作ったとします。使い始めて半年後に、その人が別の現場に移りました。残ったのは「この項目はなぜ入力必須なのか」「この計算式は何を足しているのか」が分からない台帳です。誰も触れないまま、新しい工事が増えるたびに運用でカバーする。こうして「あの人しか分からない」状態ができあがります。

運用保守を考えるとは、こうした場面が来る前に「誰が、どこまで、何を担うか」を決めておくことです。

保守の作業を4つに分ける

「保守」と一言で言っても、中身はまったく違う作業が混ざっています。まず4つに分けます。

作業	内容の例	起きるタイミング
日常運用	ユーザーの追加・停止、アクセス権の見直し、使い方の問い合わせ対応	毎週〜毎月
改修	項目の追加、一覧の変更、承認フローの見直し、連携の追加	業務が変わったとき
障害対応	「動かない」「表示が崩れた」の原因調査と復旧	突発
バージョンアップ対応	kintoneの更新で、カスタマイズやプラグインに影響が出ないかの確認	更新の案内が出たとき

この4つは、必要なスキルも、発生の頻度も、頼む相手の選び方も違います。「保守契約」とだけ書かれた見積書を見ても、どれを含んでいるのか読み取れないことがあります。4つに分けておくと、見積書の項目と突き合わせて確認できます。

内製で持てる範囲と、外注に出す範囲

作業ごとに、内製と外注の目安を考えます。判断軸は「社内に、その作業ができる人がいるか」と「その人が異動・退職しても回るか」の2つです。

日常運用は、内製で持ちやすい

ユーザーの追加や停止、アクセス権の見直しは、画面の操作で行える管理作業です。kintoneの管理者には種類があり、公式ヘルプでは次のように整理されています。

管理者の種類	範囲
cybozu.com共通管理者	すべての権限
kintoneシステム管理者	「システムの管理」権限で指定
アプリ管理者	個別アプリの設定・管理
スペース管理者	特定スペースの管理

「システムの管理」権限では、アプリ・スペース作成権限の設定、テンプレート作成、全体カスタマイズ、プラグイン登録ができます。「アプリ管理」権限はアプリ単位の設定操作です。つまり、全体に及ぶ権限と、アプリ単位の権限を分けて渡せます。社内の担当者には日常運用に必要な範囲だけ、外部の保守担当者にはアプリ単位だけ、といった切り分けが可能です。保守担当者に最初から全権限を渡さなくても、頼める作業は多くあります。

なお、公式の技術サポートの対象は共通管理者とされています。電話サポートはライトコースでは使えず、ライトの窓口はチャットとメールです（公式の料金ページより）。これはサービスの標準サポートであり、自社のアプリの改修や、作り込んだカスタマイズの面倒まで見てもらえるという意味ではありません。公式サポートがカスタマイズやプラグインの不具合までどこまで見るかは、今回は確認できていません。「サポートに入っているから保守は不要」とは考えないほうが安全です。

改修は、「直すと何が変わるか」を知っている人がいるかで分ける

項目を1つ足す程度なら、アプリ管理者が自分で直せることも多いはずです。一方、運用開始後の設定変更は、見た目より手がかかる場合があります。たとえばプロセス管理の作業者を変えるとき、公式ヘルプには次の注意があります。

• 設定を変えても、作成済みレコードの作業者は変わらない。必要ならアプリ管理者が個別に対応する
• 利用停止したユーザーが作業者のままだと、そのレコードのステータスを変更できない
• 作業者の指定方法を変えるとき、そのステータスに作業者指定済みのレコードがあると変更できない

「担当者が異動したので作業者を差し替えるだけ」のつもりが、承認待ちのレコードが動かなくなる。こういう実害は、設定画面を見ただけでは気づきにくいものです。さらに、プロセス管理を無効にすると、既存レコードのステータスと変更履歴は残りますが、「作業者」を条件にした絞り込みとアクセス権の設定は削除されます。改修を内製で持つなら、こうした「直すと何が変わるか」を知っている人が必要です。

障害対応とバージョンアップ対応は、外注を検討しやすい

JavaScriptやプラグインを使ったカスタマイズは、kintoneの更新の影響を受けることがあります。公式のコーディングガイドラインでは、要素のidやclass属性の値は予告なく変更されること、DOM構造も変わることがあること、そのため製品のDOM構造を直接操作せずkintone JavaScript APIを使うことが示されています。更新でカスタマイズが動かなくなる可能性にも触れられています。

実例もあります。2022年9月の公式告知「フロントエンド基盤刷新」では、APIとして提供されていない要素に依存する実装は、プラグインの設定画面の表示が崩れるなどの影響を受ける可能性があるとされました。プラグイン開発者には、設定画面が正しく表示されるか、画面操作と設定の保存が動くかの確認が求められています。

こうした影響を見つけるには、更新情報を見て、影響を受けうるカスタマイズを洗い出す作業が要ります。cybozu developer networkの「更新情報」には、API更新情報などが公開日つきで載ります。これを定期的に確認することが入口です。社内にJavaScriptを読める人がいなければ、この作業は外注に寄せるほうが安定します。

状況	判断の目安
JavaScript・プラグインをほぼ使っていない	日常運用と軽い改修は内製、障害時の相談先だけ確保
カスタマイズやプラグインを多く使っている	バージョンアップ対応と障害対応は外注を検討
社内に担当者がいない・1人しかいない	4つとも外注、または外注と内製の分担を明文化

保守契約の形と費用の決まり方

外注する場合、契約の形は大きく3つの考え方があります。

形	考え方	向いている場面
月額	毎月一定額で、あらかじめ決めた範囲を見てもらう	問い合わせや軽微な修正が毎月ある
都度	依頼のたびに見積り、作業ごとに払う	改修の頻度が低い、まず様子を見たい
時間数	月あたりの対応時間を決めて、その範囲で依頼する	依頼の量は読めないが上限は決めたい

どの形でも、費用を左右する要素は似ています。対応範囲の広さ、応答時間（何時間以内に返事が来るか）、休日や夜間の対応の有無、カスタマイズやプラグインの数と複雑さ、そして引き継ぎ資料の有無です。

ここで、kintone自体の料金と保守費用は別物だと切り分けてください。kintoneの月額料金は、公式の料金ページでライトコース1,000円、スタンダードコース1,800円、ワイドコース3,000円（いずれも1ユーザー）です。ライトとスタンダードは10ユーザーから、ワイドは1,000ユーザーから契約できます。これはサービスの利用料で、アプリの改修や障害対応を頼む費用は含まれません。見積書に「ライセンス料」と「保守作業費」が並ぶ場合は、別の項目として読んでください。プラグインに利用料がかかる場合も、それは保守作業とは別です。

保守費用の目安については、一部の開発会社のサイトで、開発費の10〜20%程度や、月額3万円〜といった数字が紹介されています。比較の参考に構築費用の相場を確認しておくと、保守が開発のどの程度の規模かが把握しやすくなります。ただし、サイボウズは保守費用の相場を公表していません。これらの数字は、その会社の契約でどこまで含まれているかによって意味が変わります。目安として読むときは、数字の大きさより「その金額に何が入っているか」を確認するほうが役立ちます。

「伴走支援」「定額制」といった名前のサービスも、中身は会社によって違います。月あたりの対応時間が決まっているのか、作業の種類が決まっているのかを聞いてみてください。

開発会社そのものの選定ポイントは、別の記事で詳しくまとめています。外注先を探す段階の方は、先にkintoneの外注先の選び方を読むと、保守契約の話が進めやすくなります。

見積書で確認する点

保守契約の見積書は、金額より先に「何が書かれていないか」を確認するのが近道です。次の項目を並べて、空欄になっているところを質問してください。

確認項目	質問の例
対応範囲	4つの作業のうち、どれが含まれるか。追加改修はどこから別料金か
小規模の線引き	「小規模な修正は含む」とあるとき、何時間・何項目までが小規模か
応答時間	問い合わせへの初回返答は何営業時間以内か
休日・夜間	休日や夜間の障害対応はあるか。ある場合の追加費用は
対象アプリ	保守の対象は全アプリか、特定のアプリだけか。アプリが増えたときの扱いは
引き継ぎ資料	設定内容の資料は納品されるか。更新されるか
解約時	解約したとき、資料やデータはどう渡されるか

「小規模な修正は保守内」という書き方は、よく見かけます。ただ、どこまでが小規模かは、会社によっても案件によっても違います。見積の段階で「項目1つの追加は含みますか」「計算式の変更は含みますか」と具体例で聞いておくと、後のすれ違いを防げます。契約前に画面を見ながら確認したいときは、無料相談で見積書の読み方から一緒に整理できます。

もう1点、担当者の異動や退職で保守が止まる場面も想定しておきます。開発会社側の担当が変わったとき、引き継ぎはどう行われるか。自社の担当が変わったとき、窓口の変更はどう伝えるか。契約書に書かれていなくても、聞いておく価値があります。外注先を選ぶ段階の確認事項は、外注のチェックリストにもまとめています。

属人化を避ける最低限の記録

内製でも外注でも、記録がなければ引き継げません。全部を文書にしようとすると続かないので、最低限を絞ります。

1. フィールドの意味: 項目名の横に「なぜ必須か」「計算式が何を足しているか」を1行で残す。
2. アプリ間の依存関係: どのアプリが、どのアプリの値を参照しているか。1つ直すと別のアプリに影響が出ないかの確認に使う。
3. JavaScript・プラグインの一覧: 何のために入れたか、誰が作ったか、更新の影響を受けやすいか。
4. 外部連携先: kintoneとつながっている外部のシステムや、APIで呼び出している先。

JavaScriptカスタマイズの一覧は、アプリの設定画面から確認できます。この画面を記録の入口にして、一覧と目的を対にして残しておくと、バージョンアップ対応の際に洗い出しが速くなります。

アプリの設定そのものをバックアップできるかも気になるところです。ただ、公式の手段と限界は、今回一次情報の原文まで確認できていません。確認できている範囲で言えるのは、「テンプレートだけで設定が完全に復元できるとは限らない。レコードは別に書き出しておく必要がある」という程度です。復元の方法は、実際に使う前にテスト用のアプリで試しておくのが安全です。

まとめ：保守の線引きを決めてから発注する

最後に、pullieの立ち位置を書いておきます。pullieはサイボウズの認定パートナーではありません。独立した立場で、kintoneの構築と運用の相談を受けています。

認定の有無だけでは、発注側の業務（日報、承認、請求、原価管理など）をどこまで理解してくれるかまでは分かりません。ですので、認定の有無にかかわらず、見積書の内訳は同じ項目で確認してください。

大規模で多拠点、組織の体制を重視する案件では、パートナー企業の組織力が向く場面もあります。現場への定着を優先して小さく始めたいなら、「自社の業務をどこまで理解してくれるか」を選ぶ基準に加えてみてください。pullieは、建設・不動産の現場実務を経験したエンジニアが、業務の言葉のまま要件を聞き、kintoneの仕組みに翻訳する進め方をとっています。

この記事の流れを、発注前の手順に直すと次の4つです。

1. 保守の作業を4つに分け、どれを誰が持つか仮置きする
2. 内製で持てる範囲を、担当者の異動を想定して決める
3. 外注する作業について、契約の形（月額・都度・時間数）を比べる
4. 見積書の確認項目を並べ、空欄になっている点を質問する

保守の線引きが決まれば、見積書の金額にも説明がつきます。上司に聞かれたときも、「この範囲をこの理由で外に出し、ここは自社で持つ」と答えられる状態になっているはずです。