> エントリ一覧 |

レビューと心理的安全性

コードレビューや仕事のフィードバックをする際によく聞くフレーズがあります。

「コードと人格は別だから」「コードを批判してるだけで、あなたを批判してるわけじゃない」などです。

でも、本当にコードや仕事の成果物と人格は別物なのでしょうか?

プロ野球の珍プレー好プレーはある種の仕事の成果物ですが、プレーとその人の人格はある程度一緒くたに扱われます。

ホームラン王を取れば本人もファンも嬉しいし、エラーをすれば本人も凹みますしファンからも叱咤されます。

それを「プレーと人格は別だから」とは誰も言いません。

野球の話はさておき、コードを書くという行為は、その人の思考プロセス、価値観、時には美意識すら反映される創造活動です。

私はそもそもプログラミングはロジックではなくアートだと思っています。

デザインパターンのデザインは日本語で表現すると設計なのですから。

どのアルゴリズムを選び、どういう変数名をつけ、どんな構造で組み立てるか━━これらの判断には、その人のアイデンティティが深く刻み込まれています。

「このコードは違う」と言われることは、「あなたの思考プロセスはダメだ」と言われているのと同じです。

Git(Github)が開発のスタンダードとなった今、プルリクエストを元にレビューを行うのは、もはや当たり前の慣習になっています。(自分から進んで有識者にレビューを求める行為はこのエントリで言及するレビューとは別物と考えてください)

レビューを受ける方もする方も、レビューそのものを懐疑的に捉える人はあまりいないと思います。

しかし、実際にはレビューをすればするほど、それに比例して個人のアイデンティティが蝕まれている現実があるのです。

レビューによるコード改善のメリットと、レビューを受ける人間のメンタルに与えるダメージ、この両者を天秤にかけた時、果たしてメリットの方が本当に大きいのでしょうか?

まず、レビューを行ったからといってコードが良い方向に改善されるという保証はありません。

むしろレビュワーの能力不足により、より悪くなったり、レビュー対象だけで評価すればそれで良いものでも、システム全体で見れば不適切であったり、その後のシステムの歴史の紡ぎ方によってはレガシーになってしまったりします。

逆に、レビューによる指摘は、人の気分を下げることはあっても、人の気分を上げることはありません。(良いコードは褒めようみたいな文化もあるらしいですが自分は見たことがありません)

返却されたテストの答案用紙のバツが人を気持ち良くすることがないのと同じように。

さらに、よりスマートに記述できるのを知りながらあえて冗長に記述するケースも状況によってはあり得ると思いますが、そういった場合に、レビュアーから冗長さを突っ込まれた時、その説明に心理的体力を奪われたりもします。(わざわざnitsを書いて相手の気分を害するぐらいならそもそも書かない方がマシだと思います)

最近、AIレビューも体験していますが、評価基準のコンテキストがコードにしかなく、コードにしかない上にさらにその一部しかないので、指摘内容と現実に存在する全てのコンテキストを考慮してレビューの内容を吟味する必要が発生し、それはそれで心労が発生します。

能力とやる気を天秤にかけた時に大事なのはやる気の方です。(もちろん仕事をこなすための最低限の能力は必要ですが)

能力については、AIの進化により人の能力に対する依存度は減っています。

かたや、やる気については能力に比べればどうでもいいだろ、と考える人もいるかもしれません。

しかし、できるよりやる方が大事だし、やる気の減衰は仕事のクオリティに影響します。

ちょっとした気持ちの入らなさの塵積がハインリッヒの法則の土台の土台を築き上げるのです。

そして個人のクオリティの減衰はコミュニケーション不全として別のメンバーのクオリティの減衰にも繋がっていきます。

出来の悪い仕事は他人の仕事を増やすのです。

以上のことから私は、むしろデメリットの方が深刻だと感じています。

そしてコードに限らず、あらゆる仕事のアウトプットには作り手のアイデンティティが宿っています。

企画書、デザイン、文章、プレゼン資料━━これらすべてが、その人の知識、経験、感性の結晶なのです。

そうであるならば、何かしらに対する意見の存在は、必然的に誰かしらのアイデンティティを脅かす結果に繋がるのです。

