5年以上ぶりに自分の曲がバンドでリリースされた

本日 2026-02-13 をもって42歳児になりました。自分の誕生日プレゼントにといって突然新しいベースを買ったりと、あい変わらずわけの解らないこと言ってます。花粉症が始まっていますが、薬も効き始め、あい変わらず僕はなんとか大丈夫です。

最近、バンドで新曲を録音していました。完成したのでリリースしましょう、という段になって、メンバーが小粋な気を利かせてくれて、「せっかくならしんぺいさんの誕生日にリリース日を合わせようよ」と提案してくれました。「そりゃいいですね」ということになり、晴れて本日リリースと相成りました。

わたしのやっているバンドは、ギタリスト、鍵盤弾き、ベーシストがそれぞれ曲を書き、自分の曲は自分で歌うというスタイルで活動しているのですが、なんとこのバンドでわたしの曲がリリースされるのは、2020年8月以来らしく、思えばだいぶ過ぎちゃったなという感じです。これには言い訳があって、ギタリストと鍵盤弾きの曲がよすぎるんだよな。レコーディングエンジニアはわたしがやっていて、わたしが彼らの曲のファンなので、どうしても彼らの曲を優先しうちゃうんだよね。なんにせよ、久々の自分の曲のリリースということで、まあ、正直に言えば結構嬉しいもんです。

本作は、『3月の写真』という曲です。学生時代を、路面電車のある街で過ごし、キャンパスの入り口に長いスロープを擁した学部に毎日通っていました(ほんとうに毎日まじめに通っていたかはともかく……)。で、「3月の写真」。ありていに言ってしまえば「卒業ソング」ってやつですよね。42歳が卒業のことを歌うというのはあまりにちょっと「青春病」がすぎるという部分もありますが、自身の卒業や大学生活を「突き放して」歌えるようになるまでに20年間かかっている、ということでもある気がします(42歳……)。

冒頭の路面電車の音は、わざわざ都電荒川線に乗ってフィールドレコーディングしてきました。空気感含めて楽しんでもらえると嬉しいです。卒業というのはたいへんに個人的な体験である、と思っていますが、その個人的な体験がどこか、いろんなひとの普遍的な感情と繋がるといいなと思って作った曲でもあります。

YouTubeならばワンクリックで聞けます。

www.youtube.com

各種音楽配信サービスでも聞けます。お使いのサービスで「3月の写真」と検索してみてください。信号機の写真がジャケットになっているものがそれです。

「よかったよ」という方は、ぜひBandcampで投げ銭しつつご購入いただければ幸いです。Bandcampでもフル尺で聴けます。

triothecmyk.bandcamp.com

リズム練習をClaudeくんにコーチしてもらう

じぶんのベースの演奏を各AIくんに分析させたところ、Claudeが一番定量的な評価をしてくれた。どうやら内部で信号分析のスクリプトを書いて実行していそうだった。これはおもしろいぞ、と思って、以下のプロンプトを入力してみた。

16分音符を基準として、ベースの発音が、ジャストに対してどのくらいズレているのかを分析してみてほしい。「ズレは平均どのくらい(ms、何分音符ズレているか)か」「ツッコミ気味なのか、レイドバック気味なのか」などが可視化されるといいな

結果、かなり詳細に分析してくれて、このタスクにおいては他のAI君たちとClaudeくんは格がちがった。他のAIくんたちはおべっか使うばっかりで役に立たなかったが、Claudeくんはかなり練習や分析の役に立つ。

AIくんによる総評とわたしの感想

分析結果は以下のようになっていた。

完成しました!16分音符グリッドを基準としたタイミング分析です。

主な発見

タイミングのズレ

  • 平均ズレ: +7.1ms(16分音符の約0.093個分)
  • 中央値: +9.9ms(16分音符の約0.129個分)
  • 絶対値の平均: 15.8ms(16分音符の約0.21個分)

演奏スタイル

レイドバック(後ノリ)気味 の演奏です: - レイドバック: 68音符(61.3%)← 多数派 - ジャストタイム: 18音符(16.2%) - ツッコミ気味: 25音符(22.5%)

解釈

