この記事は「GoQSystem Advent Calendar 2025」8日目の記事です。
こんにちは、GoQSystemでバックエンドエンジニア兼マネージャーをしている佐々木です。
この記事について
マネージャーになってから数々の失敗を経験し、4つの重要な学びを得ることができました。 指示を出す際の前提情報の重要性、相談・報告の適切な順序、障害対応における役割分担の大切さ、そして直接対話することで見えてくる状況があることです。
今もまだ学習の途中ではありますが、同じような立場で悩まれている方の参考になれば幸いです。
マネージャー職に向き合う
私はもともと保守運用を担当しており、コードを読み解いて原因を特定し修正することや、既存機能の改善作業に集中していました。 そのためマネージャー職については経験も知識も不足しており、正直なところ不安を感じていました。
しかし、社内で開催された『リーダーの仮面』の輪読会に参加したこともあり、せっかく任せていただいたのだから、会社の利益に貢献するためにも責任を全うしようと考えるようになりました。
以前の失敗：業務をすべて自分で抱え込んだ
マネージャーになった当初、役割や責任範囲について理解が不足していました。 その結果、目の前の業務に対応することに終始し、本来すべき仕事を見失っていたと反省しています。
特に反省しているのはPRレビューへの取り組み方です。他メンバーの作業を進めることが最優先と考え、ほぼ全員のPRに目を通そうとしていました。 しかし結果としてレビューに多くの時間を費やし、自分が本来担当すべき開発業務に支障をきたすようになりました。
最近社長から「3割が自分の仕事で、7割の仕事は他の人に振る」と教えていただき、今後仕事していくうえでの目安にしようと決めました。
学び1：指示には前提情報と完成イメージを示す
仕様策定の依頼において、私の準備不足が原因で大きな問題を引き起こしてしまいました。
メンバーに仕様検討を依頼する際、判断基準や完成イメージを十分に整理せず、関連ドキュメントを共有するだけで依頼してしまいました。その結果、レビューの段階で抜け漏れを繰り返し指摘することになり、メンバーに不必要な負担と手戻りを強いてしまいました。
ドメイン知識を持たないメンバーが、ドキュメントのみで考慮すべき要件をすべて把握することは困難です。私が責任を持って前提条件を整理し、口頭で質疑応答をしながら共有するべきでした。
また、「過去に類似機能を実装した際はこのような課題があった」「この仕様変更は他機能に影響する可能性がある」といった経験に基づく情報を事前に提供していれば、手戻りは防げたはずです。依頼する側として必要な情報を整理し提供する責任を果たせていませんでした。
学び2：相談には適切な順序がある
ある定型業務が遅れがちであることに気づいた際、適切にエスカレーションをせず、いきなり全体会議で指摘してしまうという失敗をしました。
営業部の上長から「宿題をやっていない生徒がいても、いきなり校長先生に報告はしないでしょう。まず担任の先生に相談するはずです」というご指摘をいただき、自分の行動の問題点を理解できました。
相談や報告には、問題の性質に応じて適切な手順があります。今回のような個人の作業進捗の問題は「宿題をやってこなかった」レベルの話であり、まず直属のリーダーに相談すべき案件でした。一方で、もしハラスメントや重大な規則違反のような深刻な問題であれば、上位の責任者に直接報告することが適切な場合もあります。
まず当事者と直接状況を確認し認識を合わせる。必要に応じて直属のリーダーや同じ階層の関係者に相談する。それでも解決が困難な場合に、適切な責任者に報告・相談する。このような段階的なアプローチを取らず、問題の重要度を見誤って組織の秩序を乱してしまったことを深く反省しました。
学び3：障害対応は役割を分担する
障害発生時に、マネージャーである自分が真っ先に状況を把握して社内へ共有しなければならないと考えていましたが、これは大きな誤解でした。
実際には、チーム全体で効率的に対応するための役割分担と指揮が求められていました。
該当機能に精通したメンバーに状況調査を依頼し、別のメンバーには並行して影響範囲の特定と暫定対策の検討を担当してもらう。マネージャー陣は全体の状況把握と上長への報告・相談に集中し、他部署や社外への連絡内容については事前に上長のレビューを受ける。このような役割分担を明確にすることで、迅速かつ正確な対応が可能になりました。
この経験を踏まえ、事前にチーム内で障害対応の役割分担や手順を決めておくことで、混乱を避け、後から対応方針について指摘を受けるケースも減りました。 一人で抱え込まず、チームの専門性を活かすことの重要性を学びました。
学び4：口頭で話すと見えることがある
チャットでのやり取りだけでは状況把握に限界があることを痛感し、口頭で話す機会を増やすようにしました。
実際に口頭で話すことで、文字だけのコミュニケーションでは見えてこなかった重要な情報を把握できるようになりました。
例えば、タスクが進んでいないと思っていたメンバーが、実は要件の理解に課題を抱えていたこと。調査作業は継続しているものの、中間報告の習慣がなかったため進捗が見えていなかったこと。緊急度の高い別業務の対応に時間を取られており、予定していたタスクに着手できていなかったこと。これらの状況は、チャットの履歴を確認するだけでは把握できませんでした。
また、画面共有をしながらメンバーの作業手順を確認することも非常に有効でした。想定していた手順と異なる操作をしていたり、効率的でない方法で作業を進めていたりすることに気づけます。このような直接的なコミュニケーションの機会を継続的に設けることの重要性を実感しています。
まとめ
マネージャーとして経験した失敗を通じて、4つの重要な学びを得ることができました。
- 指示を出す際は前提情報と完成イメージを丁寧に共有する：業務知識を持つ側の責任として、必要な情報を整理し提供する
- 相談・報告は適切な順序を踏んで行う：問題の性質を見極め、組織のルールに従って段階的にアプローチする
- 障害対応は一人で抱えず、役割を分担する：チームの専門性を活かし、効率的な対応体制を構築する
- 直接話す機会を確保する：テキストベースでは見えない状況を把握し、適切なサポートを提供する
これらの学びは、マネージャーの本質的な役割である「チーム全体の成果を最大化する」ために必要不可欠なものでした。 メンバーを成功に導き、組織の秩序を保ちながら効率的に問題解決し、緊急時にはチーム全体の力を結集し、メンバーの真の状況を把握して適切なサポートを行う。 これらすべては、自分一人で処理するのではなく、チーム全体の力を引き出すマネージャーになるための基盤となる技術です。
おわりに
マネージャーとしてはまだまだ学習途中であり、今後も多くの課題に直面することと思います。 しかし、失敗から学ぶ姿勢を大切にし、チームとして良い成果を出せるよう努めてまいります。
同じような立場で試行錯誤されている方の参考になれば幸いです。最後まで読んでいただき、ありがとうございました。
