以下の内容はhttps://irof.hateblo.jp/entry/2025/01/24/121938より取得しました。

表出した事象を叩き潰してはいけない

ふつうのいとなみ

多くの事象は人の言動によって表出します。 そうして表出した事象に対して、私が「叩き潰す」と表現するような行為があります。 「叩き潰す」という言葉選びの通り、乱暴な行為です。 叩き潰している当人は問題に対処しようとして悪意なく行うのですが、当人の思惑と関係なく、叩き潰しのダメージを受けるのは表出させた人になります。「問題」に向けているのに色々貫通して「人」に至ってしまうのがよくないです。帰属の誤りではあるんですが、当人の意図とは関係なく、言葉は届いた場所で無意味に人を傷つけてしまうものです。 そんなことをしておいて「私は問題に対して攻撃しているのであって、人に対してではない」なんて言い放ったりします。当人は心の底からそう言うつもりなんでしょうが、受け止めた人は攻撃された経験を得てしまいます。 結果として、当然の防衛反応として「攻撃への対処」を考えるようになってしまいます。

ここまで挙げている叩き潰している「当人」とは私のことで、それへの自分へのストッパーが「表出した事象を叩き潰してはいけない」です。それなりに長いこと使っていますし、たまに言ったりもするので聞いたことがある人もいるかもしれません。

口語や𝕏で言うものの、形式化した記憶はないので書いてみようと思ったのがこのエントリです。

誤った防衛反応

いくつか考えられます。攻撃に対して反撃する。攻撃に備えて表出させる。そもそも表出させない。いずれも良いものではありません。無用な仕事を増やすことになります。

具体例で言うと、CIでテストが落ちた場合などが挙げられます。1秒でも早くテストを通す必要があります（それがCI、すなわちContinuous Integrationであるならば。落ちた状態でのんびりしていられるならば、それはCIの皮をかぶっているかもしれませんが、Cではないです。）。テストが通った後、落ちた原因に向き合って、何かの改善を検討する必要があります。これに対して「表出した事象を叩き潰す」と言う行為を行うとどうなるか。「なんでCI落ちてるんだ！！」と言う叱責ですね。

反撃 ：「これはCIじゃないから落ちてていいんです！！」CIというプラクティスを投げ捨てることになります。それをすてるなんてとんでもない。

攻撃に備える ：叩き潰される前にチェックします。チェックして反応すれば攻撃は飛んできません。一見よさそうに見えますが、push後に正常終了するまで眺めるのはどうなんでしょう？「pushした後はテストが通るまで待つんです」とかが暗黙のルールになる場合すらあり、自分たちでプロセスを重くします。こういう細かいものの積み重ねで効率は落とされていきます。自縄自縛。

表出させない ：通知を止める。CIでのテストをskipする。冗談のように思えるかもしれませんが、こういう意思決定が行われる世界も存在します。怒られるくらいなら隠すのは小さいこどもなどがよくやることですし、おとなもやるように、それなりに行われるものです。こういう「よくないとよく知られているけれどよく行われるもの」を「アンチパターン」と言ったりします。やらなければいい、でおしまいではなく、やらせてしまうフォースがあると見なければならないことです。

他にも防衛反応はあるかもしれませんが、いずれも「叩き潰す」のような乱暴な攻撃に対する必然のリアクションです。こんな仕事を作る仕事なんてやっている暇はないはずです。

叩き潰しの他の例: XXX禁止

先に挙げたCIでテストが落ちた時の話の他に、よく見られる叩き潰しの例として「XXX禁止」があります。具体例としていくつか。

  • コピペ禁止
  • getter/setter禁止
  • null 禁止
  • XxxManager という名前の禁止

よく聞くものですし、一定の効果があること否定しません。 でもこういうの、嫌いなんですよね。嫌ってるくせに自分でも言っちゃうし、他の人が言うことを咎めたりも（あまり）しないという、微妙な嫌い方ですが。

