2007年10月26日

宮本　文宏さん（４）
日本ユニシス株式会社　人材育成部　ＨＲ変革コンピテンスセンター　チーフ・スペシャリスト

宮本　文宏（みやもと　ふみひろ）さん
日本ユニシス株式会社

人材育成部　ＨＲ変革コンピテンスセンター　チーフ・スペシャリスト

1989年3月　岡山大学文学部哲学科卒業　同年4月　日本ユニシス株式会社入社。UNIXによる開発を多数手がける。
2000年からP2/M等、上流工程からのITコンサルティングに従事。
2002年からソリューション開発領域システム構築PMとしてプロジェクトを担当。
2006年から人材育成部に。

PMを育成する上で直面する難しさ

能登原
それでは人材育成についてお伺いしたいのですが、「うちではこういうPMをぜひ育てたい」ということなど、なにかお考えになっていますか。

宮本
そうですね。去年からPM育成の企画をして、コンテンツをご紹介いただいたりしているのですけど、PM育成に何が本当に必要なのか、非常に難しいと感じています。アーキテクトであれば、まずは技術を教えましょうというのがありますが、PMには何を教えればいいのだろうと。基本的なPMBOKやプロジェクトのプロセス、あるいは「社内でこういうことをやっています」ということは基礎素養として知っておくべきだと思うのですが、先ほどお話のあったような、大規模のプロジェクトを回していける人材をどうやって育成するかとなるとなかなか難しい。何かブレークスルーできるような方法はないのかなと思案中です。 研修だけではなく実際のOJTや現場での育成も含めた企画で、研修と現場をうまくローテーションしていく必要があります。研修コースで基本的なことは覚えるにしても、PMとして中規模とか大規模のプロジェクトを上手くマネジメント出来る人というのは、研修だけでは育成できないですよね。 実践力につながって、再度知識を吸収するサイクルをうまくつくっていきたいのです。ですから全体をうまく回していけるようなPDCAの仕組み等を、現場に対してうまく提供できないか、常に考えています。能登原さん、何かいい育成の方法がありますか？

能登原
では、ぜひ一度営業に伺いますよ（笑）。私は今回の宮本さんのお話をお聞きしていても、人材育成にはキャリアパスが非常に大事だと思うのです。宮本さんもいろいろな経験を積みながら成長されましたよね。私はその部分が重要だと考えています。「このレベルの人になれば、こういうことができる」という目標を若いうちに示して、ペルソナのように目標にできるメンバーの存在を見せてあげるのです。

宮本
抽象的な目標ではなく、具体的な人を見せるのですね。

能登原
ええ、「目標とすべき人は、このくらいの社歴のときにだいたいこういうことができて、このような段階を踏んで昇進しました」という道筋を見せてあげないと。よくソフトハウスの人と話すと、「自分はこの会社に入ってみたけれど、どうやれば目標とするあの人ぐらいになれるんだろう」という不安を持っている人が多いのを感じます。 ですから、まず目標を明確にする。品質管理と一緒です（笑）。 そのときに、レベルの高すぎる仕事を与えると、無理して病気になってしまったりしますから、現在の実力レベルを見て、目標をうまく、しかも具体的に与えて、ちょっとずつ目標を高くしていくのです。ローテーションなどで、そういう筋道を立ててあげるというのがよいと思います。そうすると頭のいい人は、宮本さんみたいに「私はこれをやりたいんです！！」と手を挙げるのではないかと思うのですよね。

宮本
具体的なモデルと、そこへいくパスを見せて、能力よりもう少し上ぐらいの仕事をタイミングよく与えながら、成功体験を踏ませていくというイメージなのですか。

能登原
そうですね。それと、弊社でも社員を育てようといろいろ考えてやっているのですけど、一番効くのは、プロジェクトが終わったら、完了報告を必ずさせることです。

宮本
「振り返り」としてやらせるのですね。

能登原
ええ。発表させて、そこになにかまずいことがあったらどうするかを話し合う。お客様アンケートもいただきますので、完了報告をして、なるべく勉強会のような振り返りの会をやるようにしているのです。 うちもそうですし、御社もたぶんそうだと思うのですけど、みんながそれぞれの現場に行っていますよね。

宮本
ええ。

能登原
ですから、普段はまず顔を合わせないのです。現場から帰って来たときに、そこで得たノウハウを共有する。それをまた弊社の標準に展開するようなことを、なるべく積極的にやってもらうようにしているのです。そうするとモチベーションも出てきますし。

宮本
確かに。PMはわりと孤独というか、孤立しがちです。お互いに違うプロジェクトをやっている人と情報を共有したりすることで、また違う目線になるかもしれないですね。

能登原
PM同士で集まる機会があって、同じ立場の人と話すと、癒されたりしますよね。

宮本
そういう機会がやはり必要なのでしょうね。そういう場をいかに提供して、その中でお互いのコミュニケーションを深めてネットワークつくっていくのか考えないといけないですね。もう少し広く、同じ業界の中でも違った会社の方とネットワークづくりをうまくやっていくとか。アーキテクトはわりと業界の広がりができるのですけど、PMはそれがないのです。

