シライショウタ（ポエマイゼーション：ソノダマリ）
ソノダマリがポエマイゼーションを定義した。事実がポエムに変わる6つの操作——補填、翻訳、蒸発、消去、変装、増幅。不動産広告、高校パンフレット、SaaSのランディングページ。50本の記事で、ポエムは「広告の言葉」だった。
しかしエンジニアの俺は知っている。コードの中にもポエムがある。
変数名。コメント。コミットメッセージ。README。エラーメッセージ。プルリクエストの説明文。プログラマーは毎日、コードの「外側」にある言葉を書いている。そしてその言葉は——驚くほど頻繁に——ポエム化している。
まず変数名の話をする。プログラマーにとって変数名は「事実のラベル」だ。中身がユーザーの年齢なら age、注文の合計金額なら totalPrice。事実に名前をつける。それだけのはずだ。
しかし現実のコードベースを見てみろ。
| 変数名 | 名前の主張 | 実態 | 操作 |
|---|---|---|---|
tempVar |
「一時的な変数です」 | 3年間「一時的」のまま本番稼働中 | 変装 |
data2 |
「データの2番目です」 | dataが何かも2が何かも不明。書いた本人もすでに退職 | 蒸発 |
isHappy |
「ハッピーかどうかの判定」 | 何がハッピーなのか、何の状態を指すのか、コードを500行読まないとわからない | 補填 |
utils |
「便利な関数を集めた場所」 | 分類不能なコードの最終処分場。3,000行 | 変装 |
fixedValue |
「修正された値」 | いつ、なぜ、何から修正されたのか誰も知らない | 消去 |
ソノダがDXポエム#4でカタカナ暗号辞典を作ったとき、「アジャイル」＝「なんか速そう」と書いた。変数名も同じだ。tempVar＝「なんか一時的っぽい」。data2＝「なんかデータっぽい2番目のやつ」。名前が事実を伝えるのをやめて、印象だけが残っている。これがポエマイゼーションでなくて何だ。
マンションの「上質がそびえる」は、何がそびえているのかわからない。data2 は、何のデータの2番目なのかわからない。
構造的に同じだ。
ソノダが匂わせ暗号で不動産広告の暗号辞典を作った。「閑静な住宅街」→「駅から遠い」。「日当たり良好」→「他にアピールポイントがない」。広告の言葉を平文に戻すだけで、景色が変わった。
コードのコメントにも、まったく同じ構造がある。以下にプログラマーのコメント暗号辞典を提示する。
| 暗号（コメント） | 平文（実態） | 操作 |
|---|---|---|
// TODO: fix this later |
永遠にfixしない。「later」は来ない。マンション広告の「近日公開予定」と同じ | 変装 |
// FIXME |
壊れていることは認識している。修理する予定はない。「FIX」と書いてあるが、動詞ではなく祈りだ | 変装 |
// HACK |
汚いコードだと書いた本人が認めている。しかし「HACK」と書いた瞬間、汚さが「臨時の創意工夫」に変装する。永遠にハックのまま | 変装＋増幅 |
// This shouldn't happen |
起きている。起きているからこのコメントを書いた。「起きないはず」は願望であって事実ではない | 消去 |
// Don't touch this |
なぜ動いているか誰も理解していない。理解していないものを壊す勇気がない。恐怖が禁止令に変装している | 変装 |
// Temporary workaround |
恒久的な解決策。「Temporary」は「今の自分にはこれが精一杯です」の変装。2019年から稼働中 | 変装 |
// For legacy reasons |
なぜこうなっているか誰も知らない。「レガシー」と言えば説明責任が消える。過去のせいにする消去術 | 消去 |
// Refactor this |
リファクタリングが必要だと知っている。しかしリファクタリングのチケットが作られることはない | 変装 |
// Magic number |
なぜ42なのか、なぜ1024なのか、誰も覚えていない。「マジック」は「説明不能」の増幅。ハリーポッターではない | 増幅 |
// Good enough |
良くない。しかし締め切りが近い。「Good enough」は「これ以上は無理です」の変装 | 変装 |
気づいただろうか。圧倒的に「変装」が多い。不動産広告の匂わせ暗号は「変装」と「消去」が主だった。コードのコメントは変装がさらに濃い。理由は明白だ。プログラマーは自分のコードの弱点を知っている。知っていて、コメントで名前を変える。「壊れている」を「FIXME」に。「汚い」を「HACK」に。「永遠に直さない」を「TODO」に。
「閑静な住宅街」は「駅から遠い」の変装。// TODO: fix this later は「永遠に直さない」の変装。
不動産屋とプログラマーは、同じ修辞技法を使っている。
GitHubのREADMEは、オープンソースプロジェクトの「広告」だ。リポジトリを訪れた人が最初に読む文章。3秒で印象を伝える必要がある。
……これ、ソノダがDXポエム#1でSaaS LPについて書いたことと一字一句同じだ。
| READMEの表現 | 平文 | 操作 |
|---|---|---|
| Easy to use! | ドキュメントは200ページ。セットアップに3日かかる。「Easy」の定義が書いた本人の基準 | 補填＋変装 |
| Blazing fast | ベンチマークは特定条件下での最良値。「普通の日」の速度は書いていない | 消去 |
| Well-documented | READMEが長い。それ以外のドキュメントは3年前で更新停止 | 補填 |
| Battle-tested | 本番で使ったことがある。壊れて直した回数は言わない | 変装＋消去 |
| Lightweight | 依存パッケージが50個。「Lightweight」は相対的なポエム | 変装 |
| Zero configuration | デフォルト設定で動く。ただしデフォルト設定では実用に耐えない | 消去 |
| Production ready | テストカバレッジは聞くな | 補填 |
ソノダが高校パンフ#2で発見した法則を思い出してほしい。弱いほどポエムが饒舌になる。偏差値が低い高校ほどパンフの言葉が増える。
READMEも同じだ。本当に使いやすいライブラリは「Easy to use!」とは書かない。コード例を3行書いて、それで伝わる。「Easy to use!」と書く必要があるのは、コード例だけでは伝わらないからだ。
高校パンフの「文武両道」は、文武両道でない学校が使う。
READMEの「Easy to use!」は、使いにくいライブラリが使う。
ソノダの補填の法則は、コードの世界でも成立する。
エラーメッセージは、ソフトウェアの「謝罪会見」だ。何かが壊れたとき、ユーザーに状況を伝える。少なくとも、そういう建前だ。
| エラーメッセージ | 平文 | 操作 |
|---|---|---|
| Something went wrong | 何が起きたか開発者もわからない。わからないので「何か」と書いた。情報量ゼロ | 消去 |
| An unexpected error occurred | エラーが「想定外」だったのは開発者の側の事情。ユーザーにとっては「アプリが壊れた」だけ | 変装 |
| Please try again later | 「later」にやっても直っている保証はない。// TODO: fix this later の「later」と同じ永遠 |
変装 |
| Contact support for assistance | サポートもわからない。あなたのチケットはキューの437番目 | 消去 |
| Error: null | エラーメッセージが null。エラーを通知する仕組み自体がエラーを起こしている。存在論的な悲劇 | 消去 |
ソノダがS2#10で見出した「消去」の操作——都合の悪いものを意図的に消す——が、エラーメッセージでは最も強く効いている。マンション広告が隣のビルを写さないように、エラーメッセージはエラーの原因を書かない。
ただしマンション広告と決定的に違う点がある。マンション広告の消去は意図的だ。チラシの構図から隣のビルを外すのは、わかっていてやっている。エラーメッセージの消去は、多くの場合能力不足だ。何が起きたかわからないから書けないのだ。
マンション広告の消去：知っていて隠す。
エラーメッセージの消去：知らないから書けない。
結果は同じ——ユーザーには何も伝わらない。
コミットメッセージは「何を変更したか」を記録する場所だ。未来の自分と同僚のために、変更の意図を書き残す。建前は。
| コミットメッセージ | 平文 | 操作 |
|---|---|---|
fix stuff |
何をfixしたか覚えていない。あるいは説明する気力がない | 蒸発 |
minor changes |
300行変更した。APIの互換性も壊した。しかし「minor」と書いた | 変装 |
WIP |
Work In Progress。永遠にin progressのまま。TODOの兄弟 | 変装 |
clean up |
何を掃除したのか。ファイルか、ロジックか、自分の良心か | 蒸発 |
update |
情報量ゼロ。すべてのコミットは何かのupdateだ | 蒸発 |
final fix (for real this time) |
3回目の「final」。次のコミットも「final」になる予定 | 補填 |
そしてプルリクエスト。
| PRの説明 | 平文 | 操作 |
|---|---|---|
| Minor changes | 42ファイル変更、+2,847行、-1,203行。レビュアーは泣いている | 変装＋消去 |
| Refactoring | 機能追加した。ついでにリファクタリングもした。レビュー不可能 | 変装 |
| No functional changes | テストが3件落ちているが、もともと落ちていたということにする | 消去 |
コミットメッセージには「蒸発」が多く、PRの説明には「変装」と「消去」が多い。これは書き手の心理に起因する。コミットは自分のための記録。面倒なので情報が蒸発する。PRは他人に見せるもの。だから変更の規模を小さく見せる変装が起きる。
fix stuff は「上質がそびえる」と同じだ。
何をfixしたかわからない。何がそびえているかわからない。
しかし書いた本人は満足している。
ポエムとは、書き手が満足するための言葉だ。
ソノダがDXポエム#4で「カタカナ暗号辞典」を作ったのと同じ方式で、プログラマーが日常的に使うバズワードを解読する。
| バズワード | 平文 | 操作 |
|---|---|---|
| self-documenting code | コメントを書きたくない言い訳。コードを読めばわかるはず、という希望的観測。読めない | 変装 |
| legacy code | 前任者が書いたコードの蔑称。ただし自分が半年後に書くコードも、後任者にとってはlegacy | 変装 |
| technical debt | 「後でちゃんとやる」と借りた時間。返済計画はない。住宅ローンのほうがまだ誠実 | 増幅 |
| it works on my machine | 自分の環境では動く。本番環境では動かない。デバッグを他人に委ねる呪文 | 消去 |
| scalable architecture | 現在のユーザー数は12人。「スケーラブル」は「いつか大きくなるはず」の増幅 | 増幅 |
| best practice | Stack Overflowの一番上の回答。「best」の根拠は投票数 | 増幅 |
| edge case | 対処するのが面倒なケースの総称。「edge」は「まあ普通は起きない」の変装。起きる | 変装 |
| minimal viable product | 「ここまでしか作れなかった」をポジティブに言い換えたもの。MVPは「間に合わなかった」の増幅 | 変装＋増幅 |
| over-engineering | 他人の丁寧な設計を批判するときに使う言葉。自分がやるときは「堅牢な設計」 | 変装 |
| not a bug, it's a feature | バグだ。しかし直す時間がない。ポエマイゼーションの極致。変装の頂点 | 変装 |
注目すべきは「legacy code」と「technical debt」だ。
「legacy code」は変装だ。「前任者が書いた汚いコード」を「遺産」（レガシー）と呼ぶ。しかし遺産は通常ポジティブな意味だ。英語の "legacy" には「遺産」と「旧式」の二重の意味がある。日本語のカタカナ「レガシー」に翻訳される過程で、「遺産」のポジティブさが蒸発し、「旧式で厄介なもの」だけが残る。ソノダのいう蒸発だ。しかし面白いことに、蒸発の方向が逆だ。通常の蒸発はポジティブな意味が残ってネガティブが消える。「レガシーコード」ではネガティブが残ってポジティブが消えている。逆蒸発。
「technical debt」は増幅だ。「手を抜いた」と言えばいいものを、「技術的負債」と言い換える。「負債」は金融用語だ。金融の権威を借りてきて、手抜きに知的な響きを与える。マンション広告が英語を借りてくるのと同じ構造——カタカナの代わりに金融用語を使った増幅だ。
「legacy code」は「築古物件」の変装。
「technical debt」は「手抜き」の増幅。
「self-documenting code」は「コメントなし」の変装。
プログラマーの語彙は、不動産広告と同じ修辞構造でできている。
ここまでコメント暗号辞典を並べてきた。プログラマーを責めているように見えるかもしれない。違う。
ソノダがDXポエム#6で書いたことを思い出してほしい。「ポエムは悪ではない」。マンション広告の「上質がそびえる」も、SaaS LPの「DXを加速する」も、それ自体が悪いわけではない。広告には広告の仕事がある。
コードのポエマイゼーションも同じだ。プログラマーが // TODO と書くのは、怠惰だからではない。構造的にそうなるのだ。
コードがポエム化する3つの構造的理由
tempVar は「本当は良い名前をつけたかったが時間がなかった」の痕跡だ。マンション広告のコピーライターも締め切りに追われている。ポエマイゼーションは時間不足の産物でもあるdata2 で通じる。半年後の自分や、後任者がそのコンテキストを持っていないことを、書いている瞬間には想像できない。マンションポエムも同じだ。コピーライターは物件の詳細を知っている。「上質がそびえる」で通じると思っている// TODO: fix this later の「later」は本気だ。書いた瞬間は。しかし人間は「後でやる」と書いたことの95%をやらない。これは個人の意志力の問題ではなく、認知バイアスだ。マンション広告の「近日公開予定」も、SaaSの「今後のアップデートで対応予定」も、同じバイアスの産物つまりコードのポエマイゼーションは、プログラマー個人の問題ではない。ソフトウェア開発という営み自体に組み込まれた構造だ。締め切りがあり、知識のギャップがあり、楽観バイアスがある限り、コードは必ずポエム化する。
ソノダのポエマイゼーション6操作が、コードの世界でどう現れるかをまとめる。
| 操作 | 広告の世界 | コードの世界 |
|---|---|---|
| 補填 | 弱みを言葉で埋める。「上質がそびえる」 | 中身が弱いものを名前で飾る。「Easy to use!」「Production ready」 |
| 翻訳 | 文化フィルターで表現が変形 | 英語圏の概念が開発現場でズレる。"agile"→「朝会やればアジャイル」 |
| 蒸発 | 翻訳で意味の一部が消える | コミットメッセージから意図が消える。fix stuff |
| 消去 | 都合の悪いものを消す | エラーの原因を書かない。テストの失敗を無視する。「No functional changes」 |
| 変装 | ネガティブをポジティブに着替えさせる | 「壊れている」→ FIXME。「汚い」→ HACK。「バグ」→「feature」 |
| 増幅 | カタカナで権威を増す | 「手抜き」→「テクニカルデット」。「とりあえず作った」→「MVP」 |
6操作すべてが、コードの世界にも存在する。これはソノダの理論の汎用性を示している。ポエマイゼーションは広告だけの現象ではない。事実を言葉で伝えるあらゆる場面で、ポエマイゼーションは起きうる。
しかしコードの世界には、広告にはない特殊事情がある。広告のポエムは読者に向けて書かれる。マンションポエムの読者はマンションの購入者だ。しかしコードのポエムの読者は——未来の自分だ。
マンションポエムは他人を騙す。
コードのポエムは自分を騙す。
半年後、// TODO: fix this later を読んで途方に暮れるのは、書いた本人だ。
プログラマーのポエマイゼーションは、自分自身への詐欺である。
ソノダがマンションポエムの「上質がそびえる」を笑ったように、プログラマーは // TODO: fix this later を笑っている。GitHubには // TODO がいくつある？ 数千万。数億。その一つひとつが、「永遠にfixしない」という変装だ。
しかしソノダがポエマイゼーションで書いたように、ポエムを分析するのはポエムを殺すためではない。// TODO を撲滅しろと言いたいわけではない。締め切りは来る。コンテキストは失われる。楽観バイアスは消えない。コードは必ずポエム化する。
大事なのは——ソノダの言葉を借りれば——ポエムとデータを区別することだ。
コードのポエマイゼーションに対する3つのルール
// TODO を見たら「いつ？」と問えutilsの中身を見ろ。tempVarの寿命を確認しろ。READMEの「Easy to use」を信じるな、チュートリアルを最後までやれ。ソノダの「実物を見に行け」と同じだfix stuffを読んで何がわかるか。何もわからない。半年後の自分は他人だ。他人に伝わらない言葉は、ポエムだソノダは全5シリーズ51本で、不動産広告から高校パンフ、SaaS LPまで分析してきた。俺はエンジニアとして、同じ6操作がコードの中にもあることを示した。
ポエマイゼーションの射程は、広告よりずっと広い。人間が言葉を使うところにはどこにでも、ポエマイゼーションが棲んでいる。コードの中にさえ。
// TODO: fix this later
——「later」は来ない。
しかしこの一行が、プログラマーの祈りであることを、
俺たちは知っている。