嫌っている理由は前述のような防衛反応（とくに「表出させない」のような誤魔化す方向）にいきがちだからです。 道具そのものが悪なんてことはあまりなく（ null に関しては、まぁ。でも広く受け入れられた道具ですしね…… ）、その道具の使用禁止を背景を伝えずに強要するのは、自分は嫌です。なので、せめて自分はやらないようになりたい。そう言う感じです。

やること: 叩き潰すを封じる

このように「叩き潰す」は誤った防衛反応を生み出してしまうので避けたいところです。 「表出した事象を叩き潰す」をざっくり分けると「表出」「事象」「叩き潰す」になりますので、個々をみていきます。

まずは「叩き潰す」ですが、この叩き潰しは「表出」が受け止めかねませんし、そうなると表出させた人に炸裂します。最悪です。 また、どれだけやっても「事象」を責めることになります。事象が問題の根源でないことは多いです。この点は後述。

つまり「叩き潰す」は「表出」も「事象」にも向けてはいけないので、存在意義がないです。封じてしまって、前者二つに向き合うための制約が掲題です。

タイトルを回収したのでここまでで完了としてもいいのですが、封じたあとの話も書いておきます。叩き潰さないとするだけで他の行動に移せるなら事足りるのですが、単に禁止とするだけで良くなることはそうそうありませんので。

やること: 表出を歓迎する

「表出」は如何なるものであっても歓迎するのが良いと思います。 「よく見えるようにしてくれた」と。

そのためには表出を抑えるフォースは可能な限り排除することです。 典型的なのは先の叱責ですが、他に言い出しっぺの法則とかもあります。

言い出しっぺの法則は、言い出した人が対処しなければならないことが固定化されてしまうことです。 気づいた人が一番詳しかったり、一番関心を持っていたり、一番困っていたりしますので、ある程度の妥当性はあるとは思います。 しかしながら「言った人しか対処しない」となると、表出のモチベーションは下がります。 対処まで至らずとも「あれどうなってます？」とか聞いてしまうだけでも、表出させたことが足枷になってきます。よくない。やってしまいがちだけど。 言い出しっぺの法則と仲良く付き合いたいなと思ってる。アイデアはありません。

共有という表出であれば、共有によって個人からチームに持ち主が移転されなければなりません。 チームワークが機能していないと「気づいていたんだけど言ったところでどうせ誰も何もしないし」と共有をしなくなります。

これに対して「気づいたことは共有してください」と言ったところで効果は薄いんですよね。ややもすればこの言及が「叩き潰し」行為となって「気づいてなかったことにしよう」となってしまう。 また「共有しない」を選ぶのは、成功体験に乏しく失敗経験が積み重なった結果の防衛反応だという構図になります。「共有したものが無視される」「共有したのに個人から移転していない」（いずれも「共有」って言葉の意味が軽くなっていることが問題っぽい）などは「叩き潰す」行為に他なりません。「叩き潰す」という言葉ほどアクティブに動いてなさそうなのでイマイチ感はありますが、無視もイジメとかいうのとたぶん同じです。

話が発散気味なので無理矢理戻しますが、「表出」は歓迎したいです。これ単体でも言葉で言うほど簡単ではないです。たぶんコミュニケーションとかの分野で一大テーマとして扱われているんではないでしょうか。知らんけど。

やること: 事象に向き合う

「事象」を人とか色々なものから切り離して独立させて、いわゆる「問題対私たち」の構図をちゃんと作ります。ちゃんと。ふわっとしてるな。

とにかく「事象」に向き合います。 ここでやることはインシデント対応みたいな文脈になってきます。軽くいきます。

  • 出血があるならば、それを止める。
  • 事象を引き起こした原因を特定する。
  • 原因を作り出したコンテキストを改善する。

まず出血があるならば止めましょう。先に挙げた「テストが落ちている」ならば「テストが通る」です。ソフトウェアの変更であれば、最初にやるべきはいつだって前回通ったバージョンへのリバートです。リバートしても通らないのであれば、それはプロダクトの作りに致命的な欠陥がある証拠です。流石にコンテキスト依存が強くなりますので割愛しますが、とにかく最速で出血を止めましょう。出血した状態で他のことをやっちゃいけないです。