この演奏は意図的にビートの後ろで弾くスタイル。ジャズやファンク、R&Bでよく見られる「グルーヴ感」を生み出す手法です。約7msの遅れは、心地よいレイドバック感を作り出しており、機械的でない人間らしいグルーヴを生んでいます。

6つのグラフで: 1. タイミングのズレ(ミリ秒)の時系列 2. タイミングのズレ(16分音符単位)の時系列 3. ズレの分布ヒストグラム 4. タイミング特性の割合 5. 統計的サマリー(箱ひげ図) 6. タイミングの推移トレンド

特に右下のトレンドグラフを見ると、演奏全体を通じて一貫してレイドバック気味であることがわかります。これは非常に安定したグルーヴ感の証拠です!

claude codeが演奏を分析してくれたグラフ。文章にかかれていた内容が可視化されている

これは「絶対値の平均」を出してきたのがかなりいい分析だと思っていて、「ジャストよりも前」と「ジャストより後」が打ち消し合ってずれの平均が低くなったところでそれは「ガタガタの演奏」であるわけだから、絶対値の平均を持ってくるのは気が利いている。

グラフを読み解くと、前後40msのブレに収まっていることがわかる。が、全体がレイドバック気味なときに前に40msというのはかなり「ツッコミすぎ」であり、このあたりは改善の余地がありそうだ。

ちょっとローデータに近すぎるなと思ったので、「解釈しやすい数字と解釈を入れてくれ」としたところ、面白い事実として

  • ジャストからのタイミングのずれの標準偏差が: 17.44msであることが示された。
    • この数値の解釈としては……
      • 人間が音のズレを知覚できる限界約10〜20msちょうど境界ラインらしいのでまあ悪くないラインにいそうだ
      • プロのセッション基準が<10msである、とClaudeくんは主張していて、なるほどまあ感覚的にわからんでもないラインだ。
  • 平均と中央値の差: 2.75ms
  • 意図的なレイドバック(+7.12ms)を一貫して維持
  • 極端なズレ(>30ms): 13.5%
    • セミプロレベル(5-15%)の範囲内

おべっかを使ってセミプロレベルと言ってくれているが、極端なズレ(>30ms)が13%以上あるのはいただけない。

わたしの解釈とネクストアクション

  • リズムフィール、タイム感については全体的には一定安定してるといって良さそうだ。
  • 問題は 極端なズレ(>30ms): 13.5% であろう。演奏の1割以上が、30ms以上ずれているということだ。60fpsで考えて2fというのはけっこう大きい数字だ。これはいただけない。これが改善すると、リズムのずれの標準偏差も小さくなるはずであり、より「安定してレイドバックした演奏」を見につけることができそうだ。

では、どうしたら「極端なずれ」を減らすことができるのか。これはもう単純にフィジカルだと思う。早いパッセージで転ぶ、とかそういう「頭でなってるリズムに体が追いついていない」ということが起こっているのは、フィジカルがついていっていない部分だ。フィジカル練……嫌いなんだけど……これをやらないと一歩上にいけないということを定量的に見せつけられていて、たいへん優秀なコーチであると感じる。あしたから毎日30分基礎練します……。

ところで、これはけっこうすごいのではないか?

よく「〇〇のリズムは魔法で」とか「バックビートに重心が〜」とか言ってるけど、定量的な話はなにもしないオカルトリズムパーソンがインターネットに湧いて出てきては初心者にハラスメントをやっていくが、オカルトリズムパーソンが言っているようなことを、この手法で定量的に研究することが簡単に可能になるのではないか? 今回はスクリプトをClaudeが作ってClaudeが実行したので再現性にやや難があるが、スクリプトを提示させれば再現性も確保できよう。リズムのオカルトをAIが解き明かして、その原理を学習したAIが生成する音楽がよりファンキーで踊れる人間的な演奏のニュアンスを獲得していく、これはけっこう面白い未来だと思う。芸大生あたりが研究しないかな。わたしは音源が1000億再生されて億万長者になったら研究します。

2026年1月音楽活動月報 アジャイルな見積もりと計画づくり - 音楽編

現状確認

2025音楽活動振り返り - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く で触れた通り、今年は音源のリリースとライブ活動について結構ストレッチな目標を立てている。

