2020年音楽活動まとめ

年の瀬なので、毎年恒例の音楽活動まとめをしようと思う。

例年はその年に作ったり関わったりした音源をバーっと紹介していたんだけど、今年は数が多すぎるので印象に残っているものやことをまとめていきたいと思う。

ひとさまの楽曲の編曲、レコーディング、ミックスをやりはじめた

去年もちょいちょいやってたんだけど、今年は本格的にやりはじめた。きっかけは去年の夏にやったバンドのレコーディングで、そのときに

• 自分のミックスのやり方は大きく間違えているというわけではない
• 一方でプロの技術とは練度が違いすぎる

というふたつのことがわかった。これがきっかけで「もっと音源制作（楽曲制作ではなく、「音源」の制作）のレベルを上げたい」という気持ちに火がついた。

練度を上がるためにはとにかく試行回数を増やす必要があるが、自分の作った楽曲だけミックスしているだけでは、スループットが「自分で作れる楽曲の数」に律速されることになり、試行回数を稼げない。とくに自分は作詞が苦手なので、そこが一番のボトルネックになっていた。そのため、今年は以下のふたつを新しい活動として始めた。

• 自分がいろんなひとに曲を書いて、詞はひとにまかせちゃう。それをレコーディング、編曲、ミックスする。
  • この活動はtmrr recordsという音楽レーベルとして結実していて、配信ディストリビューターの公式プレイリストの常連入りを果たすことができた。ちょうど先日もtmrr recordsの「閑古鳥ガールズ」が公式メディアにも取り上げられたりと、一定のクオリティを内輪と違うところに認めてもらえているのはうれしい
• 弾き語りミュージシャンを主な対象に、編曲、レコーディング、ミックスを低価格で請ける
  • ありがたいことにリピーターも少しずつ増えている。価格に対して満足してもらえる程度の出来であるということだろう。嬉しい。なお購入した機材やプラギンなどのことを考えると、この活動は赤字です（が、足しになっているので実質勝利である）

バンド活動が充実

メインでやってる「TRIO the CMYK」というバンド（名前が覚えにくいしググラビリティが低い）で、1枚のEPと1枚のシングルをSpotifyなどで配信した。そのうちシングルの方はセルフレコーディングに挑戦したし、EPのほうはSpotifyの公式プレイリストに選出された。

セルフレコーディング

「2DK」という作品をセルフレコーディングした。

open.spotify.com

自分がベーシックトラックをDAWで作って、鍵盤とギターは各自宅録したファイルを送付してもらい、ドラムは最後にスタジオで生録。ミックス、マスタリングも自分が行った。これはめちゃめちゃ勉強になった。

• ドラムの録音はスタジオ依存がすごいので、ちゃんとそういうスタジオでやらないとミックス時に死ぬ
  • とくに部屋鳴りはどんだけマイキング工夫したところでスタジオの部屋鳴りがやばければどうしようもない
  • 一方でそういうやべえ録音状態を外科手術でなんとかするテクも覚えられたのでこれはこれでよかった
  • 次回セルフレコーディングするならドラムはちゃんと録れる環境を用意することにした。
• ボーカルに関しても音の入り口がまじで重要。録れ音がカサカサしてたらもうそっから先はディジタルではどうしようもない。これはアナログ機材にこだわる必要がある部分だと思った。
• 一方ギター、鍵盤、ベースに関してはDAW上の処理でも結構なところまで詰められる。80点までは行けそう。90点目指すならここもアナログ機材にこだわる必要はありそう。
• ドラムを最後に録ったのはスケジュールの都合だけど、ドラムは全ての要なのでやっぱり最初に録るべきだな〜〜〜〜〜と当たり前のことに気づいた

セルフレコーディングにもかかわらず、この作品もディストリビューターの公式プレイリストに載ったので、セルフレコーディングでも一定のクオリティは満たせている（出してもディストリビューター公式プレイリストに乗らないのもけっこうあるからね）というのは自信に繋がった。

EPのリリース

「太陽と暮らすシトラス」というEPを作った。

open.spotify.com

これはバンドにとって2枚目のスタジオ作EPとなる。前作での反省を活かして

• リハスタで練習しているときから、実際のレコーディングとおなじクリック（16分音符で「ココカコ」など）を鳴らして練習する
• アンプじゃなくてラインでしっかり音を作っておく

