黒鍵の「この音」、なんと呼ぶ問題

雑文

先日、絶対音感持ちだけど楽典には弱い（楽典に弱い、というのは本人談。ぼくがその人をみていてもそんなにめちゃめちゃ楽典弱いとも思わない。強いとも思わないけど）の友人が、調がB♭マイナーの楽曲のメロディーの中の、m3に当たる音を指して「ド♯」と言っていて、軽い違和感を持った。一般的にはB♭マイナーの楽曲を考えたら「シ♭-ド-レ♭-ミ♭-ファ-ソ♭-ラ♭-シ♭」というスケールを思い浮かべるので、B♭マイナーの楽曲の中で「レ♭あるいはド♯」で表される音が出てきたらそれは「レ♭」と呼ぶことが多いと思う。とはいえ、べつに「レ♭」でも「ド♯」でも、平均律の世界においてはその音高に1Hzの違いもなく、同じ音を指すので、違和感をもつくらいで、コミュニケーションに齟齬が起こることもないのでそれ自体に問題はないし、それが間違いだとは（ぼくは）思わない。

で、ちょっといろいろ考えていたんだけど、じゃあ自分がもし、とくに調などの文脈なしに、いきなりピアノの前に連れてこられて「ドの半音上、レの半音下に位置するこの黒鍵の音はなに？」と聞かれたら、たぶんその友人と同じく「ド♯」と答えると思う。調というコンテキストがない状態で考えたときに、そこに位置する黒鍵の音名は「レ♭み」よりも「ド♯み」のほうがずっとずっと強い。

じゃあ「♯」を基本に考えているのかというとぜんぜんそんなことはなくて、「レの半音上、ミの半音下の黒鍵」は「レ♯」だとちょっときもちわるくて「ミ♭」が収まりがいい。「ファの半音上でソの半音下」は「ソ♭」というよりは「ファ♯」だし、「ラの半音上でシの半音下」は「ラ♯」よりも「シ♭」が収まりがいい。おもしろいのは「ソの半音上でラの半音下」で、これは「ソ♯」でも「ラ♭」もどちらも同じくらいに収まりが良いと感じる。そしておそらくこれは楽譜を読んで音楽を演奏する多くのひとと共有できる感覚なのではないかと思っている。

これにはカラクリがあって、楽譜を読んで音楽を演奏する際、ぼくたちは臨時記号（おたまじゃくしの隣に付く♯や♭）によって半音変化させることよりも、調号（ト音記号とかヘ音記号のよこに書かれる♯や♭）によって半音変化させることのほうがずっと多い。それは考えてみれば当然のことで、もし調号で半音変化させるよりも多く臨時記号で半音変化させるような楽譜があるのであれば、それはそもそも別の調として捉えるべきメロディを間違えて捉えて書いた譜面だとみなせるはずだ。

ここで、「ファ♯とソ♭は同じ音ですが、調号においてはどっちの読み方が頻出ですか」ということを考えてみる。ちょっと考えればわかるんだけど、ファ♯が調性記号に初めて出てくるのは、キーCから♯がひとつ増えるキーGで、そのあとD, A, E, Bと順に♯が増えていっても常にファ♯は出現する。一方ソ♭がいつ調性記号に出現するかというと、キーCから♭がひとつ増えるF,そこから順にひとつずつ♭がふえるB♭、E♭、A♭ まで出現せず、D♭きて初めて出現することになる。

最初の「ドの半音上、レの半音下」の話に戻ると、ここでも同じことが言えて、調号として普通に楽譜を読んでいて「ド#」が出てくる頻度と「レ♭」が出てくる頻度だったら、「ド♯」が出てくる頻度ほうが圧倒的に高い。だから、楽譜を読んで音楽を演奏する多くのひとにとって、調のコンテキストなしで見た時「ドの半音上、レの半音下に位置するこの黒鍵の音」は「ド♯」みがつよい、ということになるのだと思う。

ここで面白いのは、冒頭の「絶対音感はあるが楽典には弱い」友人とぼくの違いだ。ぼくは絶対音感がなく、ちょっとだけある相対音感と楽典で音楽を理解しがちなので、「この曲はキーB♭m」という意識が強く出た上で、「キーB♭mにおけるm3の音だからレ♭（つまり調号で考えている）」と感じる一方、絶対音感がある一方普段そんなに楽典を意識していないひとは調の前に「ドの半音上、レの半音下の"この音"」の意識が強いから、調のコンテキスト抜きにパッと「ド♯」という音名が出てくるのではないか。

