概要
Platformチーム はエンジニア主導で動き、 プロダクトマネージャー がいないことが多い。 次に何を作るか を決めるのは主にエンジニアの役割。 仕事を「発明」するための シグナル はシステム・ユーザー・組織・業界の4方向から来る。 各シグナルの読み方と特徴を解説。 優先すべきシグナル の選び方が重要。
プラットフォームチームの仕事の「発明」
- Platformチーム はエンジニア主導で、 プロダクトマネージャー不在 が基本
- ロードマップ や 売上目標 がなく、仕事はエンジニアが自ら見つける必要
- チームが提供する 価値の最大化 が常に課題
- Staff Engineer の重要な役割は「次に何を作るか」を決める「仕事の発明」
- 仕事を発明するための 4つのシグナル ：システム、ユーザー、組織、業界
システムからのシグナル
クラッシュ主導の発見
- システムのクラッシュや ポストモーテム は明確な修正点や改善点のシグナル
- パターン認識が重要だが、 直近や大きな失敗に偏りやすい 点に注意
- 最も遅い指標 であり、ビジネスチャンスの発見には不向き
コスト
- クラウド費用 や ベンダー契約 などのコスト最適化
- 「アウトソース」と「自前化」の見直しは一度きりでなく、 継続的な判断 が必要
- チームやビジネスユニットの P/L 確認
自チームのToil（雑務）
- 目に見えないコスト であり、優先度が低くなりがち
- 自分たちのToil改善は 経済性向上、ユーザーのToil改善は ユーザー体験向上
ユーザーからのシグナル
継続的なディスカバリー
- ユーザーへの定期的なヒアリングで 課題の把握
- 「どんな作業で困ったか」「それを解決したら何が変わるか」などを質問
- ユーザーの提案は鵜呑みにせず、根本的な課題を深掘り
- 課題は 頻度でインデックス化 し、問題空間を可視化
オーバーロードユースケース
- 本来想定していない使い方をユーザーがしている事例
- その理由や背景を調査し、 他のユーザーにも共通かどうか を判断
- ユーザー自身が作った プロトタイプ として活用
パートナー・トゥ・プロトタイプ
- ユーザーと協力し、 新しいプロトタイプ を共同開発
- プロトタイプは 正式機能化の約束ではなく、検証の場
- 他ユーザーにもニーズがあるかが 吸収判断の基準
組織からのシグナル
OKR
- Objective and Key Results が設定されていれば、すでに「仕事が発明」されている状態
マネージャー繰り返しヒューリスティック
- マネージャーが同じ話題を短期間に2回以上出す場合、 未解決の課題 がある可能性
- 上層部ほどユーザーから遠ざかるため、 証拠が弱くなりやすい
マイグレーションのデブリ（残骸）
- プラットフォームの大規模変更後、 移行できない/しないユーザー が発生
- それは「現状の提供物が不十分」というシグナル
- 平均的ユーザーだけでなく幅広い層 への対応が必要
業界からのシグナル
記述的なドキュメント作成から処方的な提案へ
- 既存システムの 設計ドキュメント を作成し、業界の最新事例と比較
- 現状の設計上の課題や時代遅れの意思決定 を発見できる
- 「書きながら考える」プロセス
業界トレンドのラグを活用
- オープンソース、他社ブログ、論文、カンファレンス で最新情報収集
- 業界の「束ねる・分ける」トレンドは社内にも 遅れて波及
- ラグ（遅れ）を利用し、 他社の失敗や成功から学び、無駄を省く
- 遅れすぎると時流に乗り遅れるリスク
シグナルの優先順位と活用
- 11個ものシグナルを 同時に追うのは非現実的
- シグナルは「 どれだけ論拠が揃っているか」「 先行か遅行か」の2軸で評価
- ポストモーテム、コスト、OKR は論拠が明確、だが遅行指標
- 業界ラグ は強い論理だが証拠が外部、 マネージャー繰り返し は証拠ゼロ
- 継続ディスカバリー はユーザー課題を提供するが、仕様化は自分たちの仕事
- オーバーロードユースケース は実運用中の証拠があり、先行指標として最適
- パートナー・トゥ・プロトタイプ は自ら証拠を作るコストが必要
- マイグレーションデブリ は前回の遅行、次回の先行
- 記述的ドキュメント は気づきはあるが、緊急性・論拠は弱い
結論
- シグナルは 常に存在 し、上記以外にも多様
- エンジニア主導のPlatformチームの失敗パターンは「空のバックログ」ではなく、「 一番大きな声 のシグナルだけで埋まったバックログ」
- 仕事の発明は「どのシグナルを選ぶか」の 理由付け が本質
「発明する仕事」＝「要件工学」って、ちょっと変な表現だと思う。