LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

kintoneとは：ノーコード/ローコードで業務アプリを作るプラットフォーム

kintone（キントーン）とは、サイボウズ株式会社が提供するノーコード/ローコードの業務アプリ作成プラットフォームを指します。プログラミング知識が乏しい担当者でも、ドラッグ＆ドロップの操作を中心にデータ管理・ワークフロー・レポートを組み合わせた業務アプリを構築できる点が特徴です。

DX推進・業務効率化の加速を背景に、kintoneの導入企業は業種・規模を問わず広がっています。受注管理・問い合わせ対応・プロジェクト進捗管理など、現場ごとのアプリを手早く作れる柔軟性が評価されています。

ノーコード/ローコードでも専門知識が必要になる場面

kintoneはノーコードで始められる一方、活用が進むにつれて専門知識が求められる場面が増えます。たとえば複数アプリ間のデータ連携・外部システム（基幹系・SFAなど）とのAPI接続・プラグインの選定と保守・アクセス権限の設計といった領域は、業務知識とシステム知識の両方が必要です。

「誰でも作れる」という入口の手軽さが、逆に「設計が属人化しやすい」という課題を生むことがあります。社内担当者が異動や退職をすると、アプリの保守・改善が滞るリスクが高まります。

内製人材不足が起きやすい理由：リソース不足・スケジュール遅延・専門知識の壁

kintoneの社内推進担当者が不足しやすい背景には、複数の要因が重なっています。

本来業務との兼任でリソースが枯渇する

kintoneの社内推進担当者は、多くの場合、情報システム部門または現場部門の兼任です。日常業務をこなしながらアプリ開発・保守・ユーザーサポートを並行するため、担当者1人に対する負荷が集中しやすい状況があります。

開発案件が増えると対応が後回しになり、現場からの「使いたいのに待たされる」という不満がDXへの反発につながるケースもあります。スケジュール遅延が常態化すると、kintone導入効果が出にくくなります。

追加要員の即時調達が難しい

kintoneの社内担当者を増やそうとしても、即戦力として活躍できる人材を採用するにはリードタイムが必要です。kintoneの設計・開発・運用を一通り経験した人材は市場での絶対数が限られており、採用活動を始めてもすぐに配置できるとは限りません。

急なプロジェクト追加や組織改編のタイミングで、人材確保が追いつかないという状況が発生しやすいです。内製一本足の戦略だと、スケジュール変動への対応力が弱くなります。

業務理解とシステム知識を両立する難しさ

kintoneのアプリ設計では、業務フローの理解とシステム実装の知識を組み合わせる必要があります。「現場の課題をどうアプリに落とし込むか」という設計の判断には、業務経験と技術知識の両方が求められます。

特に他システムとのAPI連携やJavaScriptカスタマイズが絡む場面では、純粋なノーコード操作の範囲を超えます。社内にその知識を持つ担当者がいない場合、開発が手詰まりになりやすい状況が生まれます。

外注・公認パートナーで補完する3つの選択肢

kintoneの開発・運用人材が不足している状況を解消する手段として、サイボウズ公認パートナー^*1への委託が有効です。公認パートナーはサイボウズが認定した企業で、業務課題の整理からアプリ設計・開発・定着支援・他システム連携・運用保守体制の構築まで一貫して支援できる実績を持ちます。

スポット開発：特定アプリを成果物として依頼する

仕様が固まっており、特定のアプリや機能を完成品として受け取りたい場合はスポット開発の委託が向いています。受注管理・稟議ワークフロー・顧客データ管理など、用途が明確な案件で機能しやすい形態です。

自社の管理工数を抑えながら成果物を受け取れる反面、仕様変更が発生した場合に追加費用が生じやすい点は注意が必要です。また、開発完了後の保守・改善をどこが担うかを事前に取り決めておく必要があります。

伴走型支援：設計から定着まで継続的にサポートを受ける

「何を作るかがまだ固まっていない」「現場への浸透まで一緒に考えてほしい」という状況では、伴走型支援が効果的です。公認パートナーが業務課題の整理に入り、アプリ設計・開発・ユーザートレーニング・定着フォローまでを継続的にサポートします。

仕様変更や追加改善に柔軟に対応できる点がメリットです。一方で、継続的な関与になるため、委託期間中の費用が発生します。内製担当者が育つまでの橋渡しとして活用するのが機能しやすい使い方です。

運用保守委託：日常的な改善・管理を継続的に任せる

アプリの開発は完了しているが、日常的な保守・小改善・ユーザーサポートを担う社内リソースが不足している場合は運用保守委託が向いています。月次・週次での問い合わせ対応・軽微な設定変更・プラグインのアップデート対応などを外部に委ねることで、社内担当者の負荷を下げられます。

外部システムとの連携が複雑な環境では、連携部分の保守・障害対応も含めて委託範囲に入れることで、運用の安定性を保てます。

委託を進める5つのステップ：課題整理から運用保守体制まで

外注・委託によってkintone開発・運用を補完する際は、段階を踏んで進めることで品質と定着率を高められます。以下に実務で機能しやすい5ステップを示します。

ステップ1：業務課題を言語化して優先度を整理する

「どの業務プロセスを改善したいのか」「現在どのような非効率・ミス・遅延が起きているのか」を言語化することが出発点です。kintoneで解決できる課題とそうでない課題を切り分けるためにも、業務フローの現状把握が先に必要です。

優先度の判断基準としては、関係者の人数・発生頻度・作業時間の削減余地が参考になります。社内担当者だけで整理が難しい場合は、公認パートナーにヒアリングから入ってもらう形が有効です。

ステップ2：アプリ設計・開発をパートナーに依頼する

