CYBOZU TEXTBOOK
CHAPTER 01

何の問題を解いてきた会社なのか Four Stuck Points and the Three-Layer Answer

INFO · APPROVAL · EXCEPTION · FIELD
2026-04-23 INITIAL · AS OF 2025年12月期 · 約3,450字
サイボウズが売ってきたのは、ソフトではない。日本企業の“詰まり”をほどく手段だった。

サイボウズという会社を「グループウェアの会社」と説明する資料は多い。間違いではありません。ただ、その説明は会社の輪郭をなぞっているだけで、中身にはまだ届いていません。

この章で見たいのは、製品の集合としてのサイボウズではなく、解決してきた問題の集合としてのサイボウズです。

情報が共有されない。承認が止まる。例外処理で流れが崩れる。現場が改善できない。日本企業の現場で四半世紀にわたり鳴り続けてきた、地味だが深い警報音に、この会社はひとつずつ応答してきました。製品が先にあったのではない。詰まりが先にあったのです。

だから本章では、Office・Garoon・メールワイズ・kintoneという固有名詞をいったん脇に置き、「この会社は何を解いてきたのか」を四つの角度から見ていきます。章の終わりに、その四つが一本の糸でつながっていることを確かめる。その糸の名前が、次章以降の主役になります。


SECTION 1

「情報共有できない」という、地味で深い病

日本企業の現場では、情報共有の不全はたいてい大げさな言葉で語られません。部署ごとにExcelが散らばっている。意思決定がメールの末尾に埋もれている。隣の部署が何を抱えているのか、必要になったときにしか見えない。資料は個人のPCに眠り、業務はその人にだけ貼り付き、同じ質問が何度も繰り返される。症状はありふれています。だからこそ、病として認識されにくい。多くの組織で起きているのは、情報不足ではなく、情報流通の不全です。

この病の厄介なところは、症状が「遅さ」や「ミス」という別の姿で現れることにあります。意思決定が遅い。二重作業が起きる。新人の立ち上がりに時間がかかる。これらはしばしば能力や気合いの問題として処理されますが、実際には、情報がしかるべき場所に、しかるべき形で置かれていないことの結果にすぎません。属人化という言葉で片づけられがちな問題も、根は同じ場所にあります。

サイボウズが創業直後からこの領域に踏み込んだ理由は単純です。ここを解かない限り、他のどの業務改善も効かないからです。 掲示板、スケジュール、ポータル、ファイル共有。いま聞けば当たり前に見える機能群は、当たり前の情報共有を組織にインストールするために設計されてきました。

情報共有は地味です。派手な変革にも見えません。けれど、日本企業ではこの地味な層こそが最も欠けやすい。そして、承認が止まるのも、例外処理で流れが崩れるのも、現場改善が動かないのも、元をたどればすべて情報が流れていないところから始まっている。サイボウズはまず、その最下層から手をつけた会社でした。そこを飛ばした改善が、日本企業でことごとく空回りしてきたことを、おそらく誰よりも早く見抜いていたのです。


SECTION 2

承認フローという、日本特有の詰まり

情報が流れるようになっても、次の詰まりが待っています。承認が、止まる。

日本企業の承認は、欧米企業のそれとはそもそも形が違います。単に上位者がハンコを押す線形の流れではなく、回覧・稟議・根回しという層が重なり合った立体的な設計になっている。関係部署にあらかじめ声をかけ、懸念をつぶしてから正式な書類を回す。決裁者の手前でいったん止めて調整を入れる。書類の順番そのものに、組織の力学が埋め込まれている。

この構造は、外から見ると単なる非効率に映ります。実際、非効率な側面は確かにあります。しかし同時に、合意形成の品質を担保するための仕組みでもあり、少なくとも現場はそう運用してきました。問題は、仕組みの是非ではなく、この複雑な流れをデジタルでどう受け止めるかです。ここを粗く作れば、現場は紙とメールに戻る。実際、多くのワークフロー製品がここで敗退してきました。

