🙂

プログラミングにおける精神的摩擦（Mental friction）と向き合い方

2021/12/08に公開

Ruby

はじめに

これは Qiita Advent Calendar 2021 D言語カレンダーの 8日目の記事です。

近年プログラミング言語の1つであるD言語のコミュニティフォーラムで言及されるようになった「精神的摩擦（Mental friction）」という概念について、個人的な考えも交えつつ整理したもの公開しておこうと思います。

ある程度読んでいただくと、以下のような課題に対して改善が図れたり理解が進むのではないかと思います。

プログラミング等で自分の怒りや不満を抑えるポイント、改善に向けた方法論
稀に見るヘイトにあふれた技術記事や日ごろ発生する不満への対処法
プロダクトの価値としてぼやけがちな「心地よさ」の明確化

もちろん話を単純化したうえで予想を多く含むので、怒りや不満の心理を理解したとか言うつもりはまったくありません。全然違うこともあると思います。以下実際のやり取りをまとめたものなので、そういう例もあったのだ、という程度にご覧いただければと思います。

また心理学っぽい用語ですが、本当にこういった言葉があるかどうかについては調べもついていないため触れません。あくまでもローカルな概念と思われるので、プログラミングやプログラマーという文脈でのみ考察、内容整理したものです。

要約

主にプログラミング中、思考の必要性などに起因してエネルギー消費が必要になる事を物理現象になぞらえて「精神的摩擦(Mental friction)」と呼ぶ
- 何かの要因でストレスを感じる瞬間、その対応エネルギーが必要となることを「狭義の精神的摩擦」と呼ぶ（ほとんどの場合、これを単に精神的摩擦と呼んでいる）
精神的摩擦はそれ自体熱を発生させる。小さな摩擦でも続くと大きな熱となり、発散されないとオーバーヒートが起きる。
- オーバーヒートが起きると、人は摩擦そのものに思考が向けられてしまい生産性が落ちる
- 逆に摩擦が少なければ快適で、使っていて気持ちが良いと感じやすい
- その人の経験や知識、好みによって摩擦を感じるポイントは異なる
- 摩擦の評価にあたっては、発生した摩擦以外にも将来発生するだろう摩擦が予測として含まれている
精神的摩擦では、大きく2つの陣営とそれぞれの課題がある
- 摩擦を感じている人が、自身の感じる摩擦をどう軽減するか
- 摩擦を感じていない人が、摩擦を感じている人や全体最適化とどう向き合うか
自分が摩擦を感じている場合の対処
- 小さな摩擦が積もっている場合、改善目途が立つのか考えてみるのが有効。過去の実績から案外すぐ直るかも、と思えることがある。
- 摩擦に対する改善策を手に入れる。同じような摩擦を感じる人を探したり、関連コミュニティへの参加が良い
過熱に対してプロダクトオーナーや摩擦を感じていない人に求められる反応
- ほとんどの過熱は、わずかな致命的要因によるものか、小さい要因が多数積もったものか、で大別できる
- どちらか見極めたうえで、前者ならピンポイントで早期対応、後者なら改善策や今後の改善計画を伝えることが重要
- 多くの場合、問題発生の経緯説明は摩擦軽減に役立たない。可能な限り効率的な代替手段を先に提示したほうが良い
- 精神的摩擦の大小を第三者が安易にラベル付けするのは良くない。比較が必要なら当事者間で合意を得るよう努めると良い。ダメならせめてグレーにしておくというのも配慮

精神的摩擦（Mental friction）とは

完全に元は英語です。Mentalが精神的、frictionが摩擦なので「精神的摩擦」です。技術的負債や破壊的変更も同じ文法と思います。

摩擦ですので、何か2つのもの、直感的には対人的な衝突なりを意味しそうに思えます。

しかし今回意味する精神的摩擦というのはそれとは異なり、個人でも起こり得る、かなり当たり前で普遍的な現象を表しています。

思考とエネルギー消費

人はプログラミング中、ほとんどの時間で何か考え、思考し続けています。

あまり意識していなくとも、作る必要があるアプリの仕様はもちろん、文法やコーディング規約、エラーの可能性やパフォーマンスなどなど、挙げればキリがありません。

考えることが多いということは、当然それだけエネルギーも時間も必要になります。
人が使えるエネルギーには限度がありますから、無駄な消費は可能な限り避け、有意義に使わないともったいないですよね。

今回お話する「精神的摩擦」は、まさにこの様々な活動や要因に対し 精神的なエネルギー消費が必要となること を指します。

常に誰もが向き合っている現実であり、ポジティブもネガティブもなく、ただのエネルギー消費に関する法則のようなものです。
特に、その エネルギーを消費している状態を「精神的摩擦がある」と表現します。