業務課題が整理できたら、アプリの設計・開発を委託します。kintoneのアプリ設計では、データ項目の定義・ワークフローの分岐・アクセス権限の設計が骨格になります。

プラグインの実装・JavaScriptカスタマイズ・外部システムとのAPI連携が必要な場合は、その範囲を委託スコープに明記しておくことが重要です。スコープが曖昧なまま開発を進めると、完成後に「想定と違う」というギャップが生じやすくなります。

ステップ3：社内定着支援でユーザーへの浸透を図る

開発が完了しても、現場に使われなければ効果は出ません。社内への浸透を支援するトレーニング・操作マニュアル作成・問い合わせ対応などの定着支援を委託スコープに含めることが大切です。

現場の担当者が「使いにくい」と感じる箇所への改善対応も、定着フェーズに含めます。小改善を素早く回せる体制があると、導入後の利用率が上がりやすくなります。

ステップ4：他システムとの連携を設計・実装する

kintoneは単独で使うだけでなく、既存の基幹システム・SFA（営業支援システム）・会計システムなどと連携することで効果が高まります。連携には専用のプラグインやAPIを活用しますが、接続先システムの仕様理解と設定作業が必要です。

連携設定を誤ると、データの二重入力・不整合・システム停止といったリスクが生じます。連携範囲と障害時の切り分け基準を事前に定義した上で、実装を進めることをお勧めします。

ステップ5：運用保守体制を構築して継続改善サイクルを回す

稼働後の運用保守体制を最初から設計しておくことで、属人化と開発停止を防げます。定期的なアプリの見直し・プラグインのバージョン管理・kintoneのアップデート対応といった継続業務の担い手を明確にします。

社内体制が整うまでの間、運用保守を外部パートナーに委ねることで、開発成果を劣化させずに維持できます。内製体制の強化と並走させることが、中長期的な安定稼働につながります。

内製と外注・委託の比較：費用・スピード・ノウハウ蓄積

内製対応と外注・委託の判断を誤ると、スピードを失うか、ノウハウが組織に蓄積されないかのどちらかに傾きやすくなります。両者の特徴を整理します。

内製と外注のどちらかに一本化するより、「外注でスピードを確保しながら内製を育てる」という組み合わせが、継続的なkintone活用に向いています。社内担当者が存在しないゼロスタートの状況では、まず外部パートナーと一緒に立ち上げることが現実的な選択肢です。

委託時の3つの注意点：業務理解・属人化回避・プラグイン保守

kintoneの開発・運用を外部に委託する際は、事前に確認しておくべきポイントがあります。見落とすと、委託完了後に社内での継続運用が難しくなるリスクが高まります。

注意点1：業務理解の深さをパートナー選定時に確認する

kintoneのアプリ開発は、業務フローの理解なしに設計だけを進めると、現場で使われないアプリができあがるリスクがあります。「動くアプリを作れる」だけでなく「業務課題の整理から一緒に考えられるか」を委託先の選定基準に含めることが重要です。

選定時には、過去の導入支援実績・業種別の対応事例・ヒアリング提案の進め方を確認することをお勧めします。技術スキルだけでなく、業務理解の姿勢を持つパートナーかどうかを見極めることが、後の定着率に直結します。

注意点2：属人化を防ぐドキュメント整備を委託スコープに含める

委託で開発したアプリの設計思想・データ構造・権限設定が外部担当者の頭の中にだけ存在する状態は、委託終了後の保守に大きな支障をきたします。アプリ設計書・フィールド定義書・運用手順書を成果物として契約に明記することが大切です。

設計書がない状態で委託を終えると、後から保守を引き継ぐ社内担当者または別の外部パートナーが一から調査をやり直す必要が生じます。これは実質的なベンダーロックイン（特定の委託先なしには運用できない状態）と同じ結果をもたらします。

注意点3：プラグインの保守継続性を事前に確認する

kintoneでは、標準機能を補うためのプラグインを組み込むことがあります。プラグインはサードパーティ製も多く、バージョンアップ・サポート終了・kintone本体との互換性変更といったリスクが伴います。

委託先がプラグインの選定・保守・代替対応まで責任を持てるかどうかを、契約前に確認することをお勧めします。プラグインの保守対応が委託スコープ外だった場合、kintone本体がアップデートされた際に連携が壊れたまま対処が遅れるリスクがあります。

まとめ：kintone人材不足に対応する3つの判断軸

本稿では、kintone（業務アプリ）の開発・運用人材が不足している状況における外注・委託での補完方法と、業務課題整理から運用保守体制まで一貫して進める手順を整理しました。要点を3つに集約すると次のとおりです。

第一に、内製一本足で停滞するより、外注・公認パートナーを早めに活用すること。社内担当者の兼任負荷やスキル限界でkintone活用が止まってしまうより、専門知識を持つパートナーを活用してアプリ開発・定着支援・運用保守を前進させることが、DX推進の現実的な選択肢です。

第二に、委託形態はフェーズと課題の性質で選ぶこと。仕様が固まったアプリ開発にはスポット開発、課題整理から浸透まで伴走してほしい場合は伴走型支援、稼働後の保守・小改善は運用保守委託が向いています。プロジェクトのフェーズと社内体制の状況に合わせて選択することが大切です。

第三に、属人化防止とドキュメント整備を委託設計に最初から組み込むこと。設計書・フィールド定義・運用手順書を成果物として定義し、委託終了後も社内で継続できる状態を作ることが、長期的なkintone活用の前提条件です。プラグイン保守の責任範囲も契約前に確認しておくことが、後のトラブル回避につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：サイボウズ株式会社「kintone 公認パートナー」（サイボウズ公式）

Tweet