具体的な職歴の概要を、その企業での実体験を交えて紹介しています。

C社時代

システム開発部門に所属し、アセンブラ、コボル、PL/1などのプログラミング言語を使って、金融機関や製造業向けのシステムの設計・開発を経験しました。
某鉄鋼メーカー向けのシステム開発では、3か月くらい土日がない生活を経験しました。朝が白けてくると目がランランと輝いてくる異常な体験は、忘れられません。
ちなみに、“起きている間は全部仕事” だと、月の残業時間が250時間くらいになるようです。椅子を6つ並べて仮眠を取っていても “頼むよ” と、30分も寝てないうちに起こされてしまうのには、正直参りました。

K社時代

電気研究所のコンピュータ・サイエンス チームに所属し、研究員として学際的な研究職に従事しました。画像処理アルゴリズムの研究とか、インタプリタ言語(Java言語の仕組みに近い)の開発とか、知識工学(人工知能の一分野)の研究もしました。

そして、突然、米国の巨大自動車メーカー向けの大型プレスシステムの開発にIT技術者として参画することになりました。受注金額が250億円を越す大仕事で、1台目のシステム用、2台目のシステム用と、納期が次々と来るので、車の中で交代で2時間くらいの仮眠をしてテストを繰り返すというような生活を、1年半くらい過ごしました。

一時期は、妻子を実家に帰して仕事に明け暮れました。でも、真夏の暑いときに、ヘルメットをかぶって、安全靴を履いて、汗だくになりながら工場で過ごした時間は、とても心地良かったです。現場大好き人間です。

E社時代

フイルム関連製品の製造販売が主たる事業の米国企業(NY上場)で、日本にある研究開発センターのコンピュータ・サイエンス研究部に所属し、画像処理システムの設計・開発などに従事しました。 当時は、従業員が16万人いましたが、デジタルカメラの出現で...  (デジタルカメラを発明したのは、この会社の社員です。)

“英語は初めからしゃべれたの? ”  いいえ、全然...
入社面接では、アメリカ人が喋りまくる英語を分かった振りして聞いていました。

でも、黙っているだけだと変なので、事前に準備してきた唯一の質問:  I would like to know the education system. だけで、なんとかパスしました。

入社してからは、ほとんど毎日(真冬の寒いときも)5時半に起きて、ビジネス英語を学習しました。電車の中では、乗るとすぐに(左右からの圧力が均等になる)真ん中に移動して、テープを聞いたり文法書を読みました。その甲斐あって3年後には、TOEICのスコアを300点アップさせることができました。

I see from your resume that you are a golfer. Yes, indeed. I started playing golf when I was in high school. In fact ... 

1987年4月から始まった 『やさしいビジネス英語の』 の出だしです。軽く100回以上聞いたので、覚えてしまいました。これだけで、本が書けそうです。まさに、“継続は力なり” を実践しました。

ニューヨーク州にある本社まで、片道15時間かけて出張して、帰ってきて1週間後にはまたニューヨーク出張するような、いわゆる典型的な外資系企業のビジネスマンでした。

M社時代

半導体製造装置の輸入販売会社で、大手電機メーカー(S社)の子会社だった米国企業の日本法人に、ITマネージャー(IT部門の責任者)として入社しました。入社して数年後に、本社の業績悪化で会社は解散してしまいましたが...

ちなみに、企業経営に関わる業務知識は、この時代に独学で習得しました。入社して直面した ERPに関わる難題 については、粘り強い努力 をお読み下さい。まさか累積赤字で会社を閉鎖してしまうとは、思いもよりませんでした...

P社時代

1000店舗を超えるフランチャイズ・ショップを全国展開しているジャスダック上場の企業で、情報システム部長として、フランチャイズ・システムの骨格である店舗の受発注システム(EOS/POSシステム)の再構築などを手がけました。

ここでは、著名なITコンサルタント会社であるX社との戦いが、忘れられません。

入社してまもなく、創業者である社長から、X社が作成したプレゼン資料と共に、X社の社長とマネジャーに引き合わせられました。X社の資料には、業務分析からシステム構築までの手順の概要がコンパクトに書かれており、よくできていると思ったので、“よくできていますね” と素直な感想を述べました。

それが、2か月に及ぶX社との戦いを引き起こすことになろうとは思いもよりませんでした...

2か月後にわかったことですが、社長としては、この面談で、X社をITコンサル会社として使うかどうかの判断を私に仰いでいたのです。しかし、社長とX社の社長とは、同じ創業社長として交流があり、私としては、社長が使うことを決めており、最初の顔見せ、と思っていたのです。

その結果、関係会社を含む業務システムの再構築の最初のステップとして、X社が業務システム構築のプランを作成することになりました。2か月でX千万円の契約でした。そして、社内の業務分析が始まりました。

私は、彼らが仕事がしやすいように積極的に支援しました。社内の業務分析、関係会社の業務分析、と順調にこなしていくのですが、X社のマネージャーからの報告や連絡や相談が、いつまでたっても全くありません。定期的な会合を持とうともしません。 “なんか変だな…”。

X社のマネジャーと何度か話し合いましたが、誠意ある対応がなく不信感がつのるばかりです。本当につらい日々でした。

そして、2か月が過ぎました。社長とお昼をご一緒することになりました。私は、その場で、X社の3人のITコンサルタントと私の技術レベルを比較して “彼らは必要ない” というメッセージを図で示しました。

社長から “あなたにも半分責任がある” と言われました。そして、X社との契約は2か月で打ち切られました。

