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

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

2006年4月24日

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

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

プロジェクト大型化の流れと技術変化の速さの中で

中山嘉之さん

能登原
80年代後半になると、もっと大規模なプロジェクトにかかわられるようになったんですね。

中山
ええ、だんだん大きくなってきたように記憶がありますね。

能登原
具体的にはどういったものをやられていたんですか。

中山
80年代の後半は営業支援システムをやっていたと思います。このときはデータベースといっても、今で言うデータウェア・ハウジングにやや近い感覚かも知れないですね。

能登原
データウェア・ハウスというのは、もうちょっとあとに盛んになったものですね。

中山
ええ、そうなんです。私がその営業支援システムをやっていた80年後半頃のデータベースは、DBMSそのものがデータウェア・ハウジング機能を備えていないです。要するにクエリー系ですよね。基幹系で出た情報をデータベースに移植して、それをいろいろな切り口から利用するということをやっていました。いわゆる「スター・スキーマ」が出てきたりしたのはもっとあと、90年代の後半かな。

能登原
後半ぐらいですかね。90年代半ばから後半。

中山
はい。だから本当の意味の「データウェア・ハウス」はそっちで、当時のシステムではデータの再利用がそれに近かったというくらいの話です。
90年代の前半になると、会計のフロントの仕組みを作りました。これも結構、ミッションクリティカルなんですよ。債務管理だったり、オーダー・エントリーの後ろで、請求を出したり売掛金管理したり、あるいは在庫を管理したりというものです。ですから会計と言っても、いわゆる一般会計、[GL]とは違います。この開発のときはまだホストコンピュータでした。

能登原
90年代の前半にパソコンが出てきて、そのころはWindowsの3.1があるかどうかでしたね。

中山
そう、Windows 3.1が出たのが、92か93年じゃないかな。
そのあと、93か94年から会計システムをやりました。これが大きなプロジェクトだったんです。最初にクライアントサーバが出た時代で、私の記憶だと1年半ぐらいのプロジェクトでWindows 3.1で開発して、稼働して2ヶ月後にクライアントをWindow95にバージョンアップしたんです。つまり3.1の時代がすごく短かかったんですね。開発しているうちに95が出ちゃって、「世の中95になるよ」って言うので96年ぐらいに95に書き換えたんですよ。そんなことをやっていました。

ちょっと話が戻りますが、先ほどお話した80年代の後半っていうのは今で言うDECの時代ですね。汎用機じゃないんですよ。ミニコンです。

能登原
ミニコンってありましたね(笑)。

中山
そこで僕はリレーショナル・データベースを結構勉強しました。あとネットワークもね。データ再利用のプロジェクトで、データベースを作れば情報の切り口はどんな取り方も出来るんだとわかった。DECのデータベースは汎用機のデータベースとちょっと違うんですよね。

能登原
DECのRDBですかね。DEC純正のRDBを使われていた。OSはまだUNIXの前のVAX(バックス)で。

中山
OSはね、VMSですね。オープンVMS、VAX(バックス)です。PDPとかMicroVAXとかいって。ここで勉強したのは、DECのリレーショナル・データベースと、それからDECNETです。これも今でいうIPの前身ですよね。それからリレーショナル・データベースもSQLが出る前ですね。80年代でそういうものを勉強して、90年代はオープン系が出てきた。90年代の後半はインターネット、Webの時代。

能登原
そうですね。

中山
このあたりの技術の変化は速かったですよね。先ほど言った、会計の仕組みをクライアントサーバで作っているときにWebが登場したんです。それで私の先輩から「もうこれは役に立たない」と、きついお言葉をもらいました。システムがあと1~2ヶ月で動くという時に、「書き換えた方がいいんじゃない」って言われたんですね。でも、そのときはやりませんでしたけど。

従ってそのアプリケーションは、わりと短命に終わったんですよ。作ってから7年、ちょうど2002年に、そのアプリケーションを書き換えました。この2002年から作ったグローバルな会計の仕組みが、一番大きいプロジェクトでしたね。

能登原
その2002年からのシステムで採用したのがGLOVIAですね。

中山
そうです。社内・社外含めてトータル人月数が1800人/月くらいですから、ちょっと大きかったですね。うちはそれまでにも7~800人/月というのはあるんですけども、あまり1000人/月を超えるプロジェクトはなかった。それが1000を超えて1800までいっちゃった。しかもそれが2年だったんですよ。2年で1800人/月というのは、割り算すると結構きついです。

