奥田民生『たばこのみ』のコード進行が不思議

奥田民生の名曲のひとつに『たばこのみ』という曲がある。サイケな音像のギターがリズムを立てて、まるまるとした音質のベースが縦横無尽に駆け回り、たぶんメロトロンかな? 鍵盤がちょっとドリーミーな雰囲気を与えて、ドラムのフィルインはちょっとリンゴ・スターっぽい訛りかたをしている、中期ビートルズに多大なリスペクトを払ったであろう楽曲だ。

www.youtube.com

しかしこの曲、コード進行もなんだか変だ。ジョン・レノンもこういう変なコード進行をよくするけれど、それにしてもどう解釈すればいいんだろう?

楽曲はGで始まる。最初はなんてことはない、普通にキー:Gメジャーの楽曲として解釈してまったく問題ない感じで始まるのだけれど、歌い出しの「だれがなんと言おうとたばこを愛している」の最後の「る」でいきなりm3rdの音がでてきて、コードもGmになる。いきなりIm? という感じだ。つづいて「それはもうナイスな」でコードはCにいく。キー:Gメジャーとしてとらえたらこれはそんなに変ではない。そこから一瞬コードはCmに。これもGメジャーで捉えたらサブドミナントマイナーなのでおかしくない。が、次にF7 -> B♭と進むので、やはりこれをGメジャーとしてとらえるのはちょっと無理があるだろう。

ところで、この Cm -> F7 -> B♭ はよくみるとキー:B♭におけるIIm -> V -> I となっている。メロディもここで解決するような動きをしているので、キーB♭としてとらえてみるとどうだろうか? GはVIのメジャー、Cはドッペルドミナントであると解釈することができる。こっちのほうが自然だと思う。しかし当然VIメジャーはダイアトニックコードではなくて、「曲のド頭にノンダイアトニックコード、しかも3rdをメジャーにしたもの」を持ってくるのはかなり大胆な発想がないとできない気がする。

また、曲の最後は「G7 C7」の繰り返しになっていて、これをキー:B♭で解釈するのもかなり厳しいものがある気がする。

そう考えると、この曲はたぶん「キー:G」で始まって、そのあといきなり突拍子もなく「同主調であるGm、あるいはその平行調であるB♭に転調している」と捉えるのが自然なんじゃないだろうか。出てくるコードはだいたいキー:Gとして捉えるかキー:B♭として捉えると違和感なく解釈できるようになっているんだけど、そう捉えると今度は「同主調(とその平行調)をフラフラといったりきたりしている」という感じになって、この「落ち着きどころがよくわからない感じ」がこの曲の独特の雰囲気に一役かっている、という感じだろうか。この、同主調をふらふらといったりきたりしていると捉えられるようなコード進行はジョン・レノンもよくやる気がする。そのあたりもやはり中期ビートルズリスペクトなんだろうな。

正直かなり不思議なコード進行で、ほんとうにこういう解釈の仕方でいいのかな? という感じはしている。識者がなんかいい解説してくれないかな。

#phpconfuk 2024に登壇してきました

スライドは以下にアップロードしてあります。

過去や未来を扱うのは難しい? 過去と未来に立ち向かうための勘所

過去や未来を扱うとき、ソフトウェア開発やサービス運用はその難易度が上がります。サービス運用をしていく中で困らないように、あるいは、今後もコードの改修を伴うサービス改善を行うときに困らないようにするためには、過去や未来を扱う際にどんなことを考えてソフトウェアを作っていくべきか、というテーマです。

ベテランからすると、ともすると「当たり前」のように感じる内容の気もしますが、その「当たり前」は意外と言語化されてきていない気もしており、知見の継承という観点でも、われわれ(とは?)のようなおじさん世代が「当たり前をちゃんと言語化していく」ことには意味があるだろう、という気持ちで登壇させていただきました。

