kintoneを導入したのに、なぜか現場に定着しない。あるいは、これから導入するにあたって「うちも同じ失敗をするのでは」と不安になる。

そんな検索をした担当者に、先に伝えておきたいことがあります。kintone導入プロジェクトが失敗する確率を示すような公式統計は、実は公開されていません。「導入の何割が失敗する」といった数字に振り回される必要はないということです。

一方で、サイボウズ自身がこの不安に正面から向き合っている事実もあります。公式のノウハウ集「kintone SIGNPOST」は、経験豊富なkintoneユーザーの勘所を44パターンに体系化したコンテンツで、「目的設定」「プロジェクト計画」「設計・構築」「リリース・浸透」「運用」「継続的な計画」の6ステップで構成されています。つまり、「同じところでつまずく担当者が一定数いる」ことを前提に、公式が回避策をあらかじめ用意しているのです。

この記事では、公式ドキュメントが指摘する典型的な失敗パターンを3つに整理したうえで、導入前に確認できるチェックリスト、そしてすでにつまずいている場合の軌道修正の選択肢まで解説します。

失敗パターン1: 要件定義をせず始めて手戻りが発生する

kintoneは、ポータル画面の＋ボタンから数クリックでアプリが作れます。この手軽さが、実は最初のつまずきの原因になります。

kintoneアプリストアの新規作成画面。「はじめから作成」「Excelを読み込んで作成」など複数の選択肢があり、「はじめから作成」に「これを選ぶ」の注記が添えられている。

「とりあえず作ってみよう」で始めたアプリが、運用開始後に「あの項目が足りない」「この部署の業務フローと合わない」と手戻りを起こすケースです。kintone公式ガイド「kintoneの歩き方」も、「kintoneを入れただけでは課題は解決できません。まずは導入の目的を明確にしましょう」と明記しています。何を解決したくてkintoneを使うのか、導入前に言語化できているかどうかが分かれ目です。

ただし、ここで注意したいのは「完璧な要件定義をしてから着手する」という逆方向の失敗です。同じ「kintoneの歩き方」は、「100点満点を目指すのではなく、75点を目指して素早く実現しましょう」「運用中でも日々カイゼンできます」とも述べています。要件定義に時間をかけすぎて着手が遅れることも、社内浸透を遅らせる要因になり得ます。

もう一つの分かれ目は、要件を検討する順番です。kintone SIGNPOST「基本機能から考える」は、「『カスタマイズ開発で実現できることか？』ではなく、『カスタマイズ開発でしか実現できないことか？』を確認する」ことを推奨しています。要件定義の段階で「まずkintoneの標準機能で足りないか」を確認する順番にしておくと、後述する過剰カスタマイズの失敗も同時に防ぎやすくなります。kintoneアプリの作り方を3ステップで解説では、実際の構築プロセスで要件をどのように検証していくかが解説されています。

着手前に自問したいのは、「目的は明確か」「75点で一度動かす前提になっているか」「標準機能で足りるかを先に確認したか」の3点です。

失敗パターン2: 推進担当者が孤立し社内展開が止まる

要件定義がうまくいっても、次に多いのが「担当者一人で抱え込んでしまう」失敗です。

推進担当者1人体制とチーム体制の比較

kintoneの歩き方は、社内浸透が失敗する典型として「担当者が自分しかいなかった」ケースを挙げ、「チームで進めると、浸透も早い」と複数人体制を推奨しています。一人で全アプリを設計・保守していると、次のような悪循環に陥りやすくなります。

複数人体制の構築方法や、内製と外注のバランスについては、kintone開発は内製か外注か？費用と定着率で見極める選び方に詳しく述べられています。

実際、kintone SIGNPOSTの「担い手を増やす」でも、「いつまでも同じメンバーのみでkintoneアプリの作成や運用をしていては、増えていく現場の要望に対応することができない」と指摘されています。同パターンが挙げる対策は、次の3段階です。

  1. 利用者・機能範囲をあらかじめ設定する
  2. 各部署に一人はアプリを設計できる人材を育てる
  3. 社内共有会を実施する

また、kintoneの歩き方は「『使いづらい』を放置せず、現場の声に耳を傾けることは、さらなる改善のチャンス」ともしています。担当者が一人だと、この「現場の声を拾う仕組み」自体が抜け落ちがちです。次の章のチェックリストでも、体制の観点として扱います。

失敗パターン3: 過剰カスタマイズで保守できなくなる