心理的安全性という概念がありますが、この現実を踏まえると、真の心理的安全性など存在しないのです。

誰に対しても忖度なく意見を表明できる状況は、みんなが自分のアイデンティティを否定する可能性を内包しているのです。

心理的安全性はそういった二律背反や矛盾を孕んでいます。

以前述べたように、言語化能力が高くなればなるほど、違いが明確になり、対立が生まれやすくなる現実があります。

細かい指摘をすればするほど、受け手との思想や価値観の違いが顕になり、コードとの心理的距離は縮みますが、その分人間の心は離れていきます。

レビューはみんなが思っているほど生産性があるわけではないし、心理的安全性もその実態は絵に描いた餅なのです。

何が言いたかったのかというと、脳死のレビューはピープルウェア(システムではなく人)にバグを潜ませるし、仕事において心理的な安全など存在せず、心理的な安全が欲しいのであれば組織などに属さず全ての仕事を自分一人でやり切るしかないのです。

Tags: プログラミング, 仕事

> エントリ一覧 |

知性の源泉

我々が知性を感じるとき、その知性の源泉は知識量から生じているのだろうか?

多くの人が知性と聞けば、まず思い浮かべるのは知識の量や論理的思考力といったものではないだろうか。

確かに、テストの点数が高い人や、難解な本を読み込んでいる人、複雑な数式を操る人などを見ると「賢い人なんだろうな」と感じる。

しかし、人々が知性を感じるのは相手の持っている知識量や論理性ではなく、もっと別の何かなような気がする。

例えば、栄養学について詳しく知っていて、偏った食事の害悪について語ることができるのに、自分自身は日々ファストフードばかり食べて不健康な体型をしている人がいるとする。

一方で、特に栄養学的な知識はないが、何となく体に良さそうなものを選んで食べ、自然と健康的な体型を維持している人がいるとする。

どちらがより知性的だと言えるだろうか?

知識偏重の価値観で見れば、前者の方が知性的に映るかもしれない。

しかし、現実世界での適応という観点で見れば、後者の方がはるかに知性的な振る舞いをしているのではないだろうか。

これが、知識から生まれる知性と、身体性や本能から生まれる知性の違いだ。

レヴィ=ストロースが『野生の思考』で述べた概念にも通じるが、人間の知性は論理や知識だけから生まれるのではない。

長い進化(もしくは人生)の過程で培われた身体的な感覚や直感、本能的な反応もまた、知性の重要な源泉なのだ。

知識から生まれる知性は確かに優秀だが、往々にして抽象的なレベルに留まってしまう。

頭では分かっているのに行動が伴わない、理論は完璧なのに実践で失敗する、といった現象はその典型例だ。

対照的に、身体性や本能から生まれる知性は、現実世界との直接的な相互作用の中で磨かれる。

そのため、具体的で実践的な場面において、しばしば知識偏重の知性を上回る成果を生み出す。

ここで一つ、知識よりも身体性が大事だと思わされる出来事が最近あったので紹介したい。

自分はラフロイグというウィスキーが好きでバーに飲みに行った時は、年代物やボトラーズのラフロイグをよく飲む。

ある日、ラフロイグの25年を飲んでいると、おもむろにマスターが別の瓶のラフロイグ25年を棚の奥から引っ張り出してきて「こちらも飲んでみてください」とお勧めされた。

そして、お勧めされた方のラフロイグを飲んで(いや香りの時点で)あまりのクオリティの違いに青天に霹靂が走った。

同じ「ラフロイグ25年」という定番商品にも関わらず、美味しさの次元が違ったのだ。

同じパッケージの商品なのに中身の品質にこれほどの差分が発生することにものすごく衝撃を受けた。

自分が今まで持っていた単純なウイスキーの知識では、熟年期間の長さに比例して味も良くなる、ぐらいしかなかった(し、大抵はそう)。

しかし、同じ熟成年数であるのにも関わらず、もはや別の飲み物レベルで味が変わるという実経験を経ると、知識だけではなく、いかに自分が実際に体験することが大事なのかが分かる。

