「クソコード」との向き合い方を人類の排泄物処理の歴史から考える
なにかと物議を醸す表現である。
クソコードと聞いて、一般にプログラマはどのようなものを想像するだろうか？
大きすて画面に収まらないメソッド、依存関係が把握不能になったモジュール、乱雑な変数名、不適切なトランザクション制御、何に使われるのかわからないhoge.shファイル。
うーん、想像するだけで気分が悪くなってくる。しかし残念なことに、大抵のプロダクトには、多かれ少なかれこんなコードが存在する。
そいつはあなたがプロジェクトに参画する前からそこにあり、これからもプロジェクトに居座り続ける。
それは、理解には労力、修正には苦痛を伴うとんでもないものだ。あなたの生産性を著しく低下させ、「このクソコードがなければもっと良い仕事ができるのに！」と、焦燥感を駆り立てる。
プログラマなら、少なくとも一度はこんなものを目にし、また触れたことがあるのではないだろうか。
みんな大好きファウラー先生のリファクタリング本でも語られているが、プログラマの仕事の大半は、残念ながらそんなクソコードとの戦いである。
この記事は、そんなクソコードを処理する手法については触れない。おそらく、記事を読むより上記のファウラー先生の本を読んだ方が有用である。
この記事は、粗野な好奇心と下衆な勘ぐりを持って、そもそもなぜプログラマはそういったコードを「クソコード」と呼ぶのか、ということを考えてみたいと思う。
コードの質を非難するだけなら「ゴミコード」や「ダメコード」でもいいはずである。
私は一時期日本語でメシを食おうとしていたことがあり、日本語という言語を神聖視している。この「クソコード」という言葉には、何かとんでもなく深い意図が込められているのではないか。
そう思った私は、まずは「クソとは何か」ということを調べてみようと思い、こんな本を読んでみた。
プロダクトはクソをする
境界を持つことーーそこにコントロールされた漏れ口があることーーは、生命にとって不可欠だ。エネルギー、情報、物質を環境と交換できる系を。私たちは解放系と考える。その反対は、境界が何も出し入れさせない系だ。全ての生物は、人間を含め、解放系だ。
（排泄物と文明 49ページより)
半ば素朴な悪ふざけから手にとったこの本に、実に含蓄のある、面白い切り口の分類を発見した。クソをするものとしないもの、という分類の根拠についての記述だ。
我々が日々心血を注ぐプロダクトは、この分類で言うならば「解放系」に該当する。顧客の要望、マーケティング施策、セキュリティ、技術の進歩、そして組織の変化。プロダクトはその生命を維持するため、日々大量の情報と、コーディングと言うエネルギーを「摂取」し、それを代謝する。その結果、プロダクトには「使われなくなった実装」や「無理のある実装」が老廃物として蓄積する。
健全な生物であるならば、そのような老廃物は「コントロールされた漏れ口」から適切に排泄物として放出される。しかし残念ながら、大半のプロダクトは地球が作った「生物」というプロダクトよりも出来が悪い。「コントロールされた漏れ口」はしばしば適切に作用せず、プロダクト内部に老廃物が蓄積していく。
これこそが、エンジニアを悩ませる「クソコード」の正体ではないだろうか。
「それは無計画なエネルギー摂取のもたらした結果だ。そんな変なものをプロダクトに食わすな！」
と言うのは、エンジニアがよく陥りがちな思考だが、その考え方は短慮に思える。プロダクトは、現代人のように飽食の世の中に生きてはいないのだ。「キャッシュ」という栄養を摂取するために苛烈な競争を繰り広げる、市場という名の適者生存の中で生きている。
長期的に見れば、プロダクトの健康に著しい悪影響を与えるものであっても、今日を生き延びるために「食べる」選択肢を余儀なくされることは多い。
死人はクソをしない。クソコードは、プロダクトが今日までなんとかして生き抜いた結果であり、今なお生きている証なのだと思う。
そんなこと言ってもクソは臭い
と、クソコードを賛美するような文章を書いてみたが、私はクソコードがプロダクトにあるのはしょうがないことだ、と諦める立場をとらない。とりたくない。なぜならば、臭いものは臭いからだ。俺だって洗いたてのシーツみたいないい匂いがするコードが開発したい。
それに「クソ」というものは、生命にとって有害な成分を含む事が多々あり、エンジニアにとってのクソコードもその例に漏れない。クソコードが大量に存在するプロダクトでは、エンジニアの仕事は「いかにクソコードを動かすか」に終始してしまうことがほとんどだ。それは新しく効率的な技術の導入を阻害し、陳腐化した技術で仕事をすることを余儀なくさせる。それが多くのエンジニアのキャリアに甚大な悪影響を与えることは想像に難くない。
そもそも大量のクソコードがプロダクト上に存在することは、プロダクト自身にも多大な悪影響がある。クソコードによって動きが取れなくなり、開発が続けられなくなったプロダクトの数は決して少なくないはずだ。
しかし、多くのプロダクトは、クソコードをそのままにしてしまう意思決定を踏むことが多い。これはなぜなのだろうか。
クソを片付けるのは常識か？
「クソコード自体が臭いを持たないからな。みんな全く解っちゃいない。部屋にクソが落ちていたら片付けるのは当然なのにーー」
プログラマはしばしばそんな風に考える。私も考えていた。しかし、人類と排泄物の歴史からを学んでみると、それは早計だったように思えてきた。
中世ヨーロッパの都市部では、屎尿がそこら中に放置されていた。その臭いを隠すために香水が発展したーーというのは有名な話である。しかし、当時の人々も、別にそれをよしとしていたわけではない。本質的に解決できないクソに香水をかけて急場をしのぐ。我々プログラマの代表的な仕事と一緒だ。
「排泄物と文明」によると、
「十六世紀のフランスでは、一五三九年の勅令によって、国民は自家用の汚水溜めを造ることを命令されていた」
とのことである。しかし、同著によれば、結局「クソはきちんと片付ける」という習慣が定着したのは十九世紀中頃。少なく見積もっても、三世紀という膨大な時間が必要となっている。
しかもその最後のきっかけは、クソの持つ毒性の科学的証明だ。疫学の父として知られるジョン・スノー医師が、「コレラの原因は屎尿の混じった飲料水だ」と証明し、ロベルト・コッホが「微生物病原菌説」としてそれを前進させたことがきっかけになっているらしい。
実際に悪臭を放つクソの現物ですら、それを適切に処理するという習慣の定着には、科学的な裏付けが必要だったのである。
ソフトウェア開発はまだまだ発達途中の分野だ。「クソコード」のもたらすプロダクトへの被害は根拠に薄く、諸説が入り乱れている。プログラマですら「このコードはそのままにしておくとどれだけの被害が発生する」というのを定量的に見積もるのは難しいであろう。
例えクソコードが実際に悪臭を放つようになっても、もしかしたら人間はそれをすぐには片付けないかもしれない。そんな風に思えてしまう。
なぜ我々はトイレでクソをするのか
ここまで話すと、いわゆる「クソコード」問題はある種絶望的に思えてくる。だが待ってほしい。人類史における全ての文化が、その処理方法についての勅令が出るほどの悪臭を経験はしていないはずだ。
科学的根拠に基づかずとも、「クソはトイレにする」という習慣を持っていた文化は多い。私はレイシストではないので、そこに民族的な優劣があるなどとは考えない。
そもそも、現代人たる我々はなぜトイレでクソをして、それを水で流すのだろうか。悪臭がするからだろうか。病気の原因になるからだろうか。
否。そんな複雑な理屈については考えていないはずだ。
それは、そうするのが当たり前だからである。トイレ以外でクソをするのは恥ずかしいことである。幼い頃からそう育ち、教育をなされた。自分の親もそうしており、周りの人間も皆そうしている。そう言った文化に所属しているから、そうするのである。そこに明確な根拠はない。
これは歴史がたまたま獲得させた、文化の力だ。
そういった意味では、先の中世ヨーロッパの例はその逆説となる。彼らは「クソを片付ける」という文化がなく、そうした文化を手に入れる機会が、運悪く科学的根拠の獲得までなかったのである。
ここに、クソコードという言葉の持つ素晴らしさと、我々の問題を解決する糸口があるのではないだろうか。
プロダクトのクソコードか、個人のクソか
プロダクトの意思決定は、全てが揺るぎない科学的根拠に基づいて行われるわけではない。組織の価値観と習慣ーー文化から、最も勝率が高いと思われる仮説を立て「やってみるか」と実行されることがほとんどだ。しかし、「コードの品質が低いため、その改善に投資する」という判断は、プログラマが感じている有用性の割に、選択されることが極めて少ないと感じる。
この「クソコード問題」というのは、プログラマ組織の文化の問題なのではないだろうか。
最もやりがちで、そして最も話をややこしくするのは、プログラマ個々人の「クソコード」への向き合い方だ。
クソコードがプロダクトの一部である以上、どこかしらにそれを作った人間や、その責任を担う人間が存在する。その認識を誤ると、ただでさえややこしい「クソコード」問題に、人間の複雑な感情まで関与してきて手に負えなくなる。
私はかつて、この過ちを犯してしまったことがある。
当時のプロジェクトのリーダーは聡明なプログラマで、複雑なコードを削除することの価値を深く理解していた。技術選定やプロダクトマネジメントの経験も豊富だった。少なく見積もっても当時の、そして今の私よりも仕事ができる人だ。当時フロントエンド経験がほぼなかった私に、フロントエンドテストの設計を経験させてくれた大恩ある人である。
私はある日、そんなリーダーに、プロダクトの中枢にある、複雑な抽象化層モジュールのリプレイスを提案した。事前調査でそのモジュールがメンテナビリティを下げているのは解っていたし、他のエンジニアもそれに同意してくれていた。ほとんど「使われていないコードを捨てる」実装だったので、検証を含めても工数も非常に少なく済む見通しだった。
しかし、その提案は即座に却下された。リーダーから理由は色々と説かれたが、どれも腑に落ちるものではなかった。いつもの聡明なリーダーらしからぬ言動で、当時の私にはその意図が理解できなかった。
それが理解できるようになるのはもう少しプログラマとして経験を積んだ後、自分の作ったコードが削除され、違うものになるという体験をした後のことだ。当時の私は、その際にかかる心理的な負荷を甘く見積りすぎていた。というより、まったく理解していなかったのである。
「尊敬するあのリーダーの作ったものをより良くしたい！」という一心での行動だったが、私はその時、そのコードがいかに無価値で有害なものであるこかを、ただ滔々と説き続けてしまったのだ。私はそのコードが今までそのプロダクトの一端を担っていたことを忘れてーー
つまり、敬意を欠いていたのである。
こんな問題は、いろいろなプロダクトで起こっている事なのではないだろうか。
理想論で言えば、コードはプロダクトに属するもので、それらは常にプロダクトが最適になるように修正されるべきだ。クソコードはプロダクトのクソコードであり、チームで対処すべき事柄であり、個人に属するものではない。
しかし、残念ながらコードを書く我々プログラマは人間である。プロダクトにあるクソコードを、昔の自分が漏らしたクソのように感じてしまう事は無理なからぬ事だ。
それを皆の前で、経緯も配慮もなく、公然と晒されたとなってはーー「それはクソではなく味噌だ！ 栄養のある有用なものだ！」 などと意地を張るしか、人としての尊厳を守る方法がなくなってしまう。
私がこの結論に至れたのは、長期的にPJに関わる機会を得て、そこで自分のコードが不要なコードとして扱われるようになる経験をした最近のことだ。
この失敗があったため私は取り乱す事なく対応ができたが、分かっていてもなかなか精神的にクるものがあった。
クソコードと成長
さらにこの問題をややこしくしているのは、「プロダクトに残るコードは、その大半が今の自分にとってクソコードだと思える」ということにあると思う。
プログラマは日々成長する。コードを書き続けるだけでも、次第により良いやり方でコードを書けるようになっていく。勤勉なプログラマならば、新しい技術や未知の設計理論についても新たに学習するだろう。
しかし、プロダクトに書かれたコードは成長しない。そこには、いつまでも無知と未熟極まる自分がしでかした実装が横たわっている。それは作った本人も分かっている事がほとんどだ。それを他人に声高々に主張されると、幼少期にクソのついたオムツをしている写真を皆にひけらかされるようなーーそんな羞恥を覚えるものだ。
そして、成長するのはプログラマだけではない。プロダクト自身にも同じ事が言える。
健全なプロダクトは「仮説→実行→検証→修正」のいわゆるPDCAサイクルを回して開発を進められている。仮説は当然誤ったものを含む。ゼロから始まったベンチャーのプロダクトであれば、その黎明期の実装は、後から見れば「なんでこんなことをしていたんだ？」という「クソコード」だらけになるのは道理である。
しかし、それは仮説を検証したので、実行した内容が間違っていたと証明された結果にすぎない。人間が成長するようにプロダクトも成長する。今あなたが格闘しているクソコードなければ、今のあなたの仕事は、そのクソコードよりもひどいクソコードを作るのが仕事だったかもしれない。
誰だってオムツにクソをしていた時期があるものだ。
あなたも私も、そしてプロダクトも。
クソコードと文化
つまり、大切なのはクソコードの扱いに関する文化なのではないだろうか。
まず必要なのは、クソを作る原因となったことへの敬意。つまり失敗への敬意だ。
コレラの原因が人間のクソであると発見したジョン・スノーも、彼が中世フランス人である以上、路上にクソをばら撒く平均的な人間であった可能性は高い。もしかしたら、彼のクソが原因でコレラになった人間もいたかもしれない。
しかし彼を「路上にクソを撒いた人間」として評価する人間はいないであろう。彼は感染症疫学の父と呼ばれる偉大な医師である。むしろ、そのような文化に属し、問題を解決しようとしたからこそ、昨今の公衆衛生について大幅な進歩を得たのだと、私は思う。
日々我々の目の前に横たわるクソコードは、何かしらのプロダクト上の課題を解決したか、もしくは課題を発見するために必要な検証作業だったはずだ。
次に必要なのは、そのクソコードは、誰かの残したクソであるという事実の認識だ。
昔の未熟な自分が残したもクソについて、大抵のプログラマはちょっとした心当たりがあるし、自覚しているものだ。そうでなければ、そのプログラマはろくに成長していないことになる。
それはおそらく本人にとってはあまり見たくない過去であるし、あまり公然とされると、人間としての尊厳を守るために、「それはクソではない！」と開き直ったり、不健全な忖度が発生することになる。
自らの関わるプロダクトのクソコードについて、社外まで聞こえるような大きな声で喧伝するのはーートイレで誰かのクソを見つけて騒ぐ、男子小学生のような幼稚な行為だ。そこにクソがあるのは事実だ。だが、それを大声で叫ぶ必要はないはずだ。
最後に必要なのは、これらを踏まえた上で、きちんとプロダクトのクソについて意識を揃えることだ。
クソコードはレバーをひねれば簡単に流れるものではない。技術と経験を要するし、プロダクトの状況によっては「流さない」ことが正解になることだってある。どこにどんなクソがあるのか、それを皆が認識するのは、健全なプロダクトには必要不可欠だ。
プロダクトに昔から横たわるクソコードを必死で流したのに、誰もそのことに気づいてくれないーーみたいなことになると、プログラマのモチベーションを大幅に削いでしまうことになりかねない。
プロダクトに、ある程度のクソコードがあるのはごく自然で健康な事だ。クソコードからいかに人格を切り離し、不要な軋轢を産まずに認識を揃えるか。そんなやり方をプロダクトで見つけていくことも、プログラマの大事な仕事のひとつなのではないだろうか。
おわりに 〜クソコードに対してクソみたいな態度をとっていた私とあなたへ〜
さてはて。勢いで書いたらえらい長文になってしまった。
ここまで書いてみて気づいた事がある。それは、実物のクソが好きな人間は少ないが、クソについて語る事は好きな人は非常に多いという事だ。
クソに関連したスラングはどこの国にも多い。下ネタは人類にとって、あらがえない魅力があるものなのだろう。こんなクソに関する記事を7000字に及んで書き上げた私も、そしてそれを最後まで読んだあなたも、多分そんな魅力に取り憑かれている一人だ。
クソコードが原因で仕事が仕事がうまくいかずに焦っている時、プログラマがついクソコードに悪態をついてしまうのは、ある種無理もないことなのかもしれない。
とはいえ、20代半ばくらいの私はクソコードに対して、本当に「クソみたいな」態度を漏らしていたと思う。正直背筋が寒くなる思いだ。
しかしまあ、その態度もまた、私がこの記事の結論、成長にたどり着くために必要な「クソ」であったのだと、今では思う。
そんなわけで、クソコードにまつわる過去の話はーー
ーーお互い水に流すということで、どうかひとつお願いしたい。
この記事が気に入ったらサポートをしてみませんか？