プロジェクトマネジメント、プロジェクト管理におけるポータルサイト

HOME > プロマネの勘所 > 【PM研修】第二回 演習から実プロジェクトを振り返る

2007年7月30日

【PM研修】第二回 演習から実プロジェクトを振り返る

計画や体制図の重要性を再認識

― 演習では、講師にお客さん(ユーザー企業のキーマン)の役をしてもらい、受講者から「○○部門の●●さんに質問です」といった形で、質問をぶつけてもらいますが、そういった理不尽な力関係は、入っていませんからね。

松井
そうですね。それは全く考えずに演習を行っていました。演習の中では、「お客様」に質問やヒアリングをする際に、失礼な聞き方をしてもちゃんと答えを返してくれます。

― あくまでも講師ですから。ただ、質問のレベルによって答えの出方が違うというのはあると思います。

松井
はい、質問をしたことに対してのみ答えが返ってくるので、質問の内容がちょっとずれているだけで、全然違う答えが返ってきたりすることもありました。
実際の現場では「お客様には、そんなことは聞けない」という部分も出てきます。でも、関係者をどこまで巻き込むか、その範囲を選定するところについては、考え方としてものすごく勉強になりました。

― 計画編にも共通することですが、普通、体制図の中にユーザーは入れなかったりしますからね。

山口
僕がいま担当しているのはパッケージなので、そもそもユーザーさんがいらっしゃらないのです。とは言っても、「登場人物を全員出さないことには始まらないよね」と、体制図をとても重要視して、けっこう時間をかけて作っています。何か未決事項があったりすると、それがプロジェクトの遅延に即つながります。それはもう、去年僕自身が痛い目に遭ったので(笑)、身に染みました。
どういうふうに体制を組んだら意思決定が早くできるのかと、上司等も含めて徹底的に議論をしました。それで体制図を作って、ようやく運用が始まって、今は大きな問題もなく動いていますけれども、それが今後も効果を発揮するのか、ちょっと心配ではあります。今回計画編を受講して、それまでの僕は、体制図をおざなりに作っていたことや、自分のやっているプロジェクトの体制図を見たこともない場合も多かったことに気づきました

― 特に、プロジェクトの一部分を担当していると、そういうことはよくあります。

山口
プロジェクトについての問題は、例えばプログラマの方が気付いたりしますよね。それを誰に言えばいいのかも含めて、リスク管理の一環になるというのが、計画編を受講して、すごくよく分かりました。また実際に自分で痛い目も見たからこそ、それが分かってきたというのが、僕にとって非常に大きい経験だったと思います。

松井
私も今ちょうど、計画や体制図の重要さを実感しているところですね。こちらの場合は、さきほども言いましたがフレームにとらわれすぎているのです。体制図もしっかりできているのですけど、その体制図がちゃんと運用できていない。「とりあえず名前が入っていればいい」みたいな感じです。

― それはありがちですね。

松井
本来であれば、体制図の中の管理する人間がWBSに載ってくるはずなのに、一担当者がWBSに載っているとか。リスク管理という意味の進捗管理も含めて、会議体も計画書には載っているのだけれど、誰が出るのかがあやふやであるとか、そんな状態です。私がコントロール編を受講したときに使ったような資料は全部そろっているし、全部の項目は埋まっている。だけども実用には向かなくて、単純に上に報告するための資料作り的状態になっている。たぶん他のプロジェクトでも、そういうところはけっこうあると思うのです。

― そうですね。多いと思います。

松井
計画の部分をしっかりやっておけば、万一ぶれてしまっても、結局は人と人のつながりだから、何とかなる部分が大きいと思います。でも最初にずれていると、それによって人間関係がこじれることも往々にしてあると思うのです。やはりコントロール編を受けて思ったのは、計画編も重要だということですね。

山口
やはり「計画ありき」というところがありますよね。計画があってないような状態で走ると、もうほんとうに、ズタズタになっていくのですよ。

松井
すごいことになりますよね。

山口
僕もプロジェクトを始めたときは、計画の立て方もよく分からなくて、リスクの洗い出し方も分からないし…「リスクって何?」というところから始まって、やっと計画らしい計画も少しずつできるようになってきました。まだ完全にきれいな計画は作れないし、計画自体はどんどん壊れていくもので、「そのつど組み直せばいいや」と、最近は思うようになりましたが。

― 計画にはある程度、そういう含みがあることが重要です。

要員計画とコミュニケーションの難しさ

山口
そうですね。これまで僕も「ピッタリできる工数を報告してください」とやっていたのですよ。でも、それだと何か起こったときに、何も入れられなくなってしまう。だからバッファを取ってやるように心がけてはいるのですけど、やはり「納期ありき」でスケジュールもタイトですから、バランスが難しいです。メンバーに負荷をかけ過ぎないように、かつ楽をさせないようにというところが、一番難しいと思っているのです。

