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

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

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

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

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

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

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

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

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

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

この記事の続き。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<追記>

</追記>

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

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

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

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

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

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

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

アジャイルなプロジェクトマネジメントにおける「スコープ調整」でやるべきこと、やるべきではないこと

アジャイルなプロジェクトマネジメントの勘所のひとつとして「スコープを調整する」があると思いますが、これを「どの機能を落しますか」とか「どの画面落としますか」「機能の優先順位はどうなってますか」とかそういう話だと認識すると不幸になると思っている。というのも、これは「価値」ではなくて「機能」に向き合ってしまっているから。

するべき調整はむしろ「この価値を届けるために、どう工夫したらもっと小さいコストで最低限を届けることができるか」みたいな話であって、例えば「機能作りきれません」ってなったら単純に優先順位順に機能を落としましょうという話をするのではなくて「1stリリースのタイミングでは、このレポーティング機能はプロダクトの画面上には載せないけど、代わりにCSチームの協力を仰いで機能が実装できるまででレポートを手動で作成・送信してもらうことは可能なんだっけ」とかそういう形で「なんとかして価値を届け切るために、組織全体での価値の出し方ごと組み替える」みたいな調整をすることだと思う。そのために頭に汗をかくのが、アジャイルなプロジェクトマネジメントにおける「スコープ調整」なのではないかと思います。

言うは易し行うは難しすぎる。けど知的労働ってそういうことだと思う! みなさん頑張っていきましょう。

ソフトウェアの「適切な構造」の構成要素とは?

いろんなところで主張してきたことの繰り返しになりますが、ソフトウェアの設計とは、「解きたい問題に対して適切な構造を与えること」だとわたしは考えています。

「解きたい問題に対して適切な構造を与えること」という以上、「解きたい問題」が変われば「適切な構造」も変化する、ということが言えるはずです。これは「まず問題を適切に捉えること」の重要性を示していると言えると思っています。しかし、そのことと同等に問題とされるべきは、「適切な構造は何によって構成されるか」であるとも思います。

わたしは、ソフトウェアの「適切な構造」を構成する二大要素は「関心の分割点」と「分割点によって分割された要素同士の依存関係」だと思っています。

つまり、ソフトウェア設計とは、「まず解きたい問題を理解し、その問題に応じて、適切な関心の分割点を見出し、見出された関心の分割点で分割された各要素に対して最も適切な依存関係を設定すること」だと、わたしは考えています。なお、「解きたい問題」は、時に「真に解くべき問題を見出す」という問題であることがあり(というか現代のソフトウェア開発においてはそういう問題が大多数を占める)、その場合は「探索的な問題を解くために必要なアジリティを確保できるような分割点と依存関係を見出すこと」が設計の勘所になってくる、という話になってくると思っています。

ちょっと抽象度が高い話をしたのでいつか機会があればもう少し具体的な事例を交えて書きたいかもしれない。ブログなので今日は雑に書いておしまいとする。

チームでのファシリテーションで心掛けてること

最近現場に入っていって改善おじさんをやっているのだけれど、その中で「しんぺいさんのファシリだと納得感もってなおかつ物事が決まっていく」と言ってもらえて、これがとても嬉しかった。納得感とものごとが決まること両方が必要な場合に、自分がファシリテーションするときに意識していることを軽くまとめてみる。大きく言うとふたつしかなくて

  • 話は基本的に無限に逸れていくものなので、常に時間を意識して「この会議で決めないといけないこと」に関連するメインストリームに話を戻すことを気をつける
  • メインストリームに話を戻しつつ、全員の意見をきいてなるべく全会一致を目指す

だけ。念の為再度書いておくと、「納得感とものごとが決まること両方が必要な場合」の話で、独断で決断したほうがよいものなど、それよりも優先されるべき事柄がある場合はこの限りではない。

ものごとが決まらない会議というのはだいたい無限に話が逸れていったり詳細に入り込んでしまっていることが多い。なので、ちゃんと決めたいときは、必ず時間を意識して、時間内にゴールに辿り着けなさそうなときは「ちょっとこのままだと時間内に決まらないから話を戻したいんだけど」と話をメインストリームに戻すことを意識している。これをやるだけで「決まらない」ということはだいぶなくなると思う。

