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

HOME > プロマネへの道 > 木村 勝さん(3) 住友化学システムサービス株式会社

2007年5月25日

木村 勝さん(3)
住友化学システムサービス株式会社 技術部 部長

木村 勝さん木村 勝(きむら まさる)さん
住友化学システムサービス株式会社
技術部 部長
1985年、法政大学電気工学科卒。同年4月 沖電気工業(株)に入社。
都銀/地銀の営業店システムの開発に従事。
1991年住化インフォテック(現 住友化学システムサービス(株))に入社。
工場システムの開発/運用に従事。
1996年より住友化学様R/3導入に従事(サプライチェーンを担当)
2001年よりR/3インフラ構築に従事。
2004年より技術部にて、ネットワーク再構築、セキュリティ基準/IT標準の策定などを担当。

東京へ転勤、R/3導入プロジェクトへ

木村勝さん

能登原
新居浜のほうでやられていたのは何年くらいですか。

木村
4年くらいですね。それで「今度、住友化学さんがR/3を入れる」という話になって、それでこっちに来たのです。

能登原
東京ですか、大阪ですか。

木村
その時は、幕張にオフィスがありましたから、幕張に行きました。

能登原
転勤というかたちですか。

木村
そのころは長期出張という制度があって「ちょっと3ヶ月行ってくれ」という感じでした。

能登原
それが、3ヶ月で終わらなかったということですか。

木村
ほんとうに長期の出張になってしまいました(笑)。

能登原
もう、そのころはご結婚されていますよね。

木村
いや、結婚する前です。97年に結婚したので、こちらに来てから1年くらいして結婚しました。

能登原
奥様は地元・愛媛の方ですか。

木村
そうです。

能登原
本当は、ずっと向こうにいるつもりで。

木村
うーん、ちょっと(笑)。

能登原
予定が狂っちゃった(笑)。

木村
向こうの親御さんには悪いことをしたと思います。

能登原
R/3を入れ始めて、だいたいどんな感じでしたか? まだ、あのころは旬というか、出始めじゃないですか。そんなに日本でも事例があったわけではないでしょう?

木村
最初は分からなかったですね。パッケージだというので買って、いろいろやるのですが、操作説明書などはなくて、コンサルさんに聞くのですけど、何でそうなっているのかが、なかなかよく分からない。やはり業務的な知識を持って、「だからこんな処理をやっている」というのでないと理解しづらいですね。その時に、「本当に業務を知らないと駄目」というのがよく分かりました。
でももう、それを使って生産管理、サプライチェーンのシステムをやり始めていたのです。最初、現場にプレゼンしたというか、現場の要求を聞いて一週間後にはもう「こういう形で生産管理ができるのですよ」と見せに行きました。そのとき「ああ、もう一週間でできる世界になっているのだな」と思いました。それまでは作ったり、画面に表示をさせたり、いろいろ苦労をしたというのに、「すでにこういう世の中なんだ…」と、ちょっとびっくりしましたね。

能登原
でも、それが一週間でできて本当によかったですよね。その後もほぼ順調に進んだのですか。

木村
いやあ、とてもとても(笑)。システムを動かすのは難しくないので、一週間でできますけどね。やはり仕事の流れも考えた上で作っていかなければいけないですから。
確か98年の4月から、ある事業部のサプライチェーンを構築するというので、そのプロジェクトに入って、カットオーバーさせたのは1999年12月だったと思います。

能登原
ほぼ1年半ですか。

木村
1年半です。そのサプライチェーンの前に一度、設備管理システム構築にR/3を使いました。そちらは途中で抜けて、サプライチェーンのほうに入ったのです。それをやるのに、あるべき姿の新業務フローを、ユーザの人たちと一緒になって検討し、「これでいきましょう」とオーソライズして、それでシステムを作っていく。まあ、そんなふうにやりまして、品目数も1万いくらかでした。
とにかくR/3というのは作りの問題じゃなくて、R/3をどう動かすかというマスターをどうそろえるかというシステムなので、そちらのほうがかなり大変でした。8月くらいにはカットオーバーの予定だったのですけど、12月くらいになりました。やっぱり中にはアドオンという追加のプログラムを組み込んだりしましたからね。

能登原
でも、とても正しい方向でやられたのですね。要するに、業務フローを書く。それと現状のR/3とのギャップ分析をするのですよね。で、「ここは業務でそのままでは使えないので、この部分をアドオンで作り込みましょう」という手順でやられたのではないでしょうか。非常に正しいやり方でやられているなと思います。

木村
その時は、新しい業務フローをまず作ることにしたのです。システムはあるけれども、「今の業務フローからあるべき業務に変えていくので、その中でシステムをどう使うか」という議論をする。そんな流れでした。システムに最初から入っていくと、ゴールが分からなくなります。そのシステムを使うのだったら、そのシステムの業務フロー、R/3が持っているシナリオ通りにやるというのが目標になってしまう危険がある。その時は、別にあるべき業務フローというのをみんなで作ってそれをやり、使えるところはシステムを使うと、そんなイメージでやりましたね。

能登原
正しいアプローチという気がします。

木村
そうですね。あるべき姿の業務フローを私たちが作ったのではなくて、ユーザーさんが作ったということで、みんなやる気になっていました。ちょうど2000年問題もありましたので。

能登原
2000年が来ては駄目ですよね(笑)。

木村
その前にカットオーバーしなきゃ。

能登原
だから99年12月なのですね。

木村
そうです。それはやらないと駄目なのです。

