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

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

2006年4月 7日

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

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

経営システム工学専攻、でも新入社員は工場経理から

中山嘉之さん

能登原
中山さんと私はけっこう長いおつきあいですが、今回は改めてこの場で、ご自分がプロマネとして成長された過程を、失敗談であるとか、そこで悔しいので巻き返しを図ったというお話などを含めてお聞きしたいと思います。まあ、いつもの中山さんらしくお話いただければと思うのですが。

中山
なるほど、了解です。まずはどこから話せばいいのかな。

能登原
まず現在のような情報関連の仕事に就かれた経緯を、時系列的にお話しいただければ。

中山
そのあたりはちょっと複雑なんですよ。大学時代は、いわゆる今でいう経営システム工学を専攻していました。そのころはまだITじゃなくて、私の専門はオペレーションズ・リサーチ(OR)と言っていた分野なんです。要するに科学的経営手法っていうのかな。専門って言っても、大学時代ですからさほど深くやったわけじゃないんですが。

能登原
それで、協和発酵に入られたわけは?

中山
動機は曖昧なんですけど、一つには、協和発酵って昭和のベンチャーだったんですよ。あまり固まってない会社がいいな、という気持ちがあったんです。

能登原
大学のときから、コンピュータ関係の仕事をしたいと思われていたんですか。

中山
あまり思っていなかったですね。当時でも本当にシステムをやりたければ、ITベンダーに行ったと思うんだけど、そこまで強い気持ちでもなくて。この会社ならお酒が飲めるからいいかな(笑)と。なにしろ面接で「お酒は飲めますか」と聞かれるんですから。「飲みにュケーション」という言葉を僕はここで初めて聞きましたからね。
会社に入ってから2年間は経理部門で見習いをしていたんですよ。

能登原
中山さんが経理にいらしたんですか?

中山
ええ。当時、うちの会社は生物工学系やケミカル係のサイエンティスト以外、技術系の採用はなくて、学卒はみな事務系で採用していたんです。たまたまそういうところへ入ってしまった。事務系ですから最初の2年間は会社を勉強するという名目でみんな経理をやらされるんです。

私は1980年に入社し、82年ぐらいまで経理にいたんです。そのあと基幹系のシステムを全面的に再構築するプロジェクトがありまして、経歴からそこに呼ばれました。確か当時の情報システム構築の技術はEDP(Electronic Data Processing)って言っていたかもしれない。すごく古いですけど。

能登原
データ・プロセッシングですか。

中山
ええ、そういう時代でしたね。実は最初に誘われたとき、どうも暗そうだったので断ってしまった。そうしたら今度は地方の工場に赴任することになって、さすがに2年もいると、もう何でもいいから東京に戻りたいと思ったんですよ。

能登原
工場はどちらに。

中山
三重県四日市の石油化学コンビナートにいました。作業着に安全靴の世界です。それとヘルメット(笑)。それはそれでよかったんですけど、さすがに2年もいたんでそろそろという気分に…

能登原
ということは、その四日市の工場で経理をなさっていたんですか。

中山
ええ、メーカーですからね。工場の経理から始めて、見習いはそこで勉強しなさいというのが一般的なシナリオなんです。

最初のプロジェクトが基幹系再構築、プログラムを書きまくる

中山
本当はもうちょっと四日市にいるはずだったんですけど、そのプロジェクトが起こって、先輩からお呼びが掛かって、82年からずっと大手町です。それが情報システム(IS)部に来ることになったそもそものきっかけなんです。

当時はホストコンピュータしかなかったですし、基幹系の再構築ということで、オーダー・エントリーから、受注・発注・原材料購買・生産管理、それから債権債務・会計・人事、全部を3年ぐらいやったんですよ。ゼロベースに作り替えて。

能登原
それは全部汎用機上でやられたんですか。

中山
ええ、汎用機上で昔のシステムを捨てて作り直しました。テータベースはリレーショナル・データベースです。RDBのバージョン1.0ですよ。これがとにかく動かなかった(笑)。検索を1回かけたら止まっちゃう。下手したらホストがクラッシュするって、そのくらいの状況でしたよ。

その時入っていたコンサルの会社にデータ総研の椿さんがいらして、その会社が持っていたプライドという方法開発論やインフォメーション・リソース・マネジメント(IRM)ディクショナリーを入れ、かつリレーショナル・データベース化しようと。要するにやり方からツールから全部変えようというプロジェクトでした。OLTPもあったかな、VISがちょうど出た頃ですか。

能登原
あのオンラインの…