今日思いついたことは以上です。まじでなんの役にも立たない雑文だなこれ

追記：

スケジュールとスコープはトレードオフだが、ではユーザーストーリーは？

よく、プロジェクトマネジメントにおいて、「品質、コスト、スケジュール、スコープ」はそれぞれトレードオフにあり、すべてを固定することはできないと言われる。ここにt_wadaさんの「質とスピード」の話を合流させると、品質はスケジュールとトレードオフではなくてむしろスケジュールに対する説明変数である、と見ることができる。結果、これは「コスト、スケジュール、スコープ」のトリレンマと理解することができるし、アジャイルな開発においては「スコープを調整していく」ということがよく行われる。

ここでいう「スコープ調整」については以前書いた。

アジャイルなプロジェクトマネジメントにおける「スコープ調整」でやるべきこと、やるべきではないこと - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

それに対して以下のようなレスポンンスをいただいた。

いろいろなスコープ調整 - 半空洞男女関係

上記の「スコープとスケジュールはトレードオフ」という話とこれらの話をつなげて考えてみたい。

すると、スコープとスケジュールはトレードオフなのだが、ユーザーストーリーとスケジュールは実はトレードオフではない、と言えるかもしれない。スケジュールを固定したらスコープを動かさなければならない、あるいはその逆も真だが、ユーザーストーリーとスケジュールは両方固定できる。そういう考え方ができそうだ。「機能」は「できた」「できなかった」の二値なのだけれど、ユーザーストーリーは「めちゃめちゃ実現できた」「おおよそ実現できた」「少し実現できた」などのグラデーションがある、という見方はどうだろうか。このような見方をすると、スコープ調整は「当初狙った通りのユーザーストーリー達成の水準は狙えないので、水準は落とさざるを得ないが、どのようにしてなるべく水準を落とさずにリリースを迎えるか、そのためにどうタスクや機能を組み替えるか」を考えることだ、という発想に至れそうな気がする。

どうでしょうね？

重要かつ高コストな「合意」の扱い方

組織やチームにおいて、合意は非常に重要だと思う。そもそもなんらかの合意が存在しないチームや組織はそれはもはや組織やチームではなく、バラバラな個人の集まりとなる。

一方、合意はとても高コストだ。全ての行動に合意が必要となる場合は、動きはとても遅く、目的を達成するためのコストは跳ね上がる。なにをするにしても「根回し」と「合意」をとらなければならなくてとにかく仕事が進まない、というのはよく聞く嘆きではないだろうか。合意は重要だが、一方でハイコストなので、合意を取る必要のないものについては合意なしで済ませることも重要となる。

合意は非常に重要だが、ハイコストである。このジレンマに対しては、「合意を取るべきものはなにか」「何ならば合意を取らずに進めていいのか」の合意、いわば合意に関するメタ合意とでも呼ぶべき合意が重要になると考えることができると思う。メタ合意さえあれば、本当に合意を取るべき（と合意が取れている）ものについてはコストをかけて合意を取ることでチームや組織として動くことができるようになり、一方で合意を取らなくて良い（と合意が取れている）ものについては合意のコストをかけずにクイックに物事を進めることができる。逆にメタ合意がない場合、「空気を読む」「よろしくオシャレにやっていく」というスキルを関わる全員が（全員が！！！）持っている必要が出てくるし、それは現実的ではない。その結果として「どこまで決めていいのかわからない」ということがおこり、クイックに物事を進めることができなくなってしまう。

このメタ合意について、常に「正解」となるようなパターンはおそらく存在しない。というのは、組織のサイズやフェーズによって、適切なメタ合意の位置は異なるはずだからだ。

一方で、「メタ合意パターン」というのはいくつか導くことができそうだ。たとえばKPIツリーと、それに紐づく目標というのは「メタ合意パターン」のひとつとして解釈することができそうだ。組織としてひとつのKPIツリーを設定するということは、とりもなおさず、どのようなKPIを設定し、それらがどうつながっているべきかについて、組織内で取られた合意を形式化することにほかならない。また、それらのKPIに紐づいた目標を設定するということは、ある期間において達成すべき成果についての合意を取ることにほかならない。

たとえばKPIツリーを「メタ合意パターン」として使うことで、「どの指標が重要で、どの指標をどこまで上げるかについては合意を取りました。手段については合意はいりません、好きな手段で指標をあげてください」というメタ合意を取り付けることができる。逆にいうと、KPIツリーを作って指標に対しての目標を設定したにも関わらず、目標達成のための施策についていちいち合意が必要になる場合は、KPIツリーをメタ合意パターンとしてうまく使えていないと見ることも可能そうだ。

