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

HOME > プロマネへの道 > 塚田 雅一さん(1) 株式会社キリンビジネスシステム

2006年12月14日

塚田 雅一さん(1)
株式会社キリンビジネスシステム 経営企画部

塚田雅一さん塚田 雅一(つかだ まさかず)さん
株式会社キリンビジネスシステム
経営企画部 担当部長
キリンビール株式会社入社後、システム開発部(当時)に配属。
ビール製造計画システムの開発・運用を担当。
RADツール導入においては、開発標準化、運用ルールの整備を担当。
1998年株式会社キリンビジネスシステムに出向。
主にグループ外(外販)のシステム開発プロジェクトに従事。
2003年より経営企画部門を兼務し、プロジェクト品質向上活動、SE教育企画・実施などを担当。

教育学部数学科から情報システムの世界へ

塚田雅一さん

能登原
まず、この対談の趣旨ですが、読者の方々には「IT業界に入ったものの、今後どうやっていこうか」と悩んでいる人も多いと思うんです。そのとき「自分たちはこうやって生きてきたんだよ」ということを、先輩に生で語ってもらうのが一番参考になるのではないかという思いがまずあります。また、対談のゲストには何十年か働いてきた自分を一回振り返って見る機会を持っていただくことになります。私自身もそれをやってみて、それまでの経験が整理され、なかなかよかったということがあるんです。

塚田
過去の対談を見てみますと、いろいろなご経歴を持たれている方のお話がたくさんありました。読むのは楽しかったのですが、すごい方ばかりなので、今日はちょっと緊張しています。

能登原
塚田さんは入社されて、もう何年になられますか?

塚田
16年弱ぐらいにはなりますね。

能登原
それをちょっと振り返ってみようかな、というくらいのお気持ちで気楽にお話しください。いままでのご経験の中でお感じになったことを話していただければ。

塚田
了解しました。

能登原
まず恒例の、なぜIT業界にお入りになったかというところからお聞きしたいのですが。

塚田
私はキリンビールでの採用なんですけども、キリンビールではIT職を特別に採用する枠があるんです。IT部門でITの人材を育成するための要員ということで、普通の営業系や技術系とは別枠であります。もちろん普通にエントリーするかたちもあります。
実は私はIT系の枠で入社した訳ではないんですよ。面接のとき「君の専攻は何ですか」というような話をしているうちに「じゃあ君はシステムだね」って、そんな感じで振り分けられてしまいました。

能登原
学部は理系の学部でいらっしゃるんですね。

塚田
一応理系なんですけど、どうしてもシステムがやりたいといって入ったわけではなかったんですよ。

能登原
ちなみに学部はどちらだったんですか。

塚田
教育学部の数学科です。

能登原
教育学部でいらしたんですか。塚田さんは先生をされていても、それはそれで良い先生になられていたのではないでしょうか。

塚田
いえいえ(笑)。ただ、長い会社での人生を考えたときに、システムは非常に重要だなと最初から考えていました。ですから、面接の時に「できればまず最初に、情報システム開発の仕事をやってみたい。それを基盤にして次の仕事をやっていきたい」という話をしました。「じゃあ、それだったらそこの部門に行ってもらおうかな」という話になりまして。

能登原
事実上、面接のときに進む方向が決まったんですね。数学科でもコンピュータはけっこう使ったりされていたんですか。

塚田
私は使ってなかったんです。だから本当に素人という状況でした。
プログラムを作るとかシステムを設計するといった授業は選択していなかったので、全く初めてと言ってよかったと思います。

能登原
最初に配属になったのはキリンビール本体の情報システム部門ですね。

塚田
そうです。はい。本当に一からでしたが、学生のときからばりばりシステムをやっているという社員はそんなに多くなくて、「ちょっと授業でプログラムをやっていました」という程度だったので、そんなに大きな差はなかったのかなという気もします。

能登原
塚田さんのときは、情報システム部に何人ぐらい配属されたんですか。

塚田
同期では4名です。われわれの世代は毎年だいたいそれぐらいでした。大学院卒である程度システムをやっていた人もいましたが、経験値があまり自分と変わらない人のほうが多かったですね。

能登原
それじゃ、最初はプログラミングから入っていったんですね。そのころはまだ汎用機の時代でしたか?

塚田
そうですね。汎用機全盛というわけではないですけど、まだ開発の中心でした。最初に配属されたときには2ヶ月ぐらいシステム系の研修ということで、外部の研修所にずっと詰めていました。で、そこで一通り基礎からプログラミング技術の研修を受けました。

能登原
情報システム部門だと、会計系だとか工場系だとかいろいろあるんですけど、最初に配属されてやられたというのはどちらのほうの業務になるんですか。

塚田
工場でビールを製造するときの製造計画・生産管理のシステムをちょうど開発していた時期だったので、そのチームに配属されました。

能登原
そうすると、どこかの工場勤務?

塚田
いえ。工場勤務ではないです。システムのテストや導入するときだけ工場に詰めていましたけど、それ以外は本社に勤務していました。

能登原
生産管理にもいろいろあると思うんですけど、キリンさんは全体計画を本社で立てるんでしょうか。工場が何工場もありますよね。工場別に特徴が違うものなんですか。

