仕様と一口に行っても、GUIや他システム連携I/Fなど見た目で分かる外部仕様と、クラス設計や関数設計など作りの中身の内部仕様に分けられます。コードを書けない・書かないというなら、この内部仕様について触れようともしないし理解できていないのでしょう。外部仕様はもちろん、内部仕様もある程度は理解しているというのが理想ですが、PMやPOでテックバックグラウンドの弱い人は、そこまではできないという感じも居るでしょうか。せめて外部仕様は詳しく通じて、内部仕様も概要設計レベルでは抑えておいてほしいですね。

シニアエンジニアならコードを読める必要があるような気もしますが、ジョブディスクリプション次第なのでなんとも言えないです。

シニアエンジニアでもあり、プロダクトオーナーでもある、という状況が理解できなかったです。プロダクトマネージャーならまだギリわかりますが...。

シニアエンジニアでコード読めなくて仕様を調べられないのは問題ですが、プロダクトオーナーであれば詳細まで知らなくて良い思います。

プロダクト「オーナー」は、どちらかといえば「ユーザー」側の立ち位置で「こうなっててほしいよね〜」とか言う立場なので、プロダクトオーナーとしてはむしろそれで正しいような気もします。

プロダクト「マネージャー」がそれだったら、「お前もうどっか行けよ」となるとは思いますが。

プロダクトオーナーの役割っていうのがマーケティング寄りなのか技術寄りなのかによって、本来の期待がかなり振れ幅の大きいJDになるかと思いますので、この方が果たしてスキルがミスマッチなのかあるいは周りに誤った期待をさせてしまう状況なのかどちらに起因するのか見極めが必要ですかね。

シニアポリティシャン

スクラムにおけるPOの役割なら、詳細仕様を必ずしも把握はしていなくても良いと思います。

POに期待されるのは利用者やステークホルダーのニーズと期待値の調整と優先順位のヒアリング、実装のロードマップからバックログ化になるので、Howは開発チームだけで会話すれば良いのではないでしょうか。

もちろん、仕様を知っていることで調整が早く楽になるなら知っていた方が良いですし、ステークホルダーとのミーティングへ開発チームが仕様説明に常態的に駆り出されているなら、やってる事がスクラムじゃないので体制ややり方を見直された方が良いのではないかなと思いました。