(株)NTTデータシステムズ　 ネットワークソリューション事業部 eソリューション部課長　 梅田　修士氏 Profile 梅田　修士（うめだ　しゅうじ） 1987年某メーカー系会社に入社。某研究所において、衛星の地上系制御システムの開発に従事。1992 年に東京NTT データ通信システムズ(現・NTT データシステムズ)に入社。システムの方式設計をメインにプレイングマネジメントを実行。現在はWeb 型SI のマネジメントを行っている。

梅田　弊社（NTTデータシステムズ）は、NTTデータグループの一員として、主にミドルマーケットを中心としたSI事業を展開しています。設立は1985年ですが、本格的にSI事業を開始しましたのは1992年、前身の東京NTTデータ通信システムズになってからです。昨年、現在のNTTデータシステムズに社名変更しました。社員数は約500名で、そのほとんどが20代〜 30代前半で構成される若さあふれる元気な会社です。
　弊社は、いち早くオープンシステム環境でクライアントサーバ（C/S）型システムの開発に取り組み、データベーステクノロジー、インターネットテクノロジー等の最先端のITスキルを蓄積してきました。現在、大きく分けて個別S I サービス、ERPパッケージ“SCAW”を活用した基幹業務システム開発、パッケージインテグレーションサービス、プロダクツサービス／アウトソーシングサービスの４つの柱を基軸として、法人分野、公共分野、金融分野のいずれの分野においてもソリューション展開しています。中心はミドルマーケットですが、この枠を超える業界を代表するトップ企業に対しても、私どものソリューションを提供しています。

図1 NTTデータシステムズの主なソリューション

―その中で、梅田さんのお仕事、主要ミッションは。

梅田　私が所属するネットワークソリューション事業部eソリューション部は、個別SIのうち、特にWeb型SI に特化したビジネスを行っています。Web型SIのソリューションとしては、ワークフローやアクセスセキュリティなどの基本モジュールをはじめ各種業務パッケージを備えたミドルウェアである“intramart”を活用する場合と、Webアプリケーション・サーバの“WebLogic”等を活用して一から手作りで開発する場合の２つがあり、私は、主にWebLogicによる開発のマネジメントを担当しています。

― Web 型SI が増加傾向にあるのは間違いないと思いますが、特に企業のミッションクリティカルな基幹業務系システムのWeb 化というニーズは増えているのですか。

梅田　トレンドとして、企業の大小を問わず、Web型システムでビジネス形態を変革することがIT 投資の主流となっていることは間違いありません。特に最近は、基幹業務系のWeb型SI に関する引き合いが非常に増えていますね。私自身、コンシューマーサイトからミッションクリティカルな基幹業務系システムまで、業種・業態を選ばずの何でも屋です。

文学部出身にも関わらず、3カ月の新人研修の後、いきなり開発の現場へ

―プロジェクトマネジャーになる前にどのようなお仕事をされてこられたのか、バックグラウンドをお聞かせください。

梅田　私は、1992年秋に当時の東京データ通信システムズに某メーカー系会社から転職してきました。当時は、いわゆるビジネスアプリケーションをクライアントサーバ環境で構築することが注目されはじめた頃で、オープン系技術スキルを持ったSEが必要とされていました。そのような理由で採用され、主としてC/S型システムの方式設計、つまりC/S型システムで高パフォーマンスを実現するためのシステムのプラットフォームの設計に関する仕事を行っていました。

―メーカー系の会社でどんなお仕事をされていたのですか。

梅田　入社して、３カ月間の新人研修を終えると同時に、まったくビジネスアプリケーションとは関係のない、制御系システムの開発現場に配属されました。実は私は、文系出身で、ソフトウェアのなんたるかも分からないままに、某研究所において衛星から送られてくるデータの解析処理など、地上系のデータ処理システムを開発する現場に送り込まれたわけです。当時は、プログラムばかり書かされていました。

―まさにOJTですね。相当なご苦労があったのではないですか。

梅田　「とにかくやりなさい」という世界ですね。正直、分からないことばかりで、苦労なのか何なのか分からないままに、とにかくやらなければということで必死で勉強しプログラムを書いていました。開発言語は科学技術計算用のFORTRANがメインで、後半はCを使うようになりました。特異なお客様だけに、先進的な技術を採り入れたりとか、最新のハードウェアを導入されたりとかしましたので、最新テクノロジーに携わるというチャンスはかなりありました。また、衛星という非常にクリティカルなシステムに関して、厳格な進捗管理のもとで仕事を進めるといったことを含め、当時の経験が、その後のビジネスアプリケーションの開発に生かせていると思っています。

