プロから音源のアドバイスをもらえる「音源センセイ」という企画（？）を島村楽器がやっているのですが、それに応募していた『ワルツを踊る猫』が店内BGMに選出されました。明日7/1から全国の島村楽器で流れるようです。うれしい。
じつは2025年にも『天色reverb』という楽曲が同様に島村楽器店内BGMに選出されており、今年は1年ぶり2回目の選出となりました。うれしい。こちらも合わせてどうぞ。
本質的な複雑性と偶有的な複雑性の違いは実は自明ではない
本質的な複雑性と偶有的な複雑性の区別は、有名な『銀の弾丸はない』で提唱されたものだ。
本質的な複雑性というのは、「どうあがいても、その問題に内包されている複雑性」のことで、たとえば医療で言ったら「麻薬施用免許を持たない医師やスタッフが麻薬処方の指示を出してはいけない」というのはあたりまえの話だけど「じゃあその処方箋はどう現場で管理されないといけないんですか」とか「鍵付きのところに保存されてないとダメで、そこから取り出すためには麻薬施用免許を持った医師が出して、麻薬施用免許を持った医師がハンコを押した処方箋がないといけない、そしてそれは参照できるところに管理されていなければならない」みたいな話はまあ、医療安全上の本質的複雑性だと言っていいだろう。
一方で偶有的な複雑性というのは、実装方法だとか、技術的な制限だとか、あるいは間違えた解決領域を作ってしまったことだとかによる複雑性だ。たとえば、システムがバッチで一度にデータを処理する機能を作っていないせいで、ユーザーが一件一件目grepしながら正しいデータを登録しなければいけない手間だとか、まあそういうやつ。
一般的に、本質的な複雑性に向き合いましょう。そのためには、偶有的な複雑性を減らしていきましょう。というのが、「模範解答」だと思う。
しかし、世の中ってのはそんなに簡単ではなくて、すくなくともひとつの問題がここに絡んでくる。それは、「本質的」というものは本質的に主観的（と言ってしまうのが言い過ぎであれば、間主観的）なものである、ということ。
この世の中に、ア・プリオリに本質的なものは存在しない。というか、そもそも「問題」すらア・プリオリには存在しない。だれかがなにかを「問題視」して初めてそこに問題が生まれる、という考え方にぼくはたつ。さて、問題領域がそうやって生まれたときに、そこに対する「本質」ってのもまた、「誰かがこの視座から見たら本質的に見える」というように判断することではじめて「本質性」というのが立ち上がってくる。「問題の本質」は問題に内在しておらず、その問題に対峙する人間の観察に存在する。それが「本質」というのは本質的に主観的である、ということの意味だ。異なる主観をぶつけ合い、磨き合い、間主観性の中で生まれる「本質」もあるだろうけれど、それは議論に参加しているひとたちの間主観に存在するもので、やはり問題に対してア・プリオリに存在するわけではない。
つまり、「本質性」というのは、だれがその問題に対峙するかによって容易に変化するものである、と言える。
ところで、ぼくたちがなにかサービスやソフトウェアを作っているとする。このとき、前述した通り「本質的な複雑性に向き合いましょう。そのためには、偶有的な複雑性を減らしていきましょう」というのが「模範解答」であろう。このお題目は大変に必要だし、何が本質的な複雑性で何が偶有的な複雑性なのかを仮説でいいから切り分けて、「筋の良さそうな切り分け」を目指すのは大事だ。つまり、「いまそれを作っているひとたちにとっての間主観性で削り出した本質的複雑性と偶有的複雑性の区別」があるのとないでは、全然問題解決の筋のよさが違うということはあたりまえにおこる。
仮説でいいからこのふたつの区別をやらないと、「いまの業務が持っている偶有的複雑性を維持するためだけの要らない機能を作りまくってそれがその後の足枷になる」みたいなことが平気で起こる。本質的な複雑性を偶有的複雑性だと読み間違えて、「実際はそこの細かい仕様が満たされていないと業務上重要な担保したいことがみたせねえんだよ！！！」みたいなことが平気で起こる。だから、がんばってこのふたつを切り分けようとするのはたいへん大事。
しかし、である。ここでさらにややこしいことに、「よし、切り分けて、偶有的複雑性を排除して、本質的複雑性に向き合ったぞ！！！」とおもって、ユーザーにサービスを使ってもらうと、ま〜〜〜あびっくりするくらいにわれわれは本質的複雑性と偶有的複雑性を見誤っていたことに気づいたりする。いくら頭のなかでやっててもそれは想像でしかなくて、実際に動くブツで、実際に動く業務をやってみないことには、われわれのサービスがなにをどれくらい実際に解決できて、どんな偶有的複雑性を持ち込んでしまったのかが、わからない。これはべつにわれわれが無能なだけじゃなくて、やはり「ないものでないことをやってても気づけない」んだ。それは「あるものである業務を実際にやったときに初めてユーザーさんが気付けるような、実戦で使われ、初めて形が見えてくるもの」なんだよな。
つまり、本質的複雑性というのは「実際にユーザーが実際のものを使った時に、ユーザーや我々の間主観性の中に立ち現れてくるもの」であり、ア・プリオリに存在するものではないわけだ。
だから、ふたつのことが言えて、ひとつは、なにが本質的な複雑性でありなにが偶有的な複雑性であるかは自明ではないので、みんなで知恵を絞って仮説としてたててサービスをつくらないといけない、ということ。この仮説の精度は大事。そして、仮説の精度がいくらよくても、だれかの頭のなかにある本質的複雑性ではない、「本物の本質的複雑性」は現実の運用の中でからしか見出されないので、実際に存在するものを使ってもらうことでしかわからない、ということ。
「本質的複雑性だとおもって向き合ったところが、どっちかっていうと偶有的複雑性でした」（あるいはその逆）に対して、そうして得られた学びをシステムにフィードバックし、直していければ、チームの筋肉が育っていくし、サービスは常に新しい「本質的複雑性に向かい、偶有的複雑性を減らす」ための新しいやり方に向かっていける。一方、学ぶことはできたけど、それだけではコードはなにも変わっていない場合、システムの現状と「学習されたはずの本質的複雑性と偶有的複雑性の分離」はどんどん乖離していく。これは本来の意味での「技術的負債」というやつだし、「ドメインの蒸留」という言葉が指しているのも、ここでの学びをソフトウェアの設計に再投資していけ、という話のはずだ。
というわけで、ぼくは日々、本番で使われているサービスこそが最も学びの多い場であり、最も負債が貯まる場所だと思っている。これはいいことなのだ。学習の機会なのだから。そしてこの学びをもって、粛々とこの負債を解決していきたい(=新しい学びにマッチする構造にソフトウェアを変えていく）。さらには、新しく見えてきた「現場のここを解くことで現場が抱えた偶有的複雑性を肩代わりして、現場が本質に向き合える！」といういわゆる新機能を同時に作り上げていくことだって貪欲にやっていきたい（それはまた新しい学び/倒すべき負債を産むことになる。世界をよくする永久機関が完成しちまったなぁ〜！！）。と、最近はこいう夢をもって日々を過ごしている。それだけの夢を説明するのに、これだけの背景を説明しているのは、ひとことで言ってしまえる夢のそのバックグランドを知って欲しかったから。
「課題を解決して飯をくう」をやっているひとたち、一緒に、こういう夢をもって日々を過ごしていきましょう
メトロノームアプリを大幅改訂した
前回の記事を見て、BPM Prompterはやっぱりうまくできているな。と思った。で、じつは昔groove partnerというメトロノームアプリを使ってたんだけど、それに対する不満とかが言語化できたので大幅改装した。
https://groove-partner-2.netlify.app/
特徴としては 1. 曲を複数保存できる 2. Bpmだけではなくリズムパターンもかなり柔軟に指定できる 3. サーバーで状態を持たない。ブラウザだけで動く 4. ブラウザ側で持っている状態はURLに埋め込まれてるので、URLの共有や保存がそのまま状態のシェアや保存となる 5. クリック音はmp3にエクスポートできるようにきている
これけっこう便利なはずで、リハスタでしっかりBPMを自分たちの体に覚えさせたいときはこっち、クリックを出すまでもないあるいは出せないところ（本番とか、本番直前でクリックの補助輪を外したい練習のときとか）はBPM prompterを使うと、かなり練習、本番が捗るのではないでしょうか。
これらを統一アプリにしたい誘惑がうまれるのが人の常だが、じつはこのふたつは解きたい問題がことなるので、別アプリにしておくべきだろうという判断をている。
BPM Prompter、弊バンドではかなり活躍しているが、今後はGroovePartnerもヘヴィスユースされるのではないでしょうか。
バンドマンは使ってみると地味にライフチェンジングだと思う。
BPM Prompter: https://bpm-prompter.netlify.app/#%5B%7B%22title%22:%22song%20title%22,%22bpm%22:120%7D%5D GroovePartner: https://groove-partner-2.netlify.app/
ClaudeCodeに /goal 一発でほぼ出来てはーすごいっすね〜となった。生活が向上していてうれしいですな。
バンドのレパートリーのbpm一覧管理とセトリ作成をdiscord経由でclaudeにやらせる
モチベーション
うちのバンドでは、ライブごとにセットリストをbpm prompterで作り、練習中に参照したり、本番でも足元などで表示している。
これがけっこう便利で（デザインがダサかったりするんだけど視認性のためにあえてだったりする）、まだ体にBPMが入っていないときにこれを見ながらリハスタで練習するのもかなり効率が良いし、リズム隊などカウントを出す側は本番でも足元などにこれをおいて「へんなBPMでカウントを出してしまわないようにする」ということを実現している。ぼくはバンドじゃなくてアコースティックユニット的な編成でライブすることもあって、そういうときもこれでセトリを表示しながらやるとBPMがその日の体調や気分に影響されずらくて良い。
で、これ便利なんだけど、問題がふたつあって：
- セトリをぽちぽちと入力するのがだるい
- セトリを組むとき、「あれ、この曲BPMはいくつだっけ」となり、毎回曲を聴いたり調べたりしている
後者はレパートリーとそのBPMをちゃんと一元管理していないのが問題で、「ちゃんとやれ」という話だし、セトリ入力するのなんか5分もあれば終わるんだからこれも「ちゃんとやれ」なのだけれど、バンドマンに「ちゃんとやる」ことを求めるのは、鶏に「飛べ」というようなもんである。
まあこういうめんどうなのは、人間がやるんじゃなくてAIくんにやらせようぜ、というのが令和最新版のトレンドであろう。幸いわれわれのバンドはコミュニケーションをバンド用discordサーバーで取っている。というわけで、じゃあdiscordでbotに指示を出したらレパートリーを管理、更新してくれたり、BPM prompterでセトリ作ったりしてくれるようにすれば、スタジオに入っているときだとか寝転びながらバンドの打ち合わせをdiscordでしているときとかにパッと指示出してシュッじゃんね、ということである。
手法
- discord にbotを常駐させる
- こいつはrailwayで動かす
- botの内容
- claude のapi keyをわたしておく
- レパートリー用のシートへの書き込み/読み込み権限渡しておく
- toolsは以下のように汎用的なものを用意しておく
- レパートリーのスプシを全部読むというツール
- 任意のセルを書き換えるというツール
- ここはかなり強めの権限をLLMに委譲することになるので、データ破壊が怖いところではある。が、べつにバンドのレパートリーが破壊されたからってなんぼのもんじゃい。と思っている
- セトリをBPM prompterで作成する
肝は、BPM prompterの作りで、こいつは実はサーバー的にはステートレスで、曲順、曲名、bpmなどはすべてURLに保持するようになっている。つまりBPM prompterでセトリを作成する = URLを作成する、なのである。だからこういう使い方と相性がいいのだわね。
demo
こういうことが可能となった
さいごに
なお、この仕組みを作るにあたってコードは自分で一行も書いていない（ぜんぶClaude Codeにやらせた）。レビューはざっとしている。すごい時代になったもんである。
「音の三原色」という夢（夢は夢である）
光の三原色、というものがある。これは、赤、緑、青の光をいろいろな強さでまぜることで様々な色が表現できる、というやつだ。
ところで、光は波である。色とは、言い換えれば、その光のどの周波数成分にピークがあるか、ということだ。つまり、赤の光の周波数成分と、緑の光の周波数成分と、青の光の周波数成分をうまく合成することで、可視光線内の任意の色の周波数特性を持つ波を作れる、ということである。同じく、音は波である。ならば、同じ理屈で、三つの音をうまいこと混ぜるだけで可聴域の任意の音が合成可能なのでは？ と思いついたわけだ。つまり、「音の三原色」という夢である。
賢明なるみなさまにおかれては、「それは成り立たない」ということも同時に気づいたのではないかと思う。というのは、実は光の三原色というのは「光側」の特性ではなく、「人間の目の側」の特性だからだ。人間の目が、RGBそれぞれのピークを選択的にキャッチする。つまり、RGBの3色で再現されている「えんじ色」は、自然界にある「えんじ色」と同じ周波数特性を必ずしも持っているわけではなく、人間の目が選択的に捉えるピークにおいて同じ程度の成分が含まれていることしか意味しない。つまり、人間の目の分解能をうまくつかったのが光の三原色の仕組みであると言える。三つの波を合成して、あらゆる波を再現しているわけではなく、三つの波を合成することで、人間の目にとっては同じに見える波を合成している、というわけ。
一方、人間が音を聴くときは、そのような仕組みになっていない。可聴域というものは存在するが、可聴域において選択的にあるピークを聴き取っているわけではない。むしろ可聴域においてはあらゆる成分を聴くことができる、というほうが近いかもしれない。改めて人間の耳の分解能の高さに驚く。たった三つの波をうまく合成するだけで任意の音を再現する、ということはできないわけだ。
「音の三原色」という夢は夢として終わってしまうわけだけれど、同じ波であるはずの音と光でも、「人間の側の性能」で合成について異なる様相を見せるのは、すこし面白い違いだと思う。
「半分に割った赤いリンゴのイビツな方」はどのような形をしているか
スガシカオの名曲『アシンメトリー』には、「半分に割った赤いリンゴのイビツな方をぼくがもらうよ」という歌詞が出てくる。どこかでスガシカオ本人が、「このフレーズは、男の不器用な優しさがうまく表現されていてうまく書けたな、と思っていたんだけど、"半分に割ったんだから片方が歪ならもう片方も歪なんじゃないの？"と突っ込まれて"そうじゃん！"と気づいた。図らずも男のひとりよがりな浅はかさを表現することになってしまった」というようなことを言っていた覚えがあるのだけれど、それがどこだったかうまく思い出せない。スガシカオ本人がそう言っていた、というのもどこかでなんかの記憶がごっちゃになっているだけかもしれない。それはともかく、ぼくはこのエピソードが結構気に入っている。
しかし、である。「半分に割ったんだから片方が歪ならもう片方も歪なんじゃないの？」というツッコミは果たして正しいのだろうか？ たしかに、りんごを「パカっ」と半分に割ったとき、片方が歪な形をしているのであればもう片方も歪になるというのは直感的には正しそうに思える。しかし、まずは話を簡単にするために、円で考えてみよう。いま、原点Oを中心とし、半径1の円Aがあるとき、座標(0,1)を通り、なおかつ中心が(0,a)ただし a > 0かつ a < 1であり、面積が円Aの半分であるような円を考える。このとき、円Aと円Bは以下のように描くことができる。
これは、もとの円の面積を半分にし、片方が歪で片方が正円であるような分割方法である。これを立体にまで拡張することで、「半分に割った球の歪な方と球体のほう」という分割が可能なことは自明である。つまり、こういうことである。
つまり、「半分に割った赤いリンゴのイビツな方」と「そうでない方」というのは存在できるので、スガシカオさんは「図らずも男のひとりよがりな浅はかさを表現することになってしまった」と言う必要はないわけである。ひとりよがりのロマンチストの浅はかな男たちは、救われたわけである。しかし、こんなことを考えている人間はかなり救われないバカであるかもしれない。
株式会社ヘンリーに入社しました
エイプリルフールではありません。いわゆるIC的なポジションで様々な問題解決に精を出す所存です。入社初日で、まだまだなにも成しておらずですが、成果がきちんと出せるように努力していきたい。退職エントリを書いたので取り急ぎ対となる入社エントリを。