仮想や抽象レベルの話であれば知識の方が有用に思えるが、こと現実においては身体知は知識を凌駕する。

スポーツ選手が理論を学ばずとも卓越した技術を身につけたり、料理人が厳密なレシピなしに絶妙な味付けをしたりするのも、こうした身体知の現れと言える。

料理研究家のリュウジ氏は料理に関する知識をたくさん持っているからすごいのではない。

彼自らの感性と才能により、誰でも真似できる料理のレシピや、人気メニューの解析レシピを次々と生み出し続けているからすごいのだ。

もちろん、知識は知識でとても大事なものだ。

ただ、我々は知識だけが知性の全てだと思い込みがちである。

現代社会では、テストの点数や資格の数、学歴などが知性の指標として重宝される。

しかし、そうした評価軸だけに囚われていては、人間が本来持っている豊かな知性の可能性を見落としてしまう。

もし真の知性とやらが存在するのならば、それは知識と身体性、論理と直感、抽象と具体のバランスの中にこそ宿っている。

知識を持ち、経験をし、分別を得ることで初めて躰から知性が滲み出るのである。

そして、そのジャンルのトップオブトップというか「全人類でこの人が一番スゴい」みたいな人との邂逅が、人の人生を大きく作用する、と個人的に思っているが、その現象も知識だけではなく、その人間から発する全てを自分の六処全てで吸収した影響が多大に関与するためなのかもしれない。

Tag: 哲学

> エントリ一覧 |

システムに舞い降りたリヴァイアサン

今、目の前のモニターに映し出されているエディタには技術的負債の積み上がったコードが無機質に描画されている。

設計や仕様が存在しないドキュメント、存在しても今となっては嘘吐きとなったドキュメント。

現状のシステムと乖離した内容が記載されたREADME。

マークダウン記法すら守れずフォーマットが崩れたREADME。

まともなローカル開発環境を構築することもままならないリポジトリ。

定義の曖昧なドメイン言語。

言葉の認識の揺らぎによるコミュニケーション不全。

awaitとforが幾重にもネストしたスパゲッティコード。

真偽地ではなく複雑なオブジェクトの配列を返すisXxxxxと名付けられた関数。

anyfullなts拡張子のついたJS。

実行する必要のない不要な処理たち。

そんな不要な処理の奥深くに残されているN+1問題。

そして、その問題により動かなくなった本番環境。

さらに、その問題を解決できずにあたふたするクライアント。

動かなくなった機能に対して不満を募らせるユーザ。

なぜか複数存在する同じ処理を行うモジュール。

APIを介してデータを取得する設計なのに直接DBにアクセスするモジュールの存在。

残されたままのオミットされた機能のコード。

さりとて、初期化処理は動作しているため、迂闊に削除できないオミット機能が使用しているモジュール。

リクエストヘッダを改ざんするAPIのコモンモジュール。

NoSQLなのにリレーショナルなデータ設計。

ひとまとまりのクラウド関数群と見せかけて、実は複数のリポジトリに分割されているクラウド関数群。

さらにプレフィックスで分割されていると思いきや、プレフィックスなしやサフィックス付きが混在する、破綻された命名規則。

そして、破壊された命名規則が奏でるコードの難読化。

「分からないことはなんでも聞いてください」と言われ、聞いて返ってくる答えが「分かりません!」。

そんな環境を一切改善することもなく、盲目的に仕事を行なってきた過去の開発者たち。

……そんな現実を前に、目の前のエディタと戦いながらタスクを消化していく。

ここまでで散々書き殴ってきたこのシステムは、新しく技術的連帯保証人になった自分からしたら悪意の塊でしかない。

しかし、冷静になって考えると、お金をもらって仕事している人間がそんな悪意を込めてコードを書くだろうか?

システムの所持者やレビューをする人もそんな悪意を無条件に受け入れるだろうか?

答えは否としか考えられない。

ということは、目の前のもはや殺意すら覚えるほどのコードには人間の悪意は一ミリも含まれていないのだ。

ただ、悪意がなくても、知見の足りなさや能力不足の結果起こる目の前の局所的な対応の積み重ねによって、致命的な致命傷に至ることはままある。

