計算量の見積りは「最適化するするため」だけではなくて「複雑な最適化をしないで済むため」にも大事

とくにサーバーサイドのソフトウェアエンジニアリングにとって、計算量の見積りをするのは大切だ。というと、「うん、そうだよね、最適化って大事だよね」という話になりそうだけれど、今回書くのはそういうことではなくて、むしろ「最適化をしないで済むために計算量の見積りが大切」という話。

たとえば、計算量の見積をせずに「なんとなくこのあたりが重くなりそうだからキャッシュ入れておこうか」「なんとなくこのあたりが重くなりそうだから工夫したアルゴリズムにしておこうか」としたとき、わたしたちは「状態を新たに導入したことにより、状態の同期を考えなければならないコスト」や「複雑なアルゴリズムをメンテし続けるコスト」を引き受けている。しかし、このときに「ここの計算量はたがだかO(log N) であるな」とか「たかだか線形であるな」とわかっていれば、「たかだがO(log N)なので、まあキャッシュせずに毎回計算でええやろ」とか「たかだか線形なので、（ページネーションなどで）Nの数にcap持たせる仕様にしても問題ないならそれでええやろ」としてメンテナンスのコストを引き受けずに済む。あるいは、「ここの計算量がO(N2) になってしまうなあ」とわかっているときに「じゃあもっといいテーブル設計できないかな」と検討しなおすことで安易にキャッシュしたりせずにすむかもしれない。

わたしはいままで結構、「創意工夫」の結果複雑な状態管理や複雑なアルゴリズムになってしまっているシステムを見たり作ってしまったことがあるが、そのうちの結構な数が、「そもそも計算量ちゃんと見積もったら全然問題ないところを創意工夫している結果生まれた複雑さ」だったりした。

なのでまあ、計算量を見積もるというのは「パフォーマンスに困った時にやること」じゃなくて、そもそもコード書く時、テーブル設計するときに計算量を見積もって、いらん創意工夫をしないためにもやるといいんじゃないかな、と思ったという話でした

生成AIによって、演奏の仕事が置き換えられていく可能性は低いと思う。が……

生成AIと音楽について。

掲題のとおり、わたしは生成AIが「演奏」という仕事を置き換えていく可能性は低いと思っている。というか、「もうとっくに別のものによって置き換えられている」というほうが正確かもしれない。というのも、すでに我々はDTM、コンピューターによる演奏という手段をとっくに手にしていて、「そのひとならではの演奏！」だとか「人間の身体性に基づいた演奏じゃないと困る音」、つまり「（特定の、あるいは身体を持った）人間がやっているということ自体に価値があるもの」以外の演奏の仕事は、とっくの昔に機械に奪われている。あれだけ生演奏に拘っていた「NHKのど自慢」でさえ、生演奏からカラオケ演奏に切り替わっているのだ。「その人じゃなくてもいい演奏」なんてもうとっくに奪われていて、そこで生き残ってるひとたちは「その人が演奏すること」自体に価値があるので生成AIに置き換えられる心配は少ないと思う。

一方で、わたしが請け負っているような、「弾き語りオリジナルソング」と「こんなイメージで、という指示」をインプットにして、アレンジ済みトラックを出力するような仕事、あるいは「こういう用途で使います」「こういうイメージで」をインプットに、BGMを出力するような仕事は、「よほどのこだわりがある場合」を除いて、生成AIによって早晩奪われていくだろうと思っている。最近、web広告などのクリエイティブ（この「クリエイティブ」ってのも謎の用語ですよね）が生成AIによって作られている、という事例が徐々に生まれ始めているが、それと同じような形で、おそらくまずはBGMなどからその仕事が奪われていくだろう。そこまでいったら、「オリジナルソングのアレンジをする手段を持っていないけど、どういうふうにしたいというイメージはあるから、そのスキルを持っているアレンジャーに依頼している」という感じの仕事が奪われるまではあと一息だ。生き残るのは「そのひとのアレンジだからこそ価値がある」という一握りのトッププレイヤーだけになっていくのではないだろうか。

わたしの請け負っているような仕事がどんどん奪われていくことに対しては、自分勝手な思いとしては「ふざけんなよまじで」「令和のラッダイト運動まったなし！！！」みたいな気持ちがないと言えば嘘になる。まあそれは感情の話なので……。とはいえ、「頭の中ではいいものが鳴っているのに、それを実現する手段がない！」という人が、科学技術によってその手段を手にして、表現が民主化されていき、いままでだったら世に出ることがなかったかもしれない新しい表現が増えていくことはいいことなのではないか、という気もする。