塚田
生産設備は工場によってまちまちなんです。工場を建設した当時の最新の機種を入れていくかたちになりますので、装置は別々なんですけど、それを使ってどれくらいの量のビールを生産していくかという計画については本社のほうが大きく方針を出します。それに則って私の担当したシステムが「どういう種類のビールを、どれくらいの量で、いつ作りなさい」というような計画を立案します。

白紙の状態でDOAを叩き込まれる

塚田雅一さん

能登原
なるほど。新入社員のとき、いきなり設計段階からそのシステム開発に入られたんですか。

塚田
いえ、いきなり私がやらされたのは、データ分析です(笑)。もともと、今もそうなんですけど、DOAを中心とした開発を強みとしている会社ですから。そのときも配属後すぐに「DOAでいくんだ!」という簡単な研修があって、「じゃあデータを分析してください」って。ちょっと教えてもらっただけでしたから、面食らいましたけど。

能登原
キリンさんにはもともとデータ総研さんが入られていて、データ分析重視で、塚田さんが入られた頃から当たり前の技術としてやられていたんですね。

塚田
はい。私が入社したのは91年ですが、そのときにはもうDOAで開発していくというプロジェクトが何プロジェクトかあがっていました。

能登原
そうですか。そのときはデータ総研さんがTHモデルでモデルを作って、それを設計図として、汎用機のリレーションデータベースに実装ということになるわけですか。

塚田
そうですね。そういうかたちでやってきました。

能登原
やっぱり最初からDOAで入ったほうがいいですよね。変な癖がつかないで。

塚田
そうですね。そういう頭の構造に自分もなってしまっていますんで、処理中心でという考え方は最初からないです。

能登原
それ以前に階層型データベースの考え方とかが入っていて、なかなか変換できずに困っている人がものすごくたくさんいるんですけど、そういう面では出足として非常に世の中の流れにあっていましたね。

塚田
恵まれていたかもしれないですね。

能登原
そうですね。そのときはどういうふうに感じられました?

塚田
そういう理論を教えてもらってからスタートしたわけではなく、「とにかくやるんだ」という状況だったので「まずは手を動かしてやってみる」という感じでしたね。だからその良さが分かってきたってのはかなりあとですよ。それがちゃんと刷り込まれて体に入っていくには時間がかかります。最初は本当に「やるだけ」という感じでした。

能登原
でも、やはり現場の方とか、実際に生産計画を立てる方にヒアリングをされたでしょう。

塚田
ええ、そういうキーマンにプロジェクトに入っていただいていて、画面の設計を一緒にやって、ヒアリングをしながら決めて行きました。

能登原
それをデータ分析して書く。設計書やモデルに落とすというようなことをやられるわけですね。

塚田
そうですね。はい。

能登原
それはプロジェクトとして、だいたい何年ぐらいやられていたんですか。

塚田
私が入ったときはすでに走っていたプロジェクトだったので、本稼動したのがその翌年です。92年ぐらいにもう立ち上がってしまったんですよ。そのまま運用に移行しました。最初は1工場だけ導入して運用してみて、それで不具合とか調整したうえで全国展開を3年ぐらいかけてやりました。私もそれをずっと3年間かけて展開し続けていました。

能登原
それを一通りやると、計画を作って現場でそれがFAのラインに乗って製品ができていくところまでの全部の製造の流れ、つまり計画から出荷までの、一連の流れが頭に入りますね。

塚田
そうですね。だいたい大まかな流れは把握できます。

能登原
データ項目1件1件だって吟味して作られていますもんね。

塚田
はい。それはそうです(笑)。

能登原
その生産計画はビールだけなんですか。

塚田
そうです。その時代はまだビールしか販売していなかったので。生産計画と言っても、いつの時期にどれくらい作るかということしかやっていなくて、基本的には「Aビール、Bビールをいつ、どれくらい作る」という感じでしたから、そんなに難しい話ではなかったです。

能登原
最近はビールも種類が多いし、発泡酒もあるし、だいぶ難しいんでしょうか。

塚田
そうですね。品質管理面では中身、つまり液そのものが違いますし、製法も違いますので、その分複雑になります。ビールではここの工程はあるけど発泡酒ではこの工程は抜くとか、逆に使わなきゃいけない工程とかあるのでたいへんなようですね。

能登原
現場のいわゆるローカルルールもありますよね。

塚田
ありますね。でも、そのときは全国で1つのものを使っていくということで、ローカライズは極力避けるようなかたちで、ローカルルールも吸収できるようなシステムの作りをしていました。

大規模再構築時にRADのツール導入を担当

塚田雅一さん

能登原
そのプロジェクトが終わってからはどうしましたか。

塚田
そこからまたぜんぜん違うことをやって、そのあとは企画系の仕事をしました。
ちょうどそのときRAD(ラピッド・アプリケーション・デベロップメント)という言葉が流行っていて、そのRADを実現するツール導入のプロジェクトに参画をして、導入までやりました。