余談として、「どのような手段を使うかについて合意はいりませんよ」という場合にも、ガバナンスを効かせることは必要であろうが、ガバナンスを効かせることと全てに対して合意が必要になることはまた別のものだと思うので、ここではガバナンスについてはスコープ外としている。

重ねて言うが、常にどんな組織、チームにもKPIツリーが「メタ合意の正解のあり方」になるとは言っていない。メタ合意のパターンの一例として眺めてみたにすぎない。

こう書いてみると当たり前のことのように思えるが、意外と「メタ合意」がないせいで物事がうまく進まないという組織やチームは多いのではないだろうか。とくに「決められない」「どこまでやっていいのかわからない」「毎回合意を取っていて大変」みたいな感じで物事がうまく進まないときに、自分達はどのようなメタ合意のもとに仕事をしているのか、あるいはそもそもメタ合意が存在するのか？　ということを考えてみても良いのかもしれない。

謙虚であるために、謙虚であってもらうために

謙虚と卑屈の違いについて考えていたら、思い当たったことがある。それは、卑屈は目線が自分だけに向いていて、謙虚は目線が他人とのコラボレーションに向いているのではないか、ということだ。

例えば、自分の作った曲が100万再生されたミュージシャンがいたとして、そのミュージシャンが「100万再生すごいですね」と言われた時の反応を例にとってみる。

それに対して、「いや、私なんてすごくないですよ、歌のピッチだって揺れているし、歌詞だって恥ずかしいものだし」と応えるミュージシャンと、「とても嬉しいですが、自分の力なんて微々たるものです。応援してくれたファンの方々がたくさん感想を拡散してくれたことも大きいですし、形にしてくれたレコーディング・エンジニアの方の力も大きいですし」と応えるミュージシャンを考えてみると、前者は卑屈に、後者は謙虚に見えるのではないだろうか。これは、前者はとことん「自分のダメなところ」に目線が向いているのに対して、後者は「達成したことについて、自分がやったことや他人がやったこと」に対して目線が向いているからなのではないかと思う。

仮に、自分の成果にばかり目線が向いているのが卑屈、自他のコラボレーションに目線が向いているのが謙虚である、という考え方が多くの人に受け入れられるとすると、以下のようなことも言えるのではないかと思う。それは、自分が謙虚であるためには他人のやること、やったことに対して敬意と感謝を持つことが重要である、ということと、他人に謙虚を求めるのであれば、そのひとの達成したこと（あるいは達成しようとしていること）に対して、自分や第三者がどのような役割を演じているかを添えて伝えることが重要である、ということだ。

自分が謙虚であるためには他人のやること、やったことに敬意と感謝を持つことが重要と言うのは説明の必要もないように思うけれど、他人に謙虚を求める場合に自分や第三者の役割を伝えるべきというのには少し飛躍があるかもしれないので補足をする。

他人に謙虚を求めるということは、逆に言うと当人の態度が今は謙虚でないように見えている、という前提がある（当たり前だ……）。それはとりも直さず、達成した（あるいは達成しようとしている）成果に関して、他人の貢献が見えていないあるいは認めていないように見えている、ということだ。謙虚でいてもらうためには、他人の貢献を認めてもらう必要がある。しかし、そもそも当人とっては自分一人の認知では他人の貢献が見えていなかったりそれを貢献だと認めていないからこそ、そのような態度になっているのだから、きちんと「こういう貢献があるよね？」と伝えてあげて、他人の貢献を認知してもらう必要があるだろう、という理路で、「謙虚を相手に求める場合には自分や第三者の貢献を同時に伝えた方が良い」ということが言えそう、という話。さらに言えば同時に「あなたの貢献としてこれこれこういう素晴らしいものがある」ということも伝えればより良いだろう。

そうじゃないと「自分の能力を低く評価しろってことか？」「自分の能力をお前は低く評価してんのか？」と受け取られかねないと思うし、そのようなすれ違いはあまりいい結果を産まないと思う。

「リズムの重心」という言葉について考えるのをやめた

最近のベースの練習で向き合っているリズムのオカルトを解き明かしたい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

この記事の続き。

この記事では暫定的に「重心って要するにアクセントね」と結論づけたが、どうもそのあとそう思って練習していてもまったくしっくりこない。

実際「アメリカのリズムは、リズムの重心がバックビートにある」みたいなことを言っているひとが「アクセントってことではない」と言っているのも見聞きして、「まあそうだよな」となった。

