Seeing Like a Software Company
ソフトウェア企業の実態
チームで働くよりも一人で仕事をする方が効率が良いというのは自明 エンジニアが休暇を取ってようやく仕事を終わらせたり、生産性の高い仕事が夜間や週末に行われたりするといった逸話が数多くあるのはこれによる
エンジニア主導の仕事は上から指示された仕事よりもはるかに迅速に進む 別の何かに翻訳する必要もなく、あらゆる方向に積極的にコミュニケーションを取る必要もなく、最も単純かつ効率的な方法で行うことができる
スタートアップなどの小規模な企業が大規模なソフトウェア企業よりもデリバリーにおいてはるかに優れていることが多いのもこれによる なぜ大企業はこの状況に対処して全てのプロセスを廃止しないのか？
エンジニアの作業を遅らせるプロセスは、エンジニアの仕事を社内の他の社員にとって分かりやすくするプロセスである
以下が満たされていること
1. 部門長は、エンジニアにとって、部門が現在取り組んでいるすべてのプロジェクトを把握している。
2. その責任者は、部門が前四半期に出荷したすべてのプロジェクトの包括的なリストも知っている（または要求できる）
3. その頭脳は少なくとも1四半期先（理想的にはそれ以上）の仕事を計画する能力を持っている
4. その責任者は、緊急時には、部門の全資源を即時の作業に指揮することができる。
小規模で効率的な組織は4つ目しか満たしていないが、全員が必要な作業の共通認識をもち、製品が継続的に改善されていれば問題とならない なぜ大企業においてこれらが大事か？
エンタープライズの顧客は可読性を非常に重視し、取引相手のベンダーにも同じ可読性を求める 可読性のための単純化
1. 同じ役職のエンジニアのパフォーマンスはほぼ同じ
大きなばらつきがあり、適性によって生産性は大きく変わる
2. 開発生産性を大幅に損なうことなく、エンジニアを配置し直したり再編成したりすることができる 3. チームに同じ数のエンジニアがいる場合、そのチームは長期間にわたって同じレベルの生産性を維持する 4. プロジェクトは、ある程度の誤差はあるものの、事前に見積もることができる。プロジェクトの見積もりに時間をかければかけるほど、見積もりの精度は高まる 見積もりの大部分は空想である
最初の見積もりによって、その見積もり期間内に完了するために必要なエンジニアリング作業の種類が決まるのであって、その逆ではない
そのため、プロジェクトを複数の部分に分割してそれぞれの部分を見積もると、エンジニアが全体の出荷日を合わせるのが難しくなる。結果的に見積もりの精度が低くなることがよくある
これらの前提は、会社の責任者に理解しやすい情報を提供するという目的においては意味がある
プロジェクトの見積もりが正確かどうかに関わらず、それは計画の立案や他の大規模組織とのコミュニケーションに活用できるというメリットがある