プロジェクトマネージャコミュの料理のできない料理長

ある料理店の料理長は
おいしそう(?)なミンチカツの料理の絵を画用紙に書き、
料理人達に「こんな料理を作ってくれ」
「ミンチカツは大きめで」と注文します。
料理人達がいつまでもミンチカツを油あげていると
「いつまであげているんだ！　はやく皿にのせろ」
と料理長は激怒。
結局料理人達は生焼け状態のミンチカツを客に出し
後に客からクレームをつけられました。
(大きいミンチカツだからじっくりあげないと中まで火がとおりません)
そして料理長が料理人達に
「君達がうまく料理ができないのは何故かを考え、次回からは同じ過ちをしないでくれ」
と一言。
実は料理長の料理スキルが無い為の失敗なのだが
料理スキルが無いからその本質に気づいていない…

IT業界のPMさん達の話を聞いていると、そんな料理長である人を多々見かけます。
導入するシステムに利用されるものの名前
(たとえばJavaとかOracleとか何かのフレームワークの名前だったり)
やそれらの簡単な利用用途は知っているが、
コーディングスキルや導入スキルは現場PGの方がはるかに高いという現場は多く存在します。
標準出力に”Hello World”と表示させるだけの単純な
バッチですらできないPMさんも存在します。

PMとしてプロジェクトのトップに立つからには
PMになる人はメンバーの中でトップクラスのスキルを
持つべきではないかと思うのは私だけでしょうか…

PMをされている方やPMを目指されている方は本件についてどのように
お考えか教えて下さい。

#上部の例え話が下手でスイマセン...

コメント(24)

最初
全て
最新の40件

[2] mixiユーザー 04月26日 16:15

端的に言うなら、
その料理長を更迭するのが、
店長＝ＰＭの仕事かなと。

[3] mixiユーザー 04月26日 16:50

>PMとしてプロジェクトのトップに立つからには
>PMになる人はメンバーの中でトップクラスのスキルを
>持つべきではないかと思うのは私だけでしょうか…

スキルはあったほうがよいと思いますが、トップクラスである必要はない気がします。
やり方でカバー出来る部分って、あると思います。

それと、上記の例は（上記の例で表現するのは難しいですが、）「スキルがないために起こったこと」ではないような気がします。

[4] mixiユーザー 04月26日 17:15

確かに、最低限の知識やスキルは必要だと思いますが、
マネジメント業務に必要な資質と実際の作業に必要な資質は
基本的に違うものだと思っています。

マネージャの大事な役割は、プロジェクトをいかに円滑に、
いかに効率的に運営できるかを常に考え、そのために対応していく
ことだと私は考えています。

もちろん、そのための最低限の知識やスキルは必要だと思います。
ただ、トップレベルのスキルである必要はないように思います。
逆にPMがトップクラスのスキルを持っていたら、「メンバーを
信頼して仕事を任せる」ことや、「メンバーの意見や提案に
聞く耳を持つ」ことができず、チーム全体のモチベーションも
下がってしまうようなケースも出てくるかも知れません。

Ebiさんが例えとして挙げられていたように、
自分が無知であることを自覚していないというのは問題外ですが･･･^^;
メンバーを信頼して、周りの人間の言うことに聞く耳を持てること。
メンバーときちんとコミュニケーションを取り、信頼関係を
築きながらプロジェクトを進めていけること。

本当に必要なのは、「ヒューマンスキル」なのではないかな･･･
と私は日々感じています。

･･･なんて、私はシステム系のPMではないので、あまり偉そうなことは
言えませんが･･･

[5] mixiユーザー 04月26日 22:41

ご意見ありがとうございます。
ご意見いただいた「やり方」や「マネージメント」なのですが
根本的なスキルすら無いため誤ったやり方を実施しているPMさんが多いように思えます。

以下実際にあった話なのですが

某大手で社風を持つために社内のコミュニティーの活性化を行うという
プロジェクトが立ち上がり、コミュニケーション用サイトとしてMIXIのような
社内用SNSサイトを構築する事になりました。