発表の中で紹介した様々な事例はフィクションですが、我ながらかなりリアリティがあるというか、長くシステム開発運用に関わってきた方ならばどれも「あるある」という感じの事例だったのではないかと思っています。なるべく地に足のついた、それでいて特定のケースのみに役立つHowではなく(「それはHowなんよ」を発表の中に入れ損ねた!!)、初めて見るケースや問題に対しても応用が効くような内容にしたいと思っていましたが、それが成功しているかどうかはみなさまからのフィードバックを待ちたいと思います(ブログ書いてね!)。

発表を聴く立場としては、PHPでデータベースを作ってみたという発表を最も楽しんで聴かせていただきました。「だってたのしそうだから」で自分の興味のままに物を作り、動かして楽しむ、という、ソフトウェア作りの楽しさの根源みたいなものを思い出させてくれる素敵な発表だったと思います。わたしもなんか作りたくなった。

クロージングでも触れられていましたが、「カンファレンスがあることは当たり前ではない」というのは本当にその通りだと思っています。自分のスタンスの話をすると、技術コミュニティとの関わり方に悩んでいる、というのは以前のブログ記事でも一度書きましたが、いまだにその悩みはクリアになったわけではありません。ただ、それがクリアになっていないとはいえ、「カンファレンススタッフに対しては感謝の思いがある」ということと、「自分はやはり登壇して知見のサイクルを回すお手伝いをするという形での貢献をしたい」ということには間違いがないな、と改めて思いました。またなんらかのカンファレンスにこのような形で関われればと思いますので、その際はぜひ宜しくお願いします。

音楽と生成技術 2024春

生成技術の発展が本当に日進月歩ですごい。音楽に関しても、もう「なになに風の音楽を作って」というものについてはあと一歩で実用レベルだな、と思わせるところまで来ている。以前もこのブログで以下のように書いた。

「こんなイメージで、という指示」をインプットにして、アレンジ済みトラックを出力するような仕事、あるいは「こういう用途で使います」「こういうイメージで」をインプットに、BGMを出力するような仕事は、「よほどのこだわりがある場合」を除いて、生成AIによって早晩奪われていくだろうと思っている。

生成AIによって、演奏の仕事が置き換えられていく可能性は低いと思う。が…… - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

なんならLogic11の新しい機能のSessionPlayerなんかはもう「アレンジ済みの演奏を出力する」「ベーシストとして楽曲制作のお手伝いをする」みたいな私の仕事を一部置き換えてしまったと言っていいのではないかと思う。

この流れは多分止まらなくて、思ったよりも早く「劇伴」とかBGMの仕事の総量は減っていきそうだ(全てが置き換えられる、ということもまた起こらないのだろうと思うが)。イラストの世界ではすでに、「文章を売っている」「音声を売っている」みたいなタイプの個人制作の作品におけるイメージ画像(イメージ画像、という言葉を使うときいつも、「イメージイメージ……」と思って違和感を得るんだけど他にいい言い換えをしらない)や挿絵などが、生成技術によって生み出されたもので置き換えられつつあるが、それと同じことが多分あと一年かそこらで音楽でも起こると思う。

さて、ぼくはある意味では生成技術によって「金銭を得る手段」をひとつ潰された立場にあるわけだけれど、一方でこれらの生成技術に対して現在あまり嫌悪感を持っていない。それどころか、ちょっとワクワクすらしている。たぶんそれは、ぼくが音楽以外に生業を持っているからというのはあって、自分はあくまで「作りたいから音楽を作っている」という立場だからなのだと思う。音楽の仕事が奪われた(あるいは奪われる)とはいえ、それで生活に困るかといえばそうではない立場、言い換えれば、簡単に「趣味のひと」に戻れるという立場だ。