能登原
PMもほんとうはそういうふうにするべきでしょうね。うちのメンバーも、現場がそれぞれ東京、名古屋、大阪と分かれているので、例えば「テスト計画で何かいいのない？」とか、メールが飛び交ったりしていますよ。 それから会社でModus（※弊社方法論の名称）勉強会を開いて、いいアイデアがあればそれを元に弊社の方法論を改定し、製品にして売り、それを使った結果を振り返って、また改定するというところまで考えています。人材育成については、ほかにもいろいろアイデアとかフローがあります。

宮本
実は、去年開催された御社のプロジェクトマネジメントの教育コースには参加しようと思っていたのですが、タイミングが合わなくて出られなかったのです。自分自身の勉強も兼ねて、どういうコースをやられているのか興味があったのですけど。

能登原
うちのコースもけっこう手づくりで、お客さまのニーズをちょっとずつ追加しているのですよ。最初計画編を作ったのですが、「もうちょっと網羅的に」というご要望が出たので、原則編を最初に座学でやるコースを作って、そのあと「コントロールのときも何かほしい」と言われて、コントロール編を作ったのです。そうこうしていたら、あるお客さまが、「教育をやったけれどなかなか効果が上がらないから、もうちょっとなんか工夫ない？」と言うので、半年ぐらいあとにもう一回集まって振り返る定着セッションをつくったのですよ。教育を受けた人は、そこで覚えたテクニックを現場で使うわけですから。

宮本
なるほど。

能登原
現場では研修コースで習ったスケジュールを作ったり、リスク管理をやります。ですから、実際に現場でやったものをまたみんなで持ち寄って議論をするのです。 問題解決もやりますが、そこで上っ面な問題解決しかやらない人がいるとしたら、根本原理を洗いだして対策をしようといったことを、みんな持ち寄ってディスカッションする。この定着セッションだけでなく、お客さまが困っていると、「じゃあ一緒に考えましょうか」という中でコースをつくってきました。また、やるたびごとに修正もかけているので、ですから、すぐ実践的に役立つコースになっていると思います。だからアカデミックじゃないのですけど。

宮本
定着セッションの場合には、研修受けた全く同じメンバーの方が集まるのですか？

能登原
それは全く別の参加です。例えばその会社さんで計画編を何回に分けて実施します。それをみんな現場で実践していますので、その中から何人か集まってもらいます。

宮本
なるほど。それでお互いに議論をするのですね。

能登原
ええ。「自分は、コースで教わったこれを、こういうときにこういうふうにやっているのだけど、みんなはどう？」みたいなことです。

宮本
そこで、真の問題に気づいてやり方を変えていくとか、情報を入れていくのですね。

能登原
ええ、それをやらないとどうなるかと言うと、たぶん宮本さんもご経験があると思うのですけど、「スケジュール遅れました…」ということになると、進捗会議で「遅れているけど、どうするんですか」「いや頑張ります。もうちょっと、頑張ります」というやりとりになってしまう。でも、「頑張ります」というのは解決方法じゃないよなあと（笑）。 遅れたのには、なにか理由があるはずですよね。例えば、計画では一週間工数があったけど、みんな最後の一日、二日で何とかつじつまを合わせようとしてダメだったとか。ものすごく忙しくて、本当に大変なスケジュールだったために遅れたという場合もあるし、理由はいろいろあるじゃないですか。それを突き詰めて、真の対策をとるような訓練をするのです。

宮本
そうですね。本質的な原因が何かというのを見抜くという力は非常に重要です。

能登原
PMも進捗会議のとき、そういう曖昧な発言を許さないとかね。でも多いですよ。「来週中には何とかしますから」とか（笑）。

宮本
結局、何とかならないですから（笑）。解決になってないですよね。

能登原
なっていないですよ。

宮本
PMに関しては、わりと精神論で語られる部分もありますからね。「頑張って何とか改善します」とか。もう少しロジカルに考えるようにしていかないといけないのでしょうね。

能登原
ええ。そういうことについても、教育コースでいろいろな試みをしています。

宮本
なるほど。こういう業界は、製造ラインを動かして、ものをつくっているわけではなく、人がものをつくっていくのですから、人が一番重要というのは間違いない。「人が財産である」という点に着目していく点では、弊社は非常に強いメッセージを出しています。そこで人材育成部では、何名かのメンバーで人材育成戦略を担っているわけですが、私自身PMをやっていたこともあって、PMをいかに育成していくのかをきちんと考えなければと思っています。

大規模プロジェクトのPMに求められる適性とは

能登原
そうですね。PMをやっていた人が育成するのが一番いいですよ。やったことがない人だと、なかなか分かりません。

宮本
そうなんですよ。それから、PMとアーキテクトは微妙に違ったりしますしね。アーキテクトの人は、何かとPMを避ける傾向があったりとか。

能登原
あれは何でしょうね。