文字通り摩擦ですので、熱が発生したり、物理現象と同様に弱めることができ、頑張ればゼロにできるかもしれない、という言葉的に類推される部分もほとんど同じ性質があると考えられます。

元々英語だったものを日本語に訳しても比喩のまま通じるところが多く、個人的には本質を表した上手い表現であるように思います。

狭義の精神的摩擦

精神的摩擦が発生する、つまり思考が求められる要因としては、「やりたいから」「必要だから」「不要そうだがやると決まったから」「本当はやりたくないけど必要なのは確かだから」などなど様々な状況が考えられます。

このうち特に「不要そう」「やりたくない」といった 主観的にネガティブな精神的摩擦 を「狭義の精神的摩擦」や「強い精神的摩擦」、あるいは単に「精神的摩擦」と表現します。

これを単に精神的摩擦と呼ぶことがあるのは、精神的摩擦（Mental friction）という言葉を使う状況がもう大体ネガティブな話をしているので、そこは省いて単に「精神的摩擦」としても通じてしまうからです。

また当然の話ですが、ネガティブな精神的摩擦はストレスに直結しますし、人によってはそれが怒りや失望として表出することがあります。

こういった 怒りが発生する状況を「精神的摩擦によって熱を持っている」と表現する ことがあります。摩擦熱です。

近頃は自分の怒りを制御するという「アンガーマネジメント」なるものも知られつつありますが、問題の元を辿ればこの「精神的摩擦」や「摩擦熱」という概念で上手く表現できるかもしれず、あわよくば未然に防ぐ対策もあるかもしれない、という期待があるわけです。

私もこの点が理解できるととても有益そうに感じられ、今回内容整理し始めた次第です。

精神的摩擦の例

これはほとんど狭義の精神的摩擦の例ですが、たとえばプログラミング言語における構文や機能によく見られます。

C言語では、変数宣言を関数の1番上にまとめて書く、という制約がありました。^[1]
PHPでは、変数宣言をする際に $ で始める必要があります。
いくつかの言語では、行の最後に ; が必要です。
この関数の戻り値は null かもしれない。
非同期の処理を書くために async や await といった便利な文法が使えたら良いのに。

こういった制約を見ると何割かの人は、「なんでこんな縛りがあるのかなぁ面倒だなぁ」という（ちょっとネガティブな）考えがよぎるでしょう。また $ や ; といったキータイプが増える系の問題では、入力を忘れるとエラーになったりして手間取った経験があるかもしれません。

null などはもう言うまでもありませんが、他にも様々な言語を行き来していると感じる問題というのもあるあるです。

このとき「人によっては納得しがたい制限」や「ある種の経験と諦め」によりストレスを感じてしまいます。

この 仕様や体験といったストレス要因 のことを一般に「ストレッサー」と呼び、この「ストレッサーが人にストレスを感じさせる出来事」を「(狭義の)精神的摩擦」と呼んでいます。

つまり、ストレッサーを抑えることこそが狭義の精神的摩擦を低減する策になる、結果として人は快適になる、という構図です。

やや特殊な精神的摩擦の例

この延長として、評価の割れる精神的摩擦というのもあります。元来精神的摩擦に良し悪しはないので評価も様々です。

人によって評価が真逆だったりするものは往々にして議論の的となりますが、ツールや言語のデザインにおいてこれらを重要視するかどうかが色々な分かれ目になり得ます。

様々な最適化や検証のためにコンパイル/ビルドに時間がかかる
- 速いに越したことはないが、ある程度の理由から必然性が認識されやすい面がある
- ただし、コンパイル不要、または気にならないくらい高速な言語もあり、そういった経験がメインだった人には強い精神的摩擦が起こりやすい
短縮記法や注釈など、様々な文法・記述が許されている
- 様々な歴史や経緯を知っている熟練者ほど意識することが多く、最適を目指してしまって精神的摩擦につながりやすい（地味にエネルギー消費が多い）
- 記述のパターンが少なく誰が書いても同じになるほうが、複数人開発ではエネルギー消費、精神的摩擦は少ない、と考える場合もある。しかしこれも自由度のなさに摩擦を感じる人がいる
未知のパラダイムや全く知らない新しい概念を学ぶ必要がある
- 知的好奇心を誘う一方、仕事で手早く済ませたい人にとっては強い精神的摩擦を生む
- 精神的摩擦（エネルギー消費）という意味では最大級。新規性が必ずしも良しとされるわけではない。

どれも非常に経験や知識、慣れの問題があり、精神的摩擦をストレスに感じるかどうかも個人差があります。ある種訓練されてしまった人は、「精神的摩擦が熱に変わりにくい人」と言うことができるかもしれません。

しかしこういった精神的摩擦がないというのは非常に快適とされ、一度掴んだコアなファンが離れづらい、といったメリットがあります。

