「kintoneを導入したのに、結局Excelで管理している」
この一言で全てが伝わる担当者は少なくありません。導入を決めたのも推進したのも自分——それなのに現場は動かず、上司からは「効果がないんじゃないか」と言われはじめている。
「使いにくい」「入力が面倒」「どこに何があるか分からない」——現場からの声はさまざまですが、これらのほとんどはkintone自体の問題ではなく、アプリの設計の問題です。
この記事では、現場が使わなくなる本当の原因を整理し、自社でできる改善手順と、外部支援が必要になる判断軸をお伝えします。「投資を回収できた」と上司に説明できる状態への道筋を、一緒に確認していきましょう。
「kintone 使いこなせない」で検索する人が抱える3つの状況
kintoneの定着に悩む担当者は、大きく次の3つのパターンに当てはまります。自分の状況を確認しながら読んでみてください。
①誰も入力しない——「Excelの方が速い」と言われる
フォームの入力順序が業務の流れと合っていないため、現場スタッフは「手間がかかる」と感じてしまう。担当者だけがkintoneの画面を更新し、現場は以前のExcelや紙の運用に戻ってしまっている状態です。
②管理者だけが使っている——現場に届いていない
アプリの構築は完了したが、「なぜ入力しないといけないのか」が現場に伝わっていない。使い方を覚える機会もなく、システムの存在は知っていても自分の業務との接続点が見えていない状態です。
③入力されるが活用されていない——データが眠っている
入力はされているが、グラフやレポートを誰も活用していない。「なんとなく入れている」状態が続き、入力精度も徐々に落ちていく。蓄積されたデータが業務改善に活かされていません。
どのパターンも、根っこは同じ問題に行き着きます。「kintoneが自分の仕事の役に立っている」という実感が、現場にない——これが定着しない本当の理由です。
kintoneが使われない本当の理由——機能の問題ではなく設計の問題
サイボウズ公式の「kintone 歩き方」では、社内浸透にしくじる3大原因として次を挙げています（出典）。
- 担当者が自分しかいない（推進する仲間がいない）
- kintone利用の目的が曖昧
- 「使いづらい」を放置する
特に3番目——「使いづらい」という声を聞いているのに改善しないこと——が、現場の離脱を加速させます。では、「使いづらい」の正体は何でしょうか。
設計ミス①：フィールドが業務の流れに合っていない
公式は「業務の流れによってレコード入力できなかったり、入力する項目が多すぎたりすると、現場の人にとって『アプリが使いづらい』となり、社内浸透にしくじります」と明記しています（出典）。
業務を知らずにフィールドを並べると、現場からすると「なぜこの順番で入力するのか」「このフィールドは自分には関係ない」という画面になります。kintoneのアプリ設計では、入力者の業務手順に沿ったフィールドの配置が基本です（cybozu.dev アプリ設計ベストプラクティス）。担当者Aが入力する欄と担当者Bが確認する欄はラベルで区切る、フィールド幅を4〜5カラム以内に統一する——こうした配慮が定着率を変えます。
設計ミス②：「なぜ入力するか」が画面に書かれていない
入力フォームに「このアプリの目的」「入力のタイミング」が書かれていないと、スタッフは自分の判断で入力するか省略するかを決めてしまいます。
kintoneにはレコード一覧・詳細画面に「アプリの説明」を常時表示する機能があります（cybozu.dev ベストプラクティス）。「何のために入力するか」「誰がいつ確認するか」を書いておくだけで、入力精度が変わります。
設計ミス③：プロセス管理が現行の紙フローをそのまま再現している
承認フローを、現行の紙書類の手続きをそのままkintoneに移そうとすると失敗します。kintone SIGNPOST 3-25「プロセスのシンプル化」では、「現在の申請プロセスや運用方法そのままをkintoneで再現するだけでは、業務改善の効果は少ない。複雑な条件設定により管理が煩雑になり、設定変更時にミスが発生しやすくなる」と整理されています（出典）。
紙の承認フローを整理・簡素化してからkintoneに移す——この順番が逆になると、「操作は増えたが業務は変わらない」システムができあがります。
自社でできる改善ステップ3つ
「使われないアプリ」を立て直すための手順を3ステップで整理します。
ステップ1：現場の業務フローをもう一度観察する
アプリに手を加える前に、実際の業務の流れを図式化します。「誰が、いつ、何の情報を必要としているか」を一覧にするだけで、フィールドの過不足が見えてきます。
kintone SIGNPOST 1-09「業務の流れを掴む」では、「断片的に業務課題をヒアリングするだけでは、業務の全体像を把握することはできず、業務改善につながらない」とあります（出典）。ヒト・モノ・データ・コミュニケーションの流れを確認してから設計に入る——これが定着への入口です。
現場の担当者に15〜30分ヒアリングするだけでも、「このフィールドは入力するタイミングがない」「次に確認するのが誰か分からない」という設計の穴が浮かびあがります。
ステップ2：アプリを「75点」で直す
既存のアプリを全部作り直そうとしない。「使われていない主な原因」に絞って直すことが重要です。
サイボウズ公式は「75点を目指して素早く実現しましょう。運用中でも日々カイゼンできます」という考え方を推奨しています（出典）。完璧なアプリを目指して完成を遅らせることが、定着の失敗原因になるのです。
入力フォームの整理、フィールドの順序変更、「アプリの説明」の追記——まずここから始めることで現場の反応が変わることがあります。アプリ設計の基本についてはkintoneアプリを3ステップで作る方法でも解説しています。
ステップ3：「なぜkintoneを使うか」を現場に伝える場を作る
ツールの問題より先に、目的の共有が必要です。
公式の社内浸透ガイドでは、「役員や影響力のある人をキーパーソンとして巻き込む」「フィードバックを反映させてユーザーが主体的に育てる参加感を作る」「入力できない人を1人も取りこぼさない工夫をする」ことが推奨されています（出典）。
現場スタッフが「自分たちが改善に関わっている」と感じられる仕組みが、長期的な定着につながります。1人の担当者だけが使い続けるシステムより、チーム全体が少しずつ改善していくシステムの方が、最終的には使われ続けます。
定着と並行して、アプリの管理ルールも整えておきましょう。kintone SIGNPOST「アプリ作成ルール」では、各現場が自由にアプリを作成すると「構造の複雑化を招く」「アプリ管理の引き継ぎができていない状況も起きやすい」と指摘しています（出典）。
「使いにくい」の本体：kintoneで実現しにくいことと対処法
改善を進める中で、「設計の問題ではなく、そもそもkintoneでは難しいことかもしれない」と気づく場面があります。正直にお伝えします。
kintone標準の限界①：複雑な承認フロー
kintone標準のプロセス管理では、「議決承認」（複数人の多数決で決める）や「承認スキップ」（条件によって承認者を飛ばす）は実現できません（kintone SIGNPOST 3-25 出典）。
ただし、公式ヘルプにも「プロセス管理は設定が複雑になりがちです。実装前に業務フローを図式化することでスムーズに設定できます」とあります（出典）。「業務フローの整理が先、機能の実装は後」という順番を守るだけで、標準機能で十分なケースも多くあります。
kintone標準の限界②：帳票印刷
請求書や発注書などの帳票フォーマットへの出力は、標準機能では対応していないため、帳票出力が必要な場合は帳票プラグイン（別途ご契約が必要）を検討することになります（出典）。費用はプラグインのベンダーにより異なります。
kintone標準の限界③：大量データの処理速度
フィールド数が100を超えるアプリや、数万件規模のレコードが蓄積した場合、表示速度に影響が出ることがあります（出典）。アプリの分割設計やフィールド数の整理で改善できるケースがあります。
UIの改修は「慣れが解決するか」を先に確認する
「もっと見やすい画面に変えたい」という要望から、JavaScriptでのUI改修を検討することがあります。しかし公式は「現場メンバーの要望の多くが旧システムへの慣れに由来し、新システムに適応すれば解決する場合がある」と指摘しています（kintone SIGNPOST 3-29 出典）。
UIの大幅な改修はkintoneのアップデートの影響を受けやすく、改修を維持・更新できる技術者がいなくなった場合に困る事態も起きます（kintone SIGNPOST 5-38 出典）。「大規模なカスタマイズは専用システムを導入するより高くつく可能性がある」という点も、意思決定前に押さえておきたい事実です（出典）。
社内改善が限界を感じたら——伴走支援という選択肢
設計の見直しを自社で試みたものの、「何をどう直せばいいか判断できない」「直しても使われない」という状態になったとき、外部の伴走支援という選択肢があります。
外部支援を検討するタイミング
次の状況に当てはまるなら、外部に相談するタイミングです。
| 状況 | 背景にある問題 |
|---|---|
| 自社で修正を試みたが2〜3か月経っても改善しない | 設計の根本的な見直しが必要かもしれない |
| 「どこが問題か」の特定に確信が持てない | 業務フローごと整理するサポートが有効 |
| 担当者が設計を直し続ける時間を確保できない | 担当者のリソース問題として外部化が現実的 |
サイボウズ公式は、パートナーへの相談を特に推奨する場面として次の4つを挙げています（出典）。
| # | 場面 |
|---|---|
| ① | やりたいことが実現できるかイメージがわかない |
| ② | 業務課題はあるが、改善方法がわからない |
| ③ | 社内定着・利用促進で困っている |
| ④ | 他システムと連携した一気通貫のシステムが必要 |
③の「社内定着・利用促進」は、まさにこの記事で扱っている問題です。
「業務の言葉のまま」整理できる相手かを確認する
外部支援を依頼する際に大事なのは、kintoneの技術力だけでなく「あなたの業務を理解した上で一緒に設計を見直してくれるか」です。「帳票印刷が必要」「現場スタッフが承認フローに慣れていない」「建設業の日報・原価管理に使いたい」——こうした文脈を持ち込んで、「今のアプリ構成のどこがおかしいか」から整理してもらえる相手かを確認することが選び方のポイントです。
外部委託先を選ぶ際のチェックポイントはkintone外注時のチェックリストで、伴走支援の具体的な進め方はkintone伴走支援ガイドでそれぞれ解説しています。
pullieは認定パートナーではありませんが、建設・不動産の現場実務を経験したエンジニアが、現場の言葉のまま要件を整理し、kintoneの設計に落とし込む伴走をしています。「今のアプリ構成を一緒に見直したい」という場合は、無料相談から現状をお聞かせください。
まとめ：kintoneは「設計」で8割決まる
「kintoneが使いこなせない」「使いにくい」の原因を振り返ると、ほとんどのケースはアプリの設計の問題です。
- フィールドが業務の流れに合っていない
- 「なぜ入力するか」が現場に伝わっていない
- 現行の複雑なフローをそのままkintoneに移している
これらは、設計を直すことで改善できます。75点のアプリで始めて、現場のフィードバックをもらいながら少しずつ育てていく——この進め方がkintone定着の王道です。
標準機能の限界（複雑な承認フロー・帳票出力）にぶつかった場合も、カスタマイズを検討する前に、まず業務フローの整理をしてみてください。「設計を変えるだけで解決できた」というケースは、思った以上に多くあります。
「機能の問題ではなく、設計の問題だった」と特定できれば、上司への説明も変わります。「何をどう直せば使われるようになるか」が具体的に見えることが、kintone投資を回収するための出発点です。
