能登原
それではそろそろ、現在のセントラル・コンピュータ・サービス(CCS)に移った経緯とそれ以降の出来事について話してもらいましょう。
三河
そうですね。
能登原
前回までの話は直接または間接的に知っている事柄が多かったけれど、そこから先は僕もまったく知らない話になってくるんですよ。
三河
そこからはもう変化の連続なんです。自分が積極的に望んだ変化ではなかったのですが。
大まかに言いますと、まずCCSに出向してしばらくは参画していたプロジェクトを継続していたのですが、それが終了して、「科学技術システム部」と言う、やはりジャパンエナジーでやっていたような制御系をメインでやってきていた部署に移動しました。それが1989年の1月でそれから3ヶ月くらいの間そこで1つか2つくらいのプロジェクトにスタッフとして参画しました。
そして3月の終わりに、当時の事業本部長から、「三河君には4月から営業をやってもらいたいんだけど」という話があったんです。
能登原
そうですか。営業をやってほしいというのは、かなり突然の話だったのかな?
三河
私としてはそうでしたね。ですから、ここでもまた徹底的に抵抗しました(笑)。「いや、僕はものをつくることを楽しみとしてずっとやってきているのに、営業に行くのはいやです」という話をして抵抗したんですけども、「まあ、そうは言わずに…営業は営業でいろいろと学ぶこともあるし、何よりうちの会社にとって、営業にとって三河君みたいな人材が必要なんだ」と説得されました。
プロジェクトリーダになったときとは違って、このとき私は最後まで抵抗したんです。そしたら「まあ、そうはいってもそうしてもらわなきゃ困る」ということで、いわゆる強制発令しかないということになったんです。「そういうことだけは止めて下さい」と、散々お願いしたのですけど、「いや、もう決めたし、その期待に応えてくれると思うから」ということで押し切られてしまいました。ですからある意味、泣く泣く営業に移ったんです。
能登原
そういう事情があったんだ。それで、三河さんはどういうお客さんに営業したんですか?
三河
営業にいたのは4、5、6月の3ヶ月だけなんですが、その間、異動前に所属した部署が開発している幾つかのシステムを担当しました。お客様は2社でいづれも製造業でしたね。
能登原
実際に営業をやってみてどうでした?
三河
今から思うと、本来はお客様の視点に立ってシステム開発が順調に行っているかとか、納品し稼動した後にお客様として次にどういうことを期待しているかとか、CCSのプロジェクト運営に対してお客様から見て不安な点がないかとかをヒアリングしてくることが営業の仕事なんですけど、当時はそれが全然わからなくて…結局、私はその開発をどのように行っているのかとか、その時にどういうテストをしているのかとかっていう、どちらかというと製造側のリーダ的な視点でしかプロジェクトが見られなかったんです。
あまりお客さんのところに足を運ばずに、営業が製造リーダのように振舞うわけですから、製造からはいやがられますよね。「営業がそんなことをしてどうするのよ?あんたお客さんのところに行って、次のテーマとか聞いてきなさいよ!」(笑)みたいな感じでした。そういう状態がだいたい3ヶ月続きました。
能登原
3ヶ月でまた状況が変わるんだ(笑)。
三河
ええ。次に、CCSとしても大きな案件であった流通小売業のお客様からの引き合いに対応することになりました。私の所属は営業部署のままだったんですけども、コンサルタントとしてお客様のところに常駐することになったんです。その案件は、今までお客様の社内に散在しているデータベースを極力統合化、統一化していきたいというプロジェクトで、データベーススペシャリストとしてのIRM(インフォメーション・リソース・マネジメント)とかDOAとかの経験が必要とされていました。
「情報資源管理をもうちょっとちゃんとしましょう」というテーマのもとで立ち上がったプロジェクトなので、社内を探したら、DOAを過去にやっていた者は私とあと何人かしかいなかった。そこで私にご指名が入ったわけです。
能登原
なるほど(笑)
三河
そこで、仕方がないので、3か月担当したお客様に頭を下げに行きました。上司と一緒に「すみません」って。あとから思い返せば、わずか3ヶ月の経験でも私にとってはとても意味のあるものでした。が、お客様にとっては、結局「いったい何だったの、この3ヶ月は…」という感じになってしまいました。
能登原
まあ、そういうこともありますよ。
三河
そこから3年くらいコンサルタントとして、お客様のところに常駐しました。
能登原
3年もいたんですか?
三河
ええ、3年もいました(笑)。最初はいろいろなSIerさんのオフィスで下準備とかをしていた期間もあるんですけど、それも含めてたぶん3年ですね。この期間は初めて社外で仕事をして文化の違いとか作業環境の違いとかで大変なことも多かったのですが、楽しかったです。そのコンサルタントとして支援した会社の、特に情報システムの現場はすごく活気がありましたね。また、外部から来る人間も本当にプロパーと同じように接してくれて、いろいろな配慮もしてくれてありがたかったし、仕事そのものも楽しかったですけど、職場の雰囲気もすごく良かったですね。
能登原
それは気持ちよく仕事ができそうだ。
三河
そう、若手がすごく生き生きとしていて、オープンな感じでした。統合データベースをやっていたんで、「情報システムの三河」というかたちでプロパーの人と、経理部だとか資材部だとか社内のいろいろな部署を回って、それぞれが持っているデータベースを統合するためのヒアリングを一緒にやっていたので、結構、社内の若手に顔見知りができますよね。そうすると「三河さんもどうです?」って、例えば労組青年部のボーリング大会とかに呼んでくれるんです。外部の人間だという分け隔てがまるでなくて「同じ仲間だよね」みたいな感じで。すごく楽しかったです。
で、どうしてもそういう環境に長くいると会社への帰属意識が薄くなるんですよ。CCSの人間なのに、お客さんの会社の人間のような気持ちになってくる。
能登原
それだけ長く常駐して、しかも環境がよくて先方からも評価されると、そうかもしれない。
三河
その頃、ちょうど能登原さんもITIに移りましたし(笑)。
能登原
そう、会社を辞めて移りました。じゃあ、そのころ三河さんもけっこう揺れていたんだね。
三河
その頃から社外活動というかたちでデータモデルの勉強会とかいろいろなコミュニティにも関わっていきましたから、社外に友達が出来たということもあるんです。どうしても気持ちの軸足が社外にあるので、帰属意識が薄れて「何のためにこの会社にいるんだろうな」と。もう、心の中では首の皮一枚がつながっているという感じでした。といったところで、お客様のプロジェクトも一段落ついて、会社から「戻っておいで」と言われて戻ってきたんです。
能登原
それは危ないところでしたね(笑)。でも、管理職としての三河さんがその気持ちを知っているというのは大切かもしれない。
三河
そこからレンタカー会社のシステム作りをやりました。これが久しぶりというか、4年ぶりのプロジェクトリーダです。ただ、このプロジェクトがちょっと変わっていて、立ち上げ時から最後の最終テスト直前までの間のほとんど、CCSプロパーは私一人だったんです。あとのメンバーは全てパートナーさんで。
前のプロジェクトリーダのときは、どちらかというとプロジェクトの方向付けをして、そのためにみんなが仕事しやすい環境をつくって、もちろんその進捗とか、リスクの管理、リスクの監視をしてその都度手を打つという仕事だったんですけど、その時つらかったのは、それもやりながら、CCSとしての品質保証も一人でしなくてはいけないということでした。
テスト仕様書の書き方を教えたり、テスト結果の検証とかをひとりでやっていたのですが、最後は追いつかなくなって、今の部下の一人が最終局面で入ってくれて一緒に品質保証をやりました。それでもそのプロジェクトは苦しみましたね。納期面でも遅れてしまいましたし、いろいろトラブルも出してしまいました。
レンタカー会社のプロジェクトでもパートナーさんとはうまくいっていたんですけど、せっかく会社に戻ったんで、もちろんパートナーさんとも組むことを前提に会社の中でも何人かとチームを組んでプロジェクトをやりたいなと思ったんです。そのプロジェクトが終わる頃に、元いた製造部署に戻り管理職になりまして、そのあといくつかのテーマをやっていくために部の中で何人かの部下を付けてもらいました。「まあ、三河のためにこういうチームをつくってあげよう」ということでつくってもらったんですね。それから今に至っています。
能登原
うちもユーザだということもあるので、ここでDOAとオブジェクト指向を組み合わせた開発標準Coup[ku:](クー)をやろうとした動機や経緯について聞きたいんですが。Coup[ku:]はいつの間にか出来ていたのでびっくりしました。
三河
ありがとうございます。
私が常駐した流通小売業さんのプロジェクトでも開発をDOAでやってほぼ予定通りシステムは出来たんですが、JAVAとかで実装したプログラムの設計があまりエレガントに行っていなかった。次にやったレンタカー会社さんの仕組みもJ2EEののアプリケーションだったんですね。DOAでやってきて、もちろんデータ中心でうまくいくところもあれば、処理に関する部分の設計から実装に落とす時はなかなかエレガントなプログラム仕様というのが出来なくて…
能登原
そうですね、そこが難しい。
三河
拡張性が悪い、保守性が悪いなど、いろんな問題が出てきたんですね。これは何とかしたいなと思って、もう一回開発プロセスとか、メソトロジーを整理したいと思っていたんです。
自分の中ではそのDOAというやり方があって、で、DOAにあと自分たちなりのカスタマイズというか、いろんな新しいアイディアを付け加えて開発プロセスやメソトロジーを持っていたんですけども、それだけだとこれからは通用しそうにないのでいったん整理したいなと思った時に、ちょうど会社からも「生産性の向上というテーマで何かプロセス改善の取り組みをしなさい」という要請があったんです。「そういうことであれば、ちょっと考えているものがあるのでそれをやらせて下さい」というかたちでやったんですけどね。
能登原
それはレンタカー会社のプロジェクトのあとに作ったんですか。
三河
そうです。CCSに帰って来て、管理職になってからです。
管理職になって最初のテーマのうちの一つがそれですね。作っている途中でやっているものが正しいかどうか検証するためにいくつかのプロジェクトで部分的に適用してみました。そのあともずっと適用を何本もしながら改善作業をやっているんですけども。ただ、お客様にお約束した開発プロジェクトを持っていると、改善作業もなかなか進まなくて、タイムリーに開発標準にフィードバックが出来ないんです。
能登原
それは難しいね。やっぱり時間が取れないのかな?
三河
ええ、そのプロジェクトに関わったCoupを知っているメンバ、そのプロジェクトに関わったパートナーさんも含めて、メンバの中の暗黙知としてはもちろんフィードバックされていますけれど、形式知化するための時間がなかなかとれないですから。
それもなるべく効率化するために、改訂作業を「Bugzilla」というバグトラッキングツールでやっているんですね。「ここにはこういう問題があった」とか、いろんなヒントが入っているんですけど、そういうヒント、例えば「この部分の書き方にはこういう曖昧さが残っている」というのを全部Webで履歴参照しながら改訂作業をやっているんです。
2005年の3月くらいまでは結構改訂作業をやっていたんですけど、4月に年度が代わってから作業が止まっているというところです。
能登原
ユーザの立場からは、がんばっていただきたいと思います。
(次回に続く)