職種に求められる役割やスキルは環境変数次第だよね、という雑記
最近以下のような問いによく出会います。
「プロダクトマネージャーはどこまでを担うべきか」
「スクラムマスターはどこまで踏み込むべきなのか」
「デザイナーとPMの境界線はどこか」
「プロダクトマネージャーが持つべきスキルは何か」
要は「職種の定義」というやつですね。それぞれの職種が一般的にどのような役割とスキルを持つのが望ましいのか、というような議論をあちこちで目にしますし、意外とこれ盛り上がりますよね。おそらくそういう記事はPVを集めやすいのだと思いますし、私も昔そういう記事を書いたことがあります。
ただ、私は最近「どうでもええやん」と思うようになりました。
それは、これまで何度か転職をして様々な環境で様々な役割を担い、様々な人たちと仕事をしてきた中で、「職種に求められる役割やスキルは、周りの環境によって決まる相対的なものである」と確信を持ったからです。事業ドメイン、事業フェーズ、プロダクト特性、プロジェクト特性、組織規模、組織文化、組織状況など、様々な環境変数によって今求められる役割やスキルが決まります。
「シリコンバレーはこうやってます」みたいな情報は確かにキラキラして参考にしたくなりますが、自分の環境が持つ変数と、シリコンバレーの環境が持つ変数はどれだけ同じなのか？を考えないといけません。変数が異なるなら、その真似をしても今の環境では成果につながらない可能性が高いです。
pmconf2021のRetty 野口さんの発表にあった「Rettyに求められるPMの必要スキルの定義」のように、自らの環境の変数を踏まえて定義されたものは、この組織で活躍するために必要な指標なので、非常に有用なものだと思います。
ただ、そういう環境変数を考慮しないで「この職種にはこのスキルが必要」「ここまでがこの職種の役割であるべき」と一般的に定義されたものを盲目的に信じてもあまり効果はないと思いますし、それに囚われ過ぎるとどこの組織にもハマらない凡庸な人材になってしまうリスクがあると思っています。
もちろん、今所属している組織が持つ変数がよくわからず、かつ組織内にロールモデルとなる人がいないような環境であれば、「一般的な定義」を参考にして役割や得るべきスキルを見出していくのはアリだと思いますが、それが今の環境にハマっているかどうかは別問題です。一時的に成果は出たとしても、併せて環境変数を見抜いて役割をチューニングしていく動きも求められます。
また、逆に「一般的な定義」や「他社の定義」を自分の環境で実現するために、環境変数の方を変えにいくアプローチもあります。上の例で言えばシリコンバレーのやり方ができるように環境をシリコンバレーのように変えていく、という使い方もアリだとは思います。ただ、本当にそれが今の環境に求められていることなのかは見極めるべきです。
つまり言いたいのは「一般的な定義や他社の定義を参考にするなら、その裏にある環境変数も理解しようぜ」ということです。もちろんめちゃくちゃ難しいことを言っているのは自覚してますが、それをやっていかないとただの自己満足に終始してしまうリスクがあると思うのです。なので書籍や他社の事例を見て参考にしたい際には、可能な限り発信者に背景を聞きにいくことをお勧めします。
そしてこれは職種の役割に限らず、フレームワークにも共通する話です。スクラムとかOKRとか、イケてる企業が使ってるフレームワークが自分たちにも有効かどうかはやはり変数次第です。これらのフレームワークを活用したいなら、変数の方を合わせてから導入するべきだと思います。例えばOKRの恩恵を受けたいなら、チームへの適切な権限委譲をしないといけません。ただのTODOリストになってしまいます。
以上、最近よく思うことを雑に書いてみました。
昨年はブログの更新頻度が著しく減ってしまったので、今年はあまり準備せずに気軽に書いていきます。