宮本
PMが両方を兼ねるケースもあるのですけど、ある程度大規模で複雑なプロジェクトになったら、やはりPMとアーキテクトの両方がいて、お互いうまくコンビネーションを組んで回していくことが必要です。 そのコミュニケーションがよくなくて、PMだけ突っ走ってしまうのをアーキテクトがうまく抑えられなかったり、逆にアーキテクトはいいのだけどPMがうまくプロジェクトを回せいてなかったりすると、だめなのですよ。

能登原
これはドラッカーが言っていることなのですが、理由はよく分からないけれど、みんな得手不得手があるのです。だからアーキテクト的な人は、アーキテクトの部分を伸ばしていくし、PMが得意な人はやはりPMの部分を伸ばす。

宮本
自然と棲み分けられていくのですかね。

能登原
ええ。逆にPMが得意ではないのにPMにさせるのは、無理なような気がしています。ドラッカーは、コストと労力かけるのだったら、伸ばしたらエクセレントになるような得意なことをどんどんやらせておけばいいと言っていますけれど、私も本当にそう思いますね。 コミュニケーション能力はあまりないけれど、テクニカルなところはすごく好きで、集中してやるという人がいるじゃないですか。そういう人はアーキテクトのほうがいいですよ。無理にPMをやらせようとすると、ろくなことはないです。結局そういうことのような気がするのです。

宮本
確かに、そこは分かれます。持って生まれた性格なのでしょうか。

能登原
性格もあるかもしれないです。両者が違うことを前提に、相手に配慮をしながら折り合いを見つけていければいいのでしょうね。なかなかできそうでできないところでもありますが。 ところで、宮本さんがPMをやられたり、人材育成をやられる上で、大学のときに習われた哲学や心理学は何か役に立っていますか。

宮本
そうですね。ロジカルシンキングというか、帰納法や演繹法は、哲学や倫理学的なアプローチの仕方なのですけども、実際の開発をやっているのと近い部分があると思います。それに、心理学の分野で人とのコミュニケーションとか、行動心理学的な部分も、どこか結びついているかもしれません。

能登原
そのあたりのアプローチは、プロジェクトの中でロジカルに問題を分析していって、問題をどうやってみんなで潰していくかというのに近いのでしょうか。

宮本
そうです。問題の本質を突き詰めていく。表層的な問題ではなくて、もっと隠れた本質的な原因があるはずなので、そこを見ていかないとほんとうの対応にならないということですね。 コミュニケーションしているときの言葉や、実際のプロジェクトメンバーを見て、ちょっと顔色が悪いなとか、何かあったのではないかなと思ったら、実は家庭で何か問題があって悩んでいたということもありますよね。そこ無理に「働け」と言ったところで、どんどんパフォーマンスが落ち込んでいくのは目に見えているわけです。そこは相手の身になって、「しばらくプロジェクトから外れて、家のことに集中して、それから戻って来てくれ」と言ったほうが、本人にとってももちろんいいですし、プロジェクト全体を長期に見てもいい場合があります。

能登原
それはありますね。

宮本
いつも表層的に見て、それで「生産性が下がっているからどんどん上げろ」と言っても、上がらないです。本質的な原因が何にあるのかと、現実や現場を絶対に忘れずに対応をとっていくということが理想なのでしょう。 そう思っていても、実際にはなかなかうまくいかないことがあります。本質的な原因がなかなかつかめなかったりしますし、コミュニケーションが大切だと思っていても、PMをやっていると、お客様や社内への報告も多くなる。大規模のプロジェクトのPMをやっていると、プロジェクトメンバ全員の顔を知るのは難しいという現実があります。

能登原
ええ、最近のプロジェクトは、ほんとうにそうなります。

宮本
数値データばかり集めてアーンドバリューで見たときに、コストパフォーマンスを数値上でどうしても判断してしまいますよね。アーンドバリューはアーンドバリューで非常に強力なツールですけど、もうちょっと実際の現物を見ていく必要があります。どういうロジックで数値が集まっているのかも問題ですし、アーンドバリューで見たときは非常にうまくいっているプロジェクトも、実態を見てみると全然違っていることもあります。そこも忘れないようにして、情報をとっていくようにしないと。これが、なかなか難しくて…今までも必ずしも全てのプロジェクトが成功してきたわけではありません。そこはやはり反省点としてありますね。

能登原
そうですね。それは、ほんとうに難しいですよね。 プロジェクト自身の定義が、「一過性で特殊なもので有機的なもの」ですから、同じことを何回も繰り返してやるものではない。常に特別なものなので、もともと難しいのです。

宮本
難しいですね。同じプロジェクトは現実にはないですし、似たように見えるプロジェクトでも、必ず違うし。

能登原
やる人も違いますしね。

宮本
先は読めないわけだし、常にプロジェクトは変わっていく。何が起こるか分からないということです。そこに面白さが見出せるかどうかかもしれないですね。

能登原
そう思います。今、世の中にはそういうものが多くなって、定常的な作業は少なくなりました。

宮本
ええ、少なくなってきています。

（次回に続く）

構成：萩谷美也子