「趣味のひと」の立場から言えば、「音楽を作るための技術を磨くこと」そのものが楽しいので、別に生成技術がいかに「努力なし」でクオリティの高い成果物を出そうがあまり自分の楽しみとは関係ない(そもそも生成技術を使えば努力なしで良い出力が得られる、というのもぼくは疑問視しているが、それはまた別の話)。というか、「結果」よりも「過程」を楽しんでいるから趣味なわけで(結果を出さなければいけないならばそれはもうお仕事ですよ)、「結果だけ欲しいならばすっ飛ばしてもいいような過程を、自分の楽しみのためにわざわざやる」という酔狂なことをしている限り、生成技術によって自分の楽しみが奪われることはない。これはDTMの打ち込みによって「演奏しなくていい機会」が増えたのに「わざわざ演奏したがる(しかも素人なので打ち込みよりもなんなら下手)」という酔狂なひとがいまだにたくさんいることと相似な気がするし、あるいは買った方が安いしうまいし手間もかからないのに、わざわざ自分でお菓子を作る人がたくさんいるのとも相似かもしれない。趣味なんだからそれでいいんだよな。

雑文なのでなにか強く主張したいことがあるというわけではなくて、「生成技術がおもったよりも早くまともな音楽を作っていっているなあ」という感想と「それに伴って自分のスキルが思ったよりも早く相対的に金になりにくくなるな〜」という感想と、「とは言え趣味人としてはノーダメージだなあ」という感想を書いておきたかったので書いた。そしてぼくは今日も、趣味人として自分のバンドのレコーディングに赴くのであった。

ya8 2024に参加してきた #ya8

uzullaさん主催の「みんなで作るテックカンファレンス」のya8に参加してきました。

わたしはアンカンファレンススペース担当として、二日間アンカンファレンススペースの切り盛りをさせていただきました。アンカンファレンスのキモは「一方通行ではなくて参加者みんなで議論する」だと思っているのですが、実際二日間においてほとんどずっと活発な議論が行われていて、参加して発言してくださったみなさんに大変感謝しています。しかも、「いつメン」の同窓会ではなく、いろんな方が発言してくださっていて、ほんとうにいいアンカンファレンスになったなと思っています。

議論の内容については余裕ができたら改めてまとめるかもしれません。

さて、実は私は、約5年ぶりくらいのカンファレンス参加でした。長い間カンファレンスに出席していなかったのには実は理由があります。詳しい理由は控えるのですが、ひとことで言うと、以前「自分とテックコミュニティの関係のあり方を見直すべきだ」と感じる出来事があり、その見直しにこれだけの時間がかかった、という感じです。見直しに時間がかかっているあいだ、テックコミュニティとの関わりを意識的に避けていましたが、少しずつ整理がついていった中で改めて思ったのは「テックコミュニティにうけてきた恩を自分はテックコミュニティに返し切れているのか?」ということでした。当然返しきれていないわけで、そうであるならば改めてコミュニティに対して恩送りをしないといけない、という当たり前のところに帰ってきて、その最初のきっかけに選んだのがya8にアンカンファレンススタッフとして関わる、という一歩でした。ya8で久々に会ったエンジニアの友人たちに「リハビリ中なんです」と言っていたのは冗談でもなんでもなく、本気でそういう状態だったんですね。

そんな中で、@KentarouTakedaさんに嬉しい声をかけていただきました。曰く、以前私がカンファレンスで行った発表が仕事で実際に役立ち、しかもそれをきっかけに別イベントに登壇もされたということでした。これは私にとってはとても嬉しい声かけでした。「自分の知見をコミュニティに還元することで、新しく知見のサイクルが回っていく」ということが起こったということを実感させてもらえたということでもあります。

自分は長い間テックコミュニティとの関係のあり方をいろいろと悩んでいたりしたのですが、これを聴いて改めて「コミュニティに対して自分の経験や知見を還元する」というすごくシンプルな関わり方を中心にしていればよい、そのシンプルさを見失わないようにいよう、と改めて思うことができました。

自分にとってはとても良い「リハビリ」「再出発」の機会となりました。主催してくださった uzulla さん、お疲れさまでした & ありがとうございました。これをきっかけにまたテックコミュニティに対して積極的に関わっていこうと思います。

解釈一致、解釈違いという言葉について