経緯

ざっと定義や用法を並べましたが、ここで精神的摩擦（Mental friction）が使われだした経緯を少し整理します。

きっかけはRuby

Google等ではうまく探せず、D言語のフォーラムのみ検索しました。
見つけられた限りでは、最初に Mental friction として言及されたのは 2010年12月16日、Stephan Soller氏によるものです。
約11年前、恐らくこのあたりから使われだした表現と考えられます。

このスレッドのタイトルは Why Ruby? ということで、その多くがRubyの良さについて思い思いに書き込んでいるスレッドです。（なぜかD言語のフォーラムはいつもこんな感じ）

その中で何度も出てくるのが、Rubyの書き味とも言える表現力や思考とコードの一致度がとても高いこと、つまり「精神的摩擦が小さいこと」です。

一例としてD言語の UFCS ^[2] に対するコメントを抜粋しますが、よく出てくるのが以下のようなコードです。

map!("a * a")(filter!("a > 3")([1, 2, 3, 4, 5]));
[1, 2, 3, 4, 5].filter!("a > 3").map!("a * a");

処理内容は、「配列の3より大きい要素を取り出して二乗する」というものですが、コードとしては明らかに異なる表現、下手をすると別の言語にも見えます。

特に前者は説明文と真逆の順序で処理が表れており、主語にあたる配列が出てくるのは最後になっていることがわかります。

Stephan氏にとって、後者は自分の思考の流れにマッチしており、前者は3段階のバッファと2回のジャンプが必要で思考にはエネルギーが必要、としています。UI設計でもマウスクリックなどの操作回数が少ないほど良いと言われたりしますが、それに近いものがあるようです。

またそのうえでこの思考のコストを以下のように「精神的な摩擦」と呼んでいます。

However that kind of "mental friction" adds up and you notice that if it's no longer there. I really agree with Matz (the creator of Ruby) that the way you formulate your thoughts changes your thought patterns in turn. Ruby is carefully crafted to keep the resulting thought patterns close to the natural ones.

以下訳：
このような「精神的な摩擦」が積み重なると、それがなくなったとき（訳注：Rubyに戻ったとき）に気づくのです。思考の組み立て方によって思考パターンが変わるというMatz（Rubyの作者）の言葉には、本当に納得がいきます。Rubyは、結果として得られる思考パターンが自然なものに近くなるように注意深く作られています。

つまり、通常のC言語などに見られる関数呼び出し構文に対し、人の思考フローに合わせたUFCSは精神的摩擦が大幅に改善されていること、またRubyにはそういった思考パターンに対する配慮がある、という評価です。

ツールや言語のデザインにおいて、人の思考と乖離が少ないデザインというものは多くの場合で素早いコーディングを可能にし、生産性を高めると期待されます。

このスレッドの題でもあるRubyが「気分よく」開発できることを1つの目標として掲げています^[3]が、まさにこれを期待してのことかと思います。

その他類似機能

UFCSという名前ではNimにも同じ機能が実装されていたり、C#の拡張メソッドやKotlinの拡張関数、Goのレシーバー関数なども類似機能と言えそうです。もう少し広くとらえればRustのtraitで実装するメソッドも近いかもしれません。

こういった機能はそのどれもが開発者の思考の流れに沿った記述を可能にします。

きっと他にも多数あると思いますが、近年こういった意識を持った言語機能が増えたことで1つのジャンルとして認識され、明確な言葉で表現されるようになってきたのだろうと考えられます。

具体的なメリットとしての認識

D言語のコントリビューターである Adam D. Ruppe 氏が個人ブログで精神的摩擦に関する内容をまとめていました。2021年2月8日の記事です。

特に説明として書かれているのが以下の部分になります。

People often ask "what is D's killer feature?" and that's difficult to answer because the real benefit is a couple big things sure, but mostly a lot of little things that cut down what I call mental friction.
Regular friction is a force that works against ongoing movement when two surfaces are in contact with each other. Any sliding or rolling object will eventually come to a stop without more energy input.
(中略)
Mental friction is what I call this same idea inside your brain. A bunch of little annoyances or thought/code mismatches that never stop you, but take just a bit of constant effort to keep going. Like with regular friction, this extra energy just goes to heat rather than useful work. Most the times, this heat dissipates harmlessly, but a mental overheat makes you frustrated and angry which can be a real productivity killer.

