@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

社会経験の浅いパートナーの社会マナーどう教育してますか?

投稿者投稿内容
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2007-03-09 14:34
るぱんです。
異論は大歓迎です。

引用:

みなとさんの書き込み (2007-03-09 13:43) より:
るぱんさんと、takuさんと、もちろんNAOさんの
回答を含めると、問題点洗いだし以外は
調整とその効果に対する説明資料と、公開用の資料とか
作る時間が大変そうですね。
訴求力をもった資料作成でしょうし。。。
#この点で苦労してたです>知ってるPM


そもそも訴求力ってなんでしょう?

当初の計画通りの場合、訴求力なんかそんなに無くていいんですよ。
ドキュメントも、計画に沿ったテンプレ程度でかまわないはずです。

問題が起こったときに、アーキテクチャーを揺るがす様な物が
ボロボロ出てくると対応に追われるわけです。
なので、最初にめんどくさめに見積もって、
あとで量を調整すると言うのが僕のやり方ですね。

最初にどれだけ深く物事を見通すことが出来たかどうかに依存するって思います。
見通したらテンプレを作成。
後はメンバーにルールを押し付けてでも守らせます。

ゴールの形が定型的であればあるほど、
メンバーは「あぁ、また例の作業か。みそぎだと思って諦めよう。」
と思ってもらえるので、モチベーションは下がらないです。
引用:

問題点の洗い出しと解決に向けての模索は、最悪
担当に全部出させてもいいわけでしょうし。
#技術的に困難なPMの場合とか
#それでも、xxの部署に聞いてみたらどうだろう的な指針はあってもいいですね

ドキュメント作成の補助という意味では、誰か使いたいのでしょうけど
みんなそれぞれの線がある場合、それもかなわなくて
自分で書くしかないようです。
素データの分析あたりまでは、手伝ってとお願いされることもありましたが。。


どんなプロセスでも計画→実行の手順です。
雰囲気を察するに場当たり的な所にいるんじゃないかなぁ?
と邪推しました。

プログラマやってる人でそれなりに組んでる人は、
コメント→実装の流れがあると思います。

計画→実行→チェック→改善
これって、PDCAのサイクルそのものだと思うのですが・・・。汗

お話を伺っていると、計画がずさんに聞こえます。
引用:

引用:

遅延が発生した際の実作業


PMさんではなくてPLさんに相当する人が手を出してたかな。
「もう、おれがかく!」みたいな感じで(笑)


この状態だと、PMはメンバーを管理できていなくて、
指揮者無しオーケストラ状態です。
混乱しやすいんですよね。
一人ひとりが強ければ問題は無いんですが。汗

そうなった場合は、PLが全体を把握していることが多いんでしょうね。
PMは手出しをせずにPLの指示に従った方がよさげです。

んと、最初からどんな手順でやるか形を示しておいたほうが良さそうですね。
あくまで、僕個人の場合です。

1.要件の確定
2.必要な技術要素の洗い出しと確定
 (たとえば、Java+Springだけど、DIとAOPとJDBCだけ使う・・・とか。
  Hibernateは死んでも使わない・・・とか。EJBはイラネ。とか。4の雛形かなぁ?)
3.必要な技術要素の使い方の定型化(部品化→共通部品に纏め上げる)
4.全体方式のアーキテクチャーの策定(規約類もここら辺で出来上がります。)

PMでもPLでも良いんですが、
プロジェクト開始当初にここら辺を固めに行きます。

だいたいこけるプロジェクトは、2〜4がずさん。
パワポだけでやってると、当然手が回りません。

2〜4でモックをどれだけ作れるか、関わったメンバーを技術的な中核に据えられるか。
この辺が正念場です。
外部設計かいてる間に裏でここら辺が走ってないとね。
後は、詳細設計のテンプレート作成とか、共通部品のAPIとか、Q&A集とか。
外部設計が仕上がる間際に走る処理は大量にあるはずです。

ここで手を抜くと後で火がついても消せなくなると思います。
さらに言うと、連携部分を考慮して、インターフェースの確定させる?
(まぁ、システムの外部とのつながりなんで、外部設計に含まれるとは思うのですが・・・。)

想像力が豊かなメンバーが頭の中で処理を連想できれば、
ざっくりレビュー完了みたいな感じかな?