解釈一致、解釈違いという言葉をここ数年(つっても10年単位か?)よく耳にするようになった気がする。

たとえば、ひどくずぼらである、というイメージを持たれているひとが「冷蔵庫の中に卵があるのを忘れてて、賞味期限を一ヶ月切らしちゃったんだけど、まあ卵だし大丈夫だろって思って目玉焼きにして食べた」というエピソードを披露すると「その行動は解釈一致」と評されたりする。逆に、このずぼらなひとが「本棚の文庫本は出版社順、著者順、初版出版日順に並べてある」と言ったら「それは解釈違い」と評されたりする。

このとき、「解釈違い」という言葉は、あなたのことを誤解していた、というニュアンスではなく「あなたはあなたの人物像に似合わないことしている」というニュアンスで使われていることが多いと思う。そして、このような言葉の使われ方は、比較的新しい使われ方であるように思う。20年前だったら「キャラじゃない」あたりの言葉が使われていたかな?

ところで、今から書くこの段落はまるまる余談、脇道なんだけど、ぼくの認識としては、この使い方の「解釈違い」は、最初は二次創作などの文脈で「わたしの原作解釈とこの二次創作の作者の原作解釈は異なる」という意味で使われていた認識だ。それが転じて、自分の持っているイメージと異なる表象を持つさまざまなものに「解釈違い」という言葉が使われていくようになったのではないかと見ている(有識者によるツッコミを待ちたい)。結果としてある意味原作そのものである「本人」との間で「解釈違い」を起こしているのはなかなか面白い現象だ。

話を戻して、言葉は、その言葉をつかうひとの認識を形作る。虹の色の数はいくつか、という問いの答えが、使っている言語によって異なるのは、使う言語によって話者の認識が形作られる良い例だ。これは鶏が先か卵が先か、のような話でもあって、その逆方向、つまり、われわれがどう世界を認識しているかによって、言葉が作られていく、こともまた言える。犬と狼を区別しない世界観のもとでは、犬と狼が同じ単語で表される言語が生まれるというような話がこれに相当する。つまり、言葉の枠組みと認識の枠組みは不可分だ。

では「解釈違い」という言葉が、「だれかの人間性に対する解釈、つまりイメージを捉え損ねていた(違っていたのはイメージの方)」という意味ではなく「その言動はその人のイメージにそぐわない(違っているのは言動の方)」という意味の言葉として扱われてるようになった変化は、われわれの認識のどのような変化を反映しているのだろうか。あるいは、そのような言葉の使い方は、我々の認識をどのように変化させるだろうか。

誤解してほしくないが、ぼくはべつに「解釈違い」という言葉が「悪い使われ方」をしている、けしからん、という話をしていない。良い悪いを抜きにして、この言葉に注目することで、なにかぼくらの、「世界、とくに対人に関する認識の仕方」が以前と変化しているのではないか、という視点を持てそうじゃないですか? ということを言っているだけだ。

もちろんここから、「けしからん、先にあるべきはイメージではなくてありのままの人間性のほうだ、解釈などというイメージと実際が違うことに対して、実体の方が違う、というような用法はおかしい」という本質主義的な主張を導くこともできる。あるいは、「人間性そのものなんてものはアプリオリに存在するわけではなく、他者によって初めて見出され、物語られ、ある意味でっちあげられることによってフィクショナルに社会的に物語的に作り上げられるものだ。解釈違いという言葉が人間性に対して向けられるのは、それをよく表している」という社会構築主義的な主張を導くこともできる。

ぼくはどちらかというと後者の立場に近くて、「面白い変化が起こっているなあ」という感じでこの変化を眺めている。そもそも「キャラじゃない」という言葉がよく使われている時にはまだ「キャラ」というものがどこかに実体あるいは本質めいて措定されているが、「解釈不一致」だとあくまで無数の「解釈」が並行してあるだけ(本人の言動すら並列に置かれているところがおもしろい点だ)だし、より「解釈により人間性というものがある種フィクショナルに構築される」ということをよく捉えた言葉使いになっているとさえ言えるかもしれない。

