はじめに

以前、あるロッカーサービスの運用チームで
トラブル対応マニュアルの再構築を担当しました。

問題解決率：70% → 100%
平均対応時間：1〜2時間 → 30分
React 未経験から 2ヶ月で開発
チームは 1名（僕）だけ

という、なかなか特殊な改善プロジェクトでした。

本記事では、

なぜ React & Airtable の組み合わせで成功できたのか？
なぜドキュメントマニュアルでは限界だったのか？
を技術視点で解説します。

1. 旧マニュアルが抱えていた構造的な課題

❌ 曖昧な指示

「適宜確認」
「状況に応じて連絡」
→読んだ人ごとに動作が変わる。

❌ 現場ベンダーの知見が反映されていない

実際の対応者のほうが詳しいのに更新されない
間違った手順が延命される

❌ 多対多構造をExcelで無理やり管理して破綻

業務一覧
手順一覧
例外パターン
がバラバラのシート…

❌ フィードバックが吸い上げられない

「指示型」の文化
現場の声が反映されない
文化と構造、両方が詰んでいました。

2. 解決策：業務プロセスを「データモデル」として再構築

僕はまず、業務プロセスをすべて洗い出し、
1つ1つをエンティティ化しました。

🧩 分解の方針

業務：ケースの種類
手順：最小動作単位
多対多：複数の業務が同じ手順を共有する
メタデータ：難易度 / 注意点 / 参照リンクなど

これは普通のマニュアルではできない構造です。

3. Airtableがもたらした「データモデリングの民主化」

Airtable が優れているのは、“リレーションをUIで扱える” 点です。

例えば下のような画面：

Table1 の 1レコードが
Table2 の複数レコードと
1フィールド内で自然に紐づく

さらに多対多に向いている理由として：

リレーションレコードの順番をドラッグ＆ドロップで入れ替えられる

これは業務×手順のような
「多対多 + 並び順管理」が必要な場面で圧倒的に強いです。

✔ Airtable のリレーションUIが“業務改善に向いている”理由

① リレーション作成が選択式で直感的

外部キーを意識しない。
クリックでレコードを紐づけるだけ。

② 1フィールドに複数レコードを紐づけられる

業務 → 手順（複数）
手順 → 業務（複数）
＝多対多が自然に組める

③ D&Dで順番入れ替えができる

中間テーブル＋order_index管理が不要。
並べ替え＝業務フローの更新。

④ APIでReactフロントに直結できる

並び順・関連レコード・手順情報がそのまま取得可能。
「見たままの構造」＝「データの構造」になる。

構造図：業務と共通手順の多対多リレーション

以下の図は、Airtable で構築した
「業務 × 共通手順（多対多）」のマニュアル構造を分かりやすく示したものです。

上段：業務（Tasks）
実際の現場で起きる「ロッカーが開かない」等の業務単位
　
中段：業務ごとの手順インスタンス
各業務に固有の「並び順付きの手順リスト」
→ Airtable ではリンクされたレコードとして表現され、D&Dで並び替え可能
　
下段：共通手順（Reusable Steps）
実体として1つだけ存在する“手順マスタ”
すべての業務がここを参照する

※図では線が多く視認性を損なうため、
T1 のみ共通手順へリンクを代表表示しています。
T2/T3 も同じ構造です。

4. Reactで「Webアプリとしてのマニュアル」を構築

Airtable 側で整備した

業務
手順
並び順（order）
注意点
フィルタ条件
タグ

などを React から取得し、フレームワークでUI化。

📌 UIの特徴

検索が一瞬
業務一覧から関連手順が一目で分かる
手順詳細はアコーディオン式
例外パターンも自動で紐づく
モバイルでも見やすい

ドキュメントではなく、Webアプリとしてのマニュアルになりました。

5. 文化面の改善：最も重要なアプローチ

単に技術を入れ替えるだけでは意味がありません。

僕は以下のアプローチを取りました。

✔ 現場ベンダーと直接話す

ベンダーさんへの挨拶や気遣いを欠かさない。
手順の正しさを“現場から”検証
フィードバック文化をつくる

✔ 「指示型」から「協力型」へ

作業する側の声を必ず反映
お互いが正しい情報を共有できる関係へ

✔ 手順の変更を1箇所に集約して汎用化

手順が1つ変わるだけで全業務に反映
更新コストが激減

6. まとめ：「マニュアルは文章ではなく、『システム × 文化』である」

この成功は、「業務知識 $\times$ データモデリング $\times$ UI/UX $\times$ 技術実装 $\times$ 組織交渉力」が全て揃った、特殊な環境下で実現しました。

これは正直に言うと、
一般的な現場では成立しません。

ただし、この経験は、

マニュアルは、変更に強く、再利用性を前提とした「システム」として構築されるべきである

ということを僕に教えてくれました。

プロジェクトの圧倒的な成果（解決率70% $\to$ 100%）は、単に技術を導入しただけでなく、
業務プロセスを 「変更に強いシステム」として再定義し、現場の「協力型文化」 を醸成したことの融合によって達成されました。

改めて、現場との連携の重要性を認識するプロジェクトでした。