kintoneを導入すればDX？「ツールを入れること」と「業務を変えること」は別の話
「DXを進めるためにkintoneを導入しました」
企業のシステムについてお話を伺っていると、このような話を聞くことがあります。
kintoneは、紙やExcelで管理していた業務をアプリ化でき、プログラミングの知識がそれほどなくても業務システムを作れる便利なクラウドサービスです。
実際、システムキューブでもkintoneを利用していますし、サイボウズ社のパートナーとしてkintoneの開発やカスタマイズにも携わっています。
ですから、この記事は「kintoneを使うべきではない」という話ではありません。
ただ、システム会社としてさまざまな企業の業務システムを見ていると、一つ気になることがあります。
kintoneを導入すること自体が、いつの間にか「DXの目的」になっていないでしょうか。
kintoneを導入することと、会社の業務を変えることは、同じではありません。
そもそもDXとは何でしょうか
DXという言葉は非常に広い意味で使われるようになりました。
紙をなくす。
Excelをクラウド化する。
Web会議を導入する。
社内システムをクラウドへ移行する。
これらも広い意味ではデジタル化の取り組みですが、本来のDXはもう少し踏み込んだ概念です。
経済産業省はDXを、データとデジタル技術を活用して、製品やサービス、ビジネスモデルだけでなく、業務そのものや組織、プロセス、企業文化・風土まで変革し、競争上の優位性につなげていくことと定義しています。
つまり重要なのは、
「何のITツールを導入したか」ではなく、「その結果、会社や仕事がどう変わったか」
ではないでしょうか。
サイボウズ社自身も、DXについて単なる業務のデジタル化だけではなく、ビジネスモデルの変革まで含むものとして説明しています。
そう考えると、
「kintoneを導入した＝DXができた」
という考え方には、少し注意が必要です。
紙をkintoneにしただけなら、仕事そのものは変わっていないかもしれない
例えば、これまで紙で行っていた申請書があったとします。
氏名を書く。
日付を書く。
申請内容を書く。
上司に渡す。
上司が確認して承認する。
これをそのままkintoneへ移したとします。
確かに紙はなくなります。
検索もしやすくなりますし、どこからでも確認できるようになります。
これは十分に意味のある改善です。
しかし、
「そもそも、この申請は必要なのか」
「承認は本当に3段階必要なのか」
「すでに別システムにある情報を、なぜもう一度入力しているのか」
「承認後に誰かが別システムへ転記していないか」
といった業務そのものを見直さないまま、紙の申請書をkintoneの入力画面へ置き換えただけなら、業務プロセス自体はほとんど変わっていません。
Excelについても同じです。
例えば20列あるExcel管理表を、そのまま20項目のkintoneアプリに置き換える。
もちろんデータを共有しやすくなるメリットはあります。
しかし、それだけでDXと呼んでよいのかについては、一度立ち止まって考えてもよいのではないでしょうか。
「今の仕事をそのままシステム化する」のは簡単です
システム開発でもよくある話です。
お客様から、
「今、このExcelを使って仕事をしています。このままシステムにしてください」
と言われることがあります。
もちろん、その通りに作ることはできます。
しかし、そこで私たちが確認しなければならないのは、
「そもそも、そのExcelで行っている業務は現在も必要なのか」
ということです。
10年前に決められた業務フロー。
以前の担当者が作ったExcel。
なぜ必要なのか誰も分からない入力項目。
念のため残している承認。
別部署でも同じ情報を管理している二重入力。
こうしたものを整理せず、そのまま新しいシステムへ移してしまえば、
古い業務を最新のITツールの上で再現しただけ
になってしまいます。
これはkintoneに限った話ではありません。
Power Appsでも、Salesforceでも、スクラッチ開発でも同じです。
新しいツールを導入したからといって、古い業務の考え方まで自動的に新しくなるわけではありません。
kintoneの「簡単に作れる」という長所だからこそ注意したい
kintoneの大きな魅力の一つは、業務アプリを比較的素早く作れることです。
サイボウズ社も、kintoneを業務アプリを作れるノーコードツールとして紹介し、現場で思いついた業務改善を素早く実行できることを特徴として挙げています。
これは大きなメリットです。
従来のシステム開発なら、
要件を整理する
設計する
開発する
テストする
リリースする
という工程を経るため、小さな業務改善でも時間や費用がかかることがありました。
kintoneなら、現場の担当者自身が試しながら改善することもできます。
実際に、大企業で現場社員が多数のアプリを作り、業務時間を大幅に削減した事例も公開されています。
これはkintoneの非常に優れた部分です。
一方で、
「簡単に作れること」と「良い業務システムになること」は別です。
ここは意外と重要だと思っています。
「困ったからアプリを作る」を繰り返していないでしょうか
例えば、
営業部門で顧客管理が必要になったので顧客アプリを作る。
案件を管理したくなったので案件アプリを作る。
見積を管理したくなったので見積アプリを作る。
問い合わせが増えたので問い合わせアプリを作る。
契約管理が必要になったので契約アプリを作る。
こうして現場の課題を一つずつ解決できることは、kintoneの良さです。
しかし数年後に振り返ると、
「同じ会社名が複数のアプリに入っている」
「どのアプリの情報が最新なのか分からない」
「似たような項目を何度も入力している」
「アプリ同士を連携するためにプラグインが増えている」
「さらにJavaScriptやAPI連携が追加されている」
という状態になる可能性があります。
最初の一つひとつの判断は間違っていなかった。
ところが積み重ねた結果、システム全体が複雑になっている。
これは従来型のシステムでも、ノーコード・ローコードでも起こる問題です。
実際、サイボウズ社が紹介する大規模利用事例でも、まず現場単位で多数のアプリを作った後、業務整理を行い、同じ業務フローの統合やアプリ数の整理、運用ルールの整備へ進む取り組みが紹介されています。
つまり、作ることと、全体を設計することは別なのです。
kintoneを入れることではなく、「何を変えたいのか」から考える
kintoneを導入するとき、本来最初に考えたいのは、
「どんなアプリを作るか」
ではないと思います。
まず考えるべきなのは、
「今の業務の何が問題なのか」
です。
例えば、
毎月100時間かかっている入力作業を30時間にしたい。
情報を探す時間を減らしたい。
担当者しか分からない業務をなくしたい。
二重入力をなくしたい。
承認に3日かかっているものを当日に終わらせたい。
顧客情報を営業担当者だけでなく会社全体で共有したい。
こうした目的が先にあるべきです。
そして、
「その課題を解決する方法としてkintoneが適している」
のであれば、kintoneを使う。
逆に、
「この業務はkintoneより別の仕組みの方がよい」
のであれば、別の方法を選ぶ。
これが本来のシステム選定ではないでしょうか。
kintoneを使わないことがDXなのでもありません
ここで誤解してほしくないのですが、
「kintoneではDXにならない」
と言いたいわけではありません。
むしろkintoneは、現場主導で素早く業務改善を行えるという意味で、DXを進める有効な選択肢の一つです。
サイボウズ社も、kintoneを利用して現場主導で業務改善を進め、DXにつなげた企業事例を多数公開しています。
問題は、
kintoneを導入したことそのものを成果にしてしまうこと
です。
「50個アプリを作りました」
より、
「年間500時間の業務を削減しました」
の方が重要です。
「全社員にkintoneアカウントを配布しました」
より、
「それまで3日かかっていた業務が30分になりました」
の方が重要です。
DXを考えるのであれば、見るべき数字はアプリ数でもユーザー数でもなく、業務や会社がどれだけ変わったかではないでしょうか。
新しいツールで、古い業務を作り直していないか
私たちはこれまで、VB6や古いAccessなどで作られた業務システムの改修やマイグレーションにも携わってきました。
こうしたシステムも、導入された当時は決して「古いシステム」ではありませんでした。
その時代には便利で、会社の業務効率を大きく改善したシステムです。
しかし、その後10年、20年と使い続ける中で、
機能追加
仕様変更
担当者交代
外部システム連携
などが積み重なり、現在では簡単に変更できないシステムになっていることがあります。
これはkintoneにも無関係な話ではないと思っています。
2026年現在、kintoneは「ノーコード・ローコード」「DX」といった新しいイメージで語られることが多いサービスです。
ただし、そこで作られているものは企業にとっては業務システムという長期的な資産です。
5年後。
10年後。
その仕組みをどのように保守するのか。
別のシステムへ移行する必要が出たとき、簡単に移行できるのか。
そこまで考えておく必要があります。
「新しいツールを使っているから新しいシステム」
とは限りません。
古い業務プロセスをそのまま新しいツールの上へ作り直せば、将来それが新しいレガシーシステムになる可能性もあります。
kintone導入の前に一度考えてみたいこと
kintoneを導入すること自体がDXなのではありません。
大切なのは、
kintoneを使って何を変えるのか。
そして、
その変化によって会社にどんな価値が生まれるのか。
だと思います。
kintoneが最適なら、積極的に利用すればよい。
すでにkintoneを利用しているなら、もっと使いやすく改善すればよい。
一方、kintoneでは複雑になりすぎる業務なら、別の方法を検討してもよい。
特定のツールから考えるのではなく、業務から考える。
それが結果的に、最も長く使えるシステムにつながるのではないでしょうか。
システムキューブはkintoneを利用し、サイボウズ社のパートナーとしてkintoneの開発にも携わっています。
だからこそ、
「何でもkintoneにすればよい」ではなく、「kintoneをどこで使えば最も価値を発揮できるのか」
を考えることも、私たちシステム会社の役割だと考えています。