ya8 2024に参加してきた #ya8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

生成AIと音楽について。

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

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

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

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

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

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

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

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

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

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

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

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

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

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