なぜ、私たちの改善は「点」で終わるのか ── ハブとスポークで編み直す、しくみの骨格

現場を歩いていると、こんな静かなため息に出会うことがあります。

営業部門が新しい顧客管理ツールを導入し、商談の可視化に成功した。 一方で、経理部門は独自のシステムで請求書を発行し、効率化を進めている。 どちらも、それぞれの持ち場で懸命に「正しい改善」を積み重ねています。

しかし月末になるとどうでしょうか。 営業のツールからデータを一度CSVで書き出し、目視で確認しながら、経理のシステムへ手作業で転記する担当者がいます。 現場も、管理部門も、システム担当者も、誰もサボってはいません。 それなのに、それぞれの改善が波及せず、その場限りの「点」として孤立し、そのスキマにまた新たな手作業が生まれてしまう。

この構造的なもどかしさは、皆さんの能力不足や努力不足によるものではありません。 原因はもっと深く、静かなところにあります。 それは、しくみの「中心（ハブ）」が決まっていないまま、末端の最適化が進んでしまったという事実です。

中心なき最適化がもたらす「分断」

私たちは問題が起きると、つい「目の前の業務」や「個別のシステム」という末端から手をつけてしまいます。 しかし、中心となる「軸」を持たないまま末端の改善だけを進めると、やがてそれらは独立国家のように振る舞い始めます。 隣の部署からは中身が見えず、システムは乱立し、データは分断される。 良かれと思った局所的な最適化が、結果として組織全体の「つながらなさ」を加速させてしまうのです。

ハブとスポークで、しくみを編み直す

この分断を繋ぎ合わせるための構造的な視座が「ハブとスポーク」です。 自転車の車輪を思い浮かべてみてください。中心にある車軸（ハブ）から、放射状に複数の線（スポーク）が伸びています。

これを実際の業務やシステムに当てはめると、どうなるでしょうか。

・データにおけるハブとスポーク 例えば、営業は「株式会社A」と登録し、経理は「A（株）」と登録している状態。これはハブがない状態です。 ここで「全社でただ一つの顧客マスター」をハブとして中央に置きます。営業のツールも経理のシステムも、すべてそのハブから「顧客ID」という線を引いて（スポークとして）データを参照する構造にします。これで初めて、データが組織を貫いて繋がります。

・業務におけるハブとスポーク 各部署がバラバラに独自のルールを作るのではなく、「受注から入金までの一連のプロセス」をハブとして定義します。 「見積もり」「納品」「請求」といった各部署の個別業務は、あくまでその大きなハブから伸びたスポークに過ぎません。全体の流れ（ハブ）を整えてから、個別の作業（スポーク）をどう楽にするかを設計する。順番が逆になると、改善は必ず詰まります。

・システムにおけるハブとスポーク 現場の要望に応じて便利なSaaSを次々と導入する（スポークを増やす）前に、まずは「それらのデータが最終的に集まり、連携する基盤」をハブとして据えます。 中央に強固なデータ基盤があり、そこへ繋がることを前提として、現場が使いやすい個別アプリを選択していくのです。

「どこに繋がっているのか」を問う

業務のスキマに立つ私たちが最初に行うべきは、新しいツールを導入することでも、マニュアルを書き直すことでもありません。

「この仕事は、このデータは、全体のどこ（ハブ）に繋がっているのか？」

この問いを立てることです。 自分の足元にある改善が、組織という大きな車輪のどの部分を担っているのか。その繋がりを意識できたとき、業務はただの「作業」から、生きた「しくみの一部」へと変わります。

改善が広がらないとき、自分を責める必要はありません。 ただ静かに視線を上げ、しくみの中心に何があるのかを確かめてみてください。 ハブを定め、そこから線を引く。その構造への理解こそが、バラバラの点群を線に変え、組織を前へ進める力になるのです。

さらに深く「スキマ」を覗き込みたい方へ

ハブとスポークの概念をベースに、業務設計者の視座や、組織の構造をどう捉えるかについて、以下の回廊をご用意しています。私たちが直面する現象の裏側にある「思想」に触れてみてください。

▶ しくみの思想・構造に触れる #業務設計者論｜業務でもITでもない、しくみの“スキマ”に立つ

ITと現場の間に落ちる「誰の仕事でもない領域」に光を当て、業務設計者という存在論について語っています。

▶ 改善を構造からデザインする #業務設計者論｜改善の裏にしくみを描く力

点としての改善を、どのように面としての「しくみ」に昇華させるか。ハブとスポークにも通じる構造設計の視点をお伝えしています。