エンジニアリングマネージャーのツールとtech stack: 正直な2026年バイヤーズガイド

チームを引き継いで6週間が経ちました。「tech stack」を実際に見る余裕ができたところ、状況はあまり良くありませんでした。プロジェクトトラッカーは誰も信頼していないJiraボードです。3つ前のsprintで誰かが200枚のチケットを一括編集して優先順位を壊したからです。Slackには47のチャンネルがあり、半分はアーカイブされているようでされていません。Notionは2024年に辞めたエンジニアが最後に編集した半分だけ書かれたrunbookの墓場です。「Goals_FINAL_v3」というGoogle Docがあり、全員が参照するが誰も見つけられません。前のEMが去り、コンテキストも去りました。

心当たりがありますか? あるはずです。これは新任EMが全員引き継ぐものであり、「stackを修正する」ために輝かしいツールをもう1つ買おうとする衝動は、まさにここまで悪化した原因です。

このガイドはその反対です。ほとんど削ること、統合すること、本当に重要な6つのカテゴリーを伝えるバイヤーズガイドです。実際の価格、実際のトレードオフ、そして月曜日から始められる30日間プランです。

ほとんどのEMのstackが壊れている理由

引き継いだstackは設計されていませんでした。蓄積されたものです。3年間に3人の異なるマネージャーが、それぞれ目の前の問題を解決するためにツールを1つずつ追加し、全体について考えた人はいませんでした。今は誰もstackを所有していません。チームは支払っている分の約30%を使っています。顧客のバグは3か所に存在します（サポートツール、エンジニアへのSlack DM、誰かのラップトップ上の個人のメモ）。1:1のメモは個人のドキュメントに散らばっています。更新日? 不明。年次自動更新が発火し、1万4千ドルの請求を事後に知ることになります。

修正はより多くのツールではありません。各ツールが担うべき仕事を決め、仕事ごとに1つのツールを選び、残りを削除することです。6つのカテゴリーでカバーできます。それがフレームワーク全体です。

コア6: EMのstackが実際に必要なもの

ツールリストではなく、jobs-to-be-doneで考えてください。stackが対応すべき6つのことがあります。カテゴリーごとに1つのツールを選ぶ。2つあれば、それが「どこで見つかるか?」というSlackメッセージを生んでいる重複です。

1. プロジェクト管理: 作業が存在する場所

これは誰も信頼していないもので、他のすべてを壊しています。

• Linear（Standard $10/ユーザー/月、Plus $14）は高速でこだわりがあり、50人以下のプロダクトエンジニアリングチーム向けに作られています。sprintの代わりにCycles、機能するキーボードショートカット、Jiraクローンに変形するのを抵抗するこだわりのworkflow。ソフトウェアをリリースするチームでそれを好んでいるなら、デフォルトの選択肢です。
• Jira Cloud Standard（$7.75/ユーザー/月）からPremium（$15.25/ユーザー/月）は、コンプライアンス、複雑な権限スキーム、またはAtlassianの他の世界との統合が必要な組織向けの安全な選択です。また12人のプロダクトチームで使うと、チームが静かに嫌うツールでもあります。そのどれも必要としない場合は。
• Shortcut（約$8.50/ユーザー/月）はより軽い代替品（旧Clubhouse）で、Jiraより硬直していなく、Linearほどこだわりが強くない。Linearがスタートアップ的すぎてJiraがエンタープライズ的すぎると感じるなら問題なし。

罠: 「会社がすでに持っているから」JiraにするThink。チームがツールを嫌っていればデータ品質はゴミになり、sprintレビューは演劇になり、Slackで真実を伝えることに戻ります。乗り換えのための政治的資本を使うか、Jiraの衛生管理が本当にあなたの仕事の一部であると受け入れてください。

決定ルール: 50人以下でプロダクトをリリースしているなら、Linearがデフォルト。監査/コンプライアンスのニーズがある50人超なら、Jira Premium。その間ならチームに1週間トライアルして、エンジニアに投票させてください。

2. コードとレビュー: エンジニアが1日中いる場所

これはほぼ決着がついています。だから簡潔に。