そこで、PMさんは工数を見積もる為に
必要な機能数をあらいだしました。
「ホーム」「ブログ」「トピック作成」「ログインログアウト」
のように大カテゴリを決めてから小カテゴリ(ホームなら「足跡」「プロフィール変更」「メッセージボックス」等)をさらにあらいだし
それぞれの項目に対する　”画面数”、”機能が利用するDB数”、”難易度”を係数としてかけて
それぞれ基本設計、機能設計、詳細設計、製造、テストフェーズの工数を見積もり
プロジェクト全体の工数を見積もっていました。
類似する画面は流用率を係数としてかけていました。
PMさんのまとめた表を見ると上記の見積もり根拠もあり、妥当な数値と思えます。

しかしよく見ると、「トピック作成」と「ブログ投稿」と「メッセージ送信」は機能が違う為、別々の工数として見積もっていました。

上記3点(トピック作成、ブログ投稿、メッセージ送信)は
・画面から何かを入力する
・確認画面を表示する
・入力した値でDBを更新する

という処理なので　全て共通化できるはずなのですが
「同じモジュールで対応可能ではないのですか？」と聞くと
「機能も違うし画面もまったく違うしさらに更新するデータベースもまったく違うのになぜ共通項目なんだ？」と言われてしまいました。

そして、彼は機能別に工数を見積もり、XX人月(100人月近い)工数を見積もってしまい
その工数をベースにプロジェクトが進行していました。

MIXIの構築にかかった工数は3ヶ月(3人月)です。(でしたっけ？)
MIXIコピーの製造の見積もりは、機能数や画面数やDBやファイル数にとらわれてしまい
100人月近い見積もりとなってしまいました。
(上の人はOKを出したようですが…)
しかし、”工数削減”と日々言っている某社なのに
これは正しい選択なのかなと…

#上層部がその工数で納得しているのなら
#それで良いのかもしれませんが
#技術者として上質なものをより易くを求めるべき事も必要ではないかと思います。

[6] mixiユーザー 04月26日 22:58

IT系でマネージャをしている者です。

私もTENさんやmiyakoさんと同じ意見で
スキルはあった方が良いとは思いますが
高いスキルは必ずしも必要ではないと考えます。

理由としてはプロジェクトマネジメントの仕事は
ゴールを目指す過程における障害物を取り除く仕事だと
私は考えているためです。
技術スキルが高いから障害物が取り除ける訳ではないですよね？

ちなみに私もヒューマンスキルが最重要だと思います。
どんなに素晴らしいことを言っても
「人間としておかしい」人の言うことは心理的に受け入れたくないと思いますので。

[7] mixiユーザー 04月27日 00:58

5: を読んで
設計ってのはPMの主要業務じゃないってことを理解してもらわないと議論が深まらないと思いました。

[8] mixiユーザー 04月27日 01:32

＞技術者として上質なものをより易く(安く？) を求めるべき事も必要ではないかと思います。

いち技術者としては、そういう考えも必要だと思います。
そして、ＰＭはそういった技術者をうまくコントロールすることが
最大の仕事であり求めるべきことだと思います。

前述の料理長と料理人の例え話がありましたが
本当の料理の世界だとしても、料理人より料理長のほうの
スキルが同等もしくは上回っている必要があるのでしょうか？

料理長は
　・コース料理全体のバランスを考える
　・適材適所に人員を配置する
　・お客様のニーズに応える
といったことを仕事としているのではないでしょうか？
# 料理人の方に伺ったわけではないのであくまで想像ですが･･･

これらの中に「料理を作る」といったスキルは
ほとんど関係ないのでは？

これがＩＴの世界になったとしても同じことが言えると思います。

「優れた技術者が優れたプロジェクトマネージャになれるとは
　限らない」

どこで聞いたか忘れましたが、これが全てだと思います。

[9] mixiユーザー 04月27日 01:50

私は技術者としても一家言あるつもりですが、本当に
「・画面から何かを入力する
　・確認画面を表示する
　・入力した値でDBを更新する
　という処理なので　全て共通化できるはず」
であれば、世の中にＳＥは要らないわけで。

共通化をする場合、各機能を個別に開発する場合には
考える必要のない、汎用性を確保するための設計に
余計な工数が必要です。

さらにテストや仕様変更ともなれば、共通部品の
不具合によってあちこちに問題が発生し、
終わってみれば逆に共通化のせいで工数が超過した、
なんてことも結構あります。

