発注の前に、道具の名前を仕事の話へ戻す

ページを開いたあとで動く係です。HTML が貼り紙、JavaScript が「この欄、空のまま送らないでください」と止める人です。

よくある場面は、予約フォームです。日付が過去、人数が0、電話番号が桁不足。送信前にその場で知らせる。サーバに届いてからエラーを返すだけでも正しいのですが、入力した人は「押したのに何も起きない」と感じます。

もう一つは、画面を切り替えずに一覧を絞り込むことです。スタッフ名で予約表を探す、在庫の色だけ残す。ページ全体を読み直すと、入力途中のメモが消えます。

JavaScript は便利なぶん、止めすぎると困ります。確認のポップアップを三重に出すと、現場は「はい」を押すだけになります。止めるのは、戻すのが面倒な操作に限った方がいいです。

在庫の引き当てや複雑な権限が本体の仕事なら、WordPress は表紙にして、計算は別の仕組みに置いた方が長持ちします。全部をプラグインで足すと、三年後に誰も中身を説明できなくなります。

実装の前に、画面を紙の代わりに並べる場所です。ボタンの位置、項目の抜け、スマホで親指が届くかを、コードを書く前に見ます。

コメントがチャットに散らばると、「どの案が最新か」で一日使います。画面の横に「このボタンは店長だけ」と書いておくと、実装の質問が減ります。

予約、顧客、勤怠、管理画面。名前は違っても、やっていることは「紙や表計算で二人が同じマスを触っている」のをやめることです。

CRM は顧客台帳の少し欲張った呼び方です。検索、メモ、前回何を買ったか。そこまでで足りる会社は多いです。営業の点数管理まで最初から入れると、入力されずに終わります。

厨房とホールが、伝票で注文を渡すやり方です。画面と画面が、決まった用紙（住所と項目）でデータを渡します。人がコピペする隙間を減らすためのものです。

API は魔法の連携ではありません。相手のサービスが止まった夜に、予約を紙で受けるかどうか。そこを決めてない連携は、本番の初日に止まります。

台帳の本体です。表計算との違いは、同じ顧客を二箇所に書かないことです。予約の行には顧客番号だけ置き、名前や電話は顧客の側に一回だけ書きます。電話番号が変わったとき、予約を全部開かずに済みます。

バックアップは「昨夜の台帳が引き出しにある」状態です。更新の直前に無いと、誤って消した日の復旧ができません。検証環境は、本番の台帳を触らずに試す別冊です。この二つが無いシステムは、修正のたびに本番で賭けをします。

文章を読んで、抜き出す、短くする、仕分ける、下書きする。これが今の使い方の中心です。社内の規程や過去の見積を渡して、その範囲で答えさせるやり方を RAG と呼びます。インターネット全体の記憶で答えさせるのとは違います。

IPA「DX動向2026」（2025年度の調査）では、AI を導入した企業の効果として「業務が効率化したり迅速化した」が91.6%です。一方で「売上や利益が向上した」は3.9%です。社内の手間は減りやすく、売上の話はまだ別、という調査結果です。導入の説明を売上の約束から始めると、三か月後に話が合わなくなります。

参照してよい資料と、入れてはいけない資料（顧客の個人情報、未公開の価格）を分けるのが、モデルを選ぶより先です。

サイボウズの、業務アプリを自分たちで組めるサービスです。項目（フィールド）、1件の記録（レコード）、誰が見て誰が直せるか（権限）を、アプリごとに持ちます。日本の会社で、表計算の隣に置かれていることが多い棚です。

標準の入力フォームで足りるなら、そこで止めます。足りないときだけ JavaScript で画面を足し、他システムとは REST API でつなぎます。最初から全部をカスタマイズすると、担当が辞めたあとに直せなくなります。

プログラムの変更履歴です。「火曜の夕方、料金の計算を誰が変えたか」を残せます。GitHub は、その履歴を複数人で置く場所です。コメント付きで直して、問題なければ本番側へ合流させます。

発注側が見るべきなのは、画面の差分だけではありません。検証環境で一度見てから本番へ出しているか。バックアップはあるか。引継ぎのとき、履歴が個人のパソコンにしか無いと、そこで切れます。