あたりに注力して準備をしていったおかげで、かなりスムーズにレコーディングも進めることができたし、実際に前作に比べてかなり意図通りの良い作品になったと思っている。その結果として表題曲の「太陽と暮らすシトラス」がSpotify公式プレイリストに選出され、5,000人以上、10,000回以上の再生、原宿の商業施設でBGMとして流れるなどのいい思いをさせてもらえた。今年一番のいい思い出である。

味をしめて、それ以降配信に出すものはバンドのものに限らず必ずSpotifyの公式プレイリスト入りを狙ったリリースをしているのだけれど、まあとにかく全然入らないですね。Spotify公式プレイリスト入りの壁は厚い。曲の問題もあるとは思うんだけど、やっぱりミックスとマスタリングに関して、自分でもわかるくらいに専業プロの仕事と自分の仕事に差があることもたしかなので、ここを埋めるべく努力したい。

なお、Spotify公式プレイリストに入ってたくさん再生していただけたところで売り上げはリハスタ代2回ぶん程度のものであった。Spotify上での再生数は公開されているので、専業プロの作品を見ては「この作品、Spotifyでの売り上げはn円くらいか……」ということを考えるようになってしまった。われわれTRIO the CMYKは全員、音楽以外の本業の仕事を持っているバンドなので、趣味としてやっていくぶんには十分にありがたい話というか、聴いていただけるというだけでうれしいだけど、専業プロはほんとうに大変だと思う。みんな、応援しているミュージシャンにはじゃぶじゃぶ金を落として、ミュージシャンがビジネスじゃなくて音楽に集中できる環境を守っていこうな。

ユニット活動も充実

音楽仲間のつるえさんといっしょにやっている「錦玉もなか」の活動も、結構充実していたと思う。tmrr recordsから、Spotifyなどに3枚のシングルを配信した。

open.spotify.com

open.spotify.com

open.spotify.com

「雨にブランケット」という楽曲は自分としてはかなり気に入っているのだけれど、このリリースをしたときにはまだまだミックスのレベルが低くて、「今だったらもっと」という気持ちになる。けどつるえさんの歌が本当に素晴らしくて、自分のやりたい音楽をこうやって一緒に、しかも自分にできないこと（歌のことです）をやってくれるひとがいるというのは本当にありがたいことだなあと思う。

来年の展望

来年は自分の編曲・ミックス・マスタリングでSpotify公式プレイリスト入りを目標としたい。あとは感染症の様子次第だけど、やっぱりバンドでライブがやりたいな。まあこれは人事を尽くして天命を待つしかない類の話なので言っても詮ないことではあるのですが。来年も音楽を楽しむ人生を続けたいと思う。

VPoTになった

この10月から、VPoTという肩書がついた。公式な経緯などは会社のブログのほうに書いたのでそちらを読んでいただきたいのだけれど、こちらは個人の日記なので個人の日記レベルのことを書く。

VPoTになるまでは、テックリードという肩書で、社内を見渡して「あ、ここちょっと自分が入っていった方が物事がうまく進みそうだな」というところに入っていっては手を動かすというようなムーブをしていたのだけれど、冒頭に貼った記事のような経緯で、今は手を動かすことよりも、仕組みづくり、組織構造に起因する問題に対する解決となる構造を作ることなどが主な仕事になった。

じつは、ぼくは今の会社に入るときに明確に「CTOやそれに準ずる仕事はしたくない」と伝えた上で採用してもらっている。なのになぜ心変わりをして、いままたCTO業の一部のようなことをやっているか、ということを今日は書きたい。

そもそも、ぼくがなぜCTOやそれに準ずる仕事はしたくないと考えていたかというと、いままで携わってきた仕事の中で、一度CTO的な業務に挫折しているからだ。過去の仕事の中で、「もうここで自分がCTO業としてなにをやっても、これ以上の改善はできない」となってしまったことがある。メンバーマネジメントはそもそも自分に向いてないしメンバーマネジメントと向き合うと自分の精神がボロボロになってしまうことを学んだ。ならば、と、プロダクトを健全に開発できる構造を作り上げることに専念しようとしてみた。自分の考える問題感に対する解決を生み出すような課題設定はできた。けど、多くのステークホルダーを抱えながらその課題を組織の課題として打ち出しきることができなかった。できることはなんでもやろうとしたし実際に自分ができることはちゃんと全力で取り組み尽くしたとは思っている。そういう意味では「やり切った」のだけれど、成果としては「挫折」と言っていいと思う。プロダクトを成功に導いたとは言えないし……。それはひとえに自分の能力不足であったと思うし、もうその能力不足な自分のせいで様々なひとが笑顔でいられなくなるのをみたくなかった。