松井
そこがほんとうに難しいところですよね。結局、工数を出しても期限が切られているわけです。工数が期限をオーバーして突き抜けてしまう場合、要件を落とすか、人を増やすか、品質を下げるかしかない。でも、品質を下げるという選択肢はあり得ない。特に金融関係では、絶対にあり得ないじゃないですか。

山口
そうですね、あり得ないです。

松井
しかし、ただ人を増やせばいいというものではないですよね。「2人月を2人いれば1ヶ月で終わる」という理屈でいえば「100人月の仕事を100人入れれば1ヶ月で終わる」となりますが、実際はそうではない。でも、それが分かってない人が結構います。

― 場合によっては少数精鋭で、5人くらいでやったほうがいいこともありますしね。

松井
それから、タスクの流れによって、「ここはこれが終わらないとできないよ」というのもあるじゃないですか。

山口
最近だとアジャイル開発のやり方とか本もいっぱい出ているので、僕も「エキスパート集団で全部作っちゃえ!」という内容の本も読んだりしているのですけど、実態と合わない部分が多くて…それでも、「何か取り入れられないかな」と常に考えながらやってはいるんですけども、要員のスキルは一足飛びに上がるわけでもないし、人を入れたら入れたで、その生産性が最高になるまでに一月掛かることもあります。ですから、どういう研修を受けてもらうのがいいかとか、どういう勉強をしてもらえばいいかも含めて、ちゃんと考えていかないと、スケジュールだけじゃなくて要員計画も、ほんとうにうまくいくものは作れないですよね。
今回、僕が受講した計画編では、要員計画についての部分があまりなかったような気がします。どんなスキルがある人をアサインすればよいかという話も含めて、もっと要員計画の話それがあるといいと思います。

― 要員計画はほんとうに難しいですね。私がすぐに思い浮かぶのは、弊社のコンサルが立て直しをしたプロジェクトです。メンバーがホームランバッターばかりで逆に、コミュニケーションがうまくいっていなかった。スタープレイヤーがそれぞれ自己主張に終始して話がまとまらないし、前に進まなかったといいます。やはりプロジェクトはチームワークですよね。

松井
人柄ですね。多分私みたいな押しの強い性格のメンバーばかりが集まったプロジェクトはうまくいかないです(笑)。チームに一人、二人いる分にはいいと思うし、それが自分のいいところだと思ってもいるのですが。
実は入社して最初の何年かは、自分の性格を押し殺して、仕事中はずっと黙ってPCに向かっていました。

― それは、現在の松井さんからは想像できませんが(笑)

松井
でも、そんなふうにしているとモチベーションも全然ないし、スキルも上がらない。そういう状態で何年か仕事をしていて、ほんとうの自分と仕事中の自分の間でジレンマを感じていました。だから、今回のプロジェクトに入って、「PLをやりたい」と立候補したのですよ。自分を叩き直さなきゃ駄目だと思って(笑)。

― ご自分から変わろうとしたのは、何かきっかけがあったのですか。

松井
もうジレンマが積もりに積もっていたのですね。それから会社の上の人が何人か、「お前はきっかけがあれば伸びるよ」と、ずっと言ってくれていたのです。だから今はけっこう素の自分で仕事をしています。

― チームですから、例えば、松井さんがその押しの強さを生かして、みんながずっと思っているのになかなか口に出せないことの代弁者になってもいいですし。

松井
そういう代弁者にはなろうと思っています。例えば協力会社さんにメンバーとして入ってもらうじゃないですか。そうすると同じチームのメンバーなのに、会社同士の関係もあるから、特にマネジャには思っていることがなかなか言えなかったりもするようです。同じメンバーとして話をしていると、そういうことも聞こえてきます。それをきちんと声にできるのは自社の人間だと思いますし、私がその役回りをしようかなとは思っていて、実際にしてもいます。

― 技術者の方は、個別にいろいろ聞くといろいろ言いたいことがあるのに、会議の場だと意外と黙ってしまったりしますね。

山口
僕は、マネジャの立場として極力言ってもらうようにはしていますけどね。でも自分の会社、同じ会社の人同士のほうが、ネガティブな情報も含めてコミュニケーションがよい傾向はあるかもしれないです。

松井
私も今はリーダーというよりメンバーなので、他のメンバーと本音の部分で話しができていると思うのですが、協力会社の人はマネジャの一言で切られてしまうこともなくはないわけです。そうすると、先方の立場としては、なかなか言いづらくなるだろうなと思います。だから逆に自分が上になったときには、下の目線を忘れたくないと思います。

会社の枠を離れた演習で得られたこと

― 今回はオープンコースということで、他の会社さん、さまざまなお立場の会社の方が同じ研修を受けています。そのあたりの感想はいかがですか。とはいっても、回によってもばらつきがありますが。

