【ITニュース解説】Como uma gestão despreparada pode custar a sua carreira

システムエンジニアを目指す皆さんにとって、理想の職場とは、技術を磨き、成長できる環境だろう。しかし、時には不適切なマネジメントがその道を阻むことがある。今回の事例は、そんな「準備不足なマネジメント」がいかに個人のキャリアに大きな代償を強いるかを示している。よく耳にする「会社はそういうものだから、諦めろ」という言葉の裏には、往々にしてマネジメントの能力不足が隠されているのだ。この物語は、大規模な企業や急成長するスタートアップだけでなく、小規模な企業でも起こりうる、身近な問題として教訓を与えてくれる。

物語の中心となるのは、とあるテック企業で働くマリアという人物だ。彼女が参加したプロジェクトは、SaaS（Software as a Service）と呼ばれるWebサービス全体を、フロントエンド（ユーザーが直接目にする部分）とバックエンド（データの処理や管理を行う裏側の部分）の両方から作り直すという大規模なものだった。プロジェクトが動き出した当初、マネージャーは手早く進めるために、市販されている既成のテンプレートを購入し、その上にシステムを構築するという方針を打ち出した。一見効率的に思えるこの選択だが、実は多くの問題を抱えていた。汎用的なテンプレートは、プロジェクトに不要な機能や古い技術（依存関係）を大量に含んでおり、開発チームの時間は、それらを削除したり、テンプレート由来のバグを修正したりすることに費やされてしまうのだ。

マリアは最初のテンプレートを分析し、その問題点を早期に察知した。膨大な量の不要なコードやバグが、プロジェクトの進行を大幅に遅らせると判断し、フロントエンドを一から開発することを提案した。この提案は一旦受け入れられ、マリアはその後7ヶ月間、一人で堅牢で効率的、そして信頼性の高い基盤を構築し続けた。しかし、その後新しいシニア開発者がチームに加わると状況は一変する。マリアは経験豊富な同僚との協力を期待したが、シニア開発者は再び新たなテンプレートの購入を提案し、それは技術的な議論もなく、一方的に採用されてしまった。その結果、マリアが7ヶ月かけて築き上げた努力は、あっけなく捨て去られることになったのだ。この決定は、どちらのアプローチが技術的に優れているかという視点ではなく、「経験年数の長い人物が最後に発言したから」という理由で下された。これは技術的な誤りではなく、プロジェクトを管理する「プロセス」の根本的な問題である。役職や在籍期間が長い人の意見が、何ヶ月にもわたる実績や検証された成果よりも重んじられる環境では、チームメンバーは新しい提案をしたり、試したり、検証したりすることに意味を見出せなくなる。

この不適切な決定がもたらす本当のリスクは、プロジェクトの最終リリースまで残り4ヶ月という、もはや延期が許されない段階で顕在化した。採用されたテンプレートの基盤となる技術にバージョンアップが適用された際、マネージャーはプロジェクトへのアップデートを指示したが、システムは完全に機能しなくなってしまったのだ。シニア開発者をもってしても、互換性の問題を解決することはできなかった。以前のバージョンに戻すことは、完成したプロジェクトがすぐに陳腐化することを意味するため、結局、システム全体をゼロから作り直す羽目になった。これは3度目のやり直しであり、ここでも新たなテンプレートが導入されたが、やはり古い技術やバグを抱えていた。当初1年未満でリリース予定だったプロジェクトは、2年以上経っても完成の見込みが立たない状態に陥ったのである。このように、プロジェクトの基盤を既製のテンプレートに依存させることのリスクは、一度も真剣に評価されることはなかった。既製品の購入は一見時間短縮になるように見えるが、実際にはコストを先送りしているだけであり、最終的にはより大きな代償となって跳ね返ってくる。納期と技術選択を別々の決定事項として扱うのは、アマチュアのプロジェクトマネジメントに他ならない。この意思決定の誤りのツケを払うのは、意思決定者ではなく、現場で何度も同じプロジェクトを書き直す開発者たちなのだ。

さらに、このプロジェクトでは内部のコミュニケーションも深刻な問題を抱えていた。特にマネージャーとシニア開発者の間の連携は常に不安定で、一貫性がなかった。マリアが疑問を解決しようとしても、一方はAと言い、もう一方はBと言うといった具合で、彼女は意図せず両者の板挟みになり、本来なら彼らが事前に調整すべきことを自らが調整する役割を担わされていた。マリアはこれらの意見の食い違いを共有の場で議論しようと試みたが、それが解決に繋がることはほとんどなかった。

加えて、日々の作業においても、指示の変更が頻繁かつ一方的に行われたため、開発作業は滞りがちだった。マリアが作成したプルリクエスト（コードの変更提案）は、何週間も、時には何ヶ月もレビューされずに放置され、複数の変更が衝突して解決不能な状態に陥ることが常態化していた。これにより、マリアは同じプルリクエストを5回、6回、7回と何度も修正する羽目になった。彼女の仕事は進むことも戻ることもなく停滞しているにもかかわらず、「あなたは十分な成果を出していない」「未処理のプルリクエストが多すぎる」といった成果不足を責める言葉が浴びせられた。しかし、これらは全て、レビューを放置していた人々の責任によるものだったのだ。同時に、彼女の努力がいつでも何の警告もなく無駄にされる可能性があるという状況も常に存在した。このように、二人の意思決定者が連携を欠いた結果、その負担は最も拒否する権限の少ないマリアにのしかかった。レビュー待ちで作業が止まっている人に成果を要求するのは、パフォーマンス管理とは言えない。それは根本原因を見ず、表面的な症状だけを指摘する行為に過ぎなかった。