まあ、どちらにせよ、自分が音楽を金に変える手段のうちのひとつは確実に奪われていくだろう。それは止められない。ならば、現状を認識した上で、身の振り方を考えるしかない。今までも「本業：自称ミュージシャン、副業：フルタイムの会社員」としてやってきたが、本業から「自称」が外れ、名実ともに本業となるのはいつのことになるだろうか。一生このまま副業で生きていくしかないのかもしれない。ふーんだ。

ボトルネック以外をいくら直しても無駄なのはソフトウェアだけではない

資本主義下における労働は資本主義下における労働であるので、利益を追求する必要がある。わたしは、ソフトウェアあるいはインターネットサービスで労働を行なっているので、これからソフトウェアあるいはインターネットサービスの労働の話をする。さて、ソフトウェアあるいはインターネットサービスで労働をする場合、「組織として利益を追求する」という動きにとってボトルネックになっている部分（部署というよりは、仕事におけるいわゆる「バリューストリーム」の構造だったりいち部分だったりを指す）以外をいくら改善したところで、利益には繋がらない。

わかりやすい話として、たとえばビジネスモデルがわやであれば、いくらエンジニアリングやデザインがシャキッとしていたところでそれは売り上げにはつながらない。まあ、エンジニアリングがシャキッとしているとコストの削減にはつながるのはそうだし、自分が直したコードやインフラ構成によってコストがウン千万減らせたとかあるのでエンジニアとしてはやりがいのある部分ではあるし重要な仕事ではある。とはいえコストカットには限界がある。利益の基本は売り上げでないと、スケールしていかない。同じ仕事をしていても、「売り上げが十分にある環境」でないと、その仕事で得られる利益はどうしても小さくなってしまう。これは「高速化やインフラ最適化できるスキル」に価値がないという意味ではなく、「売り上げが出てない組織」では、せっかくのそのスキルを持て余してしまう、という話でもある。

もちろん、エンジニアリングがシャキッとしていることは、売り上げを増やすことにもつながる。内部品質が高いソフトウェアは、新たな要望、要求に高速に応えることができるので、内部品質高く開発、改修ができるエンジニアチームは、その分だけリリースを加速することができる。これは売り上げのタネをそのぶんだけ高速に蒔くことができる、ということだ。しかし、どちらにせよ、ビジネスモデルがわやだったら、いくら高速にリリースしたところで、結局売り上げは上がっていかないことになる。これは痩せた畑にいくら高速にタネを蒔いたところで収穫量は頭打ち、みたいな話だ。これも、「エンジニアリングを持て余している」状態だと言える。

そしてこの話はエンジニアリングに限らない。たとえば、いくらデザイン（ここで言うデザインはいわゆる「体験のデザイン」も含む）がシャキッとしていても、そのデザインを実際に実現してリリースできるようなエンジニアリングやデリバリー体制がなければ、その場合結局「良いデザインを持て余している状態」だと言える。

だから、この例で言うとまずソフトウェアあるいはインターネットサービスを提供する組織においては、「ビジネスモデルがシャキッとしていること」はエンジニアリングが利益につながる前提条件だし、「そのビジネスモデルで達成すべき目標を達成するために必要な時期に必要なモノが出せるようにしてある状態」は「デザインの力でよりよい体験を実現する」ための前提条件となる。こんな感じで、「ある仕事が利益につながるための前提条件」が労働においては無数にある。この前提条件のうち、「満たされていない部分」がいまのボトルネックだ。

とはいえ、ここからが現実の難しいところで、とうぜん、これらが最初から完璧うまく回るなんでことはない。結局のところ「どこがボトルネックなんだっけ？」ということはやってみないとわからないことが多いし、「やってみる」ためには「まずビジネスモデルをシャキッとさせるのが前提なので、シャキッとしてから動きましょう」とか言っている場合ではない。常に、「やってみながら今のボトルネックを認識して、そのボトルネックに対して手当てを行う」ということをやらなければならない。これは正直いってかなり大変なことだ。（自分も含んだ）人間の感情も絡むしね。しかし、それをしない限り、せっかくの良いスキルを持て余してしまうし、そうなると離職者が続出する。これはもう経験的にそう（逆に言うと離職者が続出しているところは「そこがボトルネック」なのではなくて、「その先にボトルネックがある」と言う場合がある。離職者が続出する理由は必ずしもこの限りではないが）。