また、そのＰＭの見積もり手法がＦＰ法だとすると、
機能数や画面数、ファイル数に「とらわれて」いる
のではなく、それこそが正に見積もりの根拠であり、
それ故に上層部も納得しているのだと思います。

上層部を納得させるのも、ＰＭの仕事です。
皆さんもおっしゃっている通り、ＰＭに必要なのは
技術力ではなく、人間力だったり管理能力だったりします。

[10] mixiユーザー 04月27日 06:44

wildcats さん
>技術スキルが高いから障害物が取り除ける訳ではないですよね？
確かにおっしゃるとおりだと思います。
ですが、技術力が低いがゆえに障害物を多くしているPMさんが多いように思えます。
「同じような画面だからコピペで作れるだろう… だからA画面とB画面の工数は Aが10 Bが2(流用率を考えて)」
等と見積もり、”その通りにガントチャートを作成する”
人が多いる感じがします。
もし、ソースをコピペして作ったとすると A、Bそれぞれのソースができてしまい。
仕様変更に弱くなり、保守性が下がるはずです。

>ちなみに私もヒューマンスキルが最重要だと思います。
>「人間としておかしい」人の言うことは心理的に受け入れたくないと思いますので。
上記とても同意できます。
「なんで遅れるの？」「簡単にできるでしょ？」を連呼するだけのPMさんPLさんを別プロジェクトで見たことあるのですが
現場はドンヨリしておりました。
(もしかしたら本当に簡単にできる事だったのかもしれませんが
怒るだけで現場を動かそうとしていた感じがしました)

かＪすさん
>「・画面から何かを入力する
>　・確認画面を表示する
>　・入力した値でDBを更新する
>　という処理なので　全て共通化できるはず」
>であれば、世の中にＳＥは要らないわけで。
そうですね。確かに要らないかもしれません。
私の今の現場(金融)と前の現場(またまた金融)は
前の前の現場(製造)と比較すると「SE」業務をしている人が多く
存在しました。
彼らは設計書?(エクセルにこういうシステムを作ってね～と
あれこれ細かく書くやつ)
を日々大量に作って PMやPLにレビューしておりました。
長くAgile手法な現場にいたせいかこの作業がプロジェクトに必要なのかどうかが良く分かりません。

>上層部を納得させるのも、ＰＭの仕事です。
>皆さんもおっしゃっている通り、ＰＭに必要なのは
>技術力ではなく、人間力だったり管理能力だったりします。
上記のコメントとても同意できますが、
みっくんさんの言われている
>　・コース料理全体のバランスを考える
>　・適材適所に人員を配置する
>　・お客様のニーズに応える
を無視し、料理やお客様や人員配備より
上層部が中心で料理やお客様の優先度はその次になっている現場が多いような気がします。

料理を食べる(システムを利用する)のは上層部ではなく
お客様(利用者や運用者)ではないかと…