PMとはその名の通り、ProjectManager(プロジェクトの支配人)
なわけですから、全てが手のひらの上に乗っかっているべき。
って思っちゃいます。

一人じゃ無理でも、この人に任せたら、うまく行く。
そういう役割分担が貴重です。

えと、2〜4が出来上がってれば、進捗の際にそれらを顧客に見せてれば、
それらが報告を助けてくれます。
なので、火がついても人を投入できるし、
説明するのもコストがかからないと思います。

最初にどれだけ腹をくくってやるって念じるかでかなり変わってきますよ。
みなと
大ベテラン
会議室デビュー日: 2002/06/14
投稿数: 202
お住まい・勤務地: Q州地方の日本海側
投稿日時: 2007-03-09 16:05
こんにちは

なるほど。
Verupを繰り返すパッケージの部署だったので
1話完結のプロジェクトとは少し違うのだと理解しました。
訴求することは事前にできあがっていてしかるべきで
途中で発生するのは何かあったからだ(つまり行き当たりばったり)
ってことですね。

今思えば、いっぱんにPMと呼ばれる人に相当するのが
(自分の知っている)PLのようだという印象を持ちました。
PMは常に次のVerだの現状からの追加機能だのをどうするか
ってところ(対外的に売るための製品としての戦略)を
練っていたような気がします。
#Verup(追加/修正モジュール)自体で1話完結ですね。

なんか勘違いしててすみません。


自分自身は、そのパッケージ導入時にSEや営業部隊の方々との相談役
が主な仕事でしたから、コーディングするところには
いませんでしたので、わかってなかったようです。
認識を改めないといけませんね。
#隣の席にはいたけど^^;

[ メッセージ編集済み 編集者: みなと 編集日時 2007-03-09 16:09 ]
フライト
ベテラン
会議室デビュー日: 2005/03/11
投稿数: 63
お住まい・勤務地: 津田沼・東京
投稿日時: 2007-03-09 16:05
引用:

るぱんさんの書き込み (2007-03-09 14:34) より:

そうなった場合は、PLが全体を把握していることが多いんでしょうね。
PMは手出しをせずにPLの指示に従った方がよさげです。

んと、最初からどんな手順でやるか形を示しておいたほうが良さそうですね。
あくまで、僕個人の場合です。

1.要件の確定
2.必要な技術要素の洗い出しと確定
 (たとえば、Java+Springだけど、DIとAOPとJDBCだけ使う・・・とか。
  Hibernateは死んでも使わない・・・とか。EJBはイラネ。とか。4の雛形かなぁ?)
3.必要な技術要素の使い方の定型化(部品化→共通部品に纏め上げる)
4.全体方式のアーキテクチャーの策定(規約類もここら辺で出来上がります。)

PMでもPLでも良いんですが、
プロジェクト開始当初にここら辺を固めに行きます。

だいたいこけるプロジェクトは、2〜4がずさん。
パワポだけでやってると、当然手が回りません。



全体的に同意見ですが、特に2の例えが素敵b

まあCMMIモデルで定義されているようなプロセス領域を理解し、
分野、担当毎にやるべき事が把握出来ているプロジェクトが理想ですね!

http://www.sei.cmu.edu/cmmi/translations/japanese/models/
bigzakk
常連さん
会議室デビュー日: 2007/03/07
投稿数: 33
お住まい・勤務地: 川向こうは横浜市、あと100m
投稿日時: 2007-03-09 17:07
覗いてみたら。。。。。。
「会議は踊る、されど進まず」

スレ主は?どこ?行った?
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2007-03-09 18:05
るぱんです。
引用:

みなとさんの書き込み (2007-03-09 16:05) より:
こんにちは

なるほど。
Verupを繰り返すパッケージの部署だったので
1話完結のプロジェクトとは少し違うのだと理解しました。
訴求することは事前にできあがっていてしかるべきで
途中で発生するのは何かあったからだ(つまり行き当たりばったり)
ってことですね。

今思えば、いっぱんにPMと呼ばれる人に相当するのが
(自分の知っている)PLのようだという印象を持ちました。
PMは常に次のVerだの現状からの追加機能だのをどうするか
ってところ(対外的に売るための製品としての戦略)を
練っていたような気がします。
#Verup(追加/修正モジュール)自体で1話完結ですね。

