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

HOME > プロマネへの道 > 浜田 佳正さん(2) 東芝情報システム株式会社

2008年7月25日

浜田 佳正さん(2)
東芝情報システム株式会社 第二SIソリューション事業部 技術管理部長

浜田 佳正さん浜田 佳正(はまだ よしまさ)さん
東芝情報システム株式会社
第二SIソリューション事業部
技術管理部長
1981年、青山学院大学経営学部卒業。同年4月東芝情報システム(株)に入社、分散処理コンピュータのビフォアSE、システム開発作業に従事。
1992年に、(株)東芝と協働で、C/S方式に切り替える顧客向けにDOAによる要件分析を開始。1999年よりISO9001、CMMに基づいた品質・生産性向上活動に従事。
2003年より現在まで、事業部の人材育成・技術管理を担当。

before SEという仕事の中身

浜田 佳正さん

能登原
そのbefore SEは、どのくらいやられたのですか。

浜田
before SE自体をやっていたのは6年くらいです。

能登原
けっこう長くやられていたのですね。

浜田
ええ。最初は、提案の手伝いのようなところから始まって、だんだん自分で提案をするようになりました。提案したあと受注できたら、今度は実際にシステムを作る人がいて、そこで出来上がったものを最終的に納品します。納品したあと、そのシステムが使われて、次の受注に結びつきます。
それがbefore SEの仕事です。

能登原
そこまでが、before SEの仕事なのですね。

浜田
営業がやるべきこと、という感じがするかもしれませんが。

能登原
営業さんとの切り分けはどういうふうになっているのですか。何か違いがあるのでしょうか。

浜田
あまりなかったですね。

能登原
では、before SEの方と営業さんが一体で動くわけですね。

浜田
一緒にお客さまに行って、技術的な話は全部われわれが伺い、それを実装したりテストしたりします。当時は、今みたいにきれいに要件が決まっているということはあまりありませんでした。

能登原
そうでしたね。

浜田
ですから、システムが立ち上がったあとで、修正がたくさん出てくるわけです。
私は当初、プログラムを作るのが得意ではなかったのですが、before SEをやっているうちに、知らない間にできるようになっていました(笑)。

能登原
客先で急遽プログラムを修正したり、新規に作らないといけないことが多かったのですね。

浜田
お客さまに「こんなの追加して」と言われて、最初は人が作ったものを直していたのですが、そのうち見よう見まねで、自分で作り始めました。結局それを、お客さまが使えるようにしなければいけなくなったわけです。

能登原
つまり、稼働フォローでいろいろバグが出てきたり、何かあったら、before SEであっても、すぐにぱっと直して、システムを入れて、テストを簡単にして、「さあ明日から導入だ!」といった作業もやられていたということですね。

浜田
そうですね。規模にもよりますが、小さなシステムはやはりそんな感じでしたね。

能登原
ああ、なるほど。

浜田
大きなシステムになると、下手に触ってしまうと、分からなくなってしまいますから、それはできませんでした。実際に自分が何とか分かる範囲の規模だったらやっていました。

能登原
本気でそれをやると、実力がつきますね。直す方が難しいですから。

浜田
ええ、難しいですよね。

能登原
変に直してしまったらまずいことになりますからね。だいたい全体のことが分かっていて、「ここを直したら影響なく動く」と分からないといけない。そうでないと直すことができません。

浜田
そうですね。最初にその直しを入れたのが、パッケージでした。給与とか経理とか。大学でそういうことをやっていたので、その中身の仕組みとか計算をどうするとか、「こうやったらこれが出てくる」というのはだいたい分かっていたので、あとはプログラムの中がどうできているかですよね。
お客さまに、例えば、「こんなのを追加してよ」とか、「ここをこうしないと、できないよ」といわれた場合、パッケージだからパラメータを適当に入れると動きますが、そうではないところをお客さまに要求されたのです。そのあたりを最初に触っていました。
今そんな話をすると、怒られそうですけれどね。パッケージの中身をいじるなんて。

能登原
そうですね。でも、どうしても何とかしないといけないときには、それもやらざるを得なかったですね。

浜田
ええ。

能登原
見よう見まねでも、修正のポイントが分かるというのは、相当実力があるということですよ。

浜田
もう、お客さまと一体になってやっていました。例えば、「この帳票のここの数字をこうしたいから、直して」と言われると、とりあえずやってみるのですね。やってみて、自分で「できた」と思うと、それをお客さまに「こうなりました」と見せます。お客さまは、それに対して「んー、ちょっと違うね。ここは、こうなんだよ」と、また言ってくる。それを何回も何回もやり取りして繰り返していくうちに「OK」になるのです。

