kintone設計の失敗談～100アプリ作った会社のリアル～

はじめに：まずは「作ってみる」から始まるkintoneの魅力

業務のDX（デジタルトランスフォーメーション）を進める上で、多くの企業が注目しているのが「kintone（キントーン）」というクラウド型業務アプリ構築プラットフォームです。プログラミング不要で誰でも簡単に業務アプリを作ることができ、すぐに実務へ活かせる点が大きな特徴です。

私たちミヨシテックでも、kintoneの導入当初はまさに「とりあえず作ってみる」ことからスタートしました。専門的な知識がなくても作れるkintoneは、各部門で業務改善にチャレンジしやすいツールであり、「現場の声をそのまま形にできる」ことが魅力でした。

実際に、最初は社内の数名が使っていたkintoneですが、アプリの数が増え、利用者が増えるごとに全社的なツールへと発展。現在では100人規模の組織で700以上のアプリが稼働し、日々の業務に欠かせない存在となっています。

しかし、使えば使うほど見えてくる課題もありました。特に「アプリの設計」に関しては、現場の改善意欲がそのまま反映されるがゆえに、便利さと混乱が表裏一体となる場面が出てきたのです。

本コラムでは、私たちが100件以上のアプリ開発を通じて実際に経験した「kintone設計の失敗パターン」と、それをどう乗り越えてきたかを紹介します。これから本格的にkintoneを使いたい方、すでに活用している企業担当者の方にとって、設計改善や属人化防止のヒントになれば幸いです。

“とりあえず作る”から始まる成長と、その先にある課題

kintoneの導入初期段階において、「とりあえず作ってみる」は非常に有効な戦略です。考える前に形にできることは、現場にとって大きな推進力となります。

私たちミヨシテックでも、営業日報、見積管理、設備点検記録、問い合わせ管理など、次々にアプリを作成しました。簡単に作れることで、部署ごとに独自の改善が進み、業務の属人化解消や情報の一元管理が実現しました。

しかし、次のステージに進むと見えてくるものもあります。

とりあえず作ったアプリが「現場にフィットしているのか？」「使いにくくなっていないか？」という検証のタイミングが訪れます。ここで設計を見直さずに放置してしまうと、次第に以下のような問題が発生します。

「項目が多すぎて、どこに何を入れればいいかわからない」
「誰が見ても同じように使えるアプリになっていない」
「入力されたデータが活用できない（グラフ・集計に反映されない）」

つまり、「使いながら育てていく」という視点が必要になるのです。

ミヨシテックがぶつかった“よくあるアプリ運用の壁”

フィールド過多の弊害：必要だけど“誰にとって”？

代表的な例が「問い合わせ管理アプリ」です。このアプリは全部署で使用しています。当初はシンプルな構成でしたが、運用する中で各部署がそれぞれに必要な項目を追加していった結果、現在では30フィールド以上が並ぶ状態に。

問題は、それぞれの項目が「ある部署には必要」「別の部署には不要」であること。誰がどの項目を入力すべきなのかが曖昧になり、全体として「わかりにくいアプリ」に変化してしまったのです。

さらに、「問い合わせ経路」と「認知経路」の定義がごっちゃになってしまい、チェックを入れる基準が人によってバラバラ。
その結果、グラフ化した際に実際の傾向と異なる誤解を生むデータとなってしまうケースもあります。

フィールド型・入力形式の不統一

たとえば「従業員名」の入力フィールド。

あるアプリではルックアップで従業員マスタから情報を引っ張っているのに対し、別のアプリではフリーテキストで名前を入力するようになっている。そのため、ある人は「山田」、別の人は「山田太郎」、さらに「やまだ」など表記がばらばら。

部署名に関しても同様で、「営業部」と記入する人と「営業」と略す人が混在。こうなると検索やグラフ集計、さらにはRPA連携の際に正確な判別ができません。

こうした“小さな設計の違い”が業務全体の非効率につながるということを、私たちは身をもって体感しました。

