グローバル・プロジェクトの実務ノウハウ

五嶋仁

高木右近日向

前回は、海外ベンダーと上手に付き合う方法について取り上げました。今回は、海外ベンダーへの発注時の注意点を見ていきます。

海外には、なかなかバグを認めないベンダーも

日本でもソースコードレビュー（ウォークスルー）を実施する会社が減っているようですが、製造工程の早期にこれを実施することで、プログラマの癖や標準への適合状況などが分かるため、ソースコードレビューがプログラムの品質を向上するのに役立つことは変わりません。

ですが、海外にはこういう文化がない、あるいはソースコードレビューで指摘されたバグを認めないベンダーもあるというのは知っておいていいでしょう。

あるプロジェクトのカスタマイズ開発を、海外の会社にお願いしたときの話です。ソースコードレビューを実施したところ、明らかなバグがあったので指摘したのですが認めてくれず、エビデンスを出せと言われたことがあります。

仕方なく、バグが発生するテストデータを作成し、テストレポートを出したところ、ようやく納得してくれました。

この会社だけでなく、他にも同様のベンダーが存在すると聞いたことがあります。

どういうレビューを実施し、そのレビューで発覚した欠陥について誰がどのように対応するかを契約段階で明記しておくに越したことはありません（国内であれば契約後でも、「プロジェクト計画書」に明記して調整すれば問題ないことなのですが）。

ただし、同じ会社でもブリッジSE（海外ベンダーとの間に入って、さまざまな調整をしてくれるエンジニア）がしっかりしているときは、ソースコードレビューで見つけたバグに対応してくれたので、結局はしっかりした体制を作ることが重要です。

画面設計等をシンプルにして誤認防止を図る手も

Oracle EBS（e-Business Suite、オラクル※・コーポレーション製　基幹業務向け汎用統合パッケージ）を含む海外のアプリケーションを見ていると、画面設計ではタブによる画面切り替えをうまく使い、1つの画面の処理内容がシンプルに整理されています。これはメンテナンス性を確保することもありますが、いきなり複雑な画面を設計すると、仕様が間違って伝わることで手戻りが発生するという考えがあるのでしょう。難しいものを時間をかけて作っていると機会損失する、という考えもあるかもしれません。
※Oracle EBSは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。

私たちが開発を支援している業務アプリケーションでも同様で、海外の開発ベンダーはシンプルな画面を要望する傾向があります。そのほうが間違いなく作れて、手戻りが少ないからでしょう。

実際、日本の業務アプリケーションによくあるような、職人芸的な操作性の画面設計をすると、海外ベンダーの開発者には仕様自体がよく理解できないと言われてしまいます。

まとめると、海外ベンダーに開発を発注する際には、一目瞭然で仕様伝達の際に間違いがないシンプルな画面設計を心がけることが成功の秘訣だといえます。

画面そのものがシンプルなだけではなく、実現する内容も誤解なくシンプルに伝えるようにしましょう。その場合、日本語だとどうしても曖昧、あるいは抽象的になりがちです。我々日本人が論理的に書いているつもりでも、外国人から見ると実装者の裁量に委ねる「情緒的」な指定の仕方に見えるようなのです。

したがって、最初から英語で、しかも箇条書きで簡潔に書くようにすることがコツです。

<<[第16回]を読む  [第18回]を読む>>

サービス・ソリューションに関するお問い合わせ