- James C. Scott の 『Seeing Like A State（国家のように見る）』 の核心は、組織がシステムの 「可読性（legibility）」 を高め、あらゆるものを測定・報告できるように変えようとする点にある
- しかし実際には、追跡も予測もできない 「非可読な仕事」 が不可欠であり、可読性だけを重視するとかえって効率が落ちる現象が生じる
- とくに大企業は 四半期計画、OKR、Jira などのプロセスを通じて業務を可読化するが、これは逆説的に効率を下げ、小規模企業が大企業より 20 倍効率的でありうる
- 組織は緊急事態への対応のため、「タイガーチーム」のような一時的な非可読領域を許容しており、エンジニア間のバックチャネルによる非公式な協業が公式プロセスと同じくらい重要な役割を果たす
- テック企業の成功は 可読なプロセスと非可読な実務のあいだの均衡を保つこと にかかっており、そのどちらか一方だけでは組織はうまく機能しない
序論: 『Seeing Like A State』の核心的なアイデア
- James C. Scott の著書『Seeing Like A State（国家のように見る）』の要点は、次の 3 つに要約できる
- 現代の組織はシステムを 「可読性（legibility）」 が最大化された形に変え、すべての部分を測定・報告可能なものとして統制する
- しかしこうした組織は、巨大な 「非可読（illegible）」 な仕事に依存している。つまり、追跡も計画もできないが不可欠な仕事が数多く存在する
- 可読性の向上はしばしば効率を損なうが、それ以外の利点（統制、計画、透明性など）が大きな利益と見なされる
- 可読性とは、予測可能で、成果が追跡可能で、特定の人的資源に依存しない仕事を指す。例: スケジュール管理、OKR、Jira など
- 非可読性とは、即興的であったり暗黙知に基づく仕事、すなわち文書化や公式化が不可能な協業、突然の変更、人間関係に依存する仕事などを指す
「国家のように見る（Seeing like a state）」の事例
- Scott は 19 世紀ドイツの「秩序だった森」の事例を挙げ、組織が効率のために統制と標準化を進めようとする試みを説明している
- 森のすべての木を一目で把握できるように管理することで、計画、取引、資源配分の効率が高まると期待された
- 実際には、森の多様性や下層植生の役割が見落とされ、生産性が低下し、病気や寄生虫に弱くなった
- つまり、効率と透明性の両方を狙ったにもかかわらず、過度な 可読性 の追求がかえって効率を損なう結果を生んだ
ソフトウェア企業における可読性と非可読性
- ソフトウェア企業でも同様に、小さなチームや個人のほうが効率的であることがある
- 単独で働くエンジニアは、チームの一員として働くときより効率的 でありうるというのは、ソフトウェアエンジニアのあいだではほぼ常識だ
- エンジニア主導の仕事は 上から指示された仕事よりはるかに速く進む が、それは 意味のある形に翻訳 したり、あらゆる方向に積極的にコミュニケーション したりする必要がないからだ
- 小規模なソフトウェア企業が大企業よりソフトウェア提供に優れているのは、大企業が 10 倍のエンジニアを投入しても、小規模企業が 20 倍効率的なら問題にならない からである
- 大企業 では、エンジニアの仕事を「可読」にするため、さまざまな手順やツールを導入する
- それは仕事の計画・測定・報告には有利だが、実際のソフトウェア生産性は下げうる
- 小さな会社は、問題に即応したり変化をすばやく受け入れたりできる（非可読な能力）
- 大企業がこうした効率性の代わりに複雑な手続きを維持する理由は、大規模エンタープライズ契約 にある。大口顧客はサプライヤーに予測可能性と信頼性を求める
- こうした顧客と協業するには、長期計画・機能の約束・進捗の文書化 といった可読性が不可欠である
- 可読性がもたらす価値（金額ベース）が、ソフトウェアをより効率的に生産する能力より大きい ため、プロセスは維持される
大企業が重視する可読性の実質的な価値
- 大規模ソフトウェア企業における可読性とは、次のようなことを意味する
- 個々のエンジニアに至るまで 現在進行中のすべてのプロジェクトを把握 できる
- 前四半期に完了したプロジェクト一覧 をすぐに出せる
- 少なくとも 1 四半期単位（あるいはそれ以上）で事前に業務計画 を立てられる
- 緊急時には 部門全体のリソースを動員 して即時の業務に投入できる
- 小さなソフトウェア企業は、即座に柔軟に対応する能力 を除けば、こうした要件をほとんど満たせない
- 大企業は記録、分類、長期計画には強いが、迅速な対応力（組織リソースの即時投入）はむしろ弱まることがある
- こうした可読性の確保は、主として エンタープライズ顧客との信頼、契約、長期協力 において中核的な役割を果たす
可読性確保のための前提とその限界
- 大企業は可読性を推し進める過程で、次のような単純化された前提を置く
- 同じ職位のすべてのエンジニアはおおむね同程度の働きをする と仮定する
- エンジニアを再配置・再編成しても生産性の損失はない と仮定する
- チームのエンジニア数が同じなら、時間がたっても生産性水準は維持される と仮定する
- プロジェクトは事前に見積もることができ、誤差範囲もある と仮定する
- しかし実際には
- 同じ職位でも実力差は大きく、専門性や関心 によってプロジェクトの生産性には大きな差が出る
- チーム規模と生産性のあいだには弱い相関しかない
- プロジェクト見積もりはほとんど幻想に近く、実際には見積もりの予定に合わせるために仕事の進め方が変わることさえある
- それでも、こうした前提は社内コミュニケーション、外部の大企業との合意、事業計画には有用である
一時的に許可された非可読領域
- 大企業では、可読性を生み出すプロセスが深刻な遅延を引き起こす
- プロダクトアイデア → プロダクト組織の計画段階 → エンジニアリング組織の技術レビュー → VP とシニアマネージャーによるチーム割り当て交渉 → チーム計画バックログ入り → チームのチケットバックログ → スプリント入り → 実作業の開始
- すぐに着手すべき仕事とはまったく相性が悪い構造 である
- この問題を解決するため、「バーチャルチーム」「ストライクチーム」「タイガーチーム」などの一時的な非可読領域を許容 している
- 組織が信頼する選抜エンジニアで構成される
- 管理者がまったく付かず、非常にシニアなエンジニアがプロジェクトを回すことも多い
- 緩やかな任務だけが与えられ、目標達成のためなら基本的に何をしてもよいとされる
- これは 完全な非可読性と完全な可読性のあいだにある賢明な妥協 である
- 公式プロセスを迂回するが、常設ではなく一時的にのみ維持される
- 許可された非可読性も 組織の残りの部分とぎこちなく共存 しており、他のエンジニアは、プロセス負担なしで働ける自由を見て嫉妬したり危険だと感じたりする
恒常的で無許可の非可読領域
- チーム A のエンジニアがチーム B に作業を依頼する公式な方法は、「計画」バックログに issue を作成し、12 段階のプロセスを経てスプリントに入るまで待つこと だが、これには数週間から数か月かかる
- 公式な解決策は、チーム A が計画プロセスの中でチーム B の作業を予測しておくべきだ というものだが、コードを書く何か月も前にすべての変更を予測できるはずがなく、ばかげている
- 実際の解決策は 非可読なバックチャネル である
- チーム A のエンジニアがチーム B のエンジニアに「この 1 行の変更をやってもらえますか？」と頼む
- チーム B のエンジニアはすぐ対応し、チケットを作るかどうかは任意になる
- エンジニア同士の 対人関係に依存するため非可読 である
- バックチャネルは会社のあらゆるレベルで継続的に存在する
- エンジニア間のクロスチーム・バックチャネル、チーム内バックチャネル、マネージャー間、プロダクトマネージャー間
- 公式の場で質問が出たときには、すでに回答者と私的に事前確認・すり合わせが済んでいることが多い
- バックチャネルは 問題を起こすこともあり、ときには世間知らずなエンジニアを犠牲にして自分の利益を得るために使われることもある
ソシオパス、無自覚な人たち、敗者
- Venkatesh Rao の「Gervais 原則」は、組織を 3 つの集団に分ける
- 最上層の 「ソシオパス」 は、自分の利益のために組織のルールをシニカルに利用する
- 中間管理職の 「無自覚な人たち（clueless）」 は、組織の公式ルールを信じ、その上でさらに深いゲームが進行していることを認識しない
- その下の 「敗者（losers）」 は、ゲームが行われていることは認識しているが、参加したいとは思わない
- これらの区分は 可読性の観点から読み解ける
- ソシオパスと敗者はどちらも組織の非可読な世界に関わっている
- 「無自覚な人たち」 は可読なプロセスにしか関わらず、昇進を望むときには公式のジョブラダーを調べ、次のレベルの各価値をどう実現するか計画する
- 彼らを「無自覚」と呼ぶのは過度にシニカル である
- 可読なプロセスは依然として非常に重要であり、組織の活動の大部分を占めている
- 公式プロセスを改善することは、依然として非常にレバレッジの高い仕事である
- こうした分類で人を見ると、ソフトウェア企業で頻繁に起こる対立領域が、これらの集団間の摩擦から生じていることを理解 しやすくなる
最後に
- 組織内の非可読な世界を認識し、活用することが重要である
- 著者はテック企業における非可読性の認識と活用について多くを書いてきた
- 非可読なプロセスに関する助言は 「危険な助言」 に当たる
- 公の場で、公式プロセスではなくバックチャネルで仕事を終わらせていると宣言すれば、組織から処罰される ことになる
- 管理チェーンがそうすることを望んでいたとしても処罰される
- 公式プロセスを決して迂回すべきでないという否定的な反応を多く受けるが、著者は その見方はナイーブだと考えている
- すべての組織は、可読な側面と非可読な側面の両方を持つ
- 可読な側面は一定規模を超えると重要になり、長期計画や他の大規模組織との調整を可能にする
- 非可読な側面も同じくらい重要で、高効率な仕事を可能にし、現状に合わないプロセスのための安全弁を提供し、ゴシップや緩やかな合意に対する人間の自然な欲求を満たす
1件のコメント
Hacker Newsの意見
大筋では同意するが、リーダーシップが自動的に「legibility」はあらゆるコストを払うだけの価値があると仮定している点には異論がある。もしCEOがすべての細部の業務（例: ユニットテストの並列化など）にまで気を配らなければならないなら、それは脳が指を一本動かすたびに意識しているようなもので、何もできなくなってしまう。現実的にはCEO、つまり会社のトップが統制できるのは全体の約7%程度にすぎない。残りは各従業員が埋めるものであり、自分は脳の役割であって体全体ではない。だがリーダーは自分がいちばん重要だと錯覚しがちで、時間が足りない分野や専門性のない分野（例: 優秀なMIT出身エンジニアとブートキャンプ出身の平均的エンジニアの差など）は雑に流しがちだ。Googleの成功を語るときでさえ、何十人もの優秀な実務者ではなく、創業者2人やCEOにだけ功績を帰する傾向がある
ここで書かれていることの一部は正しいが、そこまで極端でもない気がする。私は約5000人規模の会社（小さくはないがAmazon級ではない）で働いている。大半のルールにはそれなりにちゃんとした理由がある。たとえばコードレビュー担当者が2人必要なのも、ミスを防ぐためだ。レビューで却下されることは多くないが、レビューなしでデプロイすれば障害はもっと頻繁に起きるだろう。こうしたルールは、半ば強制的にでも確認させてくれる。もちろん、いつかはルールを破らなければならない場面（チームメンバーの大半が障害対応で急に抜けた場合など）が来るかもしれない。そのときはルールの趣旨に沿って例外を認めるのが妥当だ。だが、理解不能な純粋に官僚的なルールばかりの場所（誰かが自分のやり方に固執して「お前のやり方は間違っている」と言うだけのタイプ）なら去るだろう。本当の前進や成果よりも、プロセスや個人の自尊心を重視する環境なら転職が正解だ
TDD以後、「テストできないなら実装もできていない」という誘惑が強くなった。これを説明するのに「legibility」という言葉はとても的確だ。Tritiumでは何百ものユニットテストを用意していたが、実際にブログを作ってみて初めて、ユニットテストでは捕まえられない質的なバグ（テストでは確認しにくいもの）が明らかになった。参考: https://tritium.legal/blog/eat。インディーゲーム開発が市場原理に比較的よく耐えるのも、このためかもしれない。ゲーム開発者は自分の製品を直接使い（Food-dogging）、質的な改善を行う。大企業ソフトウェアのような過剰なlegibilityの表層は必要ない。要点は、質的指標と量的指標の両方が必要だということだ
テスト、特にユニットテストは「街灯効果」に弱い。些細だったり重要度の低い部分ほどテストしやすく、その結果、簡単なものばかりテストすることになりがちだ。組織がline coverageのような、測定しやすい簡単な指標にばかり執着すると、本当に意味のある（難しい）検証が抜け落ちる危険がある。経験豊富なエンジニアのレビューのような定性的評価も重要だ
ゲーム開発は、他のソフトウェア分野よりフィードバックループがはるかに短い。たとえばメモリリークが起きれば、毎秒何百回もすぐに問題として現れる。遅いコードは視覚的なカクつきとして即座に体感されるため、キャッシュの整合性やGCを使うかどうかなど、パフォーマンスの観点まで意識せざるを得なくなる
TDDは好きだが、結局のところ手動テストも絶対に必要だ。自分で試さなければ予想外の問題がしばしば起きる。特にユーザーフレンドリーさのような点は、実際に使ってみないと分かりにくい
Seanの文章はよく読んでいるが、今回の記事もプロダクト領域全般に通じるものがある。たとえば1年ほど前、複数のプロダクト担当者やエンジニアが、他チームにも役立つものを作ろうとしていた。正式なチャネル（legible channel）で承認を得るには当時の組織構造では現実的ではなかったので、信頼と尊重を土台にした非公式な形（illegible channel）で進めた。草の根的に進められ、むしろ社内で素早く口コミが広がってtractionを得た。結局いまでは経営陣がこの事例を自分たちの成功ストーリーのように使っているが、逆に今はあらゆる公式手続き（legible channel）と事後的な根拠作りに着手していて、手続きはかなりしんどい。とはいえ失敗リスクは大幅に下がったので、だいぶ楽ではある。ここ数年で最もやりがいがあり、楽しかったプロジェクトだ
長く会社勤めをし、社内政治（office politics）にさらされるほど、これは地政学（geopolitics）や外交に似ていると感じる。さらに言えば、社会的関係や恋愛関係にも平行線を見いだせる。たぶん抽象モデルを作るのが好きな数学者気質のせいだろう
私がいちばん好きなテーマはまさに政治だ。本や雑誌、各種資料を見るのが好きで、正直なところ社内政治もあまり苦ではない。要するに、人は人らしく振る舞うというだけの話だ。すべての個人（組織も同じだが）には欲しいもの（欲求）と恐れるもの（恐怖）があり、それをバランスさせる過程が一種の面白さになっている。まるで工学の問題を解くようなものだが、要件が「人間」だというだけだ。そういう問題を解く過程自体が面白い
私も最近になってこうしたことに気づいた。最初は外交を、何百人もの外交官が作り出す複雑系の結果だと見ていたが、実際には数人の権力者が絡む人間関係にすぎない。保育園で起きていることに近い発想で捉えられる
これは本能的に自然な現象だ。社会的関係（恋愛など）よりも、大企業と政府のあいだのほうが、さらに明確に似ている点が多い。企業は普通、もっと独裁的（autocratic）あるいは封建的（feudal）に近い。違いも多いが、規模が大きくなるほど徐々に政府に似ていく傾向がある。高度化した官僚制もその一つだ
ゲーム理論のWiki
現代の政治家のかなりの割合が、もともとは普通のオフィスワーカーから出発していることを考えれば、こうした現象は別に不思議ではない
私はITセキュリティ分野で働いているが、ここではこういう状況がさらに際立っている。「自分たちのチームの直接的な指標に寄与しない依頼」を受ける必要があるとき、非公式なやり方（back channel）以外に代替策があるのか気になる。知っている人がいたら聞きたい
良い記事だが、いつも触れられない一点について言いたい。本文ではソフトウェアエンジニア（SWE）が木の葉、つまり組立ラインの作業者程度に描かれていて残念だ。だが「Legible assumptions」の部分にもあるように、実際のエンジニアは、組織構造に「コード」で接続を拡張する「管理者的な役割」も果たしている。問題は適用対象が違うだけで、似たような悩みに直面することだ
本文中の「なぜ小さな会社ではなくても済むのに、大きなソフトウェア会社ではこうした能力が必須なのか？ 私の専門ではないが、たぶん大企業向けプロジェクトのためだろう」という部分に同意する人はいるだろうか。意見を聞きたい
大企業案件のためというより、内部の「大規模な情報伝達（communication at scale）」のためだと思う。従業員m人の組織は、m*mのコミュニケーション行列にたとえられる。少人数のうちは各マスがほぼ1（密なコミュニケーション）だが、規模が大きくなるにつれて0（断絶）や0.5（非公式なコミュニケーション）が大半になる。しかし情報こそが最終的には会社そのものだ。だから、マネージャーと正式なプロセスによって情報の「流れ」に責任を持つ構造が不可欠になる。企画、昇進、レビューなどは、どれもこうしたlegibilityを確保するためにある
小さな会社で大企業案件を一手に引き受けているが、内部にまで厳格なlegibilityを要求しなくても案件は成立する。顧客の前ではプロジェクト管理のlegibilityは必要だが、内部の開発方式まで細かく干渉されるわけではない。結論として、大企業がlegibilityに執着するのは、彼らがすでに大企業であるか、大企業になろうとしているからだ
医療画像の領域に長くいたが、大半の事業主は自分たちがITサービス/ソリューション業界にいることをちゃんと理解していない。ITサービスの能力こそが実際の成功要因だった。診断そのものよりも、放射線科以外の人材がプラットフォームの使いやすさと効率を高めようと努力した部分のほうが、はるかに大きかった
どれだけ大きな組織であっても、内部監査・外部監査（audit）に常に何度も備えなければならない。監査人は、できるだけ多くのプロセス文書を見たがる傾向がある。たとえばこの事例のように、最悪の場合は監査人が顧客を「解雇」することさえある
その部分（大企業案件のためだという点）はやはりやや特殊に感じる。スタートアップ出身で今は中堅企業の中間管理職だが、組織規模が大きくなるほど、仕事の進め方を示す最低限の構造は必要になると思う。どれだけプロセスが嫌いでも、Dunbar’s Numberを超えれば共感や非公式なコミュニケーションだけでは限界がある。極端な例外はSteamくらいだが、あそこでも特定のタイプの人材だけが選別され、社内政治も非常に激しい
legibility という言葉の選び方自体が興味深い。公式プロセスと非公式プロセスの二分法のように感じられる。会社が小さいうちは非公式なやり方がうまく機能するが、ある閾値を超えると正式なルールやプロセスを導入せざるを得ない。長期的にはルールが硬直化し、変化についていけなくなる。次第に目的よりも過程そのものに執着するようになる。こうしてルーティンから外れ、新しさを保つのは簡単ではない。会社ではお金を血液のようなものだと言うことがあるが、実際にお金が動機の根本であることは少ない。お金は必要条件ではあっても、存在理由そのものではないと思う
いつだってバランスの問題だ。私は25年間エンジニアリングマネージャーをしていて、強力なプロセス中心の会社で働いてきた。息苦しくはあったが、世界水準のハードウェアを安定して作り続けられたのには利点もあった（ソフトウェアではないが）。文書化などは必要不可欠だが、厳格すぎるとプロジェクトが硬直化する危険がある。最も深刻な問題はコミュニケーションのオーバーヘッドだ。だからこそ、少数の有能なチームが長く一緒に働くと、とてつもない生産性を発揮するし、「tribal knowledge」も実際には非常に重要な促進要因になる。私が Concrete Galoshes という文章を書いたのも、こうした構造的・硬直的な要素を扱いたかったからだ。最大の教訓は「すべてのプロジェクトに同じ服を着せてはいけない」ということだ。プロジェクトごとに異なる構造やオーバーヘッドが必要だ