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