出血が止まったら、落ち着いて事象の原因を特定します。原因が何階層になっているかは分かりませんし、「真の原因」とか「根本原因」とかふわっとした言葉が使われることもありますが（定義もあるのかもしれませんが）、妥当なところまでやります。 原因が特定できたら、その処置を行います。時間がかかるものは別途スケジューリングとなるでしょう。

そして重要なのにあまり行われていない気がするのがコンテキストの改善です。 原因が直されても、新たに作られるのであればマッチポンプです。マッチと可燃物のどちらが原因でどちらがコンテキストかはちゃんと考える気もないのでどっちでもいいんですが、とにかく双方なんとかしたいところです。

参考: どこどこ分析

ツリーに詳しい。「なぜなぜ分析」とセットの言葉で思い出しやすいし、何するかもわかりやすいいいネーミングだと思います。

表出した事象を叩き潰さない

うっかり叩き潰しをしてしまわないように、あるいは叩き潰してしまったことに気づくために使っている、私の中のスイッチとなる言葉です。この言葉が必要なくらいにはやってしまっている自覚を持っています。反省はしてるんだ。

この言葉を持っているので、防衛反応が観測できたら「あー叩き潰してしまった……」と気付けます。観測直後ならなんとか軌道修正できることもあります。できないこともあります。そうなると別の方法でフォローするしかありませんが、見落とすよりはマシです。観測できたら儲けものくらいの頼りにならないセーフティーネットです。全然セーフティーじゃないですが、ないよりマシです。

叩き潰しを封じるだけで、私は事象に向き合いやすくなっています。振りかざすには「表出を歓迎する」も「事象に向き合う」もそれぞれ単体で重く、万人に有用かは疑問があるのですが、文字にはしておこうと思って書いてみました。

おまけ1: メタメタ

なおこの言葉自体が「表出した事象を叩き潰した」と言う表出した事象を叩き潰すものになっています。そこは認識したうえで良しとしています。 自分宛てならいいかなって。

なので「irofがこう言うこと言ってた」とか言って「叩き潰し」を叩き潰すのはお勧めしません。いや私もやっちゃうんだけど、状況によっては全ての退路を封じかねないことになるので……もし使うときは代替案にスムーズに繋げるようにするのがいいと思います。このエントリのように、叩き潰すのを封じた流れで事象の根本原因の所在探しに目を向ける、みたいな。

おまけ2

これの1パターンが「遅れ」に対するもの。本当に個人の問題であればそれでいいのですが、仕事上で発生する様々な問題を個人に帰属させるのは私は嫌いです。これの類似が「遅れ」です。

irof.hateblo.jp

その問題に一緒に取り組める人は、たぶん問題を聞きたいと思うんです。

私は聞きたいんです。もし個人で解決できたとしても、その解決は隠れがちで、他の人や他のタイミングで同様の事象が起こった時に対処できません。私はそれが嫌なんです。

おまけ3: このテーマでの発言

ブログやTwitterから適当にひろってきました。特にTwitterの方はまとめなおして本文に反映しようとおもったんですが、それやってるとこのエントリの公開がさらに数年後になりそうなので、原液そのまま置いときます。だんいずべたーざんぱーふぇくと、とか言うやつです。

本ブログ内

irof.hateblo.jp 素直な適用例です。まんま「表出した事象を叩き潰してはいけない」と書いています。

irof.hateblo.jp こちらは「表出した事象に過ぎなかった」とストッパーに使っている例です。

irof.hateblo.jp 「表出」という言葉を使用。これに直接いくのじゃなく、迂回（元が迂回なので正面突破の方があってる気はするのだけど）する方向です。

Twitter

クソ長ツリー

クソ長ツリー



以上の内容はhttps://irof.hateblo.jp/entry/2025/01/24/121938より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14