サイボウズはこの領域に、二十年以上にわたって正面から取り組んできた数少ないベンダーです。Garoonは現在、7,500社・330万人に利用されており、阪急阪神ホールディングスでは40数社・約12,000名が共通基盤として運用しています。ITreview Grid Award のグループウェア部門では5年連続でLeaderを受賞。数千人から数万人規模の組織で、ポータル・掲示板・スケジュール・ワークフローが当たり前に動き続けているという事実は、機能の話ではありません。日本企業の承認文化をそのまま載せられる設計思想が、長年の運用を通じて磨かれてきたという事実です。

見落とされがちですが、グローバルSaaSがこの層をなかなか置き換えられない理由もここにあります。回覧順の組み替え、代理承認、差し戻しの戻し先、部門横断の合議──日本の組織が自然に行っている動作を、違和感なくデジタル化できるかどうか。日本語に訳せば済む話ではなく、組織運用の作法そのものを移植する設計が要ります。Garoonは派手な製品ではありません。しかし、派手でない領域で長く残ってきたことにこそ、この会社の一つの本質が現れています。


SECTION 3

例外処理が、すべてを止める

情報が流れ、承認が動くようになっても、現場にはまだ詰まりが残ります。例外処理です。

業務の大半は標準フローに乗ります。申請書のひな形があり、決裁のルートがあり、記録の残し方が決まっている。しかし、どの組織にも必ず「標準では処理できない案件」が一定割合で混ざります。特殊な顧客要望、例外的な取引条件、現場でしか判断できない細かな運用ルール。こうした例外は、全体から見れば少数派ですが、現場の時間を最も奪うのはこの少数派のほうです。

厄介なのは、例外処理が標準フローの外側にあふれた瞬間、業務が紙とExcelとメールに逆戻りする点です。せっかく情報共有を整え、ワークフローを整えても、例外が発生するたびに仕組みの外で処理されるなら、整備した基盤は迂回されていきます。多くの業務システムが「導入したのに現場が使わない」と言われる理由の相当部分が、実はここにあります。標準化を極めた製品ほど、例外に弱いという逆説です。

サイボウズの解き方は、この逆説を正面から引き受けています。SAPやOracleのような重厚長大な基幹系が業務を製品側の標準に寄せるアプローチを取るのに対し、kintoneは現場が自分で業務アプリを作れるという方向に振り切りました。非IT部門での導入比率は93%。例外処理は「減らす対象」ではなく「吸収する対象」だと前提そのものを置き直しているのです。標準化されない業務を標準化で殴るのではなく、標準化されないまま運用できる土台を用意する。例外が多いから現場が疲弊するのではなく、例外を受け止める場所がないから疲弊する──サイボウズは、この前提をひっくり返した会社でした。


SECTION 4

現場改善という、いちばん動かない領域

情報共有・承認・例外という三つの詰まりは、いずれも最後に同じ壁に突き当たります。現場改善です。

この領域が厄介なのは、課題が見えていても、それを直せる人が組織の中で最も遠いところに配置されている点にあります。業務の詳細を一番知っているのは現場です。一方で、業務を動かすシステムを変えられるのは、たいてい情報システム部門かベンダーです。両者の距離は物理的にも組織的にも遠く、「ちょっと変えたい」が数ヶ月の稟議と見積りの旅になる。直したい人と直せる人が一致していない──これが、日本企業の改善がなかなか動かない構造的な理由です。

経済産業省が「2025年の崖」で警告した背景にも、DX人材不足という言葉の裏側にも、この構造があります。人材を増やしても、距離そのものが縮まらなければ、現場の改善速度は上がりません。ならば、距離を前提にしたシステム運用をやめればいい。これがサイボウズが選んだ答えでした。

kintoneの非IT部門導入比率93%は、この選択の結果です。情報システム部門を経由せずに、現場の担当者が自分で業務アプリを組み立てる。そのために必要なのは高度なコーディングではなく、業務を知っている人間が自分の手を動かせる入口でした。東証プライム企業の導入率は46%に達し、契約社数は3.9万社を超えています。大企業の現場でも、自治体の窓口でも、同じ原理で改善の主語が変わった──「IT部門が現場に改善を提供する」から「現場が自分で改善する」へ。

