00:05
おはようございます、Rayです。
本日も、Ray Wow FMの時間がやってまいりました。
Ray Wow FMでは、主に株式会社耳に関する様々なテーマを扱って、
時にはゲストもお招きしながら、ゆるくやっていくラジオとなっております。
はい、本日はですね、社内でスラックでちょっと議論があったんですけれども、
山達っていう社員がいるんですけども、彼がつぶやいてたつぶやきを引用するんですけども、
特にPMの役割は何なのかっていう話で、ちょっと話をしたいなと思います。
山達曰く、いみみで求められているPMの役割とは、
工数管理とかスケジュール管理以外にも、
そのPLとしての開発ディレクション、
仕様詰めとか、ドキュメント管理とかも求められている傾向があると。
しかしそれを意識しているPMがどれだけいるか、
となれば個々人の意識の違いによるので、
いろんな認識の差異が生じるよねっていうところの話がありました。
正直なところ、プロジェクトによっていろいろとPMが担うべき役割っていうのは、
異なってくるっていうのはあり、
いろんな会社でも、そのPMとは何かっていうところの議論はあると思うんですけれども、
まず、いみみにおける役割定義っていうのは、
一応明確に定義しています。
職位ガイドラインっていうのがありまして、
こちらは外部にもノートのブログで公開はしてるんですけれども、
そこでPMの役割っていうのは定義しています。
そこによると、
いわゆる開発ディレクションとか、
仕様調整であったりとか、
ドキュメント管理みたいなところを行うっていうところは、
PMの役割としては規定していません。
およびPMはPLとも違いますと。
実際のところ、例えば仕様の調整とか仕様の決定というところは別の役割ですね。
アーキテクトやリードエンジニアやビジネスアナリストが行うっていう形で、
PM以外の役割として定義しています。
ただ、そのPMという役割、リードエンジニアという役割っていうのはあくまでロールなんですね。
プロジェクトに必要なロールっていうのを、そういう形で細分化しますと。
その中で、じゃあそのロールに対して誰が割り当たりますかというところは、
03:06
チームの役割設計になるんですけれども、
チームの役割設計になるんですけれども、
実際のところ人が少ない状況であれば、必要となる役割に対して一人の人が複数役割を兼務するっていうのはもちろんあります。
それは一般的にリソース制約っていうところがある中で、ベストエフォートやらないといけないっていう場合はそうなりますよね。
なので、PMは例えばそういった仕様調整の役割とか、
例えばそういった仕様調整の役割とか、
例えばそういった仕様調整の役割とか、
仕様調整の役割を担うべきかどうかっていうものというよりは、
マネジメントっていう役割があったとして、それ以外に仕様調整っていう役割があったとして、
できる人、必要な人がそれをやればいいっていうところが基本的な正解ですね。
ただ、重要なのはPMの役割の一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
必要なのはPMの一つにそういうチームビルディングや役割設計を行うっていうのは、
顧客や社内自社との中での役割分担も含めてですけれども
役割分担を行っていき
必要なリソースを計画する中で
役割を実際に割り当てていくというところで
チームビルディングを行っていくので
PMが使用調整をやるべきかというよりは
そういう使用調整の役割がプロジェクトで必要であれば役割を定義し
誰がその役割になるかという形で
役割分担を計画して実際にリソースをアサインしていくというところが
PMの役割ですね
その結果としてPM職を専門職とする人が
PMの役割だけではなくて使用調整みたいな役割
例えばアーキテクトであったりとか
リードエンジニア的な役割というところを
軽減していくというような役割を
兼務することはあるとは思います
という形で役割主導の考え方というところが
重要にはなりますね
これが役職主導という形になってしまうと
役職を担う人は
全プロジェクトに対する責任を負うべきだ
なので
マネージャーというのは
部門とかに関する責任を負うべきなので
部門の中での役割に対して
06:01
それを担う人がいなければ
最悪マネージャーと呼ばれる人が
その役割を担わないといけないみたいな
そういうふうになってしまうんですけれども
役職主導の考え方ですね
特に昔の組織というのは
やっぱり役職があって
そこにある役割を担う人がいると
そこに曖昧な形で役割というところが
実際に定義されないんですね
曖昧な形になってしまって
なんとなく部門とか
例えばプロジェクトとか
そういう範囲の責任を
全部負うべきだみたいな形になって
メリットは責任が明確になるんですけれども
デメリットはやっぱり負担が
非常に大きくなってしまうので
そのマネージャーと呼ばれる人に
対応することができるようになってしまうので
それに対して役割を担うことができるようになってしまうんですね
これは夢見でも
8年ぐらい前に
10年から8年から10年ぐらい前に起きた
大体前ですけども起きたことで
これを機に
それを機に夢見は役職主導から
役割主導の組織になり
会社の中での役割
あるいはマネージメントの役割というのを
細分化して
役割を明確に定義し
それぞれの役割に対して
自分はこうやりますよ
できますよ
という形で
アサインされていくというような形の
組織設計役割設計にしたんですけれども
こういう考え方がまず重要ですね
その上で
やはりいろんなプロジェクトの
アジリティですね
短い中で
実際にアウトプットを出して
効果検証したり
仮説検証していくというようなプロジェクトを
なっていく中で
やはりPMも
求められる役割というのは変わっていき
実際のところ
使用理解とか設計理解をした上で
柔軟な判断をしていかないといけない
というふうになってきていますと
そういった意味で考えると
プロジェクトマネジメントになる役割の人が
使用調整も
兼務するということが求められる
プロジェクトというのは比較的
増えていく可能性はありまして
増えていると思いますね
そういった意味で
PMが所長制とかも担うべき
というふうな主張というのは
ある意味
当てはまるかなと思うんですけれども
一方で
そういう二つの役割があったときに
それぞれの領域にお得意とする専門家が二人
それぞれ割り当たって
それぞれの二人が本当にペアワークのような形で
09:00
密に連携して仕事をするというようなやり方
というところもできますし
そのほうが現実的ではありますね
やっぱりいろんな業務を兼務できる人というのは
非常にリソースとしては希少なので
結局そういう兼務を行ってしまうと
その人が一人で行うことになって
やっぱりその人が一人で行うことになって
大変障害点であるというリスクがより高まるんですよね
そういった意味ではいかに
役割というところを明確に分担しながら
それぞれが密に連携していくというところが
組織が特にスケールしていく意味では
非常に重要になっていくんじゃないかなとは思いますね
今日はですね
そういったPMの役割とは何なのかというところと
役割主導ですね
方の
組織設計というところについて話をしてみました