上級のITコンサルティング会社は、仕事を受注するときには、常套手段として企業の社長にアプローチするようです。社内のシステム部門は、彼らにとって邪魔な存在なのでしょう。でも、請け負った企業のシステム部門を利用するだけ利用しておいて、あとは徹底して無視するやり方は、明らかにWin/Lose(自分だけが得をして相手には損をさせる) 関係を目指しており、健全なビジネスのやり方とは思えません。

さて、X社の最終プレゼンが終わってから、X社のマネージャーから小声で頼まれました。 “このことは黙っておいてください...” コンペで連戦連勝中のX社の評判に影響するというわけです。反面教師としていい経験になりました。ちなみに、契約金は、相当減額して支払われました。

しばらくして、市場激変の影響で将来が急激に不透明になってしまいました...

そんな時期にヘッドハンティングされたのは、その後の幹部社員の立て続けの退職を知ると間違った選択ではなかったようです。

T社時代

医療器具の製造販売を業とする米国企業(NY上場、従業員8万人)の日本法人の情報システム部長として、入社してすぐに直面した課題(いつものことですが...)は、導入したばかりのERPからの応答速度が異常に遅く、業務処理に支障をきたしていました。

原因の可能性は、3つ考えられました。

1つ目は、ERPを動かしているハードの選定ミス、2つめは、ERPそのものの性能上の問題、3つめは、ユーザーの運用上に原因があること、でした。

1つめのハードの選定ミスは、すぐに分析の対象から除外しました。なぜなら、超一流企業であるI社で、機種選定時に事前のシミュレーションを行っていたからです。

2つ目は、他の顧客で同じERPの稼動状況を調べてみました。しかし、ERPの応答速度が問題になっているユーザーは見つけられませんでした。

3つ目も調べてみましたが、ユーザーの使い方に問題がある可能性は低いと判断しました。

困ったな…
ハードを提供しているI社、ERPを提供しているS社と深夜まで協議しても、解決の見通しが立ちません。その間にも、ユーザーは不便を強いられていました。入金消しこみのデータを入力して、システムから応答が返ってくるまでに45分も待たされているのです。

ある時、I社のエンジニアが、ハードの定期メンテナンスにやってきました。私は、その状況を横で眺めていました。しばらくして、そのエンジニアに、いくつかの質問をしました。そして、確信したのです。ハードの機種選定ミスだと。

まもなく問題は解決しました。応答速度が劇的に短くなったのです。数日後、オフィス内を歩いていたとき、とても困っていた経理部長から “ありがとう” と声をかけていただきました。一人で失敗のリスクを負って解決策を考えだし実行した勇気が報われた瞬間です。

L社時代

自動車部品を製造・販売している米国企業(NY上場、従業員12万人)の日本法人で、ITマネージャーとして、ERPを使った基幹システムの再構築を一通り実体験しました。詳しくは、3度目の失敗を阻止をご覧ください。前任者2人がERPの導入に失敗していたことは、入社時点では知る由もありませんでしたが...

現状の業務フローをビジュアル化して、課題を構造化して、システム化する範囲を決めて、現状の業務プロセスとERPの業務プロセスとの違いを分析(いわゆるフィットギャップ分析)して、など等。

ちなみに、基幹システムを再構築するときは、今までの業務ルールや業務プロセスを、ゼロベースで見直すことになります業務ルールを変えることは、そう簡単なことではありません。

この時も、経理部門と営業部門の責任者の間で意見が異なりました。どっちの意見が正しいのでしょうか... どっちの意見も、それぞれの立場からしてみれば正しく思えました。

再構築プロジェクトを仕切っているリーダー(私)には、現場の業務ルールを変更するような権限はありません。なので、どうしても責任者どうしで話し合って決めてもらう必要があったのです。決まらないとプロジェクトのスケジュールが遅れてしまいます。

困りました... どうしたら、二人を同じテーブルについてもらえるか?

私が取った行動は?
会計の責任者(No.2)に頭を下げてお願いしたのです。このことが、硬直した事態を打開することになりました。

結局、私の役割は、2人に同じテーブルについてもらうところまででした。プロジェクトの推進に支障がでていることがわかっている両人は、率直に話し合って結論を出してもらえました。

2人が同じテーブルについたときの緊張感は、今でも忘れられません。

M社時代

米国の国防総省、エアーバスなどのハイテク産業が顧客の米国企業(NY上場、従業員1万人)のアジア太平洋地区のビジネスシステムの責任者として、7か国(日本、韓国、中国、香港、シンガポール、インド、オーストラリア)に 導入済みのERPシステムの経営への効果的な活用を推進しました。

MRPやCRPなどの生産管理システム向けのERPの仕組みを現場のキーパーソンに指導したり、在庫管理、購買業務など向けのバーコードリーダーの導入も推進しました。顧客データをBIで分析しやすくしたり、顧客をランク付けして販売価格を変えるなど、グローバルにERPを展開している企業での業務改革の難しさも体験しました。

複数の業種でのERPの導入、導入失敗からの復旧、導入後の活用の実体験を通してERPの経営への効果的な活用については、業種やERP製品が異なっても共通して不可欠なノウハウがある。ということに気づくことができました。


尚、起業後のERPの導入指導の実績は、全てのクライアント先と “秘密保持契約書” を結んでいる関係で掲載しておりません。

ERPの専門家として起業するまでの間に 複数のユーザー企業でERPに関わる様々な実体験を経たことが私の強みになっている ことを、ご理解いただけたと思います。