管理不要：初期段階のエンジニアリングチームにおけるアンチパターン

2026年1月14日原文(ablg.io)

概要

本記事は、SeedやSeries A段階のスタートアップ創業者向けのエンジニアリングマネジメントに関する提言。初期段階では「管理」よりもプロダクト開発とユーザー対話を優先すべきという主張。エンジニアのモチベーション管理やマネージャー採用は早すぎる場合が多い。 Google流など他社の管理手法の模倣も初期には不要。「退屈で堅実」なマネジメントを推奨し、例外的な管理活動のみを紹介。

初期スタートアップにおけるエンジニアリングマネジメントの誤解

Seed/Series Aの創業者 向けのエンジニアリングマネジメント課題への提案
エンジニアチーム構築 やモチベーション管理、プロジェクトの優先順位付けなどの悩み
結論：管理に時間を使わず、プロダクト開発とユーザー対話に集中
創業者自身が管理者 として振る舞うことの非効率性
よくあるアンチパターン と、より良い時間の使い方の提案

エンジニアのモチベーションを「管理」しない

エンジニアのやる気を引き出そうとする行為 （長時間労働の奨励、週末ミーティング、細かな進捗報告の要求）は逆効果
優秀なエンジニアの離脱 を招く文化形成リスク
本質的な問題解決 ではなく、表面的な対症療法に終始しがち
モチベーションは採用段階で見極めるべき資質
創業者自身が最もモチベーション高く行動 することがチームの雰囲気醸成につながる

マネージャーの早期採用は避ける

プロダクト開発フェーズでの管理職導入 は時期尚早
管理職がやるべき「管理業務」 自体が未成熟な段階では不要
最適なタイミング ：20〜50名規模に成長し、現状の管理体制が限界を迎えたとき
5〜15名規模ではフラットな組織と単一リーダー体制 が最適
必要に応じてハイブリッド型（手を動かすマネージャーや非公式テックリード） の活用

Google流マネジメントの模倣は不要

大企業の管理手法やイノベーション文化の模倣 は初期段階では逆効果
「node & postgres」的な堅実で普遍的な管理手法 を推奨
組織構造やタイトル、1on1の新規性にリソースを割くより、プロダクト開発に集中
初期スタートアップの文化は「顧客課題解決の速度」でユニークさを出すべき

初期段階における「退屈な」管理活動例

モチベーションの高い人材の採用 を最優先
採用ミスは早期・円満に解雇 し、管理でカバーしない
非同期型の進捗報告 （スタンドアップやレトロスペクティブの形式的な導入は不要）
Slackの過剰利用を避け、集中時間の確保
1on1は必要時にトピックベースで実施、定期的な関係維持目的の1on1は不要
構造化されたタスク管理システムよりも、柔軟なドキュメント（NotionやGoogle Docs）を活用
極端な透明性の実践 （顧客ノート、投資家レター、予算など全員に公開）
これらの手法は20〜25名規模まで有効、それ以上では再検討が必要

まとめ

初期スタートアップの本質は「管理」ではなく「実行と学習」
管理コストを最小化し、優秀な人材と共にプロダクト価値を最大化
組織成長に伴い、管理体制の見直しを段階的に検討
最も重要なのは、創業者自身の率先垂範と、持続的なモチベーション維持

Hackerたちの意見

996スタイルの文化について読むと、ヨーロッパ人でよかったなって思う。ここでは無理だよ。週40時間が上限で、ほとんどのエンジニアは週32時間以上働きたくないからね。だから、いいワークライフバランスが保てる。今は週に4時間しか働いてないよ。

└

初期段階のスタートアップで働く必要はないよ。実際、大多数の人はそうしてないし。でも、初期段階のスタートアップに参加したい人もいるし、ヨーロッパでもたくさんいるよ。 > だから、いいワークライフバランスが保てる。今は週に4時間しか働いてない。だから、私がPMだったとき、アムステルダムのオフィスを閉鎖して、プラハ、ブカレスト、ワルシャワに移転したんだ。週40時間働いて€80kの報酬を得ることに文句を言う人はあまりいないよ。

└

だから、ヨーロッパではますます少ない企業が採用しているんだ。

└

アメリカでは全員が996ってわけじゃないけど、ここには悪いマネジメントのパンデミックがあるよ。というか、悪いマネジメントというよりも、数万のエンジニアを抱えるアマゾンのプロジェクト管理についての記事を読んだ人たちが、自分たちの4人のスタートアップも同じように管理しようとすることが多いんだ。彼らはそれを「グロースハッキング」だと思ってるからね。アメリカのテックスタートアップは、しばしば相続税を回避するための手段に過ぎないし、VCマネーを夢を売ってより大きな愚者に変えるための手段でもある。もちろん、デメリットもあるよ。

└

「今、週に4時間働いてるよ。」どこの雇用主が4時間の契約を出すの？

└

4はめっちゃ低いね。ちょっと異常だと思う。お金持ちか、コストがすごく低いか、時給がめちゃくちゃ良いか、もしくはそのティム・フェリスの本をうまく活用できた一人なんじゃないかな。

└

EUにいるけど、これがほとんどのエンジニアを表してるとは思わないな。ここでも過労文化があって、たくさんの会社に利用されてるよ。

└

これってどういうことなの？報告するのに4時間分の仕事があるってこと？4時間以上の給料もらってるの？こういう全然理解できない発言をする人がいると、すごく気になるんだよね。

└

この記事から誤解しないでほしい。996はアメリカでは非常に稀だよ。アメリカのエンジニアのほとんどは、普通の40時間労働をしてる。

モチベーションが生まれつきの特性だってのは明らかに間違いだと思う。それは、脱モチベーションも生まれつきだってことを意味するし、それはもっと明らかに間違ってると思う。

└

人を脱モチベートするのは難しくないよ。でも、ここがポイントなんだ…みんなが同じことでモチベートされるわけじゃない。マネージャーとして人をモチベートするコツは、彼らが何にモチベートされるかを見極めるために時間をかけることだよ。そして、もし脱モチベートすることだけができるなら、最終的にはチームの全員が脱モチベートされちゃうんだ。

└

27歳で人を雇う頃には、モチベーションにかなりの差が出てくると思う。25年の経験（それは雇う人にとって「内在的」なものだよね）は、特に人生の初期には大きいよ。うつ病や皮肉、過去の経験など、モチベーションの基準が低くなる要因はいろいろあるしね。これも文脈によると思うけど、それが君が言ってることだと思うし、100%同意するよ。ある人は役割Aで活躍するけど、役割Bでは壁に頭をぶつけたくなるかもしれない。逆も然り、どちらでも「まあまあ」な人もいるしね。

Hacker Newsで議論の続きを見る

ハクソク