能登原
きついですよね。年約10億弱は必要ですから。

中山
そうなんですよ。…ということは、同時に働いている人が10人20人じゃないわけです。

能登原
100人単位ですね。

中山
プログラマーまで入れるとすごい数で、とにかく大きいプロジェクトでした。
その一番会計のが大きかったですけど、入社してちょうど10年過ぎたぐらいからは、大きなプロジェクトをマネジメントすることが多くなってきました。

ITと経営からの視点とのダブルミッションが要求される

中山嘉之さん

中山
プロジェクトマネジメントに関しては、うちの場合、80年代からずっと、アプリケーションを作る時にはユーザー側の代表のプロマネというか代表者、それとシステムサイドのプロマネと2人出すんです。責任範囲は違うんですけども必ず両方いて、その上に、実質的には関与しないプロジェクト統括者みたいなポジションがある。

能登原
オーナーですか。

中山
ええ、要するにオーナーですね。最後の時は責任を取る人です。お金の問題などはオーナーが最後まで責任持って、その直下の2人がだいたいペア組んでプロジェクト管理をやるというのが一般的なやり方なんです。

能登原
中山さんはIT側のプロマネですか。

中山
私はIT側ですね。でも、ちょっとその辺が微妙な入り方のときもあります。最近は経営企画室を兼務したり、ちょっとガバナンス軸と言うか、経営という第三のミッションが入ってきている。

業務やシステムという軸と、経営という軸はまた違うんですよね。いくら業務の人が気に入っても、いくらシステムがいいのができても、経営に資するところがないと何をやっているか分からないという話になりますので。経営企画室兼務で会計システムを持った時もそうですし、最近私はその課題を与えられる時が多いんです。別に経営企画室兼務をしなくても、経営という課題がオーナーから降りて来る時もある。ですからこれからもありそうですね。

能登原
IT側のプロマネという時と、経営軸に重きを置いてプロジェクトに関わられている時の観点の違いとか、中山さんが工夫されていることとかって何かありますか。

中山
両方やらなきゃいけないんですが、その二つのミッションは全然別のものです。でも本来、企業の情報部門は、その二つを担うのが本当の役割じゃないかと常々思っていました。そこがわれわれがベンダーさんと違うところですね。だからIT部門じゃなくてIS。インフォメーション・システム・デパートメントなんですよ。

能登原
そのとおりですね

中山
システムはツールだけでも成り立たないですし、組織全体の仕組みもシステムそのものです。そういう観点で見るとあまり変らないと最近思っています。いわゆる純粋なISと経営システムは違うと思いますけども、私たちのような企業内の情報システム部門は、ITは道具であって、作ろうとしているものはインフォメーションシステムだと理解しているんです。

能登原
それについては、私もだいたい考え方が一緒です。

中山
だからデータモデリングだったり、あるいはインフォメーション・リソース・マネジメントだったり、データベースという道具を使う。どちらかというと経営資源管理という考え方の方が近いですよね。システムは経営の資源と考えています。

経営の資源といっても、現場が喜ぶ資源もあれば、経営者が喜ぶものもある。これはもうピンからキリまでありますけど、いずれにしてもインフォメーションシステムです。それを個別最適よりも全体最適という視点で見ていく。それは82年に私がプライドなどで最初に教わったことにも全部書いてあることですけど。

能登原
ええ、書いてありますね。

中山
だから、そのころと全然軸は変わっていない。道具だけは変わったけども基本は全く変わっていないんです。

能登原
中山さんはERwinユーザー会を90年の半ばぐらいから盛んにやっていましたよね。中山 ERwinは、データベースをアドミニストレーションするために使う道具として考えていたんです。その絡みで参加した記憶があります。1995年ぐらいですから、会計システムのころですね。会計なのでやっぱりERwin使って。だからやっぱり、自分自身の軸はあまり変わっていないんですね。

私の場合、プロジェクトマネジメントテクニックは当時教科書がなかったんで、完全にOJTで学びました。OJTで試行錯誤っていうか。ただ、納期がみんな厳しくて、試行錯誤をしている時間も、失敗している時間もないんですね。だからそこはもう、臨機応変にその場その場で考えた最適化でやらざるを得なかった。