以下訳：
「Dのキラー機能とは？」とよく聞かれます。本当のメリットは確かにいくつかの大きなことですが、ほとんどの場合、私が精神的な摩擦と呼ぶものを減らす小さなことがたくさんあるので、答えるのは難しいです。
通常の摩擦は、2つの表面が互いに接触しているときに進行中の動きに逆らって作用する力です。滑ったり回転する物体は、エネルギーを入力しないと最終的に停止します。
(中略)
精神的な摩擦とは、あなたの頭の中で起きるこれと同じ概念です。あなたを止めるまではいかないが、行動を続けるためにはほんの少しの絶え間ない努力を払い続け、小さな煩わしさや思考とコードのミスマッチがある状態です。通常の摩擦と同様に、この余分なエネルギーは有用な仕事ではなく熱を生みます。ほとんどの場合、この熱は害なく放散されますが、精神的なオーバーヒートはあなたに欲求不満と怒りを感じさせ、それは本当の生産性キラーとなる可能性があります。

近年D言語を使う理由やメリットを問われたとき、この「精神的摩擦の少なさ」を挙げ、これこそが高い生産性を保てている大きな理由である、と答えることが出てきました。

実際私もこのような精神的摩擦の少なさに惹かれてD言語を使い続けています。
言語的な制約すら無視したつもりで書いた思考垂れ流しコードがなぜか思った通りに動く、という不思議体験が何度もあり、開発者を制限しない大変面白い言語だと感じます。他の言語でここまでのことは経験がありません。

もちろん個人差はありそうですが、精神的摩擦によって発生する熱が大きい方、それが生産性に直接影響している方がいることも事実でしょう。

この説明の通り、精神的摩擦が熱を生み、その結果生産性が大幅に悪化する事態は可能な限り避けたいものです。そういった問題を回避できれば、それだけで生産性は大幅に改善されると期待できます。

さらにこういった概念が頭の片隅にあれば、トータルで精神的摩擦を軽減するデザインができたり、コアなファンが付きユーザーが離脱しづらいプロダクトというものが作れるようになるのではないか、と最近考えるようになった次第です。

精神的摩擦との向き合い方

精神的摩擦は小さいに越したことはありません。積極的な改善が難しくとも、熱が溜まってオーバーヒートしてしまうような事態は避けたいところです。

そこで、摩擦が増えてしまう要因であったり、具体的な軽減策についても整理していきます。

好き嫌いと精神的摩擦

今回書き残したかったことの1つですが、精神的摩擦では、個人の好き嫌いを考慮します。

論理性と感情はよく対比的に扱われますが、論理性と感情は決して両立しない関係ではない ということです。両立する場合もあります。

いかなる利益のためであっても、人間の感情的な面を無視し続けるというのはそうそうできる判断ではありません。
であれば、むしろ全面的に受け入れよう、というのが精神的摩擦におけるメインの考え方です。

といっても難しい事は特にありません。

単に摩擦という意味では、「嫌いである以上、常に回避のための思考が働く。それはつまりエネルギー消費であり摩擦がある。 自身に相応のメリットがないと受け入れられないだろう」と評価されます。嫌いは摩擦です。

もしそこで「嫌いだろうと全体合理性に基づいて精神的摩擦を受け入れろ」というのは、個人のエネルギー収支の観点から見れば中長期的に支出を強いることを意味します。慣れれば大した問題ではない、と考えるかもしれませんが、強いられた当初に摩擦が起きることは変わりません。

もしも慣れる前の摩擦が強い段階で訳あって利用をやめたりした場合、負の感情だけが残るので誰も得をしませんよね。以前使っていたけどアレはひどかった等、身近でそういった意見を聞いたことがある方もいらっしゃるのではないでしょうか？

ここで起きる精神的摩擦を最初から低く抑えることができれば、悪い評判が広まってしまうようなことは避けられるはずです。

オーバーヒートとは？

オーバーヒートは日本語にすれば過熱です。熱しすぎた、あるいは熱暴走してるということですね。

精神的摩擦の文脈では 「摩擦熱は溜まる（色々合算される）」 とされるので、比喩的には 「その人が耐えられる熱量を摩擦熱が上回った状態」 とも言えます。

人間、一度熱くなったら作業どころではありません。 その熱によって思考が乱され、本来やるべきこと・やりたいことが手につかなくなります。

摩擦への対処で手一杯であったり、そもそも怒りや不満で何をしているか自分でもよくわからなくなるわけです。これは由々しき事態であり、まさに生産性キラーとなってしまいます。

オーバーヒートとヘイト

ここで言う「ヘイト」(Hate、英語で「嫌い」や「憎悪」の意)というのは、「『これはダメだ』ととにかく対象に悪い評価を下したり、そういった意見を広めようとする活動や意見それ自体」といった意味合いです。

技術記事でもそういった意見は稀に見られますが、その主旨には「とにかく苦労する」という内容が見られがちであることから、それらは確かに経験に根差したものであり、一種の精神的摩擦によるものだと考えられます。

一見して冷静さの有無という点で異なるところはありそうですが、「ヘイト」は一種の「オーバーヒート」だと考えることができそうなわけです。

