kintone案件で外部連携が必要になったとき、バックエンド開発をどう外注するか
- 5 日前
- 読了時間: 10分
更新日：3 日前
kintoneの導入・業務アプリ構築までは自社で対応できても、顧客から外部サービス連携や複雑な業務処理まで求められると、必要な技術領域が一気に広がることがあります。
その場合、kintone案件全体を別会社へ渡す必要はありません。kintone側は自社で担当したまま、外部連携やバックエンド開発だけを切り出して外注する方法があります。
※kintoneを自社業務で利用していて、外部連携や機能拡張を検討されている事業会社の方は、関連記事「kintoneを活かした業務システム拡張。外部連携で実現できること」もご覧ください。
はじめに：kintone案件は「外部とつなぐ」ところから必要な技術が変わる
kintoneは、顧客管理や案件管理、申請・承認業務などを比較的短期間で構築でき、導入後も利用企業自身で改善を続けやすいプラットフォームです。
そのため、SIerやDX支援会社、業務改善を支援する企業にとっても、顧客の業務をシステム化する有力な選択肢になります。
最初はkintoneの標準機能やプラグインを使った業務改善だけだった案件でも、利用範囲が広がるにつれて、顧客から「基幹システムのデータも連携したい」「決済サービスと接続したい」「LINEなどの外部サービスから情報を登録したい」「複雑な料金計算や判定処理まで自動化したい」といった相談を受けることがあります。
この段階になると、必要になるのはkintoneの設定やカスタマイズだけではありません。
API連携、データベース、認証、バッチ処理、業務ロジックなど、一般的なWebシステムのバックエンド開発領域が関わってきます。
kintone案件を受注した会社が、そのすべての技術領域を社内で抱える必要はありません。
重要なのは、自社が担当するkintone側と、外部へ切り出すバックエンド側の境界を明確にすることです。
結論：kintone側を自社で担当したまま、バックエンド部分だけ外注できる
kintone案件の外部連携では、「案件全体を別会社へ任せる」か「すべて自社で開発する」かの二択で考える必要はありません。
例えば、顧客との要件整理やkintoneアプリの設計・構築は自社で担当し、外部サービスとのAPI連携や複雑な業務処理だけをバックエンド開発会社へ依頼することができます。
役割分担の一例は次のようになります。
自社が担当 — 顧客との要件整理、kintoneアプリ設計、画面・フィールド構成、運用支援
バックエンド開発会社が担当 — 外部API連携、業務ロジック、データ変換、バッチ処理、外部DB、既存システム連携
この形であれば、自社と顧客との関係や、これまで積み上げてきたkintone導入ノウハウを維持したまま、自社内に不足している技術領域だけを補うことができます。
特に、kintone導入や業務改善のノウハウは持っているものの、本格的なWebシステム開発チームまでは抱えていない会社にとっては取りやすい役割分担です。
なぜkintoneの外部連携は「接続するだけ」では済まないのか
kintoneと外部サービスのAPI仕様が分かれば、あとは接続処理を書けば終わり、とは限りません。
実際の案件では、接続そのものよりも、その前後の設計が重要になります。
どちらのデータを正とするか決める必要がある
例えば、顧客情報がkintoneにも基幹システムにも存在するとします。
このとき、住所変更が発生した場合にどちらを更新するのか、両方から変更できるのか、一方だけ連携に失敗した場合はどうするのかを決めておかなければなりません。
ここが曖昧なまま「データ連携だけ」を作ると、運用開始後にどちらの情報が正しいのか分からなくなる可能性があります。
API連携では、データを送る処理そのものよりも、データの管理主体と更新ルールを決めることが重要です。
エラーが発生することを前提に設計する必要がある
外部サービスは常に正常に応答するとは限りません。
通信エラーやタイムアウト、認証エラー、送信データの不備などが発生すれば、「kintone上では登録済みだが、外部システムには登録されていない」といった状態が残ることがあります。
kintone内の複数のAPI処理については、一括処理APIを使うことで、途中の処理が失敗した場合に一連の処理をロールバックできる仕組みがあります。
一方で、kintoneと外部システムをまたぐ処理では、片方の処理が失敗したからといって、もう片方まで自動的に元へ戻るわけではありません。
そのため、どこまでを一体の処理として扱うのか、途中で失敗した場合に再実行するのか、担当者へ通知して確認するのかまで決めておく必要があります。
なお、認証方式やリトライ設計など、外部API連携全般に共通する考え方については、関連記事「API連携開発を外注するときに確認すべきポイント」で詳しく解説しています。
kintone側の変更が外部システムへ影響する
kintoneのメリットの一つは、利用企業や導入支援会社が比較的簡単にフィールドやアプリ構成を変更できることです。
しかし外部システムと連携すると、その自由度との付き合い方も考える必要があります。
例えば、外部システムが参照しているフィールドをkintone側で変更・削除すれば、連携処理へ影響する可能性があります。
そのため、外部連携を行うアプリについては、「どこまでなら顧客側で自由に変更してよいのか」「変更するときは誰へ確認するのか」といった運用ルールも合わせて決めておく必要があります。
バックエンド開発会社へどこまで切り出せるか
外注範囲は案件によって異なりますが、必ずしも「外部連携機能一式」を丸ごと任せる必要はありません。
例えば、kintoneアプリの設計はすでに自社で完了しており、外部APIとの接続部分だけ技術支援が必要なら、その範囲だけを切り出せます。
連携方式そのものを検討対象にすることもあります。
例えば、kintoneのWebhookで通知できるのは、レコードの追加・編集・削除、コメントの書き込み、プロセス管理のステータス更新といった操作です。
業務上必要な連携タイミングがこれに当てはまらない場合は、外部システム側から定期的にデータを取得するなど、別の方式を検討する必要があります。
つまり、「APIが用意されているから接続できる」というだけではなく、業務上いつデータを連携する必要があるのかまで確認したうえで方式を決めます。
反対に、顧客から「基幹システムとkintoneを連携したい」と相談されたものの、まだ具体的な方式が決まっていない場合には、まず技術調査や構成整理から依頼することもできます。
実際の切り分けでは、kintone側で何を管理するか、外部システム側で何を処理するか、両者の間でどのデータをいつ交換するかを整理したうえで、成果物として切り出せる単位を決めます。
そのため、最初から詳細なAPI仕様書や完成した要件定義書がなければ相談できない、というわけではありません。
成果物としての切り出し方そのものについては、関連記事「バックエンド開発を外注するとき、どこまでを成果物として切り出せるのか」で詳しく解説しています。
kintone案件の外部連携でよくある失敗
バックエンド側の検討を後回しにする
案件の中心がkintoneの場合、まずアプリを完成させ、その後で外部システムとの連携を考えたくなります。
しかし、外部連携するデータや処理がある程度見えているのであれば、できるだけ早い段階で連携方式も確認しておいた方が安全です。
例えば、kintone側で管理するフィールド構成が外部APIのデータ構造と大きく異なれば、後から変換処理が複雑になることがあります。
逆に、最初から連携を前提としてデータ構造を整理しておけば、kintone側とバックエンド側の双方をシンプルにできる場合があります。
API仕様だけ渡して「接続部分だけ」を依頼する
API仕様書があれば、実装自体は進められるケースもあります。
ただし、業務上の目的やkintone側の運用が分からなければ、技術的には動いていても、実際の業務では使いづらい連携になる可能性があります。
例えば、「登録APIを呼ぶ」という処理一つでも、いつ呼ぶのか、二重登録をどう防ぐのか、失敗時にどうするのか、結果をどこへ記録するのかによって設計は変わります。
そのため、バックエンド部分を外注する場合でも、API仕様だけではなく、何の業務を実現するための連携なのかを共有することが重要です。
障害時の責任分界を決めていない
kintone、外部バックエンド、さらに連携先サービスの3つが関わる場合、障害が発生したときの切り分け先も増えます。
顧客から「連携できない」と問い合わせが来たとき、それがkintone側の設定なのか、バックエンドなのか、外部サービスなのかを誰が最初に調査するのか決まっていなければ、複数社の間で確認が往復してしまいます。
開発時だけではなく、運用開始後の問い合わせ窓口や一次切り分けについても、あらかじめ整理しておくことが重要です。
当社がバックエンド部分を担当する場合は、まず当社が担当する処理のログや実行状況を確認し、当社側の問題なのか、kintone側または外部サービス側で追加確認が必要なのかを切り分ける形を取ることができます。
顧客からの問い合わせ窓口は貴社のまま、バックエンド領域の技術調査を当社が支援する、といった役割分担も可能です。
要件が固まっていない場合は「調査 → 切り分け → 開発」で進める
kintone案件では、顧客から相談を受けた段階でバックエンド側の仕様まで固まっているとは限りません。
「販売管理システムと連携できないか」
「このサービスのAPIを使って自動化できないか」
といった相談だけが先に出てくることもあります。
その場合は、いきなり開発見積もりを出すよりも、まず対象システムやAPIの仕様を確認します。
次に、kintone側と外部システム側の役割を整理し、必要な処理を切り分けます。
その結果をもとに、API連携やバックエンド開発を成果物単位で発注する、という進め方ができます。
現状調査 → 責任範囲・構成の整理 → 開発
という順番にすることで、仕様が曖昧な状態のまま固定された開発範囲へ入るリスクを減らせます。
調査や技術整理など、必要な部分だけを先に切り出して依頼することも可能です。
kintone導入支援は自社のまま、バックエンド部分だけ協業する
プレイリーソリューションズでは、Java / AWSを中心としたバックエンド開発、API連携、決済連携、既存Webシステム改修に対応しています。決済連携では、GMOペイメントゲートウェイの導入経験もあります。
kintone側の設計や顧客との業務整理を貴社で担当している場合は、その体制を活かしたまま、外部連携やバックエンド開発部分を担当します。
kintone導入やアプリ設定そのものを当社が引き取ることを前提とした協業ではありません。
当社自身も、社内システムでkintoneと外部システムを組み合わせて利用しており、kintone側と外部バックエンドの役割を分ける構成を実際の運用でも活用しています。
「外部サービス連携部分」「データ同期機能」「決済連携部分」といった成果物単位で開発範囲を区切り、その単位で納品する形にも対応できます。
人を補充するのではなく、完成させる対象を決めて任せる考え方です。
そのため、
「kintone案件は受けられるが、外部連携まで含むと社内の技術領域を超える」
「顧客との窓口やkintone側は自社で持ちたい」
「バックエンド部分だけ任せられる開発会社を探している」
という場合に、協業先の一社としてご相談いただけます。
発注前に共有しておくと進めやすい情報
最初から詳細な仕様書を用意する必要はありません。
まず、次の3つが分かれば相談を始められます。
顧客が実現したい業務
連携したい外部サービスや既存システム
自社で担当したい範囲
加えて、現在のkintoneアプリの概要、利用できるAPI資料の有無、希望する処理タイミング、運用開始後の保守体制の想定が分かると、調査範囲をより早く整理できます。
分からない項目は、そのまま調査対象として切り出すことも可能です。
「仕様が固まってから相談する」のではなく、仕様を決めるために必要な技術調査から外部へ依頼する、という進め方もできます。
まとめ：不足している技術領域だけを外へ出す
kintone案件で外部連携が必要になったからといって、自社で案件全体を対応できなくなるわけではありません。
kintone導入、業務整理、顧客対応は自社で担当し、API連携や業務ロジックなど、バックエンド開発が必要な部分だけを外部へ切り出すことができます。
その際に重要なのは、単に「API接続を外注する」ことではありません。
kintoneと外部システムの役割、データの管理主体、エラー時の対応、運用開始後の責任分界まで整理しておくことで、自社と外注先の境界が明確になります。
まだ仕様が固まっていない案件であれば、まず技術調査や構成整理から始める方法もあります。
kintone案件の顧客窓口や導入支援は自社で維持しながら、バックエンド領域だけを任せられる協業先が必要な場合は、その部分から切り出してご相談いただけます。
