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

HOME > プロマネへの道 > 中山 嘉之さん(4) 協和発酵工業株式会社

2006年6月 2日

中山 嘉之さん(4)
協和発酵工業株式会社 情報システム部 情報システム部長

中山 嘉之さん中山 嘉之さん
協和発酵工業株式会社
情報システム部 情報システム部長
80年、早稲田大学理工学部工業経営学科卒。同年4月 協和発酵工業入社。
82年から本社情報システム部、99年より本社総合企画室を経て、2005年10月より情報システム部長を担当。
DB設計、プロジェクト・マネジメント、システム開発方法論などを専門分野とする。

IS部門が手がけるプロジェクトには「一品料理」の楽しさがある

中山嘉之さん

中山
いろいろお話しましたが、こうして私は今に至っているので、やりたいことをやらせてもらっているし、楽しんで仕事をしてきていますね。今でも時々メンバと一緒に徹夜したりしますが、プロジェクトではいつも新しい発見がありますし。

能登原
けっこう長いおつきあいですが、いつお会いしても中山さんは楽しそうですよね。

中山
楽しいんですよ(笑)。今、サプライチェーンの大きなプロジェクトを持っているんですが、マネジャ連中からは「部長なんですからもうプロジェクトを持つのは止めて下さい」って言われているんです。それなのに「いや、次はね、購買のプロジェクトに入りたいと思っているんだよ」と言って、「ゲー」(笑)とか言われるんですよ。だけど、30%でも20%でもいいから、やっぱり現場にいたいんです。プロジェクトをやっていたい。それで、ここの部長席にはほとんど座ってないです。

能登原
だから、いつも席にいらっしゃらないんですね。

中山
僕がフリーアドレスだというのはそういうことです。必要なところに行くのが好きなんですよ。たぶんソースを書いたりするのは、それほど好きじゃないと思うんです。もう書けないですし。といって、人材とか人事的なマネジメントもすごく好きというわけではないですね。これはもう仕事柄やらなきゃいけないというのはありますけども。何が好きかというと、プロジェクトをコーディネートすると言ったらいいのかな、ディレクションというのかな…

能登原
プロデュースですね。予算を手当てして企画して、映画を作るみたいな。

中山
そうですね。そして、プロダクトのどこかに自分の色を埋め込むのが好きなんです。パッケージでも、パッケージの使い方とかインテグレートのしかたとか、どこかにオリジナリティーは入れられるんですよ。僕は同じことの繰り返しが苦手なので、いろいろ変えてやってみるのが楽しいんです。飽きないっていうか。プロジェクトは毎回違うでしょ。だからそれを楽しんでやっている。

能登原
やっぱりシステム開発は、「一品料理」だからいいですね。

中山
そう、それですよ! 絶対、同じのはないから。でもベンダーさんの場合は、SCMだったらSCMのスペシャリストが、会計なら会計のスペシャリストがいて、一品料理ではあるけれども、同じところを同じ部隊がやりますよね。ユーザー企業のいいところは、同じものを繰り返しやらないということです。例えば会計システムを一回構築したら、それから10年はやらないですから。

能登原
その次にやる時には、また環境が変わっていますからね。同じじゃない。

中山
ユーザー企業では全部、一品料理なんですよ。部品やコンポーネントが同じことはあっても、出来上がったシステムで同じものはないです。時代が違うし、その組み合わせ方によって全く違うものができる。それが面白いですよね。

うちには医薬、バイオケミカル、化学品、食品と事業部が4つあるんですが、これらは全然マーケットが違うんです。でも、現在は7割のコンポーネントを共有しようというスローガンでやっています。それでもまったく違うものができていく。ソフトウェアというのは、いろいろ発想と妄想が働くから面白いです。それに形がないから、壊すというか再構築するのは平気なんですよ。むしろ古いのを生かしてくれと言われたほうが難しくて。スクラップ&ビルドは全然大丈夫。お金と時間は必要ですけど、楽しいですよ。今でもプロジェクトは楽しいです。

能登原
中山さんは仕事だけじゃなくて、余暇を楽しむほうも達人ですよね。スキーもまだ行かれています? 打ち合わせの時にも「夜から行くから」って、もうスキーの格好で来ていたときが…(笑)

中山
ああ、ありましたね(笑)。この前も行ってきましたよ。以前と比べて回数は減りましたが。ずっとやっているのはスキーぐらいですかね。ゴルフは時間がなくてやめちゃったし。ゴルフとプロマネとスキーは両立しない(笑)。
やはり部門長なので、いろいろ細かい用事に取られる時間が多いんです。ラインですから部下が43人いる。時々メールがパンクしそうになって、色んな相談ごとがワーッと来て、もう答えられなくてね。正直つらい時もありますよ。いけないとは思いつつ、ちょっとイラついたり。

