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

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

2006年5月22日

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

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

プロジェクトマネジメントの状況を変えたERPと反復型メソッド

中山嘉之さん

能登原
90年代は、中山さんや僕が「データベースが大切だ」って言ってもみんな聞いてくれなかったですよね(笑)。

中山
モデラー冬の時代だったね(笑)。「とくかく作るしかない」っていう時代でしたから。まあ、がんばってもせいぜい「いいデータベースを作ろうか」なみたいな感じですよね。それが90年代だった。それからはERPのムーブメントの影響が大きかった気がしますよね。

能登原
それはどういう?

中山
ERPも、どうもそう簡単ではないとわかってきた。アドオンやカスタマイズで「やっぱり大変なことになっちゃった」ということが多かったし。そういう事例が世の中にはいっぱいある。それで、プロジェクトマネジメントでもアプリケーションに光が当たってきたという流れかな。

能登原
なるほどね。

中山
それからプロジェクトマネジメントにはある程度普遍的な決まりごとがあって、それはやはり有効だということがわかってきた。たとえば「必ず先のことを考えろ」というのはプロジェクトでは非常に大事なことですよね。1年なら1年、2年なら2年なりのWBSを作るときに、どれだけ先を「予習」出来るかというのがポイントです。プロマネの仕事は僕も経験していますけども、一番大事なのがプロジェクトを立ち上げる前と、立ち上がって前半の4分の1あるいは3分の1ぐらい。ここが一番大変なんですよ。もちろんその後も軌道修正とかモニターが必要で、それも臨機応変にやらなければいけないんですけども、どっちが大変かっていうと立ち上げと前半だと思います。ここが「みそ」なんだけども、90年代の人たちは、アウトラインを書かないでまず作り始めるところから入っちゃう。

能登原
そう、いきなり入ってしまうんですね。

中山
だいたいいきなり入りますよね、あるいは入りながら考えようとか。小さいプロジェクトはそれでもいいんですけど、大きいのはアウトラインを書かないと後で大変なことになります。ですから私は人材のリソースや体制とか、図にもすごくこだわりますよ。部下の描いた図を見たときに、「このプロジェクトはやばい!」と分かるんです。

能登原
たとえば? どんなところが「やばそう」なんでしょうか(笑)

中山
たとえば部下が体制図を持ってきたとしましょう。体制図なんだからヒエラルキーができていた方がいいですね。ところが、ヒエラルキーの上のほうがでっかいとかね、下がどこに繋がっているか分からなくて、点線とかが描いてある(笑)。さらにユーザーの中で一番よくものを知っている人が体制図に入っていないとか…

能登原
それは危ない(笑)

中山
そんなふうに体制図のマップを見た時に、これはやばそうかなと感覚的に分かるというのが最近の傾向ですね。だからそこにすごくこだわります。その体制が出来てゴールまでのWBSができれば、極端に言えばプロジェクトの半分はもう終わりですよ。

能登原
私もそうなんですけど、モデルができればシステム開発はもう終わったと言われましたよね。

中山
モデルができるということはベースラインが出来るということで、昔のプライドだとフェーズ1とか2ですが、今は立ち上げと方向付けから遂行の終わりまでですね。作成になると、あとはもう自分のミッションじゃないという感じです。一番大事なのは方向付けですけど、遂行フェーズぐらいまででモデルがフィックスしますので、それでだいたいもう大丈夫と。

最近の新しい反復型メソッドも、基本は大昔とそんなに変わってないんですけども、道具を使いながら早く「もの」を見られる。見ながらやっていくっていうのが今流だと思うんです。それでも全体のフェーズ取りというか方向付けが大事で、遂行までで勝負が決まるというのは変わらないです。

能登原
そうですね。

中山
そのかわり昔より安心できるんです。もう遂行フェーズでベースラインが見えていてものが動いていますから。最近、パッケージの時も同じようなアプローチをしています。まずベンダーさんとパッケージを買う契約をしたら1ヶ月後ぐらいにスタンダードエディションをインストールして、一方では一生懸命データを作って、まず第一反復は遂行フェーズの時にやる。それを動かしながら、「何が足りない」「じゃあ、どうしよう」ってアドオン計画を遂行フェーズで立てるんです。もう最初から反復でやるわけですが、そのかわり裏で実物データを用意するんですよ。全くの新規のシステムだったら新しくデータを取ってこなきゃいけないですけども、だいたいは再構築だからデータはある。つまり「データを用意する係」がいて、その人は移行フェーズまでデータをやり続ける。その部隊でデータベースも作るんです。

