ソフトウェア企業の視点で見る

230日前原文(seangoedecke.com)

概要

James C. Scott の『Seeing Like A State』の要点は、 可視性（legibility） の追求が組織運営にどのように影響するかという議論
可視的な仕事 と 不可視的な仕事 の両方が組織に不可欠であることの指摘
可視性の向上 は効率低下を招く場合があるが、他の利益のために組織はそれを選択しがち
ソフトウェア企業における 可視性と不可視性 のバランスの重要性
大企業と小企業の運営手法や意思決定の違いの背景説明

『Seeing Like A State』の本質

近代組織 は「可視性（legibility）」を最大化することで管理や統制を強化
可視性 とは、全ての作業や資産を測定・報告・計画可能にする仕組み
不可視的な仕事 （例：暗黙知、非公式な協力関係、臨機応変な対応）は追跡や計画が困難だが、組織運営に不可欠
可視性追求 は一見効率的に見えるが、実際にはシステム全体の効率や柔軟性を損なうことも多い
それでも 可視性の利点 （計画性・取引・腐敗防止など）が大きいため、組織は推進し続ける傾向

可視性の事例：ドイツの森林管理

19世紀ドイツでの「高モダニズム」的森林管理が典型例
単一種・整然とした植林 で木材管理の可視性を確保
その結果、 生態系の多様性喪失 や 病害虫リスク増大 など非効率が発生
旧来の「不可視的」な多様な森林の方が実は生産性が高かった
それでも 計画性・管理性の向上 を優先し、可視性を追求

ソフトウェア企業における可視性と不可視性

小規模なソフトウェア企業は 不可視的な作業 が多く、柔軟かつ高効率
大規模企業は 可視性の高いプロセス （OKR、Jira、四半期計画など）を重視
エンジニア主導の仕事 は迅速だが、組織全体での管理・説明・計画が困難
大企業のプロセス は効率を下げるが、可視性によって組織間・顧客間の信頼や大規模取引を可能に

なぜ大企業は可視性を重視するのか

部門長 が「誰が何をしているか」「過去の成果」「今後の計画」を把握可能
緊急時に リソースを一斉投入 できる体制
高品質なソフトウェア開発 や 顧客満足 は可視性とは別の要素
エンタープライズ顧客 は長期的な約束や透明性を重視し、可視性の高い企業を好む
可視性の低い企業 は大規模取引や長期契約で信頼を得にくい

可視性に基づく前提とその問題点

エンジニアの能力均一性 や 人員の流動性、 見積もりの正確性 など、組織の可視性確保のための単純化
実際には 個々の能力差 や プロジェクトごとの適性 が大きい
見積もり はしばしば形式的で、実態と乖離
これらの前提は可視性を高めるための「方便」として機能

一時的な不可視性の許容ゾーン

緊急事態や特別な課題対応のため、 「タイガーチーム」や「バーチャルチーム」 を編成
選抜エンジニア が裁量を持ち、通常のプロセスを無視して迅速に対応
完全な可視性 と 完全な不可視性 の間の現実的な妥協策
こうしたチームの存在は、他のエンジニアからの不満や組織内の摩擦を生むことも

まとめ

可視性（legibility） と 不可視性（illegibility） は組織運営の両輪
大企業 は取引や管理のために可視性を優先
小企業 や現場の即応性には不可視的な柔軟性が不可欠
両者のバランス をどう取るかが、組織の持続的成長や競争力のカギ

Hackerたちの意見

なぜ大手ソフトウェア会社にとってこれらの能力がそんなに価値があるのか、小さなソフトウェア会社はそれなしでもやっていけるのに？専門外の話になるけど、主な理由は大規模な企業契約だと思う。これが専門の人、コメントしてくれない？

└

