エンジニアリングとプロダクトのデータサイロ
PMとエンジニアは異なるツール・言語・タイムラインで動いています。サイロがどう形成され、何が本当の解決策かを解説します。
By Ellis Keane · 2026-03-16
「プロダクト・エンジニアリングのアラインメント」は、いつのまにか職種の名前になってしまいました。同じSlackワークスペースにいて、同じスタンドアップに参加し、理論上は同じゴールを目指す2つのスマートなグループが実際に相手の状況を理解できるよう、そのためだけに専任の人を雇う会社が増えています。こうした状況を必要にしているエンジニアリングとプロダクト間のデータサイロは、人の問題ではありません。ツールの問題です。
PMとエンジニアは十分にコミュニケーションをとっています。問題は、彼らがまったく異なるシステムで作業していることで、それらのシステム間に生まれるサイロは構造的なものです – 現代のチームがツールを選ぶ方法のアーキテクチャに組み込まれています。「もっと頻繁にアラインしよう」という掛け声では、ツール自体が互いを認識していないという問題は解決できません。
2つの現実
ここではSugarbugを構築してきた自分たちの経験から話します。毎日これを体験しているので、抽象論より具体的な話の方が役立つと思うからです。
PM側（私たちの場合は主に私）はNotionを中心に生活しています。スペックはそこに書かれ、優先順位が追跡され、顧客との会話が記録され、機能リクエストが毎週増え続けるリストにカタログ化されます。Notionは「なぜ」が生きる場所です – なぜ何かを作るのか、顧客が実際に言ったこと、特定の意思決定の背景にある戦略的文脈。乱雑で、広がりがあり、一行のコードも書かれる前に最も重要な思考が起きる場所です。
一方、エンジニアたちはLinearとGitHubで生活しています。Linearにはタスク、スプリントサイクル、依存関係チェーンとブロッキングイシューが入っています。GitHubにはコード、プルリクエスト、実装の詳細について（願わくば）建設的に議論するレビュースレッドがあります。そこに「どのように」と「いつ」が生きています – 何がどのように作られているか、いつリリースされるか、何が邪魔しているか。
どちらの現実も正確で、どちらも不可欠で、完全に互いから切り離されています。その間のギャップが、要件が陳腐化し手戻りが積み重なる場所です。
データサイロがエンジニアリングとプロダクト間でどのように形成されるか
これが意図的な選択だと思いがちです – 誰かが情報を分けておくことを決めたと。実際には、誰も有害であることを意図しなかった完全に合理的な行動を通じてサイロが形成されます。
PMはNotionにスペックを書き、エンジニアリングチャンネルへのSlackリンクを張り、ハンドオフが完了したと考えます。エンジニアはスペックを読み、そこから3つのLinearイシューを作成し、作業を開始します。ここまではすべてうまく機能しています。
しかし、スペックが変わります – 顧客との会話が優先順位を変えたり、ビジネスの文脈が変わったりします。PMはNotionのドキュメントを更新し、変更についてSlackにメモを投稿します。コーディングセッションに没頭しているエンジニアは、数時間後までSlackメッセージを見ません。その時点で、古いスペックに基づいて3つの機能のうち2つを作ってしまっており、Linearの3つ目のイシューは既に存在しない要件を参照したままです。
ここで誰も不注意ではありませんでした。誰も「コミュニケーションに失敗」しませんでした。情報は一つのシステムに存在し、作業は別のシステムで行われ、それらをつなぐ組織は、適切な人が見る前に他のスレッドに埋もれてしまったSlackメッセージでした。
これはすべてのスペック、すべてのスプリント、すべての四半期にわたって繰り返され、ズレが積み重なります。プロダクトが起きていると思っていることとエンジニアリングが実際に作っているものとのギャップは、誰かが適切なタイミングでメッセージに気づくことに依存したハンドオフごとに広がります。
なぜ「より良いコミュニケーション」では解決できないのか
アクションアイテムが「変更をより積極的にコミュニケートする」というレトロに参加したことがあります。愛情を込めて言いますが、それは組織的に「もっと整理整頓しなさい」と誰かに言うのと同じです。実行可能に聞こえ、Confluenceページを生産的に見せ、問題を引き起こしたシステムについては何も変えません。私たちは同じレトロのアクションアイテムを3回実行しました – 確認しました。
コミュニケーションを改善してもエンジニアリングとプロダクト間のデータサイロが解決しない理由は、コミュニケーションはすでに起きているからです – データは存在し、意思決定はなされ記録されています。ただし、互いを認識していないツールに記録されているのです。
Notionは、スペックが3つのLinearイシューに分解されたことを知りません。Linearは、イシューの背後にある要件が2時間前にNotionで変わったことを知りません。GitHubは、レビュー中のPRが、PMのNotionボードで優先度が下がった機能を実装していることを全く知りません。各ツールは設計通りに機能しています – ただ、一緒に機能するように設計されていなかっただけです。
「週末の間に支払っているツールが静かに現実から乖離していないかを月曜日の朝に確認することに費やすことに、ある種の暗いコメディがある。」 – Ellis Keane
それで何が起きるかというと、PMはスペックが変わるたびにNotionからLinearへの変更を手動でミラーリングし、エンジニアはSlackでPMに「まだこれが計画ですか？」と聞き、リードは月曜日の朝にボードをクロスリファレンスしてズレを確認します。私たちは、理論上すでに互いを知っているはずのツール間の手動データ同期に相当することに、週に数時間を費やしているのを目の当たりにしてきました。
システムの修正が実際にどのように見えるか
2つのツール間のギャップを見たときの本能は、橋を架けることです – Zapierの自動化、Webhook、同期スクリプト。シンプルで予測可能なフロー（LinearイシューがDoneに移動したらNotionのステータスを更新する）には、それで十分機能します。
しかし、エンジニアリングとプロダクト間のデータサイロには、ステータスだけでなくコンテキストが含まれています。PMはステータスフィールドを変更しただけでなく、3つのLinearイシューのうち2つの「完了」の意味を変えるスペックの段落を書き換えました。単純なステータスWebhookは、差分ロジックとセマンティックマッピングを追加しない限り、要件レベルの変更を見逃します。ほとんどのチームはそこまで構築する機会がありません。
実際に必要なのは、単に「このNotionページはこのLinearイシューにリンクされている」だけでなく、「スペックのこのセクションがこのイシューの要件を説明しており、そのセクションが変更された」というように、ツール間でデータの関係を理解するものです。目標は、誰かが変更に気づいて伝えることに頼るのではなく、スペックの編集を影響を受けるイシューに自動的にマッピングすることです。
それが同期レイヤーとナレッジグラフの違いです。同期レイヤーはツール間でデータをコピーします。ナレッジグラフはデータがどのように関連しているかを追跡し、それらの関係が変わったときを検出し、知る必要がある人に変更を表示します。
私たちはこのように機能するようSugarbugを構築しています – PMとエンジニアがすでに使用しているツール（Notion、Linear、GitHub、Slack、Figma）をナレッジグラフに接続し、スペック、タスク、コード、会話間の関係を維持します。まだ早期段階です（正直なところ、スケールでセマンティック差分検出を信頼性高く行う方法についてはまだ多くを解決していません）が、コアグラフは機能しており、手戻りになっていたであろうスペックドリフトの状況をすでに捉えています。
エンジニアリングとプロダクト間のデータサイロは、人のコミュニケーションが悪いからではなく、ツールが構造的に切り離されているために形成されます。修正策は、コミュニケーションチャンネルを増やすことではなく、関係レベルでデータをつなぐことです。
今週できること
「Sugarbugを使うしかない」と言うつもりはありません。今すぐ、現在使っているツールで、プロダクト・エンジニアリングのデータサイロの最悪の影響を軽減するためにできることがあります。
クロスリファレンスを明示的に、双方向に、オーナー付きで作る。 すべてのNotionスペックには、それが生み出したイシューへのリンクが入った「Linearイシュー」セクションが下部にあるべきで、すべてのLinearイシューはソーススペックにリンクバックするべきです。スペックごとにクロスリファレンスを担当する1人を割り当てます – チーム全体ではなく、名前が入った1人を。私たちは「全員が責任を持つ」バージョンを試しましたが（予想通り）誰も持ちませんでした。リンクは時間とともにずれていきますが、担当者がいることで、ずれが発見されたときに誰にpingすべきかがわかります。
リマインダーではなくトリガーを持つ「スペック変更」の儀式を確立する。 スペックが実質的に変更されたとき（誤字ではなく – 実際の要件変更）、PMはNotionのタブを閉じる前にリンクされたLinearイシューを更新します。後でではなく、「機会があれば」でもなく – タブを閉じる前に。影響を受ける各イシューへのコメントは1行であるべきです: 何が変わったか、更新されたセクションへのリンク、そしてイシューの受け入れ基準がまだ有効かどうか。更新を物理的なアクション（タブを閉じること）に結びつけることで、誰かの記憶に頼るよりうまくいくことがわかりました。記憶こそがサイロが最初に形成された方法だからです。
15分間の金曜日優先順位マッチチェックを実施する。 1人が（毎週ローテーションで）NotionのPMのトップ5優先順位とLinearのエンジニアリングスプリントのトップ5を横に並べて確認します。質問は「これらは同一か？」ではありません – 同一にはならないでしょうし、それで構いません。質問は「これらのいずれかが積極的に互いと矛盾しているか？」です。PMの#1優先事項がスプリントのどこにもなければ、それは月曜日に話すべき会話であり、ステータス更新ではありません。
これらは手動プロセスであり、有効期限があります。5人のエンジニアと2人のPMでは、面倒ですが機能します。15人のエンジニア、3人のPM、そしてFigmaを混ぜるデザインチームになると、クロスツールの関係は誰も手動で追跡できないほど速く増えます。しかし、最悪のプロダクト・エンジニアリングアラインメントのギャップがどこにあるかを教えてくれます – そして、最終的にすべてを自動化するにしても、その診断価値は労力に見合います。
長期的な修正がSugarbugであれ他のものであれ（私たちは明らかに正しいものを構築していると思っていますが、私はバイアスがあります）、プロダクトマネジメントとエンジニアリングのコラボレーション問題は、ツール自体がセマンティックレベルでつながれ、人間がアプリ間でコンテキストスイッチするのではなく意思決定に集中できるようになって初めて解決されます。
手動のクロスリファレンスが機能しているなら、続く限りそれを使い続けてください。同じレトロのアクションアイテムをコミュニケーションについて繰り返しているなら、問題はあなたの人ではありません。データアーキテクチャです。
Notion、Linear、GitHub、Slackを一つのナレッジグラフに接続して、スペックの変更が適切なエンジニアに自動的に表示されるようにしましょう。
Q: プロダクト・エンジニアリングチームへのSugarbugセットアップにはどれくらい時間がかかりますか？ A: ツールごとの初期接続は数分で完了します – OAuthでLinear、GitHub、Notion、Slack、Figmaを認証すると、Sugarbugはすぐにナレッジグラフの構築を開始します。既存データを取り込んでスペック・イシュー・会話間の関係をマッピングし始めるため、1〜2日で実用的に活用できます。オンボーディングフローはまだ改善中ですが、アカウントを接続する以外の設定は不要にすることを目指しています。
Q: SugarbugはLinear、Notionまたは既存のツールを置き換えますか？ A: いいえ。Sugarbugは既存のツールの横に置かれ、それらをつなぎます – どのツールも置き換えません。PMは引き続きNotionでスペックを書き、エンジニアはLinearとGitHubで作業し続け、Sugarbugはそれらの間の関係を維持してコンテキストが移動中に失われないようにします。すでに使っているツールをつなぐ組織だと思ってください。
Q: SugarbugはNotionのスペックが変更されたとき、適切なエンジニアに通知できますか？ A: それがまさに私たちが構築している中核部分です。Notionでスペックが変更されると、SugarbugはどのLinearイシューがそれにリンクされているかを特定し、そのイシューに取り組んでいるエンジニアに変更を表示します。セマンティック検出の部分（どの変更が実質的で、どれが表面的かを把握すること）はまだ改善中ですが、クロスツールリンキングと基本的な変更検出は機能しています。
Q: 同期ツールとナレッジグラフの違いは何ですか？ A: 同期ツールはアプリ間でステータス変更をコピーします – LinearイシューがDoneに移動したら、NotionのチェックボックスをBuildします。ナレッジグラフはデータがどのように関連しているかを追跡します: このスペックがこれら3つのイシューの要件を説明しており、受け入れ基準が変わり、それがまだリリースされていない2つのイシューに影響します。その違いは、変更がステータスレベルではなくセマンティックな場合に最も重要です。
Q: プロダクト・エンジニアリングのアラインメントはコミュニケーションの問題ですか、それともデータの問題ですか？ A: 私たちの経験では、ほぼ常にコミュニケーションの問題と誤診されるデータの問題です。チームはコミュニケーションをとっています – ただし、互いを認識していないツールを通じて行われているのが実態です。それらのツール間のデータフローを修正することで、どれだけのレトロやsyncミーティングでも解決できなかったアラインメントの問題が解決される傾向があります。