いろいろ書いたけれど、結局はソフトウェアの高速化と同じで、ボトルネックになっているところ以外にいくら投資してもそれは「持て余して無駄にしてしまう」わけで、実際にやってみてボトルネックを観察して、ボトルネックを正しく認識してそこを愚直に直していくしかないのだ。ただ、ソフトウェアだったら高速に試行錯誤をして高速にフィードバックを得て試行回数を稼げるが、これが組織となるとそうはいかないのが難しいところなのが大変なんだよね。最近でかいボトルネックをひとつ解消して、それにはすごくやりがいも達成感もあったし実際評価もされたので良かったんだけど、次のボトルネック（何度も言うけれど、それは別に特定の部署が、とかそういう話ではなくて、構造だったりいろいろなものが前提として存在していて、それがボトルネックとなる）の解消をする気力が湧かない。1ヶ月くらいスタン状態でも許してもらおうと思う。また頑張るので

しかし、何度でも思うが、本当は寝て過ごしたい。

そのあとtwitterに書いたこと：

ナレッジワーカーの集団にとってのアクセルは文化、ブレーキはルール。文化は行動が作る

よく、「仕事の属人性を排除して、仕組みやルールで標準化すべき」ということが言われる。これは決して間違えていないと思うけど、一方で片手落ちだと思う。たしかに、労働集約型の事業においては、「人数を増やせば増やすほど利益につながる仕組みやルール」を作ることが大事になるだろう。一方、知識集約型の事業においては、これは必ずしも真ではないと思う。

言ってみればあたりまえのことだけれど、ルールや仕組みは、増えれば増えるほど労働は平準化されていく。労働集約型の事業においては、「ローパフォーマーを減らすこと」のほうが、「ハイパフォーマーにさらに高いパフォーマンスを発揮してもらうこと」よりも重要だ。だって数がたくさん必要なんだもん。そのため、ハイパフォーマーにとっては「枷」になってしまうようなルールや仕組みであっても、その仕組みを課すことでローパフォーマーでも一定のアウトプットが出ることが重要となる。つまり、労働集約型の事業にとっては「ルールや仕組みを整備すること」が事業をより大きくするためのアクセルとなる。

一方、知識集約型の事業にとっては、ハイパフォーマーが、事業にとって本質的ではないルールや仕組みに邪魔されずに、事業にとって本質的な仕事に集中してできることのほうがむしろアクセルとなり、仕事を平準化するためのルールはブレーキとなる。たとえば、オーケストラについて考える。労働集約的な考え方で、楽器の素人を10,000人集めても、ブラームスの交響曲を演奏するオーケストラは編成できない。けれど、少数精鋭の各楽器の達人が、演奏への造詣が深くなればなるほど、そのオーケストラには価値が出ることになる。このとき、このオーケストラのメンバーに対して「この楽器を演奏したあとは、必ず以下の手順にそって楽器をメンテナンスをすること」というようなルールを課したところで、あまり意味がないどころか有害である。なぜなら、優秀な奏者であれば、楽器のコンディションを損なって結果として自分の演奏が損なわれるようなことはしないし、「どれくらい楽器に対してメンテナンスをしていれば最適な状態を保てるのか」を深く理解しているはずだからで、ルールで手順を定めるよりも個々人に最適なメンテナンスをしてもらったほうがいいからだ。

そんな感じで、知識集約型の事業にとっては、「ルール」「平準化」はブレーキとして働いてしまう。では知識集約型の事業にとって、アクセルとなるものはなにか。それはおそらく「文化」なのではないかと思う。そして、文化は行動が作る。もしも、「いい演奏がしたい」というのが口癖なのに、そのための練習の効率を上げるための工夫は全然しないし惰性で練習するような行動様式を持つオーケストラがあったら、そのような行動様式が、そのオーケストラの文化となるだろう。そして、他方に「いい演奏がしたい」なんて表立っては言わないけれど良い演奏のために練習の効率を上げるための工夫や行動をあたりまえのようにするような文化のオーケストラがあった場合、前者が提供できる演奏の質（つまり顧客にとっての価値）の向上のスピードは、後者よりもずっと遅いものになるだろう。これはルールや仕組みでどうにかできる問題ではない。

