「完全自動化は無理だ」と判断しました。
それは、諦めではありませんでした。
むしろ、前に進むために必要な判断でした。
配信ルームは3つ。 推しが、いつ、どのルームに現れるかは分からない。 自分は、日中不在。 想定外の挙動が起きても、その場で修正はできない。
この状況で、
すべてをプログラムに任せる仕組みを作ろうとすれば、
失敗したときのリスクが大きすぎます。
「できるかどうか」ではなく、
「今、そこまでやるべきか」
第2回で、そう考え直した私は、
一度立ち止まり、発想を切り替えることにしました。
第3回の今回は、完全自動化から一歩引くことで、最初にして最大の壁を乗り越えた経験をお話しします。
※この記事は連載3回目です。
連載の背景については、こちら。
第0回：趣味から始まる学び | 推し活をきっかけに、自動収録の仕組みを作ることにした話
過去の連載記事はこちら。
第1回：限られた時間でカタチにする。前日の夜、初級者なりに仕組みを作った一日
第2回：想定外の出来事。ルームが増え、今できることを考えた夜の話
完全自動化を捨てて、残したもの
完全自動化を諦める。
そう決めたとき、同時に考えたことがあります。
では、何を残すのか。
すべてを人の手でやるわけではありません。
かといって、すべてをプログラムに任せることもしない。
私が残したかったのは、
・人の判断
・人の意図
・最低限の操作
でした。
「推しがどのルームに移動したか」
それを判断するのは、人でいい。
「次はこのルームを録画したい」
その意思も、人が持っていていい。
ただし、
その判断や意思を、家にいない、PCを操作できない状況でも伝えられる仕組みが必要でした。
「遠くからでも指示できる」仕組みを考える
この時点で、条件はかなり限られていました。
・自宅のPCは起動したまま
・自分は外出中
・iPhoneだけは常に手元にある
・リモートデスクトップのような操作性が悪く、重い操作は避けたい
・操作はできるだけシンプルにしたい
「プログラムを書き換える」
「PC側で何かを操作する」
そういった方法ではなく、
もっと単純なやり方はないだろうか。
そこで浮かんだのが、
「プログラムの外にあって、人が書き換えることができる」
且つ、
「プログラムが“読むことができる”ものを用意すればいいのでは？」
という考えでした。
iCloud と json (設定ファイル)という発想
プログラムに、
「次はどのルームを録画するか」を直接指示するのではなく、
PCとiPhoneの両方からアクセスできる場所に設定ファイルを置く
人がiPhoneから、その中身を書き換える。
プログラムはそれを定期的に読み取る
中身が変わっていたら、その指示に従う
そんな仕組みにすればいい。
その「置き場所」として選んだのが iCloud、
「指示の中身」として使ったのが jsonファイル でした。
といっても、
難しいことをしたわけではありません。
iCloudは、
iPhoneとPCの両方から触れる置き場。
jsonは、
「今はこのルームを録画する」
という意思を書くだけのメモ。
プログラムは、
そのメモを読むだけです。
プログラムは
・なにも判断しない。
・推測もしない。
・ただ、書かれている通りに動く。
その役割分担が、
今の状況にはちょうどいいと感じました。
iPhoneショートカットとの出会い
そして、この仕組みを支えたのが、
iPhoneのショートカット機能でした。
正直に言うと、
このときまで、ほとんど触ったことがありませんでした。
「名前は聞いたことがある」
「よく分からないけど、iphoneのホーム画面にアイコンがある」
その程度の認識です。
しかし、今回の経験で、
普段使いこなせていない、iPhoneに隠された便利な機能、
iPhoneの可能性を感じました。
iPhoneは、
・常に手元にある
・通信環境が安定している
・直感的に操作できる
という、理想的な“操作端末”です。
ただ、唯一の難点は、プログラムの設定ファイルであるjsonを、
iPhoneのような画面タッチで書き換えることの操作性の悪さ。
iCloud上のjsonを書き換える、
これを容易にしてくれたのが、iPhoneのショートカット機能でした。
ショートカットを使えば、
画面を何度も操作しなくても、
数タップで指示を出せる。
そのことを知ったとき、
「これでいけるかもしれない」と思えました。
実際に作った仕組みのイメージはこちらです。
※あくまで全体像を示すための簡略図です。
iCloudに保存した設定ファイルには、PCとiPhoneのどちらからでもアクセスできます。
iPhoneからは、切り替えるルームと時間がわかった時点で内容を書き換えます。
(iPhoneのショートカット機能でワンタップ実行)
PC側は、プログラムが定期的にjsonファイルを読み取り、指定された時間になると録画するルームを切り替えます。
人の手を残した仕組み、完璧じゃないから、壁を越えられた
こうして出来上がった仕組みは、
決して洗練されたものではありませんでした。
・完全自動化ではない。
・人の判断が介在する。
・状況を見て、手動で切り替える必要がある。
一見すると、
「中途半端」
「自動化としては失敗」
そう見えるかもしれません。
けれど、この仕組みには、
この状況だからこその強さがありました。
想定外の動きが起きても、
人が判断して、
最低限の操作で方向を変えられる。
プログラムは、
・余計なことをしない。
・判断を奪わない。
・ただ、決められた役割を果たす。
そのバランスが、
不確実な状況下では、安心材料として働きました。
もし、この時点で
「すべてを自動で判断する仕組み」を目指していたら、
おそらく破綻していたと思います。
・条件は刻々と変わる。
・状況は直前まで不透明。
・検証する時間もない。
そんな中で、
完璧な仕組みを作ろうとすれば、
どこかで無理が出る。
一方で、
人の手を残したこの仕組みは、
・想定外を想定しない
・変化に対して“余白”を持つ
・失敗しても、修正できる
という強みを持っていました。
“完璧じゃなかったからこそ、壊れなかった。”
そう感じた瞬間でした。
自動化は、人を排除することではない
この経験を通して、
自分の中で、自動化に対する考え方が変わりました。
自動化とは、
人を不要にすることではない。
人がやるべき判断を、
無理に機械に押し付けることでもない。
人が考え、決めたことを、
楽に、確実に伝えるための仕組み。
その一部を担うのが、プログラムであり、
その延長線上に、自動化がある。
今回の仕組みは、
まさにその形でした。
制約があったからこそ、生まれた発想
振り返ってみると、
この仕組みは、
「制約の塊」の中から生まれています。
・自分は不在
・時間がない
・想定外だらけ
・完全自動化は無理
もし、時間が十分にあり、
すべてを自由に設計できる状況だったら、
この発想には至らなかったかもしれません。
制約があったからこそ、
・何を捨てるか
・何を残すか
・どこに人の手を置くか
を、真剣に考える必要がありました。
その結果、生まれたのが、
この「人の手を残した仕組み」でした。
最初にして、最大の壁だった
この日は、
まだ完成したシステムがあったわけではありません。
便利なUIもない。
安定した運用も、これから。
それでも、
この日を越えられたことが、
その後すべての土台になりました。
想定外が起きても、考え直せばいい
完璧を目指さなくても、前に進める
仕組みは、一度で完成させなくていい
そう実感できたことが、
何より大きかったと思います。
そして、
次に見えてきたのは「安定して使い続ける」という新たな課題でした。
まとめ
完璧を目指さない。
自動化から一歩引く。
人の手を、あえて残す。
この選択は、
後退ではありませんでした。
むしろ、
制約だらけの現実の中で、前に進むための設計でした。
次回は、
この仕組みを実際に運用する中で起きたトラブルや、
安定させるために加えた工夫についてお話していきます。
コメント