ところが、いくつかのヘイト投稿などを振り返ると「この時発生していたであろう摩擦および熱量」と「当人の訴える最終的な評価」に少し違いを感じるケースがあります。

もう少し言ってしまうと「ヘイトの場合、本人が経験していないようなシナリオも含め、あらゆる場面に対し最低評価を示すことがある」ということです。

オーバーヒートは実際のエネルギー消費や発生した熱に基づく現象なので、その多くは経験として語られるものになります。こうなってくると、何らか経験以外の要素がありそうに思えるわけです。

単なる精神的擦熱では語り切れないとすると、なぜこういうことが起きるのでしょうか？

オーバーヒートにおける「マイナス評価」

「つらい」とか「苦労する」といったマイナス評価にも様々なパターンが考えられ、これだけでは手がかりとして心もとない気がします。

そこで1つ着目したい意見としてあるのが、オーバーヒートの振り返りにおける 「最終的な評価は、摩擦に耐えるべき想定期間が長いほど悪化する」 という経験則です。

「精神的摩擦」と「それによって発生する熱」に加えて、「最終的な評価」というものが出てきました。

これが何かというと、オーバーヒートした人やヘイトを持った人は、その時点までに実際発生した熱だけでなく、将来発生する分の熱を無意識に合算して最終的な評価を下す傾向にある、ということです。

つまり多くの場合、今までつらかったから爆発するのではなく、今後もつらいだろう分を見越して爆発する、ということを意味しています。

当人としてはとてもよく考えてのことであって、これは何というか…なんとなく分かるだけに…難しいですね…

とはいえ「最終的な評価」が「摩擦熱」と別なのであれば、もう少し整理して評価を抑える方法を検討したいところです。
摩擦熱が不意に生産性キラーとなることがないよう、これは自分にとっても重要なことであるはずです。

今後摩擦に耐える期間？

自分を悩ませている要因がいつまで存在するものか、そんなの考えもしないし分かるわけないと思いつつ、フォーラムのやり取りで1つ重要そうな意見が見られました。

それは、「多くの人は、耐える想定期間として無意識に『未来永劫、永遠、ずっと』を想定している」 というものです。

単に、今までこうだったんだから、今後も同じだろう、という論法です。
当然変化させる方がエネルギーを要しますので、変化しないと考えるのはある程度妥当と言えそうです。個人的な悩みだと自覚していればこそ第三者が勝手に解決してくれるとも考え難いですし、もし何か理由があるのでは？と考えれば事態が好転する可能性は更に低く見積もられます。

ここから容易に、今までに経験した精神的摩擦はこれからも続くだろう、という予測が立ちます。

なお、この予測が正しいのか間違っているのかという話はそこまで深掘りしません。
もし予測が間違っていて、精神的摩擦が容易に解消されるのであればそれはそれで良し。もしある程度正しいのであれば、その精神的摩擦を改善する方策が必要、という話になるためです。

どう転んでも平和な未来のために、解決すべき課題はまだ目の前にあります。

マイナス評価の構造

と、ここまでの内容について対策を練っていきたいわけですが、雑多な内容が多かったと思うので一旦情報を数式的に整理してみます。ただ厳密性はないのでご容赦ください。

まず、「既に経験した摩擦および熱」と「今後経験するであろう摩擦および熱」が時間ごとにあるので、時間を $t$ と置いてそれぞれ関数で表します。

摩擦熱_{経験}(t) = ...\quad \text{where}\,\,摩擦熱_{経験}(t) \geq 0 \\ 摩擦熱_{予測}(t) = ...\quad \text{where}\,\,摩擦熱_{予測}(t) \geq 0

さらに、摩擦熱の予測値は経験値から考えられるはずなので、直近の感覚と予測が近しいとして概ね以下の仮定が置かれます。1つポイントなのが、この段階では時間によらない「定数関数」であることです。

摩擦熱_{予測}(t) \fallingdotseq 摩擦熱_{経験}(t_{現在})

この前提で、経験した摩擦熱を経験開始から現在まで時間で積分し、発散された分を引いたものが今持っている熱の総量と言えます。

現在持っている熱 = \int_{0}^{t_{現在}} 摩擦熱_{経験}(t)\,dt - 発散した熱 \\ \text{where}\,\, 発散した熱 \leq \int_{0}^{t_{現在}} 摩擦熱_{経験}(t)\,dt

さらに、今後つらいであろう分の予測があり、これを先の仮定に基づいて同じように表すと以下のような積分で表せます。

今後持つであろう熱 = \int_{t_{現在}}^{\infty} 摩擦熱_{予測}(t)\,dt

これらの熱の和が最終評価となるので、少し分かりやすく順序を入れ替えると以下のような構造となります。

