前回の記事、第3回では、
「完全自動化」を捨て、人の手を残した仕組みを作りました。
iPhoneから指示を出し、
iCloud上の設定ファイルを通して、
遠くにあるPCを動かす。
完璧ではないけれど、
今の状況では、これが一番現実的な答えだと思っていました。
実際、この日の配信のほとんどは、
意図した通りに動き、録画することができていました。
「これで、配信最終日まで乗り切れる！」
正直、その時点では、そう感じていました。
ですが、
その安心感は、長くは続きませんでした。
この仕組みが抱えていた問題に、私は気づいていませんでした。
2日目の夜。
帰宅して、まだ録画中だったPCの画面を見た時、
違和感を感じました。
指定した配信とは別の配信を録画していたのです。
発生頻度は少なく、必ずではないけれど、
・思った通りに切り替わっていない。
・操作したはずの指示が、反映されていないかもしれない。
・原因がすぐには分からない。
翌日は最終日。
私は現地参戦の予定です。
この夜は、トラブル解決のために、
「仕組みを進化させるか」
それとも、
「一度引き返すか」
その判断を迫られる、重要な時間になりました。
第4回では、トラブルの中で、
あえて“進化を止める”という選択をした理由と、
安定を最優先にした判断についてお話ししていきます。
※この記事は連載4回目です。
連載の背景については、こちら。
第0回：趣味から始まる学び | 推し活をきっかけに、自動収録の仕組みを作ることにした話
過去の連載記事はこちら。
第1回：限られた時間でカタチにする。前日の夜、初級者なりに仕組みを作った一日
第2回：想定外の出来事。ルームが増え、今できることを考えた夜の話
第3回：完璧を目指さない｜人の手を残した仕組みと、想定外を乗り越えた話
トラブルの恐怖。実際に動かしてみて起きたこと
前日の夜作った仕組み自体は、動いていました。
少なくとも、「まったく録画されていない」という状態ではありません。
実際、この日の配信の多くは、
意図した通りに録画されていました。
ですが、
帰宅してPCの画面を確認したとき、
一つだけ、見過ごせない違和感がありました。
指定していた配信とは、
別の配信が録画されていたのです。
常に起きるわけではありません。
毎回再現するわけでもない。
ただ、ごく一部のタイミングで、
思った通りに切り替わっていないように見えました。
・切り替え指示が、反映されていないかもしれない
・設定ファイルは更新されたが、読み取りが追いついていないかもしれない
・原因の検証も、判断もすぐにはできない
この時点では、
「たまたまかもしれない」
そう自分に言い聞かせることもできました。
ですが、
翌日の条件を考えると、
そのまま見過ごすことはできませんでした。
重なるトラブル。iCloudが止まったとき、背筋が冷えた
追い打ちをかけるように、
もう一つ、嫌な出来事が起きます。
設定ファイルの更新日時が、
最後に送ったはずの時間よりも前から更新されていませんでした。
iPhoneから送ったはずの指示が、
PC側に反映されていない。
設定ファイルを確認しても、
内容が更新されていないように見える。
何度か試して、
ようやく気づきました。
iCloudの同期が、止まっていたのです。
原因は、
PC側のiCloudアプリがフリーズしていたことでした。
もし、これが自宅での作業中なら、
再起動して終わりです。
ですが、このとき想像したのは、
翌日の自分の状況でした。
・自分は現地にいる
・PCには触れない
・何か起きても、すぐに確認できない
もし同じことが起きたら？
その時、私は対応できない。
そもそも気づくことさえできない。
そう考えた瞬間、
背筋が冷たくなりました。
最終日を前に、考え直したこと
この夜私の中で、
トラブルに対応するための、一つの問いが生まれます。
このまま、
機能を足して仕組みを進化させるべきか。
それとも、
一度立ち止まり、安全な形に戻すべきか。
技術的には、
原因を切り分けて、
対策を追加することもできたでしょう。
ですが、
それには時間が必要です。
検証も必要です。
何より、確実性がありません。
翌日は最終日。
失敗したら、取り返しがつきません。
ここで守るべきものは何か？
「できること」を増やすことか。
それとも、
「失敗しないこと」か。
答えは、
すでに自分の中で決まっていました。
進化より撤退。機能を削るという選択
この夜、私は決めました。
一度、引き返そう。
幸いにも、
最終日の配信は一つの配信ルームのみで行われることが分かっていました。
配信切り替え機能は、
このタイミングでは捨てる。
第1回で作った、
配信切り替えなしの、
一番シンプルで、安定して動いていた構成に戻す。
できることは減ります。
便利さも下がります。
ですが、
「録画が止まる」
「想定外の動きをする」
そのリスクを、
最小限に抑えることができる。
進化を止めることは、
後退ではありませんでした。
安定を最優先にするための、
この時点ではベストな判断だったと思っています。
この判断が、次につながった
ただし、
元に戻せば、それですべて解決、
というわけではありません。
翌日は、
私は現地に行く予定です。
一日目に安定して動いたからと言って、
絶対に不具合が起きないといえるほどの検証はできていません。
録画が止まっていないか。
PCが落ちていないか。
想定外が起きていないか。
直接操作はできないけれど、
「気づいて、最低限出来る限りの対応ができるだけの手段」は必要でした。
ここで私は、
別の方向から、安全を確保する方法を考え始めます。
「失敗しない仕組み」ではなく、
「失敗に気づける仕組み」を用意する。
この方向転換が、今後の仕組みの進化を支える後ろ盾にもなってきます。
まとめ
この日は、仕組みの進化ではなく、一度撤退することを選択した日です。
新しい技術、仕組みは一切織り込んでいません。
起きていたトラブルの原因も分かっていないままです。
それでも、この時の判断は、
実践の中で仕組みを作り上げていくために、
この時できた最大限ベストな判断だったと思っています。
そして、この時考えた、
「失敗に気づける仕組み」
これらは、実践の中で進化させていく私の仕組みを支える、核となっています。
次回、第5回では、
現地参戦という条件の中で、
仕組みを“見守る”ために考えた方法と、
Chromeリモートを選んだ理由についてお話しします。
コメント