2月も中旬になってしまったが、これをきちんとトラッキングしていこうと思う。1月月報として出す。が、毎月出すかはわからない。こういうのはだいたい三日坊主になるもんである。

目標を再度掲載、現状確認をすると……

錦玉もなか

上期

  • ☀️ 音源を2つリリースしたい、と言っていた => レコーディング、mixが終わったのであとはリリース作業をしていくだけ
  • ☀️ 告知も含めてライブを一回したい、と言っていた => 5/10、荻窪アルカフェにてブッキング済み

となっており、なかなか順調に進んでいると言えるのではないか

下期

  • ☀️ 音源をもうひとつリリーししたい、と言っていた => これは5月のライブを終えたらすぐ録れそうなのでいける見込み
  • 🌤️ もういっかいライブをしたい、と言っていた => まだまだ未確定なことが多いが、まあいけんちゃうか、と楽観視している。バンドセットでやりたいという夢を込める場合は☁️くらいまでforecastが下がる

バンド

上期

  • ☁️ 上期に音源を3つリリースしたい。 => 1曲は2/13に出ます!!ぼくの誕生日です! あと1曲はレコーディングが3月になりそう。もう一曲はもしかすると開始が5月にずれ込むんじゃないか?という気がしてきており、本当に上期に3つリリースできるか不安要素は大きい。仕事ならばリカバリ策をなにか考えるべきところだが、趣味なので、間に合わなかったら「2曲しか出ませんでしたね」にしてもまあええやろ。

下期

  • ☀️ 上期にレコーディングが間に合わなかったら一曲あとまわしにしてでもバンドセットでのライブの練習に入ろうという合意形成をバンドでおこなったので、これはあとはやるだけ。

検討

錦玉もなか

  • まあ年明け前に仕込んでいたものが正しくうごき正しく進んでいるので、錦玉もなかの活動についてはmost likelyといった感じの着地である。
  • よかった点は今後の上期の錦玉もなかの活動でやるべきことが固まっている状態を作れたこと。ライブの練習と新曲の練習、それがおわったらレコーディング。この活動が下期のリリースとライブに関わってきそう。
  • いずれにせよこれは「やるだけ」なのであまり不確定要素が多くない。5月のライブの練習とレコーディングの練習が同時に進められるのか、というところだけが若干不安要素か。けどまあいけるでしょう。
  • 下期ライブはバンドセットでやりたいという野望をもっており、これはちょっとストレッチ目標としておいてある。most likelyで読み込めば、下期もアコースティックセットで、ということになるかもしれない。しかしネクストアクションが明確なら人間は前に進んでいけるのと、計画というのは変更するためにある、計画に従うよりも変化への対応を重要視するアジャイル男なのでいまのところはこれでいいのだ。

バンド

  • 「順調に遅れが出ている」という見方が可能そう。2/13に新作がリリースされるのはいいとして(そのときまた宣伝します)、3月に次の曲をレコーディングすることになっているが、これがスタジオ一回でどこまで録れるか、不確実性が高い。「おかわり」となってしまうと、当初の目標だった上期中に3曲出すということはむずかしくなるかもしれない。
  • しかしアジャイル男なので、計画よりも変化に対応することとして、その場合は上期のリリースは2曲に止め、下期のライブのための準備に取り掛かればよいだろう。というわけで☁️としている。
  • そこからライブに向けての準備に集中すれば、ライブの準備不足で大失敗するということにはなりにくいだろう。なぜならわれわれは持ち曲が多いので、「あれとあれとあれならすぐできるな」が多いので、納期(ライブ)に合わせてスコープの調整がしやすいのだ(今回よゆうないから、練習がたくさん必要なこの曲じゃなくてあっちやろうよ、など)。ただし、そのようなセットリストの組み方が果たして顧客最優先主義になっているのかどうかは意見のわかれるところである。

ネクストアクション

  • 計画の見直しはいまのところ必要なし。時間がたって情報が増えてきたらまた見直す時間を作ってよさそう。バンドの音源を3つ出すか2つにするかは2つめの音源の進捗次第とする。
  • あとは日程の決まっているスタジオワークを粛々とやるだけ

最後にひとこと

