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")

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

2019年音楽活動振り返り

去年もやりましたが、12月となったので今年関わった音源を順に（記憶があいまいで、多少の前後があるかも）振り返りたいと思います。

夕暮れによせて

曲を作ったのは去年なんだけど、歌詞ができなくて放置していたやつ。歌詞がついたので歌った。この曲はコード進行とメロディがドラマチックなので、「ピアノ〜」「アコギ〜」みたいにやっちゃうと昼メロドラマみたいな腐臭が漂い始めるのだけれど、あえてのシンセベースとクールめなエレピにしたところが自分で気に入っている。リスナーとして信頼している友人が「ドラムの展開が面白い」と言ってくれたことが嬉しかったし、バンドメンバーのタダくんが非常に気に入ってくれたこともうれしかった。一度デュオでやったけれど、うーん、バンドでやるには不向きな曲かなとは思っていて、バンドでやることはなさそう。あと、この音源を聴くと当時はミックスにまだまだ興味を持てていないことがよくわかる。

Sounds Around (My Life)

現在ぼくが最も信頼するボーカルであるところのつるえさんに初めて書いた曲。この曲については一度このブログでも書いた。当時の全力をぶつけたつもりだけど、今になって冷静に聴いてみると、つるえさんの歌に楽曲が負けてしまっていると感じる。ミックスも今聴くと下手くそですね。自分の歌をミックスするぶんには下手くそでも大した問題はない（ある）んだけど、つるえさんの良いボーカルを活かすためにはミックスも重要だと気づいた。「もっときちんとミックスができるようにならないといけない」と感じてミックスを頑張り始めるきっかけになった曲かもしれない。

カレイドスコープ

Sounds Aroundがきっかけ、というわけでもないのだけれど、その後つるえさんと一緒に「錦玉もなか」という名前でユニットをやることになった。そのユニットはEテレソングなどを演奏したりしているのだけれど、オリジナルがほしかったので作った曲。つるさんの声はほんとうにすごくて、どのような楽曲を書くか、あるいはどのようなアレンジをするか、どのような歌詞かによって本当に様々に表情を変える。その様が万華鏡のようだな、と思ったので、万華鏡をモチーフにした曲を書いた。それと、つるえさんにThe SupremesとかThe RonnetesとかThe Emotionsみたいな「かわいい系」かつブラックミュージックな香りのあるシンガー（だれかに怒られそうな表現だなこれ……）みたいな曲を歌ってほしかった、というのが合わさってこのようになった。そんなわけでド頭はThe Supremes「Baby Love」からの引用。

「こうしたい」というイメージだけ先にできてて、メロディと歌詞がずっと出てこなかった時期が2ヶ月くらい続いたあとに、ふと通勤中「きらり　さらり　しゃらら　万華鏡まわす」のフレーズを思いついて、「勝った！」と思った。実際そこからは一瞬で出来上がったのが良い思い出として残っている。錦玉もなかはふたりユニットなので、この音源のような豪華なバージョンで演奏されることはおそらく今後もないであろう。今聴き直すと最後のドラムなんかは山下達郎「パレード」あたりからの影響を感じる。

ミックスは頑張ったけど頑張りすぎてだめになってるパターン。やりたかったのはフィル・スペクターとかナイアガラみたいなサウンドなんだけど……。こうしてひとは失敗しながら学んでいく。

ラウンドアバウト - EP

これは今年の活動の一番でかいトピックス！

バンドでスタジオ盤を作った。宅録音源とは異なりきちんとしたレコスタできちんとしたエンジニアさんにきちんとお金を支払って。クロスフェードデモを聴いてすこしでも良かったらぜひ！https://triothecmyk.bandcamp.com/album/epからご購入ください！　bandcampからじゃなくても、spotify, AppleMusic, Amazon Music, Google Play Musicなどでも配信中です。このレコーディングの経験はその後の宅録にもだいぶ生かされていて、「ははーんなるほど〜、そうやるのか！」みたいな学びがすごかった。

ツイストドーナツ

これはこのブログでもたまに登場するtmrrさん案件。tmrrさんが高校生の頃に御学友と一緒に書いた曲とのこと。ぼくはアレンジとギターの演奏とその他の楽器の打ち込みをやっている。歌っているのもそのtmrrさんの御学友です。アレンジに関して、「きゃるんきゃるんにしてほしい」というオーダーだったので、思いっきり90年代J-POPサウンドできゃるんきゃるんにしたった。これはボーカルはiPhone録音（ボイスメモ）で送ってもらったのだけれど、せっかく歌がうまいひとが歌っているのだから、もう少しよいアプリあるいは良い環境で録音してもらえばよかったという点を後悔している。録れ音がiPhoneボイスメモだとだいぶ限界がある……。アレンジは気に入っている。ミックスについてもすこしずつ勘所がわかってきて、「なにがわからないのかわからない」から「なにがわからないのかわかる」になってきた頃のように思う。

パーシモン

