問題は本当にコミュニケーションか
コミュニケーションの問題の一部は組織設計にあり
会社という業態はフルスタックのスーパーマンでなくても事業がまわるように、ジョブディスクリプションによりロール分けし異なる専門性を持った人たちの組み合わせで事業が成り立つようにした枠組みと言えます。
Webサービスの開発・運営だとソフトウェアエンジニア、デザイナー、PM、営業、カスタマーサクセスだったりそういうのですね。
一方でロールのラップ範囲がゼロだと仮定すると人員の増減に対応できないです。組織拡大により特定のロールが余剰を抱えることもありますし、急な退職によって特定のロールが足りなくなることもあるでしょう。そういう意味で小さい規模の会社の方がフルスタック性のある人員で構成した方が人員の波に対応できるかもしれないですね。
間のボールのタスクというか一般にジョブ名から想起されるタスクと違うタスクを誰かがやらないと事業が進まない場合もあります。そういった時問題はコミュニケーションとされることもありますが、真の問題は組織構造やロール設計であることも多いです。
ジョブディスクリプションが曖昧だったり、違う専門性のロールの業務を一部肩代わりできる人員で構成していればそもそもコミュニケーションが不要な場合もあります。
PM忙しいの原因一覧
PMが忙しいのでエンジニアでも仕様を作って欲しい、デザイナーが忙しいのでエンジニアでもデザイン作って欲しいというのは割合よく聞く話で、Web開発のチーム構成でエンジニアが比較的マジョリティーでPMやデザイナーがマイノリティーなので、エンジニアがもっと他ロールがやっている作業できないかはしばしば議論の論点にあがることがあります。
とりわけPM プロダクト(プロジェクト)マネージャーが忙しいになりがちな肌感があって、例えば以下の理由があると多います。
- a) PMがPO(プロダクトオーナー)を兼務している
- b) B向けサービスで顧客要望の調整コストが高い
- c) PMがEMを兼務している
- d) PMがスクラムマスターを兼務している
- e) PM以外のメンバーの採用を妥協している
- f) エンジニア/デザイナーのみ採用拡大している
aはPMが事業責任者も兼務するパターン。創業CEOが第二事業に集中するのであと全部よろしくだったりで発生するが営業サイドのマネージャーまでやりだすと破綻する。
bはカスタマーサクセスだったりの人員比率が少し受託よりというより顧客の要望や要求が仕様反映されることが多いパターン。企業によっては開発側のPdMプロダクトマネージャーと要望取りまとめ側のPMM プロダクトマーケティングマネージャーを分けている。
cはプレイヤーばかり採用してPMがエンジニア/デザイナーのマネージャーも兼務しているパターン。管理業務に追われて仕様策定ができない。
dはPMがプロダクトマネージャーとプロジェクトマネージャーを兼務しているパターン。cに類似。メンバーが増えるにつれてスクラムマスターに近い業務が増えほかができなくなる.
eは文字通り採用に妥協した結果PMがデザイナーよりの細かいことをやらないといけなかったり、エンジニア出身のPMがレビューも細かくするパターン。実開発に入り手を動かす比率が高いと速度が出ない。
fは単にtwo pizzaルールを越えてPMが仕様策定を行っており、チーム分割に失敗しているパターン。
他にもありそうですが、共通点はPMが別ロールの業務をたくさん兼務していると破綻する確率が高いですね。
「エンジニアがPMに寄り添ってくれない」は本当か
そうやってPMが忙しくなってとあるタイミングでまわらなくなると「エンジニアがPMに寄り添ってくれない」という意見がでることがあります。(リード)エンジニアが仕様を作りデザインファイルを作りタスク管理もすればPMの業務が減るという意見ですね。
それはそれで理想ではあるものの、それら全部できるエンジニアは比較的稀な印象です。こういった間のボールはもめやすい部分ですね。解のひとつとしてジョブディスクリプション・ポーカーも以前提案しました。
また、業務委託のフリーランスだと業務委託内容以外はできないという法的制限もあるのと、冷たい言い方をすると転職が容易なエンジニアにとって個人の最適化としてとある会社でしか使えないスキルを覚える合理性が低い可能性はあります。
短期はエンジニア側が一部カバーするとして長期はどうするとPMの業務を減らせるでしょうか？
複数PM化する
PMx1、エンジニアx6、デザイナーx1のチームがあったとしてエンジニアのPM(に近い)業務比率が20%だとして20%x6=120%なのでPMをもう一人増員した方がエンジニアのジョブディスクリプションを減らせます。(実際に減らすかどうかは別の話）
PM忙しいとエンジニアがPMに寄り添ってくれないは独立事象で、前者の方が問題ならそれに見合った打ち手のほうが効率はいいです。スタートアップでも人数が増えてくるとPMの組織化が必要になります。
PMの複数人化は必ずしも機能軸の分割などで同職種をする必要もなくて、例えば事業責任者(プロダクトオーナー)とPdM(プロダクトマネージャー)をわけたり、開発側のPdM(プロダクトマネージャー)と要望取りまとめ側のPMM(プロダクトマーケティングマネージャー)を分けるパターンもあります。
PdM以外の業務を専任の人に任せる
PMがPdM以外の業務を兼務している場合
- エンジニアのマネージャーも兼務している場合、EMに任せる
- PMがスクラムマスターを兼務している場合、スクラムマスターかプロジェクトマネジメントをリードエンジニアに任せる
などの手段が有効です。
一方で世界的に例外的に解雇規制がゆるいアメリカと比べて日本の解雇規制は欧州と同様に高いです。チームにいろんな所属の人がいたり、一部まるっと外注しているチームもあり、シリコンバレー比ですべて社員でそろえられない肌感があり、日本の業態ではプロダクトマネジメントとプロジェクトマネジメントを完全分離しづらい建付けはあるように感じます。
エンジニアでなくデザイナーのジョブディスクリプション要件を上げる
以前した考察だと日本はアメリカに比べてデザイナーが市場に多いことがわかっています。
PMがワイヤーフレームも作るなんてのはよく聞く話ですし、PM、デザイナー、エンジニアだとPM<=>エンジニア、PM<=>デザイナーだと後者の方がロールとして近いです。そういう意味でエンジニアでなくデザイナーのジョブディスクリプション要件を上げるのも一つのやり方ですね。
エンジニアとエンジニア以外で評価制度を分けている会社はあるのですが、デザイナーの評価制度も別にもつと制度設計が難しい可能性もあって、例えばデザイナーの要件をあげて需要と供給の均衡点をエンジニアと同じにしてしまえばロールごとの評価制度の総数を減らせる可能性はあります。
まとめ
まとめです。
PM忙しいとエンジニアがPMに寄り添ってくれないは独立事象なので、エンジニアリング以外の業務の幅が広いエンジニアを集めておくのも有効だが、同時に
- 複数PM化する
- PdM以外の業務を専任の人に任せる
- エンジニアでなくデザイナーのジョブディスクリプション要件を上げる
も検討するとよさそうです。