エンジニアがkintoneを触って感じた3つの注意点と、それでも選ぶ理由

先日の記事を振り返りつつ、学び始めた背景を確認します。

https://knowledge.heritage-arrow.jp/2025/10/30/why-i-started-learning-kintone-and-what-i-know-now/

先日、中小企業において、紙やExcelで運用している業務をデジタル化したい状況があり、ノーコードツール kintone を利用したシステム開発が有力な選択としてあがった話をしました。

実際にエンジニアとして活動してきた私は、さまざまな方法を駆使してkintoneを学んでいます。実際、どの程度の運用であれば耐えられるか、を知りたいと思っていました。今回、実際に触ってみて感じたことを整理していきます。

実際に触って感じたこと

1. 構成管理の不安が大きい

簡単な機能を一通り触ってみて気になったことがいくつかありました。それらを列挙して紹介していきます。

• マイグレーション履歴が残らない。
  • 運用中にスキーママイグレーションを実施することはよくある。
  • しかし、画面をポチポチしてると、その履歴がない状態になります。
• デプロイが管理できない。
  • 普通のWebシステム開発では、デプロイを自動化するし、承認ワークフローを組んだり、ロールバックできる状態にします。CI/CDも組みます。
  • しかし、kintoneではそれが難しく見えます。
• バックアップ機能が弱い。
  • ユーザー側でリストアができないので、間違えた時に戻せません。
  • 手動バックアップはCSV・Excelエクスポート中心になります。
  • これではリストアも色々手間がありますし、開発環境を作りにくいです。

総じて、手動運用でカバーが中心になると思います。この状況を見ると、エンジニアとして感じる不安が多々ある。これで本当に運用に突入して大丈夫でしょうか？サードパーティツールを使ったり、APIを活用することは考えられます。しかし、現実的には、運用マニュアルを作って、手動で運用することになるように見えます。

2. 画面設計の判断が難しい

軽く触ってみて、画面設計の判断が難しいと思いました。

• まず、どこまで真面目に設計すべきか迷います
  • そもそも、UI・レイアウトの設計は難しいです。
  • kintoneではデータの属性とカラム名、制約と一緒にレイアウトやUIを作ることになリります。
  • 前者のデータ周りは、きちんと考えれば終わりますが、UIは簡単ではないように見えます。
• カスタマイズの沼にハマるリスクがあります
  • 主観ですが、簡単に修正、調整できるが故に、油断すると時間を食ってしまうな気がしています。
  • 例えば、テキストフィールドの横幅がどれくらいか、というのは、運用開始までに、細かい調整が必要な部分かどうかは怪しいように見える。
  • 本質的ではない議論に時間を費やしてしまうリスクがあります。
• フルスクラッチとの感覚がズレる
  • CSSやデザイン、レイアウトのパターンがなんというか、Webの管理画面UIとしてよくあるものと、kintoneでよくあるものは微妙に違う気がします。
  • このデザイン・UIでいいのか？というのが、感覚的にわからず判断が難しくなってます。

総じて、データ周りはなんとなく設計できそうに見えますが、画面周りの設計が沼になりそうに見えてます。画面は時間制限を作ってその中でできたもので進む、くらいにしておく方が良さそうに見えます。

3. 「社内でメンテできる」のは幻想？

そもそもの話として、「社内でメンテできる」というのは幻想に見えています。

• ノーコードツールの売り文句は「社内でメンテできる」ですが、ここに疑問がわく
  • そもそも社内でメンテできるようにしたいからノーコードを選択しています。
  • なので、社内でメンテできないのであれば、「ノーコードである意味とは？」となります。
  • そして、ここまで検討してくると「本当に社内でメンテできるのか？」という疑問も湧いてきます
• ノーコードツールでも、システム開発の本質的な難しさは変わっていません。
  • ノーコードツールを使ったとしても、要件定義や基本設計は行う必要があります。
  • だとすると、実際にシステムを作るためには、設計思想を理解できる人が必要になります。
  • 設計するためにはkintoneの設計思想の理解が必要です。じゃあそれは誰？となります。
  • また、既存システムを理解していないと、変なシステムの拡張になります。
• 結局のところ、社内でできるメンテナンスは一部だけ
  • 社内でできるのは、カラム名の調整とか、追加とか、そのレベルかもしれません。
  • そうなると、「微調整できる安心感」程度の価値かもしれません。
  • さらに、マイグレーション管理やバックアップ管理が弱いとなると、それをどう考えるか問題も出てきます

それでもkintoneを使う理由

説明しやすさに価値がある

• 実際にkintoneを触りつつ、顧客と話をして思うこと
  • 顧客と画面を操作しながら要件をすり合わせられるのは強い
  • 「これ」を指さして会話できる。
• システム開発初心者と、設計の議論がしやすい
  • そもそも、システム開発初心者と、データ構造を議論するのは難しい
  • しかし、kintoneを見ていると、データについても、話のイメージがつきやすい
  • デザインではなくて、フィールドの話をしやすい
• 検証ツール・プロトタイピングとしての強み
  • 何をどう決めなければならないのか、と選択肢が画面上で見え説明不要である
  • kintoneに設置できるフォームのフィールドは、当たり前だがフルスクラッチもで使える
  • kintoneの制約の中でプロトタイプを作れば、そのテーブル構造でフルスクラッチに持っていきやすいように見える

持続可能性を考えて、の技術選定

• 結局のところ、kintoneでプロトタイプを作って運用を確かめた後に、自分でコードを書いてしまう方が管理は楽でトータルコストも少ないかもしれない
• とはいえ、自分でコードを書いてしまうと、地方で後任エンジニアが見つかるのか、問題が出てくるとも思っている。そう考えると、kintoneの方が人を見つけやすい可能性もある
• 私たちは和歌山県で活動していますが、和歌山は堅実な経営をする文化があるように見えている。それにマッチするような堅実な技術選択は何だろうか、が今の問いである。

締めの話

• 私はプロとして、顧客の事業の持続可能性を損なわない判断を提案するのが重要だと考えている。その観点から今後も検討は続く。
• さて、11/17に和歌山市のコワーキングスペースにて、kintoneの勉強会を開催します。そこで、さらに深掘りする予定です。
• 興味のある方はぜひ参加してみてください。