ソースコードのコメントに間違った日本語を見つけたら
中国から納品されたソースコードを確認したら、コメントに意味は分かるけどちょっとかわいい日本語の間違いが数多く見つかりました。
・フォマート
・マック
・バーグ
・細かい「てにをは」の誤り
・一部で中国語簡体字を使用（とりあえず日本語として読める）
現在の状況はこうです。
・顧客はこの事実をまだ知らない
・機能要件は完全に満足する
・要求仕様書に「コメントは全て日本語で記述する」と明記
・中国側の営業担当は「うちは100%日本語ＯＫ」と自信満々
ところで、前半３つの誤った単語の正解は何だか分かりますか？
正解は・・・
・フォーマット（format）
・マーク（mark）
・バグ（bug)
■問いかけ
あなたが日本側の受け入れ担当者なら、中国から納品されたソースコードのコメントに見つかった日本語の間違いを修正しますか。下記の選択肢から、あなたの意見に最も近い回答を選んでクリックしてください。
◆中国に修正依頼する
◆自分で修正する
◆修正しない
◆状況によって異なる
もし、状況によって対応が変わるなら、あなたがコメントを修正するかどうかを判断する基準は何ですか。単語の誤りは修正しても、助詞や敬語の間違いは気にしないと判断する人もいるでしょう。あなたの判断基準を下記のコメントボードにお書きください。
締切：2009年01月20日18時00分
協力：クリックアンケート
追伸
この漢字がソースコードに混ざっていたら、あなたは読めますか？
（出題：上海オフショア開発フォーラム）
正解はThe comments to this entry are closed.
Comments
状況したいです。基準は
１、お客さんとの契約違反になるか？
２、お客さんがこの問題を（知ったら）重要視するか？
３、保守に支障あるか？
４、埋まなければならない空稼働あるか？
５、空稼働作れるか？
以上の問いにyes=修正、no=修正しない。修正作業は日本人が行う。修正後、正誤一覧を共有し再発防止に。
しないのならそれでいいが、但し「一部で中国語簡体字を使用」のは文字コードの問題になるそうでやや不安。
Posted by: 張小東 | January 13, 2009 09:59 PM
私の場合、ほかの修正があるとき、併せてコメントの修正をしてもらう（課題に記入）。コメントだけの修正依頼を出しません。
Posted by: レイコ | January 13, 2009 10:00 PM
>修正作業は日本人が行う。修正後、正誤一覧を共有し再発防止に。
なるほど、よい方法だと思います。
>「一部で中国語簡体字を使用」
こちらは、MS-Office文書だと日常茶飯事ですね。
一部だけフォントが違うので、すぐに判別できます。
ある人は、お客様が問題視しなければ、日本語の間違いを「見逃す」と判断するかもしれません。組織として基準が統一されていればいいのですが。でも、もしも、お客様の会社規模や担当者によって態度が変わるとしたら、判断基準が無いとの同じです。あるいは、運用方法に問題あり。
「先輩、この“フォマート”は修正しますか？」
「あのお客様は厳しいので、今回は全て修正してください」
「中国に依頼しますか？」
「時間がないし、レビューで指摘されなかったと反撃を食らうかもしれないので、今回は日本側で修正しましよう」
オフショア開発プロジェクト受け入れの現場で、毎回同じ質問を受けてうんざりするリーダーがいます。かわいそうですね。
Posted by: 幸地司 | January 13, 2009 10:02 PM
中国在住のお友達がこう話していました。
流暢なビジネス日本語を話す中国人なのに、大事な場面で友達口調で話し始めるのでビックリ。普段から日本語を流暢に話し敬語の知識も備わっているはずなのに、突然「じゃ、またね」などと口にします。当の本人は笑顔を絶やさず丁寧な態度を保ち続けることから、不適切な言葉遣いをしたという自覚はありません。
しゃべりは日本語でも、頭の中は中国語で考えているでしょう。日本社会では明らかなマナー違反ですが、怒りを感じるのは無駄。もともと、敬語表現に馴染んでいない中国人を相手にするときには、多少の間違いなら聞き流すくらいの心の余裕を持ちたいものです。
Posted by: 幸地司 | January 13, 2009 10:03 PM
場合によると思います。ソースが納品物となる場合に、お客様がどの程度意識されるかですね。
個人的には、内容がわかるのであれば、少々の日本語の間違い（文法とか）は見過ごします。
Posted by: ひろせ | January 14, 2009 07:53 PM
自分の経験として、「①中国に修正以来する」を選択します。コメントは実行ソースコードと同様な重要度を置き、専用のツールを使って抽出し、ドキュメント化する。
なお、Lesson Learnedとして、オフショア側が正誤一覧に補充し、将来のプロジェクトで使用します。
Posted by: 周 春燕 | January 14, 2009 07:54 PM
>ソースが納品物となる場合に、お客様がどの程度意識されるかですね。
細かい日本語の間違いを修正するかどうかは、組織の品質基準が統一されているかどうかに加えて、個人の職業倫理観も影響します。医者と患者の関係に喩えると分かりやすいでしょう。
ある患者がインフルエンザにかかり医者を訪ねました。幸いにも軽い症状だったので、注射１本でインフルエンザは回復する見込みです。ここで医者は１つ気になることがあります。それは、この患者の生活習慣の乱れです。本人は、生活習慣に乱れを意識していないか、甘く見ているか、あるいは諦めているようです。医者は、お節介と知りながら、この患者の生活習慣の乱れを指摘すべきでしょうか？
・本来の要件（用件） ＝インフルエンザの治療
・機能要件を満たす ＝インフルエンザ回復の見込み
・軽い日本語の間違い ＝生活習慣の乱れ
・日本語の間違いを修正＝医者が生活習慣の乱れを指摘する
・お客様が意識するか ＝患者が生活習慣の乱れを自覚するか
患者が気にしないからといって、医者は明確な生活習慣の乱れを放置べきでしょうか。顧客はソースコードの中身なんか気にしないので、コメント中の日本語の間違いくらいは見逃すべきでしょうか。
これが「職業倫理観」の問題です。
Posted by: 幸地司 | January 14, 2009 07:56 PM
> 専用のツールを使って抽出し、ドキュメント化する
Javadocのようなツールを自作したのですか。
正誤一覧のようなモノが関係者の間で共有されると、僅かながら生産性が高まりそうですね。そして、もし正誤表に載っているのにミスを犯したプログラマがいたら、人事評価でマイナス点をつける・・・。中国人事管理の発想ですが、いかがでしょうか。現場に嫌がられるかな？
Posted by: 幸地司 | January 14, 2009 07:58 PM
多くの組織では、中国に日本と“同等”な品質基準を求めます。「なぜ、これくらいも出来ないのか？」と、時には厳しくオフショア拠点の問題を責め立てます。
プロマネ支援の第一人者 好川哲人氏は、オフショア開発で水平分業を目指すなら、中国に「日本人と同じ」を求めてもよいが、チームを作るなら逆ではないか、と指摘します。
→ 組織学習の出発点、紙に書いて目立つように掲載する
http://aicoach.tea-nifty.com/offshore/2008/03/post_0d08.html
私は、オフショア開発では水平分業を目指すべきだと思います。ですから、成熟度が低い組織では、中国に「日本と同じ」を求めるべきです。時間が経ち、水平分業モデルも成熟したら、世界規模のオフショアリングを目指します。そうなったら、基準そのものも進化します。「日本と同じ」ではなく「世界共通の基準に従え」となります。水平分業モデルの成熟に伴い、好川氏のいうように多様性（ダイバーシティ）を活用する段階に移ります。
上記指針にしたがえば、次の考え方に落ち着きます。成熟度が低く、中国の決まった一拠点としか取引しない組織では、中国オフショア開発でも「日本と同じ」を求めます。日本語の“てにをは”・敬語表現も含めて、日本と同一レベルを追求します。
ですから、もしも中国人プログラマにビジネスレベルの日本語を要求できないと判断すれば、そこは中国に任せないで日本人が対応します。そもそも、日本国内案件の納品物でも、完璧な美しい日本語文章など要求されていないので、あまり恐れることはないでしょう。
そして、中国の複数拠点と取引をはじめるようになり、さらにベトナムやインドとも共同開発するようになると、従来の延長では太刀打ちできないことに気づきます。多文化・多国籍チームにおいては、日本式一辺倒の基準などすぐに限界に達します。そこでようやく、ソフトウェア業界で使い古された「プロセス標準化」や「モジュール化」、それも世界基準の標準化が登場します。
問題は、世界基準となる標準化の抽象度です。プログラマの自由裁量を奪うほど細かい粒度の標準化が必要なのか、それとも粗い抽象的な指針レベルで十分なのか。
かつて、数万人規模のホワイトカラー職（創造的企画・開発職業）が世界規模で水平分業された経験がないので、この後は未知の領域です。プログラマや設計者をブルーカラー職（労働集約型）と見なせば、ＰＣやアパレル業界の成功例がお手本となります。
Posted by: 幸地司 | January 14, 2009 07:59 PM
開発途中で見つかりボリュームも少ない場合は自分で直して修正例を掲示し、再発した場合は「指摘｣として計上する事を明確に指示します。
自分で直せない量の場合は、注意だけして済ませ開発ロットの区切りなどで仕切りなおします。
Posted by: 竹野 | January 15, 2009 06:15 PM
>竹野さん
>再発した場合は「指摘｣として計上する
「指摘」を食らうとマイナス評価に直結するのですね。この脅しは有効ですか。指摘が増えると、PMの人事評価に響くのでしょうか。それとも、プロジェクト評価に響いて、その結果日本からの支払額が変わる？（ってことは無いか）
Posted by: 幸地司 | January 15, 2009 06:16 PM
>「指摘」を食らうとマイナス評価に直結するのですね。
そうですね。どれだけ個々の評価にフィードバックされているかは把握していませんが、自分からの定性評価には「過去にも指摘したことのあるケアレスミスが多い｣と書きます。書式のミスなどと同様の扱いです。中国で出来る確認を怠っている、と伝えます。
責任の所在が中国側にあることを伝えられるので（指摘として挙げないと、東京の受入側に責任がある、と言われる事があります）再発した場合、修正を指示しても素直にやってくれるようになります。
ソースのコメントではないですが、書式や印刷プレビューを何度も指摘したら、そろえるＴＯＯＬを中国側は作ってました。東京から送付する仕様書の罫線が揃っていない事もあり、最近はこっちの方が恥ずかしいです。
Posted by: 竹野 | January 19, 2009 10:00 PM
内容が質問とずれることをお許しください。
今回の質問は中国側からの日本語ですが、日本側で記載してきたコメント欄について記載をさせてください。
オフショアとは全く逆で日本に開発を依頼したことがあります。
その時、納品されてきたプログラムの中に書かれていたコメント
--------------
Shukkashiji-data
--------------
最初？？？？？？となり、理解した瞬間、のけぞりました！
日本語のコメントを入れてきた人まで居て、日本側のコメントに対する意識の無さに呆然。
さらに、処理結果の画面に記載されたヘッダーまで
Shukkashiji Kekka と書かれた日には泣きました。
相手のことをどれだけ思えるか？これがお互いに依頼をする時の作法だと思います。
（内容が外れてしまい、申し訳ありません。
ただ、どうしてもこの質問を見て、書きたくなってしまいました。。。ご容赦ください。）
Posted by: 中国華南在住 | January 19, 2009 10:00 PM
中国に修正依頼します。
先方からの納品物に対し、無断で手を入れるのは瑕疵担保規定上からもあり得ません。
また将来にわたり良きパートナでいるためにも、お互いのミスに対してきちんと指摘をし成長していく必要があると思います。
修正しないケースがあるとすれば、検収基準にもコーディング規約にもコメントについての取り決めが無い場合ですが、こんな契約は誰もしませんよね。
Posted by: gocou | January 19, 2009 10:00 PM
> 竹野さん
> どれだけ個々の評価にフィードバックされているかは把握していません
興味ありますね～。宜しければこっそり調べて教えてください！
拙著「オフショア開発に失敗する方法」から、オフショア開発のプロジェクト評価会でよくある光景を抜粋します。
プロジェクト完了評価会との名目で、発注側の日本企業が中国ベンダの営業担当者を呼び出します。場所は発注企業の会議室です。本来なら、中国側のプロジェクトマネージャも同席させたいところですが、完了会のためだけに来日させるわけにはいかず、やむを得ず欠席。日本に常駐して一時期ブリッジSEとして活躍した中国人SEも、すでに別の仕事に取りかかっているためこの会への出席は見合わせることになりました。対照的に、発注側からは主要な開発メンバがずらりと顔を揃えます。彼らの手元にある資料は、プロジェクト実行中に起こった全ての問題点が表形式で挙げられており、中国側への改善要求がぎっしり詰まっています。そして、プロジェクト実行中にうやむやのまま放っておかれた懸案事項を1つずつ検証して、責任の白黒をはっきりつける構えでこの日の完了評価会を迎えました。
失敗プロジェクトの評価会はだいたいこんな感じで進められます。
Posted by: 幸地司 | January 20, 2009 06:19 PM
> 中国華南在住さん
> その時、納品されてきたプログラムの中に書かれていたコメント
> Shukkashiji-data
日経BPのサイトにちょうどこんな記事が掲載されました。ナイスタイミングです。
表現のミス対策 - ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20090108/322438/
名前の付け方がその一つ。アルファベットを使う場合，日本人が理解しやすいようにデータ項目を「kokyaku」や「kakaku」などローマ字にする人は多い。だが「海外の開発者はローマ字の意味を考え込んでしまう」。これは「customer」や「price」といった英語で表記することで解決できる。
Posted by: 幸地司 | January 20, 2009 06:20 PM
> gocouさん
> 先方からの納品物に対し、無断で手を入れるのは瑕疵担保規定上からもあり得ませ
お見事！ 先日、琉球大学のプロマネ講座で同じ質問がありました。日本人同士、特に沖縄人同士のシステム保守業務では、無断で手を入れるなんて日常茶飯事らしいです。もちろん「ちょっとした変更のみ」ですが。
で、ここで問題となるのが「中国人に完璧な日本語を求めるべきか？」です。教科書的には、費用対効果の観点で意思決定する、が模範回答ですが、これが意外に難しいのです。「てにをは（助詞）」や「美しく正しい敬語」の面倒な指導は、個人の力量アップには寄与しますが、中国ベンダの組織力向上には寄与しません。理由は「激しい人材流動性」。
優秀な中国人技術者は「すぐに転職する」といいたいわけではありません。優秀な中国人技術者は「すぐに出世する」という意味です。優秀なプログラマはすぐに出世してSEへ昇格、日本語が達者なSEはすぐにプロマネやBSEに昇格、・・・。
出世魚のように偉くなった彼らは、もはやソースコードの日本語の誤りを修正する立場にいません。悩ましい事実です。
Posted by: 幸地司 | January 20, 2009 06:21 PM
> で、ここで問題となるのが「中国人に完璧な日本語を求めるべきか？」です。
このケースでは求めません。
ソース内のコメントは、予めコーディング規約でシーケンス図に記述する程度のシンプルな日本語を用いるように取り決めておきます。
その上で「てにをは（助詞）」の間違いは、コメントそのものの意味を変えてしまう恐れがあるので厳密にチェックすべきだとは思いますが、現地エンジニア相手に「美しく正しい敬語」までは厳しいですよね。
また、そうした指摘をどうやって組織の力につなげるか？については、ベンダ選定の時点で勝負が決まると思います。
企業文化レベルでナレッジマネジメントの土壌を持たない相手に、いくら指摘事項の社内共有を求めても無駄なことが多いです。
これこそ「育ち」「資質」の分野ですので、いくらこちらが頑張っても費用対効果の観点では絶望的です。
バグは上流で摘むほど低コストでの収拾が可能ですが、オフショア開発の導入も上流（＝ベンダ選定）で手を抜かないことが大事ではないでしょうか？
Posted by: gocou | January 20, 2009 06:22 PM
コメントの内容がソースコードの保守性（主に第三者視点で）に著しい悪影響を及ぼすならば、修正を要求。さもなくば放置。
Posted by: 三浦 | January 20, 2009 06:23 PM
弊社では中国、日本双方で対策をとっています。
日本側での対策は
１．中国人の書いたちょっとおかしなコメントを読解できるようにする。（慣れさせる）
２．中国に委託しているのであるから、日本語は多少おかしくても当然という意識を植え付ける。
（ど新人の日本人と大してかわらないと言う意見もあります。）
中国側での対策は
１．専門の技術通訳者（正式名称は判りません）を採用し、ソース上のコメントをチェックさせる。
通訳は技術者よりはるかに採用コストも安く、いい人材も転がっています。（現地採用日本人、中国人との給与の差も余りありません。）
２．日本語３級、２級レベルの技術者であれば、Ｓ，Ｖ，Ｏをしっかり書かせ、助詞は気にしない。（書かなくても良いとする）
３．普段よりコミュニケーションや社内チャットツールを使って、日本語の質問をしやすい雰囲気を醸成し、聞くことは恥じゃないと言う社風を作り上げる。
（聞く事によってプライドを傷つけることをなくす。）
４．頻繁に使う単語リストの作成とユーザー辞書へ登録する。（言い回しも含めて）
５．昼休みを利用した日本語の勉強会
委譲の対策を行ったうえで、コメントによって違う意味となってしまうものについては日本側で修正し
修正箇所を中国側にフィードバックします。中国側ではフィードバックされてたものを通訳に教育し、
その後技術者の勉強会で意識あわせを行います。
一発物の請負中心ですと意見はまた違ってくるとは思いますが、教育に関してはコストを気にしすぎると長期的な成長速度は却って遅くなるように感じます。
長文失礼しました。
Posted by: 大連帰り | January 20, 2009 06:25 PM
gocouさん
>オフショア開発の導入も上流（＝ベンダ選定）で手を抜かないことが大事ではないでしょうか？
まさにそのとおり！
ですが、それができないのが海外法人や長期のラボ契約を持つ大手システムインテグレータ様。大手に限らず、中規模だって特定の決まったベンダとしか取引できない会社は多数あります。
最近、私の周りでは「ベンダ選定」の話題を聞く機会がめっきり減りました。今のところ、ベンダ選定で苦労する会社は少ないというか、よりどりみどりで選び放題といった感じかもしれません。あるいは、ベンダ選定どころか、自社が中抜きされそうで困っている状態かもしれません。
Posted by: 幸地司 | January 20, 2009 11:01 PM
大連帰りさん
> 現地採用日本人、中国人との給与の差も余りありません。
これが最も効果的、かつ現実的な解決策のような気がします。社内で日本語教師を兼ねると別ですが、普通の日本人ならお値打ち価格で現地採用できそうです。かつて、語学研修にかこつけて日本人フリーターをだまして大連に拉致する事業がお茶の間でも話題にのぼりました。今頃、月給4000元ほどで現地採用された日本人はどうしているのかな～。
Posted by: 幸地司 | January 20, 2009 11:02 PM