設計と運用のあいだ｜#02急いで作るとき、落としてはいけないもの── 「どこで止めるか」の、その後に起きたこと

急いで作った自動化が止まった。

原因は
仕様でもエラーでもなく、

止まっても気づけない設計だった。

急いで作ることは悪くない。
ただ、落としてはいけない最低ラインがある。

・触られる前提
・運用ルール
・止まったときの検知

止めた設計は、
あとから運用で答え合わせされる。　　

本文

以前、
**「どこで止めるか」**という話を書いた。

仕組みを作っていると、
作り込みはいくらでもできる。

例外処理も、通知の整備も、運用の整理も、
やろうと思えばいくらでも増える。

だから問題は、
どこで作り込みを止めるかだった。

ただ、そのときはまだ、
もう一つの問題をちゃんと考えていなかった。

急いで作るときに、
落としてはいけないものだ。

1｜自動化が止まった

以前組んだ、
データを自動で蓄積する仕組みがある。

スプレッドシートに
データを転記していく、小さな自動化だ。

ある日、
「データが取得されていない」と連絡が来た。

なぜだろう。

元データの仕様変更は聞いていない。
こちらでも触っていない。

ログを見てみる。

データは届いている。
ログも残っている。

でも、

転記だけが止まっていた。

2｜原因は想定外の操作

調べていくうちに、原因が見えてきた。

直してほしいと連絡してきた本人が、
意図せず触った箇所で
判定ができなくなっていた。

途中から、
連絡なく変更されていた箇所もあった。

最初に思ったのは、正直これだった。

「なんでそこ触る？」

でも、すぐに思い直した。

設計が甘かったのだと思う。

3｜気づけたはずの抜け

今回の問題は、
仕様が難しかったわけではない。

よく考えれば、
気づけたはずの抜けだった。

触られる前提。

運用ルール。

急いで作ったとはいえ、
ここは落としてはいけなかった。

4｜本来なくてよかった仕事

原因を探して、
修正して、
運用ルールも整えた。

復旧まで、
結局5時間かかった。

大きな事故ではない。

でも、ずっと引っかかっていた。

これは、
本来なくてよかった仕事だった。

急いだ設計の甘さは、
あとからこういう形で戻ってくる。

5｜一番怖かったこと

ただ、今回いちばん怖かったのは、
別のところだった。

ツールは止まっていた。

でも、

誰もそれに気づいていなかった。

自動化の仕組みは、
壊れるときに派手なエラーが出るとは限らない。

むしろ多くの場合、

静かに止まる。

そして、気がつかれない。

6｜急いで作るときの最低ライン

急いで作ること自体は、悪くない。

現場では、
とりあえず動くものが必要なことも多い。

ただ、急いだ設計には
最低ラインがあるのだと思う。

今回抜けていたのは、たぶんこの三つ。

• 触られる前提

• 運用ルール

• 止まったときの検知

ここを落とすと、
あとから運用が教えてくれる。

しかも、
本来なくてよかった仕事という形で。

7｜止めた設計の答え合わせ

以前、
どこで作り込みを止めるか、という話を書いた。

今回の出来事は、
その答え合わせだったのかもしれない。

止めた設計は、
実際の運用で、

どこから壊れるかを教えてくれる。

急いで作った設計は、
あとから運用の中で少しずつ歪みが出てくる。

どこで止めるか、どこまで直すか。
結局は同じ判断の話に戻ってくる。

▼このnoteについて
仕事や卓球、日常の違和感の中にある
「判断の瞬間」を分けて考えています。

▼ はじめての方へ