でも今の現場のPMさんに同じ事言ったら
「じゃぁおまえは上層部を納得させれるのか？」と突っ込まれるでしょうけど(涙

>機能数や画面数、ファイル数に「とらわれて」いる
>のではなく、それこそが正に見積もりの根拠であり、
>それ故に上層部も納得しているのだと思います。
ん～　やっぱ根拠ですよねぇ。
確かにそれぞれに数値をかけて算出された工数なので
根拠のある数値のように見えるのですが技術者サイドから見れば
まったく根拠の無い数値となっている気がします。

数人月でできるはずのものが100人月近い工数となった根拠は
いったい何だろうかと…

[11] mixiユーザー 04月27日 11:37

聞く限り、そのシステムは数人月では無理です。

Ebiさんが優秀なPGであることは分かりましたが、
多くの人が関わるシステム構築においては、
誤解や偏屈なロジックによる現場の混乱を
避けるため、全体を俯瞰し調整するスキルや、
ドキュメントの整備が不可欠です。

SEやPLがその役目を担うのが通例です。
PMの役目は、さらにずっと奥にあります。

Ebiさんなら、
そのうちに見えてくると思います。

[14] mixiユーザー 04月30日 21:54

>>Ebiさん
>もし、ソースをコピペして作ったとすると A、Bそれぞれのソースができてしまい。
>仕様変更に弱くなり、保守性が下がるはずです。

エンドユーザが納期とスコープと予算を固定で考えていて
PMもそれに見合う見積もりやマネジメントしかできない状態だと仮定すると
品質が低下するのはむしろ当然のことではないでしょうか？

個人的にはPMがどうこうよりも「なぜそうなったか？」を
組織で考えないと問題の改善が難しいような気がします。

[15] mixiユーザー 04月30日 22:33

｜ですが、技術力が低いがゆえに障害物を多くしているPMさん｜が多いように思えます。
｜「同じような画面だからコピペで作れるだろう… だからA画｜面とB画面の工数は Aが10 Bが2(流用率を考えて)」
｜等と見積もり、”その通りにガントチャートを作成する”
｜人が多いる感じがします。

　他の人も書いてますが、プログラマとしての「技術力」の問題じゃなくて、工程管理の技術の問題です。
　プロジェクト管理の技術を持たない人がプロ真似やるのが原因です。プログラミング技術じゃないですってば。

｜上層部が中心で料理やお客様の優先度はその次になってい｜る現場が多いような気がします。

｜料理を食べる(システムを利用する)のは上層部ではなく
｜お客様(利用者や運用者)ではないかと…

　これもプロジェクトのスコープ定義をするスキルの問題ですね。プロジェクトのゴールを明確化してメンバーと共有できないのではプロマネではないし、そもそもプロジェクトとして成立していない可能性がありますね。

[16] mixiユーザー 04月30日 22:59

賛否両論あるかとは思いますが・・・
大手のSIが新卒の頃からマネージメントに傾斜した教育を行い、「使えない」PMを大量生産しているのを傍目で見ていると、Ebiさんの気持ちも理解はできますけどね。
FPを否定する気はないですが、
彼らは要するに「物作り」をしたことがないから、頼る術がFPだけになってしまう。
多分、一生理解しあえないでしょうね。（笑

[17] mixiユーザー 05月01日 00:32

初めまして。ベンダーで主にパッケージ導入プロジェクトをやっています。

確かに、プロマネがメンバーの中で一番高い技術を有していれば、理想ですよね。プロマネ自ら課題の技術面からの解決もできるわけですから。

小さなプロジェクト(５カ月１０人月弱くらい)であれば、それもあり得るかなと思いますし、実際、私も最近そんなロールを経験して、割りと上手くいきました。

さらに、確かにプロマネが導入しているシステムの技術や背景にある業務にチンプンカンプンのプロジェクトは悲惨です。お客さんどころかメンバーからの信頼も得られず、失敗確実って感じのものも結構見てきました。

しかし、プロジェクトの規模が大きく、導入する業務範囲が広い場合に、プロマネがナンバーワンの技術を有しているというのは現実的ではないと思います。例えばERPだとして、会計も販売も購買もBIも全部詳しい人なんていないですから。

他方、多くの方が指摘されているとおり、プロマネ固有の技術は一番優れているべきです。固有の技術にはPMBOKなどは当然として、コミュニケーション能力やコーチングスキル、リスクを察知するセンス、高い職業意識と倫理観、顧客志向などのソフトスキルも含んでいます。

先に技術を知らないプロマネがいるプロジェクトは最悪、と書きましたが、周りから受け入れられないプロマネは大抵、上述のソフトスキルも欠けています。

顧客志向があれば、例え専門外だとしても業務や技術のことを多少なりとも勉強するでしょうし、コミュニケーションが人並み以上にできるのならメンバーの技術的な提言に耳を傾けるでしょう。上の顔色しか見ないなんて職業倫理に欠けているとしか言えない行為です。

長くてスミマセン。。個人的にはこのトピックの議論を読んでこんなことを考えました。

[18] mixiユーザー 05月01日 02:00

> PMとしてプロジェクトのトップに立つからには
> PMになる人はメンバーの中でトップクラスのスキルを
> 持つべきではないかと思うのは私だけでしょうか…

理想的ではありますが、現実的にはかなり難しいと
思います。テクニカル的なスキルも十分あるＰＭで
あれば、課題に対する的確なアドバイスやチェックも
できると思いますが若手のＰＭ以外の方にこれを
求めるのは酷な気がします。

ただ、ＰＭが自分のテクニカルスキルのレベルを
正しく理解し、足りないところはメンバーの意見に
耳を傾けるという姿勢は必要でしょうね。

[19] mixiユーザー 05月01日 06:21

たくさんのご指摘ありがとうございます。
本件について色々とGoogleで調べていると
@ITの記事か何かで「最高の技術者は最高のPMになれるか？」
といった内容の記事を見つけました。
その記事ではWBSを技術者視点のみで作成し、顧客からの仕様変更のリスク等
プロジェクト進行中に発生する”開発作業以外”のリスクを
考慮していなかったが為に大変なプロジェクトとなってしまった
という内容の記事でした。
複数人で開発する場合、単純に人数倍のスピードになるのではなく
メンバー同士のコミュニケーションが必要となり
内部のコミュニケーションにかかるコストも考慮する必要があるとも書かれていました。

自分の書いた投稿を否定する事になってしまいますが、
上記コストを考慮すると社内SNSサイトの構築は数人月では無理でしょう。(かJすさんに指摘されていますが)
というより、AgileとWFとでは見積もり方法もQDCに対するプラクティスも異なるのに
「こんなに工数差ができる」というのはナンセンスでした。
(手法が違えば何かに差ができるのはあたりまえですね)

ただ、PMさんの中に現場スキル(開発とか導入とか)が低く
メンバーとのコミュニケーションができない方は多く見ます。
汎用機時代のオペレータの常識をそのままオープン系へ持ってきて
無理やり型にはめているプロジェクトは多い気がします。
そこで生じる摩擦がプロジェクト進行の大きなブレーキとなっている事に
一番下流が気づき一番上流が分かっていないプロジェクトって
多々あるような気がします。

[21] mixiユーザー 05月01日 09:00

Ebiさんのようにゼロベースで（すべてを疑って）物事を捉えることができる方は、
上の人間の言うことを鵜呑みにする人よりも間違いなく伸びると思います。

ところで、私もこのトピックのお陰で気づかされたことがあります。
それは、腕に自信のあるメンバーに限って、上が（技術的に）ある程度
尊敬できるリーダーでないとパフォーマンスを発揮できない（ついてこない）ケースが
多いのだろうな、ということ。

そういう場合ＰＭとしては、間に技術に長けたチームリーダーを挟むことが
対策として考えられるかもしれません。

また、技術者時代からのブランクが長過ぎるＰＭの場合、
過去の経験の上にアグラをかいて新しいことを学ぼうとしない方が中にはいます。
（おそらく、そういう方はこういったコミュに来ようとしない）

そういうケースにおいて、現場との感覚のズレでプロジェクトの遂行に
支障を来たすことはありそうですね。注意したいです。

[22] mixiユーザー 05月02日 00:17

Ebiさんは自分なりに理想のPM像に向かっていけば良いのではないでしょうか？
技術力でNo.1のPMを今の時点で目指すことは決して悪いことではない気がします。
年長者に老婆心ながらも頭から否定されて諦めてしまうことは勿体無いと思いますよ。
もちろん、プログラミングの知識の他にもネットワーク、DB、ストレージ・・・さらには設計の方法論、ビジネスモデリング、業務知識・・・覚えることは山ほどありますけどね♪
いろいろな局面で苦労すれば、何れにしろメンバを不幸にするようなPMにはならないでしょう。

[23] mixiユーザー 05月03日 07:03

小さな恋のメロディさん

>技術力でNo.1のPMを今の時点で目指すことは決して悪いことではない気がします。
>年長者に老婆心ながらも頭から否定されて諦めてしまうことは勿体無いと思いますよ。
私はひねくれ者なので物事の真偽を確かめるには人の意見も重要視しますが
人の意見より自分で実際に行動してみてその結果で判断します。
(ん～典型的なAgilerですね…)

また、本トピックにて「料理のできない料理長」を否定する意見を多くコメントしましたが
そんな彼らのおかげで美味しい汁を吸っていた時代もあったので
自分も否定される一員であったのかもしれません。
狭いスコープで見れば美味しい汁を吸っている側の人間だけど
広いスコープで見れば料理のできない料理長と大差無いですからね...

ログインすると、残り5件のコメントが見れるよ