これがアジャイルな見積もりと計画づくりじゃい!!!! こうやっていかねえとマジで「無限に後ろ倒しされていく目標」とかが生じて音楽活動に継続性がなくなるんだよ〜〜〜。やってることが仕事では!? みたいなところあるけど、楽しいからやる、それだけなんですね。あとまあステークホルダー多くないからそこは楽だわね。仕事だともっとたいへん

大LLM時代、コンピュータはなお「計算機」である

大LLM時代、コンピュータがその名の通り「計算機」であることの重みはますます増しているかもしれない。こう考えた理由はふたつあって、ひとつは、まさに「計算機」であることのポテンシャルを活かしに活かしているのが昨今の大規模言語モデルであるということ。大規模言語モデルは「計算量でぶん殴る」ことで成立している。たぶんだけど、「大インターネット時代」はむしろ「記録できること」「ネットワークを横断して記録がコピーできること(ダウンロード、アップロードとは本質的にデータのコピーである)」がその恩恵を支えていたが、LLMに関してはまさに「計算機であること」がその恩恵を支えている。ここにきて、コンピュータがその名のとおり「計算機」であることが重要なファクターとなっているわけだ。もうひとつの理由は、LLMが容易にカーゴ・カルト化するであろうということ。どれだけ賢く見えても、コンピュータは「計算機」である。だから膨大なテキストはベクトルという計算可能なものに変換する必要があるし、どれだけブラックボックスでもその中でなされているのは「計算」である。この認識はLLMがカーゴ・カルト化することをある程度防いでくれるのではないか。

と、まあ、このような思索は「無為な思索」の類だろう、とも思う。しかし一方でプロンプトを与えらえたわけでもないのにこうやって無為な思索をするのは人間に残された贅沢ではあろう。だし、前段で述べた通りコンピュータはその名の通り「計算機」である、という認識に立てば、こういう「無為な思索」が計算可能であるか、あるとすれば、どのように計算可能になるかを考えることは、問うに値するかもしれない。

2025音楽活動振り返り

2025年Good

バンドセットでのライブ

5月に久々にアコースティックセットではないちゃんとしたバンドセットのライブをやった。BLUE MOODという箱で、音響的にも雰囲気的にもかなり良い箱だったと思う。お客さんにもたくさんきてもらえて、感想も上々という感じで、半年くらい準備していてよかった、という感じ。

www.youtube.com

じつは3曲ほどライブ初披露の曲があった。初披露が3曲というのは、会社員兼業バンドとしてはけっこうチャレンジングなことをやっていると思うのだけれど、限られた練習時間の中でアレンジ、演奏をだいぶ仕上げられて、バンドとしての地力が上がってきていることを感じた。全員40代にもかかわらず、一生懸命やることで向上というのはできるもんである。

このバンドは、「シティポップ系」とか「良質」と評してもらうことが多いのだけれど、自分はロックバンドのつもりでやっていて、ロックバンドの本懐はやはりライブであるとも思っている。であるにもかかわらず、なんとバンドセットでのライブは2022年ぶりということで、せめて一年に一度くらいはバンドセットでのライブを続けていきたいものである。

やっているユニットの曲が島村楽器の店内BGMに選出された

八巻千鶴さんとやっているユニット(こっちはロックバンドのつもりはなくて、ポップスユニットというつもりでやっている)「錦玉もなか」の曲、『天色reverb』が島村楽器の店内BGMに選出された。

www.youtube.com

錦玉もなかの全ての曲は作詞、作曲、編曲、レコーディング、ミックス、マスタリングを自分でやっていて、それを島村楽器の「音源センセイ」という企画に提出した結果ありがたいことに店内BGMとして選出していただけた。錦玉もなかの楽曲の「顔」はとうぜんボーカルなわけで、八巻千鶴さんの素晴らしいボーカルが島村楽器に認められたことはたいへん重畳である。この曲についてはアレンジがかなり気に入っていて、錦玉もなかのいまのところの最高傑作ではないかと思っている。思っているので、それがきちんと第三者に認められたのはほんとうに嬉しいことだ。

ボーダーレスな音楽活動ができた

