大企業について | オリジナル、AI翻訳
目次
- 大企業について
- 才能の密度がチーム規模を凌駕する
- 手続きが従業員への信頼を置き換える
- リスク回避がイノベーション成長を阻害
- スタートアップは企業より迅速に展開可能
- 官僚主義が個人の責任を曖昧にする
- 大企業におけるエンジニアリング
- ルールは一貫性を強制するが創造性を制限
- 自動化チェックは微妙な設計品質を見逃す
- テストツールは戦略的評価の深さを欠く
- モノリシックシステムは急速なスケーリングに抵抗
- 冗長なワークフローが知識保持を保証
- コラボレーションについて
- チームはモジュラーコード構成を反映
- タスク所有権がコミュニケーションオーバーヘッドを削減
- 透明性がリアルタイム調整ニーズを置き換える
- AIツールが個人の貢献を拡張
- 不一致な期待がプロジェクト成功を妨げる
大企業について
大企業は巨大なプログラムのようなものだ。10万人の従業員と5万人の契約職員を抱える大企業は、15万のメソッドを持つ巨大プログラムに似ている。
ダリオ・アモデイは、才能の密度が才能の数よりもはるかに重要だと述べた。200人の非常に優秀な人材は、800人の普通の人材を含む1,000人の才能ある人材に勝ることができる。
ダリオ・アモデイはまた、大企業には多くの手続きやプロセスがあるのは、従業員や契約職員を信頼していないからだと指摘した。そのため、多くのチェックやコントロールが必要になる。
大企業の特徴の一つは、失敗を恐れることだ。一つの理由は、彼らが3000億ドルや1兆ドルの価値を持つまで成長した過程で、多くの失敗を経験し、そこから成長してきたからだ。しかし、成功すると、再びリスクを取ったり失敗したりすることに消極的になる。
これは、バグ、特にセキュリティバグを排除しようとする巨大なプログラムに似ている。特に大銀行ではその傾向が強い。
スタートアップは速いが、リソースははるかに少なく、ブランドも確立されておらず、大企業のような信頼もない。
中国では、優秀な若者は卒業後も大企業に入社しようと苦労する。シリコンバレーには多くのスタートアップがあり、中にはアイデアだけでうまくいっているものもある。
20年経っても苦戦している企業もあれば、設立数ヶ月で50億ドルや100億ドルの評価を受ける企業もある。
ミラ・ムラティの「Thinking Machines Lab」がシードラウンドで120億ドルの価値評価されたという記事や、イリヤ・スーツケバーの「Safe Superintelligence」が20億ドル調達で320億ドル評価されたという記事がある。
設立期間でスタートアップを測るのは良い指標ではない。チームの質、創業者、分野で測る方が良い。
私の一人スタートアップでは、バックエンドサーバーのデプロイに1分、小さなバグ修正とデプロイに5分しかかからない。直接的で速い。大企業では、デプロイ依頼の準備、管理者からの承認取得、ITチームとのデプロイ実施、ヘルスチェックまでに1週間かかる。
実際の作業時間は8時間かもしれないが、準備から最終ヘルスチェックまで1週間かかる。小さなバグ修正とデプロイには2週間かかる。調査チケットを取得し、分析とテストを行い、レビュー後、コードをマージし、テストチームにテストを依頼し、デプロイする。
大企業はすべてのチームやプロジェクトにポリシーを適用したがる。20万人の企業では、1万人にしか適用されないポリシーや内部プロセスは意味や結果をもたらさない。内部プロセスのためには、ツール開発に人や資金を投入する必要がある。ごく一部のスタッフにしか役立たないなら、投資対効果が見合わない。
大企業のもう一つの欠点は、大きなミスをしても誰も罰せられないことが多いことだ。
私のスタートアップでは、50万ドルの投資を受けて9人を雇ったが、2ヶ月後に解雇し、その資金を失った。その後、パートタイムエンジニアと50の小さなソフトウェアプロジェクトを行い、その資金を投資家に返した。
これは非常に強烈で苦い記憶だ。この教訓を常に覚えている。
大企業では、大きなミスをしても誰も罰せられないことが多い。あるケースでは、シニアマネージャーや新入社員が解雇されたが、それが大規模な急成長採用と関連していたかは不明だ。
この結果の一因は、大企業の煩雑で多数のプロセスにある。6ヶ月から1年在籍したエンジニアでも、大きな貢献はできなかった。典型的なタイムラインは、基本を理解するのに2ヶ月、プロジェクトに慣れるのに3ヶ月、面倒な手続きやテストに3ヶ月、ユーザーに影響を与える生産的な作業に2ヶ月かかる。
8時間労働を仮定すると、2ヶ月の実質的な生産作業では大きな結果は得られない。部門の予算は尽き、ユーザーベースは期待通りに拡大せず、さらなる解雇につながった。
この経験から得られた教訓はほとんどなかった。当初、マネージャーグループが迅速かつ大規模な採用戦略を決定したが、当時は不要に思えた。マネージャー全員を責めるのは現実的ではなく、短期間在籍した者だけを解雇するのも非現実的だった。特に他のマネージャーやテクニカルリードが6～8年在籍していた場合。
マネージングディレクターはこの状況からほとんど学ばなかった。これは彼が監督する3部門の1つに過ぎず、報酬も変わらなかった。チーム内でも、直接責任のない者は学べず、スティーブ・ジョブズのコンサルティングに関する発言を彷彿とさせた。そのため、ユーザーに優れた結果をもたらす卓越したチームを作るために必要な教訓を誰も学べなかった。
スタートアップの方が良いケースのように思える。なぜなら、本当に深刻だからだ。失敗した創業者の中には、特に誠実な人々は本当に苦しむ。
誠実な個人にとって、数百万ドルから数億ドルの投資資金を失い、基本的な製品や収益の少ないユーザーベースしか残らないことは、非常に落胆させる。
ポール・グレアムは以前、採用は時代遅れというエッセイを書いた。
しかし、大企業がうまくやっていることは何か？一つは長期主義だ。長期的な視点で物事を行う傾向がある。優れた大企業では、プロジェクト設計が非常に優れており、10年後に巨大なモノリシックプログラムになる間違いを避けるためにマイクロサービスを使用している。また、ガバナンスチームが基礎的なフレームワークを作り、チーム全体の開発プラクティスを統一している。
プロセスや手続き自体が悪いわけではない。しかし、物事を複雑にし、遅くすることが多い。Javaの統一コードフォーマットが不快ではないのは、SpotlessやCheckstyleプラグインが役立つからだ。これらのプラグインは設計が良く、使いやすい。
もう一つは、大企業は内部使用やフロントオフィスのためのツールやプロジェクトを作りがちだ。しかし、そのユーザーベースは数百人か1万人と非常に限られている。
その目的には外部ツールを使用した方が良い。ある銀行にとって本当に優れたツールなら、200の銀行にも良いはずだ。それでユニコーン企業になれる。
Pony.aiの創業者であるTiancheng Louは、企業が独立する必要がある理由は効率性が高いからだと述べている。その通りだ。
大企業は経験に基づいて従業員に報酬を与える傾向がある。一方、市場はスタートアップチームの結果や実行力に報酬を与える。これは大きく異なる。
大企業で働くのは学校で学ぶようなものだ。小学校から中学校、大学へと進む。スタートアップでは、より多くの浮き沈みがあり、アイデアや市場を移動する柔軟性がある。
大企業のリスク回避の利点は、製品が比較的安定しており、明らかなバグやダウンタイムがないことだ。これは良い。
しかし、AIのような分野では、多くのユーザーは初期段階で不安定な製品を受け入れる。例えばdeepseekは、2025年2月から3月に注目を集めた際に頻繁にダウンしたが、しばらくすると改善し、ユーザーは特に問題を感じなくなった。
場合による。革新的な製品では、多少の問題があっても迅速に市場に出す必要がある。ユーザーは理解してくれる。
プロセスについて考えると、より注意深くなるべきだ。デプロイタイプを分類するべきだ。あるタイプの変更は迅速にデプロイ可能で、他のタイプはそうではない。テストについても、変更されたコードの回帰テストに必要な部分と不要な部分を分類するべきだ。SonarQubeチェックも同様だ。
大企業では、多くのチェック、テスト、承認が不要なのは確実だ。エンジニアに作業を任せ、システムにすべての記録があるので、一部を選択してレビューできる。
すべてのマネージャー承認も廃止するべきだ。マネージャーが持つ知識でエンジニアが持たないものは何か？この知識をコードに書き込み、リクエストを自動的に承認または拒否できるか？
すべてが遅いため、労働者が物事を変える可能性は低い。10年稼働しているプロジェクトをモノリシックからマイクロサービスに変更するには2年かかるかもしれない。
ソフトウェアでは、コードとロジックが密接に絡み合っている。特に設計の良いシステムでは、開発、テスト、コラボレーションが大変になる。
そのため、チームを急に拡大してもうまくいかない。疎結合のマイクロサービスアーキテクチャがあれば、チームの出力はメンバー数に比例するかもしれない。密結合のモノリシックプロジェクトでは、チーム規模を倍にしても出力は30％しか増えないかもしれない。
ペースが遅いため、従業員や契約職員が無能なのか、システムが複雑で煩雑すぎるのか判断が難しい場合がある。あるケースでは、4ヶ月在籍した人がほとんど何も達成せず、数行のコード変更でプルリクエストを提出しただけだった。コードの質も低く、よく理解していなかった。英語も非常に弱く、スクリーンショットを貼り付け、基本的な英語で質問するしかできなかった。
安定性に関して、大企業は複数のチームメンバーが重複タスクを担当する傾向がある。例えば、タスクAとタスクBを2人のエンジニアに別々に割り当てるのではなく、両方にタスクAとタスクBの一部を担当させ、お互いの作業を理解させる。これにより、チームはより安定する。一人がコードの大部分を長年独占的に担当し、協力せず、その人が退社すると誰も作業できなくなる状況を防ぐ。
大企業がうまくやっているもう一つのことは、キャッシュフローと利益規律を維持することだ。大きくなるにつれ、大きな財務危機に直面することが多いため、これが最も優先される事項だ。苦い経験から学び、このプラクティスを業務に組み込んでいる。年間100億ドルや300億ドルの利益を出していても、労働力の最適化や解雇を続ける。
同僚の一人は、大企業は多くの労働力や時間を要する特定の製品で独占的に運営していると指摘した。これは理にかなっている。スピードではなく、規模、リソース、ブランドに依存している。
大企業で生き残る方法は？一つは、多くを実行し、話を少なくすることだ。これはアウトソーシングベンダーのデリバリーマネージャーが教えてくれたことだ。
二つ目は、他人のすることを追随することだ。安全だ。チームの平均的なエンジニアでいることは、街の平均的な人でいることと同じだ。目立ちすぎず、無視されすぎず、ちょうど中間だ。
多くの大企業がある。20万人以上の従業員を抱える企業もあれば、約2万人の企業もある。優れた大企業もあれば、業績の悪い企業もある。見た目や時価総額ではあまりわからない。Nvidiaのように数年で急成長することもあれば、クレディ・スイスのように突然崩壊することもある。
大企業におけるエンジニアリング
大企業は厳格なポリシー管理に優れている。慎重なチェックと徹底的なソフトウェアリリース評価に長けている。
しかし、多くのエンジニアリングは単純なルールに落とし込めない。設計の簡潔さや各メソッドやJavaクラスの最適化は、ルールで簡単にチェックできない。
SonarQubeスキャンは良いものであり、高いテストカバレッジも良い。しかし、多くのソフトウェア設計やエンジニアリングは簡単に測定できない。
APIの品質や機能の使いやすさは簡単に評価できない。メソッドのパラメータも簡単に評価できない。関数の設計、ブランチ戦略、開発戦略、命名も簡単に測定できない。
アリババにはJavaガイドがあり、GoogleとPlantierにはJavaフォーマットがある。これは良い。しかし、Javaプロジェクトのすべてがコードで自動チェックできるわけではない。
テストについても同様だ。多くの自動テストツールがあるが、すべてのテスト戦略、設計、哲学、技術が固定されたルールで測れるわけではない。
製品についても同様だ。多くのA/Bテストやデータ駆動型製品開発があるが、すべての製品技術、スキル、洞察が固定されたルールで測れるわけではない。
なぜこれを議論したいか？それは、私たちの価値がこれらの分野にあるからだ。大企業が苦手なことは何か？それらを支援できる。
なぜ「企業におけるエンジニアリング」ではなく「大企業におけるエンジニアリング」なのか？実際、大企業も小さなスタートアップも人で構成されており、従業員数に多少の違いがあるだけだ。
大企業のエンジニアリングはスタートアップよりも多様性に欠ける。
コラボレーションについて
コラボレーションは難しい。共通の目標を達成するために協力する必要がある。これをコーディングの観点から考えてみよう。
本質的に、個人は人生経験、職歴、世界観、親密な関係、育ち、デジタルインタラクションから構築された複雑なプログラムのようなものだ。
課題は、チームとして目標を達成することだ。グループはどのように効果的に協力すべきか？マイクロサービスはどのように調和して動作すべきか？
個人プロジェクトでは、すべてを所有し、処理するため、コラボレーションは不要だ。現在、個人は多くのAIツールを使用して目標を達成する。
数人の小さなチームでは、責任が分かれる。例えば、一人が設計を担当し、もう一人が開発に集中する。または、一人がバックエンド、もう一人がフロントエンドを担当する。
大企業では、従業員が退社することを懸念し、プロジェクトに知識ギャップが生じることが多い。責任を引き継ぐ新しい人は、数ヶ月から1年かけて追いつく必要があり、プロジェクトが遅れたり停滞したりする。
しかし、AI時代では、アプローチを適応させるべきだと思う。「人月の神話」の概念は今も真実だ。
自然なコラボレーションを強く支持する。チームの利益のために、プロジェクトが進むにつれ、特定のコラボレーション習慣が自然に形成される。
これはコードの自然なモジュール化に似ている。ある程度開発が進むと、50のJavaクラスができ、それらをパッケージに整理する。100のPythonファイルがあれば、モジュールで管理する。
タスク分離は各人の強みを考慮するべきだ。AI時代では、個人が複数の分野で優れることができる。そのため、大きなタスクをチームメンバー間でどのように分割するか再考する必要がある。
各チームメンバーが一度に比較的大きなタスクを担当すべきだと思う。これにより、他のメンバーとの頻繁なコミュニケーションや調整が必要なくなる。大きなタスクは比較的独立しており、必要な時に上級チームメンバーから助けを求められる。これにより、より多くの人が関与できるが、タスクは主に担当者に所有される。
二人が協力してすべてのコード行を編集したり、すべての詳細を一緒に作業したりするのは煩雑だ。各ステップで行動を調整する必要があり、これは難しい。コンピューティングでは、目標を達成する方法が無数にある。結果の質が高く、目標を達成すれば、特定のIDE、SQLクライアント、Pythonスクリプト、手動プロセスなど、異なる方法やツールを受け入れるべきだ。
コラボレーションのもう一つの改善点は、作業記録を可能な限り透明にすることだ。最近の仕事では、スクリプト、ログ、メモをチームメンバーと共有した。Copilotに尋ねたクエリ、途中で遭遇した問題、関連ログを共有できる。この透明性により、チームメンバーとのコミュニケーションが容易になる。
これは、タスク実行中にコンピュータ画面を記録するようなものだ。ここではテキストを使用して情報を共有しているが、より良いコミュニケーションという目標は達成される。
なぜコラボレーションは失敗するのか？どのようなシナリオがコラボレーションを妨げるか？一つの理由は、チームメンバー間の期待の不一致だ。考えられる結果は、プロジェクトが遅れたり、作業が品質要件を満たさなかったりすることだ。