エンジニア主導プラットフォームにおける「仕事作り」のガイドライン：4 つのシグナルを読み解く

1. 背景と前提

• エンジニアリング主導: プラットフォームチームは製品管理（Product Manager）や収益目標、市場防衛に依存せず、エンジニア自身が価値を創造することを前提としています。
• 仕事作り（Inventing Work）: エンジニアの主要な役割は「次に何を作るか」を見極めることであり、これを「仕事を作り出すこと」と定義します。
• シグナルの存在: 外部にはすでにチームが構築すべき方向性を示す**4 つの情報源（シグナル）**が存在しています。

2. システムが発するシグナル

システムからのデータや現状を分析し、改善点を探ります。

• クラッシュ主導の発見（Crash-led Discovery）

  • クラッシュと事後分析（Postmortem）は、修正や置換が必要な箇所を示す明確なシグナルです。
  • 利用者の影響や長期的な解消プロセスを観察することで、新たな構築物を特定できる場合があります。
  • 注意点: 事後分析のパターン認識は断片的になりがちであり、全体像を見失わないよう注意が必要です。
  • 欠点: チームを最新の失敗に偏らせやすく、最大の機会を見逃すリスクがあります（遅行指標）。

• コスト

  • クラウド請求書やデータベースクエリの最適化、VPC 間トラフィック削減は明らかなシグナルです。
  • ビジネスユニットの損益計算書（P/L）を参照し、ベンダー契約やコストセンターについて問いかける必要があります。
  • 核心的な教訓: 「ビルドか、買取りか（Buy vs. Build）」の決定は変化に応じて再考すべきであり、一過性のものではありません。

• 自らの労苦（Your Own Toil）

  • 単調で優先度の低い作業（Toil）は、単位経済を改善するべき仕事を示すシグナルです。
  • 罠: 自らの Toil を修正すると利益につながりますが、利用者の Toil を修正しないとユーザー体験は向上しません。

3. 利用者が発するシグナル

実際にシステムを使う人の声や行動から洞察を得ます。

• 継続的発見（Continuous Discovery）

  • ユーザーインタビューへの過剰依存を避け、週に N 人と話して継続的な対話を持つことが重要です。
  • インタビューの目的: 問題領域への共有理解であり、解決策の設計ではありません。
  • 質問例:
    • 「最近のタスクの詳細を教えてください。」
    • 「最大の痛み（Pains）トップ 3 は何ですか？」
    • 「その痛みの解決はあなたにとって何を意味しますか？」
  • 重要アクション: 利用者が提案する「ハック（臨時策）」を探り、真の課題には既に解決策があることを確認しましょう。

• 過負荷なユースケース（Overloaded Use-cases）

  • 当初設計された目的とは異なる使い方がされることは、プラットフォームが価値を発揮している証拠です。
  • ユーザーが「代わりのプロトタイプ」として構築したものを、統合候補として評価してください。
  • 判断基準: その解決策を必要とする他の利用者もいるか？

• パートナー化によるプロトタイピング（Partner-to-Prototype）

  • チームと利用者が協力し、問題解決のプロトタイプを作成するプロセスです。
  • プロトタイプはプラットフォームへの正式な約束ではなく、共同探索です。
  • 統合の可否も「他の利用者も同じ問題を抱えているか」という基準で判断します。

4. 組織が発するシグナル

内部の文脈や意思決定からヒントを探ります。

• OKRs

  • チームが設定・下された OKR は、すでに発明された仕事を追跡しています。
  • これらを起点として次のステップへ進みます。

• マネージャー反復ヒューリスティクス（The Manager-Repetition Heuristic）

  • 上司から頻繁に話を聞く事項（週 2 回以上）には、未解決の懸念が存在する可能性があります。
  • 注意: 組織の階層が上がるほど利用者から遠ざかり、HiPPO 効果の影響を受けやすいため、このシグナルは最も弱いものです。

• 移行による残滓（Migration Debris）

  • 移行には「肥満の尾部（Fat Tail）」のような採用曲線があり、遅れ者（Laggards）も存在します。
  • 新しい機能へのオンボーディングに苦戦するチームは、「その機能が不完全である」というシグナルです。
  • 中央値ユーザー: 移行残滓は「中央値」ソリューションでは対応できない利用者を示唆します。

5. 業界が発するシグナル

外部の動向やベストプラクティスを活用します。

• 記述的書式から規範的書式へ（Descriptive to Prescriptive Writing）

  • 既存システムについて詳細に書くこと（記述）は、改善すべき点が見つかる思考法です（Writing-as-Thinking）。
  • 設計文書を作成し、最先端の隣接システムと比較することで、陳腐化した決定を浮き彫りにします。

• 遅れはあなたの相対優位（Lag Is Your Arbitrage）

  • 業界トレンド（OSS リリース、論文など）への遅れはバグではなく、低コストで証拠を得られる機会です。
  • バンドリング/アンバンドリングなどのセクター振動において、業界全体が遅れる間隙を縫って進化する余地があります。
  • リスク: トレンドを取り残して「取り残された層（Straggler Set）」になるのは避けるべきです。

6. シグナルの活用法：優先順位付けと選別

11 のシグナルを一度に扱うことは不可能です。以下の軸で整理し、選択してください。

分類	特徴	例	注意点
議論完了・遅行指標	コストや事後分析など、結論は出ているが実行にはコストがかかる場合が多い。	クラッシュ、コストセンター、OKR	容易に見えるが、優先度が高いわけではない。
議論構築・先行指標	自ら議論を組み立てる必要があり、将来価値が高い。	過負荷なユースケース、パートナー化、記述的書式	最も価値があるが、労力を要する。
中間・取引型	移行残滓のように、現在の遅れが次の機会になる場合。	移行による残滓	次の移行の先行シグナルとなる。

• 過負荷なユースケース: シグナルが先行指標であり、議論も構築済みで生産環境にあり、最も推奨されます。
• パートナー化: 自らコストをかけて同じ証拠を購入する形ですが、価値があります。
• 記述的書式: 緊急性はありませんが、期限切れの決定に気づく確率は高いです。

7. まとめ：なぜ「仕事作り」なのか？

• バックログの問題: プラットフォームチームの失敗は「バックログが空」になることではなく、最も大きな声を持つシグナル（通常はクラッシュやトップ発言）だけでバックログを構築してしまうことです。
• 判断力: 「仕事を作り出す」とは、単にシグナルを見つけることよりも、「なぜこの一つを選び、他の十つを見逃すのか」を説明できる能力を指します。
• 非欠乏性: シグナルは常にあり、リストも網羅的ではありません。重要なのは選択と判断です。