能登原
それでは、before SEをやりながら、お客さまの役に立とうと努力していく過程で、少しずつプログラミングの実力も磨いていかれたのですね。

浜田
はい。

「顧客志向」の本当の意味とは

能登原伸二

能登原
そういったbefore SEの経験がある人とない人では、お客さまのニーズに対する感度というのが、全然違いますよね。やはりそういう経験をされると、お客さまのニーズが大切だということへの理解の度合いが違うのではないでしょうか。

浜田
before SEとして、プログラミングや設計をしている技術者の人たちと話をするときの話題に「顧客志向」という言葉が出てくるようになったのですが、話をしていて顧客志向という言葉の意味の違いを感じました。技術者の人たちは、要件とか仕様とか、お客さまが要求しているものに対応することを顧客志向と呼んでいるような気がして、「それはちょっとそれは違うぞ」とそのときに考えました。

能登原
そのとき、濵田さんの考えられていた顧客志向とはどういうものだったのでしょうか。

浜田
顧客志向というのは、単にお客さまの言うことを聞くことではないと思っていました。
例えば、お客さまの要求を聞いて、「そのままやったらこうなりますよ」というところまで、お客さまにきちんと提示することですね。その時点では、自社の業績にマイナスになる部分があったとしても、お客さまのために言ってあげないといけない。長い目で見れば顧客満足度の向上につながる。そういうところまで考えるべきなのではないかと思っていました。

能登原
なるほど。

浜田
その当時、「お客さまに言われたから変更しちゃいました」という話を、よく聞いていた記憶があります。

能登原
そうですね。何も考えずに作って、お客さまに言われたまま直して、また言われたら、先ほどの直しと矛盾するけれども、また直して、という話も聞きました。そういう無駄な直しもよくありましたね。

浜田
ええ。ただ、お客さまのいうことを聞いていればよいのだということになると、例えば、お客さまの要求をどんどん積み上げて「要求がこんなになってしまいました」ということになります。そのまま見積もりを作ってお客さまに持っていって、それで受注できなかったとか、受注できても無駄なものを作ってしまったとか。そういうことも起きてしまうと思うのです。

能登原
ああ、そうかもしれませんね。

浜田
お客さまの予算がこれだけであるというのは、当然、営業が聞いてきます。その中で、お客さまは「これをやりたい」と言っても、「それよりも、こうしたほうがいいですよ」という提案まですべきだと思います。

能登原
本当にそう思います。それを考えるということが大切ですよね。

浜田
ええ。

能登原
何かこう、お客さまの要求に対し、反射的というか反応的にプログラムを修正しててしまうところがIT業界のエンジニアの習性としてあります。自分自身でも、あまりに忙しかったりすると、思わず反応しただけになっていたことはありますよ。ちゃんと考えないとダメですね。

浜田
本当ですよね。

能登原
そこから一歩進んで、「自分だったらこうするし、これをやるのが本来あるべき姿だ」と考えるかどうかですよね。

大規模プロジェクト全体を一通り経験

浜田 佳正さん

能登原
before SEのあと、システム開発の現場に異動されたのですね。

浜田
それはある大きなプロジェクトがきっかけです。それまでに経験したプロジェクトは、それほど大きなサイズではなく、例えば、ある工場の工程管理であるとかそのくらいの大きさでした。しかし、そのプロジェクトは会社の輸出入全般を管理する業務で、要件分析から弊社が行う、かなり大規模なシステムでした。
それまで私がやってきたのはbefore SEですから、「要件分析と基本設計の入り口までは、責任持ってやります」ということで、まずサブリーダーでプロジェクトに入りました。
お客さまと打ち合わせしながら要件をまとめていくのですが、今の要件分析のようにはきれいにまとめられませんでした。当時のやり方で、お客さまのお話をうかがいながら画面のレイアウトを作り、関連するビジネスルールを書き出す方法で仕様をずんずん積み上げていきます。それを要件分析の期間内でやって、基本設計をやる方に渡して、私はまた次のプロジェクトに移るということになっていたのですが、それがずるずる納品、本稼動までいることになりました。結局プロジェクトが終了するまでに2年近くかかりました。

能登原
それはお客さまが離さなかったのですか、メンバが離さなかったのですか。

浜田
すごくいいお客さまでした。システムが大きくなると、スケジュールどおりにいかないことが多いですよね。そのシステムも徐々に遅れて行きました。

能登原
ええ、ちょっとずつ、ちょっとずつ遅れていくことがありますね(笑)。

