専門外の仕事にどこまで口を出すか。PMと専門家の境界線を考える
少し前に、プログラムを書かないPMが細かなC#のコーディング規約を決めた、という話が話題になっていました。
この話を見ていて改めて考えたのが、「専門家ではない人が、専門領域にどこまで関わるべきなのか」という問題です。
PMやプロデューサーが、チームのすべての仕事を自分でできる必要はありません。むしろ、ゲーム開発のように専門分野が細かく分かれている仕事では、それは現実的ではないでしょう。
ただし、専門外だから何も言わない、という話でもありません。
大事なのは、何を判断し、何を専門家に任せるのかを分けることだと思っています。
私もゲーム開発では専門外の領域がたくさんありました
私はもともとゲームプログラマーです。
プログラムであれば、設計や処理負荷、通信、メモリ、描画などについて、ある程度踏み込んで確認できます。
Unityであれば、
「この処理を毎フレーム動かして大丈夫か」
「オブジェクトを大量に生成していないか」
「このクラスに仕事を持たせすぎていないか」
といったことは、コードやProfilerを見ながら話せます。
一方で、ゲームを作るにはプログラム以外にも多くの専門家が関わります。
アート、モーション、エフェクト、ゲームデザイン、サウンド、シナリオ、UI、QAなど、それぞれに異なる知識と経験があります。
私は画面を見て、
「攻撃が当たった感じが弱い」
「何が起きたのか少し分かりにくい」
「この演出は少し長く感じる」
と意見を言うことはできます。
しかし、
「エフェクトをこの形にしてください」
「カメラをここから何フレームで動かしてください」
「このモーションを○フレーム延ばしてください」
というところまで行くと話は変わります。
そこから先は、専門家が持っている技術や経験の領域です。
「感想を伝えること」と「作り方を決めること」は違う
プロジェクトを進めていると、責任者が成果物に意見を出す場面は当然あります。
問題は、その意見がどのレベルまで入っていくかです。
たとえばゲームの必殺技を確認したとします。
「敵に攻撃が当たったことが分かりにくい」
これは、完成物に対する指摘です。
一方、
「画面を揺らして、赤いエフェクトを追加して、カメラを0.3秒寄せよう」
となると、具体的な実現方法まで指定しています。
もちろん、責任者自身にその分野の専門性があれば、それも一つの方法です。
しかし専門知識が十分ではない状態で細かな作り方まで決めてしまうと、担当者は自分の知識や経験を使いにくくなります。
「言われた通りに作ること」が仕事になってしまうからです。
専門家をチームに入れているのであれば、専門家が判断できる余地を残しておく必要があります。
私がプロデューサーとして見ていたのは「完成条件」でした
自分がプロデューサーとして専門外の領域を見るときは、内部の作り方よりも、完成したものが期待する状態になっているかを確認していました。
考え方としては、少しブラックボックステストに近いかもしれません。
たとえば、
「攻撃したことがプレイヤーにすぐ伝わること」
「演出が長すぎて操作を邪魔しないこと」
「初めて見ても重要な情報を認識できること」
といった条件を確認します。
この条件を満たすために、どのエフェクトを使うのか、アニメーションをどう調整するのか、カメラをどう動かすのかは、その分野を担当している人に考えてもらいます。
出来上がったものが期待した状態でなければ、
「ここでは攻撃が当たったことが分かりにくいです」
と返します。
「どう直すか」ではなく、まず「何が足りないのか」を共有するわけです。
これはプログラムでも同じです
PMがプログラムを書けないこと自体は、特に問題だとは思いません。
ただし、コードを書かないPMが、
クラス構成、命名規則、例外処理の方法、使用するライブラリ、細かな実装方法まで決め始めると、エンジニアの担当範囲と重なってきます。
PMが確認したいのは、本来もう少し別のところです。
仕様が決まっているか。
予定している期限で実現できるか。
他の機能やチームへの影響はないか。
必要な品質を満たせるか。
判断待ちになっている部分はないか。
このあたりを確認するために、技術的な質問をするのはよいと思います。
「なぜこの方法にしたのか」
「他の方法にはどのようなものがあるのか」
「こちらへ変更すると、どこへ影響するのか」
こうした質問によって、専門家が考えていることを理解できます。
質問することと、専門家に代わって実装方法まで決めることは別です。
PMは専門知識ではなく、判断材料を集めればよい
責任者になると、知らないことについても判断しなければならない場面があります。
だからといって、自分がすべての分野に詳しくなる必要はありません。
専門家から情報を集め、
何を優先するのか。
どのリスクを受け入れるのか。
納期とのバランスをどうするのか。
誰が最終的に判断するのか。
こうした条件を整理することも、PMやマネージャーの重要な仕事です。
任せることと、判断そのものを手放すことは同じではありません。
専門家には専門的な方法を考えてもらい、責任者はプロジェクト全体として必要な条件を揃える。
この分担ができているチームは、比較的仕事を進めやすいように感じます。
専門家を配置するなら、その専門性を使えるチームにする
ゲーム開発だけでも、非常に多くの専門職があります。
一人のプロデューサーやPMが、そのすべてについて担当者と同じレベルの知識を持つことは難しいでしょう。
だから問題なのは「知らないこと」ではありません。
知らない領域についても、自分で作り方まで決めなければならないと思ってしまうことです。
専門外の成果物を見るときは、
「自分ならどう作るか」
から考えるより、
「期待していた状態と何が違うのか」
「どの条件が満たされていないのか」
から考えたほうが、担当者と話しやすくなります。
専門家が専門知識を使って判断できる状態を作り、その判断に必要な条件を責任者が揃える。
役割の境界をそこに置く方法もあると思います。
これはゲーム開発に限った話でもありません。
エンジニアと営業、人事と現場、デザイナーと事業責任者など、異なる専門性を持つ人が一緒に仕事をする場面では、同じようなことが起こります。
相手の専門領域へ踏み込む前に、
「これは自分が決めることなのか」
「それとも、条件を伝えて専門家に考えてもらうことなのか」
一度考えてみるだけでも、仕事の進め方はかなり変わるのではないでしょうか。
私は辰巳電子工業株式会社のSS事業部で、エンジニアリングマネジメントや組織づくり、採用・育成などに携わっています。
普段どのような事業を行っている会社なのか、SS事業部の取り組みなどについては、公式Webサイトでも紹介しています。
