必読3つの当たり前 〜オフショア開発とご近所付き合い〜：山浦恒央の“くみこみ”な話（62）（2/3 ページ）

　ここからは前ページで取り上げた「当たり前の味」「メニューの写真」「テーブルマナー」について、ソフトウェア開発と関連付けて考えてみましょう。

オフショア開発の「当たり前の味」

　本シリーズの第1回「日本と外国との“文化の違い”を“数値”で把握」で、それぞれの国の文化の違いを数値化したホフステッドの多次元理論を紹介しました。これはレストランの味付けのようなもので、国によって料理の味付けが違います。それを文化的な背景と結び付けたのがこの理論です。

　日本人は特に「不確実性の回避」の数値が格段に高く、他国のソフトウェアエンジニアから、「日本人は、必要以上に品質にうるさい」といわれます。これは両者の品質基準が違うことを表しており、多数のエンジニアの悩みの種になっているようです。

　日本では当たり前なので、つい自社の品質基準を押し付けがちですが、相手側が初めから日本的な品質制御を理解することは容易ではありません。相手にも面子やプライドがあります。日本人は、じっくり腰を据えて少しずつ相手に理解してもらいましょう。プロジェクトを2、3回繰り返すと、徐々に相手も分かってくれます。

オフショア開発の「メニューの写真」

　第2回「行間を読む文化（日本語） vs. 読まない文化（英語）」では、仕様書の行間問題を取り上げました。これはレストランでの「メニューに写真がない」に似ています。ソフトウェア開発での日本流の仕様記述方法は、最初は厳密に仕様を記述せず、相手に行間をくみ取ってもらうスタイルです。これは日本語が高文脈言語（文章の中に全ての意味が入っておらず、不足分は、聞き手が自分の知識で補わねばならない言語）なのが一因といわれています。私たち、日本人は、無意識のうちに相手の行間を読んで人と話し、文章を書いているのです。

　それと同じ気分で仕様書を書くと、外国人エンジニアに「仕様書が曖昧だ」と言われてしまいます。これに対し、大抵の日本人エンジニアは「忙しい中で、いちいち細かいことを書いていられないよ」「日本人同士では、上手くいくんだけどなあ」と反論します。そう言いたい気持は分かりますが、仕様書はソフトウェアの根幹を決める重要なドキュメントです。開発する相手が理解できるように、相手のレベルに合わせて記述することが重要です。

　昔から言われていますが、要求仕様フェーズでの欠陥除去のコストを1とすると、リリース後には200倍に膨れます。また、要求仕様フェーズで発生するバグは、全体の30％にもおよび、その上、このフェーズの欠陥を見つけ出すことは困難だといわれています。行間が埋まっていないスカスカな仕様書を海外の発注先に渡すと、行間が空いたままのスカスカなソフトウェアが納品されることになります。開発文化が違うのです。米国人のプログラマなら、「Garbage in, garbage out（ゴミのような物を入れたら、ゴミみたいな製品が出来上がる）」と言うかもしれません。仕様通りのソフトウェアが納品されなかったときに、どちらが悪いかという責任問題に発展しないようにしましょう。

　日本のソフトウェア業界では、昔から、「行間をキチンと読むエンジニアこそ真のエンジニア」といわれています。しかし、場合によっては、日本の「当たり前」が外国では通用しない可能性があることに注意してください（※3）。

（※3）日本国内で日本人エンジニアだけで開発する場合は、細かく書き過ぎない「行間を読む仕様書」が良しとされるケースが少なくありません。細かく書き過ぎると、その裏に何か特別の意図があるのではと深読みして悩んでしまうからです。要は、そのプロジェクトの「ソフトウェアの『開発文化』に合致している」ことが重要なのです。米国で5年間の駐在を終えて日本へ帰ってきたエンジニアが、ざるソバを音なしでモソモソ食っているのを同僚が見とがめて、「アメリカかぶれしやがって。ここは日本だ。ソバってのは、こうやって食うものなんだよ」と勢いよくズルッと食って見せたという話を聞いたことがあります。ソフトウェア開発版の「郷に入っては郷に従え」ですね。