その一文、他の部分に比べて妙に具体的で単純化されてるなって思った。記事全体は結構広く真実味があったのに。中規模の会社で中間管理職をやってる自分の意見としては、会社が成長するにつれて、みんなが自分の仕事をどうやってやるかを知るために、ある程度の構造は必要だと思う。軽いものから重いものまで、いろんなデザインができるけど、ダンバーの数を超えると、常識や非公式なコミュニケーションだけじゃやっていけない。もし本当に「プロセス」が嫌いなら、かなり自由にやれるけど、Steamみたいな例があるけど、そこでも特定の性格タイプにフィルターがかかってて、仲間外れになると政治が厳しいこともあるよね。

└

私は企業プロジェクトを専門とする小さなソフトウェア会社の共同創業者だけど、この意見には賛同できないな。ただ、記事の他の部分は真実だと思う。企業はプロジェクトレベルでの可読性が必要だけど、それが契約した会社の内部での可読性に必ずしもつながるわけじゃない。特定の内部開発プロセスを要求せずに企業契約を提供することもできるし、特定の機能を優先することを約束するだけでいい。顧客向けのプロジェクト管理レベルでは可読性が必要だけど、開発者がどのように仕事をするかを細かく指示する必要はないと思う。私にとっての本当の説明はシンプルで、大手ソフトウェア会社は企業としての可読性が必要だから、または企業になろうとしているからだと思う。

└

大きな組織では、年に何回も内部監査や外部監査を受ける覚悟が必要だよ。監査人はプロセス文書を見たがるから、たくさんあればあるほどいい。最悪なのは、監査人が顧客として「解雇」することだよ。例えば、https://apnews.com/article/super-micro-computer-stock-audito...

└

企業間の取引じゃないと思う。内部のコミュニケーションが大事だと思うよ。m人の従業員がいる会社を、コミュニケーションのスロットの巨大なm*mマトリックスとして想像してみて。1は密接なコミュニケーション、0は全くコミュニケーションなし、0.5はCEOが言うところの「RTOが重要な理由」っていう廊下での会議。小さな会社（ダンバーの数以下だと仮定して）は、ほぼ全て1のマトリックスを自然に持ってる。でも会社が成長するにつれて、そのマトリックスはどんどんスパースになっていく。Googleみたいに180,000人以上の従業員がいると、ほぼ全て0で、散発的に1があるだけ。情報は依然として会社を通じて流れなきゃいけない。例えば、「これを作って、あれはダメ」とか、「このプロジェクトはクソで、終わらせるべき」とか、「グループDigutがあなたが直面している問題を解決したから、彼らが書いたこのパッケージを使って」とか、「従業員24601は素晴らしいから、もっと責任を持たせるべき」とか。これらの情報は実際には会社にとって非常に重要で、重要な意味ではその全てが会社そのものなんだ。だから、企業はその情報の流れの責任をマネージャーに正式に定めて、情報が流れるプロセスを整備して、何かが起こるようにしている。それが計画プロセスや昇進パケットの目的なんだ。情報の流れを明確にしようとしているんだよ。特定の人が特定の方法で責任を持つように。

└

私の専門分野ではないけど、推測してみるよ。大企業間の取引ではないと思う。ちょっとランダムすぎて狭い考えだよね。大きなソフトウェア会社は市場でのポジション（市場シェア）をもっと気にしてる。結局のところ、ビジネスはお金を入れて、いろんな市場からお金を引き出すお金の機械を作ることなんだ。開発作業を市場シェアにどう影響するかに結びつけたいなら、可読性が必要だよ。でも、必要なのは可読性だけじゃなくて、正確な将来の市場シェア予測で、それには特に戦略的な形の可読性が求められる。運に頼らず市場シェアを増やす唯一の方法は、自分の行動が市場シェアにどう影響するかを正確に予測すること。だけど、開発者が何を作って出荷しているのか全くわからなかったら、どうやってそれを予測できるの？無能なビジネスパーソンを笑うことが多いけど、実際に有能な人たちはこういうことをやってるんだよ。将来の収益を超正確に予測して、開発者に市場シェアを獲得するのに役立つものを作らせる。開発者はビジネス戦略についてあまり考えないことが多い（元の記事がその証拠だし、悪気はないけど）。だから、彼らは通常、自分たちのやっていることを市場シェア獲得に結びつけるのが苦手なんだ。アプリの市場のオーディエンスである開発者は、PMFや0から1に進むのが自然に得意だけど、スケールアップすると、自分たちが作っている製品の市場オーディエンスでもある開発者を見つけるのがとても難しくなるから、彼らは自分たちの開発ロードマップが市場シェア獲得にどう影響するかを予測するのが苦手になる。可読性がないと、開発者のチームはスロットマシンみたいになって、レバーを引いて機能がジャックポットに当たることを願ったり、せめて控えめなリターンが得られることを期待したりする。小さな賭けで、それは大きくなる素晴らしい方法だけど、競争の激しい大企業を運営する方法ではないよ。