最終的なマイナス評価 = \int_{0}^{t_{現在}} 摩擦熱_{経験}(t)\,dt + \int_{t_{現在}}^{\infty} 摩擦熱_{予測}(t)\,dt - 発散した熱

最後のマイナス評価はもう少し整理できますが、一旦ここで止めておきます。

評価構造の解釈

色々と「そんなはずがない」という仮定を置いたように思われるかもしれません。考慮不足もあると思いますが、これだけでも多くの場合に説明がつくので一度解釈してみます。

まず最大のポイントとして、先の「耐える想定期間が永遠である」という仮定によって 予測にかかる積分の上限が「無限大」である ということがあります。

つまり、「今後持つであろう熱」の部分は、どこかで値が0に収束する見込みがない限り、容易に無限大に発散する構造をしている というわけです。

言ってしまうと、ここで 「マイナス評価が無限大に振り切れた状態がヘイトである」という仮説 が出てくることになります。

単なるオーバーヒートなら、ちょっと許容値を超えただけですぐ収まることもあると思います。これは対象に触れなければ熱の総量は増えず、別要因で熱が発散されれば熱の総量が純減するからです。

一方ヘイトの場合は「マイナス評価が無限大」なのでちょっとやそっとでは収まりようがない、と想像できます。対立の溝はなかなか埋まらないものですが、マイナス無限大が相手だとすれば太刀打ちできないのも幾分理解できます。

しかし、もしオーバーヒートやヘイトがこのような積分式に基づくのであれば、それを防ぐ方法はあるようにも思えます。要は積分の結果を一定以下に抑えこもうという話ですから、そこまで選択肢は多くありません。

この対処は、次の節で整理していきます。

精神的摩擦を取り巻く人々

精神的摩擦を知ることで解決、軽減されるであろう課題は大きく2つあります。

精神的摩擦を感じている人 が、その要因とどう向き合うか
- どうすれば精神的摩擦が軽減できるのか
精神的摩擦を感じていない人 が、摩擦を感じている人や全体最適化とどう向き合うか
- どうすれば精神的摩擦の軽減を手助けできるか

順番に整理していきます。

自身が感じている摩擦の軽減方法

もしここまで読んでいただいたあなたが何かのツールや言語に対して精神的摩擦を感じているとすれば、根は実に忍耐強い方だとお察しします。

致命的な設計ミスと感じるようなものがあれば大々的に報告することが1つ発散する手になりますが、積もり積もっている精神的摩擦は別の方法でも軽減できる かもしれません。

すでに発生した熱に関しては変えようのない事実ですが、将来に対する見積もりの部分は変わってくる余地があるかもしれず、もし先の話のように無限期間耐える想定だった場合、案外簡単に抑え込める可能性があります。

つまり数式をベースに考えてしまえば、期間を短くするか、今後発生する熱の見込みを減らして自身の許容範囲に抑え込む、の2択です。

期間を見積もる（想定期間を短くする）

1つ考えられる対処は、今後も積もっていくであろう精神的摩擦と熱に対し、耐えることになりそうな想定期間を具体的に見積もってみる、という方法です。

先の積分で出てくる無限大部分が無限大でなくなるだけでも、その発散を防ぐことができる気がしてこないでしょうか。

ちょっとだけ、考えてみてください。

自分が強く不満に思うような事柄であれば、他の人も同じように不満に思うことがあっても不思議ではありません。
同時に、多くのプロダクトはそういった不満を聞いて「その不満は未来永劫解決しない」と言い切ることはまず無いはずです。

ここで永遠に続くつらい仕様だと考えてしまうと、今後発生する精神的摩擦の見積もり結果は無限大です。これはもう耐えようがない。今すぐ全否定すべきもその通りと思います。

しかしISOなどで世界的に仕様が定められ改変が大変そうなC++でも、今まで何度もバージョンアップを行い少しずつ改善されてきました。今は色々楽になったという声も聞かれ、今後も膨大な提案を捌きながら3年に1度という頻度でバージョンアップが予定されるようになっています。

動的型付けの言語に対しても、JavaScriptには静的に型が付与できるTypeScriptという拡張ができ、Pythonには型ヒントが入り^[4]、Rubyにも静的な型検査を導入しようという動きがあります^[5]。ある種根本的な設計指針によるつらさでさえ、それが広く認知されれば軽減しようという活動が起きうるということです。

ここから考えるに、行動を起こせば大抵は長くとも数年、当然OSSならもっと素早い対応が期待できるだろうと考えられます。今すぐは解決しないかもしれませんが、幾分有限の時間で考えられると気が楽になったりしないでしょうか？

歴史的に古く変更できないソフトウェアであったり、相当頑固な哲学を元に成り立っているプロダクトでなければ変化の余地はあるはずです。