あるいは、自分たちのパートの演奏技術の向上だけにかまけて、合奏したときの音楽の良さ（それが顧客、つまり聴衆にとっての価値だ）にはコミットしないような行動が多いオーケストラは、それが文化となるだろう。他方に、自分たちのパートの演奏技術よりも合奏したときの音楽の良さにコミットするような文化を持ったオーケストラがいたとき、どちらのオーケストラの演奏が、より聴衆にとって価値があるだろうか。これもルールや仕組みでどうにかできる問題ではない。

そのようなことを考えると、やはり知識集約型の事業においては、「文化」こそがアクセルとして機能するように思う。そして、「ルール」や「仕組み」は多くの場合ブレーキとして機能しそうだ。

もちろん、ブレーキはとても大事だ。なんのために？　事故を起こさないために。つまり、「ここを外すと事故につながってしまう」ということを防ぐための仕組みとしては、知識集約型の事業にとっても、ルールや仕組みは価値がとても高い。

というようなことを考えると、知識集約型の事業でより高い成果を上げるためには、「プラス事象を積極的に作るためにはルールではなく文化を作る（そのための行動をガンガンやる）」「ルールや仕組みは、マイナス事象を避けるために使う」という考え方が一定有効なのではないか。

ということを考えましたよ。

これを昨日の記事と繋げて考えると、「文化がナレッジワーカーの集団にとってのアクセル。そして文化は行動が作る。労働において許容される行動は、成果が実際に出でる行動である。つまり、自分のやりたいような形で、成果を出す行動をすることで、自分にとって理想に近い文化をアクセルとして使えるようになっていく」ということになりそうだ。

言うんじゃなくてやる以外に方法がない

雑文

「顧客中心主義」という言葉を振りかざすひとは胡散臭く感じてしまうが、一方で重要な考え方であるとも思うアンビバレントがある

労働についての話。

労働をしていると、「どうしてうちの組織はこうなってないんだ」とイライラすることはだれにでもあると思う。というか、そういうイライラを失ってしまったとしたらそれはもう理想を失っているということで、改善の機会を失っている。理想と現実の間のままならなさにイライラしながらも顧客（その顧客は社内の別の部署かもしれないが、それが最終的にエンドユーザーに届くロジックは強固にたてついていないといけない）に対してなんらかの価値を提供して対価を得るのが労働だとさえ思う。

ところで、この理想を実現するためにはどうしたらいいのだろうか。理想を知ること、理想の状態を想像することは簡単だけど、このままならない現実を理想に近づけるためになにかを変えるというのはすごく大変だ。このギャップがひとを苦しめる。「こうあるべき」を言うだけなら誰にでもできることなので、それに価値はほとんどない。結局価値があるのは「一歩でも理想に近づく変化をもたらす行動」だけなんだけど、その変化をもたらす行動をできるかどうかは「どういう仕事をまかされるか」に依存するので、自分の意思だけではできず、そのための仕事を任されるしかない。そして仕事は「その仕事ができるであろうひと」に任される。だってそうしないと事業が止まるもん。と、ここで気づく。「任せられるひとに仕事を任せる」ってそれループしとるやんけ。

このループを断ち切って、「任される」に入るためには、結局のところ、「だれかがやるだろう」じゃなくて「自分の仕事じゃないけどそれをやることで事業のためになるから、やって結果を出す」という行動を続けるしかない。つまり、理想状態を作るためには、「今チームの目の前にある、事業上求められていること」に対して、いままで通りのやり方で結果を出すのではなくて、いままでを超えるやり方を探索しながら結果を出すしかない。いままで通りのやり方でやっても結果は出るかもしれないけれど、それはいままで通りなのだから変化にはならない。変化させるだけで事業上の結果を出さないのであれば、それは「無駄な変化」であり単なる迷惑行為である。だけど、やり方を変化させながら事業上の結果を出せば、「仕事の報酬は仕事」という感じでさらに仕事が任され、「変えることのできる範囲」が広くなっていく。

そう考えると、理想の状態を作っていくためには、「理想の状態を作るための仕事」をするのではなくて、「理想の状態に一歩だけ近づくようなやり方で、事業上の結果を出す」ということを繰り返していくしかないのだと思う。「理想の状態を作るための仕事」は「仕事のための仕事」で顧客のための仕事ではないから、どう頑張っても優先順位が下がっていく。労働だからしょうがないよね、労働は顧客に価値を提供しないといけないんだもん。「なんで理想の状態になってないんだよ」って愚痴を言うのはだれでもやる（ぼくもやってしまう）けれど、愚痴るだけではなくて、仕事を引き受けて、引き受けた以上のやり方をして実際に良い結果を出す。これは正直言ってかなり難しいことだと思う。ぼくも常にできているかって言ったらそんなことなくて多分三年に一回くらいしかそういうことができていない。けれど、結局言うんじゃなくてやる、以外に方法がないのだ、ということを理解したのでこれからもやるしかないのだと思う。しかししんどいわね。本当は寝て過ごしたい