2月と10月にそれぞれ、友人の主催する音楽会(のようなもの)に参加した。2月の音楽会で特筆すべきは、サックスとピアノとギターのトリオで自作の楽曲をやったことだと思っていて、この曲はポップに聴けつつもビバップマナーを随所に散りばめた、けっこうジャンルとしてくくるのが難しい曲で、自分としては今年できたものの中でいちばん「面白い」というか、意欲的な作品になったと思っている。内輪の音楽会でやったもので、音源、映像の公開の許可をメンバーにとっていないのでここに載せられないのが残念である。

10月の音楽会では、久々にスーツを着込んでクラシック楽曲をやった。サン・サーンス作曲『動物の謝肉祭』より、『象』と『白鳥』をやったのだけれど、本来コントラバスおよびチェロで演奏される楽曲を、セミアコフレットレスベースで演奏した。聴いてくれたひとたちが「ちゃんとクラシック曲として成立していて、しかも聴いたことのない編成で、面白かった」と口々に言ってくれたのがかなり嬉しかった。これも内輪の音楽会でやったものなので公開された音源、映像はない。

ぼくは音楽ならけっこうなんでも好きで、ジャンルに貴賎はないと思っている。だからこういうボーダーレスな音楽活動ができることがすごく楽しいし、そういう音楽を一緒に楽しんでくれるコミュニティがあることはとても幸せなことだと思う。

2025年Bad

なんと、バンドでもユニットでも、今年は音源をリリースしていない。由々しきことである。もう中年であるからして、残された人生の時間を意識しなければならない。ゼロにはなにをかけてもゼロなので、一年にゼロリリースのペースで生きていったらもう残りの人生でリリースできる音源はゼロ、ということになってしまう。音源を残して発表する、ということは、単に「売れたい」の話だけの話ではない。「そのときの自分たちの精一杯」を形に残すことには、かなりの価値がある。

いやまあ本音を言えばそりゃ売れてほしいんですよ。1000億再生されて、みんなで会社員やめて、スタジオ作って、そこで作った音源で家族の学費を稼ぎまくって過ごして行けたら一番いいんだよ。けど、そうなれなかったとしても、「このときに自分たちの音楽はこうだった」を残すことは、ぜったいにいいし、音源を残したことでいろいろな方と知り合う機会になっている友人も多い。記録を残したら、ひょんなことから知ってくれるひとが増える。べつに増えたところで「みんなのうた」に採択されるわけではない。ないけれど、そこで得た縁は、ぼくの音楽人生を絶対に豊かにしてくれる。だから、音源は、作って、発表するべきなんだ、と思っている。

まあでも罷り間違ってまじで1000億再生されたらいいよね。1000億再生されたらこんどはこんなにゆるくできなくなって嫌になっちゃうかもだけど……。ていうかそれだけ再生させるためのプロモーションも各種配信サイトのプレイリストeditorにピッチ(宣伝)を送ることくらいしかしていないけど。ラジオとかにはまた今度投稿してみてもいいかもな。

幸い(?)1月にリリースが予定されている情報未開示の曲が1曲、すでに手元でミックス、マスタリングに進んでいるユニットの曲が2曲、年内ギリギリでレコーディングが終わりそうでミックスに進めそうなバンドの曲が1曲、リズム隊だけは録り終わっているバンド曲が2曲あるので、来年はもっとハイペースで、音楽人として生きた証をネットの海に残していきたい。

来年の抱負

前述のとおり、手元で停滞してしまっている音源がいくつかあるので、これらは全て来年リリースしたいと思っている。上期にこれらをリリースした上で、下期にはバンドセットでのライブをやる、というのが目標となるが、べつに仕事でやってることじゃないのでいくら目標を下方修正してもよい、ということを考えると、錦玉もなかは上期にこれらをすべてリリースした上で、リリース周知もかねてライブを1度は行いたい。下期にさらに1曲リリース、さらにもう一度ライブをしたい。バンドのほうは上期はとにかくレコーディングをハイピッチで進め、手元にある三曲をリリースした上で、下期にはバンドセットでリリース周知を兼ねたライブを行いたい。