もしも変化が見込めない場合は、別の方策を考えてみましょう。

仲間を探す（発生する摩擦と熱を減らす）

すでにかなりの熱が発生していて今にも許容量を越えそうな場合は、SNS等を使い同志を見つける というのが手の1つと考えられます。

これは同志が見つかれば軽減策が共有できるかもしれない、という期待があるためです。
もし今後の予測される摩擦熱が無視できるほど小さくなれば、将来無限大に発散することはほぼなくなるでしょう。

何らかのコミュニティに参加するというのは色々な情報が得られます。当然それ自体面白い経験にもなり得るので、精神的摩擦の軽減策というだけでなく1つ検討していただきたい部分ではあります。

ここまで、積もる精神的摩擦と熱を減らすために「今後摩擦が起きる期間を短くする」「今後発生するであろう摩擦熱を減らす」と捉えてみると他にも様々な対策が思い浮かぶのではないでしょうか？

こういった方策によって自身の持つ熱が許容量を超えないように制御し、生産性をより高い状態で保つことを考えてみていただければと思います。

摩擦を感じている人との向き合い方

これはちょっと極端な話ではあるのですが、自分が精神的摩擦をほとんど感じていない場合や摩擦を克服して感じなくなった場合、摩擦を感じている人の気持ちがわからなくなりがち、という傾向がよく指摘されます。

「慣れるしかない」「そういうもの」という言葉が飛び交う界隈は大変怖く厳しいものです。

とはいえ気持ちを理解しろというのも無茶な話ではあります。何か歩み寄る方法はないのでしょうか？

まず、精神的摩擦によって熱を持っている人を収める一般的な方法は無いだろう、と考えられます。怒りや不満を推し量ることは難しく、当然ながら経緯も要因も100人いれば100人違って当たり前だからです。

しかし精神的摩擦という概念によると、オーバーヒートに至るケースは大きく2つに大別できます。

何か数少ない致命的要因によって膨大な熱が発生した
小さな要因が多数長時間蓄積されて大きな熱になった

どちらであるか見極めるには各人の行動から推測するしかありません。

なお、あらかじめどちらか予測するのはとてもリスクが高いのですが、割合として考えたときには後者のほうが多いだろうと考えられます。
大きな要因なら誰の目にも明らかな問題として映るため、はっきりしない場合は大抵後者だろう、ということです。

対応における注意点

ここで1つ オーバーヒートの一次対応における問題ケース というのをご紹介します。

それは、現状の問題を何か1つ例示されたとき、それに真正面から経緯を説明して現状を納得してもらおうとする、というものです。

これの何が問題かというと、まず先のマイナス評価構造を前提とすると「理由がある」＝「変化には時間が掛かる」という意味になるため、予測分の評価が多少悪化します。さらに「確定事項なので変わることがない」となると、無限期間の積分を突き付ける結果となりマイナス評価が無限大まで悪化するトリガーにもなり得るわけです。

更にもし小さな多数の問題を抱える提案者だった場合、例示されたものは数多ある問題の1つなわけです。
そこに重大な背景なり事情を説明されたわけですから、「こんなことがそんなに大ごとなのか」「こんなことすら改善する気がないのか」といった印象を抱くことになります。

ここから一気に食い違いが起き、ある程度無難に進んでも、

なるほど分かった、他にもこれとこれとこれがある
全部あれとこれとそれという理由がある（1度答えた手前だが、書くのは大変）
なるほど（読むのも大変）
双方がプロダクトに関して大変な思いをする

というお互い大変さだけが残る状況につながります。

体力のある大きなプロジェクトなら日常茶飯事かもしれませんが、そもそもこんな状況になることは誰も望んでいなかったはず。

そして何より 提案者の精神的摩擦はほとんど軽減されません。
今後も同じエネルギー消費があり、更にこの日の思い出が頭の片隅にあるわけです。むしろ新たな精神的摩擦が発生したような気さえしないでしょうか。

本人にとっての問題の大小やその内訳は様々です。これを理解せずに先に進むのはあまりにもリスクが高いと言えます。

有効とされる対応

問題の発生経緯が大きく2パターンあるとしました。

それぞれ推奨される対応としては、

大きな数少ない要因が理由であれば、要因をヒアリングして素早く対処することが効果的
小さな多くの要因が積もった場合、一挙に改善できる見込みが少ないので軽減策の提示、継続的な改善の約束と遂行が重要

といったものがあります。

忘れてはいけない点として、摩擦を感じている人の多くは摩擦を軽減してほしいと考える ことです。
仕様であれば改善してほしい、機能不足であれば機能追加してほしい、当然適切なデザインあってのことですが、これを無理に回避しようとすると話がややこしくなりがちです。