今サプライチェーンのプランニングをやっているんです。ちょうど20年前に入れたシステムの他の部門の適用を、さすがにもうホストじゃないですからパッケージを入れてやっています。そのプロジェクトがちょうど1年の工期なんですけど、もう3ヶ月を残した時点でベータが動いているんですよ。あとはマスターをクレンジングしたり、ユーザーの教育をやるモードに入れる。昔では考えられないぐらい早いし安心できます。最悪の場合でもベータより悪くならないですから。
ウォーターフォールでやると、ドキュメントに漏れがあったりして、そこでぐしゃっと潰れる時があるじゃないですか。

能登原
ええ、それってありますね。

中山
それを予定してスケジューリングするのがプロマネの腕ですけどね。稼動時期についても、時にはメンバまで本当のところを明かさない(笑)。エンドユーザーとプロマネはほんとうの時期が分かっていて、制作側にはもっと早く言っておく。

能登原
それはもう、ものすごくよく分かります(笑)。

中山
そうすると、もし「ぐしゃっ」ときてもあと2ヶ月ぐらい余裕がある。スパイラルの時は初めから「ここがベータだ」と言って3ヶ月も余裕を取っておくとか(笑)。ただし、ベータはベータでマイルストーンを決めてそれができないといけないから、そのレベルに達してないと、やっぱり「遅れは遅れだ」っていうのが可視化されちゃう。厳しいことは厳しいんですけど、全体の工期がかなり見えるし、かつ、品質も途中でチェック出来るようになった。最近はもう、うちのパッケージ開発あるいはスクラッチはほとんどそれでやらせるようになって来たんです。まだ、ベンダーさんの方が「ウォーターフォールじゃないと嫌だ」っていう場合があるんですが、うちとしては「こっちの方がいいですよ」と言って、それでやってもらったりすることも結構ありますね。

能登原
とはいっても、ウォーターフォールと反復型の大きな違いは、「ものを早く作って見せながらやる」というだけですよね。

中山
そうなんだけど、データ担当者も結構怖がっちゃってね。

能登原
それはおそらく前提条件として、先ほどのお話の「すぐ作り始める」程度のスキルの人が集まっているからだと思います。

中山
その通りです。それでもパッケージの時には、ものを早く作って見せるということができるし有効だと思うんです。ベースラインが8割がたできていますからね。世の中では、反復型はスクラッチの場合に適応し、パッケージの場合はパッケージの導入方法が決まっているよく言われますけれど、僕はそれは逆だと思っています。パッケージこそ反復型適応ですよ。むしろスクラッチの方が難しい。「できる人間」が揃ってないとできないですから。だから今でもスクラッチがウォーターフォールになる時があります。ただ大規模なスクラッチってあまりないんですよ。大規模のはだいたい基幹系ですから、パッケージがあります。スクラッチの場合はもっと小振りで特殊なものになりますね。

能登原
我が社の中にしかないみたいな…

中山
そう、それは小さいから結構反復でもいけちゃう。従ってほとんどが反復になりつつありますね。ただパッケージの方がやっぱりハードルが高いんですよ。ベンダーさん、パッケージベンダーではなくSIerさんが、やっぱり今まで慣れ親しんだやり方じゃないと怖がるんです。

実は、最近それで失敗したプロジェクトがひとつあります。医薬系のシステムにはコンピュータバリエーションという領域でGMP・GLPという法規制があります。GMPは医薬品プロダクトの製造品質を、GLPは医薬品の開発品質を保証するものですが、それらをマネジメントしてるコンピュータシステムもバリデーション対象になってるんです。

能登原
品質に関して非常に厳しいんですね。

中山
そこにIQ、OQ、PQ等の品質管理のライフサイクル体系があるんですが、これがウォーターフォールで書かれているんです。だから、あたかもウォーターフォールでやらなければいけないかのように錯覚しがちです。

それで僕は「それは反復型適応しちゃいけないっていうものじゃないよ。しかもその中でマイルストーンが規制されるということは、ウォーターフォール以上に中間のドキュメントなり中間のブツでマネージできるんだから、もっといいんだよ。RUP反復型とエンドレスなスパイラルは違うんだよ」って言ったんですが。結果、典型的ウオータフォールでやって、システムが上がってきた時にバグがぽろぽろ出て、納期が大幅に遅れてしまった。若手プロマネも、ベンダー側、ユーザ側の個別問題もあるものの、“ウォーターフォール型開発手法に起因する問題がかなりある”ことを認めています。

能登原
もう認めているわけですね。

