「長い付き合いの日本のIT企業はこちらの業務を熟知しているので、曖昧な仕様でも、ドキュメントがなくても、対応してくれる。だがインドのIT企業はユーザーの言いなりにはならず、徹底的に議論しようとする」。近鉄航空配送の牛尾榮治取締役会長は、近鉄エクスプレスのCIO（最高情報責任者）時代に、インドのIT企業にソフト開発をオフショアした経験を通じて、仕様書作りの重要性を再認識したという。

　企業のIT部門はこれまで長い間、IT企業に「おんぶに抱っこ」の状態だった。その結果、業務をシステムに落とし込む力を失ってしまった。「仕様書を書けるIT部門」は全体の4分の1程度とも言われている。ユーザー部門の要求に対し何の疑問も持たず、しかも要件が固まっていないまま開発に着手してしまう。開発後に仕様変更が多発し手戻りが発生したという例は、枚挙に暇がない。

　こうしたなかでも、コスト削減を目的にIT企業にオフショア開発を要求するユーザー企業は増えている。だがコスト削減効果など期待できるはずはない。そもそもの問題を解決していないからだ。日本のITベンダーやITサービス会社がインドのIT企業に開発を発注する理由が、実は彼らの技術力低下にあるということを知っているのだろうか。

　グローバルで物流事業を展開する近鉄エクスプレスも、以前は日本のIT企業にソフト開発を発注することが多かった。しかし数年前、同社はインドのIT企業と直接、オフショア開発に関する契約を交わした。当然ながら同社も、コスト削減を期待しての決定だったのだが、実際にはそれ以上に得たものがあったという。それは、同社のIT部門が「システム化を仕切れる能力」を身に着けたことだ。

　話は約10年前の97年11月にさかのぼる。近鉄エクスプレスは世界規模で使う戦略的なシステムの構築を決断した。99年には全面稼働させる計画だった。ところが、「スパイラル開発で失敗を繰り返し、03年になってもうまく稼働させられなかった。この状態からどうしたら抜け出せるのか、あるいは中止したほうがいいのかということも議論したが、すでに何十億円という投資をしていた」。当時の状況を牛尾氏はこう語る。

　コンサルティング会社に分析を依頼し、再び開発に着手することにした。日米の大手ITベンダーやコンサルティング会社、インドのIT企業から見積もりをとり、グローバルな開発に対応できる体制などを条件に選定に入った。米国のダラスにおいた「システム開発センター」が開発企業向けの窓口となり、日本のIT部門がプロジェクト全体を管理するという体制も敷いた。開発の約半分は海外向け、残り半分が日本向けの機能になるからだ。

　近鉄エクスプレスが選んだのは、インドのウイプロ・テクノロジーズだった。米国のITベンダーはコストが高いし、日本のITベンダーは海外向けの開発経験に乏しく、稼働後の保守コストもかさむとの判断からだ。料金面では米国の10分の1以下、日本の4分の1程度という破格の内容だった。牛尾氏は「受注するためだけに安く提案し、プロジェクトが進むとどんどん高くなるのでは困る」とウイプロに念を押したという。最終的には、当初の提案の2倍弱にまで膨らんだが、日本のITベンダーが提案した料金に比べると半分程度で済んだ。

　ただ、当時の近鉄エクスプレスは、インドのIT企業の実力を深く理解してはいなかった。そこで、インド企業を活用する日本企業にヒアリングしたところ、「スケジュールを守って仕事を進めている、という評価だった。ネガティブな評価は一切なかった。それまでの経緯から、スケジュールをきちんと守るという点には魅力を感じた」（牛尾氏）。

「なぜこの機能が必要なのか」を徹底議論

　だが、すべてがスムーズに運んだわけではない。当初はユーザー側にも「安い開発業者を雇った」という意識があったし、仕様書を固めないまま発注したこともあって、ご多分に漏れず手戻りが発生した。ユーザーが要件を固めていないことは、インド企業側も認識していて、互いに議論する中で問題点が噴出した。インド人から「なぜこの機能が必要なのか分からない」「ここが矛盾している」などと次々に質問され、「答えられなかったこともあった」と近鉄エクスプレスの正俊彦情報システム部課長は振り返る。

　この局面の打開につながったものは、お互いがパートナーであるという意識を持つようになったことと、インド人のブリッジSEを配置したことだった。その結果、「（相手が）組織としてどう動いているのかが分かってきた。技術者1人ひとりのスキルも見えるようになった」（牛尾氏）という。当然のことながら、インドの技術者にも出来る人、出来ない人がいる。「ここはこの人になら任せられるが、あの人には任せないほうがいい」といった判断基準を持つべきなのは、日本でもインドでも当たり前のことだ。

　ダラスに来ていたインド人技術者と、開発手法について3日間も議論をしたことがあったという。こうした議論を重ねていく中で、IT部門はユーザー部門に、要求の内容を確認するようになった。「以前はあったような気がした」「これがあると便利な気がする」といった漠然とした機能、個人最適を求めるための機能があれば、それは意味のないムダな投資になるのだと指摘する。IT部門側から「ここは止めて、こうしたほうがいい」と言える提案力もついてきた。

　正情報システム部課長は「インド企業と付き合ったことで、仕様書が書けるようになった。『なぜこの機能が必要なのか』をユーザー部門と議論するようにもなった」と語る。IT部門の重要な役割を取り戻せたと言っていいのではないか。IT部門の皆さんはぜひ、仕様書作りこそ多くの時間をさくべきだということを思い出してほしいものだ。