一旦評価は受け入れたうえで、手早い対応は 代替案や軽減策の提示 です。経緯説明はそのあとでも遅くありません。

精神的摩擦がゼロにはならなくとも、改善見込みがあれば熱暴走するほどの過熱は抑えることができるかもしれず、これができる余裕もプロダクトやブランドの価値なのだと捉えると良いように思います。

またここで、過去にもこれだけのことをやってきた、今後の強化改善に期待しててくれ、という話ができるとシンプルにわかりやすい、という意見も見られます。
どこかの政治家や大統領の演説みたいですが、やはり実績というのは非常に説得力があり優秀なようです。

いずれの場合も「変化できる」ということがとても重要で、今後生き残っていくためにはますます重視せざるを得ない要素だと感じます。

精神的摩擦は順序尺度だが直接比較は避けるべき

これで最後ですが、少しだけテクニカルな話になります。

順序尺度というのは統計用語ですが、AとBを比較してAのほうが良さそう、といった感じで順番が付けられることを言います。しかし、その差や比がどれくらい、という情報は持ちません。

つまり、摩擦には大小ありますよね、というざっくりした話です。

ところが 個々の精神的摩擦は人の数だけ重大度の基準があり、この基準は時間が経つと変化することがあります。 ここは物理的摩擦との大きな違いです。

満場一致で順序が一致する場合は別ですが、食い違った意見をまとめることはまず間違いなく困難でしょう。
また結果に対しても継続的な見直しが必要になるので、比較自体を避けられれば、それに越したことはありません。

比較がよろしくない理由

第三者が2人の摩擦に基づく主張を順序付けるようとすると、その意図はなくとも一方の主張を軽視したように見えることがあります。

これが新たな精神的摩擦を生んだり熱として現れやすくなる（オーバーヒートしやすくなる）という経験則が分かってきています。

同様に、主張AのためにBより多くのコストをかけて対応する、といった判断を表明することも一方からは悪く捉えられます。
本来掛けられたコストが掛けられなかったと感じることで「精神的摩擦に耐えるべき想定期間」が暗に延びるように感じるため、ということです。

なかなか難しい影響が色々と考えられます。

教訓と対応

Issueやタスクに対し、メンテナが安易な優先度付けのラベルを付けるのも注意が必要だ、というのが1つの教訓としてあるようです。（ただし緊急を示す場合は別）
OSSとしてユーザーからの報告を直接受け付ける場合、それが一覧が見られるような体制なら特に注意すべきと言えます。

一般的に物事をグレーにしておくというのは悪く捉えられがちですが、こういう場合のグレーは良いグレーと言えるかもしれません。

また、使えるシーンは限られますが、こういった話題にはプランニングポーカーのような手法が割と有効で、主張Aの提案者が好意的で熱心であれば主張Bの問題についても意見をもらう、というのが1つ面白い対応になり得ます。

これがどういった作用を生むのかは定かではありませんが、当人からすれば摩擦が熱に変わりづらい、つまり主観的には熱が下がったように感じる、といった内容のコメントが見られます。

察するに、元々精神的摩擦は主観的に大きく評価しがちで、人の意見を推し量り比べる過程でいざ自分の摩擦に向き合ってみるとそんなに大きくなかったりする、ということかと思います。こういうのは性格もありそうですね。

とはいえ全体的な傾向として、当事者の声を活かして運営していく姿勢は好意的に捉えられる、というのは確かな事実であるようです。

今後このあたりは自戒としていきたいと思います。

まとめ

ヘイト絡みで少しヘビーな内容となってしまいましたが、精神的摩擦という割と普遍的な現象に関する内容を整理、考察してみました。

こういった概念が言語化・名詞化されることで、合理性や技術と人間の付き合い方が深まったり、議論の争点が明確になったり、技術選定の基準としても考慮され得るかなと思います。

この記事を読んで実際そういった変化が起きたら私としても嬉しく思いますし、組織やコミュニティ内の対立や不満の解消、生産性の向上というところに1つ貢献できれば幸いです。

もし将来、人の思考パターンがもう少し体系づけられるようになるのであれば、それを活用して更に使いやすい人中心的な設計がなされ、個々に合った快適なプログラミングスタイルが選べるようになるかもしれない、などと夢に思う2021年師走であります。

以上

脚注

現状はC99で既に撤廃され、色々な場所で宣言できます ↩︎
Unified Function Call Syntax (統一的関数呼び出し構文)という機能で、 func(a, b, c) を a.func(b, c) と書ける機能のことです ↩︎
https://gigazine.net/news/20110915-ruby-development-cedec2011/ ↩︎
https://docs.python.org/ja/3/library/typing.html ↩︎
https://www.wantedly.com/companies/wantedly/post_articles/346302 ↩︎