中山
この辺りがリスクって分かっていても、結局ものが顕在化しないから「やばい、やばい…」と思っていても結局先送りになりやすいのがウォーターフォールの欠点です。ありがちな陥りやすいパターンっていうか。ただ私も、プロジェクトの方法論をもう少し社内のスタンダードとして伝えていればそういうことは起こらなかったと反省しました。ですから最近は「まず繰り返しでやる!」「パッケージこそ繰り返し!」と言い続けています。極端に言えば、ベンダーさんが繰り返し型を提唱しないパッケージの導入はできないと、そこまで言ってもいいんじゃないでしょうか。とにかくリスクを潰すことです。

能登原
これはいいことを聞きました。パッケージこそ反復型!

中山
僕も最初やった時は怖かったんですよ。で、いろいろ考えて1年なら1年を自分でシミュレーションしてみたんです。だけど悪いところが見つからなかったんですよ。「ものが最初に見えていてどこが悪いの?」ということですね。だから怖がる人は、単に反復型に慣れてないということだけじゃないでしょうか。

冬の時代にも継続して伝承できた「資産」

能登原
お話をお聞きしていると、90年代に入った人たちには、中山さんにはありありと見えているものが見えていなくて、中山さんとしてはそれをどう伝えていいのか、なかなか難しいことですね。

中山
苦しいし、難しいですよ。アイ・ティ・イノベーションさんに研修をお願いし、さらにOJPで若手をとにかくプロジェクトに入れて「こんなやり方でやりましょう」と教育していますが、それでもやっぱり伝わらないところが多いです。唯一できるのは自分で管理をしているプロジェクトですが、中身をちゃんと見られるのはせいぜい3つです。プロジェクトのレビュー会議に3つ出ただけでもう週3日潰れちゃったりしますから。その中でやっている人たちは、時々私もアドバイスできますが、それ以外の人は見られない。だからCC見たらすでに手遅れになっていたりするんですけど、まあしょうがないと。

あとは、どれだけ早くミドル人材を回転させるかですね。プロジェクトは最低でも6ヶ月、長いので1年2年ですから、そんなにぐるぐる回せないし、そこのところをどんなふうに回すかも悩ましいんです。プロマネとサブプロマネがいれば、途中からサブプロマネだけ違うプロジェクトにスイッチするのを時々やりますよ。ベンダーさんじゃなくて社員だから、サブプロマネぐらいだったら可能なんです。

能登原
御社の場合、中山さんはたぶん今も方法論やデータのモデリングにこだわっていると思うし、勉強されていると思うんですけど、その基礎があるから、あとはマネジメントのところをちゃんとやればよい。そういう面では有利な立場にあるのでは。
その基礎がない会社では、これから全部やらないといけない。

中山
そうですね。私は今具体的な現場のモデリングはほとんどやってないんですけども、一応、何人かはモデラーというか、データモデリングができるようになっている。そこのところは伝承したという気持ちはあります。うちではデータモデリングをやらないプロジェクトはあまり多くはないですね。エンジニアリング系にはあるかも知れないですけども、データベースはみんなやっては来ている。

能登原
協和発酵さんは90年代の「モデラー冬の時代」もきちんとそれをやられてきたんですね。

中山
冬の時代できつかったんですけど、たまたま出来たんですね。例えばIRMのデータベースはメタ・データ・リポジトリといいまして、まあ、ディクショナリーというかデータの定義が全部入っているデータベースなんですけど、去年の秋にやっとホストからオープン環境に移しました。データベースはちゃんと生きているわけですが、最近、ホストはあまり利用しなくなっているんでWindowsにもっていったのが去年というわけです。

能登原
そうですか、ついに。

中山
うちの場合、「データ定義なりレコード定義なりシステム定義なりを、きちんとそのディクショナリーに入れること」を一応、ルール化していたんです。本当はプロジェクト実施時にやるものなんですけど、終わってからでもいいから、とにかく理屈抜きでそれはずっとやってきた。その資産があるんで、Windowsでもできるわけです。そのメタ・ディクショナリーの資産が、いまだに残っている。ごく小さなシステムが入ってないとかありますから100点はとれてないですけど、だいたい基幹系のものは全部入っています。

モデルも昨年全部書き直しました。これは通常の仕事の時以外の時間に、社内の改善運動的な小集団でやりました。それでもね、やっぱりモデルドリブンですべてのシステムについて全員が会話できるかというと、それはいまだにできていません。

能登原
それはかなり高い目標ですよ。

中山
まあ、できていないんだけど、モデルドリブンで会話できる人間を1人でも増やしていこうとはしています。とにかく後退はせずに、少しずつそういう人が増えている。それに、そういう人がプロマネになるケースが多いですね。

