Home | Blog | Guide

ツール疲れは本物：エンジニアリングマネージャーへの処方箋

エンジニアリングマネージャーは多くのツールを抱えています。ツール疲れの仕組み、そのコスト、効果的なシステムレベルの解決策を解説します。

By Ellis Keane · 2026-03-31

火曜日の朝9時47分、あるエンジニアリングマネージャーはコードを1行も書いておらず、プルリクエストを1つもレビューしておらず、チームの誰とも実際のエンジニアリング業務について話していない。彼女はLinearのステータスをNotionのドキュメントに転記し、ある決定が実際に行われたのかただ議論されただけなのかを確認するためにSlackのスレッドを参照し、昨日見たFigmaのコメントがv2モックアップのものかv3モックアップのものかを思い出そうとしている──通知には判断するのに十分なコンテキストが含まれていなかったから。

あなたがエンジニアリングマネージャーなら、それをツール疲れと呼んだことがなくても、この朝に見覚えがあるはずだ。

問題の全体像

エンジニアリングマネージャーにとってのツール疲れは、実際にはツールが多すぎることではない（そう表現されることが多いが）。問題は、情報がどこにあるか、誰が置いたか、まだ最新かどうかという心理的モデルを維持する認知的オーバーヘッドにある。スタック内の各ツールは独立した情報源であり、エンジニアリングマネージャーの仕事は、それらの情報源を意思決定に使えるほど一貫したものに縫い合わせることに、いつの間にかなってしまっている。

実際にどのような状況かを具体的に見てみよう。6人のエンジニアを管理していて、会社がプロジェクト管理にLinear、コードにGitHub、コミュニケーションにSlack、デザインにFigma、ドキュメントにNotionを使っているとしよう。これで5つのツールだが、私たちが話すほとんどのスタートアップにとっては控えめな数だ。

その過程で、「エンジニアリングマネージャー」という肩書きは「ヒューマンAPIルーター」の丁寧な言い換え──互いに通信しないシステム間でコンテキストをシャトルすることを主な機能とする人──の同義語になってしまった。

これは例外的な朝ではない。これが基準だ。エンジニアリングマネージャーにとってのツール疲れとは、チーム全体で何が起きているかを把握する仕事が、いつの間にかフルタイムのデータ統合作業になっていることを意味する。そして誰もそうなるよう計画したわけではない。

stat: "77分" headline: "1日あたりの平均コンテキストスイッチ時間" source: "4週間にわたる社内タイムトラッキングに基づく"

なぜ悪化するのか

ツール疲れは複利のように増加する（自分たちのチームで起きるのを見てきた者として言う）。新しいツールを追加するたびに、そのツール自体のオーバーヘッドが増えるだけでなく、既存ツール間に維持すべき接続の数が増殖する。

ツールが5つあれば、10の組み合わせの接続がある。8つあれば28、12あれば66になる。エンジニアリングマネージャーはそのすべての接続を積極的に使う必要はないが、どれが存在してどれが壊れているかを把握する必要がある。接続が壊れている場所こそが、情報が失われる場所だから。

そしてエンジニアリングマネジメントにおける情報損失は抽象的なことではない。ブロッカーが解消されたことを知らなかったデザイナーが、次のイテレーションを始めるまでに2日待った。Linearのステータスが「完了」と表示されていたため依存関係が完了していると仮定したスプリントのコミットメントが、実際のPRはまだレビュー中だった。毎週の同期ミーティングで、最初の15分がみんながすでに個別に知っていたが共有していなかったことを確認するために費やされる──ツールがそれらのシグナルをつなげなかったから。

ツール疲れはツールの数についてではない。ツール間のギャップの数、そしてそのギャップを埋めることがエンジニアリングマネージャーの非公式な第2の仕事になっているという事実についてだ。

効果のないアプローチ

ツール疲れへの3つの一般的な対応策で、実際には効果がないもの：

それ自体のための統合。 直感は理解できる：問題がツールが多すぎることなら、ツールを減らせばいい。しかしエンジニアリングチームには正当な理由でツールに強いこだわりがある。「[オールインワンプラットフォームX]のプロジェクト管理モジュール」でLinearを置き換えようとすれば、反乱が起きる。ツールが問題ではなく、ツール間のギャップが問題だ。あるセットのツールを別のセットに交換しても、ギャップが移動するだけだ。

ダッシュボード。 そう、分かっている。「すべてを支配する1つのダッシュボード」の魅力はほぼ抗いがたく、すべてのエンタープライズSaaS企業がそれについてのスライドデッキを持っている。しかし私たちがテストしたほとんどのダッシュボードは、状態の読み取り専用スナップショットだ──物事がどこにあるかは示すが、昨日から何が変わったか、なぜ変わったか、それに対して何をすべきかは示さない。ダッシュボードを見ているエンジニアリングマネージャーは、数字の背後にある実際のコンテキストを得るために各ツールに行かなければならない。

より多くのミーティング。 これが最も辛いのは、とてもよく見られるからだ。ツールが互いに通信しない場合、チームは同期的なコミュニケーション（デイリースタンドアップ、週次同期、アドホックなチェックイン）で補う。ミーティングは問題を解決しているのではなく、壊れた情報フローを人間の帯域幅で覆っているだけだ。そして人間の帯域幅はチームで最もコストの高いリソースだ。

試みられること