アクセス権の属人化は体制で回避

アプリごとのアクセス権限設定が細かくできるのもkintoneのメリットですが、それが裏目に出ると「誰が何を見られて、誰が編集できるのか」が不透明になることも。

実際、役員専用のアプリなどでは、アクセス権が特定のメンバーだけに限定されており、構成が“ブラックボックス化”してしまう事例がありました。

しかしミヨシテックでは、すべてのアプリに必ずシステム部のユーザーを管理権限として付与するルールを設けています。
これにより、アプリ作成者が異動・退職しても、最悪の場合でもシステム部で管理・修正が可能な体制を確保しています。

設計の見直しに向けて、始めた3つの取り組み

設計基準の明文化
出口設計からの逆算
ロール単位のアクセス権管理

この3つを軸に、アプリの品質と運用の安定性を向上させています。

属人化を防ぐ体制づくり：今やっていること

kintoneに関するセミナーの受講
社内での「kintoneリーダー会」を開催

ミヨシテックでは、kintoneを自ら作れる社員同士が集まり、
作ったアプリを持ち寄ってレビューし合う場——「kintoneリーダー会」を定期的に開催しています。

「この画面見づらくない？」
「もっと項目絞れるんちゃう？」
「そのフィールド型、こっちの方が集計ラクかも」

といったフィードバックを通じて、設計の質を社内全体で底上げしています。

成功するアプリに共通する“3つの視点”

700アプリ以上を見てきて、特に「これはうまくいっているな」と感じるアプリには、共通点があります。

一覧やグラフなどの最終出力から逆算された設計
利用者にとって入力のハードルが低いシンプルな構成
権限管理がロールベースで組まれていて柔軟性がある
改善サイクルが回っている（リーダー会での継続的レビュー）

まとめ：とりあえず作る、その後に見直し・育てていくことがkintone活用の鍵

kintoneは、その圧倒的な手軽さと自由度の高さによって、誰でも「とりあえず作ってみる」ことができる、優れた業務改善ツールです。だからこそ、導入初期には「完璧なアプリを作ろう」と構えすぎず、まずは小さく始めてみることが大切です。

実際に私たちミヨシテックも、最初は業務の一部分からアプリ化を進めるところから始まりました。「まずはやってみる」「とりあえず使ってみる」——その姿勢が、多くの現場改善につながり、社内全体へのkintone普及を加速させました。

しかし、ある程度のアプリ数が蓄積され、ユーザーが全社的に広がってくると、状況は少しずつ変わってきます。

部署間で項目の定義がずれる
入力の手間が増えて使われなくなる
一覧やグラフが見づらくなり、データ活用が停滞する
属人化により、改善やメンテナンスが進まなくなる

こうした課題を放置したままだと、せっかくの内製アプリが“情報の墓場”になりかねません。

だからこそ、一定の運用フェーズに入ったら、「設計を見直す」「運用ルールを整える」「属人化を防ぐ仕組みをつくる」といった“育てる視点”が求められるのです。

アプリは作って終わりではありません。使われ、改善され、育っていくからこそ、その真価を発揮します。
設計・運用・改善——このサイクルを回せるかどうかが、kintoneを企業のDX基盤として根付かせられるかどうかの分かれ道になります。

私たちミヨシテックも、過去に作ったアプリの数々を、今まさに見直し・再設計している段階にあります。
そのプロセスで得たリアルな経験と知見を、今後kintoneを本格活用したい企業の皆さまと共有できればと願っています。

おわりに：kintoneの改善・設計相談もミヨシテックへ

アプリがごちゃごちゃして使いづらい
設計のルールが統一されていない
属人化でメンテできないアプリがある

そんなお悩みは、私たちが実際に直面し、改善してきた課題でもあります。

ミヨシテックでは、kintoneの導入から活用、再設計までを伴走支援いたします。
ぜひお気軽にご相談ください。

kintone設計の失敗談
～100アプリ作った会社のリアル～