はじめに
以前、あるロッカーサービスの運用チームで
トラブル対応マニュアルの再構築を担当しました。
- 問題解決率：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$ データモデリング $\times$ UI/UX $\times$ 技術実装 $\times$ 組織交渉力」が全て揃った、特殊な環境下で実現しました。
これは正直に言うと、
一般的な現場では成立しません。
ただし、この経験は、
マニュアルは、変更に強く、再利用性を前提とした「システム」として構築されるべきである
ということを僕に教えてくれました。
プロジェクトの圧倒的な成果（解決率70% $\to$ 100%）は、単に技術を導入しただけでなく、
業務プロセスを**「変更に強いシステム」として再定義し、現場の「協力型文化」**を醸成したことの融合によって達成されました。
改めて、現場との連携の重要性を認識するプロジェクトでした。