第1章では、サイボウズが解いてきた四つの詰まりを追い、その答えが「データベース・プロセス管理・コミュニケーション」という三層に集約されることを予告しました。この章では、その三層の内側に踏み込みます。
kintoneはしばしば「ノーコード業務アプリ」と紹介されます。間違いではありません。ただ、その呼び名は製品の外形を指しているだけで、なぜそれが現場で回るのかを説明しません。ノーコードという語で語れるのは道具の話であり、kintoneが本当に動かしているのは主語の話です。この章では、その主語の交代を可能にしている構造を分解していきます。
世の中には数多くのノーコード・ローコードツールが存在します。Microsoft Power Platform、Airtable、Notion、Lovable、v0、Bolt。いずれも「プログラミングの敷居を下げる」ことを価値として掲げています。アプローチの違いはあれど、共通しているのは作り手の裾野を広げるという設計思想です。開発者の一歩手前の層、あるいは開発者の隣にいる人を、もう少し作り手側に引き寄せる。多くのノーコード製品は、この方向で進化してきました。
kintoneがこの系列の中で異質に見えるのは、裾野を広げる発想に立っていないからです。kintoneが目指したのは、作り手そのものを現場に移すことでした。開発者を減らすのでも、開発者を広げるのでもなく、業務の中心にいる非IT部門の人間に、作り手の役を渡す。非IT部門での導入比率93%という数字は、この設計意図が現実の運用になって現れた結果です。ノーコードが「誰でも作れる道具」の話なら、kintoneは「現場が作り手になる基盤」の話です。
両者は似て非なるものです。道具としてのノーコードは、スキルの問題として語られます。一方、主語を現場に移すという話は、誰が業務を動かすかという構造の問題に踏み込みます。第1章の終わりで「改善の主語が変わった」と書いたのは、この構造の交代のことでした。ではその交代は、何によって可能になっているのか。kintoneをノーコードと呼んで済ませていては、この問いに答えられません。三層の内側に戻る必要があります。
kintoneの基盤は、三つの層が同じ場所に重なって動く構造になっています。第1章で予告した形のまま、本章でも同じ基準点として置きます。
この三層は、機能を並べたものではありません。業務というものが実際に回るときに必要な三つの動作を、そのまま層に置き換えたものです。人間が組織の中で仕事をするとき、そこには必ず事実と手続きと会話が同時に走っています。受注の記録という事実がまずあり、それを誰がどう処理するかという手続きが動き、その合間で担当者どうしの短いやり取りが残る。この三つが欠けずに回って、はじめて業務は一周します。
日本企業の現場で起きてきた詰まりは、おおむねこの三つが分断されたところで発生していました。データはExcelに、手続きは紙と押印に、会話はメールとチャットに。別々の場所に散ったまま連動していない。連動させるには人間が頭の中で三つを突き合わせる必要があり、その作業が属人化と遅さの温床になっていました。
世界の業務ソフトウェアは、この三層をそれぞれ別の製品として切り出しています。Airtableはデータベース層を洗練させ、ServiceNowやSalesforce Flowはプロセス管理層を突き詰め、Slackや社内SNSはコミュニケーション層を磨いてきました。それぞれが自分の領域では優れています。ただ、業務がそれらを横断するたびに、組織はまた連携の設計をしなければなりません。
kintoneの設計はここで分岐します。三層を別製品で最適化するのではなく、ひとつの基盤の上に同時に載せる。アプリひとつを作ると、その中にデータベースとワークフローとコメント欄が標準装備として組み込まれる。この束ね方は、機能の足し算ではなく、業務の自然な動作をそのままソフトウェアの単位にしたという設計思想の表明です。
三層統合は、思想として語るとスローガンに聞こえます。ただ、kintoneで起きていることの本質はスローガンではなく、物理設計の話です。
通常の業務システムを開発する場合、設計者は三層を別々に組み立てていきます。最初にデータモデルを設計し、テーブルとリレーションを定義する。次にAPIを用意し、画面から呼び出せる形に整える。UIを実装し、画面遷移を設計する。そこにワークフローエンジンを組み合わせ、承認ルートを定義する。通知の仕組みを足し、最後にコメント機能や履歴機能を別モジュールとして乗せる。一連の工程はそれぞれ別の技能を要し、別のレイヤーとして積まれていきます。
この積み方は開発者にとっては自然ですが、現場の担当者にとっては越えられない壁になります。業務を知っている人間が、その知識だけで業務アプリを立ち上げることはできません。どこかで必ず、IT部門やベンダーの手を借りて層をつなぐ作業が発生する。直したい人と直せる人のあいだの距離は、この積み方がそのまま残している距離でもあります。
kintoneがやっていることは、この積み方を根本から省略することです。アプリを一つ作ると、その時点でデータベース層とプロセス管理層とコミュニケーション層が同時に立ち上がります。項目を定義すればテーブルができ、プロセス管理を有効にすればワークフローが走り、レコードごとにコメント欄が自動で用意される。設計者が三層を順番に組み立てる必要がない。三層があらかじめ一枚の基盤として束ねられているからこそ、現場の人間はその束の中で業務を設計すれば足りるのです。
この物理的な束ね方が、現場主導DXを成立させている技術的な核です。プログラミングを覚えなくていいからではありません。三層の分離という、本来なら開発者でなければ越えられない壁が、基盤の側であらかじめ畳まれているからです。非IT部門比率93%という数字の背後にあるのは、意欲の高い現場の集まりではなく、層の分離作業を現場が飛ばせる構造そのものです。この構造の強さは、使い手のスキルではなく、設計の選択に宿っています。
三層が内側だとすれば、外側には三つの接続口があります。プラグイン、API、コミュニティ。いずれも三層という中心軸があるからこそ成立しているものです。
プラグインは、三層を拡張する口です。標準機能では届かない領域、たとえば業種特有の計算、外部サービスとの連携、UIの拡張を、サードパーティが製品として補う。現場が自作するアプリの横に、パートナー各社の蓄積が並ぶ構造になっています。APIは、三層を外部から叩く口です。kintoneのレコードを他のシステムから読み書きできるようになっており、2025年に正式対応したMCPサーバーを含めて、外部のアプリケーションやエージェントがkintoneを一つのレールとして参照できる。コミュニティは、三層の使いこなしが組織の外に蓄積される場です。ユーザーコミュニティ「キンコミ」、自治体のための「ガブキン」、大企業20社のEnterprise Circle。同じ三層を触っている人間どうしが、運用の知恵を持ち寄る場所が制度として整えられています。
この三つの接続口が揃っていることの意味は、機能の厚みではありません。三層という中心軸があるから、周辺が自律的に育っていくという構造上の事実です。中心が定まっていない基盤では、プラグインは場当たり的な拡張に終わり、APIは用途が散らばり、コミュニティは話題の共有点を失います。三層が動かない基準として据えられているからこそ、外側の生態系が中心に向かって蓄積していく。
なぜこの外側の広がりが単なる機能拡張ではなく競争優位として機能しているのかは、次章のmoat本論で扱います。本章の範囲では、三層の外側に接続口が制度として存在しているという構造事実だけを置いておきます。ここまでの話は、kintoneの「内側」を見てきました。その内側は、孤立した設計ではなく、外側に開かれているということ。これが次章への接続点になります。
第1章の最後に、「改善の主語が変わった」という言い方をしました。IT部門が現場に改善を提供する構造から、現場が自分で改善する構造へ。その主語の交代を可能にしていたものの正体が、ここまでに見てきた三層の統合構造です。
「直したい人と直せる人が一致していない」という状態は、多くの日本企業が抱える構造的な課題でした。業務を一番知っているのは現場で、システムを動かせるのは情報システム部門やベンダー。この二者のあいだに、三層の分離作業という越えられない壁が横たわっていた。人材を増やしても、教育を強化しても、壁の高さ自体は変わりません。kintoneがしたのは、人材の問題を解くことではなく、壁そのものを設計の側で下ろすことでした。
だからkintoneの本質は、ノーコードという形容ではうまく捉えられません。ノーコードだから現場主導DXが回るのではなく、三層の統合が主語の交代を物理的に可能にしているから回る。構造としての答えが先にあり、ノーコードはその結果として見えている表面にすぎません。
現場が自分の仕事を自分で作り変えられるというのは、比喩ではなく、kintoneの設計そのものの記述です。事実と手続きと会話がひとつの基盤で束ねられ、その束を現場の言葉で組み替えられる。第1章で見た四つの詰まりが、この一枚の基盤の上でほどけていく。kintoneの正体は、この束ね方にあると言い切って構いません。