はじめに
先日、人生で初めてサーカスを生で見ました。
まずは普通に感動しました。
「すごかった」「いや本当にすごかった」しか出てこない。
いわゆる小並感。
ただ、気づいたら変なことが起きていました。
なぜかそこに自分の仕事が透けて見えてきたんです。
「例外処理やリカバリーフローの設計がすごい」「依存関係が整理されたワークフローみたいだな」「オンボーディングうますぎる」...
そんな感想が、観ている間中、頭の中にずっと浮かんできていました。
自分でそうしようとしたわけじゃない。
気づいたらそうなっていた。
完全に職業病でした。
テーマで言えばこんな感じです。
- 再現性
- 段取りと依存関係
- 失敗を織り込んだ設計
- UX設計
- 見えない運用や鍛錬
といった、エンジニアリングにも通じる感覚を覚えました。
この感動を「すごかった」で終わらせるのがどうにも惜しくなって、
サーカスを無理やりソフトウェア開発に当てはめたいわけではないんですが、
ちょっと整理して本記事を書きました。
最初に強く思ったのは、「これ、再現性の塊では？」ということだった
サーカスを見て最初に受けた衝撃は、もちろん個々の技のすごさでした。
ただ、見ているうちに別の意味でもかなり驚きました。
これ、全部ちゃんと毎回成立させてるのか？
という点です。
会場はテント。
常設会場ではありません。
つまり、
- 建てる
- 公演する
- 撤収する
- 次の場所でまた建てる
ということを繰り返してるはずです。
これは...IaC...!?
Terraformのように厳密な意味ではないにしても、感覚としては近いですよね。
毎回きちんと立ち上げられて、撤収できて、次の場所でも同じ品質で回せる。
インフラの言葉で言えば、
provision して終わりではなく、deprovision まで含めて成立している設計になっています。
しかも、ただ建てられるだけでは意味がありません。
- 観客を安全に入れる
- 公演を成立させる
- 終わったら撤収する
- 次の土地でも同じ品質で回す
「一回成功したら終わり」ではなく、何度でも同じ品質で回せることが強さになっています。
どこから作る？どこから壊す？
テント(というか会場そのもの)を移動させる前提だとすると、その作業のパターン化・効率化も相当練られており、各種機材(リソース)の依存関係もきっときっちり管理されているのだろうと。
我々のインフラにしても運用にしても、本当に強いものは「頑張って一回立ち上がったもの」ではないと思います。
作り直せるもの、戻せるもの、再現できるもの。
サーカスを見ながら感じたのは、奇跡のような技というより、再現可能な奇跡という印象でした。
演目そのもの以上に、演目の"つながり"がすごかった
もうひとつ印象に残ったのは、演目の切り替わり方でした。
準備、撤収、転換がとにかくきれいで、流れが途切れない。
観客から見える部分は華やかだけれど、その手前の「つなぎ」が異常にうまい。
ここで見ていて連想したのは、CI/CDというより、依存関係を整理したオーケストレーションやワークフローでした。
ある意味、DAGで組まれたパイプラインに近いと思います。
- 何を先に片付けるか
- 誰がどのタイミングで入るか
- どこまで終われば次に進めるか
単に速いのではなく、詰まらないように設計されている感じがあります。
構築して終わりではない。
撤収まできれい。
しかもその構築と撤収が、次の演目の成立を邪魔しない。
データ基盤のワークフローやジョブオーケストレーションを見ているときと、少し似た感覚でした（dbtでDAGを組んでいる人なら余計そう感じるかもしれません）。
派手な技はもちろん主役ですが、本当にすごいのはそれらを一本の興行として成立させている流れなのかもしれません。
ただ、流れが途切れないだけじゃなくて、緩急もちゃんとあるんですよね。
すごい技の後に、ピエロが出てきてネタをやる。
すごい技をやると思いきや...ってやつです。
ギャグ、緩い技、成功すると見せかけて成功しない仕込み等。
笑いが起きて、場の空気がほぐれる。
最初は「つなぎ」かと思ったんですが、あれがないとたぶん観客がもたない。
緊張感がずっと続くと疲弊するので、ピエロのパートは「息継ぎ」として意図的に設計されているように見えました。
システムでも、全部が最高負荷である必要はないですよね。
処理の重さに緩急をつける、バッファを置く、時間差で処理する。
人が触るものなら、疲労感まで含めた設計が必要になる。
ピエロがいないサーカスは、たぶんしんどい。
チームワークが良いというより連携が「型」になっている
サーカス全体を見ていると、演者同士もスタッフも、とにかく連携が速い。
もちろんチームワークが良いのは前提としてあります。
ただ、それ以上に印象的だったのは、連携そのものがほぼ「型」になっているように見えたことでした。
- 誰が補助に入るか
- 合図が来たら何をするか
- 少しズレたら誰がフォローするか
それが空気ではなく、身体に入ったプロトコルとして動いている感じでした。
エンジニアの現場でも、強いチームは「仲が良いチーム」だけではないですよね。
誰が何を持ち、どこで次の処理が動き、どこで助けに入るかが整理されているチームが強い。
Runbookや運用手順が身体化されているチーム、と言ったほうが近いかもしれません。
サーカスの連携は、属人的な神業というより鍛えられた個人が、鍛えられた型の上で噛み合っている感じでした。
これはかなり理想的なチームの姿に見えました。
それと、改めて思ったんですが、サーカスってこんなにジャンルが広いんですね。
空中ブランコ、ジャグリング、マジック、バイク、動物、棒逆立ち、ピエロのコーナー、他諸々。
当然、全部同じ人がやっているわけじゃない。
それぞれの演者が、それぞれの領域で完全にプロです。
でも全部が、一本の興行として溶け合っている。
強いチームって、なんでもできる一人がいるんじゃなくて、専門家がちゃんと噛み合っているチームのことだと思っています。
サーカスはそれが完成形として目の前にある感じで、かなり刺さりました。
あと気になったのが、同じジャンルの中に複数の演者がいる演目があったこと。
全部が全部そうじゃないんですが、複雑な演目ほどそうなっていた気がします。
同じ文脈を持てる人が同じジャンルに隣にいる(一緒にやる)。
それだけでも属人性はかなり緩和されますよね。
目に見えない部分が、全部を支えている
ここまで書いてきたことは、どれも「見えている部分」の観察です。
でも実際には、その裏に膨大な鍛錬と、日々の運用がある。
毎日の練習、疲労や怪我のケア、調整、機材のメンテナンス、テント設営から撤収までのオペレーション。
観客には一切見えない積み重ねが、公演約2時間/回を支えています。
エンジニアリングも全くそうで、よく動くシステムの裏には深夜の障害対応、地味なリファクタリング、ドキュメント整備、アラートの細かい調整がある。
本番で「なんとなく安定している」ように見えるものの背後には、ものすごい量の見えない運用が詰まっています。
サーカスを見ながら、「自分たちの仕事もこういうものだ」と少し噛み締めました。
派手さよりも、それを支える土台の方にシンパシーを感じてしまうのは、エンジニアの性かもしれません。
動物の演目を見ていたら、AIエージェントを思い出した
これは今時だからこそかもですが、刺さったことがありました。
それは動物の演目ですね。
動物は言葉が通じない。
細かい指示を理解できるわけでもない。
でも、トレーナーの合図を受けて動いて、うまくいかなかったら動物が自分でリカバリーを試みる。
見ていてかなり率直に思ったのは、これ、今のAIエージェントっぽい ということです。
オーケストレーターがいて、サブエージェントがいて、タスクを割り振って、結果が返ってきて、うまくいかなければリトライする。
トレーナーと動物の関係が、そのまま重なって見えました。
しかも、動物が失敗してもショーは止まらない。
トレーナーがすぐ動いて、別の流れに切り替える。
1匹だけその場を離れる姿があったのは、別のタスク(演目)の準備のために抜けたか、流れを壊さないために退いたかのいずれかかなと思ってます。
あのリカバリーの自然さは、エージェント設計を考えるときにちょっと参考になる気がしました。
（サーカスって、ずっとマルチエージェントをやってたんですね...違うか）
失敗を織り込んだ設計に刺さった
個人的に、ここが今回いちばん心に残りました。
サーカスにはハラハラする瞬間があります。
少し危なそうに見える瞬間、間が生まれる瞬間、崩れたかと思う瞬間。
でも、そこで全部壊れない。
ちゃんと続く。
そしてショーとして成立したまま流れていきます。
失敗を減らす努力は当然あります。 でも、それでもゼロにはできない。
だからこそ、
- カバーする仕組み
- リカバリーの流れ
- 仕切り直す余白
が最初から設計されているんだろうなと思いました。
まあでもサーカスにおいては、失敗したように見せるハラハラ演出自体も「仕掛け」のひとつだとは思います。
たとえば空中ブランコでは、演目の下にネットがあります。
あれは「最悪の事態を防ぐ安全策」であり、同時に大技の挑戦を可能にするガードレールでもあります。
しかも、ただそこにあるだけじゃない。
演目の終わりに演者がネットに飛び降りて、そのバウンドでくるくる回ってポーズを決める。
安全策のはずが、実はフィナーレの舞台になっていたんですね。
何かを防ぐために置いたものが、別の価値を生んでいる。
エンジニアリングでもこういう設計があると面白いなぁ...(ある？これだ、ってものが思いつかない...)
いろいろ書きましたが、本当に強い仕組みは絶対に失敗しないものではない。
失敗しても壊れないもの、リカバリできるもの。
というのは、エンジニアリングでも同じだと思います。
例外処理、リトライ、フォールバック、ロールバック。
バックエンドでもデータパイプラインでも、ここが弱いと本番はすぐつらくなります。
サーカスは、それを身体で体現しているように見えました。
観客参加の演目で感じた、「すぐ分からせる設計」のすごさ
観客参加の演目も、かなり強く印象に残っています。
その場でランダムに選ばれた素人の観客に役割を与えて、一緒に演目を成立させる。
しかもほぼノンバーバルで成立している。
細かい説明を長々としなくても、見せて、一緒にやって、理解させる。
複数あった参加者企画のうちの1つを取り上げると構成はこうでした。
ピエロが2人、参加者が1人。
- 簡単なアクションをピエロ2人で手本を見せる→参加者にやってもらう
- ちょっと難易度をあげて、ピエロ2人で手本を見せる→参加者にやってもらう
- ピエロはノー参加。ノー説明。いきなり参加者に手のひらで「どうぞ！」
「3回目で何をするか」は、誰も言わない。
でも、1→2の流れを見ていれば、3で何をすべきかは自然にわかる。
ピエロが「次はわかるよね？」な空気を無言で出すので、笑いが起きる。
会場全員が「あ、そういうことね」となる瞬間があるんです。
しかも難易度が絶妙で「頑張ればできるライン」に収まっている。
失敗したらピエロにジェスチャーと効果音付きで「ブブー」ってやられて、2〜3回リトライできる模様。
成功したら大拍手！
正直に言うと、最初は「これ、事前仕込みでは？」と疑いました。
最初に声がかかったのが料金高めのプレミアム席だったので。
でも次のシーンで、ピエロが私の席のすぐ近く（通常席）でキョロキョロしながら「誰にしようかな〜」という感じで客席を見回してランダムに人を選んでいたんですよね。
それでも演目はちゃんと成立していた。
この流れを見ていて思ったのは、オンボーディング設計の理想形ではということでした。
特にすごいのは、「次に何をすべきか、教えなくても伝わる」設計になっている点です。
演目の3回目で何をすべきかは、1と2を見ていれば自明になる。
説明コストゼロで次のアクションが伝わる。
エンジニアリングでも、優れた仕組みは「説明しないと使えないもの」ではなく、見ればわかる、触ればわかる、一度一緒にやれば再現できる、という方向に寄っていくと思います。
(まあそれは極論かもですが。そうであって欲しいという想いベースなところはありつつ)
サーカスがそれを演目の中でやってのけていて、ちょっと感動しました。
ただ、サーカスとシステムでは「ハラハラ」の意味が違う
ここは似ているようで、決定的に違います。
サーカスは、ハラハラそのものを商品にしています。
観客は手に汗握る体験を求めています。
一方、システムは基本的にハラハラを売ってはいけません。
- 決済が通ったか不安になる
- 保存できたか不安になる
- バッチが終わったか不安になる
こういうハラハラは、価値ではなく不具合です。
なので、サーカスから学ぶべきなのは人をハラハラさせることではありません。(そりゃそう)
ハラハラする状況を、事故にしない設計。
- サーカスは「制御されたハラハラ」を売る
- システムは「制御された安心」を売る
みたいな感じですかね？
両者は商品が違います。
でも、その裏側で必要になる準備・設計・リカバリー等「見えない支え」の思想は似ているはずです。
そこに何かしらシンパシーを感じました。
おわりに
いや〜、サーカスまじですごかったです。
自分の中に残ったのは、技のすごさだけではありませんでした。
上記で書いた通り、表裏(妄想含む)いろんなことに、かなり心を動かされました。
子どもの頃にサーカスを見ていたら、たぶんこうは思わなかったと思います。
その頃ならきっと「すごい」「こわい」「ピエロおもしろい」で終わっていたはずです。
（それはそれで純粋でよかったかもしれませんが...）
でも今は、技そのものだけでなく、それを成立させている構造に目が行ってしまいます。
エンジニアをやった後だからこそ、刺さるものがあったのかもしれません。
サーカスは身体でそれをやっている。
我々はコードやシステムでそれをやっている。
媒体は違っても、本番を成立させるためのプロフェッショナリズムの構造は、きっとかなり似ています。
以上です。