能登原
それはたいへんですね。部下の評価もしないといけないし。

中山
そう、教育プランはまだいいんですよ。こちらが主体でいろいろ考えられるから。評価は公平性を考え、かなり時間がかかりますね。それと部下の仕事上の悩み相談とか人事問題みたいなのとか。43人もいればそれは多いですよ。それに加えて対外的な部門間の調整もありますし。

能登原
43人と言うのは、弊社より人数が多いですからね(笑)

中山
けっこう大変なんですよ。だけど今私の下にマネジャが78人いて、相当カバーしてもらっているって感じです。部門間の調整だけは私が出て行かなきゃいけないけど。
その8名中、部内管理の人間を除き6名は、ほとんどプロジェクトマネジャとしてプロジェクトを持てるスキルの人間です。

モチベーションを保つのがプロマネの要

能登原
いつも対談の最後に聞いているんですけども、プロジェクトマネジメントをする時に、あるいはシステムやISの仕組みを作る部分でもいいんですけど、何が一番大事だと思われますか。

中山
なんだろうね、うーん…われわれ社内IS部門では、プロジェクトマネジメントというのが、最も大きな生産行為なんですよ。かつ一品料理なので、出来上がるのが楽しいですし、その課程でいろいろなことがあるんだけど、その場で対応しなければいけないことがあること自体がやっぱり楽しい。だから楽しくするために、何か新しい要素を必ず入れるとかね。

能登原
楽しいっていうことは、要するにモチベーションが高く保たれているということですね。

中山
そうですね。別にITのプロジェクトじゃなくても、モチベーションを保つということが一番大事なんじゃないかと。アナログ、デジタル関係なしに、モチベーションだと思いますよ。

能登原
そういう話は私もよく聞きます。

中山
例えば自分が保守的な立場にいて、リストラがらみのプロジェクトをやろうと思ったらたぶんできないですよ。自分をいかにモチベートするかと言う意味ではITも同じかなと。自分にモチベーションがわかないと、メンバには絶対にわかってもらえない。で、先ほどの話のように、雇われマネジャみたいだと、バカにされちゃう。裏と表があるのもダメ。裏表なし、楽しく、モチベーションを高くもってやるっていうのが、やっぱり一番大事かな。そこにテクノロジーも自然とついてくる。

能登原
裏表なくて、情報もオープンで楽しくっていうのが一番いいですね。

中山
ええ、オープンでやっています。ITのプロマネの中で、このタスクは隠そうとかあまりないですよね。大きなプロジェクトの場合はあるんですか?

能登原
プロジェクト計画が大きいと、あるベンダーの意向で何か突然変わったとかいうケースってよくありますよ。「あれ? いつの間に変わったんだ、こりゃ」「いや、裏でちょっと」というのが、一番モチベーションが下がりますよね。

中山
それはいやですね。でもその手の話は、ユーザー企業の場合にはエンドユーザーとシステムの間で起こる可能性があるんですよ。システム側は、よかれと思って考えるんだけども、実はエンドユーザーは、とくにその中にITコンシャスな人間がいたりする場合は、「実は、自分でやりたいことがもっとあった」とかね。エンドユーザーの真意がISの部門に伝わってなかったという悲しいことが起こる可能性があるんですよ。

能登原
それはありそうですね。

中山
その時はね、完成度のごく浅い段階で「本当は、こうなんじゃないの?」とユーザーさんと本当に腹を割って話してからやらなきゃいけないです。あるいはたまに、一番業務を知っているキーパーソンが参加していないプロジェクトがあるんですよ。そうすると最後にそのキーパーソンがプロジェクトをひっくり返す可能性がある。だから「その人を入れたほうがいいんじゃないですか」と僕らは言うんです。ですから裏と表というのは、僕らの場合、ユーザー部門との間で起こる可能性があって、始めからしっくりきていないプロジェクトはまず成功しない。もともとユーザー部門が気に入らないプロジェクト、要するに失敗してもいいとは思わないけども、あまり乗り気でないのはね…どうしても。

能登原
そういう時には上手くいかないですよ。

中山
いかないです。

能登原
やはりユーザー部門もやる気で、IS部門もやる気のプロジェクト。そうしたらベンダーもついてきてくれますよね。

IS部門のプロマネに必須の勘とバランス感覚とは

中山嘉之さん