印象・影響・成長の3 つの観点であげられる2 つのプロジェクト案件

―これまでいろんな開発プロジェクトに携わってこられた思いますが、印象に残っているプロジェクトとしてどのようなものがありますか。

梅田　私にとって印象深いとか、影響を受けたりとか、それを契機に成長することができたという意味で、２つのプロジェクトがあげられます。１つ目は、某広告代理店会社様のC/S型基幹業務システムの開発で、２つ目は某情報提供サービス会社様のWeb型基幹業務システムの開発です。この２つのプロジェクトは、私のその後の仕事に多大な影響を及ぼしました。まさに、私はこの２つの開発プロジェクトによって、育てられたといっても過言ではありません。

―ご苦労された点とか、挑戦しがいのあった点をおきかせください。

梅田　１つ目のプロジェクトは、入社して初めて携わった仕事でした。当時、技術的に参考になるような資料も少なく、トライ＆エラーの連続でした。しかし、そこでの苦労が後々のノウハウになっていることは事実です。例えば、あるパッケージプロダクトについては、市場出荷前のバージョンで検証確認を行っていました。また、あるネットワーク機器に関しても、まだ日本では市場に出荷されていない製品を検証したりしました。そういった交流によって、ベンダーの方々とお互いに情報共有の仕組みが形成できたりとか、ノウハウだけではなくていろんな意味で有形無形のメリットが得られたと考えています。

―どの位の開発期間でしたか。

梅田　約２年間で、1994年にカットオーバーしました。十分な開発期間をとらせていただきましたので、オンスケジュールで構築できました。このお客様とは、その後も継続的に仕事をさせていただき、顧客視点の重要性、IT 投資効果など、それまでのシステム方式を中心にした考えから、プロジェクトマネジャーとして必要なものは何かを勉強させていただきました。その後の10年間に私は何をすべきかを考えさせてくれたという意味で、私にとっては非常にラッキーなプロジェクトであったといえます。

―２つ目のプロジェクトに関しては、どのような点があげられますか。

梅田　開発に要した期間は、最初のシステム企画の段階から含め約１年７カ月で、2002年５月にカットオーバーしました。それまで携わったシステムの中で、規模という観点で一番大規模なシステムであり、重要性・クリティカル度の高さという点でも比類なきものでした。そのハードルの高さ故に、お客様と開発側が意識を合わせて共通ゴールに向かって協調して進めていく必要がありました。双方が情熱をもって進めていけたので、成功したと考えています。特に、お客様が何がマスト（must）かを十分にご理解されており、逆に開発者側の私たちがそこを理解することによって、お互いが良いシステムを作っていきましょうということで、何度も夜を徹して議論したものです。

―Webベースのシステムですね。

梅田　そのお客様のコアコンピタンスとなる基幹業務システムです。お客様だけではなく、そのパートナー様も使用します。サーバ・サイドはWebベースで、クライアントサイドJavaも使っています。これは、Swingを用いています。特に工夫を凝らしたのは、開発環境と違って本番環境はクライアントがリソースの少ない端末でしたから、クライアントJavaの起動に要する時間をいかに短縮するかという点でした。本当に、最初は使いものにならないくらい遅かったですね。

―チューニングされたのですか。

梅田　クライアントがいろんなサービスの端末でもあったため、レジストリーを変更することさえ許されませんでしたので、かなりアプリケーションのソースレベルのチューニングを施しましたが、非常に難しかったですね。とにかく、いかにクライアントのリソースを使わないようにするかとか、データのやりとりを少なくするかとか、DBアクセスを少なくするかとか、地道なステップの積み重ねで、本当にミリ秒・ナノ秒の時間短縮を積み上げていくことによって、最終的にパフォーマンスは画期的に改善されました。革新的な目新しい技術ということではなく、愚直な方法を積み重ねるということしかできなかったですね。

プロジェクトマネジャーとして、常に意識している12項

―難しいお仕事ばかりご担当されてこられたようですが、これまで失敗されたご経験は。