そのようなアングルでもって眺めてみると、本質主義的な考え方の強い言葉が溢れているのと、社会構築主義的な考えが強い言葉が溢れているのでは、形成されるアイデンティティや、他者との葛藤のあり方にも違いが出てきそうだとも思う。そういう中での表現活動もまた、異なる在り方になっていく、あるいは今まさに変化の最中にあるかもしれない。

願わくば、「表現活動たるものこうあるべきだ」みたいな凝り固まった視点を持った自分ではなく、その時起きている表現活動をいったんそのまま受け取って柔軟に楽しむことができる自分でいたいものだと思う。

さて、このような文章を書くぼくは、ぼくを知る人たちにとって、解釈一致だろうか、それとも解釈違いだろうか。

組織やチームの慣性力に負けない心構え

組織やチームはそれぞれルールや文化、仕組みを持っている。この仕組みやルール、文化はときに外部から見ると「アンチパターン」に陥っているようなこともある。そのとき、「アンチパターンを抜け出してベストプラクティスを」と言うのは簡単だけど、実際にそこから抜け出すのは「言う」のと比べるととても大変なことだ。なぜなら、多くの仕組みやルールは複雑かつ有機的に絡まり合って現在の「仕事のフロー」を形成しているからだ。自分の職能の範囲だけで改善しようと思っても、仕事は自分の職能の範囲では完結せず、「他の職能のやり方がこうだからベストプラクティスは採用できない」となってしまいがちだ。こういう「変えるのが大変」という状況をぼくは「チームの慣性力が働きすぎている状態」と呼んでいる。

では、この慣性力に負けないためにはどうすればいいのだろうか。ぼくは心構えとしては以下のようなことを考えている。

  • 文化や仕組みを変えるのは大仕事なので時間がかかってあたりまえなので焦らない
  • 小さい身近なところからやろうとしつつ、小さいことをやりきろうとしない。むしろ小さいところから始めることで学習するくらいに思う。
    • 小さい身近なところから変えていこう、という話はよくされるし、実際小さいところから始めることは有益だと思う
    • 一方、「小さいところ」に見えても結局のところ他の「小さいところ」と有機的に結びついていて、その小さいところを変えるために依存関係すべてを変えなければならないということが普通に起こる。これはソフトウェアの変更と似ていますね。「たった一行」を変えるために他のあらゆる関係する箇所を変える必要が出てきたりするってやつ。
    • もし小さいところが簡単に変えられたら、万々歳ではある。万々歳ではあるが、逆に言うとあまり本質的なところではない
    • 「小さいところ」から変えてみようとしたときにどこがブロッカーになっているかを学習することで、今の自分たちの仕事のフローがどこがどことどうつながっているのかを「仕事の中で」見つけることができる。この「仕事の中で」ってのが大事で、大上段からの「業務フロー分析」はなかなか進めるのが難しいが、仕事の中に組み込まれることでチームの学習が進みやすくなる。
  • 見つけた「変化に対するブロッカー」は敵ではなくて、「同じことに困っている仲間」のはずなので、問題意識の共有からtobeの認識を共有するまでコミュニケーションして同じゴールに向かえるようにする。これに成功しても、次なるブロッカーが生まれるのが常なので、これを繰り返す。ここで大事なのが最初に書いた「焦らない」で、焦ると無力感に押しつぶされる。

とはいえ、常にこのように改善が進められていれば「心構え」などいらないわけで、逆に言えばこれらがいつもできているわけではない、むしろ気持ちとしては常に負けっぱなしである、とも言える。そんなわけで、これは「負けそうな状態を生き抜くため」に自分に言い聞かせている内容、というほうが近いかもしれない。というかふつうによく心折れてしばらくものごとを進められなくなってる(そして回復してからまた取り組みはじめる)。

クラスやメソッド、関数を分割するとき、その中の複雑さは減るが全体の複雑さは増える