ツール統合 – 5つのツールを1つに置き換える。エンジニアが反乱を起こし、オールインワンが5つのことを中途半端にこなす。
ダッシュボード – とにかく元のツールからのコンテキストが必要な読み取り専用スナップショット。
より多くのミーティング – 壊れた非同期フローを補うための同期的な情報転送。

実際に役立つこと

統合ではなく接続 – ツールを維持しつつ、ツール間のギャップを埋める。
シグナルルーティング – すべてではなく、変更したことと注意が必要なことを表面化する。
非同期コンテキスト配信 – 情報を要求せずに必要な場所と時間に届ける。

実際に効果があること

実際のエンジニアリングチームと接触しても生き残る解決策には、共通の特徴がある：人間に統合作業をさせない。接続をシステムレベルで構築し、エンジニアリングマネージャーが情報収集ではなく判断に時間を使えるようにする。

意図的な通知ルーティング。 ほとんどのツール疲れは、間違った情報が間違った場所に届くことから来る。ステータス更新とデザインフィードバックが混在するSlackチャンネル。積極的に作業していないリポジトリのGitHub通知。解決策は通知を少なくすることではなく、より適切にルーティングすることだ。チャンネルの規則を設定し（私たちはエンジニアリングのシグナルには#proj-[name]-eng、デザインには#proj-[name]-designを使う）、積極的に整理する。すぐに効果が出る具体的な自動化の一つ：PRのステータス変更をLinearの課題IDを含めてプロジェクトのSlackチャンネルに投稿するGitHub Webhookを設定する。それだけで朝のルーティンから「この課題にPRは存在するか？」という確認がなくなる。地味な作業だが、ノイズを大幅に削減する。

週次「情報発掘」の予算。 クロスツールの縫い合わせが今は避けられないと受け入れ、タイムボックスを設ける。私たちは月曜日の朝に30分を「金曜日以降ツール全体で何が起きたか」のスキャンに専用で割り当てている。スケジュールに入れることで、週の他の時間にそれが入り込まなくなり、タイムボックスを設けることで、ウサギの穴に入り込む代わりに時間が来たら止まれる。

クロスツールのシグナルルーティング。 これがこのカテゴリの向かう方向だ（そして、そう、これがSugarbugで構築していることだ）。エンジニアリングマネージャーが手動でLinear、GitHub、Slack、Figmaを確認して世界の状態を構築するのではなく、これらすべてのツールにAPIで接続し、関連する変更、決定、ブロッカーをルーティングするレイヤーだ。ダッシュボード（受動的）ではなく、あなたが注意を払う必要があることとその理由を積極的に伝えるもの──昨日からのすべてのSlackスレッドとすべてのPRコメントを読んだ経験豊富なチームリードがあなたにブリーフィングするのに近い。

現状の正直なバージョン：最初の2つの解決策は今日有効で、3つ目はSugarbugが構築中のものだ。まだ完成していない──シグナルフィルタリングをどのくらい積極的にすべきかはまだ決定していないし、ランキングモデルはまだ抑制したいノイズを表面化している。しかしコアアーキテクチャは機能している：各ツールのAPIコネクター、LLMベースのシグナル分類、そして人、タスク、ソース全体の議論をリンクするナレッジグラフ。「金曜日以降何が起きたか」のスキャンを77分ではなく数秒で処理する──それが私たちを続けさせていることだ。

エンジニアリングマネージャーの仕事は、5つのツールを1つの一貫した全体像に縫い合わせることであるべきではない。それは機械の仕事だ。人間の仕事は、その全体像をもとに何をするかを決めることだ。 attribution: Ellis Keane

よくある質問

シグナルインテリジェンスをインボックスにお届けします。

Q: エンジニアリングマネージャーにとってツール疲れとは何ですか？ A: ツール疲れとは、多数の断絶したSaaSツール間で業務を管理する認知的・運用的コストです。エンジニアリングマネージャーにとっては、LinearやSlack、GitHub、Figma、Notionの間で情報を移動させることに、実際の意思決定よりも多くの時間を費やすことを意味します。

Q: Sugarbugはツール疲れに役立ちますか？ A: はい──ネイティブなインテグレーションを通じて既存のツールに接続し、各ツールからのシグナルを分類して、重要な情報を一か所に集約します。最初のコーヒーを飲む前に5つのダッシュボードを確認する代わりに、必要なコンテキストが手元に届きます。シグナルフィルタリングの正確な仕組みについてはまだ改善中ですが（正直、取り組んできた中で最も難しいデザイン問題の一つです）、コアパイプラインは稼働しています。

Q: 典型的なエンジニアリングチームはいくつのツールを使っていますか？ A: 私たちが話すほとんどのチームは、チームの規模や機能によって8から14のSaaSツールを使用しています。問題はその数自体ではなく、ツール間のギャップでどれだけのコンテキストが失われるかです。8つのツールを持つ3人のチームと、9つのツールを持つ50人のチームを見てきました。数よりも、ツールが実際に情報を共有しているかどうかの方が重要です。

Q: エンジニアリングマネージャーはツールスタックを統合すべきですか？ A: 場合によりますが、通常は間違ったアプローチです。5つの専用ツールを5つのことを中途半端にこなす1つのオールインワンツールに置き換えても、根本的な問題は解決しません。本当の解決策は、すでに持っているツールを接続して、誰かが手動でコンテキストをコピー&ペーストすることなく情報が流れるようにすることです。本物の冗長性（例えば2つのプロジェクトトラッカー）を削減できるなら、そうしてください。しかし数を小さくするためだけに統合しないでください。