試運転は、できるかを確かめる場ではない

試運転は、できるかを確かめる場ではない。自分の文脈に馴染むかを確かめる場だ。これを取り違えると、新しい道具をひとつ覚えるたびに既存のスタックが膨らみ、いつのまにか自分が道具に飼われている。

きっかけはufolium.comだった。3Blue1Brownを日本語に翻訳しているチャンネルで、彼らがPythonのManimというライブラリを使っていることを知った。数式と図形が滑らかに動く、あの独特の表現。お手本にしたかった。今のGSAPと比べて何が違うのか、どこまで描けるのか、自分の手で確かめたかった。

三本のデモを書いた。Manimは書けた。書けたうえで、採用しないと決めた。

理由はManimの限界ではない。むしろ逆だ。Manimにできることは、GSAPでも、それを内包する周辺ライブラリでも、ほぼ同じ表現が可能だった。だとすれば、判断は単独性能の比較ではなくなる。すでに自分が握っているもの、つまりGSAPと既存の素材群に、Pythonという別の言語を一本足すことの煩雑さ。それが採用を止めた。

道具は、それ単体では選ばれない。すでに自分が握っている道具との角度で選ばれる。

ただし、ここでひとつ向きを変える必要がある。自分が握っている道具、と書いたが、自分はもうコーディングを直接書いていない。書くのはAIだ。だとすれば「自分が握っている道具」とは、自分の手元の道具ではなく、AIが既に握っている道具のことになる。Manimを採用しなかった本当の理由は、煩雑さの先にこれがあった。

そうなると、自分のスキルは書く技術ではなくなる。伝える技術になる。AIに何を、どの粒度で、どの順番で渡すか。AIには得意と苦手がある。空間認識は苦手だ。三面図を渡しても立体は組み立てない。逆にFusion 360との連携は、APIを叩くテキストを生成する形なら筋が良い。得意・苦手の地図を持っているかどうかで、伝える技術の精度が変わる。

時間が経てば、これも変わるだろう。AIが空間を読めるようになれば、自分の役割はまた別の場所に移動する。今は伝えることに注力する、というだけの話だ。試運転で確かめたのは、Manimの性能ではなく、自分が今どこに立っているかだった。

道具を試すことの本当の用途はそこにある。新しい道具を一本書いてみると、自分の足元が一段はっきり見える。書けたから採用する、書けなかったから諦める、ではない。書いてみて、自分の今の立ち位置が確認できる。それが収穫だ。

Manimそのものは捨てない。社内の技術勉強会で使う候補として、引き出しに入れておく。3B1BJPは時々眺める。文脈が変われば、また呼び出す日が来る。