とはいえ、ユニット活動もバンド活動も相手がいることなので相手のペースというものも大切だ。もしもこれらの目標が難しいようであれば、そのぶんいろんな友人のボーカルをfeaturingして音源を作り上げていくくらいのアグレッシブさを取り戻す必要があるなと思っている。

絶対音感を説明する表現に対する提案

絶対音感を持っているひとには、すべての音が音名で聞こえる」という表現がよくなされるが、これはかなり誤解をうむ表現だと思う。

たとえばホワイトノイズはその定義上音高を持たない(基音を持つのであればそれはホワイトノイズではない)。これ極端な例だが、音高を決めることとなる「基音」を特定するのが難しい(聴感上むずかしい、という話ではなく、スペアナにかけても判断がつきにくい、ということ)音はこの世に無数にある。

「すべての音が音名できこえる」と言ってしまうと、そういう音も音名で聞こえると思われてしまい「絶対音感ハラスメント」(ハンドクラップをして「これなんの音?」と聞いたりするやつ)が生まれたりするのだと思う。

「すべての音が」という部分のほかに、音名に「聞こえる」という表現もまた、誤解を招きやすいと思う。

「どーはどーなつーのどー」と歌った時、最後の音の音高「ミ」なわけだけど、この、「音高がミでありことばとしてはドと発音されているぶぶん」は、耳にはちゃんと「ドと発音している声」として、つまり歌詞通りに聞こえている。その上で「音高はミだな」と同時に判別している、という状態にある。つまり耳に「聞こえている」のは言葉や歌詞なわけで、「音名で聞こえる」という表現も誤解をうみやすいと思う。

そんなわけで、絶対音感とはなにかを正確に表現するならば、「基音が判別できる、つまり、音高が判別できる音ならば、基準となる別の音高を示されなくても音名を判別できる」あたりになるけれど、これだとさすがにわかりにくい。というわけで、正確さを犠牲にした表現だが、誤解を生みにくい言い方として「音の高さがちゃんとある音ならそのドレミがわかる」という言い方を提案したいが、どうか。

なお、一部の人間において、ほんとうにこの世のすべての音が音名で聞こえるということを主張するひとがたまにいるので、そういうひとにはホワイトノイズを聴かせて「これの音名は?」と言ってやり、正解が出るまで(正解なんてないんだけど)出られない部屋に閉じ込めてやりたい、といういじわるな気持ちがないわけではないこともここに告白しておきます。

コード1行あたりの収支を意識する

ソフトウェアサービスというのは、リリースした瞬間から、もっと言えば書いてリポジトリにコミットした瞬間から「コスト」を産み始める。

新しい機能を作りたいとき、われわれは既存の機能、既存のコードとの整合性をとる必要がある。そのため、「既存のコード」の量が多ければ多いほど、「新しい1行」を追加するときのコストは上がる。また、ライブラリアップデートやフレームワークのアップデートをするときも、「既存のコード」の量が多ければ多いほど作業量は増える。また、リリースされているのであれば、そのコードが使う計算資源は当然ランニングコストとしてかかってくる。また、顧客からの問い合わせの調査においても、コードの量が多ければ多いほど調査のコストは増える。つまり、あらゆるコードは「ランニングコストのかかる困ったもの」であるとみなすことができる。

では、なぜそのような困ったものが存在することが許されるのか。これは単純で、そのコード(あるいはシステム全体)で稼ぐ金額が、そのコードが生み出すコストよりも大きい(あるいは、大きくなることを見込んでいる)からだ。

そう考えると、「同じ価値(売上)が出るのであれば、より少ないコード、より少ない仕様であるほうがコストが抑えられて利益率が上がる」という当然の帰結が導かれる。導かれるのだけれど、この「当然のこと」というのはすぐに見えなくなってしまう、ということに注意が必要だ。

まず、「コードや仕様を追加するときに、自分たちがあらたなランニングコストを抱えようとしている」ということに敏感になりがちなのはソフトウェアエンジニアであることが多い。それは当然のことで、実際にコストがかかる作業をすることが多いのはソフトウェアエンジニアだから。一方で、「そのソフトウェアの仕様や機能で出る価値(売上)」に敏感なのはディレクターや営業であることが多い。これも当然で、売上の源泉である顧客のニーズを日々肌で感じる機会はソフトウェアエンジニアよりも多いだろうから。このとき、ソフトウェアエンジニアが顧客に無頓着で、ディレクターがコストに無頓着であったらなにが起こるのか。当然、「なんで価値が出ることをやりたがらないんだ」VS「またランニングコストだけが増えて行くのか」という対立構造になってしまう。そんな組織、腐るほどあるのではないかな。