浜田
お客さまのメンバーのなかに、個性の強いお客さま方がいらっしゃって、そのお客さまと私は気が合うのかよく話ができたので、トラブルについても、いつも私が話をお聞きしながら対応することになったのです。

能登原
顧客対応、顧客マネジメント対応要員だったのですね。

浜田
今で言うと、そうなりますね。当時はそういう意識はなかったですが。

能登原
顧客マネジメントは非常に重要です。ある人がお客さまに対応すると上手くいくけれど、ある人が対応すると喧嘩して帰って来てしまうということはありますから。そこはやはり、人に依存しています。

浜田
そういうわけで、最初は要件分析をしていたのですが、そのうちにそれをベースに設計も手伝うようになりました。さすがにプログラミングはやりませんでしたが、テスト仕様を書いたりテストしたり。

能登原
そのとき初めて、大規模なプロジェクトマネジメントの一翼を担ってやられたのですね。

浜田
システムという意味では、そのときが最初かもしれないですね。

能登原
入社して、6年目とか7年目くらいですか。

浜田
そうですね。7年目くらいです。

能登原
ちょうど皆さんがある程度経験を積んできて、リーダを経験するタイミングですね。
私は学部卒なので22歳で会社に入って、30歳くらいのときに、本格的にプロジェクトマネジメントを主体的に実施し始めたような気がします。

浜田
そのときのプロジェクトで全体の工程を経験してみて、今まで自分がやっていた、要求や要件を聞くというところが、一番楽しくて、そのあと、会社に持ち帰って工場で設計開発を実施することは、自分にはあまり合っていないということに気がつきました。

能登原
全工程を経験してみたからこそ、自分の適性に気づいたということですね。

浜田
そうですね。

能登原
要件どおりにシステムが開発されているかどうか、また、品質確保のためのテストについては、どのように考えられていましたか。

浜田
今は品質確保のためにテストの重要性がすごく言われています。しかし当時、テスト工程は、「遅れている時間を、そこでつじつまあわせの調整ができる」と考えていたのではないでしょうか。プロジェクトを開始するときに、テスト計画を作っておくというのが、本来のやり方ですが、当時は、テストの直前にテスト仕様書を書くというのが多かったと思います。

能登原
なるほど。実は当時、私は発注側の担当だったこともあり、人が作ったシステムをテストして、上手く動かないところを見つけて、上手く動作するように指摘するのが好きだったのです。
ベンダー側の人は、ものづくりをしたら終わりなのですが、発注側は結局、ユーザ部門に「いつまでにカットオーバーします」と約束しているので、最後の追い込みでテストして、とにかく動かさないといけない立場です。テストの段階で頑張って、どんどん見つけて、どんどん直さないと、間に合わなくなるじゃないですか。そこに責任も感じていたのです。

浜田
当時としては、なかなかいなかったタイプですね。

能登原
みんなやはり、作るほうが好きでしたね。

浜田
ええ、作るほうが好きでした。

能登原
濵田さんと同じで、上流設計は私も好きですよ。

浜田
上流って、あやふやでモコモコという感じがしますよね。あれがいいですね。

能登原
そうそう、それをだんだんかたちにしていくところがいいのですよね。何もないところから、何かを作り出していく感じがして。

浜田
そうですね。それがいいですね。

能登原
今お話ししていると、そのプロジェクトを途中で抜けずに、最後までやり切ったということが、経験としてはよかったようですね。

浜田
ええ、いい経験をしたと思います。

能登原
一回、システム開発の全工程を経験すれば、だいたいやり方は同じですからね。

浜田
やはり全体を知らないと、つらい部分がありますよね。

能登原
例えば、移行の大変さも分からないですね。そのプロジェクトの時には、移行はなかったのかもしれませんが。

浜田
少しだけ、あったかもしれません。大規模なシステムからの移行ではなくて、何か小さなシステムは作っていたような記憶はあります。移行は一番大変ですよね。
移行を経験したプロジェクトマネジャーやPMOのメンバーに聞くと、やっぱり移行が一番大変だと言います。移行だけのプロジェクトというのもありますし。

能登原
ありますね。で、われわれも推奨しているのが、昔の汎用機の階層型データベースから、DOAできれいにリレーション型のデータベースに移行することなのですが、そのときはものすごく大変です。コードも全部換えないといけない。その大変さは、やっぱり経験しないと分からないですよ。

浜田
そうですね。全然違うものへの移行ですからね。

(次回に続く)

構成:萩谷美也子

↑ このページの先頭へ