ただ、そこでもプライドが役に立ちましたね。昔はウォーターホールだったんですけども、実はプライドをよく読むと、「必ずフェーズの先頭で、あるいは前のフェーズのラストステップでは次のフェーズのことをもう計画しろ」とか、あるいは、「早い段階からリスクマネジメントしろ」とか役に立つことがたくさん書いてあるんですよ。これをちゃんと読んでいない連中がウォーターホールはだめだとか言うんだけど、大きなフェーズ取りの中でやるべきことというのは、実はあまり変わっていないんですよね。「先のことを読め」とか「再見積をかけろと」か、それにしつこいくらいにドキュメントを作りましたよね。むしろ昔のほうがそういうドキュメントはしっかり作っていたんですよ。

能登原
そうでした。ドキュメントをずいぶんたくさん書きましたよね。

プロジェクト難易度は増したのに、プロマネができない世代の問題

中山嘉之さん

中山
そしてそれに続く90年代が、データ総研の椿さん曰く「失われた10年」だったんですよ。90年代にオープン系の環境が出てからドキュメントを書かなくなった。これでガーンと質を落としたおかげで、その90年代に作ったアプリケーションは短命に終わったんです。2000年に入ってもう再構築にかかっていますよ。でもホスト時代のアプリケーションはまだ残っているんですから変な状況ですよね。90年代はテクノロジー優先の10年で、今またマネジメントにまた少し戻ってきたっていう感じがします。90年代は、みんなでハチャメチャにものを作っていた時代で、あんまりプロマネということを言いませんでした。

能登原
まあ、言いませんよね(笑)。

中山
表に出なかったと思いますよ。プロマネよりソース書けるやつのほうが偉かったですから(笑)。

2000年に入って、大型のプロジェクトが増えてきて、それで失敗事例も多く出てきたんで、「じゃあプロマネって何をやるの?」と。再びそこに脚光が当たってきたかなと感じています。だけど僕らは80年代にそれを1回経験しているから、それほどお作法が違うとは思っていなかった。ところが、90年代に初めてIT部門に入った人間は、プロマネをすること自体がきついんですよ。プロマネ軽視の時代に入社しているからマネジメントが辛い。つまり90年代前半に入った人はプロマネを1回も経験しないで2000年を迎えて、いきなり「10年経ったから日々のプロジェクトでプロマネやりなさい」ということになってしまったんです。僕らはもうひとつ前の時代にやっていたので、大きなプロジェクトのマネジメントはどんなものかがわかっているし、しかも最初にやった経験がすごくきつかったんで、身に染みている。それに私はインフラも経験があるので、アプリケーションだけを見るんじゃなくて、同時にインフラも見るのにたまたま慣れていた。そういう経験から今日に至っているわけです。

ただ、昔のホストの時は、アプリケーションは4つ5つあってもプラットホームはホストコンピュータのOS一丁で、ランゲージはCOBOLとか決まっていたんですけども、今はオープン環境になったということもあって、プラットホームというかインフラ・ストラクチャーまで開発する時もあるし、インフラはインフラでやるタップがタスクがちゃんとあって、そこにアプリケーションの構築部隊がいて、かつユーザーの構築部隊がしっかりしなきゃとか…あるいは運用設計もちゃんとやってデータセンターに預けなきゃとか、要は同時にやることが圧倒的に増えています。そこをマネジメントしなければいけないわけですから。

能登原
ええ、条件としては今のほうがずっと厳しいですね。

中山
そういう意味では今2000年代のプロジェクトマネジメントは、マネジャーだったら技術は何でも見られるようじゃないといけない。もっと部下に任せるという手段もあるんですけども、そんなにリソースがないですから、それもなかなか難しい。

先ほどの1800人/月のプロジェクトのときには、私がプロマネをやって、その下に社員は4名でした。私を入れて5名というメンバです。確かユーザー側から2人とか3人でしたね。だから実働部隊は圧倒的にベンダーさんなんですよ。大きいプロジェクトでもその程度で、小さいプロジェクトは社員1人でベンダーさん10人が一般的なんです。つまり今情報システム部にいる連中は、プロジェクトを1人1個背負わされるんです。まだペーペーの新米でも背負わなければいけない。

能登原
それは大変ですね。中山さんのように、プライドの経験があって、一応もうこういうものだとわかって、データベースも分かる人なら、プロジェクトごとに「こことここはもう考えなくてよくて、他のところだけ考えてマネジメントすればいい」切り分けができる。そういう軸がない人は結構きついですよ。あるいはその軸がブレていると。

中山
実際、それで失敗が多いんですよ。私だって全部は見られませんから。報告が上がってきた時はもう遅いぐらいですから、私はメールでも先にCC見ますからね。