能登原
「その前に、何がなんでも動かすぞ」みたいな。そういう意味では、せっぱ詰まっていたのですね。

木村
ええ、詰まっていましたね。かなり。

能登原
もう後には戻れないですよね。それではR/3を入れたというのも、2000年問題も関係していたのですか?

木村
それが契機ではないですね。R/3を入れるという話は最初からありました。その中で、もう無駄な投資はしたくないので、2000年問題をどうするかといったときに、システムがあるところは更新するか、それともR/3に置き換えるかということになるわけです。そこを「R/3でいきましょう!」ということですから、背水の陣です。

能登原
それは本当に背水の陣ですね。それに、R/3にしないシステムは全部直さなければいけなかったわけですよね。

木村
そうなんです。

能登原
その時はどういう立場でやられていたのですか。

木村
サプライチェーンの現場のリーダーでやりました。

能登原
そうすると結構プレッシャーも大きかったでしょうね。

木村
大きかったですね。

能登原
絶対、カットオーバーしないといけませんものね。規模的には何十億でしょう?

木村
そこまではいってないです。

能登原
でも、億単位くらいは、絶対かかりますよ(笑)。

木村
まあ、システムを作るという今までのやり方とは全然違う世界だったので、僕も始めてでしたし、お客さんと話の仕方など、すごく勉強になりました。

思った以上にたいへんだったマスター整理

木村勝さん

能登原
それまでも、全部システムは新居浜のほうでやっていたわけですが、仕様を聞いて作って、構成を決めていくというのは、それにやり方は近いのですか?

木村
どちらかと言うと、今まではシステムを作るための要件を聞いていました。でもR/3は、業務をどうしていくかを考えなければならない。ここが、なかなか難しかったです。ユーザーもそんなことをやるのは初めてですしね。ある意味では、向こうにしてみれば、話しやすかったかもしれないですけど。

能登原
業務中心で話ができますからね。

木村
ええ。でもこちらも向こうも,あれほどまでマスターが大変だとは思っていなかったです。

能登原
そんなに大変でしたか。どんな感じだったのですか? 1万件あったとするとマスターの数はもっとすごいですよね。いろいろなマスターがありますから。組織のマスターもあるし、製品も当然ある。

木村
そうです。品目のマスターと品質検査規格関係、部品表そういうマスターが多かったのです。それをR/3に合うように整備していかないといけないのです。

能登原
それでは2000年になる前までは、それを作るのに必死で…

木村
そのへんがね、なかなか(笑)。僕らもそのときが初めてでしたから、今になって思えば、マスターをちゃんと早くやっていてればよかったと思いますけれど、何となくそれまでのシステムの感覚で、「仕組みができたら、あとはマスターをちょっとずつそろえれば動くものじゃないかな」と(笑)。マスターが大変だというのは頭では分かっていたけれど、まだ感覚的にはしっくりきてなかったという状態だったのです。「もうちょっと早めにマスターに取り掛かっていたら楽だったのに」と思います。

能登原
そういうことですか。なるほど。

木村
R/3を使う、つまりマスターを作ることができるということは、要件は全部決まっているということなのです。そこまでに至らなかったのがよくなかった。

能登原
それは要件をどこまで決めればいいかが、はっきりしなかったということですか。

木村
いや、はっきりはしていたのですけれども、遅れたのです。

能登原
ああ、仕様を決めるのが遅れましたか。ユーザーさん側でもなかなか決められなくて。

木村
そのときに実感しましたが、決めてからそれをどう整理していくのかというのも、また一つの計画として考えておく必要があるのですね。整理のための手順や計画は、非常に重要なのです。ここに置いたら、誰が手順で投入して、結果をチェックして、終わったらこっちへ持ってくるという、一連の流れを全部定義した上でやらないと、わけが分からなくなります。それを構築して、本当にやっていくというのが大変ですよ。それが一つのノウハウになっているかな、と思いますけど。

能登原
それは、マスターデータの構成管理なのですか。

木村
そうですね。

能登原
そういうことですか。マスターをこうやって入れて、もし間違えたらまたこうやってという手順。

木村
ええ、お客さんとの間で変更管理をどうしていくかとか。

能登原
プログラムは普通、構成管理で直しますよね。そうではなくて、マスターの入れ替えで変更管理の時に対応するわけですか。

木村
そうです。その投入前に。いろいろ作っている最中の管理です。

能登原
そこが大事なのですね。

木村
一番大事ですね。

能登原
要件が変わってきますものね。

木村
もちろん、ある程度は決まってから作り始めるのですが、一人でマスターを作っているのではなく、いろいろな部署のユーザが作成するので、「ちゃんと直った」、「ここまでは全部直してから次へいく」ということを、ちゃんと定義付けする必要があります。さらに、作りながら片方ではユーザの業務が動いているので、そこでもまた変更も発生するし、そういうのを管理しないといけないのです。

能登原
なるほど。言われてみれば分かるような気がしますが、あまりそういうお話は聞いたことがありませんでした。今日は非常にいいことをお聞きしました。今度私がR/3にかかわることがあったら、ぜひ活用させていただきます。 でも、R/3はその時パッケージでしたが、先ほどおっしゃったように、業務フローをちゃんと作り、きちんと工程は守られていったのでしょう? 当初の計画は一応決まっていて。それはもうきちんとやって。

木村
工程は守られたと思います。延びましたけれど。最後はなだれ込んだ感じでしたね(笑)。

(次回に続く)

構成:萩谷美也子

↑ このページの先頭へ