「才」を「オ」と書いても問題ないが、「ツ」を「シ」と書いたら問題がある話は結構面白い問いだと思う

雑文

漢字テストが理不尽である、という話は定期的にインターネットを駆け巡る。最近も「才」を「オ」の形（これちゃんとわたしが意図したグリフで見えているかが環境依存なんだよな……）で書いたのが「間違い」扱いされた話が話題になっていた。

最初にわたしの立場を明らかにすると、わたしは「読める、なおかつ他の文字と混同されないような特徴があればそれは正答とすべきだろう」の立場であるけれど、この問題は一方で「算数の掛け算の順序問題」とはだいぶ違う種類の難しさを孕んだ問題であると思う。

というのは、掲題の通り、「才」を「オ」と書いても「同じ文字」とみなしても問題がないとされている（see 漢字のとめはねはらい等こまかな形状で正誤を決めてよい根拠はありませんファイナルアンサー2023リンク集 - なないち研 ) が、一方で、「ツ」と「シ」を同じ文字とみなしては（今のところ）問題が生じるという話があるからだ。あるいは「未」と「末」を分けるものはなにか、という話でもある。

これは、「シ」と「ツ」には、それぞれが排他的に理解されるという、ある種偶然で恣意的な線が引かれているが、一方「才」と「オ」にはそれが（今のところ）引かれていない、という話である。つまり、「シ」が「シ」として理解されるのは、それが「ツとは異なる特徴のある形をしているから」であって、「左上から右下に向かって比較的短い線が2本書かれていて、右上と左下を結ぶ、前述のふたつの"比較的短い線"より長い線が書かれている形をしているから」ではない（ためにしに「ツ」という文字が前述の特徴を満たすかどうか確かめてみらたいい）。

もちろん、当然、「才」と「オ」の件に関しては「カタカナと漢字で違うからだろ」という素朴な反論がありうる。けれど、じゃあもし「オ」という形の「才」と異なる漢字が仮に存在していたら、「オ」は「才」と了解されないだろう。これはそういう話だ。

ということを考えると、実は「漢字テストの採点基準」というのは、そもそも「形と漢字の対応関係」が恣意的である以上、本質的に恣意的な性質を帯びていると私は思っている（これは「今の厳しい基準が恣意的だ！　悪だ！」という話ではなく、その基準を緩めにするにしろ厳しめにするにしろ、どちらにせよそこには恣意性が入っている、という話だ）。だからこそ、現実的には「本質的に恣意的なので、"大枠の形が合っていて、別の字に読めるわけではないもの"は正答の側に倒すくらいのゆるい運用が望ましいだろう」という意見になるのだけれど、一方で、この問題は「そもそも文字とはなにか、われわれはどのような形で文字を文字として認識し、言語として扱っているのか」という話とか、記号と意味の結びつきの恣意性とか、言語ゲーム的な話とか、そういう言語そのものの謎あるいは性質にとって面白い問いになりうる問題なので、単に「国がこう言ってるからこうなんです〜」みたいな話で終わらせるともったいないと思う。

というか、そういう話があるからこそちゃんとした研究に基づいた文化庁の見解が「読めて他の文字と区別できればヨシ！（意訳）」となっており、一方現場では（無意識にでも）「そもそもそれが恣意的だから現場の運用で厳し目に倒すしかないんじゃい！」という「ハック」が必要となるんだよな、多分。

アマチュアバンドこそセルフレコーディングしようぜって話

2023年度を迎え、所属するバンドも新しい音源の制作としてレコーディングを開始しました。わたしの所属するバンドは、2度ほどいわゆる「エンジニア付きレコーディングスタジオ」でレコーディングをしたのですが、そのあとの音源制作は、基本的に私がエンジニアをしてDIYレコーディングを行っています。わたしがバンドでDIYレコーディングを始めたときは、まだ音楽のお仕事でお金をもらい始める前のできごとなので、まごうことなき「アマチュアによるDIYレコーディング」です（でした）。