一方、「メインストリームに話を戻すぞ〜」と意識することと「俺の思う結論にみんなを誘導するぞ〜」というのは話が別で、ここで「話を戻したいんだけど、これが結論だよね」としてしまうと、ものごとは決まるんだけどメンバーにとっては納得感のない結論になってしまう。ここで二点目の「全員の意見をきいてなるべく全会一致を目指す」がポイントになると思っている。

全員の意見を聞くときにぼくが意識しているのは、必ず「それってこういう意味?」と自分の言葉で繰り返してみることだ。自分の言葉で繰り返すと、相手の言っていることを自分が都合よく解釈していた場合「そうじゃない」とフィードバックが返ってくる。これ一発で「その通り」ってなることは稀で、何度も「そうじゃなくて」をくり返す中で、わたし自身も、そのやりとりを聴いている周りのメンバーも、「意見があるひと」の意見を解像度高く理解できるようになってくる。こういうことを繰り返していると、ふたついいことがおこる。

ひとつめのいいことは、自分が見えていなかったこととか知らなかった背景が相手からどんどん出てくるようになって、「俺が思う結論」よりももっと良い決定ができるようになることだ。対話によって「より良い結論」が出るのであればみんなハッピーなので、「俺が思う結論に誘導する」よりもずっとそのほうが良い。もうひとつのいいことは、そのやりとりを聞いていた他メンバーの発言が誘発されることだ。だれかの意見をぼんやり聞いていても、なかなかそれに対する意見は出てこない。だれかの意見を解像度高く理解すればするほど、芯食った質問がでるようになるし、それに誘発された自分の意見も出てくるものだ。

こうして相手の意見を自分の言葉で言い直すことを繰り返すことで、多様な意見が出てくるようになる。そうすると、どうしてもまた詳細に入り込みすぎちゃったりとか今回決めたいことからズレたところに議論がいっちゃうことが起こるんだけど、行きすぎたらメインストリームに戻しながらもこれを繰り返していると、だんだん「論点は出揃ったね」という雰囲気になってくる。し、だいたい論点が出揃った頃にはみんながなんとなく「これに決めちゃっていいんじゃないかな」と合意できるような状態が出来上がっていることが多い。そうなると納得感もった上でちゃんとものごとが決まっていく。

ただ、そうやって論点が出揃ったと思ったあとにもどうしても決まらないことって結構ある。そういうときって「これっていわゆる決めの問題だよね」という状態になっているか、「本当は論点が出揃ってない」かのいずれかである場合がほとんどだと思う。そういうときどうするか。ぼくは、自分が「決めの問題じゃん」と思っている場合は「これってさ〜決めの問題じゃない? 決めの問題だってことってみんな同意できる?」と聞くことが多い。ここでみんなが「そうだな、決めの問題だな」と思うなら、ぱっと決めちゃえばいいし、「決めの問題であるという合意」は得られているので、納得感も得られる。

一方、「いや、決めの問題ではない」という人がいる場合、「なぜ決めの問題ではないのか」を聞き出すようにしている。そうやって聞き出したものに対して「それってこういう意味?」と自分の言葉で言い直すことをやっていると、途中で相手が「あ〜、てことは決めの問題か」と気づくこともあるし、ぼくが「あ〜〜〜それは決めの問題にできないですね」と認識が揃うかになってくる(だいたい五分五分くらいでそうなるので、やっぱり対話が大事)。後者のパターンの場合はつまりそれまでの議論で出てこなかった論点がこの対話の中で出てきたことにより合意に近づき、どちらにせよめでたしめでたしという感じになる。

だいたいの場合、時間を意識しながらこれを繰り返すことで、時間内に全会一致にたどり着くことができると感じている。一方、問題のサイズがデカすぎたり根が深かった場合、時間内に全会一致に辿り着けない場合もある。そういうときっどうするか。ぼくは、ケツがシビアなものに関しては「ケツがシビアなので、情報は出揃ってないけど決断しないといけない。決断するのはコイツ」だけ決めてお開きにするし、ケツがシビアではない場合は「もっかい時間決めて集まろっか」で持ち越すことが多い。

なんか雑多な話になってしまったが、自分のファシリテーションはこういうスタイルなんすわ、というのを書けてよかった。ブログはまとまってなくても雑に書いていくべきって思ってたのに最近それができてなかったので、まとまってないけど雑に書いた!