このような不安定な技術的環境に加え、マリアは日々の会議で精神的な負担も強いられていた。会議では不快なジョークが飛び交い、時にはマリアがその標的となり、「道化役」にさせられることもあった。誰もその問題に気づいていないか、あるいは気にしていなかったようだが、マリアにとっては大きな苦痛だった。ある時、ジョークに対してマリアが笑わなかったことが、彼女が昇給を望んでいない、あるいは昇進を望んでいないという解釈をされ、皆の前でそのように告げられた。彼女は言葉を失ったという。笑わないことが昇給を拒否するサインと見なされることは、暗黙の、しかし効果的な強制の形であり、不快感を飲み込むことを強いるものであった。これは決して「気楽な企業文化」や「不器用なコミュニケーション」ではない。プロフェッショナルな評価が、業務成果とは無関係な感情的なパフォーマンスに結びつけられる問題である。ジョークに笑うことが、会社で成長するための非公式な条件となるのであれば、問題は笑わなかった側のユーモアのセンスの欠如ではなく、他者の不快感を取引材料として扱うマネジメントの姿勢にあるのだ。

日々のストレスが蓄積した結果、マリアの体は悲鳴を上げ始めた。最初のバーンアウト（燃え尽き症候群）は自覚がなかったが、2度目、3度目と症状は悪化し、不安、不眠、そして徐々にうつ病へと進行していった。免疫力も低下し、彼女はついに「限界だ」と助けを求めた。しかし、数分後に返ってきたのは「会社はそういうものだから、諦めろ」という冷たい言葉だった。これは、入社時に「家庭的で、友好的で、理解ある環境」を約束した会社とは正反対の反応であった。この段階では、準備不足だったマネジメントは、もはや無関心としか言いようがない。チームリーダーが全ての問題に即答できるとは誰も期待しないし、ましてや個人の心の健康に関する専門家である必要もない。しかし、どうすればいいか分からないことと、直接的な助けの求めに対して何もしないと選択することの間には大きな隔たりがある。後者は責任放棄に他ならない。

ついにマリアは解雇され、最初の感情は安堵だったという。しかし、数週間経つと、自分が何をすべきか分からなくなり、深い喪失感に襲われた。7ヶ月間かけて築き上げた仕事がたった一言で捨てられるなら、2年半もの間、自分の仕事が常に誤っている、疑問視されるものとして扱われるなら、一体自分は何ができるのだろうかという疑問に苛まれた。その経験は彼女をキャリアから遠ざけ、成長するはずだった環境で生き残るために費やした時間が、すべて無駄だったと感じさせたのだ。約6ヶ月後、マリアは少しずつ復帰し始め、自分の判断がほとんどの時間、あるいは常に正しかったことを理解し始めた。

マリアが経験した2年半の出来事は、決して彼女の技術的な未熟さによるものではなかった。テンプレートが機能しなかったり、コードが壊れたり、技術が更新されたり、バグが発生したりすることは、どんな開発チームでも日常的に起こりうることだ。彼女が自分自身を疑うようになった原因は、技術的な問題そのものではなく、7ヶ月分の成果が議論もなく廃棄されたこと、自分で検証できないプルリクエストのことで責められたこと、ジョークに対して沈黙したことが成長を望まない証拠として利用されたことだった。これらはいずれも、個人の能力を測る指標とはなり得ない。これらは、本来であれば組織を統制すべき立場にある人間がもたらした混乱を、個人がどれだけ吸収し耐えうるかを測るものに過ぎなかったのだ。

マリアの事例で描かれているのは、これまで構築されてきたものを評価せずに意思決定を下したマネージャー、声の大きい人間の意見を何ヶ月もの実績よりも重んじたマネージャー、そして自分が作ったチームとのコミュニケーションを調整できなかったマネージャーの姿だ。彼は不快感が評価の取引材料となるような環境を許容し、時には助長した。そして、切実な助けの求めに対して、「会社はそういうものだから」と答えることを選んだのだ。これは単なる「企業文化」で片付けられる問題ではない。特定の個人の責任であり、中小企業特有の問題でもない。マネージャーがオーナーである小さな会社であろうと、リーダーシップがその役割を果たさない大企業であろうと、改善を促す者がいない限り、この種の「準備不足なマネジメント」は多くの場所で存在し続ける。

優れたリーダーシップとは、常に正しい選択をすることではない。それは、プロジェクトの最前線で働く人々の意見に耳を傾け、彼らの努力を軽々しく捨て去らないことだ。責任を追及する前に連携を確立し、自分の価値を証明するために不快な思いをする必要がない環境を保証することである。これらが欠けている場合、コストはスケジュール遅延という形だけでなく、その環境を去った個人が「問題は自分自身にあった」と思い込み、キャリアに疑問を抱くという形で後になって現れる。もし、あなたが現在働いている、あるいは過去に働いていた場所で、このようなパターンを認識したことがあるなら、自分自身を疑う原因となったのが、本当にあなたの仕事だったのか、それとも方向性を示すべき人物の混乱だったのかを問い直す価値がある。そして、今、その重荷を一人で背負っているかもしれない同僚にも注意を払うことが大切だ。