さて、ところで、エンジニアさん付きのレコーディングプランの価格を調べてみたことがありますか？　調べるとみなさんびっくりされると思います。たとえばスタジオノアのレコーディングプランでは、スタジオ代に追加で ￥24,200- 支払えば、きちんとしたエンジニアさんが6時間もレコーディングを行ってくれます。高い？　いえいえ、サウンドエンジニアはれっきとした専門職であることを考えると、破格のお値段だと言えるし、5人バンドだったら一回飲み会を我慢すれば十分に支払える金額ではないでしょうか？

それなのに、なぜ、わざわざ、絶対にプロエンジニアよりいい音で録れるはずがないのに、アマチュアがDIYでセルフレコーディングなんかを始めたのか。それは、「いい音」と「好きな音」は違うからです。正直、ハウスエンジニアにおまかせすれば、「素早く、しかも良い音に」仕上がります（もとの演奏の音がよければね！）。なのですが、これが音楽の面白いところで、「良い悪い」と「好き嫌い」は独立した軸なんですよね。つまり、「一般的に良い音であると認識されるし、好きな音」「一般的に良い音だと認識されるけど好きじゃない音」「一般的には悪い音だと認識されるだろうけど好きな音」「一般的も悪い音だと認識されるし嫌いな音」がある。このとき、ハウスエンジニアさんに作業をおまかせして「一般的に良い音であると認識されるし、好きな音」を目指そうとすると、「好きな音」を言語化し、エンジニアさんにお伝えする必要があります。しかも限られた時間の中で！！　これは実は相当に難しいことです。

さて、これがDIYの場合は？　当然経験が浅いうちは「良い音」を作るのが難しいのですが、試行錯誤して研究していけば確実に「いい音」を作れるようになっていきます。そして、自分（たち）でやるなら、自分（たち）の時間が許す限り、時間に追われずに「好きな音」をじっくり追求することができます。正直言って、最初のDIYレコーディングや、まだお金をいただいていない頃に友人、知り合いから（勉強半分で）請け負ったレコーディングの音源は「好きな音」にも「いい音」にもできませんでした。けど、回数と反省を重ねるうちに、「プロよりいい音じゃないけど、自分が好きな音」は作れるようになっていきました。バンドの2作目のDIYレコーディングなんかはプロのエンジニアが限られた時間でやった仕事よりも、「いい音ではないけれど自分の好きな音」に仕上がっています。いま録音しているDIYレコーディングの作品は、「ハウスエンジニアが限られた時間でやった仕事」とおなじくらい（というか時間かけられるので、それ以上に）いい音になっている自信がありますし、好きな音を狙って作れています。（余談ですが、わたしがお金をいただく仕事で時間ごとじゃなくて作品ごとでお金を頂いてるのも、「限られた短い時間内に及第点出す」という技術がまだ未熟だから、というのがある。逆に言うと時間をかけることでちゃんとクオリティは担保しているし、今はさまざまな実績がちゃんとある）

さて、わたしは今、サウンドエンジニアとしてはお金を頂くようになりました（それだけで食っていけるには程遠いっていうか機材代等考えると赤字ですが……）が、「バンドマン」としてはアマチュアです。アマチュアってことは、「売れなくていい」ってことです（！）。クライアントからお金を頂いて、クライアントの満足ではなく自己満足のための仕事をするのはタコのやることですが、アマチュアのいいところは「自己満足でいいこと」なんですよね。そうなってくると、プロのミュージシャンだったら「悪いけど好きな音」と「良いけど嫌いな音」を比べたときに後者を取るべきだと言えるけど、アマチュアの場合、「いい音」よりも「好きな音」を優先して良いんです！

そうなってくると、これはもう「アマチュアこそ、セルフでDIYレコーディングをしよう」という話になってきませんかね。そういう動機で、わたしはDIYレコーディングを始めました。やってみたら、リスナーとしての耳も育ったり（楽器を弾けるようになると、いままでわからなかったような音楽が楽しく聴けるようになったりしません？　それと同じことが起こる）、「ここまでできるようになったらお金もらっても許されるのでは……？」からの音楽仕事でのリピーター様獲得、自分の手がけた作品がSpotify公式プレイリスト入りなど、さまざまな良いことが起こったりもしたので、なんにせよ「録音物作り」に興味があるアマチュアバンドマンにとっては、セルフレコーディング、おすすめです。

「一緒にレコーディングに入って、やり方教えてくれない？」みたいな話も全然請け負うので、もしよかったらご相談くださいね！（最後宣伝になってしまった）