能登原
CCですか?

中山
自分が宛先の時は自分で処理出来るからいいんだけど、CCっていうのは同報だから、早く手を打たないともう他のところへ行っちゃうんですよ。だから、そこで押さえなければいけないものを見分けて早く実行に移すために、最初にCCを見るんです。ちょっと余談ですけどね。

能登原
なるほど。そういう工夫は大事ですよね。

中山
だいたい危ない情報はCCにあるんです(笑)。自分のところで止まるメールはまだいいんですよ。OKしなきゃいいですから。でもCCもいっぱい入ってくるし、自分でも全部は見られない。そういう状況の中で、90年代に入った人たちのアプリケーション・プロジェクト・マネジメント能力の低さが課題なんですね。正直に言うと、彼らはプロマネができません。昨年プロマネ研修会に出させていただいたのは、そこなんですよ。「僕らみたいな形では経験を積めないなら勉強するしかないだろう。まずはプロマネ初歩の研修をしましょう」ということです。短期間でプロマネをある程度のスキルにするには、まず勉強しないといけない。それプラスOJTっていうことなんだと思うんです。

先ほどもいいましたが、ろくにプロマネができない人間が、1人で1個プロジェクトを持たなきゃいけない状況なんですから。これはきついですよ。

能登原
そうですよね。

中山
しかも、ベンダーさんが入って来ますから、ともするとうちの社員がメッセンジャーみたいになるんですよ。「エンドユーザーがこう言っているから」と繋ぐ役とか。コーディネータって言うと聞こえがいいんですけども、コーディネータまでいかないですよね。メッセンジャーぐらいです。で、「ベンダーさんからこれが出来ませんと言われました」と(笑)。これではISという役割になってない。

能登原
それはあまりにもったいない。

中山
もったいないし、存在意義が分からない(笑)。そこで最近は教育をやろうかということになってきたわけです。

能登原
でも1人で一本背負っていたら、研修に出ても真剣でしょうね。

中山
とにかくせっぱ詰まっていますからね。しかも、失敗が多いんです。まあ、いきなり失敗というきつい言葉は使わないですけど、納期通り上がらないのを失敗と言えば、8割ぐらい失敗なんです。納期通りっていっても、ある部分外注に回したりとか、多少範囲を縮小したりして、やっと納期通りとかね。残念ながら、プロジェクト開始時点に描いたスコープ全部を、納期通りにきちんとやれるプロジェクトがほとんどない。1割もないと思います。

能登原
計画をちゃんと作っていないのか、あるいは計画はちゃんと作っているんだけどコントロール出来ないのか、どっちが問題なのかが、また難しいとこですね。

中山
たぶん前者だと思います。計画が出来ていないんですよ。

能登原
そうですか。計画の作り方が分かっていれば、全部のタスクを洗い出して、リスクも分析できるんですけど。たぶんそれができてないんでしょうね。

中山
例えば仮に、ユーザーがどうしても来年の4月にやってくれというプロジェクトがあったとします。ITの人間はボリュームを見て「4月までにできるのはここまでですよ」と答えないといけないわけですよ。計画をちゃんと立てずに答えるというのは、まずその段階でダメです。次にプロジェクトを進めていくにつれて遅れが出るという、二次災害的な場合があるわけです。両方あるんですけれども、僕らが見ている感じでは最初の要素が大きいような気がするんです。

能登原
計画がうまく立てられていないということなんですね。経験していれば、あるいはノウハウの引き出しをたくさん持っていれば、そこで勘が働くわけですけど。WBSも自分で洗い出せるし。

中山
そこはやはり経験が問題なんですよ。とにかくWBSが引けないんです。1週間分なら引けるんですけど1年間のWBS引けない人間が多い。

僕の場合には、1980年代にプライドをやったときにメソドロジーを叩き込まれ、それにプラスOJTがありました。まして新人だったので、メソッドの言葉を覚えられるぐらいやった。「フェーズ1、アクティビティFでは次のフェーズの見積もりをせよ」とかね。今でも言えますよ(笑)。そこにちゃんと「リスクを洗い出せ」とか書いてある。それは暗記していないけど(笑)。そのくらい叩き込まれましたね。

能登原
いまでもそらで言えるぐらいですからね(笑)。

中山
そういう基礎がないというのが、大きな問題だと思うんです。

(次回に続く)

構成;萩谷美也子

↑ このページの先頭へ