能登原
一時期キリンビールさんがデータ総研さんと組んでやられたDOA-RADですね。今でも開発プロセスとか方法論も含めたサービスというかたちでやられていますけれども、塚田さんのやられたのは、あの原型になっているんですか。

塚田
その前ですから、それの「走り」みたいなものです。

能登原
それはどういう目的で、どういう経緯でやられたんでしょう。

塚田
ちょうどそのときに、経理と物流の再構築という話がありまして、しかもかなり規模の大きいものでした。再構築するためには、安く早くやらないとなかなか競争に勝てないし、時間をかけているとビジネスの考え方がまた変わってきてしまいます。そのために早く作れるようなツール、しかもDOAをちゃんと踏襲できるようなものはないかというので、プロジェクトが立ち上がって検討してきたという経緯があります。

能登原
その大規模な再構築をする前に、「どうやってやるのが本当にいいのだろう」と検討していたということですね。

塚田
そうですね。着手する1年か2年前くらいから検討をしようという話が出てきました。もともとそういうことを考えている上司や先輩がいたので、その人たちと組んでやりました。

能登原
そのときの再構築はダウンサイジングも含まれていたんですか。

塚田
そのときはまだ汎用機での構築でした。その時代、ちょうどクライアントサーバーが少し出てきていましたが、クライアントサーバーでそれだけ大規模なものが構築できるのか、まだはっきりと分からなかったんです。それはもう汎用機で、という話になっていましたね。

能登原
検討され始めてみてどういう感じだったですか。どういうポイントについて、どういうかたちの進め方で調査し、作っていかれたんですか。

塚田
実はそのプロジェクトも最初からの参画ではなくて、最初の製造計画システムの展開作業が一段落ついたあとに入ったんです。たぶん、DOAの考え方がある程度染みついているものがツールを選定したほうが、より具体的イメージがつけやすくて展開もしやすいのではないかということで選ばれたんだと思います。ポイントは、DOAの考え方がしっかり踏襲できていて、COBOLみたいに何でもかんでも手でコーディングしないといけないツールとは違う新しいツールを探すということで活動していました。

能登原
つまりツールの選定とか、開発の方法論のやり方を決めていくということですか。

塚田
そうです。方法論はツールを決めたあとに「このツールだったらこういう作り方があるよね」というかたちで考えていました。そのときはRADというとスパイラル型の開発が普通という考え方でしたので、ツールを導入したらスパイラルをどういうふうにやっていくかを検討していきました。

能登原
94年とか95年ぐらいですね。私も実はそのころRADという考えに侵されていました。ちょうどジェームス・マーチンがラピッド・アプリケーション・デベロップメントと言い始めたんですよね。弊社も林がその当時のジェームス・マーチン社にいましたから、そのあたりについては詳しいです。
そのとき自分なりにジェームス・マーチンのRADを読んでみると、実施のためのポイントが何点かあるんです。ユーザーを巻き込むとか、もちろんDOAですとか、いろいろな要件を受けて、自分がたまたまPM、プロジェクトリーダーをやってもいいというプロジェクトをRADで一度やりました。そのとき、CASEツールはXupper(クロス・アッパー)、ERwin(アーウィン)、PowerBuilder(パワービルダー)と、3種類使って実現しました。また、開発体制としては、ある業務領域を担当したメンバーが設計から開発まで全部責任をもってやることにしました。それによって、途中の中間ドキュメントがなくて生産性もアップしました。そのときの私のプロジェクトにはRAD的開発手法は効果がありました。今でも思い出すとよかったなと思うんですけど。塚田さんはどういう考え方でやられましたか。

塚田
まさにいま言われた通りのことを全てやった感じですね。当社にはもともとユーザーさんがプロジェクトに入るという文化はありました。まずここは確実に入っていただくということと、やっぱりデータ中心の設計をするということです。それをもとに高速にアプリケーションが作れるツールをしっかりと導入して、上流から下流まできちんとやりきっていく。それを心がけてやったということですね。

能登原
ツールはどういうものを使われたんですか。

塚田
実際にデータを設計するところは、データ総研さんと一緒にやっているのでTHの考え方を使いました。そのあとデータ項目をリポジトリに登録し、そのリポジトリからデータ項目などをサピエンスというCASEツールのリポジトリに自動的にインターフェイスするようにしました。そうすることで、すぐに画面設計に取り掛かれる仕組みを実現しました。

能登原
じゃあ、そういう方法論とかツールの選定をされて、そのあと実際の開発にまわられたんですね。

塚田
いえ、私はそのサピエンスというツールの運用・管理を中心にやっていて、実際に経理とか物流の再構築プロジェクトには入っていませんでした。最初はツールの管理だけでたいへんでしたので。開発メンバー全員が知らない新しいツールが導入されたわけですから、「どういうふうにアプリケーションを作ったらいいのか」とか、「このへんどうなんだ?」というような問い合わせに対応するだけで手一杯な状態でした。

能登原
それは今で言うITアーキテクトの仕事ですね。

塚田
とてもアーキテクトまで行きませんね。「アー」に入るか入らないぐらいの、ほんの一部分だけです(笑)

(次回に続く)

構成:萩谷美也子

↑ このページの先頭へ