"壊してよいオモチャ"はアプレンティスシップ・パターンにある私のお気に入りパターンの一つです。
お気に入り具合は干支が一周して同じようなタイトルでブログを書いてることから察してください。
"壊してよいオモチャ" とは
自分で作った、自分で使う、自分のためのツールのことです。
書籍の「問題」セクションはこういう文章で始まります。
あなたは、失敗を許さない環境で働いています。
先のブログでも「仕事では安易に失敗することはできません。」と書いていたりします。書籍ではこう続きます。
しかしながら、何かを学ぶ最善の方法は、たいていは失敗することです。
「 "壊してよいオモチャ" を通して失敗を経験していこうぜ」と言うのが大まかなパターンの説明です。
"壊してよい" という言葉
壊してよいと言える条件にはどのようなものがあるでしょうか。 仕事で扱うプロダクトで「壊してよい」と言うためには様々な条件があるでしょう。 自分で使うツールであれば、直せるならば壊しても構わないと言えることが多いです。
着目したいのは「壊れてよい」ではなく「壊してよい」と言うところ。 原題だと「Breakable」となっています。ableなので「壊せる」のような積極的な感じも感じたり感じなかったり。英語わからん。 「何もしてないのに壊れた」は定番のネタですが、このコンテキストでは自分の行動によって「壊す」が盛り込まれています。 壊れてしまうような、むしろ積極的に壊すようなチャレンジをしてもよい。それが "壊してよい" にあるように思います。
"オモチャ" という言葉
「オモチャ」という言葉には「楽しめる」ということが含まれます。
オモチャであり楽しめるものであるべきことを忘れないでください。それらが楽しめなくなり、最初の熱狂の嵐が過ぎ去った後は、それらは埃を被ることになり（以下略
楽しめることが大事です。時間を忘れていじってしまうような、そういうもの。 この辺りがうまく名付けられたパターン名の良さですね。
なおアプレンティスシップパターンには情熱という言葉を含む「情熱を放つ」と「情熱を育む」があります。そういえば同年代に情熱プログラマーという本も出版されてました。「情熱」が流行っていた時期なんでしたっけ。
"壊してよいオモチャ" という言葉
夢中でいじり回して、ぶっ壊してしまって、直して、またいじる。 そんな物体が "壊してよいオモチャ" です。
子供が遊んでいるオモチャを見ていると、簡単に壊れるものの、簡単に直せるようになっているものが多いです。 負荷が集中する稼働部はあえて外れやすく作り、そうでない部分は頑丈に作っている、というような話を聞いたことがある気がします。 これも "壊してよいオモチャ" が持つべき特性の一つでしょう。
ソフトウェア開発者が扱うのはソフトウェアですから、ハードウェアや物体、人などを扱う仕事に比べて "壊してよいオモチャ" を得るハードルは非常に低くあります。せっかくのアドバンテージなので活かしましょう。
"壊してよいオモチャ" を持つ
さてタイトル。 "壊してよいオモチャ" は昔からある言葉ではあるし、珍しいアプローチではないものの、なかなかハードルが高くもありました。
特に近年は自分でツールをつくらずとも、よくできたツールに溢れていました。 特化したツールを使わずとも汎用的なツールでなんとかなる場面も多いです。
書籍でも以下のように書かれています。
たいてい、これらのオモチャは、業界の標準ツールの簡単な再実装であり、（以下略
これは明確に「車輪の再実装」と呼ばれるアンチパターンですが、アンチパターンは特定文脈においては推奨される行動になります。 たとえば「プログラマが知るべき97のこと」の "車輪の再発明の効用" が挙げられます。
"車輪の再発明の効用" では作る過程で知ることが多いところにフォーカスしています。 "壊してよいオモチャ" も同様の記述はありますが、それ以上に使い続けてメンテナンスすることに力点があるように思います。 これは「メンテナンス」というプロセス自体も再発明の範囲と言えたりする感じ。
本稿の趣旨は「車輪の再発明をしよう」という話ではなく「持ち続けよう」です。前者も大事なんだけど、それを踏まえた後者です。
自分のためのツールを作って、それを使い続けましょう。 その過程で得られるものは非常に多いです。 メンテナンスの中には「0から作り直し」があっても構いません。同じ名前をつけた同じ目的のツールを「使い続ける」のが大事です。
AI時代だからこそ
なんでこんなことを書いているかって言うと、AIによって「それっぽく動くもの」を作る速度は明確に早くなったからです。
なのでそれに乗じて自分のための道具を作って、それを使い倒してみるといいんじゃないかなーと最近思っている次第。実際やってみたら思った以上に手応えがあったので書いてます。
「こういうことできる気がする」と言う、自分の「気がする」と言う直感を検証するのが容易になりました。 開発者としての直感を鍛えたり検証したりすると、いろいろ捗ります。
このスライドでは「重々しく捉えなくても100行くらいならノリで書けるでしょ？」とか言ってますが、そりゃ書く労力だけならねぇって感じで。実際は脳内で設計とか走らせてるわけで。難しいものもあるよね。 でもその辺もAIが担ってくれます。思いついたらやってみましょう。
その過程で自分の知らない技術が勝手に出てくることもしばしばあります。そこをとっかかりに対象技術への理解を深めましょう。 「この技術使ってるけど、なんで？」とかAIを問い詰めてみるのもいいでしょう。 知っている技術だけで構成されてしまったなら、意識的に気になっていた技術を盛り込んでみましょう。特定ライブラリやフレームワークでもいいですし、設計パターンでもよいでしょう。キーワードだけぶちこめばそれに沿ってそれっぽいものを作ってくれます。
AIでの初期作成はさっくり作れてしまうので「車輪の再発明」の過程で得られるものはほとんどありません。プロンプトの試行錯誤などはありますが、それはその技術であって「車輪」に用いられる技術ではないわけで。 それゆえに使い続ける点に力点を置きます。 作ったツールを使っていると、当然のように痒いところに手が届きません。 どんどん変更していきましょう。 そして、ふとした変更で簡単に壊れてしまうでしょう。
壊れにくくするのか、直しやすくするのか、置き換えやすくするのか。そういうことを考えて "壊してよいオモチャ" に取り組むのは、これまでも大事だったことですが、今後も活きていくんじゃないかなって。そうおもったりします。
具体例
JIGは私にとっての "壊してよいオモチャ" の代表例です。
2018年4月からなので8年弱さわり続けていることになります。 あまり変更していない時期もありますが、ずっと生きていますし、色々と「壊す」ようなことにも取り組んできました。 壊したときの影響範囲をどうコントロールするかとかも重要なテーマ。 こういうプロダクトがあると「AIと既存コードをぶつけたらどうなるかとか」とかの肌感覚も得やすいです。
JIGは他の人も使っているので「自分だけのため」ではありませんが、 "壊してよいオモチャ" は別に「自分のため」であって「自分だけのため」ではないです。 「自分のため」は自分自身がそのツールに対して要求を出す第一人者であり、動かなくなったりしたら真っ先に困る人ってこと。 他の人のためのツールは動かなくなって困るまでにラグがあったり、ちょっと困っても「別に言わなくていいか」となったりするので違うんです。 作りっぱなしでそれっぽく動くだけのものは "壊してよいオモチャ" ではありません。ここ大事。
あと全然開発に関係ないものだと、将棋の棋譜閲覧ツール。
完全に自分専用で配布とか考えてないんだけど、vibe coding 100%でKotlinつかったデスクトップアプリと言う。Kotlinなんもわからん。vibeなので一行も書いてないけど、一応読んではいる。純粋に「趣味で自分が欲しいと思ったもの」に振り切っているのがポイントで、作りが微妙でも「まぁ動くならいいや」と進めていたりする。そのうち「仕様を出力してゼロから別の技術使って作り直した時にどの程度のものになるんだろう」みたいなのを試しそうと思ってる。
他にも開発で使うツールは色々あったりします。 "壊してよいオモチャ" は毎日のように使うのが大事だと思います。 少しの引っ掛かり、ちょっとした機能追加。そう言うのを使いながら感じるのはある種の才能かもしれませんが、ある程度は習得できる技術だとも思います。 使っている間は情熱を持ってメンテナンスするのですが、役目を終えて使わなくなったものはメンテナンスもしなくなります。打ち捨てられるのもオモチャの宿命かね。
脱線：失敗について
失敗に関しては昔（2013年）にこんなこと言っていたり
最近だと若干まるい表現に。
表現がまるいだけで、言ってることは「失敗しようぜ」である。
脱線：パターンの使い方
「アンチパターン」とか「デザインパターン」とかはよく見聞きするでしょうし、個々のパターンが言及されることは日常でも少なくありません。
パターンはパターンとして名前がついて輪郭を帯びるだけでもかなりの力を発揮します。 そのため「特定の状況のこと」をパターンと呼んでいることもしばしばあります。
これはこれで間違いないのですが、パターンの力はそんなものではありません。 パターンにはコンテキストやフォースなどもありますが、大きいのは「パターンはパターン間で繋がる」ということです。 パターン間が繋がるとテコの原理が働き、相乗効果が生まれます。 一つのパターンだと語りきれない状況もパターンを組み合わせて網目を構築すると掬えたりしますし、新たなパターンで補うこともできます。
「これパターンだっけ？」と思ったら、そのパターンの原典をあたるなりAIに聞くでもいいので、関連パターンに意識を向けてみましょう。 きっと新たな発見があります。
ちなみにChatGPTさんに「壊してよいオモチャの関連パターンは？」と雑に投げると、以下が返ってきました。
書籍で記載のあるものとかぶっていたりいなかったりですが、まぁ確かにという感じ。どう関連あるかとかも言ってくれるのでよかですね。
まとめ
好きなAIで好きにまとめて。←
いや正直、人が書くブログなんて思考を原液で垂れ流すくらいのほうが今後は価値あるんじゃないかなぁって思ったりするわけですよ。
あ、 "壊してよいオモチャ" って言う言葉から個の何かをイメージしがちなんだけど、部分的に「ここは "壊してよいオモチャ" にできるな」みたいなのがあります。 たとえば仕事の中でプロダクトでは難しくても、テストコードだとかCI環境だとかは "壊してよいオモチャ" として、壊れてしまうかもしれないチャレンジをしがいがある場所です。うまいこと設計すればプロダクトの中でも "壊してよいオモチャ" 領域は作れます。仕事の中で "壊してよいオモチャ" で遊びながら力もつける、なんてことを無意識にできるようになると、経験値も爆上がりでタイパも良いです。と言うかそう言うことができないと「仕事外の時間で勉強しなければならない」みたいなことになっちゃって、なんともだよねって思ったりします。
まとめセクションに発散することを書くんじゃない。