それなのにどうしてVPoTのポジションを打診されたときに（「しんぺいがやりたくないって言っていた仕事なのはわかってるのだけど……」とぼくに切り出した副社長が、ものすごく申し訳なさそうな顔をしていたのはちょっと面白かった）もう一度挑戦してみようと思えたのか。それはひとえに「いま自分がすごく恵まれた環境にいる」ということに、周りを見渡して気づいたからだ。

ぼくが入社したあとも会社は拡大を続け、エンジニアの数もとても増えた。そしていま周りを見渡すと、ぼくの入社以前からいるメンバーにも、後から入ってきてくれたメンバーにも、それぞれの得意領域においてぼくなんかよりもよほど優秀なアウトプットをどんどん出してくれるひとがたくさんいる。全体最適を考えたときに自分のやるべきことを再度自分に問い直したら、「じゃあぼくは、このひとたちの素晴らしい力が変な組織的な問題によって正しく機能しないみたいな状態を防ぎ、このひとたちの力が最大限に発揮できるような状態を作ることに尽力したほうがいい」とごく自然に思えた。嘘ごめんちょっと見栄張った。「ぼくがVPoTなんかやってる間に、みんなはエンジニアとしてのスキルをどんどん研ぎ澄ませるのに、ぼくはそれでいいの？」って少し思った。まあ少し思ったのはそれはそうなんだけど、それが気にならないくらいにそのメンバーたちのことは好きだし尊敬してるから、最後にはきちんと納得できた。

そして、エンジニアメンバーだけじゃなくて、部署外や経営陣を見渡してみたときに、「このひとたちに一度も理不尽に否定されたことがない」と気づいた。意見が異なるときにも、見えてるものが異なるときにも、いつでもみんな「しんぺい（さん）が言うならそれはそうなんだろう」から始めてくれていることに気づいた。けどそれは「単に鵜呑みにしてぜんぶ受け入れる」ということではなくて「そうなんだろう」から始めた上で、ぼくに見えていない範囲のことを説明してくれて、その上で一緒に問題解決に動こうとしてくれるひとしか周りにいないことに気づいた。

そういうひとたちが「しんぺいにこの責務を担ってほしい」と言ってくれるのであれば、今度は前回よりも少しはうまくやれるかもしれない。少なくとも、孤独に挫折してくことはないはずだ。このひとたちはぼくを助けてくれるし、ぼくに助けを求めている。そう思えたら、自然と「ぼくがやります」と言えるようになった。嘘ごめんちょっと見栄張った。腹くくるまでかなり時間かかった。かなり時間かかったけど、最後にはしっかり腹くくれた。

あとはやっぱり前CTOのささたつさんの存在はぼくにとっては大きくて、ささたつさんがCTO業の片割れをやってくれるなら、互いに補い合ってやっていけるんじゃないかな、と思えた。じつはぼくがVPoTを引き受けたときにはまだVPoEをだれに頼むから決まってなかったんだけど、ぼくは「ささたつさん以外にいないでしょ」と思っていたし、実際ささたつさんを猛プッシュしすぎて「圧がすごい……」っていわれたりもしたんだけど（笑）、目論見（？）どおりささたつさんがVPoEを引き受けてくれたので、まあこれは結果オーライみたいなところはある。

それと、そーだいさん（id:Soudai）が手伝いに来てくれてることもかなり大きい。そーだいさんの声くらい大きい。そーだいさんはぼくが困ったとき、悩んでるときに組織マネジメントの先輩としてすごく真剣に相談に乗ってくれる。その安心感も、ぼくがVPoTを引き受ける後押しをしてくれた。

というわけで、VPoTを引き受けるときの葛藤について、個人の日記を書いた。完璧にやれる自信なんかないけど、その一方で「今必要とされてる役割」だと思うし、「そして今やるなら自分が適任だ」という自負もある。腹くくったので、「やり切った」となるまでは全力投球しようと思う。

コミュニケーションを成立させることはとてもむずかしい