• GitHub Team（$4/ユーザー/月）がフロアです。GitHub Enterprise Cloud（$21/ユーザー/月）でSAML/SSO、監査ログ、セキュリティチームがいずれ要求するものが手に入ります。
• GitLab Premium（$29/ユーザー/月）が勝つシナリオはちょうど1つ: repo、CI、セキュリティスキャニングを1つのツールにまとめ、ベンダーを減らす代わりにやや使いにくいレビューUXを受け入れる意思がある場合。
• Bitbucketは、すでにAtlassianに深く入っていてMarkdownよりYAMLをより多く書くチームにだけ正解です。

正直な見解: GitHubがデフォルトである理由があります。ネットワーク効果は本物です（すべての請負業者と新入社員がすでにアカウントを持ち、すべてのOSSの依存関係がそこにある）。レビューUXはまだカテゴリーで最高です。チームの誰かがGitLabへの乗り換えを提案しているなら、どの具体的な問題を解決しているか尋ねてください。「1つのツール」は問題ではありません。それは好みです。

インフラを所有するStaff Engineerを採用しているなら、プラットフォームレベルの決定はその人が主導すべきです。何を探すかについてはStaff Software Engineer JDを参照してください。

3. インシデントとon-call: 午前3時の問題

これは安くするとコストが最も高くなるカテゴリーです。

• PagerDuty Professional（$21/ユーザー/月）は老舗です。成熟した統合、信頼性の高いページング、他のベンダーがまだ追いつこうとしているon-callローテーションのツール。
• Opsgenie Standard（$9/ユーザー/月）はAtlassianの代替品。安価で、小さなチームには問題なく、すでにAtlassianに支払いをしているなら当然の流れ。
• Incident.io（$16〜24/ユーザー/月、tiered）は急成長している新参者。Slackネイティブで、セットアップが圧倒的に速く、ポストモーテムとインシデントコミュニケーションのworkflowはカテゴリーで最高。チームがSlackで生活しているなら、最初に評価すべきものです。

罠: ローテーションを「とりあえず」Googleスプレッドシートに入れること。午前3時にページを受け、ローテーションが6週間前に誰かがPTOに入ったときに静かに壊れていることがわかり、何が問題かを修正する代わりに誰がon-callかを把握することになります。1席あたり$21を払ってください。今まで買う中で最も安い保険料です。

決定ルール: ローテーションに8人以下でSlackネイティブな文化なら、Incident.io。より大きなチームまたはすでにAtlassianにいるなら、Opsgenie。規制が厳しいか24/7で顧客向けの信頼性コミットメントがあるなら、PagerDuty。

4. 人事評価、1:1、フィードバック: ほとんどのEMが使いすぎるカテゴリー

実際に何が必要かについて正直になってください。

• Lattice（Talent Managementバンドルで約$11/ユーザー/月、フルHRISスイートはさらに高い）は洗練された選択肢。目標、評価、1:1、フィードバック、すべて1つに。30人以上のエンジニアがいてHRが賛同しているなら価値があります。
• 15Five（バンドルにより$10〜16/ユーザー/月）はわずかに人事評価管理に重点を置いた代替品。週次チェックインとOKRが強い。
• Officevibe（$5/ユーザー/月）はパルスサーベイがうまくできてそれ以外はほとんどない。

正直な見解: 30人以下のエンジニアなら、これらは何も必要ありません。1:1のメモ用の共有Notionテンプレート、Google Formsの四半期評価フォーム、カレンダーのリマインダーで、コストゼロで80%の価値が得られます。残りの20%は主にVPが欲しがるダッシュボードであり、VPはおそらく実際には見ていません。

罠は「フィードバック文化を改善する」ためにLatticeを買うことです。Latticeは人々を正直なフィードバックを与えさせません。あなたが1:1でそれをモデルとして示すことがそうします。ツールは文化を増幅させます。文化を作りません。1:1のケイデンスが壊れているなら、何も買う前に1:1のケイデンスを修正してください。

5. ドキュメントとRunbook: 1つだけ選ぶ。1つだけ。

