1 ポイント 投稿者 GN⁺ 2025-08-18 | 1件のコメント | WhatsAppで共有
  • 大企業で1年間働き、これまでのスタートアップ、SME環境との極端な違いを実感した
  • 責任の所在の把握と社内プロセスが複雑化することで、小規模組織では問題にならなかった点が解決不能な課題へと変わる
  • 資源の浪費と採用基準の不均衡によって、組織の効率性とモチベーションに問題が生じる
  • 業務の緊急性、セキュリティ管理など組織内の主要な概念が、実際の意味とは異なり形式的・手続き的な行為へと変質する
  • さまざまな問題の中でも、能力開発、キャリア成長などの前向きな経験を見いだした

エンタープライズ経験 1年の振り返り

大企業とスタートアップの違い

  • $ENTERPRISEでの最初の1年を過ごし、これまでのスタートアップおよびSME(中小企業)との違いを経験した。
  • 社内ソフトウェア開発の経験不足が批判ではなく、むしろ前向きなシグナルであることを後になって認識した。
  • 観察した点を整理し、大企業の勤務環境の現実を紹介する。

小規模企業では問題なかったことが大企業では大きな問題に変わる

  • ツール関連のエラーを解決する際、責任者や担当者の特定に長い時間がかかる。
  • 組織内の情報共有不足や担当者変更により、非効率とコストの浪費が発生する。
  • 一時的な解決策はローカル設定のオーバーライドだが、根本的には組織構造上の限界である。

資源配分の非合理性

  • 小規模企業で十分な予算なしに働いていた経験とは異なり、大企業では過度な資源の浪費が頻繁に起こる。
  • 短期的なプロジェクトの失敗や不要なクラウド利用などが財務的な浪費につながる。
  • 実際の必要性とかけ離れた予算・資源管理が、業務へのモチベーション低下を招く。

一貫性のない同僚と採用構造

  • スタートアップでは実力ベースの採用が相対的な基準を保っている。
  • 大企業では実力と無関係な採用や構造調整が一般的である。
  • 特定の職位が業務能力と無関係であったり、レポートの品質に関係なく組織が維持されたりする現象が起こる。

業務の緊急性の解釈

  • スタートアップでは明確な緊急性が基準だったが、大企業では業務の多層的な意味解釈が必要になる。
  • 本当に緊急な状況(例:サービス障害)以外にも、形式的な緊急性が頻繁に発生する。
  • このような手続きの中では、真の業務優先順位を見極める能力が求められる。

形式化されたセキュリティ管理

  • セキュリティプロセスは組織にとって重要な役割を持つが、実際にはリスクに対する形式的な報告に偏重している。
  • 数値目標や指標達成のために意味が薄れたセキュリティ業務が日常化している。
  • エンジニアとセキュリティ担当者の間のコミュニケーションの非効率も存在する。
  • 誰もが数値だけを重視する文化が危険であることを強調する。

職級の無意味さ

  • "Head of Architecture" などの重複した役職が一般的で、役割が明確ではない。

不確実性を弱点と見なす組織文化

  • 大規模な組織改編と随時行われるリストラの中で、リーダーたちは「わからない」と言うことを禁句視する。
  • ドメインの複雑さにもかかわらず、リーダーシップでは即応性と自信だけが優先される。
  • その結果、過去の失敗が繰り返される構造が固定化される。

サイロ化されたエンジニアリングチーム

  • それぞれのエンジニアリングチーム(あるいは「帝国」)は独自の標準と文化を持つ。
  • 部門間の障壁が大きくなり、標準化やベストプラクティスの展開が難しくなる。
  • 各部門の自律性が、チーム間協力の制約要因として働く。

前向きな経験

  • エンジニアコミュニティへの参加を通じて、ソフトウェア開発に対する視野の広がりを経験した。
  • キャリア成長、メンタリングの機会、大規模ユーザー経験など、新たな満足感がある。
  • 専門性の高度化多様な同僚との協働教育と能力開発が積極的に奨励される。
  • 定期的な給与支給、職務の安定性といった安定面も長所として働く。

結論

  • 批判的な視点にもかかわらず、大企業の前向きな価値は明確である。
  • 今後、長い時間が過ぎたあとに変化した視点を改めて点検してみる意向である。

