データの仕事は工程でロールを切り分けるとうまくいかない。IVRyの白水さん（@sorami）による、Data Product Orchestrator（DPO）という役割についての記事を読んで、改めてそう感じました。 記事では、データから価値を生む過程を「課題設定・技術探索・活用設計」として描き、それぞれが独立した工程ではなく互いに影響し合うものだと整理しています。 自分もいま分析・検証、Sansan Data Intelligenceのアプリケーション、マスタデータ、システム連携までを見ています。傍ら事業全社横断のデータ基盤も見ている。PdMとして考え続けているのは、この縦に長い範囲を「別々の担当領域」として扱うのか、「一続きの営み」として扱うのか、という問い。前者のほうが組織としては整理しやすい。けれど実際には、分析・検証で見えたことがマスタの設計判断を変えたりアプリケーションの優先度を変えている だからこそ、記事が言う「オーケストレーション」は関係者の調整のことではない、という整理に強く共感します。自ら手を動かし、文脈を持ったまま領域を行き来することで、初めてどこを変えるべきかが判断できる。Notebookで動いた時点で満足せず、業務の中で継続的に機能するところまで責任を持つという話も、マスタデータやアプリケーションのように使われ続けて初めて価値が出る資産を扱う立場からすると、とても実感があります。AIによって一人がまたげる範囲が広がりつつあるいま、境界をまたぐこと自体を役割として定義したのは筋の良い判断だと思う。 自分の組織でも、基盤・分析・アプリ・連携のあいだで得た学びを次の判断へ持ち帰るサイクルを強くしたい note.com/sorami_dev/n/n000c8…