友人の島林深雪くん（以後みゆきくん）が曲を書いて、そこにtmrrさんが詞をつけたもの。本来はみゆきくんが歌っている曲なのだけれど、あまりに良い曲だったので錦玉もなかで勝手にアレンジして勝手につるさんに歌ってもらった。出来が良かったので、事後承諾で公開させてもらった。ミックスもだいぶうまくなってきて、音源の完成度としては多分今年一番の出来なのではないかと思っている（つるさんの歌のうまさにおんぶにだっこではある）。自分が書いた曲よりもこちらのほうがつるえさんの歌の良さが出ていて、かなり悔しい思いをした音源でもある。

ピクニック

ぼくがお世話になっているお店アルカフェの店主だんさんと友人のみゆきくんとが、つるえさん宛に合作された「ピクニック」という曲。つるえさんが出産を控えて里帰りされるということで、プレゼントとして制作されたとのこと。なのでボーカルもつるえさん。わたしはアレンジ（エレピ及びコーラスはだんさんの手によるアレンジ）とベースを担当。そのほかにも趣味レコーディング・エンジニアとして、みなさんの演奏のレコーディング（ボーカルがつるえさん、ギターと男声コーラスはみゆきくん、エレピと女声コーラスはだんさん）をして、ミックス、マスタリングをもぼくがやった。ミックスはトラックについてはだいぶよくなってきたが、ボーカルの処理がまだまだ甘い。というかつるえさんの歌すごい。Sounds Around、カレイドスコープ、パーシモン、ピクニックのすべてで、声がまったく違う表情を見せている。本当にすごいボーカリストだと思う。あと「好きな時間〜」という部分で「ん〜」をハイトーンで出させる作曲者は鬼だと思う。

台風のせい

またしてもtmrrさん案件。tmrrさん作詞作曲、歌。残りのパートのアレンジと演奏と打ち込みはぜんぶぼくがやっててすごい（自画自賛）。じつはいま聴くとエレピのアレンジちょっと直したいところがある……。 ミックスに関して、このあたりから「ステレオ感がどうしても足りない」「PANの問題ではなさそうだ」「ボーカルのミックスなにもわからん」ということに悩み始めている。この音源はtmrrさんがすごく喜んでくださったので、やってよかったと思う。自分のスキルがだれかに喜んでもらえるのって人間の根源的な喜びですよね……。

ノイジーペンギン

「最近ぜんぜん自分が歌う、しかもバンドでできそうな新曲作ってないな〜」という思いから作った曲。そういう半端な思いから作ったせいで、手癖で作ってしまった。そのせいかあんまりぴんとこなくて、結果自分の心の「イマイチ」フォルダに突っ込んである。けど好きって言ってくれるひとも結構いるのでそれは素直に嬉しいです。歌がちょっとうまくなってきたかもしれない。

図鑑を買いに

「ノイジーペンギン」の出来がいまいちだったことが心のどっかでひっかかってたんでしょう。すぐに次の曲を作った。「ノイジーペンギン」を「手癖」で作ってしまったことへの反省として、「いつもと全く違うアプローチで、違う曲想のものを作りたい」という気持ちで、かなり新鮮な心持ちで作った。Aメロ-Bメロ-サビ-Cメロ構成といい、アレンジといい、思いっきりJ-POPマナーをやりつつも、ちょっとヒネたポップス、というのがテーマ。アレンジもミックスも今の所だいぶ気に入っていて、良い出来になったと思う。おそらく音源の出来としては「パーシモン」につぐ出来なのではないかと思う。はやくこれが「この頃はレベルが低かった」といえるくらいにレベルアップしたい。

グラデーションスライダー

これもtmrrさん案件やんけ！！！！　tmrrさんが自分の誕生日に向けてみゆきくんと合作したもののアレンジをした。楽曲があまり自分にない語彙のものだったので、そういうものを編曲するのは非常に勉強になった。ただこれは結構ミックスがたいへんだった思い出がある。というのも、全員遠隔で作業をしていたのが原因で、tmrrさんのボーカルの音とみゆきくんのボーカルの音が録れ音の段階で全然違う状態の録音だったんですよね。そのあたりをどうカバーするかという工夫をして、そこもたいへん勉強になる案件だった。

総括

こうして見ると、今年は10曲に関わっておきながら、純粋に自分の曲、自分が歌う曲というのは3曲しかやってないことがわかる。だいぶ「ひとのサポートをする」というのがメインの年になったと思う。しかし自分にとっては今年はDTMを始めてから一番音楽的に充実していたと言える一年だったように思う。バンドのレコードも作れたしね！

自分がメインの表現よりも、「だれかの表現を形にするお手伝い」のほうがぼくは好きなのだということに改めて気付かされたし（バンドでもどちらかというとそういう役回りだしね！）、そういうサポートを通じて自分のできることのレベルがぐんぐん上がっていくことが実感できる年だった。来年はこれをすこしでいいから収入に結びつけていくことを大きな目標としている。twitterのbioも「編曲家でプログラマ。弾き語りミュージシャンの編曲やレコーディング格安で請け負います。まずはDMか shinpeim@gmail.com にご連絡ください。相談は無料で乗ります」に改定しました。まだごらんのレベルだけど、「本物のプロに頼む余裕はないしそこまでガチではない、けど自分の弾き語りをバンドサウンドにしたい」とか「弾き語りを自分で録るよりもいい音で撮りたい」というようなニーズにお応えしたいと思っていますので、まずはご相談ください。