コミュニケーションが成立するためには、双方の発信器官、受信器官（ここで言う器官というのは身体的な器官のことではなく、「メカニズム」くらいの意味だ）が健全に稼働していることが必要条件となることは言うまでもないことだとおもう。片方の受信器官が壊れていたら、とうぜんもう片方がいくら発信したところでその信号はだれにも届かないまま消えていく。これは逆もまたおなじことが言えて、片方の発信器官が壊れていたら、とうぜんもう片方がいくらがんばって受信したところでそれは理解不能なものになるし、そもそも発信されてないものを受信することはできない。いくら耳をすましていても。

いま、双方の発信器官受信器官が健全に稼働していることをコミュニケーション成立の「必要条件」と言ったけれど、ではこれらの条件はコミュニケーション成立の「十分条件」だろうか？　ということを考えてみたいと思う。換言すれば、「双方の発信器官も受信器官も健全に稼働しているが、コミュニケーションが成立しない、ということはありうるか」ということについて考えてみたい。少し考えると、「必要条件ではあるけれど十分条件ではない」ということに気づく。仮に日本語しか解さないひとと、英語しか解さないひとがコミュニケーションをしていることを考える。このとき、片方の日本語というルールを使った発信器官と受信器官は健全に稼働しているし、もう片方の英語というルールを使った発信器官と受信器官は健全に稼働している。だけど、当然日本語と英語ではそのままではコミュニケーションが成立しないことは想像にかたくない。

もうちょっと話を抽象化すると、これは「コミュニケーションが成立するためには、双方が同一の "プロトコル" を使った発信器官,受信器官が健全に稼働している必要がある」となる。「プロトコル」とはコンピュータ用語で「通信のお約束ごと」のことで、たとえば「まずは通信を始めたい側が決められた通りの信号を相手に送ります」「信号を受け取った側は決められたとおりの"受け取ったよ"という意味の信号を送ります」「"受け取ったよ"を受け取った側は、"受け取ったよを受け取ったよ"を発信します」みたいなもので、ソフトウェアエンジニアは、この「プロトコル」に沿った挙動をするソフトウェアを書くことで、自分とは別のところにあるソフトウェアと通信を行います（いまこの文章を読んでいるあなたの使っているソフトウェア（おそらくブラウザでしょう）は、はてなブログのサーバーと、事前に決められたプロトコルに沿って通信しているから、単なる01の羅列をこうして文字列として表示できているわけです）。

翻って、現実のわたしたちはどうでしょうか。同じ日本語を使っているはずなのに、なぜかコミュニケーションがうまくいかない。そういうことが日々おこっています。これは、「日本語」というレベルのプロトコルは同一であったとしても、「その意味解釈のしかた」というレベルでプロトコルが異なっている、と考えることができるのではないでしょうか。具体的な話をすると、ソフトウェアエンジニアの多くは、よく「うーん、できなくはないけどやりたくないですね」とか「うーんそれはかなりめんどくさいですね」という発信を行います。この発信に対して、同じソフトウェアエンジニア同士だと「なるほど、これをやることによって、ソフトウェアの保守性が犠牲になったりして、未来の変更が高コストになってしまうのだな、あるいは、高い負荷に耐えられないようなソフトウェアになってしまったりするのだな」と受信することが多い（当然、すべてのソフトウェアエンジニアがそうだとは言いませんが）のではないでしょうか。ただし、これは発信する側の意味解釈プロトコルと受信する側の意味解釈プロトコルが一致しているため、問題なく意思の疎通ができているだけです。このプロトコルを共有しないひとが受信したら「は？　仕事なのにやりたいやりたくないの話すんの？　めんどくさい！？」というふうに受信してもなにひとつおかしくはないでしょう。

かなり極端な例をあげましたが、こういうことは毎日そこらじゅうで起こっています。これは当然のことで、意味解釈のレベルでまったく同じプロトコルでコミュニケーションするなんて原理的に不可能なのです。なぜなら、わたしたちはそれぞれに異なった環境で育ってことなった体験をしてきて、その中でじぶんの認知を育ててきています。まったく同じ経験をするなんてことはできないので、多かれ少なかれ異なったプロトコルでコミュニケーションをしているわけです。当然、その違いには濃淡があり、似たようなプロトコルを使う同士ではコミュニケーション上の齟齬はおきにくいでしょうし、逆に全然似ていないプロトコルを使うもの同士ではコミュニケーションを成り立たせることにとても苦労することでしょう。

