とある昔、とある現場でのお話。

そのチームはアジャイルを志向しつつ、デザイナー／QAを含めると、小さなマイクロサービスの単位でも15名ほどのメンバーで共同作業をする現場だった。

その現場では、Googleスプレッドシートで課題管理をしていたが、Github Issues に管理を一元化しようとしていた。

移行計画当初は、デザイナーを含め Github に直接 Issue を起票しようという方向性で動いていて、デザイナーにも Github を利用する事を促していた。

実際にGithubでの運用が始まる直前。デザイナーが「このGithubってどうやって使ったらいいですか？」とPMに質問してきた。そのPMは当初の方向性を無視しデザイナーに対し「なかなかGithubでIssue書くのはハードル高いと思うので、GithubにIssueを追加するGoogleスプレッドシートをGASで作りますよ」（と言ってしまった。そのPMが自分でつくる分けでは無く誰かに作らせる前提なのに。

このPMにより、その組織は以下の将来価値を喪失した；

• Github に馴染んだデザイナーを育成する機会を失った。これは組織にとってだけでなくデザイナー本人のキャリアップのチャンスも奪った
• GoogleスプレッドシートからGithubにIssueを登録するためのGASを組むエンジニアが、他にコミットすべき開発の時間を奪った
• GithubにたてたIssueのステータスをデザイナーが直接閲覧するチャンスを奪ったために、他のPMがそのデザイナーと（無駄な）コミュニケーションをする時間が将来必要となり、本来もっと価値を生むコミットができたはずのPMの時間を奪った

PMは、そもそもが間接コストとなってしまう存在だ。だから何かとメンバーにこびへつらって無駄な仕事を請けてしまう。

それによりPMは自分の仕事（テリトリー）を増やすこととなり、そのPMの砂上の楼閣はどんどん大きくなっていく。

このPMは自分の仕事を守ることを目的として行動しており、組織やサービスに価値を与えることなんてまったく考えていない。

本来このPMがすべきだったのは、デザイナーが問題なくGithubを利用できるようにガイダンスする事である。

PMは本来、自分がいなくなっても自動的（自立的に）チームメンバーが行動できるレールを設計し、補助し、そして将来的には自分が別のロール（スクラムマスターやプロダクトオーナー）に移行したり、もしくは別の現場に移る事を目指すべきだ。それこそが、将来価値を産むPMである。