コードは読まれるより実行されることのほうが多い
(olano.dev)- 「コードは書かれるより読まれることのほうが多い」という原則は、作者より保守担当者を優先せよという考えから出発し、ユーザー・運用・ビジネスまで考慮する意思決定モデルへと拡張される
- コードの価値は精巧さそのものではなく、ユーザーの目的を満たしているかにかかっており、早い段階から頻繁にユーザーに見せ、フィードバックを反映する過程が重要である
- プロダクションでコードを「実行」するとは、デプロイ、アップグレード、観測、監査、モニタリング、修正、廃棄までを含み、長期運用コストは開発中の不便よりはるかに大きくなりうる
- KISSはコードの単純化にとどまらず、可動部分を減らし、故障モードを理解して、故障しても動作するようにする運用原則へと拡張される
- 予算、マーケティング、締め切り、利害関係者、投資家、政治的利害が意思決定に介入するため、ユーザーを喜ばせることと売上を生むことが常に一致するわけではないと認める必要がある
優先順位モデルの拡張
- 「コードは書かれるより読まれることのほうが多い」とは、最初にコードを書く人が、将来それを読んで修正する人のコストを無視してはならないという意味である
- この原則は、単純さ、テスト、文書化のような保守性への投資を正当化する根拠になる
- 要約すると、
maintainer > authorというモデルと見なせる
ユーザーは開発者より先にいる
- コードは目的のための手段であり、ソフトウェアは何らかのユーザーにサービスを提供しなければならない
- どれほどよく書かれたコードや精巧な技術であっても、目的を満たし、良いユーザー体験を提供できなければ価値は下がる
- 優先順位は
user > maintainer > authorへと拡張され、開発者の役割を区別しないならuser > devとなる - ユーザーが何を望んでいるかを推測したり尋ねたりするだけでなく、プログラムを早い段階から頻繁にユーザーの前に出し、フィードバックから学んだことを反映するほうがよい
実行にはプロダクション運用まで含まれる
- 「実行」とは単にプログラムを起動する行為ではなく、プロダクションで運用する全過程を含む
- デプロイ
- アップグレード
- 観測
- 監査
- モニタリング
- 修正
- 廃棄
- Dan McKinleyのChoose Boring Technologyでは、システムを安定して動かし続ける長期コストは、作っている間の不便さより、ほとんど常にはるかに大きいとされる
- この観点を入れると、モデルは
user > ops > devになる - 多くのソフトウェアは意味のある規模のプロダクションに到達できず、検証されていない仮定の上に作られている
- プロダクションでコードを運用すると、KISSはコードの次元を超えて、可動部分を減らし故障モードを理解する問題になる
- 重要なのは、何かをデプロイし、失敗したときでも動作することを保証することである
ビジネスは別の軸である
- ユーザーを意識して開発すれば遠くまで進めるが、「ユーザーに価値あるソフトウェアは組織にとっても価値がある」という前提は単純化された抽象化である
- 開発者の立場からは、良いソフトウェアを作り、ビジネスがそれをお金に変えると分けて考えやすいが、結局は作業の過程にビジネスの視点を含めなければならない時が来る
- この区別は、コンシューマーソフトウェアとエンタープライズソフトウェアでは概ね機能する
- モデルは
biz > user > ops > devへと拡張される - 予算は最も明確な例であり、ユーザー要求を満たすための資源は無限ではないため、コストと利益を測定しなければならない
- マーケティング、締め切り、利害関係者、投資家、個人的利害、政治も意思決定に影響する
- ソフトウェア、チーム、ユーザーだけを見れば正しい判断でも、組織全体を考えると正しくないことがある
- ときには、ユーザーを喜ばせることよりも売上を生むことを優先しなければならない
モデルで見る開発組織の臭い
-
保守不能なコード:
author > maintainer- 賢いが怠惰なコードは、スパゲッティや「幽霊の森」になる
- 早すぎる最適化、特定の人しか触れないモジュールのような問題が含まれる
-
使えないソフトウェア:
dev > user- ユーザーから学ばないチームや技術を優先するチームから生まれる
- 過剰設計されたプログラム、ユーザー体験を悪化させる「モダナイゼーション」、ブラウザ機能を壊すWebアプリが例である
-
「自分のマシンでは動くのに」:
dev > ops- 運用を念頭に置いて設計されていないソフトウェアである
- 小さなデータ負荷に派手なデータベースを使ったり、小さな1チームがマイクロサービスの生態系を運用したりするような過剰な複雑性が含まれる
- 障害が起きると真夜中に起こされる人と、それを設計した人が別であるソフトウェアもここに当てはまる
-
「正しいこと」:
dev > biz- コードをそれ自体が目的であるかのように扱うケースである
- 気取り屋の職人、タイタニックの音楽家、Lisp Hackersが例として挙げられる
-
履歴書主導開発:
dev > *- 失うものがなく、開発者が望むままにできるときに作られるソフトウェアである
-
想像上のソフトウェア:
biz > user > ops > dev- 作られたものの、ほとんどまたはまったくプロダクションに行かないソフトウェアである
- Charity Majorsはこれをliving a lieと呼ぶ
- ユーザーのいないソフトウェアも想像上のソフトウェアに当たり、問題を解いていない、間違った問題を解いている、あるいは誰も抱えたことのない問題を解いている場合がある
- 大げさな技術を持ち出して何にでも振り回し、ぼんやりしたユースケースのようなものが出てくる場合も含まれる
-
「後期資本主義」
- ベンチャー投資ベースのソフトウェアがビジネスモデルを持たないか、独占にまで成長した後でユーザーを搾取するビジネスモデルを持つケースである
ユーザーとビジネスの緊張
biz > userは受け入れがたい波及効果を持つ- ソフトウェアを学んだやり方は最終ユーザーの問題を解くことにあり、The Pragmatic Programmerの最後の助言の一つは、単にコードを納品するのではなく、ユーザーを喜ばせよという目標に要約される
- ソフトウェアが普及するにつれて、この前提を維持することはますます難しくなっている
- 多くのソフトウェアはユーザーを気にかけず、操作し、あるいはユーザーを製品にしてしまう
- この問題はソーシャルメディアに限られない
- 宿泊予約、料理の注文、Windowsのスタートボタンのクリックでも、ユーザーの注意を引こうとするポップアップが現れる
- Google検索では、ゴミの山のような結果が返ってくると表現される
- 良いことをしていると信じていたことと、業界のかなりの部分が収益性があると見なしていることとの不一致が、多くのソフトウェア専門家の居心地の悪さを説明している
- 経済的現実を無視していた過去に戻ることはできないが、ユーザーに害を与えないための、より強い倫理的態度が必要である
- ユーザーが常にビジネスより先に来られるわけではないが、ビジネスも無条件に先に来るべきではない
user > ops > devbiz > ops > devbiz ≹ user
1件のコメント
Hacker Newsの意見
あるユーザーは、そのシステムが好きで使っているのではなく、会社が購入したから使っている場合がある。
このような状況では、定義上ビジネスがユーザーより優先され、開発者は実際のユーザーではなく顧客企業の中間管理職の要求に合わせることになる。そうしないと契約を取れないからだ。結局ユーザーは、開発チームが中間管理職に受けそうな新機能を作るのに忙しい間、適当に提供された機能に縛られることになる。
少しシニカルではあるが、エンジニアとして自分が根本的にそういう種類の会社にいるのかを知るのは役に立つ。たとえばオンライン小売業者はユーザーに非常に敏感で、ドイツ人はXを好み、米国人はYを好むという理由で、国ごとにWebサイトのバージョンを変えることもある。小さな変更が売上に大きな差を生むからだ。
一方で、製品を買う人が実際のユーザーではないため、ユーザビリティにほとんど敏感でない会社もある。
契約を取るには顧客企業のチェックリストを満たす必要があったが、ユーザー体験にも気を配っていた。優れたユーザー体験が顧客の厳格な要件であることは、ほとんどなかった。
競合ソフトウェアは使うのが非常につらかったので、その部分で差別化したかったし、そのおかげでトレーニングが楽になり、ユーザーの満足度も高まり、可能な場合には自分の上司に私たちの製品をもっと買うよう勧めてくれることもあった。
結局のところ80%は「私たちのソフトウェアはひどくない」という誇りと共感から出たものだったが、長期的にはブランドが築かれるという点で、私たちの利益にもなっていた。
プロダクト主導の成長戦略を採っていたため営業担当者がおらず、プロダクトチームは完全にユーザー体験に集中していた。問題は、私たちがユーザーに売っていたわけではないという点だった。ソフトウェアを購入する人たちはユーザー組織内の別の人々で、実際の製品を直接使った経験もなかった。
失敗するしかないアプローチだった。購買者の頭の中を理解し、彼らに利点を説明し、ユーザーが組織内の他の人たちに利点を説明できるようコーチする営業担当者が必要だった。ユーザーと購買者の間のギャップを埋める必要があった。
そのため、どのユーザーを優先するかの問題になり、他のユーザーに影響力を持つ少数派の体験を優先することと、残りのユーザーが経営層に意味のあるデータを提供できる程度には製品を使い続けられるようにすることの間で、バランスを取る必要がある。
重要なのは市長、タウンマネージャー、市議会の意見だけだった。レポートの見栄えがよく、価格が合えば更新していた。
現場の会議で、毎日使っている人たちが私たちの面前で、どれほどひどいかを語っていた場面を覚えている。それでも例外なく、いくつかの特定のバグを直すという約束と最小限の値上げで、その顧客は更新した。
今日、≹ という記号を知った。「比較される2つの対象のどちらも他方より大きくも小さくもないが、必ずしも等しいとも言えない関係を表す。厳密に数値的ではない比較方法がある領域で重要な微妙な区別」だという（https://www.mathematics-monster.com/symbols/Neither-Greater-...）
むしろ |z_1| = |z_2|、つまり2つの複素数が同じ絶対値を持つと書くほうが明確に見える。
「結論として、≹ 記号は従来の関係演算子の間の中間地帯を提供するうえで重要な役割を果たす」とあるが、数学の博士課程学生として一度も見たことがない。重要な役割を果たしているとは信じがたい。
ゲームは超現実数の上位集合で、超現実数は実数の上位集合だが、超現実数の定義をゆるめて全順序性を失わせたものだ。
そのため、他の数と「混同されうる」または「ファジーな」奇妙な数が生じる。最も単純な例は （star）で、0より大きくも小さくもないため0と混同される。0の周囲にあるファジーな雲のようなもので、0║ と表記する。
より複雑なゲームであるスイッチは、より大きな数の区間と混同されうるし、「熱い」と見なされる。スイッチで数を作ると、より興味深い熱いゲームを作れる。
単一のデバイスで生成されたイベントには、常に完全な順序がある。しかしオフライン状態の2つのデバイスでイベントを生成すると、どちらが先かは言えず、2つのイベントの間に ≹ 関係が生じる。言い換えれば、イベントが同時的だと見なすということだ。
そのため「d > b > a」と「d > c > a」という順序が生じうるが、「c ≹ b」となる。
このような場合の同順位処理を決定的に行う方法を定義することが、CRDTが解決する問題の大きな部分だ。
そんなことがどうして可能なのか？
私たちのかなり多くにとって、コードを10億回実行するコストは、開発者の数分の時間より安く済むことがある
AWS で月にサーバー費用として 200 ドル使えば、自分の Web API コードのかなりの部分を 1000 億回でも実行できる
だから人間の読者のための最適化が常により良く、経済的に耐えられないほど遅いことが証明された場合にだけ、別の最適化をすればよい
記事は次の式で終わっている:
user > ops > dev
biz > ops > dev
biz ≹ user
結論は、コードはエンドユーザーとビジネスのために存在する、ということに近く見える。最後の式である ≹ は、エンドユーザーとビジネスの要求は同じではないが、コードの存在にとってはどちらも同じくらい重要だという点をうまく表している
ユーザーは、より高い電気代、縮んだ寿命[0]、失われた機会、より大きなフラストレーション、より頻繁なハードウェア更新といった、見えにくい形でコストを払っている
しかもほとんどのユーザーは開発者の年収や生活の質を持っていないので、被害は何倍にも大きく感じられる
[0] 他人の時間を浪費することは QALY を減らすことだ
本番環境で運用すること、つまりデプロイ、アップグレード、観察、監査、モニタリング、修正、廃棄などをすべて含むという
タイトルの帰結を筆者に返して言うなら、「コードは書かれるより多く読まれる」ではなく、読めないコードは長く実行され続けられないに近い
ただし、私は開発に横移動しようとしている熟練のシステム管理者で、その意味では完全な初心者だ
より正確には、「読めないコードは長く修正可能な状態ではいられない」に近い
意図的な難読化を扱っているのでなければ、ほとんどのコードは努力する気のある人なら読めるし、必要ならコードフォーマッタもある
ここに付け加えたい帰結がある。次の各段階の間では、使用回数が指数関数的に増加する
多くの言語では各段階の比率はおおよそ 1000 倍程度なので、言語設計者 1 人につき、モジュールを設計して配布する人が 1000 人、開発者が 100 万人、ユーザーが 10 億人いることもあり得る。具体的な状況によって数字は大きく変わるが、定性的な議論にはおおよその規模感として合っている
要点は、1 段階目や 2 段階目でのごく小さな怠慢が、下流で劇的に増幅されるということだ。1 段階目で「自分の都合」のために 1 分を節約しようとして作った汚いハックが、他人の貴重な人生から文字どおり何百万時間も浪費させることがある。遅いソフトウェアを待たせたり、クラッシュで苛立たせたり、2・3 段階目で機能開発が遅れて待たせたりするからだ
最初の 2 段階で必要な品質水準を維持するには、途方もない自己規律と個人倫理が必要だ。逆に、コア言語や標準ライブラリ設計に関して正当化できない立場を擁護する話を聞くたび、深く悲しくなる
「この鋭い角が生まれた歴史全体さえ知っていれば大丈夫だ！ 永遠に警戒していれば問題ではない。誤って使わなければ、安全でないわけでも、セキュリティ上危険なわけでも、遅いわけでも、問題があるわけでもない」といった言葉をよく聞くが、それらが今後何十年にもわたって開発者をつまずかせ、何百万・何十億人ものソフトウェアを遅くすることが分かっているからだ
筆者はかなり良い経験則を持ち出して、万物の理論を作ろうとしているようだ
すっきりして賢明に見えるが、無理のある表現を除けば、広く知られたありきたりな話を蒸し返しているのに近い
そのため表現がぎこちなくなることがある
そして「広く知られたありきたりな話」だとしても、この記事はそれらを特に一貫した形でうまく結び付けており、有用な参考資料になっている
誰かにとってはすべてが新しく、私にとっては自分の偏見を確認しただけだったとしても、興味深い視点だった
筆者のフレーミングは、あまりに多くの形で誤解され得るため、有用な短縮表現にはなりにくい。これらのトークンの間に絶対的な順位はあり得ない
まず、ここでいう「dev」は1人の人物ではなく、複数の組織のプロダクト、エンジニアリング、デザイン部門にまたがる、さまざまな専門性と経験年数を持つ人々の集合である
「ops」も単一のものではなく、エンジニアリング運用だけを意味しない。事業運営、カスタマーサポートなども含まれ得る
「biz」も同様に単一ではない。ブランディング、マーケティング、営業、法務、経営陣、取締役会、規制当局、融資機関、投資家などがある
こうした全員が、どのようなコードが書かれ、どのように書かれ、いつどのようにユーザーへ配布されるかに影響を与える。全員が同じ問題を解かなければならない
組織内の多くの人々は、全員が同じ問題を理解し、同じものを見て、同じ目標に向かって働けるようにするために存在していることが多い
しかしその理解は絶えず進化し、組織全体へ伝播するには遅延がある。そのため、目標自体が変わっている最中に、全員が同じ目標に向かって働くことにも遅延が生じる
最後に、「user」も単一ではなく、どのユーザー集団も静的ではない。さまざまなユーザー集団があり、その行動は長期的に安定しているとは限らない
だからこそ、周囲のあらゆる変数がどのように変化しているのかを理解し、認めたうえで、その文脈の中で不完全で壊れた世界を解釈することが役に立つ。そうでなければ、他の全員がひどく、すべてが壊れているのだから、全部を最初から作り直したい、という方向に陥りやすい
倫理に近い内容が議論されているのを見てうれしい
本文の「私たちが良いことをしていると思っていたことと、業界のかなりの部分が収益性があると見なすことの間に不一致があり、これが多くのソフトウェア専門家の不快感が高まっている理由だと思う」という箇所で、不快感というのはかなり控えめな表現だ。多くのことが語られないまま残っている
いくつか質問を付け加えたい。ユーザーが顧客、つまりお金を払う人ではない場合はどうなるのか。ビジネスは、お金を払わないユーザーを含め、すべてのユーザーに対して倫理的義務を負うのか。有料顧客が、ユーザーに負の下流効果を生む形であなたのビジネスを使おうとしたらどうなるのか
たとえば、プラットフォームが既存の代替手段よりも詐欺を容易にしたり、偽情報を広めやすくしたり、ユーザーの意見を長期的には破壊的だが魅力的で習慣形成的な形に shaping しやすくしたりするとしたらどうだろうか。これらはすべて、一定期間にわたって成功したビジネスモデルであることが証明されてきた
こうした力学が現実なら、ビジネスはそのような搾取的モデルを追求すべきなのか。追求するなら、より責任ある形でできるのか。より倫理的なバージョンのビジネスは、競合他社の最悪の傾向を緩和できるのか、それとも結局は問題の一部になるのか
核心となる結論は明らかだ。ある種の問題は、ビジネスモデルよりも大きく重要である。「企業をある程度の常識の範囲内で機能させるには、どのような規範とルールが必要か」として構成できる問題がある
最後に明確にしておきたい。ビジネスは本質的に一連の価値を伝えるものであり、これは避けられない。「人気が勝つ」という立場だけを取ったとしても、それ自体が価値に深い含意を持つ選択である。政治学者や歴史学者は、多数派の専制という問題を昔から知っていた。政治哲学が何であれ、考えるべき点だ
「最善」の倫理体系が何なのかは分からないが、ある倫理が別の倫理より優れていることは分かる。そして、私たちが倫理を検討しないまま放置するのではなく、継続的に磨いていくことを望む
どの問題や領域が自分の倫理に合うかは選択できる。この記事は、システムをどう作り、作業の優先順位をどう決めるかについての話である
ビジネスは実際に存在するものではなく、リソースを組織して一緒に働くために私たちが作り出した想像上の構成物である
ビジネスが何よりも重要なわけではない。ユーザーは複数いて、ときには利害が衝突する。どこにでも存在できるわけでも、すべてになれるわけでもないので、優先順位を決めなければならない。より収益性の高いユーザーや長期戦略に合うユーザーを追求することが「ビジネスに良い」ように見えるかもしれないが、実際の目標はユーザーに奉仕することだ。ただ、そこに至るまでにいくつかの段階を挟むだけである
社内政治がこじれて、ユーザーの幸福にどうつながるかを考えず、ビジネスの利益だけのために意思決定するところまで行くと、その組織は有害になっている。もはや存在すべきではない。しばらくはゾンビ状態でよろめきながら進めるかもしれないが、下降線にあり、優秀な人はみな去っていくだろう
感情も状況への反応を説明するために作られた構成物にすぎないと言うことはできるが、原子でできていないからといって「実在」しないわけではない
ビジネスは、多くの人の人生を決定づける主な要因であるという意味で存在している。都市、メディア、法律、政治、外交政策を形作り、ほぼすべての重要なものに大きな影響を及ぼす。実在するかどうかにかかわらず、私たちの周囲に実質的な影響を与えている
オープンソースの外では、金を払う主体が、作られるもののあり方を決めるという点はかなり明らかだ。その決定がその主体にとって悪く、ユーザーにとって悪く、一般大衆や環境にとって悪いとしてもである。もちろん産業や政府の規制はあるが、概して企業が決定権を持っている
残念ながら、ビジネスは所有者に奉仕するために存在している。ほとんどの場合、特に従業員5人未満の零細事業ではない大企業では、所有者が金を求めているため、会社の全員は所有者により多くの金を稼がせるために存在している。他人の幸福、ユーザーの幸福でさえ、売上と相関がある場合を除けば、まったく関係がない
会社内のもう一つの普遍的な誘因は自己保存だ。したがって意思決定者は、金を稼ぐことに加えて、自分の雇用の安全性も考慮する
従業員は辞めない。会社が十分に満足させるからだ。給料をよく払い、「共同体」の一員であるかのように感じさせることで、悪辣だったり顔の見えない組織で人を働き続けさせるのは驚くほど簡単だ。FAANGのオフィスを見れば、こうした人事上のトリックの詳しい一覧が見られる
こうした会社が有害で、存在すべきではないという点には同意するが、実際には会社はこのように機能している。これは衰退の兆候ではなく、何十年も続き得る成熟した健全なビジネスの姿だ。役員も製品も所有者も変わるが、ビジネスは残る
しかし重要性は主観的だ。自分の楽しみのための個人コードなら、ビジネスは重要ではない。それを主な収入源に変えたいなら、ビジネスが最も重要になる。ソフトウェアが誰にも奉仕できなければ、どれほどユーザーが気に入っていても実際の売上には変わらないからだ
ビジネスモデルがなければ、ユーザーに好まれ、配布可能で、保守可能な優れたソフトウェアであっても、しぼんでしまう可能性がある
最初は懐疑的だったが、この思考モデルは気に入っている
もちろん盲目的に従うべきではない。dev > biz となる例外もあり、OpenAIの騒動がそれに当たるし、dev > ops となる例外もある。初期のスタートアップでは素早く動く必要があるため、とりわけビジネス上の理由で dev > ops になり得る