それではリズムの重心とは一体なんなのか。そう思っていろいろと調べていたら、あることに気づいた。リズムの重心について話している人の中で、「リズムの重心」の定義について、音量、タイミング、音質、音程などの要素を用いて「この要素のこれのこと」という形で説明している人が見当たらないのだ。その一方、「アクセントのことではない」をはじめ、「なになにではない」「こうではない」「ああではない」という説明は無数に行われている。それどころか、「音量、タイミング、音質、音高などで言うなんのことなんですか？」という質問に対して、「あなたは重心の違いを感じなかったのですか？」という逆質問をしている始末であった。

これは、教育ではなくてハラスメントの文法である。

もちろん、話者が悪意を持ってマウンティングしてやろうと思っているのだろう、とは私は思わない。本人が会得した、「心地よく感じるリズムを生み出す方法」を伝えたいという熱意は本物であるはずだし、話を聞いている自分も「なんか自分のリズムに違和感あるんだよなあ、クエストラブのようにいかねえんだよなあ」と実際に感じていて、そこにはなにかしらの「秘密」が隠されているということは体感している。

そうやって最善の相で「リズムの重心」という言葉について捉えると、「要素還元的なアプローチでそれを伝えようとすると、どうやってもハラスメントの文法でしか伝えることができない」という種類の概念なのではないか、ということが見えてくる。

わたしもバカではないので、世の中には要素還元的なアプローチでは理解が難しいものごとが存在するということは理解している。「複雑系」というのがまさにそれだという認識だ。そして、リズムという非常に音楽にとって根源的なもの、というか、リズムから人間が受け取る印象が、要素還元的には理解できないというのは、少なくとも自分としては納得できる。

つまり、「リズムの重心」という概念は、「音量、タイミング、音質、音高」などの要素還元的なアプローチでは理解、体得できず、全体を全体としてとらえることでしか理解、体得できないものなのだろう。そうである以上、「リズムの重心とはなにか」を分析することにはなんの意味もなく、理想としているリズムの音源を先生にして、自分で試行錯誤しながら練習することでしか理解、体得できないのであろう。

そう考えると、「リズムの重心とはなにかについて解説する」という行為や、「リズムの重心とはなにかを要素還元的に理解しようとすること」自体が意味のない行為であることも理解できる（一方、「リズムの重心」という感覚を、マンツーマンなどのレッスンで身につけることの有用性もまた同時に理解できる。だから、リズムの重心ということを言う人が「わたしがレッスンをすると生徒の演奏がガラリ変わる」と言うのも本当なのだろう）。「こういう練習をすることでリズムの重心という概念を体得することができることが広く知られています」などのアプローチには意味がありそうだ。

ということでわたしはもう「リズムの重心」という言葉について理解しようとすることをやめた。そのかわり、練習や試行錯誤を繰り返すことで、理想としているリズムに自分のリズムを近づけていくしかないのだと思う。

最後にひとつだけ恨み言を言うと、「説明」から身に付くものではないものについて「リズムの重心について説明します」という面をして無理に要素還元的なアプローチで説明しようとして、結局要素還元的には説明できず、要素還元的に学ぼうとしている人間を混乱の底に叩き込んでいるのは害悪であるとわたしは思う。だったらいっそ「これは音量とかタイミングとか音質とか音高とかそういう話で説明ができず、”バンドのリズム全体”で捉えるしかないものなので、理想のリズムを聴きまくって練習しまくって"理解"じゃなくて"体得"するしかないんですよ」ときちんと言えばいいのに。それができなくてコミュニケーションがハラスメントの文法になっちゃうの、「無能で十分説明できることに悪意を見出すな」というハンロンの剃刀にしたがって、そこに悪意を見出しはしないけど、「教えるひと」としては十分に無能だよな。一流のミュージシャンが一流の教師である必要もないのでしょうがないが。

すでにわかっているひとにはわかるけど、まだわかってないひとにはわからん文章

今日は掲題のような文章について。

世の中には「すでにわかっているひとにはよくわかるしとてもわかりやすいんだけど、わかってないひとにとってはなんのこっちゃかわからん」みたいなタイプの文章が存在すると思う。