異なるプロトコル同士でコミュニケーションを成立させなくて良いのであれば楽なのですが、とうぜん人間ですのでそうは行かないことが多いでしょう。家族でも、職場でも、共通の問題に対して別々の立場の人間が協力して立ち向かわなければならないシチュエーションはたくさんあります。ではそのときに、どうやったら上手にコミュニケーションが成立するのか。とうぜん、最初に互いのプロトコルを知り、揃えていく必要があるわけです。しかし、ここでとても大きな問題にぶつかります。プロトコルを揃えるためには、とうぜんそのためのコミュニケーションが必要です。しかし、そのためのコミュニケーションを成立させるには、やはり共通のプロトコルが必要です。これはたいへんに困ったことで、コミュニケーション・プロトコルの問題を解くためには、コミュニケーション・プロトコルの問題を解決しなければならないという再帰的な構造になっているわけです。

これは困った。どうすればいいのか。

しかし、よく考えてみると、コミュニケーション・プロトコルというのは実は多層になっています。同じ日本語というプロトコルを利用していても、意味解釈のレベルでは異なるプロトコル、という例が良い例ですね。「コミュニケーション・プロトコルの問題を解くためには、コミュニケーション・プロトコルの問題を解決しなければならない」というのは、再帰的な構造ではありますが、無限再起、あるいはデッドロックではなく、何度も再帰していくうちに「同じ日本語」だとか、なんだとか、どこかで共通のプロトコルにぶつかることを期待することはできます（ぶつからないこともあるでしょう）（というか細かい話をすると、ほんとうはぶつかることはなくて、「同一ではないが妥協できるところ」が見つかるだけなのだけれど）。

まとめると、異なるプロトコルをしゃべるもの同士のコミュニケーションがうまくいかないときには、プロトコルを揃えるためのコミュニケーションが必要になるが、そのコミュニケーションにもまたプロトコルを揃える必要が出てきて、ここにはものすごいコストがかかるでしょう。というのが、プロトコルの異なるもの同士がコミュニケーションをするための大きな壁です。

そして、この壁を乗り越えるのを難しくしている要素のひとつとして、「相手とうまくコミュニケーションが成立しない」となったときには、相手の「発信器官」「受信器官」どちらかが壊れているように見える、という問題があると思います。同じプロトコル同士でしゃべるときには自分の発信器官も受信器官もうまく動いているように見えます（どっちかが壊れてたらコミュニケーションが成立しないからとうぜんですね）。さらに、「プロトコルが異なっているからうまくコミュニケーションが成立しない」なのか、「相手が壊れてるからうまく成立しない」なのかは、こちら側からは判断不可能です。両方のプロトコルを理解しているひとがはたからみたら判別可能ですが、両方のプロトコルを理解しているのであればそもそも困ってないわけですからね。そういう理由で、「相手とうまくコミュニケーションが成立しないのは相手の受信器官か発信器官が壊れているせいだ」と結論してしまうのはそう不自然なことではない、とぼくは思います。

そう不自然なことではないけれど、それでは問題は解決しないので、コミュニケーション上の問題が起こったけどそれを解決しないといけないときには、「相手が壊れていることを前提にせず、単にプロトコルが異なっているだけなのだと自分に強く言い聞かせながら、根気強く共通のプロトコルにぶつかるまでプロトコル調整のためのコミュニケーションを繰り返す」ということを双方が行わないとだめなわけですね。それってめちゃめちゃに難しいことだと思う。というわけで、コミュニケーションの成立って、そういうめちゃめちゃに難しいことなんだよ、という共通認識をまずは広く持ちたいなあ、という意図で書かれた文章なのでした。

Logic Pro X のver.10.5 にアップデートしたときにFlexPitchの挙動がおかしいのを直す

TL; DR

設定のリセットをして

設定のリセットをして

スケールクオンタイズをクロマチックにする

スケールクオンタイズをクロマチックにする

LogicのアップデートでFlexPitchの挙動がおかしくなった

Logic をアップデートしたところ、Flex Pitchを使っていると

• ノートを選択したりノートの外側をクリックするとタイムラインが吹っ飛んで「いまどこ編集してたの」がわからなくなってめっちゃストレス
• ノートを掴んで移動しようとすると半音単位じゃなくてなんかへんなところで全音で移動したりする。たまに半音で移動してわけわからん

みたいな挙動になってめっちゃストレスでした。twitter検索すると困ってるひとが多そう。これらを直す。

タイムライン吹っ飛び問題

これはtwitter検索してたら「設定のリセットでなおる」という噂があったので「まあそんなにたくさんカスタムしてないし、ためしてみるか」と思って設定をリセットしたら直った。

