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

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

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

  • 文化や仕組みを変えるのは大仕事なので時間がかかってあたりまえなので焦らない
  • 小さい身近なところからやろうとしつつ、小さいことをやりきろうとしない。むしろ小さいところから始めることで学習するくらいに思う。
    • 小さい身近なところから変えていこう、という話はよくされるし、実際小さいところから始めることは有益だと思う
    • 一方、「小さいところ」に見えても結局のところ他の「小さいところ」と有機的に結びついていて、その小さいところを変えるために依存関係すべてを変えなければならないということが普通に起こる。これはソフトウェアの変更と似ていますね。「たった一行」を変えるために他のあらゆる関係する箇所を変える必要が出てきたりするってやつ。
    • もし小さいところが簡単に変えられたら、万々歳ではある。万々歳ではあるが、逆に言うとあまり本質的なところではない
    • 「小さいところ」から変えてみようとしたときにどこがブロッカーになっているかを学習することで、今の自分たちの仕事のフローがどこがどことどうつながっているのかを「仕事の中で」見つけることができる。この「仕事の中で」ってのが大事で、大上段からの「業務フロー分析」はなかなか進めるのが難しいが、仕事の中に組み込まれることでチームの学習が進みやすくなる。
  • 見つけた「変化に対するブロッカー」は敵ではなくて、「同じことに困っている仲間」のはずなので、問題意識の共有から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に書いたこと：

ナレッジワーカーの集団にとってのアクセルは文化、ブレーキはルール。文化は行動が作る

よく、「仕事の属人性を排除して、仕組みやルールで標準化すべき」ということが言われる。これは決して間違えていないと思うけど、一方で片手落ちだと思う。たしかに、労働集約型の事業においては、「人数を増やせば増やすほど利益につながる仕組みやルール」を作ることが大事になるだろう。一方、知識集約型の事業においては、これは必ずしも真ではないと思う。

言ってみればあたりまえのことだけれど、ルールや仕組みは、増えれば増えるほど労働は平準化されていく。労働集約型の事業においては、「ローパフォーマーを減らすこと」のほうが、「ハイパフォーマーにさらに高いパフォーマンスを発揮してもらうこと」よりも重要だ。だって数がたくさん必要なんだもん。そのため、ハイパフォーマーにとっては「枷」になってしまうようなルールや仕組みであっても、その仕組みを課すことでローパフォーマーでも一定のアウトプットが出ることが重要となる。つまり、労働集約型の事業にとっては「ルールや仕組みを整備すること」が事業をより大きくするためのアクセルとなる。

一方、知識集約型の事業にとっては、ハイパフォーマーが、事業にとって本質的ではないルールや仕組みに邪魔されずに、事業にとって本質的な仕事に集中してできることのほうがむしろアクセルとなり、仕事を平準化するためのルールはブレーキとなる。たとえば、オーケストラについて考える。労働集約的な考え方で、楽器の素人を10,000人集めても、ブラームスの交響曲を演奏するオーケストラは編成できない。けれど、少数精鋭の各楽器の達人が、演奏への造詣が深くなればなるほど、そのオーケストラには価値が出ることになる。このとき、このオーケストラのメンバーに対して「この楽器を演奏したあとは、必ず以下の手順にそって楽器をメンテナンスをすること」というようなルールを課したところで、あまり意味がないどころか有害である。なぜなら、優秀な奏者であれば、楽器のコンディションを損なって結果として自分の演奏が損なわれるようなことはしないし、「どれくらい楽器に対してメンテナンスをしていれば最適な状態を保てるのか」を深く理解しているはずだからで、ルールで手順を定めるよりも個々人に最適なメンテナンスをしてもらったほうがいいからだ。

そんな感じで、知識集約型の事業にとっては、「ルール」「平準化」はブレーキとして働いてしまう。では知識集約型の事業にとって、アクセルとなるものはなにか。それはおそらく「文化」なのではないかと思う。そして、文化は行動が作る。もしも、「いい演奏がしたい」というのが口癖なのに、そのための練習の効率を上げるための工夫は全然しないし惰性で練習するような行動様式を持つオーケストラがあったら、そのような行動様式が、そのオーケストラの文化となるだろう。そして、他方に「いい演奏がしたい」なんて表立っては言わないけれど良い演奏のために練習の効率を上げるための工夫や行動をあたりまえのようにするような文化のオーケストラがあった場合、前者が提供できる演奏の質（つまり顧客にとっての価値）の向上のスピードは、後者よりもずっと遅いものになるだろう。これはルールや仕組みでどうにかできる問題ではない。

