kintone導入支援会社が外部連携案件を受けたとき、バックエンド担当とどう役割分担するか
- 2 日前
- 読了時間: 11分
kintoneの導入・業務設計は自社で担当し、基幹システムや外部APIとの連携部分だけをバックエンド開発会社へ任せたい。
この分担で重要なのは、「kintone側」「バックエンド側」と大きく線を引くことではなく、両者の境界にある連携インターフェースを誰がどう管理するかを決めることです。
はじめに：この記事では「どう外注するか」ではなく「分けた後の境界」を考える
kintone案件で外部連携が必要になったとき、どの範囲をバックエンド開発会社へ切り出せるかについては、kintone案件で外部連携が必要になったとき、バックエンド開発をどう外注するかで解説しています。
本記事では一歩進めて、
kintone側は自社、外部連携のバックエンド側は別会社
という分担を選んだ場合に、2社の間で何を共同仕様として管理すべきかを考えます。
たとえば、
kintoneのフィールドを変更したら、バックエンド側へどの時点で共有するのか
APIトークン経由の操作を、kintone上のアクセス権とどう整理するのか
連携に失敗したレコードを、どちらが検知して復旧するのか
データの管理主体を、誰が決めるのか
といった部分です。
外部連携案件では、プログラムの実装場所よりも、システムとシステムの境界で起きることを誰が管理するかのほうが重要になります。
結論：両社で共同管理すべきなのは「連携インターフェース」
役割分担の基本形そのものは複雑ではありません。
kintone導入支援会社は、業務要件、アプリ、フィールド、プロセス、画面、利用者向けの運用など、主にkintone側を担当します。
バックエンド担当は、外部API、基幹システム、社内DB、データ変換、バッチ、AWSなど、主にkintoneの外側を担当します。
しかし、その間にはどちらか一方だけでは決められない領域があります。
それが連携インターフェースです。
具体的には、
何のデータを連携するか
どのフィールドとどの項目を対応させるか
いつ連携するか
誰がデータの管理主体を決めるか
何をもって連携成功とするか
失敗時にどう復旧するか
kintone側を変更するときにどう連携影響を確認するか
といった内容です。
ここを「kintone担当」「バックエンド担当」のどちらかへ押し込むのではなく、両社の共通仕様として管理することが、役割分担の中心になります。
データの「正」をバックエンド担当だけで決めない
kintoneと基幹システムを連携するとき、「どちらを正とするか」という話がよく出ます。
ただし実際には、システム単位で一律に「基幹システムが正、kintoneが従」と決められるとは限りません。
顧客基本情報は基幹システム、営業担当者が入力する対応状況はkintone、というように、項目ごとに管理主体が異なることがあります。
この考え方については、kintoneと基幹システム・社内DBを連携するとき、データ同期方式をどう選ぶかで詳しく扱っています。
本記事で重要なのは、その管理主体を誰が決めるのかです。
バックエンド担当は、データをどう取得し、変換し、同期するかを設計できます。
しかし、
顧客住所はどちらの変更を優先するのか
営業担当者はkintoneから変更してよいのか
基幹側で削除された顧客をkintoneからも削除するのか
といった判断は、技術だけでは決められません。
業務を理解しているkintone導入支援会社と顧客側が管理ルールを整理し、その結果をバックエンド担当と共有します。
「何を正とするか」は業務側で決め、「そのルールをどう連携処理に実装するか」をバックエンド側で設計する。
この分担にすると整理しやすくなります。
フィールド対応表を「両社の境界仕様」として扱う
外部連携では、kintoneのフィールドと接続先の項目を対応付けます。
たとえば、次のような情報です。
顧客コード：kintone「顧客コード」／基幹システム「CUSTOMER_ID」／基幹側で採番
顧客名：kintone「顧客名」／基幹システム「CUSTOMER_NAME」／基幹からkintoneへ連携
営業担当：kintone「営業担当」／基幹システム「SALES_STAFF」／kintone側で管理
更新日時：kintone「更新日時」／基幹システム「UPDATED_AT」／同期判定に使用
こうした対応表は、単なる開発者向けの資料ではありません。
kintone担当とバックエンド担当の境界を定義する共通仕様として扱えます。
最低限、
kintoneのフィールドコード
外部システム側の項目
データ型
必須・任意
管理主体
連携方向
コード値の変換
空値の扱い
更新条件
程度を共有しておくと、後から「その項目を変更すると連携に影響するとは知らなかった」という問題を減らせます。
特に重要なのがフィールドコードです。
画面上の表示名だけではなく、バックエンド処理が何を参照しているのかを両社で特定できる形にしておきます。
kintoneのアクセス権とAPIトークンの権限を同じものと考えない
kintoneとの外部連携で、役割分担上とくに注意したいのが認証です。
kintone REST APIでは、アプリごとに生成するAPIトークンを使った認証が利用できます。
サイボウズの公式ドキュメントでは、APIトークンを使用した操作はAdministratorによる操作として扱われるとされています。
そのため、
kintoneの画面では一般利用者に編集権限を与えていないから、外部連携からも同じように編集できないだろう
とは限りません。
外部連携を別会社が担当する場合は、少なくとも、
どのアプリにAPIトークンを発行するか
読み取りと書き込みのどちらを許可するか
トークンを誰が発行するか
認証情報をどちらが保管するか
バックエンド担当へどの方法で受け渡すか
契約終了や担当変更時に誰が無効化するか
を決めておく必要があります。
これは単なる認証設定ではありません。
kintone側のアクセス権設計と、外部システムから与える権限を接続する責任境界です。
kintone側の変更は「アプリを更新する前」を責任境界にする
kintoneは、業務に合わせてアプリを変更しやすいことが大きな特徴です。
一方、外部システムと連携しているアプリでは、その変更がバックエンド処理へ影響する可能性があります。
たとえば、
フィールドを追加・削除する
フィールドコードを変更する
データ型を変更する
アクセス権を変更する
プロセス管理を変更する
JavaScriptカスタマイズを変更する
といった場合です。
ここで「変更するときはバックエンド担当へ連絡する」というルールだけでは、タイミングが曖昧です。
kintone REST APIの公式ドキュメントでは、動作テスト環境のアプリ設定を運用環境へ反映するAPIについて、アプリの設定画面で「アプリを更新」や「変更を中止」をクリックする操作に相当すると説明されています。
この「運用環境へ反映する前」を、そのまま責任境界として利用できます。
当社がkintone外部連携のバックエンド側を担当する場合は、外部連携に関係する設定を動作テスト環境で変更した時点で共有していただき、「アプリを更新」する前に連携影響を確認することを基本とします。
これなら、運用環境へ変更したあとに障害が起きてから確認するのではなく、反映前に影響を確認できます。
もちろん、すべてのkintone変更をバックエンド担当の確認対象にする必要はありません。
自由に変更できる範囲
説明文の変更
連携処理から参照していない項目
連携に影響しない表示上の調整
連携仕様として管理する範囲
連携対象のフィールド
フィールドコード
データ型
APIトークンやアクセス権
外部連携の実行条件に関係する設定
このように分けておけば、kintoneの変更しやすさを損なわずに外部連携を管理できます。
連携失敗は「技術的な検知」と「業務上の判断」を分ける
たとえば、次のような状態を考えます。
kintoneへの登録は成功
外部APIへの送信は失敗
kintone上にはレコードが残っている
このとき、バックエンド担当が技術的なエラーを検知できても、
このレコードを再送してよいのか
利用者へ連絡する必要があるのか
二重登録の可能性はないのか
までは判断できないことがあります。
そこで、バックエンド側では、
通信エラーを検知する
エラーログを残す
対象レコードを特定できるようにする
必要に応じて再実行手段を用意する
といった技術的な仕組みを担当します。
一方、kintone導入支援会社や顧客側では、
エラーを利用者へどう見せるか
再実行可能な業務状態か
手動対応が必要な場合に誰が何をするか
を決めます。
「エラーを検知できること」と「そのエラーをどう業務上処理するか」は別の責任として考えると整理しやすくなります。
バックエンド外注全般で、試験や障害対応などの責任境界をどう設計するかについては、バックエンド開発を外注するとき、責任分界はどう決めるべきかでも解説しています。
具体例：基幹システムの顧客マスタをkintoneで利用する
たとえば、顧客企業から次のような要望があったとします。
顧客マスタは既存の基幹システムにある。営業部門ではkintoneを使いたいので、必要な顧客情報を連携したい。
この場合、単純に次のように分けただけでは、まだ不十分です。
kintoneアプリ：kintone導入支援会社
同期プログラム：バックエンド担当
両社で次のような共同仕様を決めます。
顧客を特定するキー
顧客コードなど、両システムで同じ顧客を判断する方法を決めます。
フィールド対応
基幹システムのどの項目を、kintoneのどのフィールドへ入れるかを決めます。
管理主体
顧客名や住所など、項目ごとにどちらから変更するかを決めます。
同期タイミング
リアルタイムなのか、数分ごとなのか、夜間バッチなのかを決めます。
異常時の状態
一部の顧客だけ連携に失敗した場合、どこへ記録し、どう再処理するかを決めます。
変更手順
連携対象フィールドを変更するとき、運用環境への反映前に誰が確認するかを決めます。
こうした共同仕様が決まれば、それぞれの実装範囲は明確になります。
kintone導入支援会社は、営業部門が使いやすいアプリや業務フローの設計に集中する。
バックエンド担当は、基幹システムへの接続、データ変換、同期処理、エラー処理などに集中する。
一社がすべての技術領域を抱えなくても、境界を共同で設計できれば一つのシステムとして成立させられます。
すべての案件で詳細な共同仕様書が必要なわけではない
ここまで読むと、
外部連携があるなら、毎回かなり細かな仕様書を作らなければならないのか
と感じるかもしれません。
必ずしもそうではありません。
たとえば、
連携するフィールドが数個しかない
一方向のデータ取得だけで済む
連携先APIの仕様が明確
エラー時は単純に再実行できる
kintone側の連携対象項目をほとんど変更しない
といった小規模な連携であれば、数ページの資料や一覧だけで十分な場合もあります。
一方で、
基幹システムと双方向に同期する
項目ごとに管理主体が異なる
データ変換ルールが多い
複数アプリをまたぐ
バッチやWebhookなど複数の契機がある
エラー後に業務判断が必要
kintone側の設定変更が多い
といった案件では、境界仕様を明文化する価値が高くなります。
重要なのは、資料を厚くすることではありません。
連携の複雑さに応じて、「両社の認識がずれると困る部分」だけを共同仕様として残すことです。
kintone導入支援会社側で最初に整理しておきたい5項目
バックエンド担当との打ち合わせ前に、すべての技術仕様を完成させる必要はありません。
まず次の5項目が整理されていると、役割分担を話しやすくなります。
何と連携したいか基幹システム、社内DB、外部SaaSなど。
何のデータを連携したいか顧客、案件、在庫、受注など。
どちらで入力・変更したいか項目単位で決まっていなくても、現在の業務を説明できれば構いません。
いつ反映されればよいか即時性が必要なのか、定期同期でもよいのか。
失敗したとき業務上どう困るか数時間遅れてもよいのか、その場で処理を止める必要があるのか。
ここまでを業務側から共有し、API、認証、データ形式、実行方式などの技術要件はバックエンド担当と一緒に詰めていく進め方ができます。
プレイリーソリューションズが担当できること
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、Java / AWSを中心に、外部API連携、既存Webシステム・DBとの連携などに対応しています。
kintone導入支援会社が顧客との業務整理やkintoneアプリ構築を担当し、
既存システムやDBとの接続
外部API連携
データ変換・同期処理
バッチ処理
AWS上のバックエンド
エラー処理・ログ
技術調査
など、kintoneの外側に必要となるバックエンド領域を成果物として切り出す形でご相談いただけます。
連携先の仕様や接続方法がまだ明確でない場合は、最初から実装範囲を固定せず、技術調査と連携仕様の整理から始めることも可能です。
まとめ：2社の間にある仕様を、どちらのものでもない状態にしない
kintone導入支援会社とバックエンド担当の役割分担では、「kintoneは自社、APIは外注先」と決めただけでは足りません。
重要なのは、その間にある、
フィールド対応
データの管理主体
API認証
エラー時の扱い
設定変更時の確認
連携仕様
を、両社の共通仕様として管理することです。
特にkintoneでは、APIトークンの扱いや、動作テスト環境の設定を運用環境へ反映する仕組みがあります。
こうしたkintone固有の仕組みまで責任分界へ落とし込めば、単に開発作業を分担するだけでなく、運用開始後の変更にも対応しやすい外部連携になります。
kintone案件で外部API・既存システム・AWSなどのバックエンド領域を切り出せる協力会社をお探しのkintone導入支援会社・DX支援会社の方は、対応範囲の整理段階からご相談ください。