プロマネ、あるいはISというポジションはどのようなものか

中山嘉之さん

中山
プロマネはその人のコアテクノロジーというかスキルというか、ひとつ専門科目を持つべきだと思います。別にデータベースじゃなくて、ネットワークでもいいかも知れないです。今ネットワークは花形だし。とくかくプロマネをやる時に一番大切なのは、「バカにされないこと」です。

能登原
バカにされない、ですか。

中山
部下からバカにされないことですよ。プロマネが部下に侮られると、そのプロジェクトは危ないんです。部下が言うことをきかなくなるから。だから何でもいいですがとにかくなにか専門性を持っていることです。この道で専門だという人がプロマネに立てば、専門外のところは部下が補ってくれます。だけど専門が何にもなくて、人材の通信簿だけを付けているようなマネジャがプロマネをやると、若い人たちから最も嫌われる。

能登原
いわゆる「管理のための管理」になってしまうと嫌われますね。

中山
そう、日本語で言う管理職と、プロジェクトマネジャは違う職種なんですよ。だけど一般企業ではシステム部門でも例外ではなく、マネジャは管理職という職制の人がついて、人を採点する係になりがちです。その両方が出来る人はいいんだけど、そうじゃないケースがありますよね。人材のマネジメントは得意だけど、テクノロジー系はできない人ではうまくいきません。いくら人使いが上手くて、部下のおだて方やにんじんのぶら下げ方が上手くても、まったくテクノロジー的な会話に加われない人にはITのプロマネはできないと思いますよ。

能登原
プロジェクトの中では問題が頻発するじゃないですか。それを解決出来る能力がないプロマネは信用されないですよね。

中山
そうです。プロマネはそのためにいるんですから。最初の計画が一番重要ですけれども、始まっちゃったら、あとは全部それですよ。

能登原
そうですよね。始まったらもう、どんな問題が勃発するか分からないですから。

中山
それに、プロジェクト進行のためにはその「悪い知らせ」を早く言ってもらわないとだめなんです。リスクをつぶさなきゃいけないから、ネガティブなことを言いやすくするコミュニケーションが大事です。その時に、「相談しても、テクノロジーが分かりそうにないし答えてくれそうにないな」とか、「きっと、おまえが考えるべきだって言われるだけだな」って分かっていると、部下は相談しないじゃないですか。

能登原
ええ、相談できませんよ。

中山
そうすると早期発見できずに問題が先送りになって、最後にボーンと爆発するパターンです。よいプロマネであるためには、キャラクターは厳しい人でも優しい人でもどっちでもいいんです。相談されやすいポイントは課題に対して答えられるかどうか、あるいは決断が出来るかということです。しかもそれが毎日のことですからね。たくさん相談事が持ち込まれて、大きな「悪い話」つまりリスクが大きい部分の相談事もきちんとプロマネのところへ来るかどうか、それが大事だと思いますよ。

能登原
以前はこうやって中山さんともずいぶんモデルやプロマネの話をしましたが、最近は経営の話が多くなってきましたよね。

中山
でもね、僕は最近、経営とかビジネスモデルもIT屋から見た「形のきれいさ」って結構大事だと思うんです。IT屋って、完全にビジネスを裏側から見ているんですよ。だから最近、ISも生意気になってきて(笑)、ユーザーが言うことを聞かないと、「おれたちはビジネスを裏側から見ているんだ」とマネジャ同士でちょっと偉そうに話していたりするんです。だけど、それはおごり高ぶっているのではなくて、本当に裏から見えちゃうんですよ。コンプライアンス問題とかトレーサビリティだとか、システムを作っていたらちゃんとやっているかどうか分かるじゃないですか。

能登原
それは絶対分かりますね。

中山
中身がブラックボックスとかいうのは、怪しいですよね。プロセスの可視化が難しいものには、だいだい何かあったりします。要するに、きちんと真実をシステムに落とすんだという観点から見ると、ISは会社のひとつの要です。自分で経営したり、ものを売りに行ったり作ったりしていないんで、裏は裏なんですけど、最も会社の実情がよく見える立場でもあるんですね。

そういう意味では、解決課題は経営だったりコンプライアンスだったりしますけども、立っている拠り所は、ITだったり、ビジネスモデルやデータベースだったり、あまり変化がないという気はしますね。ただ昔と違って、それが多少市民権を得てきたというか、経営とITがだいぶ近づいてきた感じがします。

(次回に続く)

構成;萩谷美也子

↑ このページの先頭へ