開発体制について、管理者は常に頭を悩ませているだろう。
アジャイルでのスクラム開発は、チームにより生産性が高くなった　というプロダクトもあれば、生産性が落ちてしまった　というプロダクト千差万別だ。

自分が経験した所は生産性が余り良くなかった気がする

なぜだか振り返ってみる。

・POはスクラム体制のDeveloperと同様デイリーに参加はするのだがDeveloperメンバーの技術内容を把握し指導が可能なスキルの持ち主ではなかっではなかった。過去に実際アプリ開発を経験したり直近で「手が動かす業務を経験しているPO」なのか、「エンジニアのアサイン担当をする半営業的なPO」かによりチームの生産性にものすごく関係があると少なくとも自分は思う。

エンジニアのアサイン担当をする半営業的なPOである場合、Developerメンバーの技術把握が全く出来ず、何か問題が起きた場合その原因や理由さえ全く理解できない（または過去に開発経験がない。そして理解、学習さえしようとしない！ そもそもなぜかこの手のPOまたはその上の役職が世の中にはびこっているのかの意味がわからない）
更にはDeveloperチームとは名ばかりでコード書けないメンバー比率が低いと負荷が必然的にコード書けるメンバーに偏るに決まってる。

その辺りがボトルネックになりPOと実際に手を動かせるDeveloperメンバーとの間に大きな壁が出来てしまう。
PO自身が理解できないので、目先で起きている問題を解決しようとせず曖昧なまま重要問題を宙に浮かせたままにしておく。そして顧客に回答期限を迫られた時点で、PO自身のスキルでは解決不可能である事実（要するにPOは開発経験者ではない、新しい技術がわからない、例えばWebであればJSP等のレガシー環境でしか開発した経験がない。。。最悪なんちゃってお飾りPO）である事がDeveloper全体にバレ、POが多忙なエンジニアの時間を割き、いきなり差し込みタスクを入れてくるのだ。（そしてこれらのPOの方って大手SIerの社員だったりする事が多かったりする）
スクラムで時間管理しているのに、どちらかというとPOのアラート対応要員みたいになってしまってくる。
しかもその「アラート対応」をタスク化せず、秘書のように使いっパされると知らない間にパシリエンジニアと化して裏強制残業させられる。。

実際にコードを改修する「フロントエンド」「バックエンド」メンバー同士は会話が弾むのだが、POがDeveloper経験者でない場合（敢えて説明をしてもどうせわからないだろうからーーと「大丈夫です。」といって　残業して影タスクを背負い込んでいたメンバーも居た。
Developerの「どうせPOはｘｘ知らないから説明しなくていいや」体制で会話している方が結構多いのですが、この姿勢もどうかと思う事がある。
更にいうとPO側もわからなくても「理解する」という姿勢も欲しいなーと思ってみたりします。要するに「歩み寄り」の姿勢が欲しいのですが、何故か諦めの姿勢。

工数が増えそうだと思った場合、人員で解決するのも辞めて欲しい。
逆に足引っ張る場合の方が大きかったりする。
なんでだろうか。令和の世の中になってもレガシー頭の人がPOをやると
チームに歪が起きてしまう。

これはあくまで自分の例だが、聞くと知人Developerも同じ理由でため息ついていました。。「スクラム」　という形を完璧にこなそうとその体制を維持する事だけに神経を注ぐスクラムマスターもちょっとヤバめ。
開発経験積んでスクラムマスターをせよ。と思ったりする。
今、何が優先なのかを見極める臨機応変さと体制を並行して柔軟に考える事ができるスクラムマスターであってほしい。管理に立つのにDeveloperの状況が見えない鈍感なPOとかスクラムマスターなら、スクラム体制をやらない方が進捗率上がる気がして仕方なかった。。そんな経験談をつらつらと。
経験してみないとわからない事って多いですね。
まあそこを改善できなかった自分にも力が無かったというオチでした。

『管理者には開発経験あって実際コード書ける人になって欲しいぃーーーーーーーー！！！』という叫びのしめでした！