中山
オンライン、リアルタイムですね。そのとき私はまず担当したのがサプライチェーンの刷新です。今で言うサプライチェーン・プランニング。当社の薬品部門、フード、それから当時まだ協和発酵にあったお酒のサプライチェーン・プランニングをスクラッチで作ったんです。

ところがこのシステムだけはその頃はまだ下地がなかったんですよ。その時たまたま私はFORCASTとかを知っていたので、「まあやりなさい」と言われたんですが、80年代にはレガシーというシステムにサプライチェーン・プランニングはなかったので、ゼロから作ったんです。そこでプライドの方法論を採用したり、ロジスティックスを初めて勉強しました。今で言う物流じゃなくてロジスティックスは、いわゆるMRPの世界に近いんです。

能登原
生産計画だから原料と生産原価を結びつけるんですね。

中山
そうです。生産と販売のシンクロナイズですね。手法は米軍のベトナム戦争の物資補給の仕組みです。基本的にはロジスティックスって戦争からきているんですよ。どうやって前線に玉を送るかっていう仕組みの、玉の代わりに製品になるだけなんですね。ですから雛形のモデルっていうのは全部アメリカのモデルで、コンサル会社がそれを担いできていたんです。80年代前半ですから当然パッケージなんてなくて、全部手作りです。

僕はシステム部員としてはまったくの新人で、プログラムはFORTRANしか書けないし、COBOLも初めて覚えて、データベースを覚えて、なんやらかんやら新しいことを覚えながら2年で作ったんです。全体では30名から40名のプロジェクトだったんですけども、そこのサプライチェーン・プランニングはマネジャと私を含めて3人しかいなかった。ですから自分でソースも書くし仕様も書くし、自分で書いた仕様を自分でソースコーディングし、自分でテストして、自分で検証をあげる。若干のプログラマーは当時も雇っていましたけども、自分も書きました。2年で200本ぐらい書いた。そういう時代でしたね。それが私の最初のプロジェクトの経験なんです。

能登原
それはたいへんでしたね。

中山
なにしろ入社3年目なんで、どういうのが大変でどういうのが普通なのかっていうのがそもそも分からなかったんですよ(笑)。それがよかったのか悪かったのか…

それから、だいたい2年くらいのアプリケーション・プロジェクトを次々にやりました。サプライチェーンのあとは会計をやったり、営業支援をやったり。うちのビジネスで関係しているところのアプリケーションはほとんどやったかな。
なぜか人事は担当になったことがないですけど、人事以外はほとんどやりました。

自ら意識的に選択したキャリアプランとは

中山
アプリケーションをやってばかりなので、インフラ・ストラクチャーの仕事も4年に1回ぐらい交互に挟んでもらっていたんです。たぶん私のキャリア・デベロップにはよかったと思っています。なぜかと言うと、いろいろなレイヤーを経験できますからね。アプリケーションをやったら、今度はその下のネットワークをやるんです。4年アプリケーションやったら2年ぐらいインフラ・ストラクチャー、また4年アプリケーション。そんな感じで2対1ぐらいでインフラをやらせていただいたんですよ。

能登原
それは上司の方がそういうキャリアプランを組んだんですか。

中山
いや、それより自分が飽きてしまったんです。もう会計を3年とかやると見たくもなくなるんです。サプライチェーン3年もやるともうロジスティックスとか、言葉だけでも聞きたくないぐらいになるんで(笑)。

能登原
そんなものですか(笑)

中山
ですから私自身が「アプリケーションにもう行き詰まっているから、インフラ・ストラクチャーがやりたい」と言った部分もある。特に育成プランがあったわけじゃなくて、「もう飽きたから、ちょっと別なことをやらせて!」という形ですね。そういうのを繰り返して人事以外のアプリケーションをほとんどやってきたわけです。

能登原
中山さんのおやりになっていたころのインフラ・ストラクチャーというと?

中山
とにかく長いですからね。インフラ・ストラクチャーも当然ホストコンピュータからオープン系、Windows、UNIXってところに変わってきた。だから私がインフラをやった時っていうのは、どちらかっていうとプラットホームの変わり目です。ホストからPCが出てきた時代に関わったり、ネットワークがLANやIPネットワークになってきた時に、ネットワークをやったりとか。面白そうな新しいイノベーションがあった時にやらせてもらっている。だから好きなことをやらせてもらって幸せ。それが今までの流れです。

その間の業務知識とかあるいはITの知識はOJTで必然的に身に付いたということになります。

ライフワークはデータベース、DAの視点でプロジェクト遂行

中山嘉之さん

能登原
それが今現在の中山さんにつながるわけなんでしょうか。

