顧客のキーパーソンはITベンダーの出身者。手の内をよく知る相手からの鋭い質問攻めに、徹底的に渡り合い、大手2社との競合に粘り勝ちした。
2008年4月19日午後10時過ぎ、日本酒類販売のサーバールームは、新しい基幹業務システムへの切り替え作業を間近に控えた緊張感が漂っていた。構築を請け負った日本オフィス・システム（NOS）の開発営業第一部 部長の光枝義高は、その夜だけで3回目の差し入れを持ち込んでプロジェクトメンバーを鼓舞した。
20日午前4時に新システムが稼働。「お疲れ様！」と、日本酒類販売の情報統括部次長である大西完治はメンバーをねぎらった。
メンバーが集中できるよう、あえて切り替え作業に立ち会うのを控えていた光枝が、稼働の報告を受けたのは20日9時に出勤したときのこと。これまでの努力が報われる思いがしたという。
初訪問で真意を確認
NOSと日本酒類販売との出会いは2005年12月である。連絡したのは大西からだ。NOSが開いたレガシーマイグレーションのセミナーに参加したことがある大西は、「今度、基幹系のレガシーマイグレーションを検討している。御社のソリューションについて詳しく聞きたい」とNOSの担当者に言った。
「危ないかもしれない」。今回の案件を聞いたとき、この案件を受け持つことになった光枝は直感的にこう思った。顧客の口からいきなり「レガシーマイグレーション」という単語が出てきたことに違和感を感じたからだ。
レガシーマイグレーションはメインフレーム上にあるアプリケーション資産をオープンシステムに移植するもの。全面刷新に比べて安価にオープン系にシステムを移行できる。
レガシーマイグレーション自体は手段にすぎない。「業務改革を進めたい」「メインフレームの運用コストを下げたい」など本当の目的は別にあるはずだ。
レガシーマイグレーションが最適解でなかった場合、痛手を受けるのはシステム構築を請け負うソリューションプロバイダ側だ。プロジェクトの途中で「本当の目的はそうじゃなかった」と顧客から仕様変更の通告を受けると、ソリューションプロバイダが手戻りのコストを引き受けることが多い。
過去にこうした事例を見てきた光枝は、課題より先に手段を耳にした商談は慎重を期すことにしていた。最初の訪問では、顧客の本当の目的を見極めることを優先させた。
相手はITベンダー出身
初訪問は2006年1月（表1）。正月明け早々に光枝は日本酒類販売を訪れ、大西と対面した。
光枝は大西にプロジェクトの意図を慎重に聞く。「御社を取り巻く状況はどうですか」「御社が抱える課題は何ですか」「課題を解決するため、なぜレガシーマイグレーションに注目されたのですか」─。より上流の話題についてヒヤリングを重ね、レガシーマイグレーションありきにならないように努めた。
大西の話を聞くうちに、光枝の懸念は杞憂（きゆう）だったことが分かった。よく考えたうえで、レガシーマイグレーションが必要という結論に達していた。
日本酒類販売の最大の目的は、業界の変化にオープンシステムで対応することである。メインフレームのままでは追加開発が困難になる、と判断していた。
オープン化に当たって、会計システムは業界標準のパッケージに置き換えて、業務改革を実行することに決めた。しかし会計以外の基幹業務システムは担当者の負担を考慮し、現行機能を継承することを第一に考えた。その結果顧客は、レガシーマイグレーションにたどり着いたのだ。
レガシーマイグレーションを決断するまでの経緯を聞きながら光枝は大西を「普通のユーザー企業のシステム担当者とは違う」と感じていた。聞くと大西は「ITベンダーでSEや営業を経験したことがある」と答えた。