たとえばソフトウェア開発の文脈で言うと、基本情報技術者試験の勉強の際に読むようなやつを想像してみてほしい。ぼくは基本情報技術者試験って結構役に立つよなあって思っている側の人間で、ある程度ソフトウェア開発の経験を積んだひとからもけっこう「内容はいいよね」っていう言葉は聞くと思う。で、この「内容はいいよね」ってところが結構ポイントだと思っていて、実際にソフトウェア開発の経験をある程度積んで、暗黙知や経験知がある程度溜まった状態、つまり「わかっている」状態であれらを読むと「わかるわかる」となるが、一方でそういう暗黙知や経験知がない状態で基本情報技術者試験に合格しても結構「とりあえず暗記したけどこれ結局どういうことなんだろう？」となりがりなのではないか（そういう体験談はちょいちょい耳にする）。

で、ぼくはこの「わかっているひとにはわかるけど、まだわかってないひとにはわからん文章」のことを悪いと言いたいわけではなくて、こういう文章の存在価値ってのはふたつくらいあるとおもっている。ひとつは、暗黙知や経験知を明確に言語にすることによって、既存の知の体系に組み込む、まさに「体系化」することが可能という価値がまずあると思う。なので「すでにわかっているひとにはわかるけど、まだわかってないひとにはわからん文章」は「すでにわかっているひと」にとっても結構重要なのだ。

じゃあ「まだわかってないひと」にとってはどうなのかっていうと、これは「なんとなく聞いたことがあるなこれ」っていうインデックスを脳に作っておく価値があると思う。まだ知恵になっていない知識を、先にをインプットしておくことによって、暗黙知や経験知を得たときに「あっ！！！　これって！！　あれのことじゃん！！！」と繋がることがあり、そういう場合は知識が先にインプットされていない場合に比べても強い経験知を得ることができると思う。ので、「すでにわかっているひとにはわかるけど、まだわかってないひとにはわからん文章」は、まだわかってないひとにとっても結構重要だと思う。

隙あらばじぶん語りをすると、ぼくはこの「知識を先にインプットしておく」というのが苦手という自覚があるけど、まあそれはまた別の話。

で、この話がどこにむかうかというと、最近「すでにわかっているひとにはわかるけど、まだわかってないひとにはわからん文章」としてめちゃめちゃいいなこれって思った文章があるので宣伝します。それは「システム及びソフトウェア品質の見える化、確保及び向上のためのガイド」です。

これは「システム開発、まじでむずい」「結局のところ、ユーザー理解含めた開発プロセスの品質を上げていくことでしか顧客価値って創造できないのでは……？」みたいなことを肌で理解しているひとにとってはおそらく「すでにわかっているひとにはわかる」やつで、なおかつ、その肌感覚をこれで言語化して「既存の知の体系」の中に組み込むことによって「説得したいひとを説得しやすい言語」を獲得できる文章であると思います。

<追記>

</追記>

継続してプロダクトの品質を保つためにはプロダクトに向き合うだけでは足りないという話

ソフトウェアの内部品質への投資を怠ったが故に、その内部品質がビジネスの足枷になってしまった、という失敗はよく聞かれる例だと思う。

そういう場合、「なのでソフトウェアの内部品質を直しましょう！」と言う発想になりがちだし、当然そのための投資を始めることは必要なのだけれど、それ以上に注目しなければならない問題がある、と最近は思うようになった。

「内部品質が落ちたので内部品質を直しましょう」というのは、単なる対症療法である上に「いつんなったら直って内部品質への投資やめられるの」という誤った問いを誘発してしまう。よくある話として、一定の内部品質を達成するために「リプレースプロジェクトです！」と言って書き換えを進めて、それが終わったらまた内部品質は鑑みられなくなるような話があるし、内部品質だけではなく「EOL対応」とかでもそういうケースはまま聞く。

じつは直面すべき課題は「内部品質の低さ」や「依存ライブラリのアップデートが間に合っていないこと」ではなく、そのような状況を生み出してしまった開発プロセスや組織設計にあり、「開発プロセスや組織設計をどう直すか」なのである、というのはこの一年の大きな学びの一つだった。そして、とくに組織設計の話は現場のことをしっかり理解した上でトップダウンで進めるべき仕事で、VPoEとかCTOとか呼ばれる人の仕事だったり、ぼくがいまいる会社で言えばVPoTがやるべき仕事なのだ、と思う。

記事のタイトルを回収しておくと、プロダクトの品質を継続的に高く保つためには、プロダクトに向き合うだけでは足りなくて、それを生み出すプロセスや組織に向き合う必要がある。チームはそれぞれチームに向き合う必要があるし、チームを束ねる立場（これは上下ではなくて役割の違いだ）は各チームの組成をどのように行い、各チームがどのようにコラボレーションするかの設計に向き合わなければならない。

こんなあたりまえのことをきちんと理解するまでに1年以上かかってしまったけれど、理解したからには向き合っていこうと思う。