中山
強いて言うと、さっき言ったサプライチェーン・プランニングのアプリケーションのころからデータベースが入って、データベースをライフワークにしようと思ったんです。私も新人なわけですが、それまでやってきたベテランのSEって人たちはデータベースを知らないじゃないですか。ということは、これに関しては誰もスタート地点が一緒なんですよね。ベテランも私も。

能登原
スタート地点でみんなが並んでいると。

中山
「ということは、データベースをちゃんとやっておけばあとで役に立つだろう」と考えたわけです。業務知識をたくさん持っているよりも、やはりデータベースならデータベースのメカニズムを押さえておこうと。そのへんは非常に今のデータ総研の椿さんに感銘を受けましたね。業務知識というのはどういう仕事に携わるかで変わりますから、データベースのアプローチを覚えて、それを私自身の技術のコアというふうに勝手に位置付けていたわけです。それを知っているとリード出来るじゃないですか。「リード」って言い方は変かな…要するに自分の好きなようにできるだろうという思いもあったんです。

そういう意味じゃアプリケーション開発も、業務設計よりも切り口はデータベースであって、モデリングしながらアプリケーションを作っていっている。どっちかって言うとトップダウン手法です。ヒアリングをたくさんしすぎてわけがわからなくなっちゃうんじゃなくて、ヒアリングは別に担当者がいて、ある程度は僕も聞きますけども、それはそれ、データベースはデータベースで、真ん中からシステムを作っていくっていう感じのやり方でずっとやってきてます。

能登原
じゃあ、プロジェクトを作る時にデータ・アドミニストレーション(DA)でやられていたんですか。

中山
ええ、DA主体で。DAだけの役割として割り切れるだけのリソースはないですから、時々フロントにも出て行ったりとか。イン・アウトって言うか画面まわりや出力はIS部門にも人員がいるし、ましてやベンダーさんにもいっぱいいますから、それはパートナーにお願いしたりしながらずっとDA中心でやっていました。それが唯一ちょっと人と違うキャリアかも知れないですね。

能登原
でも早いですね。82年の段階でもうすでにそのようにされていたというのは。

中山
それはたまたまコンサルタントがそうだったためと、私の上司がそういう先見の明のある人間だったんです。でも、そう、早いかもしれませんね。

能登原
私が前の会社にいたときに、その会社でもプライドという方法論まではやっていましたが、データベースまではやってなかったですね。

中山
欲張りだったんですよ、非常に。

能登原
その上司の方が?

中山
そうです。その上司はもう会社を辞めて、自分の会社を立ち上げて別の仕事をしていますから、この業界にいないんですけども。たまたまそういう巡り合わせだったんですね。

能登原
その頃はまだ入社してそんなに経っていないわけですから、まだプロマネ的要素はあまり入ってきませんよね。

中山
ええ。入社後初めての、3人でやっていたプロジェクトは、マネジャとしてとりあえず管理職の方がいたけども、あと2人しかいないので自分で自分のマネジメントをしないと無理だというところはありましたが、自分でやるのは簡単ですから。実際に中規模以上のプロジェクトマネジメントをするのはもうちょっとあとですね。

ただDAという入り口から入っていたんで、わりと切り口は一貫していたかもしれません。DAっていうのは、固有のアプリケーションよりもっと広い。いわゆる今で言う、個別最適じゃなくて全体最適っていうような感じです。だからむしろ個別プロジェクトとは相対する関係にあるんですよ。

能登原
DAの視点ではそうなりますね。

中山
ええ、要するにアプリケーション横断的にデータベースを作りますよね。あるいは統合とよく言うんですけども。個別のファイリングシステム作るということではないので、プロジェクトの利害とは話が一致しないんですよ。ある意味で競合関係にあったりしながら、かつ折り合いを付けていくような仕事です。

その軸でやっていくと、システムのクオリティーに対する要求度が違います。データベース屋の世界では、ただ「出来て動きゃいいよ」というのではなく、メンテナンスやライフサイクルや永続性の問題という視点がけっこう入ってくる。そういう目でやれたのがよかったかな。純粋なプロジェクトマネジメントとはちょっと違うんですけど、「自分のプロジェクトだけよければいい」というのより、もう少しハードルが高いんですよ。

能登原
なるほどね。

中山
でも、矛盾もあります。そういうミッションを求められつつ、期限のあるプロジェクトを仕上げなきゃいけないですから、それはそれで完全にプロジェクトの一員になっているということです。私の場合、いわゆる奥に退いて見ているだけのDAとは違ってプロジェクトに入るんですよ。プロジェクトに入りつつかつデータ・アドミニストレーションするっていうのは矛盾するんですけども、まあ、両方のミッションがあったという感じですね。

(次回に続く)

構成;萩谷美也子

↑ このページの先頭へ