根本治療をせずに対症療法だけを続けても、薬やサポートに依存しなければ保てない弱い体になってしまうように。

一つ一つは悪意がなくても、局所的な対応の連鎖の結果が悪意を発するサムシングに育ってしまう。

個々人の行動の結果の総意に意思が宿ったように見える現象は、攻殻機動隊S.A.C.で描かれる「笑い男」事件に通じるものがある。

一人一人にはその意思がなくても全体として統括した場合、そこに明確な意思が宿る場合がある。

それがシステム開発運用における技術的負債という名の悪意である。

実際にはシステムそのものに悪意はないが、それを保守運用する人からすれば悪意を感じられずにはいられない。

システムの中のドキュメントやコードはただの文字列なのに、そこに悪意を見出すのはおかしいと思う人もいるかもしれない。

そんな人に分かりやすい例を用意してみた。(ちなみにブラウザのコンソールですぐに確認することができるぞ)

  const isClrNum = x => x == 1 ? 1 : isClrNum(x - 1) + 1;

上記のコードは意味がない上にバグを含んでいる。

  isClrNum(100000);

と、デカめの数字が入ってくると例外が発生する。

あなたが不具合調査の結果、上記のコードを見つけたら「誰だ!このコード書いたやつ!ぶち殺すぞ!」と言う気持ちが湧き上がるはずだ。

上記のような極端なコードはないかもしれない(と信じたい)が、度重なる仕様変更や作業者変更によるコンテキストの断絶の連鎖で、存在意味がない上にバグやパフォーマンス問題を含んだコードが悪魔錬成されることが稀によくある。

技術的遺産相続人でも書いたが、人の入れ替わりによるコンテキストの断絶の連鎖が積み重なって技術的負債は生まれる。

なんの対策も無しにシステム運用を続ければ、断片化された幾多のコンテキストがそのままコードに反映され、蓄積され続けることになる。

コンウェイの法則は組織体だけでなく人の入れ替わりにも適用される。

そのコードを後から参画した人が現在進行形のコンテキストだけを前提にして読むと魑魅魍魎が蔓延るパンドラの箱に映る。

そういった経緯で悪魔が宿ってしまったコードも、元は(きっと、たぶん)読みやすく意味のある真っ当なコードであったはずだ。

それが大人の事情で紆余曲折を経た挙句、歪なキメラに変貌を遂げたのだ。

個人の部分最適の積み重ねが集約されて悪意を持つかのような結果を生み出すこの構造は、何もシステム開発の世界に限った話ではない。

組織、市場、そして社会全体を見渡しても、同様のパラドックスが至る所で発生している。

例えば、ディープステイトや陰謀論でよくある、どこかしらの誰かや組織が世界を牛耳っていて、一般大衆の健康や富を脅かしている、という見方がある。

陰謀論でなくても、普通に政治家の無能さを嘆いて、自分の生活や未来の国のあり方に不満を持っている人は多い。

しかし、我々は自分の意思で社会から提供される商品やサービスの取捨選択を繰り返しているし、政治家も選挙で勝ち抜いた選ばれし精鋭たちである。

一人一人の良かれと思った日々の生活における選択の総意の結果が現実社会である。

その現実社会に不満があるなら、その源泉は陰謀や政治ではなく我々の内にある。

昔書いたブラック企業は会社がブラックなのではなく、そこに所属している人がブラックである話と同じようなものだ。

個人個人が抱えるコンテキストを全部ごっちゃにした結果、社会の裏に悪魔的な何かがあたかも存在するような幻影が浮かび上がってきただけだ。

ただの文字列でしかないコードに悪意を感じるのと同じように。

技術的負債を作ろうと思って作っているのではないのと同じように、ただ、個人個人の選択の結果が自分の意識できていないところで社会負債を積み重ねているにすぎない。

水の温度を上げたい人が追い焚きしているお風呂に、水の温度を下げたい人が氷を入れ続けるような、ルーブ・ゴールドバーグ・マシンにすらなれないような悲劇が我々の日常には潜んでいる。

……そんなことを考えながら手元ではrm -rfとコマンドする打鍵音が響いていた。

Tags: プログラミング, 社会

More entries ...