ノートが全音で動く問題

これはFlexPitchの「スケールクオンタイズ」が悪さをしていて、こいつをクロマチックに設定してやるともとの挙動になった。

困っているひとはためしてみてください。

錦玉もなかの1st single「雨にブランケット」をリリースしました

コロナでSTAY HOMEな日々、いかがお過ごしでしょうか。わたしはといえば、友人のつるえさんと一緒にやっている音楽ユニット「錦玉もなか」（きんぎょくもなか、と読みます）で、リモートでファイルのやりとりをしながら、1stシングル「雨とブランケット」をリリースしました。

各種サブスクリプションサービスでお聴きいただけるほか、AmzonやiTunesStoreなどでも単曲でお買い上げいただけますので、サブスクリプションサービスなどで聴いていただいた上で、気に入っていただけたらぜひ応援がわりにご購入いただけると幸いです。売り上げは次回作以降の配信費用となる予定です。

配信サービスの一覧はこちらとなります。

https://linkco.re/grdNx7Hm

もともとこの曲は配信に載せる予定でいたので、ほんとうならばもっといい環境、いいスタジオ、いいマイクでつるえさんの歌を録音したかったのですが、つるえさんの歌うこの歌を、この自粛の間に出すことにはちゃんと意味があるだろうと考えて、リモートでのファイルのやりとりで完成させてリリースすることとしました。聴いてくださった方から、「心が穏やかでない今の時分に、心を落ち着かせてくれる」という感想もいただけたのがとても嬉しかったです。

なんだかわたしも慌ただしい日々を過ごしていて、ブログで報告するのを忘れていましたが、錦玉もなか1stシングルのお知らせでした。

“雨にブランケット” music, words by 丸山しんぺい

誰かひそむような　影に怯えながら
雨の音を聴いて　震えていたいつかに
目を閉じて耳を澄まして聞こえる　かすかなことば

「おやすみ」「おやすみ」
ぼくのライナスの毛布はきみに預けたままでいいんだよ
眠れぬ夜に　月が静かに見ている

雨が止む頃には
空を青く映す小さな水たまりに
弾ける笑い声をあげながらはしゃいだ
幼いぼくらがまだ知らぬこと

「さよなら」「さよなら」
ぼくのライナスの毛布はきみに預けたままがいいんだよ
眠れぬ夜に　月が静かに見ている
月が静かに見ている

弾き語り バンドアレンジ やり方 方法 無料 合法

最近わたしは副業で弾き語りミュージシャン向けに「編曲とトラック作成、レコーディングを格安で請け負います」ということを始めている（おかげさまでご好評いただいており、ありがたい限りです）のですが、音楽仲間から「しんぺいさんどうやって編曲やってんの？」とか「手が早くない？」みたいに言ってもらえることがあり、なおかつわたしはノウハウはどんどんOpen & Shareしていくことを良しとするwebプログラマでもあるので、自分の編曲ノウハウをドキュメント化しました。自分で言うけど結構まとまった内容になっており、弾き語りミュージシャンが自分で編曲も始めてみたい、というときに最適な内容になっていると自負しております。

その名も SongArrangementWorkshop です。ご自身が弾き語りミュージシャンである方はもちろん、お友達が弾き語りミュージシャンである方にもぜひ紹介してくださると嬉しいです。

Rubyで標準エラー出力に対してwarning吐いてる犯人を探したい！

gemとかが標準エラー出力に対して「deprecatedなメソッド呼んでるよ〜」みたいなwarningを吐いてくれることがあると思うんですが、自分のプロダクトコード側でそのメソッドを呼んでいるわけではなくて依存してる別のgemの気がする、犯人は誰だ！みたいなときの話です。

だいたい./vendor/bundle以下を検索すればまあ犯人見つかるというのはあるんですが、メソッド名を動的に作ってるやつとかがいると引っかかってこなかったり、あとは同じ文字列がたまたま関係ないところで出現してるみたいなときもあるにはあり、「このwarningを出してるところのスタックトレースがほしいよお！」ってなることがある。そのようなときには、

class CustomStdErr < IO
  def write(*args)
    p caller
    STDERR.write(*args)
  end
end

$stderr = CustomStdErr.new(STDERR.fileno)

warn("heyhey")

このようにして標準エラー出力をジャックしてやるとスタックトレースが取れて便利だと思う。