梅田　今までは、割と敬遠されがちなプロジェクト案件をたまたま担当させていただいたケースが多かったように思います。目的・やるべきことが明確で、とにかくその実現に向けて走るだけですので、本人にとっては言われるほど大変だとは思ってはいませんね。失敗という面では、事前に回避することができたと思われるトラブルが後から発生したという経験はありますが、納期に遅れたり、品質面での決定的な失敗は、これまで一度もありません。

―プロジェクトマネジャーを目指す方々に、プロジェクトを成功に導くための秘訣というか、どのような点に留意したら良いかの提言をお願い致します。

梅田　まだまだ若輩の身ですから、提言などというおこがましいことは言えませんが、経験を踏まえて私が常に意識している事項として、仕事を回していくプロセスと、開発メンバーのマネジメントの両面で、次のような点があげられます。

＜プロセスマネジメント＞

(1)「思い立ったが吉日」ではない。
　即、行動といわれるところもありますが、影響範囲を意識しないと手戻りが多く、かえってアダになってしまいます。私は、深呼吸して３秒間考えてから行動する「３秒ルール」をメンバーに徹底しています。

(2)継続は力なり。中途半端にしない。
　一度決めたことは、愚直に継続することが重要で、ころころ方向・方針を変えないことです。

(3)答えがないものは、課題にしない。
　これは、若いマネジャーさんがよく陥りやすい点ですが、現実と理想のギャップが課題になりますが、答えがないものを課題にしてもストレスとなるだけです。

(4)“FACT IS FACT”真実を多角的に追求する。

(5)PDCA（Plan Do Check Action）は当たり前というクセをつける。

(6)正しい評論家は必要、エセ評論家は徹底的に排除する。
　特に、リーダーに成り立ての人はいろんな方々から意見を聞いたりすると思いますが、正しく見極めることが重要です。

(7)目的と手段を見極める。
　システムを使用して何か効果が出ることが目的であるのに、いつの間にかシステム開発が目的になってしまい、変な状況に陥ることになります。

―例えば、具体的な例としてどのようなケースがあげられますか。

梅田　仕様変更に対する対応があげられます。システム開発が目的になってしまうと、費用・期間・品質の面で、仕様変更はできませんということになってしまいます。これはある意味正しいと思うのですが、顧客視点に立った場合に業務を遂行する上で不可欠な仕様変更は、行わなければならないことです。重要なのは最終的なゴール、目的がどこにあるのかでということです。

＜ヒューマンマネジメント＞

(8)理解と納得のバランスを意識。
　メンバーと話をすると“Yes, But”の答えが返ってくることがあります。そんな場合は、どこか納得していない部分があるということですので、徹底的に会話をすることが重要です。

(9)話を聞き、その場で否定はしない。
　その場で答えをだすのではなく、話を聞くことが大事です。些細なことでもメンバーにとっては重要です。解決が目的ではなく、とにかくコミュニケーションを図り、そこから内在している問題が何かを探り出すことが目的です。私は、席に座っていることは希で、いつも動物園の熊のようにメンバーの後ろをグルグル回って声をかけたり、かけられたりしています。

(10)過度に頑張らせない。無理は禁物。
　これは、賛否両論あるかと思いますが、高過ぎるハードルは品質を劣化させ、スケジュール遅れを発生させる原因です。少し上の目標を設定し、その目標達成を繰り返し積み上げていくことで、最終的に頑張ったと同じレベルまでもっていくことが重要です。

(11)考えさせる（敢えて失敗させる）。
　言われるとおり実行するだけでは、成長しません。自分で考えたことは力になります。考えさせるシチュエーションを作ることが重要です。

(12)情報は等しく公開する。
　「私は知らない」という孤立感を排除するためにも、情報はメンバー全員に等しく公開することが重要です。

マネジメントプロセスのナレッジを若い社員に展開し、No.1SIerを目指す

―最後に、ご自身の今後のビジョン、将来の夢をお聞かせください。

梅田　まだまだビジョンや夢を語るほどのレベルにはいたっておりません。マネジメントプロセスに改善点はないか、仮説・検証を繰り返していかなければと考えております。そして、そのナレッジが若い社員に展開できればと思います。その結果、(優等生的な発言ですが)弊社がミドルマーケットにおけるリーディングSIerに成長できればと思っています。

―本日は有り難うございました。

（聞き手・構成　編集長　河西義人）