└

医療画像の分野でかなりの時間を過ごしてきたけど…ほとんどのビジネスオーナーは、自分たちがITサービスやソリューションの分野にいるってことを理解してなかったんだよね。成功した理由は、診断部分だけじゃなくて、放射線科医じゃない人たちが作ったITサービスやプラットフォームが、放射線科医がもっと効果的に働くために何を求めているかを学ぼうとしていたからなんだ。

企業で働いて、オフィスの政治を学べば学ぶほど、地政学や外交と似てるなって思う。目を細めると、社会的な関係や恋愛関係にも似てる部分が見えるかも。抽象的なモデルを作るのが好きな数学者の自分がいるのかもね。

└

人間って、何にでもパターンを作るのが好きだよね。

└

グループが大きくなるほど、洗練された特性が失われていく。怖いよね！

└

それって自然じゃないの？社会的なことと恋愛のことはあまり関係ないと思うけど、大きな企業や政府は確かに同じような問題を抱えてるよね。企業はもっと独裁的な傾向がある気がする。封建的って言った方がいいかも？違いはたくさんあるけど、企業が大きくなるほど政府っぽくなる気がする。少なくとも、私にはそう見える。どっちもすごく官僚的だしね。

└

https://en.wikipedia.org/wiki/Game_theory

└

私の好きなテーマの一つは政治だよ。政治についての本を読むのが好きだし、（地政学的な）政治にも興味がある。政治雑誌を購読して、オフィスの人間関係も気にしない。結局、根本的には同じことだから。人間が人間らしく行動してるだけだしね。どんな人（や組織）にも欲望や恐れがある。二つの当事者が集まると、みんなの欲求をバランスさせるのが楽しい。複雑な工学の問題みたいだけど、代わりに人間の要件があって、政治がその設計図みたいなもの。人間って素晴らしいし、こういう問題を楽しむのが本当に好きなんだ。

└

最近やっと気づいたんだけど、地政学を複雑なシステムの中で数百人の外交官が織りなす緻密な行動だと思ってた。でも実際は、権力を持つ数人の国のリーダーたちの人間関係に過ぎなかったんだよね。これは、幼稚園の遊び場のドラマや小競り合いと大差ない、って言えるかも。

└

現代の政治家が日常のオフィス仕事から出てくることが多くなってるから、あまり驚きではないね。

これはずっとバランスを取ることだった。25年間エンジニアリングマネージャーをやってて、そのバランスに悩まされた。プロセス重視の会社で働いてたから、イライラすることもあったけど、世界で最高のハードウェアを一貫して生み出してた（残念ながら、ソフトウェアについては同じことは言えなかった）。書き留めることはプロジェクトを硬直させることもあるけど、でもそれなしではやっていけない。コミュニケーションのオーバーヘッドが一番の敵なんだ。だから、経験豊富なエンジニアの小さなチームは、協力して働くことに慣れてるから、すごい量の仕事をこなせるし、「部族的知識」—ソフトウェアプロセスの専門家が嫌がるやつ—は実はすごく重要な加速剤なんだ。『Concrete Galoshes』っていう記事を書いたことがあって、プロジェクトに構造や柔軟性を加えるものについて話してる。一番の教訓は、「One Size Fits All」な解決策には気をつけるべきってこと。プロジェクトの種類によって、必要なオーバーヘッドや構造は違うから。