3つ目は、要件定義や体制の問題をクリアした後にも起こりうる失敗です。「これまでのExcelや紙の運用を、そっくりそのままkintoneで再現しよう」とすると、カスタマイズが際限なく膨らみます。

kintone SIGNPOST「業務のkintone化」は、「過去の業務プロセスを踏襲するためのカスタマイズ開発が、開発工数・開発期間・保守コストを増大させてしまう」と明記しています。旧システムの操作感を忠実に再現しようとするほど、開発と保守の負担は増えていくということです。

「JavaScript / CSSでカスタマイズ」画面。JavaScriptファイルとして「pullie_demo_chips.js」が1件追加され、すべてのユーザーに適用する設定になっている。

実際のカスタマイズ開発にかかる費用については、kintone構築費用の相場と内訳を徹底解説で具体的な相場が示されています。

さらに厄介なのは、無理なカスタマイズが将来の足かせになる点です。同じくSIGNPOST「ほどほどのUIカスタマイズ」は、kintoneが推奨しない実装方法に依存すると「kintoneのアップデートの影響を受け、カスタマイズした部分が想定通りの動きをしなくなる可能性がある」と注意を促しています。そのうえで、検討の順番を次の3段階で示しています。

検討順対応方法
1フォーム設計（標準機能）で対応できないか
2プラグインの活用で対応できないか
3本当に必要な部分だけカスタマイズ開発する

いきなり3番目から検討を始めてしまうことが、保守できないシステムを生む典型パターンです。「このカスタマイズは本当に必要か」を、この順番で一度立ち止まって確認するだけで、将来の保守コストは大きく変わります。

失敗を防ぐ導入前チェックリスト

ここまでの3パターンを、導入前にチェックできる形にまとめました。

導入前チェックリスト(要件定義・体制・カスタマイズ方針)

要件定義

推進体制

カスタマイズ方針

すべてに完璧に答えられる必要はありません。むしろ、答えられない項目が「今、何を優先して手を打つべきか」を教えてくれます。

導入後に軌道修正する場合の選択肢

すでに導入が進んでしまっていて、「今さら要件定義からやり直すのは現実的でない」というケースもあるはずです。その場合は、次の3つの選択肢を段階的に検討できます。

軌道修正の選択肢(振り返り・自社点検・パートナー伴走)をコストと効果で位置づけた図

1. まずは社内で振り返る

kintone SIGNPOST「継続的な振り返り」は、軌道修正の入口として次の3項目を挙げています。

2. 自社でアプリの状態を点検する

過剰カスタマイズや項目の肥大化が疑われる場合、外部に依頼する前に「今あるアプリの中身」を自分たちで棚卸しすることもできます。たとえば筆者らが提供している「フィールド棚卸し」は、アプリ内のフィールドコード・ラベル・型・必須設定・計算式を一覧化し、直近レコードの入力状況から使用中・低使用・未使用を自動判定するツールです。人手で全アプリのフィールドを見直す前段階として、どこが肥大化しているかの当たりをつける用途に使えます。

3. 社外のプロに伴走を依頼する

自社に構築知見が十分にない場合は、外部の力を借りるという選択肢もあります。kintone SIGNPOST「プロの伴走」は、組織内に構築知見がない場合「機能の使いこなしや基本機能での実現可否、連携サービスの選定などの判断が難しく、時間がかかることがある」とし、公式パートナー企業への伴走依頼や、サイボウズ自身によるパートナー選定支援サービスの活用を挙げています。どこまでを自社で巻き取り、どこから外部に頼るかは、上記1・2の振り返りの結果次第です。kintone伴走支援とは？外注・内製化支援との違いと費用感では、伴走支援の進め方や選定基準について詳しく述べられています。ここでつまずいたら、無料相談で今のアプリの画面を見ながら一緒に整理することもできます。

まとめ

kintone導入の失敗は、「要件定義をしないまま見切り発車する」「推進担当者が一人で抱え込む」「過去の業務をそのまま再現しようとして過剰カスタマイズに陥る」という3つのパターンに集約されます。いずれも、サイボウズ自身が公式ノウハウ集で言及している、再現性のあるつまずきです。

裏を返せば、この3つは事前にチェックリスト化できる失敗でもあります。導入前ならチェックリストで芽を摘み、すでに進んでしまっている場合は「振り返り→自社点検→伴走依頼」の順で軌道修正すればいい。手順を知っているかどうかで、避けやすさは大きく変わります。