ユーザーは気にしない――だが、あなたは気にするべきだ
(lewiscampbell.tech)- ユーザーはコードそのものの内在的な性質よりも製品が動くことを重視するが、悪いコードは性能・バグ・開発速度に直接的な下流影響を及ぼす
- 「ユーザーは技術スタックやテストを気にしない」という言い方は表面的には正しくても、コード品質が低いほどバグ修正や機能追加はより難しく、より遅くなる
- 橋の点検、酔った操縦士、不安定な建物の基礎のたとえのように、ユーザーが工程そのものを見ていなくても、その結果は安全性と信頼に影響する
- こうした通念が人気を保つ背景には、自分がうまくできないことを過小評価しようとする自我防衛機制が働いている可能性がある
- 真剣なソフトウェアの仕事はさまざまな関心事と視点の混合であり、そのすべてが成否に寄与するため、コード品質を軽視してはならない
繰り返されるクリシェとその限界
- ソフトウェア業界では
- 「顧客はテストを気にせず、製品が動くかどうかだけを気にする」
- 「ユーザーは技術スタックを気にしない」
- 「工学的な優雅さは市場価値と同じではない」
- 「ユーザーはAIが書いたか人間が書いたか、あるいはどのフレームワークを使ったかは気にせず、製品が動くことだけを気にする」
といった言葉が繰り返される
- こうした言葉はすべて「顧客はそれを気にしない」という同じテーマの変形である
- あたかも熟練した実用主義者が、理想主義的または近視眼的な人々に世の冷徹な真実を教えているかのような態度を取る
- しかし、これはすべてたわごと(horseshit)であり、
同じ論理を別の分野に適用すると穴が見えてくる- 道路利用者は橋が最終点検を受けたかどうかを気にしない、車を支えてくれるかだけを気にする
- 乗客は操縦士が酒に酔っているかを気にしない、飛行機が定刻に到着するかだけを気にする
- オフィスワーカーは高層ビルの基礎が安定しているかを気にしない、金を稼ぐことだけを気にする
- こうした比喩は表面的には正しいが、明白な**下流影響(downstream effect)**を無視している
無視される下流影響
- 顧客がコンピュータコードの内在的性質に関心を持たないという点は正しいが、
コード品質は性能、バグの有無、バグ修正にかかる時間、機能追加にかかる時間に影響する - コードが悪いほど、こうした問題を解決するのはより難しく、より遅くなる
- AirBnB、OpenAI、Metaのような企業は、圧倒的な市場支配力、莫大なVC支援、疑わしい合法性によってこうした懸念を押し切ることができる
しかし、そのような企業でなければ同じやり方で問題を覆い隠すのは難しい
『Folk Wisdom』の持続性とソフトウェアにおける複数の関心事
-
通念のしぶとい生命力 (The Persistence of Folk Wisdom)
- 一次効果だけが重要だと見る考え方は、ソフトウェアの世界で非常に人気のある民間通念として定着している
- 人は自分が得意でないことを割り引いたり、矮小化したりする傾向がある
- 良いコードを書く能力が足りないと認識すると、良いコードは重要でないだけでなく、良いコードを書ける人々のほうがむしろ問題だという見方を取りやすい
- その見方では、顧客が気にしないことを理由にリリースを止める人たちが問題として扱われる
- この態度は、自分の弱点を避け、他人に責任を転嫁するための**自我防衛機制(ego defence mechanism)**として機能する
-
私たちは社会の中で生きている (We Live in a Society)
- 真剣なソフトウェアの仕事は、異なる関心事と異なる視点の混合物である
- 技術営業(tech sales)から技術スタック(tech stack)まで、ユーザー体験(UX)から一意識別子(unique identifiers)まで、さまざまな要素がソフトウェアの取り組みに含まれる
- これらすべての要素が成功または失敗に寄与する
1件のコメント
Lobste.rs の意見
こういう文句は、伝え方も受け取り方も良くも悪くもなりうる
たとえば「顧客はテスト自体にはまったく関心がない。製品が動くかどうかに関心がある」という言葉は、「バグを出荷しろ」ではなく、特定の テストのイデオロギー よりも 製品が実際に動くこと に集中しろ、という意味にも読める
テストはコードを動かすための手段のひとつなので、テストカバレッジが高くて全部通っていても製品が動かなければ失敗だし、テスト以外の方法で製品をうまく動かせるならそれでもよいし、形式的な教義に従わなくてもバグをうまく見つけられるならそれでもよい、というふうに解釈できる
また、ユーザーやビジネスの観点では「製品／機能が存在しないこと」もバグになりうるので、既存バグの修正と機能のリリースが常にきれいに分離されるわけでもない
ただ実際には、こういう文句が「手を抜いてゴミを出荷しろ」という意味で使われることもあるのを聞いたことがある
ひどいプログラミング が数か月単位で見ても「実用的」だという考えは完全に退ける
設計が悪くテストも不足したコードベースで新機能を作るのは遅くて高くつく
開発者は 価値が生まれるところに時間を使っているか を意識すべきで、経営陣もなぜそうした作業をしているのか理解しているのが理想的
理解不足と誤ったインセンティブ構造が合わさると、結局は「手を抜いてゴミを出荷する」ことになる
正直、こういうことを言う人は、ユーザーのこともあまり気にしていない人に見えることが多い
ユーザーにちゃんと動く製品を届けるには、その可能性を高める仕組みが開発プロセスの中に必要だという点は、すでに 数日前のコメント でも述べた
こうした情緒は、ユーザーが製品について適切にフィードバックする手段もなく、実際の 利用指標 もない状況でよく現れる
ユーザーが今すぐ見たり気にしたりしなくても、影響を受ける失敗シナリオは多い
典型例としてセキュリティでは、データがオンライン流出リストに載るまではユーザーが「安全ではない」ことを気にしないかもしれないし、性能も、もっと良くできると知るまでは問題だと感じないかもしれない
改善プロセスはどんなものであれ、ひとつの要素だけを選んで最適化して良い結果を得るのは難しいが、議論を前に進めるにはしばしばそうせざるをえない
だから実際に 目に見える問題 がどこにあるのかに合わせてフィードバック経路を調整し、議論を補正していくのが役に立つ
こういう文章は、ソフトウェアプロジェクトの成功に影響する一方で相互に排他的に見える要素を思い起こさせようとする試みだと思う
技術的な勘のある人たちだけが知っていることを言語化して擁護するのには価値があるが、多くの技術者は 見えない作業 のバランスを取ったり、その重要性を効果的に説得したりするのがあまり得意ではないようで、私自身もその点は練習中だ
内部を気にかけることは重要で、実際にユーザーの利益にもなる
この見方は気に入っている
反対側の極端である 過剰エンジニアリング に行きたいわけではないが、「速く動いて壊せ」という考え方からは抜け出してほしい
経験上、Web開発の世界ではほとんど伝染病のようだ
LLM が可能にした低品質ソフトウェアの流入が、むしろユーザーが信頼できるソフトウェアに報いる方向へ働いてくれればいいと思う
だんだん grug brain 開発者になってきているので、これが広く共有された感覚なのかは分からないが、「機能をもうひとつ追加しよう」にはうんざりしている
私たちはソフトウェアのコストを リリース日 だけで測るという誤りをよく犯し、その寿命のあいだに発生する保守コストをほとんど含めていない
「難しくないですよ、1週間もかかりません！」と言いながら、毎年 2〜4 週間ずつ保守、修正、拡張、更新、統合、文書化にかかる時間については語らない
似たような趣旨のことをよく言う
「エンドユーザーは、ソフトウェアが テストカバレッジ100% かどうかや、
lbl0のようなラベルが付いた文書化されていないアセンブリで 100% 書かれているかどうかは気にしない。正確さ、性能、ユーザー体験を気にする」ただし、ソフトウェアエンジニアリングはまさにそうした目標により簡単に到達し、品質を良い水準に保つ助けになる
問題は、この道もまたカーゴカルトや過剰エンジニアリングにつながりうることで、私にも間違いなくその罪はある
それでも最終的には、ユーザーに実際の価値を届けなければならない
Boeing や Airbus のように、証明可能な最適結果が存在する
なぜ両社の機体があれほど似て見えるのか、誰が先に設計して誰が盗んだのかは本質ではない
誰も盗んでおらず、別々のチームの世界最高クラスのエンジニアたちが同じ制約の中で設計した結果、そこから外れる設計は定義上劣ったものになる
パレート・フロンティア の上にいなければならず、そうでなければ食われる
私たちの分野にもどこかに最適点は存在し、問題はそこに到達するための道具、予算、適切な人材があるかどうか、そして実際にそこへ到達したかを見極められるだけの十分なユーザーがいるかどうかだ