• Notion（Plus $10/ユーザー/月、Business $15）はチームのお気に入りの内部知識ベースです。柔軟で、書くのが速く、エンジニアがすぐに理解するブロックモデル。
• Confluence（Standard $6.05/ユーザー/月、Premium $11.55）はエンタープライズのデフォルト。アクセス制御が優れ、Jiraとのネイティブ統合があり、書くのがあまり快適でない。
• GitBookは公開向けのエンジニアリングドキュメント（外部APIのデベロッパードキュメントなど）には良いですが、内部runbookには過剰です。

罠: NotionとConfluenceの両方を運用すること。これが私がEMのstackで見る「runbookはどこですか?」というSlackメッセージの最大の発生源です。1つを選んでください。会社にConfluenceのライセンスがあって逃れられないなら、runbookをそこに置いてNotionは個人メモにだけ使う。自由に選べるなら、プロダクトチームにはNotion、PMとファイナンスがすでにAtlassianで生活しているなら相互運用のためにConfluence。

6. CRMと顧客バグのフィードバックループ: ほとんどのEMのstackが無視するカテゴリー

ほとんどのEMのtech stack記事は5カテゴリーで止まります。これがそのギャップです。

チームが有料のB2B顧客向けにソフトウェアをリリースするなら、顧客のバグは会社名付きで来ます: 「Acme Corpのエクスポートボタンが壊れていると言っています。」CRMがループに入っていないと、それらのバグはサポートへのDMで死に、アカウントコンテキストなしにJiraに再入力され、エンジニアはブラインドで修正します。チケットとエンジニアリング作業の間のつながりが人の記憶だから、サポートチームは修正されたときに顧客に知らせることができません。

Rework（CRM/Sales Opsで$12/ユーザー/月、Work Opsで$6/ユーザー/月。rework.com/pricing参照）はこのループを閉じます。サポートチケット、顧客アカウント、エンジニアリングのタスクが同じワークスペースにあるので、エンジニアがバグを修正したときにどのアカウントが報告したかを確認でき、サポートチームは自動的に通知されます。EMを対象としたガイドで名前を挙げるカテゴリー6のツールはこれだけです。なぜなら代替案（ZendeskにJiraにSalesforceをZapierとお祈りでつなぐ）は、P1顧客のエスカレーションが金曜日の午後に来た最初の時に失われるエンジニアリング時間で$12/ユーザー/月より高くつくからです。

正直なフレーミング: 内部ツールだけをリリースするチームなら、このカテゴリーはまったく必要ありません。スキップしてください。有料顧客にリリースしてバグが会社名で報告されるなら、ここでの答えが必要です。問題は自分でビルドする（Zendesk + Jira + Salesforce + 統合のグルー）か買うか（Rework、1つのワークスペースで）です。

30日間のstack監査

これがこのガイドの実際の成果物です。4週間をブロックしてください。週に1つのことをやる。すべてを午後一度でやろうとしないでください。正直な答えは得られません。

第1週: 棚卸し

スプレッドシートを開く。1行に1ツール。列:

チームが触れる全ての有料ツールについて記入する。各管理パネルから席数を取得する。アクティブユーザーの割合は席数より重要です。ほとんどのEMは第1週に少なくとも2〜3件のゾンビ契約を見つけます（「18か月前にトライアルして解約し忘れた」ツール）。更新日は請求書または調達チームから来ます。更新日を誰も知らないなら、それが所見です。

約4時間かかると見込んでください。無駄な作業に感じるでしょう。それでもやってください。

第2週: コア6へのマッピング

棚卸しを通して各ツールに6つのカテゴリーの1つをタグ付けする。重複がすぐに目立ちます: NotionとConfluence、LinearとJira、SlackのDMと本物のチケットシステム、3つの異なるフィードバックツール、プロジェクトトラッカーがすでにやっていることと重複する「エンジニアリングメトリクス」プラットフォーム。すべての重複にマークを付けます。

6つのカテゴリーに当てはまらないものも所見です。チームが本当に必要とする7番目のものかもしれません（コードプラットフォームにバンドルされていないCI/CD、またはfeature flagツールなど）。もはや持っていない問題を解決しているツールかもしれません。

第3週: チームと話す

次の1:1のラウンドで、1つの質問をする: 「使わないようにしているツールは何ですか? 代わりに何を使いますか?」