└

コミュニケーションのオーバーヘッドが一番の敵なんだ。そうだね。これを強調するために言いたいのは、必要なコミュニケーションを可能にするのは指数関数的な方程式だってこと。具体的には、チームメンバーを追加すると、チーム内のコミュニケーションの要求が指数的に増えるし、組織にチームを追加することも同様だよね。 > だから、経験豊富なエンジニアの小さなチームは、協力して働くことに慣れてるから、すごい量の仕事をこなせるし、「部族的知識」—ソフトウェアプロセスの専門家が嫌がるやつ—は実はすごく重要な加速剤なんだ。あなたが指摘した両方の状況は、同じ概念から派生していると思う - 信頼と理解。信頼は、長い間一緒に働いてきた小さな経験豊富なチームが、お互いの得意な部分と苦手な部分を学ぶから。理解は、そういう効果的なチームが築いた信頼を大切にし、お互いのスキルを補完しようとするから。だから「部族的知識」は、上記の結果として期待されるもので、理想的には文書化やメンタリング、プレゼンテーションなどでキャッチされるべきだと思う。

ソフトウェアじゃない大企業でも、これって結構当たってると思う。仕事に関する仕事がしばしばもっと重要で、昇進に関わる進展には特にそうだよね。

私はITセキュリティの仕事をしていて、ここではさらに顕著だよ。具体的には、「あなたのチームにこのことをやってもらう必要があるけど、それはあなたの指標には役立たない」という時に、バックチャネルの効果的な代替手段を知っている人はいる？お願いだから教えて！

└

自分のチームのエンジニアを、彼らが選ぶプロダクトや機能、ロードマップのアイテムに取り組ませる代わりに、自分のやりたいことをやってもらうって提案してみては？

ショーンの投稿、またいいね。これはプロダクトの領域やエンジニアリングにもかなり当てはまる。例えば、約1年前に、プロダクトの人たちと同じ考えを持つエンジニアたちが、他のチームにも役立つと信じる何かを開発したいって思ったんだ。公式に資金を調達するのは色々な理由で大変だったから、みんなでやっちゃおうってことになった（OPが言うところの「非公式なチャンネル」）。これには大きな信頼と尊敬が必要だったけど、このグループにはそれがあった。上からの指示じゃなくて、純粋な草の根の取り組みって感じで、組織全体で開発が意外と早く進んだんだ。今では上層部がこれを成功事例として取り上げてるけど…まあ、いいことには報いがないってことだよね！チームは今、ビジネスケースや正当化を公式なチャンネルを通じてやり直さなきゃいけなくて、もちろん痛いけど、失敗の可能性が大幅に減ったから少し楽になったかな。最近数年で取り組んだ中で、一番楽しくて満足感のあるプロジェクトの一つだよ。

このブログ記事を読んで、ただの病理のリストにしか見えなかった。しかも、会社の利益にどう影響するかにしか焦点を当ててなくて、社会に対してどれだけ有害かには触れてないんだよね。経済的にも、精神的にも、身体的にも。そして、これらの病理が一つの理由、つまり権力と資本を持つ階級の人たちが労働者階級を搾取するためだけに存在していることにも触れてない。だから、みんなが会社をこう見るのは分かるけど、私が挙げた問題を無視するなら、資本主義が多くの人に失敗する理由の一部になってしまうし、ほんの一部の人にしか利益をもたらさないんだよね。

└

「社会主義は簿記だ」と、ウラジーミル・レーニンが言ってた。もし、後期のメガコーポ資本主義が病的に官僚的だと思うなら（実際そういうこともある）、ソビエト圏がそれをどう扱ったかを思い出してみて。これらの病理は、信頼の欠如から来ていて、その結果、監視とコントロールの必要が生まれるんだ。信頼の問題は、小さなチームでは通常起こらないし、同じ考えを持つ人たちのコミューンでも起こらない。経済や所有権の問題じゃなくて、コミュニケーションやゲーム理論の問題なんだよ。

