止まらないより、止まっても起き上がれるように

その自動化、止まったとき気づけますか

自動で動くようにしておいたはずの仕組みが、ある日、いつのまにか止まっていた。しかも、しばらく気づかなかった。そんな経験は、ありませんか。

このシリーズでも、前に1度、似た話をしました。動いているつもりが止まっていて、数字を見るまで気づけなかった、という話です。自動化のいちばんやっかいなところは、止まったことが、静かなまま伝わってこないことにあります。今日は、その「いつか止まる」を前提にして、仕組みのつくり方をどう変えたか、という話をします。

大きな流れに、相乗りさせていた

私たちの発信づくりは、ひとつの大きな流れの中で動いていました。記事を取り込み、翻訳し、下書きを作り、確かめ、投稿し、数字を測る。その長い一本道を、ぐるぐると回し続けるしくみです。

前の編まで話してきた、返信の下準備、つまり絡む相手の投稿を拾って、返信案を作る仕事も、最初はこの一本道の途中に組み込んでいました。一見、自然なつくりです。ぜんぶがひとつの流れに乗っていれば、管理する場所もひとつで済みます。

けれど、これには弱点がありました。一本道のどこか手前で時間がかかったり、つまずいたりすると、その先にある返信の下準備まで、順番が回ってこないのです。本体が重たいと、相乗りしている仕事は、いつまでも自分の番が来ない。実際、動かしてみると、返信の下準備は、なかなか始まりませんでした。

ひどいときには、半日たっても、その番が回ってこない。本体が外の取り込みで手間取っているあいだ、後ろに並んだ仕事は、ただ待たされ続けます。順番待ちの列のいちばん後ろにいると、前がつかえるたびに、自分の番が遠のいていく。返信の下準備は、まさにその、列の後ろにいたのです。

「止めない」は、たぶん難しい

最初に考えたのは、「では、本体を止まらないようにすればいい」でした。けれど、これはたぶん、勝ち目のうすい戦いです。

外とつながる仕組みは、いつかどこかでつまずきます。通信が一瞬切れる。相手のサービスが遅れる。1つの処理が、思いがけず長くかかる。原因をひとつ潰しても、また別のところがこけます。「けっして止まらないもの」を目指すと、こけるたびに、もぐら叩きのように追いかけることになります。

そこで、目標を立て直しました。止まらないことを目指すのをやめて、止まっても自分で起き上がれるように作る。守りの向きを、変えたのです。

だから、切り離した

まず、返信の下準備を、大きな一本道から切り離しました。

本体の流れに相乗りさせるのをやめて、決まった時刻に1度だけ動く、小さな独立した仕事にしたのです。目覚まし時計をセットしておくのに似ています。時間になったら起きて、ひとつの用事だけを済ませて、また眠る。ずっと起きている必要はありません。

この「走って、終わる」というかたちには、思わぬ良さがありました。ずっと動き続けるものは、どこかで固まったまま止まる、ということが起こります。けれど、1度動いて終わるだけのものは、固まりようがありません。仕事が終われば、いったん消える。次の時刻に、また新しく起き上がる。止まったまま居座る、という状態そのものが、起きにくくなりました。

ずっと起きている仕組みは、どこかの処理の途中で、外からの返事を待ったまま固まってしまうことがあります。つないだ相手がいつまでも応えてくれないと、こちらはただ待ち続ける。待っているだけなので、エラーも出ません。外からは動いて見えるのに、中では止まっている。これが、いちばん気づきにくい止まり方です。前に「止まったことに気づけなかった」と書いたのも、これでした。けれど、1つの用事だけ済ませて終わる仕事なら、たとえその1回が固まっても、次の時刻には、新しく立ち上がり直します。固まった回は、そのまま捨ててしまえばいい。1回ごとに区切れているので、全体が止まったままにはなりにくいのです。

1度きりにせず、何度も起こす

次に、その小さな仕事を、一日に1度ではなく、何度か起こすようにしました。朝・昼・夕の、決まった時刻に。

ここで効いてくるのが、別に設けた歯止めです。一日に出していい数の上限を、仕組みの側で決めておく。すると、朝の回でその日のぶんが足りていれば、昼と夕の回は、起きても「もう今日はやることがない」と、何もせず眠ります。逆に、朝の回が何かの拍子に失敗していれば、昼の回が、残りを拾ってくれる。

つまり、わざわざ「失敗したら、もう1度やり直す」というしくみを作らなくても、何度か起こすことと、上限の歯止め、その2つを組み合わせるだけで、自然とやり直しになるのです。失敗した回は、次の回が埋める。同じ仕事が二重に出ないよう、すでに出したものは記録しておく。これで、取りこぼしはかなり減りました。

この「何度も起こす」やり方には、もう1つ良さがあります。どれか1回がうまくいけば、それでいい、ということです。すべての回が完璧に動く必要はありません。1回ごとの成功率が多少ふらついても、回数でならせば、その日のぶんはたいてい片づきます。一発勝負にしないというだけで、途中の失敗に強くなります。

止まっても、拾い直せるように

もうひとつ、小さな備えを足しました。もし、その時刻にパソコンが動いていなかったら——つまり、起こすはずの瞬間に、そもそも誰も起きられなかったら。そういうときは、次に動き出したときに、抜けたぶんを埋めにいくようにしました。

完璧な見張りを置くのではなく、こけることを最初から見こんでおく。そして、こけたあとに、どう起き上がるかを、先に決めておく。設計の重心が、「止めない」から「立て直せる」へ移ったのです。

完璧より、立て直せること

ここには、自動化とのつき合い方そのものが、少し表れている気がします。

機械にまかせると、つい「完璧に動き続けてくれる」ことを期待してしまいます。けれど、外の世界とつながるかぎり、完璧はありません。だとすれば、目指すべきは、けっして転ばないことではなく、転んでも自分で起き上がれることのほうです。

これは、人の手間の面でも効きます。仕組みが自分で立ち直るぶん、人がそのつど手で立て直す回数が減る。その時間を、見張りではなく、中身を良くする方に回せます。

このシリーズで考えてきた「AIに任せきりにしない」は、ぜんぶ人が張りついて見張る、という意味ではありませんでした。むしろ逆で、人が安心して任せられるように、こけても自分で戻る土台を、人が先に整えておく。任せるために、整える。その順番なのだと思います。

もし、あなたの自動化が、ときどきこけるなら

最後に、持ち帰れることを1つだけ。

もしあなたが、何かを自動で動かしていて、それがときどき止まって困っているなら、「止まらないようにする」のを、いったんあきらめてみてください。代わりに、「止まっても、次にどう拾い直すか」を考える。1度きりにせず、何度かに分けて動かす。やり過ぎないよう、上限で歯止めをかける。止まった回は、次の回が埋める。

転ばない仕組みを追いかけるより、転んでも起き上がる仕組みを作るほうが、たいていは長く続きます。止まらないことを目指すのはやめて、止まっても、また動かせばいい。そう割り切ってからのほうが、結果として安定して回っています。