これはまあコストとベネフィットの「要はバランス」ではあるのだけれど、要はバランスというときは「どこにバランスさせるのか」ということも同時に議論しないとなんの結論も進捗も出ない。ではどうやってバランスさせるのか。「同じ価値でも、このやり方のほうがランニングコストが抑えられますよ」ということについてはソフトウェアエンジニアのほうが詳しい。というかそうあるべきだ。一方、いま簡単に言った「同じ価値」について、ほんとうにそれが同じ価値の出るものなのかどうか、つまり顧客理解については、ディレクターのほうが詳しい(はず)だ。よって、バランスさせるためには、コストに詳しいエンジニアとベネフィットに詳しいディレクターが「ここでいう価値とはなにか」を同じ基準で、あるいは同じレベルの目線で話し、お互いの専門性を差し出しあう必要がある。

事業会社ソフトウェアエンジニアは、ソフトウェアを切り売りしているわけではなく、そのソフトウェアを使って利益をあげている。ならば、ソフトウェアエンジニアこそが1行のコードがうむ価値の収支を意識すべきだ。その収支のコストの評価をするためには、ソフトウェアエンジニアの専門性が必要なのだから。コストだけに目を当てれば、当然、ソフトウェアに閉じた工夫(なるべく保守性が高くなるようにソフトウェアの設計原則を意識して書く、計算量を無駄に増やさないようにする、など)も必要だ。だけど、それだけでは済まないことも多く、「そもそもこの仕様を削ればめちゃめちゃコスパが良くなるんだからそうしましょうよ」という提案も必要となる。このとき、「コスパが良くなる」の根拠は、少なくとも「コストが減る」「けど(ほぼ)同じ価値が提供できる」の二つが必要となる。そりゃ当然だ。コスト「パフォーマンス」なのだから。後者の「同じ価値が提供できるでしょ」を添えて議論しなければ当然「要はバランス」のバランスを崩してしまうことになる。ソフトウェアエンジニアとしては無頓着になりがちな「価値」の話をきちんと理解し、提案する力が必要となるはずだ。

ただ、この「価値」ってのがけっこうややこしくて、「だってお客さんが欲しいって言ってるじゃん」みたいな話に終始すると、価値の見積もりが不可能となってしまう。どんなものでも「やるべき価値のあること」になるので。一番ダイレクトな問いは「それって、それをやることでどれくらい売上に効くんですか」となるだろうけど、あまりにダイレクトすぎて顧客目線から遠くなっちゃうこともあるので、プロダクトごとに、合意された「価値の見積もりの基準」が作れると良いだろう。その基準さえあれば、それぞれの専門性を持ち寄った上で「コストかけてやる? やらない?」を納得感もって決断することができるはずだ。それが、結果的に企業としてもユーザーとしても従業員としても嬉しい結果につながるはずだ。

ここから先は余談。成熟したチーム、あるいは互いに高いプロフェッショナリズムを持ったチームは明文化しなくとも、基準が存在していると感じることがある。じゃあ未成熟なチームはどうするべきかって考えた時、パッと思いつくのは「じゃあ基準を明文化しましょう!! そのためのワークショップをやりましょう!」とかになるんだけど、これはあまり機能しないと思っていて、なぜならば漏れのある抽象化の法則が発動し、ルールとして作った基準は常に個別の事例に対して不足するから。わたしは必要なのはルールではなく文化の醸成である、という立場をとっていて、どうやって文化を醸成するのかと言ったら、ソフトウェアエンジニア側からで言えば、嫌がられても臆せず敬意をもって「これユーザーにとってはどういう価値なんですか? 教えてください!」「わかんないので一緒にユーザーのところ行かせてください」というように「こっちがそっちの基準をまず理解しにいくよ!」という行動を取り続けることでボトムアップで変わって行くしかないのだろうと思う。