良い記事だけど、話の中であまり触れられていない側面があると思う。SWEがグラフの葉っぱのような存在だっていう世界観にとらわれてる。組み立てラインの作業員みたいなもんだ。でも、著者も「明確な仮定」のセクションで言ってるように、これは真実じゃないって知ってるはず。ソフトウェアエンジニアは、組織のグラフを拡張するマネージャーなんだ。コードを使ってね。特異な点もあるけど、彼らはマネージャーだよ。一つの領域の問題は、他の領域でも類似のものがあるんだ。

└

ソフトウェアエンジニアは、ICレベルを上げるために実際のマネージャーであることも求められてる。単にコードを書くことだけじゃ不十分なんだ。プロジェクトマネージャー、アーキテクト、チームリーダー、そして強力な説得者である必要がある。そうじゃないとシニアとは見なされないし、証明するための書類も必要だよ。

TDD運動以来の誘惑は、「テストできないものは『書かれていない』」って考えだと思う。「明確さ」って言葉がその欲望を表すのにぴったりだよね。Tritiumには何百ものユニットテストがあるけど、それを使ってブログを書き始めるまで、見逃されていた質的なバグを見つけることができなかったんだ（ユニットテストでは見つけにくいもの）。それらは明確じゃなかった。これが、インディーゲーム開発が他のソフトウェアの垂直市場が「勝者総取り」になる中で、なぜ市場経済に強いのかの理由だと思う。ゲーム開発者は、自分たちの製品を質的に良くできるのは、しっかりと自分たちのものを使っているからなんだ。記事でも言及されているように、彼らは「企業」としての面積が小さいから、明確さがそんなに必要なんだ。実際には、質的な指標と量的な指標の両方が必要なんだよ。

└

これ、ほんとにそうだと思う。TDDの大ファンだけど、手動テストも大事だよね。思った通りにいかないことが多いし、特にユーザビリティに関することはそうだし、他のことでも同じだよ。

└

テスト全般（特にユニットテスト）はストリートライト効果に陥りやすい。何かが trivial だったり重要でないほど、テストが簡単になる。これが、重要な部分よりも簡単な部分をテストしたくなる誘惑を生むんだよね。さらに、組織が「可読性」を重視して、簡単な「可読性のある」指標（例えば、行カバレッジ）を推進することで、さらに悪化することもある。実際には経験豊富なエンジニアによるテストのレビューのような、難しい「不可読な」指標ではなくて。

ここで言われてることには一理あるけど、そこまで極端じゃないと思う。私は5000人くらいのエンジニアがいる会社で働いてるから、小さくはないけど、アマゾンほどではない。でも、ほとんどのルールにはそれなりの理由があると思う。例えば、コードレビューは2人必要っていうのは、プロダクションにミスが入るのを防ぐためだよね。レビューが拒否されることはあまりないけど、もしコードレビューなしでプロダクションに行ったら、もっと障害が起きたり、いい加減なコードが増えたりすると思う。だから、これは強制的な機能として働いてる。今のところ、そのルールを破る必要はないけど、いつかはそうなるかもしれない。例えば、チームの90%が重大なインシデントに引っ張られて、レビューができない状況になったら、1日だけルールを破って重要な修正を出す必要があるかもしれない。それはOKだと思う。ルールの理由と修正の理由、ルールを守れない理由をバランスよく考えればいいんじゃないかな。理解できないルールや、ただの官僚主義に感じるルールがあったら、私は辞める。そういう職場で働いたことがあって、誰かが自分の好きなプロセスを持ってて、「それ、持ち方間違ってるよ」って叫ぶんだよね。ほとんどはSCRUMだけど、他にもいろいろある。運営してる人たちは、実際の進捗よりもプロセスや自分のエゴを大事にしてる。そんな時は辞めた方がいいよ。

ハクソク