2026-09-20週の動き

壊れ方を先に決める — Lab Weekly 2026-W38（9/14〜9/20）

週報

卸売業の価格改定を計算する案件で、全商品の再計算に37秒かかっていた。担当者は画面を見つめて待つしかない。今週それを0.2秒にした。ただ、この案件で本当に時間を使ったのは速さではない。「途中で止まったらどうなるか」を決め直すことだった。今週はいくつかの案件で、同じことを考えていた。

消してから書くか、書いてから消すか

再計算は、古いデータを消してから新しいデータを書く作りだった。途中で失敗すると、消えただけで書かれていない状態が残る。現場から見れば、昨日まで見えていた価格が消えている。

順番を逆にした。新しいデータを全部書き終えてから、古いものを消す。途中で止まっても、前のデータがそのまま残る。

速くする工夫も同じ週に入れた。同じデータを何度も読み直している箇所を整理し、対象にならない行は保存しないようにした。全商品の再計算は37秒から0.2秒、書き込みは11.7秒から0.05秒になった。

ただ現場が安心したのは、速くなったことより、失敗しても前の状態が残ると分かったときだった。速いシステムは便利だが、壊れないシステムでないと任せてもらえない。

自社で作っている経営シミュレーションでは、もっと厄介な壊れ方をした。経営者役でどの戦略を選んでも、利益が0、破産する確率が100%と出る。エラーは出ない。画面は堂々と数字を返してくる。

原因は単純だった。費用は実際の数字を使い、売上だけが初期設定の値のままだった。片方だけが現実で、片方が仮の値。噛み合わないまま計算が通っていた。

直し方は二つあった。その設定値を実際の数字に入れ替える。これなら数分で終わる。もう一つは、片方だけが仮の値になっている状態そのものを見つける仕組みを、計算の中に置く。

後者を選んだ。値を直すだけだと、別の項目で同じことが起きたときにまた気づけない。エラーを出して止まる間違いより、黙って答えを返す間違いのほうが怖い。

製造業の帳票を読み取る案件でも、似たことをしていた。複数の帳票をまとめて取り込むとき、1件が失敗すると全部が止まる作りだった。1件の失敗は1件でとどめ、残りは進む形に変えた。

棚卸しの確認作業も、途中で通信が切れたり、同じ記録を二人が同時に触ったりしても、元に戻せる経路を用意した。

このサイト自身にも同じ考えを入れた。週報の下書きを自動で作る仕組みを今週作ったが、下書きを受け取る窓口は「公開する」という指示を受け付けない作りにしてある。権限で守るのではなく、間違えられる経路を最初から作らない。

システムを入れるか考えるとき、うまくいったら何ができるかは、たいてい提案書に書いてある。聞いておいたほうがいいのは、うまくいかなかったときに何が残るかだ。途中で止まったら、前のデータは無事か。間違った答えを返したとき、誰かが気づけるのか。その答えが曖昧なまま任せると、止まった日に困る。

卸売業の価格改定を計算する案件: 再計算を「新しく書いてから古いものを消す」順に変更。索引の整理と保存対象の絞り込みで、全商品の再計算を37秒から0.2秒に。操作マニュアル（A4・5ページ）を納品
製造業の帳票を読み取る案件: 一括取り込みで1件の失敗が全体を止めないように変更。棚卸し確認に、中断や競合からの復旧経路を追加
会員制サービスの入会・退会を自動化する案件: 予定した回数だけ処理が動いたかを数える仕組みを本番へ。記録が残らなかった回を見つけられるようにした
自社の経営シミュレーション: 片方だけ仮の値という噛み合わせの崩れを検知する仕組みを実装
この実験ログのサイト: 週報と深掘り記事の2本立てに刷新。公開してよい範囲を先に決め、下書きの自動生成に組み込んだ
自社の学習プラットフォーム: 3コース（全15章）を公開
自社の話し方トレースの試作: メニューを4つに整理し、練習の初期表示を選びやすいものに変更

経営シミュレーションの検知の仕組みを本体に入れる。自社の感情記録アプリでは、使い始めて1日で止まった4人に直接話を聞きに行く。画面の改善より先に、理由を聞く。