松井
私の受けた回は他の会社の人が少なかったです。「うちの会社対象かな?」という感じで(笑)。でも自分の会社の中でも、私は金融機関にいるけど、産業のほうから来ている人は、仕事のやり方から何から全然違っています。そういう意味ではやはり新鮮ですよね。例えば金融のほうであれば、下に5人付いていてもPLという立場だけれども、産業のほうでは、規模が小さくて納期が2ヶ月といった短かい仕事があると、下に2人付けてマネジャでやっているとか、一番分かりやすい違いはそのへんですね。

― プロジェクトのタイプによって、どの部分を丁寧にやって、何を端折るかという勘所も違いますよね。

松井
私は産業のほうの仕事をやったことがないのですが、よく聞くのが「とりあえずリリースをして不具合が出たらメンテで直します」ということができるといいますね。金融ではそれは有り得ないので、もうテスト、テスト、テストの繰り返しです。今のプロジェクトも、もう2年半ぐらいやっているのですけれど、単体テストから始まり結合をやって総合、その後、総合テスト2とか、今3とか、そういう感じで進んでいます。「とにかく、危ないところは全部潰しましょう」ということですね。それに金融はシステムが大きいですから、全体を見るのが難しいです。だからずいぶん違うと思いますよ。

― なるほど。山口さんが受講されたときはどうでした?

山口
私は逆に、他社さんばかりの回でした。いろいろな会社さんが集まっていて、多分10何社からいらっしゃっていましたね。

― 山口さんのいらした回は17人くらいだったのですよね。

山口
そうですね。飲料メーカーさんあり、製薬会社さんあり、SIerさんあり。コンサル系の会社さんとかも。

松井
それはまた、うらやましい(笑)。

山口
一緒に手を動かしながら、「これは、こうだよね、ああだよね」って議論していると、考え方はやはり会社によって違うことが分かります。会社の文化が出てくるのですよね。特に面白かったのは、ユーザー企業さんのシステム部門の方がグループにいらっしゃったのですよ。「体制図は出してもらうものだ」とおっしゃったのですね。でも、僕らは「出すものだ」となりますよね。でもその場で話し合っていると「合意するものだ」という結論になったのです。そういうゴールにたどり着く。

松井
ああ、なるほど。

山口
ユーザー企業さんとSIer、ソフトウエアベンダーというのは、何かこう「こっちはお客さん、こっちはそれを受けている人」という切り分けで仕事をずっとしてきたのですけど、そうではないのではないか、と思ったわけです。ユーザー企業さんもそれをプロジェクトだと認めているわけだし、僕らも僕らでそれをプロジェクトだと認めているわけですよね。同じプロジェクトとして認識して、同じ立ち位置で見ないと駄目だなということに、今回のオープンコースでユーザー企業さんのシステム部門の方と話をしたことで気付けたと思います。ただ、不思議なのは、自分が実際に仕事をしていて、もちろんユーザー企業のシステム部門の方とお話はしていたのですが、そのときには全然気付かなかったのですよね。

― そこがこのようなオープンコース演習の面白いところなのです。

山口
今までの仕事を振り返って、「ああ、やはりこのときこうすればよかったかな」とか、「これからそういう機会があればこういうふうにしていこう」とか考えることができました。そういう意味で、いろんな会社の方が来ている演習は、非常に勉強になりましたね。

― それは演習がリアルな力関係のないフラットな場で、率直にいろいろ聞けるからでしょうね。

山口
そうですね。実プロジェクトでは、なかなかできませんね。実際の担当者レベルでは話ももちろんできるし、仲良くなるケースもあると思うのです。ただ全然上にエスカレーションができないのですよ。

松井
できないですね。

山口
エスカレーションする方法は、どのプロジェクトも稚拙というか、ルートがない。

松井
会社の壁は想像以上に厚いですよね。

山口
それはプロジェクトマネジャがやらなければいけないことだと、僕は思いますね。

松井
私も同意見です。実際の現場では、「管理系の仕事はお客様で、こちらは実作業をやりますよ」という切り分けであるはずなのに、お客様が仕事以外に「人」の管理までしようとするところがありますね。しかもそれが必ずしも仕事の管理に結びついていない。
おかしいとは思うのですがお客様に対して問題提起をするスキームが確立していない。これもやはり現場に出て初めて思うことです。
金融のような大きなプロジェクトの特徴かもしれませんが、下手をすると現場を全然見ないで、上からの意向をそのまま通して「ここまでにやれ」という押し付けになりがちです。それではどうすればいいのかというと、プロジェクトマネジャがそこを交渉するべきだと思います。自分の会社のもっと上の人間を巻き込んだり、お客さんの部長クラスだとか、もっとその辺と掛け合ってもいいのではないかと私は思うのです。

(次回に続く)

構成:萩谷美也子

| トラックバック[0件]

トラックバック

このページのトラックバックURL:
http://www.promane.jp/blog_manager/mt-tb.cgi/506

↑ このページの先頭へ