中山
一番モチベーションの低下が起こりやすいのは、トップだけが、自分はプロジェクトに加わらずに「これをやりなさい」と言って、ユーザー部門にも「やるんだからね!」といって、IS部門で作れという話になるときです。ユーザー部門がもともとの発信源でない時は、結構リスキーです。

能登原
やらされるって感じですか。

中山
やらされている。で、ユーザー部門はなんとか逃げたいと。「逃げられないですよ」と言っても、なんとか逃げようとするから。

能登原
これはよくあります、ほんとうに。

中山
その時僕らはプロジェクトを立ち上げるかどうかというところで、かなり時間を取るんですよ。「トップがああ言っているんだけどさ、だけど、本当にやる?」っていう確認ですね。「立ち上げてからは早いからさ」とか、「そこのところは、ちゃんとコンセンサスを得てからやろうね」とか、あるいは本当のキーマンがそろわないから「プロジェクト立ち上げるの、ちょっと待とう」とかいう調整をやります、最初が肝心って、さっき言った話に戻っちゃいますが。「実はそんなに乗り気でない」という裏があるのが、だいたい半分ぐらいの失敗要因なんですよ。

能登原
よく言っていただきました。本当にそうですよ。

中山
ユーザーとよくよく話した結果「だったらやらないほうがいい」という結論もある。始めからボタンがかからない時はやらないほうがいい。

能登原
それを言っていただけるのは、中山さんだからですね。やっぱりSIベンダーは言えないんです。だいだい、その部分が分かりにくいんですよ。

中山
そうでしょう。微妙にあるんですよ、空気が合わない時って。そういう時は、やっちゃいけない。IS部門やプロマネはそういう勘も働かなきゃいけないんです。別に人脈とかじゃなくて、どうも乗り気じゃないなとかね。で、よくよく聞くとトップだけが言っていて、現場は乗り気じゃない。それが一番危険です。ボトムから上がってきたのは、まあ、そこそこできますよね。

能登原
そう、いきますよね。現場が必要と感じたことですから。

中山
ただし、ボトムから上がってきた場合は、逆の失敗パターンがあるんです。せっかく作ったシステムが何にも経営のためになってないというケースですね。百人のエンドユーザーから気持ちよくなったと言われて、一円も儲かってないとか(笑)。構築と運用にコストばっかりかかっているのに、仕事も速くなってないとか(笑)。これも気をつけなきゃいけないんですよ。どちらにも気をつけなきゃいけない。ユーザーからだけ喜ばれて、経営から「アホだ」と言われるのも、これもダメなんですよね。失敗パターンとしては、どっちもありがちだけどね。

能登原
経営の視点も必要だということですか。

中山
そう、それがないと、現場は快適、だけど経営者はお金を使っただけでした、みたいなことになってしまう。その両方を、ある程度満たすのは難しいことなんです。

能登原
中山さんの経験とお立場だから言えることですね。

中山
でもね、そういうふうに私が言えるということは、それに近い失敗がいっぱいあるということなんですよね。だから納期とか、プロジェクトとしての表面的な結果が見えるもの以外に、「何を作ったか」ということが本当は大事なんです。
そういう意味では、成功とか失敗を言わないプロジェクトが、実は一番危ない(笑)。とりあえずシステムはできて納期にも間に合ったけど「お金をムダ使いしちゃったかな」とか。どこかに偏ると、そういうことってけっこう起こるんですよ。

能登原
そのとおりです。

中山
でもシステムのプロジェクトって、あまり成功と失敗って2つに分けないですよね。うちなんかも終わったら宴会やって、「終わった終わった、しゃんしゃん」っていうのが多いんですよ。
それで最近、反省会をやるようにしています。ベンダーさんも入れて、どこが悪かったか議事録をとって次に生かそうということを反省会と称してやるんです。だから「もう終わったことは終わったでいいから、お互いストレートにものを言いましょうよ」という会なんです。ベンダーさんによってはいやがることもありますが。
自分のところの問題も言うし、「ベンダーさんもここをこうしたらもっと良かったね」とか、そういう反省会をやっています。

能登原
振り返りを行って共有をするということですね。

中山
そうです。それをやっておくと、必ず次のプロジェクトに生きるからです。「あそこのところでもっと深く考えておけばよかったね」というの、いっぱいありますんで。

能登原
次にもっとよい「一品料理」を作るために、それは非常に大切なことですよね。
本日はざっくばらんに、かつ生々しく(笑)、現場感のあるお話をいただけて勉強になりました。ありがとうございました。

(おわり)

構成;萩谷美也子

↑ このページの先頭へ