PUBLIC · CASE 01
兵庫県加古川市|特別定額給付金のオンライン化で事務処理を10倍に効率化
標準パッケージで拾えない地域固有業務を、現場の職員がアプリ化した典型例。制度対応のスピードが、ベンダー発注サイクルから職員の業務知識に主導権を移した。
PUBLIC · CASE 02
山形県酒田市|定期船予約の電話を1日最大70件削減
既存の電話受付という運用そのものを現場が再設計した事例。改善対象は画面ではなく、住民と職員の時間だった。
PUBLIC · CASE 03
兵庫県庁|健康観察システムを2週間でリリース
感染症対応のような緊急局面で、調達プロセスを待たずに現場が立ち上げた事例。平時の効率化ではなく、有事の即応力が現場主導の副産物として現れた。
ENTERPRISE · CASE 04
スタッフサービス|バックヤード全社ペーパーレス化+市民開発ガバナンス確立
大企業スケールで現場主導の改善を回すと、必ずガバナンス設計が課題になる。同社は「現場が作る」と「IT部門が守る」を両立させる運用モデルを構築し、市民開発の標準形として参照されている。

自治体と民間大企業、規模も業種も異なる四つの事例が同じ一点を示しています。改善を動かすのは機能ではなく、主語の設計であるということ。kintoneが解いてきたのは、ノーコードという流行ではなく、この主語の問題でした。


SECTION 5

サイボウズが辿り着いた答え — 三つの層

ここまで四つの詰まりを見てきました。情報共有・承認・例外処理・現場改善。別々の症状に見えて、根はひとつに繋がっています。業務というものが、データだけでも、手続きだけでも、会話だけでも成り立たないという事実です。

日本企業の現場で起きていた詰まりは、この三つのどれかが欠けていたことで発生していました。データはあるのに流れない。手続きはあるのに止まる。会話はあるのに残らない。三つを一体として運用できる土台がなかったから、改善はいつも途中で止まっていたのです。

サイボウズがたどり着いた答えは、この三つを別々の製品で解くのではなく、ひとつの構造として重ね合わせることでした。kintoneの本質はノーコードでも、業務アプリビルダーでもありません。次の三つの層が、同じ基盤の上に同時に存在している点にあります。

THREE-LAYER FOUNDATION
  • データベース層|業務データを持つ土台
  • プロセス管理層|承認・例外・通知を運ぶ筋肉
  • コミュニケーション層|人と人のやり取りを残す神経

データベース層が業務の事実を持ち、プロセス管理層がその事実を動かし、コミュニケーション層が動かした人間同士のやり取りを記録として残す。これは単なる機能の寄せ集めではなく、業務が実際に回るときに必要な三つの働きをそのまま写し取った構造です。

この三層は本章で扱った四つの詰まりに過不足なく対応します。情報共有はデータベース層とコミュニケーション層にまたがる問題であり、承認フローと例外処理はプロセス管理層の設計問題、現場改善は三層すべてを現場が自分で組み替えられるかという問題でした。Garoonが情報共有の土台を、メールワイズが顧客接点のコミュニケーションを、kintoneが三層を統合して現場に渡す──製品が違って見えても、同じ世界観の展開形として並んでいるのはこのためです。

三層の中身がなぜこの形で機能するのか、なぜこの構造が日本企業に対して強く働くのかは、第4章で本論として扱います。この章ではまず、サイボウズの答えはこの三層に集約されるという事実を置いておくだけで十分です。

CHAPTER SUMMARY
この章の要点
  1. サイボウズは製品ではなく、日本企業の“詰まり”を解いてきた会社である
  2. 情報共有・承認・例外・現場改善という四つの課題が一本の糸で繋がっている
  3. kintoneの「データベース+プロセス+コミュニケーション」はその糸の答えである
FOR INVESTORS
解いている問題の普遍性が、収益の普遍性を規定する。
FOR CUSTOMERS
導入しているのは道具ではなく、詰まりをほどく運用思想である。
DEEP DIVE · CHAPTER 04
→ kintoneの正体 — なぜ「現場主導DX」が回るのか
三層の答えを、その内側から物理設計として読み解く。
HUB
← 母艦ページ(サイボウズ #01 全体目次)に戻る
EXTERNAL TOOL
サイボウズ(4776)の最新決算を見る
Garoon・kintoneそれぞれの導入数・売上推移は決算ナビで継続更新中。
決算ナビを開く ↗
関連する書架へ
HUB サイボウズ(4776)— 母艦ページに戻る TEXTBOOK 企業の教科書(シリーズ一覧)