シャドウstackが実際に何が壊れているかを教えてくれます。3人のエンジニアがJiraを避けてプライベートのLinearワークスペースを使っているなら、それは自律性ではなく、データの分断です。両方に支払いをしています。2人のエンジニアが検索が壊れているから会社のNotionを避けてObsidianでメモを取っているなら、答えはNotionを修正することであり、Obsidianをstackに追加することではありません。

機能するスクリプト:

「stackの監査をしています。判断なし、告げ口なし。使わないようにしているツールはどれですか? そしてその作業を実際にどこでやっていますか? 支払っているものと実際に使っているものの間のギャップを知りたいです。」

期待以上に正直な答えが得られます。エンジニアは、何かに対して行動すると信頼できるなら、何が壊れているかを喜んで教えてくれます。

第4週: 決定と統合

カテゴリーごとに1つのツールを選ぶ。毎更新の60日前にカレンダーにリマインダーを設定して、自動支払いではなく評価の時間を持つ。重複を解約する。6つのカテゴリー、それぞれの選択ツール、更新オーナー、jobs-to-be-doneを記載した1ページの「これが私たちのstack」ドキュメントを書く。ピン留めする。オンボーディングで参照する。

これは解約メールを送る週でもあります。遅らせないでください。ベンダーは留まるよう割引を提供します。それは去る理由であり、留まる理由ではありません。

よくある落とし穴

よく見る間違いの短いリスト:

• 文化の問題を修正するためにツールを買う。 Latticeはチームを正直なフィードバックを与えさせません。1:1ドキュメントテンプレートはあなたをより良い聴き手にしません。ツールは文化を増幅させます。作りません。
• 自律性のために各エンジニアに自分のツールを選ばせる。 ライブラリとエディタでは自律性を持たせる、そうです。プロジェクトトラッカーでは、いいえ。分断されたstackのコストは次のEM、新入社員、on-callローテーションに落ちます。
• 使用状況を監査せずに年次更新する。 エンジニアが7人のときに12席分を払うことになります。自動更新がデフォルトである理由があります。チェックしないと賭けています。チェックしてください。
• すべてのカテゴリーで最も安いツールを選ぶ。 時には$21/席のPagerDutyが$9/席の代替品がページを落とすから価値があります。見逃したページのコストは「月$12/席節約した」ではありません。
• 統合に過剰集中する。 stackを動かすために14のZapが必要なZapierのグラフが必要なら、stackが間違っています。それ自体で優れていて、選んだ他のものとネイティブに統合するツールを選んでください。

テンプレートとツール

チームのrunbookフォルダに保管する価値のある3つのアーティファクト:

1. Stack監査スプレッドシート（第1週の表）。四半期ごとに再実施する。
2. 1ページの「私たちのエンジニアリングstack」ドキュメント: 6つのカテゴリー、それぞれの選択ツール、1席あたりのコスト、jobs-to-be-done、更新日、オーナー。ドキュメントツールにピン留めする。
3. 1:1のシャドウstackスクリプト（第3週の質問）。6か月ごとに尋ねるよう、ローテーションの1:1質問バンクに追加する。

成功の測定

この監査を実施してから90日以内に、次が真実になります:

• 全ツール、1席あたりのコスト、オーナー、担うjobs-to-be-doneをすべて記憶から言える。
• 更新日は全ての更新の60日前のリマインダーと共に共有カレンダーにある。
• 6つのカテゴリーそれぞれにちょうど1つのツールがある。シャドウstackが縮小した。
• 顧客にリリースするなら、顧客バグへの単一の受付経路がある。
• 新入社員を1日以内にフルstackにオンボーディングできる。

これらの5つのうち3つでも真実なら、私が話すEMの90%より先を行っています。ツールは仕事ではありません。仕事はあなたを信頼するチームとソフトウェアをリリースすることです。stackはただ邪魔にならないようにするだけです。

関連記事

• エンジニアリングマネージャーの1:1のケイデンス
• 小規模エンジニアリングチームのsprint計画
• 最初のStaff Engineerを採用する
• エンジニアリングマネージャーのオンボーディング