「この車種、どこからフィルター取り出すんでしたっけ」
加盟店から本部への電話が来る。施工現場で、手が止まった状態で。本部の担当者がマニュアルをめくって探して、答える。この繰り返しは双方にとってロスだ。
スマートフォンで車種を検索して、3秒で施工手順が見れればいい。
何を作るか
施工マニュアルシステムに必要な機能は3つと決めた。
1つ目は車種検索と施工マニュアル閲覧。加盟店がスマートフォンで車種名を入力して、施工手順・注意事項・写真を確認する。現場で立ったまま使うため、モバイル最適化が前提だ。
2つ目は施工記録の登録。施工するたびに廃液量・廃液色・風量・温度差・作業時間を記録する。記録が積み重なることでデータになる。
3つ目は是正提案機能。現場でマニュアルと実際の手順が違うことに気づいた加盟店が、「この手順はこう変えた方がいい」という提案を本部に送る。本部が確認・承認するとマニュアルに反映される。現場の経験が本部のナレッジに還流する仕組みだ。
データモデル
CREATE TABLE vehicles (
id SERIAL PRIMARY KEY,
name VARCHAR(128) NOT NULL,
maker VARCHAR(64),
model_year_from INTEGER,
model_year_to INTEGER,
notes TEXT
);
CREATE TABLE manuals (
id SERIAL PRIMARY KEY,
vehicle_id INTEGER REFERENCES vehicles(id),
section VARCHAR(64),
content TEXT,
updated_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE manual_images (
id SERIAL PRIMARY KEY,
vehicle_id INTEGER REFERENCES vehicles(id),
section VARCHAR(64),
image_path VARCHAR(512),
caption TEXT,
sort_order INTEGER DEFAULT 0
);
CREATE TABLE correction_proposals (
id SERIAL PRIMARY KEY,
vehicle_id INTEGER REFERENCES vehicles(id),
section VARCHAR(64),
current_manual TEXT,
proposed_change TEXT,
reason TEXT,
status VARCHAR(32) DEFAULT 'pending',
created_at TIMESTAMPTZ DEFAULT NOW()
);
各車種のマニュアルは4つのセクションで構成した。フィルター(取り外し方・位置)、ノズル挿入(位置・深さ・角度)、廃液排出(排出経路・時間の目安)、施工設定(A/C・風量・内気/外気・温度)。
セレナC27はフィルターが助手席足元右側パネル内という特殊な位置にある。プリウス50系はドレン経路が長く廃液排出に時間がかかる。これらの車種固有の注意事項がsettingsやdrainのセクションに入る。
技術スタック
バックエンドはFastAPI(Python)、データベースはPostgreSQL、フロントエンドは静的HTML(vanilla JS)。既存のEC2インスタンスに相乗りさせた。ポートは9300番。orderocrが9200番を使っているため1つずらした。
URLはhttps://manual.example.jpで公開している。
是正提案ワークフロー
加盟店が「この手順、実際と違う」と気づいたとき、提案フォームから送る。
本部の管理画面に「未確認の是正提案」が一覧で出る。本部が確認して承認すると、提案内容がそのままマニュアルのcontentカラムに反映される。手動でマニュアルを編集する手間を省きながら、「誰の提案が承認されたか」の履歴も残る。
現場の経験でマニュアルが育つ。これがこのシステムの一番大事なところだ。
初期データの投入
リリース時に6車種のマニュアルを投入した。アルファード30系・プリウス50系・ヴォクシー80系・C-HR・フィットGK・セレナC27。
内容はみんカラ・トヨタ公式マニュアル・整備ブログなど複数のソースから集めてまとめた。公式整備情報サービス(FAINES)は加盟要件があり一般には使えない。そのため初期データは「出発点」であり、現場施工記録と是正提案を積み重ねることで信頼性を高めていく設計だ。
データは使われながら育てる。最初から完璧にする必要はない。
*シンプルシステム株式会社 代表 伊藤勝彦*