「先週の変更で、数字が急に変わりました。何を変えたのか、誰も覚えていません」

料理を出す前には、厨房で味見をします。お客さんの前で初めて作ると、失敗が見られてしまいます。ツールも、本番を直接触らず、試す場所で確かめてから反映します。

テスト環境（Sandbox）

試す場所。壊れても影響がない

検証

現場の代表が、実際の使い方で確かめる

本番反映

時間と手順を決めて反映する

戻す手順

うまくいかないときに、前の状態へ戻す

変更履歴（いつ、誰が、何を、なぜ変えたか）を残します。数字が急に変わったとき、原因を追えるようにするためです。削除や型の変更のように戻せない変更は、バックアップを取り、承認をつけます。現場への事前の連絡と、反映後の確認をセットにします。

押し入れは、片づけずに物を足し続けると、何がどこにあるかわからなくなります。項目・自動化・レポートも、使われなくなったものが残り続け、動きを重くし、理解を難しくします。これを技術的負債と呼びます。

項目

直近半年で、入力・参照されているか

自動化・フロー

実行されているか。まだ必要か

レポート・ダッシュボード

誰が、いつ見ているか

ユーザー・権限・連携

使われているか。持ち主はいるか

壊れ方は、消す基準がない、消すのが怖い（何に使われているか不明）、棚卸しが担当者の善意頼みで後回しにされる、です。四半期に一度の棚卸しの日を決め、消す手順（非表示→一定期間待つ→削除）を決めます。作るときに持ち主と使い道を残せば、棚卸しのときに判断できます。

スマホの契約は、使っていないオプションを払い続けると、毎月静かにお金が出ていきます。ツールも、席数・アドオン・重複した機能に、気づかないうちに払い続けます。

契約の一覧

ツール、費用、更新日、席数、持ち主

更新の3か月前に見直す

未使用の席、重なる機能を洗い出す

導入前にデータの出口を確かめる

エクスポートの形式、項目の対応、移行の手順

ここで先に反論しておきます。「費用は削れるだけ削ればよい」わけではありません。効果が測れるものは効果と比べ、測れないものは使われ方で見ます。安いツールが保守の手間で結局高くつくこともあります。乗り換えの出口を考えずに入れると、移行に何か月もかかります。

本番を直接変更することはありますか？ 変更の記録は残っていますか？

あれば、変更ミスが現場に出て、原因も追えない

半年間使われていない項目・レポートは、いくつありますか？

数えられなければ、棚卸しができていない

使われていない席とアドオンは、いくつありますか？

把握していなければ、払い続けている

今のツールをやめるとき、データは取り出せますか？

確かめていなければ、乗り換えの道がない

先週、仕組みに加えられた変更を、いくつ言えるでしょうか。言えないなら、数字が急に変わったとき、原因を探す手がかりがありません。まず、変更を記録する1枚のシートから始められます。ツールと構成の基本編に戻って、役割の分担から見直すのもよい進め方です。