1件のコメント

 
GN⁺ 2025-08-18
Hacker Newsの意見
  • Remy's Law of Enterprise Software(関連リンク: https://thedailywtf.com/articles/graceful-depredations)は常に覚えておくべき。ソフトウェアが「enterprise」と呼ばれているなら、たいていろくでもない。冗談はさておき、記事の最後で挙げられていた前向きな点には興味を引かれた。いくつかは理解できたが、実際には問題を増やすだけに見える項目もあった。たとえば「実際のキャリア開発の機会がある」という話だが、キャリア開発が単にもっとお金を稼ぐという意味なら、ただ「もっと稼げる」と言えばよく、わざわざ言い換える必要はないと思う。そうでないなら、これまで挙げられてきた組織の非効率や問題の中にさらに深く埋もれること以外に、キャリア開発とは何なのか気になる。そして「数百万人が使うソフトウェアを作るのは満足感がある」というのも、そのソフトウェアが良くなかったりユーザーに害を与えたりするなら、それでもなお満足できるのか疑問だ

    • キャリア開発が単にもっとお金を稼ぐことなのかという問いについて言えば、人生について長く考えると、結局のところ自分たちはもっと大きなシステムの中で小さな役割を担っているという現実に向き合うことになる。そう考えていくと、「不当な社会の中で自分は正しくあり得るのか?」「小さな役割の自分が共同体に良い影響を与えるにはどうすればいいのか?」といった深い問いがついてくる。この問いへの向き合い方は人それぞれだ。変化の機会を求めて積極的に動く人もいれば、システムの中で無力感を覚えて、いっそ目を背ける人もいる。私の場合は自分たちの仕事に信念があり、会社でのキャリア開発は単なるお金ではなく、責任が増え、変化を起こせる力が高まることを意味する。非効率な組織で自分にできる選択肢は、会社を去るか、今の位置にとどまるか、組織の深部に入り込んで前向きな変化を作るかだ。「使われているソフトウェアが悪かったり有害だったりしたら満足できるのか?」という問いについては、有害な仕事にも満足すると答える人もいるだろうが、少なくとも私はそうではなく、自分の仕事には社会的に良い機能があると信じている。つまり「数百万人が使う、社会にとって前向きなソフトウェアを作るのは満足感がある」ということだ

    • 大企業でのキャリア開発は、お金以上の意味がある。たとえば、より大規模なプロジェクトをリードしたり、以前ならスタートアップ1社が作っていたような製品を社内でまるごと開発する機会がしばしばある。数年にわたって複数のプロジェクトに参加したり、より大きなチームを率いたりする経験も、大企業のほうが比較的得やすい。そしてソフトウェアが悪かったり有害だったりする場合は? スタートアップや小さな会社が無条件に優れているわけではなく、ケースバイケースだ

    • データサイエンティスト研究員、デベロッパーエバンジェリストのような職種を目指すなら、その仕事を支えられる組織が必要だ。マイクロサービスアーキテクトのような役割も、小規模組織には合わないが、3000人以上の大企業では歓迎される。エンジニアリングマネージャーのキャリアパスも、人材プールが十分にあってこそ意味を持つように、規模から生まれるキャリア開発の機会がある。ソフトウェアが悪かったり有害だったりすることもあるが、私たちが扱っているものが必ずしもエンタープライズソフトウェアである必要はないし、むしろそうでないことを願う

    • エンタープライズソフトウェアが本質的に悪いとは思わない。もちろん良いエンタープライズソフトウェアを作ることは十分可能で、複雑な要件を守りながらそれをやり切ること自体がかなりの力量を要する。ただ実際には、組織でユーザー体験にどれだけ気を配っているかが評価されることはめったにない。私は7年以上$ENTERPRISEにいるが、ユーザーに直接会ったのは一度だけだ

    • ソフトウェアが悪くても、有害でも満足できるのかという点については、多くのエンジニアが大規模な環境で働いていること自体に満足を感じたり、無力感から自分とは無関係だとみなしたりすることがある。本当にそのスケールを持とうとすれば巨大企業に所属するしかなく、結局はそこで繰り返されるアルゴリズム的ダークパターンや株主利益の最大化といった資本主義の構造に流れ込まざるを得ない

  • 抜けている点がある。新しいリーダーシップが入ると、既存メンバーを追い出して自分の息のかかった人たちで埋めることがある。そして毎年チーム名が変わるのに、実際にやっていることは変わらず、チーム名に「Innovation」「Discovery」「Leadership」のような単語だけが追加されることが繰り返される

    • そんなに頻繁にチーム名が変わるくらいなら、いっそ「Pikachu」みたいな名前で固定してずっと仕事したい。名前が何であれ重要ではないとみんな分かっていれば、名前変更はやめるはずだが、名前が変わるたびに文書を直して全体に知らせる無駄な手間と時間が大量にかかる

    • うちの組織には、Terraform CDKで作った内部インフラコードのライブラリがある。DatadogやPagerdutyに監視リソースを自動生成してくれる。ある日、必須引数だったteamが実質7か月ごとに変わるようなものだと分かって、削除してしまった

    • 私のライバルは、新しい会社に入るたびに、以前の同僚であるヘルプデスク全員や開発チームを少しずつそっくり連れてくる。理由は忠誠心だ。結果が悪くても不満を言わず、上層部に問題提起もしない。その人の会社で働いた元社員の話を聞くと、いつも同じ流れだ

      1. 問題点の診断(新しいMicrosoftパートナーCRMがないのが問題だと言う)
      2. 問題解決の名目で金を使う(そのCRMパートナーとMicrosoftのおかげで年3回ラスベガス出張)
      3. CRM導入に失敗(問題はスコープが十分大きくないからだと主張)
      4. もう一度プロジェクト範囲を調整(福利厚生はさらに増える)
      5. また失敗しそうな段階で新しい会社に転職し、元の会社には問題だけを残す
    • 「Excellence」みたいな単語がプロジェクト名に入っていると、だいたい信用できない

  • 本文の内容の大半は公的機関にも当てはまる。ただし、週末勤務がないこと、(技術的な)キャリア開発の機会があること、能力開発や教育が奨励されることを除けば似たようなものだ

    • 最初に出てくる楽しさや金銭的利益への言及も、公的機関にはあまり当てはまらない気がする
  • とても面白くて興味深い記事だった。エンタープライズで3年ほど働いている。技術的には成長しているが、実際には人、コミュニケーション、官僚主義についてもっと多く学んでいる気がする。予算やマウスに関するコメントにも共感する。ただ、$ENTERPRISEの財務的な安定性のおかげで、私はそのまま自分でマウスを買ってしまう。誰かが未承認のマウスに文句を言うかもしれないが……無視するか、マウス承認という偽の緊急性を大したことではないと受け流せばいい

  • こういう組織では到底耐えられない。給料が3倍でも、数か月で完全に壊れる

    • 報酬は、実際に必要な仕事量に反比例する

    • 向精神薬(ゾロフト)をかなり強く飲まないと、どうにか耐えられない

    • ときどき、金を優先して$ENTERPRISEで高給をもらい、十分貯めてから長期サバティカルに入ろうかと考えることがある。でも面接プロセスがきつすぎそうで、その考えだけでやる気が失せる。今は$MIDSIZENOLONGERSTARTUPにいるが、ここにもここなりに、私を消耗させる妙なことがいろいろある

  • 私も似たような環境で働いていて、この記事は痛いほど正確だと感じた。自分の仕事は問題を解決してソフトウェアをデプロイすることだと思っていたが、現実の組織の「真の優先順位(revealed preferences、関連リンク: https://en.wikipedia.org/wiki/Revealed_preference)」はまったく別だ。著者が小さな会社から大企業に転職した話のように、逆に大企業から小さな会社へ移った経験のある人がいるのか気になる。エンタープライズでの経験を小規模チームの面接でどうアピールすればいいかも聞いてみたい

    • 私の経験では、これはまるで二つの都市の物語だ。私も$ENTERPRISEでの無意味な時間の浪費にうんざりしていて、今では年収の20%を捨ててでも、小さくてもまともな場所で何かを成し遂げたいと思っている。ただ、この3年間で学んだことをネガティブな雰囲気なしに説明しようとしても、スタートアップ創業者たちは私の経歴をやや重たく見る。ジャングルで必要なサバイバルスキルと動物園で必要なサバイバルスキルはあまりにも違うので、動物園に長く居すぎたのではないか、という反応だ。逆に大企業の側も、内部プロセスや階層構造を理解している人を採りたがるので、スタートアップ出身者がこうした場所を受けるのも簡単ではない

    • 大きな会社から小さな会社へ移った経験があるが、会社の規模が大きくなるほど、解くべき問題は技術的なものよりも、人や社内政治の問題のほうがずっと大きくなる。大企業ではゴールデンハンドカフ(関連リンク: https://en.wikipedia.org/wiki/Golden_handcuffs)型の報酬で中核人材をつなぎ止めることが多く、そのため人は報酬を手放すまでは組織のさまざまな馬鹿げたことにもより長く耐える。「大企業を離れて、実際に変化を作りたかった」というストーリーで語れば、小さなチームではたいてい理解してもらえる

  • 大企業は、自分たちなりの成果物を一貫して提供することにしか関心がない。目標設定も、数字の達成、規制手続き、役員の判断など、さまざまな理由で決まる。私たちが考える人間的な合理性とはまったく別の領域だ

  • 元記事の「他にも帝国はある」について、実際にイギリス(手動QA)、エジプト(ソフトウェアのピラミッド)のほか、モンゴル(ある日突然、大量の要件を投げ込んで消える)、スペイン(あらゆる規則を完璧にしようとして、かえって摩擦ばかり増える)、日本(役員に叱責され、キャリアを自傷するような冒険に出る)、中国(会議の迷路に迷い込み、コミュニケーションが極度に秘匿的)といった感じの冗談も添えた

    • この記事は本当に楽しく読めたし、特にモンゴルとの戦争のたとえが面白かった。実際、歴史的にもモンゴルとの戦いは楽ではなかった
  • オフィス政治や経営陣の役割の重要性がよく伝わる、良い洞察だった

  • $ENTERPRISEに在籍して18か月目だが、現実に共感しすぎて痛いほどだ