みなさま、こんにちは。おくむら(@nori_broccoli)です。
人の時間を躊躇なく奪い去るダメなリーダーというのは世の中にたくさんいますが、そういった人は、最初はとても良い人を演じていたりして見抜くことが難しかったりします。そんなダメなリーダーに振り回されたことのある経験から、Geminiに今後の対応について聞いてみました。判断を投げ返すというのはとても良い方法だなと思いますし、開発時間が遅れてしまうこともリーダーの判断なワケですから、こちらに責任が降りてくることもありません。そういうやり方をしようとするとまた不機嫌になるというややこしいタイプのリーダーだったので困りましたが・・・最終的にはあらゆる営業ミーティングに出ないということで離脱したところ、プロジェクトが破綻しました。
Geminiの出した対策は今後の参考になるポイントがたくさんあるように思います。
開発時間を死守せよ！ダメなリーダーに振り回されないエンジニアのための鉄壁の対処法と兆候の見極め方
ソフトウェア開発におけるエンジニアの生産性は、ビジネスの成功に直結します。しかし、中には開発リソースの重要性を理解せず、目の前の営業機会を優先しすぎる「ダメなリーダー」が存在します。彼らはエンジニアを営業の席に同席させ、開発時間を奪い、断れば不機嫌になり、開発が遅延すればさらに不機嫌になるという、板挟みの状況を作り出します。本記事では、このような状況下でエンジニアが開発時間を守り、健全な環境を維持するための具体的な対処法と、そもそも巻き込まれないための予防策を解説します。
結論：開発時間を奪うリーダーへの対処戦略
開発時間を守るためには、「感情」ではなく「客観的なデータ」に基づき、「開発の優先順位」を明確に提示することが不可欠です。また、自身の業務範囲を明確に定義し、リーダーの不機嫌な態度を個人的な問題として受け取らず、業務上のリスクとして記録・共有することが重要です。
開発時間を奪うダメリーダーへの対処法：板挟み状況を乗り越える5つのポイント
ダメなリーダーに振り回されている状況下でも、エンジニアとしての責任を果たしつつ、自分の時間とメンタルを守るための戦略が必要です。
1. 客観的なデータに基づく交渉
感情論や個人的な要望としてではなく、客観的なデータを用いて、開発タスクと営業同席のトレードオフを明確に示しましょう。
- タスクの分解と見積もり（T-shirt Sizingやポイント）: 現在抱えている開発タスクを細かく分解し、それぞれに具体的な工数（時間またはストーリーポイント）を見積もります。
- 機会費用（Opportunity Cost）の提示: 営業同席に費やす時間が、どの重要な開発フィーチャーの遅延に直結するのか（例：バグ修正Aのリリースが3日遅れる）を具体的に示します。
- 時間管理ツールの活用: 実際のコーディング時間、会議時間、営業同席時間を記録し、リソース配分の偏りを可視化します。
2. 権限と責任の明確化を要求する
「営業に行くこと」と「開発を完了させること」という、矛盾した命令を受けている場合、最終的な意思決定（どちらを優先するか）の責任をリーダーに戻す必要があります。
- 「このタスク（営業同席）を優先すると、締め切りXが守れなくなります。どちらを諦めるか、ご判断をお願いできますか？」と問うことで、リーダーに判断を強制します。
- 優先順位の変更は、必ずメールやチャットなど記録に残る形で依頼し、決定事項として保存します。
3. 感情ではなく事実を記録する（不機嫌対応）
ダメなリーダーは、不機嫌になることで間接的な圧力をかけてきます。これに屈しないためには、その感情を「業務上のリスク」として処理する必要があります。
- 記録の徹底: 「〇月〇日、〇〇リーダーが営業同席を断った際に不機嫌な態度を取った」ではなく、「〇月〇日、リーダーは優先順位の決定を拒否し、プロジェクトのコミュニケーションに支障をきたす態度を取った」と事実のみを記録します。
- エスカレーションの準備: 開発遅延や不適切なリソース配分が深刻な場合、上司やHR部門に対して、感情ではなく、記録された事実（工数データ、コミュニケーション記録）に基づいて相談できるよう準備しておきます。
4. チーム内での連携と支援体制の構築
自分一人で対応しようとせず、チームの他のメンバーと連携します。
- 「開発を守る」という共通認識を持ち、誰かが営業に引っ張られそうになったら、他のメンバーがサポートに入る仕組み（例：代理出席、情報共有の仕組み）を作ります。
- 複数人で同様の問題を報告することで、個人的な不満ではなく、組織的な問題であると認識させやすくなります。
5. 自分の仕事の範囲を定義する
エンジニアのコアな役割は「コードを書き、問題を解決すること」です。営業支援はサポート業務であり、その時間には上限があることを主張します。
- 事前に「週に確保できる開発時間は〇時間、営業サポートは最大〇時間まで」と自己宣言し、それを超える要求には交渉の余地を残します。
ダメなリーダーを事前に見抜く：巻き込まれないための兆候チェックリスト
転職や異動の際、初めから開発時間を尊重しないリーダーのもとに就かないようにするための見極めポイントです。
1. リーダーシップの核となる判断基準の偏り
開発効率よりも、表面的な成果や外部との関係性を異常に重視するリーダーは危険です。
- 具体的な兆候:
- 開発プロセスや技術的負債よりも、「今月の売上」や「顧客の機嫌」を最優先事項として口にする。
- 技術選定や工数見積もりにおいて、エンジニアの専門的な意見よりも、営業やマーケティングの要望を圧倒的に優先させる。
- 常に緊急対応や割り込み業務が多く、明確な優先順位付けが機能していない。
2. コミュニケーションと透明性の欠如
情報を隠蔽したり、一方的なコミュニケーションを取るリーダーは、エンジニアの時間を勝手に支配する傾向があります。
- 具体的な兆候:
- なぜその作業が必要なのか、なぜ営業同席が必要なのか、目的や背景を説明しない。
- タスクや期限が頻繁に変更されるが、その理由がチームに共有されない。
- 質問や懸念を表明した際、論理的な回答ではなく、威圧的または感情的な反応で対応する。
3. 成果評価の基準の曖昧さ
エンジニアの評価基準が開発貢献度よりも、リーダーへの従順さや、営業支援の回数に偏っている場合、開発環境は崩壊しがちです。
- 具体的な兆候:
- 「頑張っている」といった抽象的な評価が多く、具体的な開発成果や品質向上の指標がない。
- 営業チームからの「協力的なエンジニアだ」という意見が、開発チーム内での評価よりも重んじられる。
FAQ（よくある質問）
Q1: 開発遅延を言い訳にするための効果的なデータは？
最も効果的なのは、「計画からの逸脱度」を示すデータです。以下の情報をセットで提示しましょう。
- 本来のタスクAの完了予定日。
- 営業同席（〇時間）によって発生した実質的な遅延工数。
- その結果、タスクAの完了予定日が〇月〇日に変更されたという事実。
Q2: 営業同席を断る際のベストな言い方は？
ただ「忙しい」と言うのではなく、「別の優先度の高いタスク」を理由に断りましょう。例：「申し訳ありません。現在、P0（最高優先度）のセキュリティパッチの修正に取り組んでおり、離席できません。このパッチを後回しにすると、リリース済みのシステムに影響が出ますが、それでもよろしいでしょうか？」
Q3: ダメなリーダーが改善する見込みはありますか？
リーダーが自身の行動の結果（開発遅延、チームの士気低下）を客観的なデータとして認識し、それを改善する必要性を自ら認めた場合に限り、見込みがあります。しかし、感情的な不機嫌さで支配しようとするタイプは自己認識が低いことが多く、改善を期待するよりも、対処法を確立するか、環境を変えることを検討する方が賢明です。