タイトルで全てを言ってしまった。

クラスやメソッド、関数が大きくなってきたとき、これを分割したいと思うのは当然のことだと思う。分割統治することでひとつひとつのコンポーネントはシンプルになり、メンテしやすくなる(はず)だからだ。一方、クラスやメソッド、関数の数が増えれば増えるほど、全体としての複雑さは大きくなっていく。「なんかいろんなところに無秩序に飛んでいって読み解きにくいコードだな」と思ったことはないだろうか? わたしは(自分が過去に書いたもの含めて)そういうものを結構見てきた。

ここで「じゃあ全部ベタ書きすればいいね!」となるのはあまりに短絡的なので、もう少し考えてみる。

「なんかいろんなところに無秩序に飛んでいって読み解きにくいコードだな」となるのは、分割したことが単純な原因ではなく、分割の仕方が悪いと考えることができると思う。つまり、その分割によって凝集度が下がっているのではないだろうか。あるいは、「もともとひとつだったもの」を単純に分割するということは「結合度の高いふたつのコンポーネントを作る」ということでもある。分割によって全体性の複雑さが上がるデメリットがあったとしても、そのデメリットを上回りメリットを単体の複雑性を減らすことで得るためには、単純に分割するのではなく、凝集度が高くなり、結合度が低くなるような分割点を見つける必要がある。

では、むしろ凝集度を下げ、結合度をあげてしまうような分割の「コードの匂い」をどのように嗅ぎ取ればいいだろうか。ぼくがいまパッと思いついたのは「引数をいろんなところにひき回している」「インスタンス変数にいろんなところからアクセスしている」という2例がある。

引数をいろんなところに引き回すことによって引数を介した結合度は上がるし、その引数の関心がいろんなところに散らばっているので、これは当然結合度と凝集度が高くなる。結果として全体の複雑性を大きく引き上げることになる。分割したときに引数をひき回しているのを見つけたらなにかがおかしいと思うべきだ。

また、たとえばインスタンス変数を介してメソッドの結果をクラス内でやりとりしている場合、仮にprivate変数であっても、そのインスタンス変数という状態を介して、複数のメソッドが結合することになる。さらにいえば他のあらゆるメソッドがそのインスタンス変数にアクセス可能なわけで、あらゆるメソッドがこのインスタンス変数を介して潜在的に結合してしまっている。たとえばもともメソッド内ではローカル変数に閉じていたものを、分割に伴ってインスタンス変数を介してなにかをやるようになってしまったら「状態を気にしなければならないスコープ」は拡大し、メソッド単位の凝集度が下がり結合度が上がってしまう。publicなインスタンス変数を介したやりとりに至っては、さらにそれがクラス外への影響として出てくることとなる。分割した際にインスタンス変数が増えたらなにかがおかしいと思うべきだ。

なんだか2例とも「変数にアクセスできるスコープはなるべく小さくしよう」というあたりまえの話に収束してきた気がする……。

別の視点の話をする。じゃあどういうときに全体の複雑性が上がったとしても単体の複雑性を減らすべきだったと判断できるのか。これは結構難しい問いだと思うんだけど、上記のようなコードの匂いを感じさせない、きちんとそれぞれに閉じた分割ができたのであれば、それによって上がる全体の複雑さは「そもそもそのビジネスロジックの複雑さ」の表れなので受け入れるべき複雑さとなるのではないかな、というのが今の意見だ。逆にいうと、「そんなに複雑なビジネスロジックじゃないはず」のものがいろんなところにすっ飛んで実現されているのであればそれは「全体の複雑さを徒に上げているだけ」の分割であるとみなしても良いと思う。

凝集度を下げ、結合度をあげてしまうような分割の「コードの匂い」について、他の例もおそらくあげられると思う(のでみんな記事書いてほしい。読むし仕事で参照するから)が、いずれにせよ「単純に分割するだけ」ではむしろ全体の複雑さを増やす場合がある、ということをここでは共有したかったのでした。