はじめに

複数チームが絡むプロジェクトでは、「問題は把握しているが、自分には最終的な決定権がない」という立場で課題を前に進めなければいけない場面があります。

今回、データ連携基盤の処理上限(Lambdaのペイロードサイズ上限)にデータ量が近づいているという課題に対して、自分自身は意思決定者ではない立場から、どう調査・整理・エスカレーションを進めたかをまとめます。

発端:他チームからの指摘

この課題は自分で見つけたものではなく、別チームからの指摘がきっかけでした。「特定のデータについて、連携基盤側の処理上限(10GB)に近づいてきているのではないか」という懸念が共有されたところから調査が始まりました。

自分自身が最初の発見者ではない場合、まず「本当にリスクがあるのか」を自分の手で確認し直すところから始める必要があります。伝聞ベースの懸念をそのまま上に報告するのではなく、一次情報として自分で裏を取る、というステップを踏みました。

具体的な調査内容としては、対象データの増加傾向を確認し、このままのペースで増え続けた場合にいつ処理上限に到達するかを推定することに重点を置きました。

現時点で上限を超えているかどうかだけでなく、「あと何ヶ月/何回のリリースサイクルで上限に達しそうか」という時間軸を示すことで、対応の緊急度を関係者間で共有しやすくなります。単に「まずいです」と伝えるより、具体的な期限感を数字で示す方が、意思決定者が優先度を判断しやすくなると感じました。

この課題が厄介だったのは、対応自体が複数チーム合同のリリースとして動く必要があった点です。

合同リリースでは、各チームがそれぞれの担当領域のリスクを洗い出し、報告する必要があります。しかし、あるチームの調査が不十分だったり、リスクの粒度が他チームと揃っていなかったりすることもあります。

そうした場合、自分の担当領域だけを報告して終わり、というわけにはいきません。他チームの報告内容も含めて全体のリスクバランスを見て、抜けている観点があればそれを補い、マネージャーへの報告としてまとめ直すという役回りが必要になりました。

ここで意識したのが、単純に「A案とB案があります、どちらにしますか」という選択肢の提示だけで終わらせないことです。

決定権を持つマネージャーに判断を委ねる以上、選択肢を並べること自体は必要です。しかし、選択肢だけを並べて判断を丸投げすると、

という問題があります。そのため、選択肢を提示する際は必ず**「自分としてはこの理由でこちらを推奨する」という判断も添えて出す**ようにしました。最終的な決定権は無くても、判断材料としての「一次情報を持つ人間の意見」は加えることで、意思決定の質とスピードの両方に貢献できると考えています。

最終的にこの課題は、データを分割するという方向性で対応が決まりました。ただし、その分割の具体的な方式については、影響範囲が大きい担当チーム側で検討・決定してもらう形となり、自分の役割はあくまで「調査・情報収集・整理・エスカレーション」でした。

決定権がない立場であっても、

という動き方によって、課題を前に進める役割は十分に果たせると感じています。