やっと暑すぎる夏も終わりかけてきましたね！
こんにちは！ 松田軽太です。
さて、先日、このポストでちょっとした盛り上がりがありました。
「システム開発未経験者の僕がkintoneでシュシュっと基幹システムを作っちゃうぞ！」って張り切ってる案件。
— 松田軽太【ほぼ公式】 ゆるフワ系DX （ソリュエイ亭門下生）5550 (@matudakta) 2025年9月18日
これは…ヤバいkintoneの使い方では… https://t.co/y1nDcIt2lt
ChatGPTに「この件をベースにブログを書きたいんだけど」と相談したら、ほぼ完成形を出してくれました。
手を入れる必要もない完成度なので、このまま載せちゃいます。
なぜkintoneで基幹システム刷新は危険なのか
最近X（旧Twitter）でちょっとした話題になったポストがありました。要約すると——
システム開発経験のない他部署の管理職が、部下に触らせていたkintoneで「基幹システムを置き換えられる！」と会社に宣言。役員が真に受け、インターン70名体制で開発を始めることに…。しかも対象は国のインフラ関連システム。
この投稿に対して、私も「これはヤバいkintoneの使い方では…」と一言つぶやいたのですが、多くの反響がありました。寄せられた反応を整理すると、大きく3つの方向性が見えてきます。
-
設計や要件定義を飛ばしていることへの懸念
-
kintoneの強み・弱みを理解せず「魔法の杖」と誤解していることへの冷ややかな目
-
基幹システムという重要領域でそれをやることへの恐怖感
この記事では、なぜ「kintoneで基幹システム刷新」は危険なのかを整理してみたいと思います。
kintoneは何が得意で、何が不得意か
まず誤解してはいけないのは、kintone自体はとても便利なツールだということです。プログラミング経験がなくても画面を作り、業務フローをすばやく改善できます。社内の小さな業務改善や、部門レベルでの情報共有には非常に強みを発揮します。
ただし、kintoneは「業務改善ツール」であって「基幹システム刷新ツール」ではありません。スピードと柔軟性に優れる反面、以下のような領域は不得意です。
-
高い可用性や信頼性の担保（止まったら会社が止まるレベルのシステム）
-
長期運用を見据えた保守・拡張性
-
複雑な権限管理やセキュリティ要件
-
他システムとの大規模・複雑な連携
つまり「現場の困りごとをすぐ解決する」には向いていますが、「会社の心臓部を置き換える」用途には根本的に適していないのです。
基幹システムとkintoneのギャップ
基幹システムに求められるのは以下のような要件です：
-
止まらないこと（24/7稼働）
-
長期安定運用（10年、20年単位で利用）
-
厳格なセキュリティと権限管理
-
高い信頼性とデータ整合性
-
法規制・業界基準への準拠
これらは「画面をポチポチ作る」だけでは対応できません。むしろ設計・要件定義・テスト・運用設計といったソフトウェア工学の基礎が欠かせません。ここを飛ばして「ツールが簡単に使えるから大丈夫」と考えるのは非常に危険です。
危険な理由
では、なぜ「kintoneで基幹刷新」が危険なのか。ポイントは4つあります。
-
道具への過信
「簡単に画面が作れる」→「基幹もいけるやろ！」という思考の飛躍。 -
設計不在
要件定義や設計を飛ばすと、あとから必ず破綻します。動くものは作れても、正しく動き続ける保証はありません。 -
人材リスク
インターンや未経験者に丸投げすると、知識が属人化し、引き継ぎ不能。数年後に誰も面倒を見られなくなる恐れがあります。 -
コストとリスクの肥大化
「安くできる」と思って始めても、結局は追加開発・トラブル対応・システム再構築に大きなコストが発生します。
事例紹介（失敗と成功から学ぶ）
❌ 失敗事例
事例1：販売管理システムを無理やりkintone化
中堅製造業A社は古い販売管理システムをkintoneに置き換えようとしましたが、在庫と受注の整合性が取れず、会計システムとの連携も失敗。処理が重くなり、最終的に再構築コースに。二重投資となってしまいました。
事例2：インターン主導で開発 → ブラックボックス化
サービス業B社では、インターンが複数のアプリを構築。しかし退職後にメンテ不能となり、「触ると壊れる謎システム」に。全社導入は断念しました。
👉 共通点：「基幹システムの置き換え」を狙ったことが失敗の原因
✅ 成功事例
事例1：経費精算フローをシンプルに
C社はExcelでやっていた経費精算をkintoneでアプリ化。申請・承認がスムーズになり、工数が3割削減。監査対応も効率化しました。
事例2：プロトタイプとして活用
物流系D社は新しい配送管理システムを導入する前に、kintoneで簡易アプリを作成し、現場で検証。その知見をプロが構築する本格システムに反映できました。
👉 共通点：「周辺業務の改善」「プロトタイピング」として活用したからこそ成功
正しいkintoneの使い方
ではkintoneはダメなのか？そんなことはありません。正しい使い方をすればとても有用です。
-
部門内の業務改善・効率化
-
ちょっとしたデータ管理や申請フローの自動化
-
本格システム導入前のプロトタイピング
-
既存の基幹システムを補完する「サブ的な役割」
つまり「小さく速く改善」には最適ですが、「会社の心臓を作り直す」には不向きなのです。
まとめ
-
kintoneは便利な業務改善ツールである
-
基幹システム刷新には根本的に向いていない
-
ソフトウェア工学の基本（設計・要件定義・テスト）は欠かせない
-
DXだからといって「ノーコードで全部！」は大事故につながる
Xでのやりとりは笑い話のように見えるかもしれませんが、国の基幹システムとなると笑えません。「便利ツール」と「基幹システム」を混同しないこと。これがDXを成功させるための第一歩だと思います。
＊＊＊＊＊＊
ChatGPT、すげー！
この完成度の文章をあっという間に書いてくれるんだもの。
数年後、どうなっているのか恐ろしくなりますね･･･