あるいは、自分たちのパートの演奏技術の向上だけにかまけて、合奏したときの音楽の良さ（それが顧客、つまり聴衆にとっての価値だ）にはコミットしないような行動が多いオーケストラは、それが文化となるだろう。他方に、自分たちのパートの演奏技術よりも合奏したときの音楽の良さにコミットするような文化を持ったオーケストラがいたとき、どちらのオーケストラの演奏が、より聴衆にとって価値があるだろうか。これもルールや仕組みでどうにかできる問題ではない。

そのようなことを考えると、やはり知識集約型の事業においては、「文化」こそがアクセルとして機能するように思う。そして、「ルール」や「仕組み」は多くの場合ブレーキとして機能しそうだ。

もちろん、ブレーキはとても大事だ。なんのために？　事故を起こさないために。つまり、「ここを外すと事故につながってしまう」ということを防ぐための仕組みとしては、知識集約型の事業にとっても、ルールや仕組みは価値がとても高い。

というようなことを考えると、知識集約型の事業でより高い成果を上げるためには、「プラス事象を積極的に作るためにはルールではなく文化を作る（そのための行動をガンガンやる）」「ルールや仕組みは、マイナス事象を避けるために使う」という考え方が一定有効なのではないか。

ということを考えましたよ。

これを昨日の記事と繋げて考えると、「文化がナレッジワーカーの集団にとってのアクセル。そして文化は行動が作る。労働において許容される行動は、成果が実際に出でる行動である。つまり、自分のやりたいような形で、成果を出す行動をすることで、自分にとって理想に近い文化をアクセルとして使えるようになっていく」ということになりそうだ。

言うんじゃなくてやる以外に方法がない

雑文

「顧客中心主義」という言葉を振りかざすひとは胡散臭く感じてしまうが、一方で重要な考え方であるとも思うアンビバレントがある

労働についての話。

労働をしていると、「どうしてうちの組織はこうなってないんだ」とイライラすることはだれにでもあると思う。というか、そういうイライラを失ってしまったとしたらそれはもう理想を失っているということで、改善の機会を失っている。理想と現実の間のままならなさにイライラしながらも顧客（その顧客は社内の別の部署かもしれないが、それが最終的にエンドユーザーに届くロジックは強固にたてついていないといけない）に対してなんらかの価値を提供して対価を得るのが労働だとさえ思う。

ところで、この理想を実現するためにはどうしたらいいのだろうか。理想を知ること、理想の状態を想像することは簡単だけど、このままならない現実を理想に近づけるためになにかを変えるというのはすごく大変だ。このギャップがひとを苦しめる。「こうあるべき」を言うだけなら誰にでもできることなので、それに価値はほとんどない。結局価値があるのは「一歩でも理想に近づく変化をもたらす行動」だけなんだけど、その変化をもたらす行動をできるかどうかは「どういう仕事をまかされるか」に依存するので、自分の意思だけではできず、そのための仕事を任されるしかない。そして仕事は「その仕事ができるであろうひと」に任される。だってそうしないと事業が止まるもん。と、ここで気づく。「任せられるひとに仕事を任せる」ってそれループしとるやんけ。

このループを断ち切って、「任される」に入るためには、結局のところ、「だれかがやるだろう」じゃなくて「自分の仕事じゃないけどそれをやることで事業のためになるから、やって結果を出す」という行動を続けるしかない。つまり、理想状態を作るためには、「今チームの目の前にある、事業上求められていること」に対して、いままで通りのやり方で結果を出すのではなくて、いままでを超えるやり方を探索しながら結果を出すしかない。いままで通りのやり方でやっても結果は出るかもしれないけれど、それはいままで通りなのだから変化にはならない。変化させるだけで事業上の結果を出さないのであれば、それは「無駄な変化」であり単なる迷惑行為である。だけど、やり方を変化させながら事業上の結果を出せば、「仕事の報酬は仕事」という感じでさらに仕事が任され、「変えることのできる範囲」が広くなっていく。

そう考えると、理想の状態を作っていくためには、「理想の状態を作るための仕事」をするのではなくて、「理想の状態に一歩だけ近づくようなやり方で、事業上の結果を出す」ということを繰り返していくしかないのだと思う。「理想の状態を作るための仕事」は「仕事のための仕事」で顧客のための仕事ではないから、どう頑張っても優先順位が下がっていく。労働だからしょうがないよね、労働は顧客に価値を提供しないといけないんだもん。「なんで理想の状態になってないんだよ」って愚痴を言うのはだれでもやる（ぼくもやってしまう）けれど、愚痴るだけではなくて、仕事を引き受けて、引き受けた以上のやり方をして実際に良い結果を出す。これは正直言ってかなり難しいことだと思う。ぼくも常にできているかって言ったらそんなことなくて多分三年に一回くらいしかそういうことができていない。けれど、結局言うんじゃなくてやる、以外に方法がないのだ、ということを理解したのでこれからもやるしかないのだと思う。しかししんどいわね。本当は寝て過ごしたい