なんか勘違いしててすみません。


自分自身は、そのパッケージ導入時にSEや営業部隊の方々との相談役
が主な仕事でしたから、コーディングするところには
いませんでしたので、わかってなかったようです。
認識を改めないといけませんね。
#隣の席にはいたけど^^;

[ メッセージ編集済み 編集者: みなと 編集日時 2007-03-09 16:09 ]


えっとですね、
1.要件の確定
のプロセスにおいて、切り分けをやるんですね。
今回のVerで受け持つ範囲と次回のVerで受け持つ範囲の切り分けも同時に行います。

途中で入れられるものを今回のVerに取り込んだりもしますが、
そこは無理のかからないように受け持つもんです。

次回どうするかって話は、製造が終わってテストに入った段階で
PMの権限を一部切り離してPLに移管します。

その際に自分の手が完全に空くので、
次期Verに向けた要件と、今回作成のVerのアーキテクチャーレベルでの
すり合わせ等を行います。

まぁ、一人で何役もやることが多いので、
こんな感じになるんですよ。

パッケージ開発の場合は、要件が決まっていない事が多いので、
可能性と納期と工数を考慮してアイデアを盛り込むって言う手間が増えると思います。

それが前回Verのどのタイミングで・・・。
こんな話になるので、
専門に特化した状態を持ってPMとなっているのかも知れません。

>フライト様
お気に召さない点はどんどん言ってくださいね(笑)
例えが・・・と言うのがピンとこないのですが。(滝汗)
bigzakk
常連さん
会議室デビュー日: 2007/03/07
投稿数: 33
お住まい・勤務地: 川向こうは横浜市、あと100m
投稿日時: 2007-03-09 18:30
先ほどはチャカしてすいませんm(_ _)m
ただ、これほどの反響があるのに問題提起者(スレ主)の発言が無いのが許せなくて。
私はいわゆるインフラのPLとしてPMの補佐をしてきました。
PMは、私の目から見てるとプロジェクト全体(アプリ,インフラ、運用etc)の管理、顧客との大まかな調整(細かい調整はPLが行う)を行う人と思ってます。
パワポが出来るからPMと言わないですね。(逆に出来ない人が多い?)

すいません、話が脱線しそうなので元に戻すとスレ主は、このスレの今の状況についてコメントしない(できない?)状態では元々パートナーを把握する能力が無かったのではと思います。
そもそもタイトルからして?って感じです。
PMを勤めるならこの状況を収拾できるくらいの発言があって然るべきだと思います。

横槍みたいで申し訳ありませんが、一言、言いたくて投稿しました。
kuma
大ベテラン
会議室デビュー日: 2004/02/25
投稿数: 110
投稿日時: 2007-03-10 00:48
本題に無関係なので削除しました

[ メッセージ編集済み 編集者: kuma 編集日時 2007-03-10 08:45 ]
KYO
ベテラン
会議室デビュー日: 2005/09/08
投稿数: 52
投稿日時: 2007-03-10 10:36
昔のログを見て横槍をつい。。

スレ主さんの発言でどこの会社かすぐわかりましたが、
あの会社はどの事業部でもこんな問題を慢性的に抱えてるようですねぇ。

ポジティブで広範囲把握と論理的思考が出来てないPLやPMは、
パートナーだろうが部下だろうが上長だろうが客だろうが同僚だろうが、
周りから見下されてるでしょ。だって答えられないし。

本人はいままでそんな事を考えた事もなく、考え方も知らず、
言われてる事がわからず、もちろんスキルもない。
歳だからスキル覚える気力もなくて、多分やりたくないと思ってるだろうし。
多分、、つか、間違いなくそうだろうと思うけど、、

そんな人間をPL、PMにするほうがおかしんだけど、そーもいかないだよねぇw
落穂になるのが目に見えてるから、そんなプロジェクト関わりたくねーよ。
誰しも、、パートナーやら、、etcみんな思ってるはず。
俺だって関わりたくねーしww

他の会社もこんなんだったら、IT業界ってやっていけるのかね・・・。
俺は反面教師でいい材料が回りにいるから幸せな環境だけどさ。

[ メッセージ編集済み 編集者: KYO 編集日時 2007-03-10 10:53 ]

スキルアップ/キャリアアップ(JOB@IT)