Comments
Description
Transcript
インド設計会社への設計委託 について
インド設計会社への設計委託 について のぞみ株式会社 ２０１１年11月 住所 ： 東京都多摩市関戸４－２３－１ 関戸ビル３Ｆ E-mail ： [email protected] 電話 ： 04２(319)6146 11 1 「のぞみ」について 組込み技術全般に高い技術を有する。「千手観音のような会社」（ユーザの言葉） 組込みシステムのハード/ソフトの設計会社 基礎技術開発 RTOS（iTRON、T-Kernel、Linuxなど） 通信プロトコル（TCP/IP、Bluetooth、ZigBeeなど） Cコンパイラ の設計 など FPGA（Actel、Xilinx、Altera）設計 「のぞみ」の応用技術 低消費電力化、ワン・チップ化 に強み 制御 ： 機構制御、電子回路制御、基板・装置テスト 音声 ： ヘッドフォン・ステレオの音声技術 画像 ： ディジタル・カメラ、ゲーム機 通信 ： WLAN , DSRC , Bluetooth , ZigBee , TCP/IP（次ページを参照） セキュリティ ： 指紋認証、スマート・カード 2 インドでの電子機器の設計と製造 最近、インドでは、ソフトウェアだけではなく電子機器の設計および製造も行われ るようになってきた。 インドで設計、製造された電子基板 インドで製造される電子機器 3 インドでの電子機器の研究と設計 インドでの電子機器の研究と設計の現場 4 インドでの電子機器の製造現場 インドでの電子機器などの製造現場。日本の企業は中国で製造するケースが多 いが、EUの企業やUSの企業は製造にインドを活用するケースも増えてきている PCB Assembly Fiber Optics Wire Harnesses Chip-on-Board Clean Room Injection Molding 5 インドでのソフト設計例 ソフトウェア開発の代表的な例を3つ紹介する。 １ 音声・画像開発 1.1 開発製品 2.2 開発結果 ： コーデック、サムネイル ： デモ 参照 ２ 通信ソフト 2.1 開発製品 ： TCP/IP 2.2 開発結果 （１）パフォーマンス ： 世界最高クラス （２）メモリ効率 ： 世界最高クラス no copy, no buffer による。 またflexibilityに富む。 ３ IC カード 3.1 開発製品 3.2 開発結果 ：EMV、評価システム、カード・インターフェース など ：次ページを参照 6 インドでのソフト設計例の結果（TCP/IP） Protocol ARP Process ARP Request Process ARP reply Maintains Cache Table Size IP, ARP, ICMP TCP UDP Sockets IGMP, DHCP Total Acme (ARM 32bit) IP Basic data transfer Fragmentation UDP TCP ICMP Basic data transfer Connection Basic data transfer Process Echo Request Send Echo Reply Basic data transfer Sending Error messages Sending multicast (level 1) Checksum Delayed ack version1 version 2 Reassembly Interniche Blunk tech., micro Ubicom (ARM system (Unknown) 32bit) (Unknown) ROM - 7kb, RAM – ROM -15kb 20bytes ROM - 7.9kb, RAM – 8bytes ROM - 0.4kb, RAM – 0byte ROM - 31kb ROM - 4.7kb RAM - 88bytes (1 socket) ROM - 2.3kb + 5.9kb _ RAM – 250byte ROM = ~28kb RAM = ROM - 46kb 366bytes IGMPv1 and v2 - ROM -5.6kb, RAM – 92 ROM - 7kb, RAM – 92 ROM - 2.1kb, RAM – 28 - ROM - 5kb, RAM – 140 - DHCP ROM 2.1kb RAM – 36 - ROM = ~20kb RAM = 388bytes Jacobson rto estimation algorithm Jacobson slow start algorithm Jacobson congestion avoidance algorithm Process Error messages DHCP Basic host auto configuration send option request list Receiving multicast (level 2) Basic Protocol and Features Configurable Protocol and Features 例 TCP/IP stack configurablity 7 開発過程で生じた問題とその解決方法 １ 事前の対処 ： 検証が一番問題。試験システム自体もインドで開発。 ２ 開発過程 ： 順調に推移。特にインドでの上流設計をレビューしたことが効果。 アルゴリズム、データ構造などについてのレビューを実施。 （開発初期に日本のエキスパート4名が2週間、インドで実施） ３ 検証 ： TCP/IPを検証するためにWindowsのTCP/IPをはずし、かわりに開発した TCP/IPをWindowsに埋め込み、世界中のサイトと接続して検証をおこ なった。 ４ バグへの対処 ： 日本での一次窓口で問題点を絞込んでインドに対策を依頼。 ５ 版数管理等 ： 日本で一元管理した。Versionも日本から指示した。 8 高いインドのソフト開発力 技術者 設計態度 知識/方法 集中度 開発時間 ： 前向き、より技術志向（ビジネス志向の強い中国人に比較して） ： 実際的な知識が高い。研究、開発の方法論も身に付けている。 新卒で日本人の３－４年の経験者に相当する。 ： 非常に高い。 ： 土曜日勤務も多い。深夜まで、また日曜の作業も珍しくない 設計組織 設計環境 ： 一般的には日本より恵まれた環境（次ページの写真を参照） 仕組 ： ISO、CMMIなどの仕組み構築能力は高い 技術開発力 ： 新規技術にチャレンジする精神は旺盛 柔軟なモデル ： 日本の会社に入っての開発、インドでの受託など柔軟なビジネ ス・モデル 9 インドで開発する前に（1） １ はじめてインドの会社に開発委託するとき （１）委託する案件について 実績あるソフトを導入したり、それを自社の製品にインプリメントする作業を委託するのは容 易にみえて結構難しい。自社の環境との整合をとるための努力が必要。 バリデーションやシミュレーション・システムの構築を委託が比較的容易。 （２）日本での経験のある会社をえらびかた 優秀な代理店や日本事務所をもつ会社をえらんだほうがよいのではないか。 ２ ビジネス・モデル インドのソフト会社は通常、非常に柔軟なビジネス・モデルを用意している。 （１）契約上 ☆ Turn key ☆ ODC ☆ Licence ☆ 著作権の扱い ・委託元に帰属させることも可能 （２）開発の形態 ☆ On Site ☆ Off Shore 10 インドで開発する前に（2） ３ 租税条約 日印租税条約に基づいて、インド側からの役務提供、ライセンス・ロイヤリティ などには10 パーセントの租税が掛けられる。06年度より２０パーセントが１０パーセントに切り下げられた。 日本の国内法により10パーセントの租税は源泉徴収される。徴収された証明をインド側に 送るとインド側では税の減免を受けられる場合がある。 ４ ソフトの開発スタイルについて （１）検証方法 多くの優秀な技術者を容易に確保できるという利点を生かして、検証システム自体も開発 することをすすめる。しかし日本では技術者数の制約や開発コスト削減のために、対象となる ソフト開発自体にはリソースを投入しても検証をシステム化することに注力することには意識 が希薄な場合が多い。その延長でソフト開発のみをインドの会社に開発委託し、検証は日本 でおこなうというスタイルが多いようである。 （２）品質管理 インドのソフト会社の多くは日本のソフト会社よりも優れた品質システムを有している。日本 の品質システムを持ち込まなくとも、彼らの優れたシステムを活用することができる。 11 インドで開発する前に（3） ５ 日本側の決定過程の特徴 多くのインドのソフト会社は、日本の会社は開発を決定するまでに非常に多くの時間を要すし、 他方、開発を決定したあとの具体的な開発は非常に速いと感じている。 彼らの多くがUSの会社からの開発委託を経験しており、その経験を日本での開発決定プロセ スに投影してみるからである。 1) 日本的なトップダウン トップダウンといっても、具体的な方針が下りてくるのはまれである。具体的な判断の多くは下 にゆだねられている場合が多い。 2) 日本的判断 「トップの判断」とは、実際は下からの提案を承認することを意味する場合が多い。 決定前は「まだか、まだか」、決定後は「そんなに早くはできない」というインド側の対応に会う ことになる。 決定前から、インド側の体制を確認しておくとよい。 次ページにインドのソフト会社の見た日本の会社の決定プロセスを示す。 12 インドで開発する前に（4） Decision process (Japanese Top down) Decision flow Co-Operate Company Go and back need long time President & CEO President Division Department General manager General manager Make plan Case by case Section Section Section Manager Make plan インド設計会社に開発委託するために（1） １ 要求仕様を明確にすること ソフトウェアの開発において、しばしば期待した内容と異なる機能を実現してくることがあ る。 ☆ 仕様そのものを事前に可能な限り検証すること （１）仕様自体を検証するシミュレーション・システムを構築する方法も検討したほうがよい。多 くのインドのソフト会社は、こうした能力を保有している。 ☆ 英訳上の注意点 日本語の仕様書を英訳してインドの会社に依頼するときには次の点を注意すること ◎ 日本語を事前に検証し、日本語のもつあいまいさを極力除くこと。代表的な日本語の問 題は次の通り。 （１）主語がない。 （２）指示代名詞がなにをさしているのか明確でない。 （３）かかり、が色々に解釈できる。 （４）造語が使用されている。また一つのことに複数の言い方をあてている。用語が統一され ていない。 等 ◎ 翻訳自体をインドのソフト会社に委託することも可能であるが、翻訳の品質は、もとになる 仕様書の日本語の品質次第である。 14 インド設計会社に開発委託するために（2） ☆ 仕様書に記述する指示内容を明瞭に記述すること 日本人は「かくあるべき」ことは実現することが必須の仕様であると感覚する。しかし、「あ るべき」をそのまま英語に翻訳すると通常、 should に翻訳される。 should は、通 常、実現したほうが良いが実現しなくともよい、と解釈される。次のように必須項 目は shall で記述し、実現できれば良いが必須ではない項目を should で記 述する旨、仕様書の最初に記述しておくと良い。 shall should Denotes a mandatory requirement Denotes a recommendation 15 検証システム例 検証システムの例を示す。中央にテスト・プログラムを記述すると、右に結果が表示される。 左では各種の機能区分を定義できる。テスト・プログラムのためのコマンドを選択する機能も用 意されている。 INP UT FILE S REA DS REA DS C-SPY MAC RO EXECU TES ICCOS CONFIG.D AT WRIT ES GENERAT ES EXECUTI ON RESULT REA DS WRIT ES ICCOS TESTING TOOL GENERAT COMRARE ES S LOG FILES EXPECT ED RESULT Script Testing Control Flow 16 インド設計会社に開発委託するために（３） 3 開発プロセスの共有化 インド側には彼らなりのやり方や文化がある。それを尊重しながら、同時に開発プロセスの共 有化を図ることが必要である。 4 チームの定義 インド側（に限らないが）は組織的にソフトウェアやシステムの開発に取り組むとき、チーム員 の連携を取りながらチームプレイにより開発をすすめることは、あまり得意ではない。チーム （Team）という用語は共通でも、インド側と日本側とが共通のイメージを持つとは限らない。 SE － プログラマ － コーダ という開発段階を階層化し、各自の役割を明確にして開発するスタイルがインドでも一般的であ る。 はじめに、一つのプロジェクトを担当する集団をチームと定義し、チーム員はお互いに情報 を伝え合い、また協力しあうことを確認することは有効である。 5 情報の共有 普通、チーム員のAさんに伝えた情報は他のチーム員のBさん、Cさんには伝わらない。他のメ ンバと情報を共有するように伝えても、普通、自分の役割とは考えず、他のメンバーに情報を伝 えるとは限らない。上記のようにチームが定義されお互いに情報を共有することが確認されてい るならば、Aさんに他のチーム員に伝えるように頼むことができる。 17 インド設計会社に開発委託するために（4） 6 なでしこジャパンの強み チームプレイ、選手たちの連携のよさは抜群 右の写真は女子ワールドカップ決勝の延長 後半に澤選手が同点のゴールを決める直前 の写真です。 黒丸の青いユニフォームが澤選手。コーナ キックをける前にコーナ方向の誰もいない領 域（四角く白く囲った空間）に向けて走り出す （上の写真）。 そこに向けて宮間選手がボールを挙げた （下の写真、白丸の中にボールが見える）。 直前の短い時間に“宮間が「ニアに蹴る」と 言い、それに澤が「一番に飛び込む」と答えた “そうである。 ソフト開発においても日本のチームプレイ、 選手の連携のよさは抜群である。日本人は自 覚していないことも多いが。 18 インド設計会社に開発委託するために（5） 7 野球におけるチームプレイ ファーストごろを処理するときの選手の動きを示す。一塁手がボールを取りに走り、投手が1塁 を抑え、右翼手が一塁の背後を守る。 選手は自然にこのように動く。野球の理論を各選手が体で覚えているから。 ソフト開発技術者が開発の進展や他の技術者の進捗を見て相互に連携してプロジェクトをす すめるよう日本の技術者は自然に動く。この時、日本人はチーム員相互の絆が強いと感じる。 インド人も似た感覚を持っている。しかし、早くチームプレイを根付かせ、あるいは日本側と共 通の認識にたってプロジェクトを進めるには理論的に整理し共有化したほうがよい。 右翼手 投手 一塁手 ボール 19 インド設計会社に開発委託するために（6） 8 インド側と日本的なよさを共有するために インド側も日本のよさを認識しつつある。 インドの技術者にはチーム員相互の連携をソフト開発のTheoryとして教育するならば、彼らも 日本人と同様にチーム内で有機的に活動するようになる。おそらく農耕民族としての共通性、村 落共同体出身者が多いという土壌が関係しているように思う。 9 役割 すでに述べたようにチーム員としての自覚を促すことがはじめの一歩である。 また、役割、進め方、マイルストーンなどをあらかじめ確認しておくとよい。 次に、その例を示す。 20 Software design management regulation • Role and Authority Role Authority Project Manager Management of a development project Establishment of a project. Assignment of a project leader. Completion judgment of a software design. Project Leader The leader of a development project The planning of a design. The check of the input to a design, and recognition of the output from a design. Project Member The member of a development project Participation to a design planning. Creation of output. Design verification of output. Software design management regulation • Output and Records The output and record for every milestone are defined. P - Software development plan document SD PD CD PT ST (VD) VD - review record - System specification document - Design review record - Program specification document - (Design) review record - Source code, Binary - Test specifications - Test result - Test result review record - Shipment Approval record Software design management regulation • The work item in Milestones Planning: - Creation of a software development plan document - Development outline - Development organization - Development schedule - Design data - Development environment - Management method - Quality management - Test plan - Special mention matter - Development scale It is created by the project leader. The example - The review of a software development plan document With all the persons concerned. The example-1 The example-2 インド設計会社に開発委託するために（6） 10 バグやクレームへの対応方法 バグやユーザからのクレームの対応方法に対しては、問題点を日本で絞り込んでから、対応 を依頼すること。そのような体制を日本に構築しておくこと。 11 品質優先か、納期優先か インドのソフト会社の多くは、品質を優先する。開発に時間がかかったり、テストに時間がか かっている場合、当初の計画とは異なる事項が生じているとかれらが考えた場合、納期に製品 が完成しなくとも当然という感覚をもっている。 おそらく日本以外では、普通の感覚であろう。 24 インド設計会社に開発委託するために（7） 12 議論はできるだけ具体的に たとえば、「開発プロセスを改良すべき」といった抽象度では生産的な議論は難しい。「プログラ ム仕様書に記載する項目にXXXXを追加すべき」というように、できるだけ具体的に議論すること。 13 反省は求めないこと 問題を起こしたことに対して反省をもとめるとうまくいかない。問題点を解決するように、問題点 への対策を具体的に要求仕様にもりこむこと。 14 インドの会社とのコミュニケーションについて 開発の丸投げは危険。 （１） メールやレポートによる管理 週次で、開発の進捗についてメールや報告書による報告を求めることを推奨する。 （２） mail stone 管理 定期的にミーティングを持つことを推奨する。上記の報告で顕在化した問題を解決するとよ い。また開発計画や仕様についてのインド側の理解が誤っていたり、日本側から提供した資料な どに不備がある場合も多い。 25 インド設計会社での開発委託における問題例（1） 委託内容 システム全体は日本で開発したが、ある部分の開発をインドの設計会社に委託した。そのイン ドの設計会社は大手の設計会社であり、当該の技術に関しては実績があるという話だった。ま た、既存のパッケージ・ソフトをこの会社から購入し、問題なく使用できたという実績もあった。 直接の問題 ほぼ、納期通りにインド側から、当該のソフトは納品されてきたが、インド側で開発した部分と 日本側で開発した部分とのインターフェースが一致しておらず、インドで開発した部分が動作し ないという問題が生じた。インターフェースの問題が解決した後も、機能上の問題が次々と現れ、 結局は日本側で再設計することになった。 対処の仕方 当初、インド側とは、メールやデータのやり取りによって問題の箇所と修正方法を明らかにし、 日本側で修正をおこなうという方法により解決を目指したが問題を解決することができなかった。 日本側での再設計も難航し、大幅に納期を遅延させることになった。 26 インド設計会社での開発委託における問題例（2） 真の問題 そもそも設計を委託した日本側では、設計手順や設計工程の管理方法が明確ではない、とい うインドに開発を委託する以前的な問題が根本にあるように思われる。 しかし、ここでは話を設計の仕方や、インド側とのコミュニケーションのとり方に限定したい。 （１）インドへの開発委託の目的： 開発コストの低減。 インドの高い技術力を活用して、開発期間を短縮し、いち早く製品を市場に投入する、いわ ば「時間を買う」という考え方をする企業も現れてきた。 （２）開発スタイル： 日本風の設計スタイルのまま。（後述） （３）インド側の位置づけ： 下請け。したがって情報も基本的にインド側への一方通行。 USの会社の場合、インドの設計会社をパートナーとして位置づける場合が多い。 （４）問題の解決の仕方： 問題が生じた場合は日本側で解決するという解決の仕方。 27 インド設計会社での開発委託における問題例（3） 開発スタイル 日本での技術者同士が顔をつき合わせて、仕様を確認し、また問題を一緒になって解決して いくという、日本風？の開発スタイルを日本側はとりながら、他方、インドの設計会社に開発委 託した部分を、いわばパッケージ・ソフトを購入するように扱っている。 この日本の会社はこれまでも、システムの特定部分を日本の設計会社に委託して開発して きた。この場合、開発を委託する日本の設計会社とは、日本での技術者同士が顔をつき合わせ て、仕様を確認し、また問題を一緒になって解決していくというスタイルをとってきた。今回はイン ドに開発を委託することから、従来、日本の設計会社に対しての開発スタイルをとれない。以前 のパッケージ・ソフトを導入したときのような態度をとったのである。 開発スタイルを変えることは容易ではない。日本的な開発スタイルにはそもそも試行錯誤を繰 り返すから、よい製品を開発できるという積極的な意味がある場合も多い。 開発スタイルをかえるより地理的に離れているなかで、どのように従来のスタイルに近い方法 を考えたほうがよい。具体的には、 （１）ある程度、頻繁にミーティングを持つこと。 （２）日本側から仕様をインド側に提供するだけではなく、インド側に、その都度、資料の提供を 求め、日本側で検証すること。 （３）一定のずれが生じた場合の対処や、日本側での仕様変更をも見込んだ計画を立て、相互 に確認しておくこと。 28 インド設計会社での開発委託における問題例（4） インターフェースの確認 一部の機能部分を先行してインド側で開発し、日本側では接続部分を開発し、実際の結合テ ストの前に両者のインターフェースの確認を行っておくとよい。 この場合、インド側で開発する部分は簡単なモデルでもよい。たとえば、日本側で開発するモ デルからデータを送り、インド側で開発するモデルが受け取り、それを送り返すといった簡単な テストでも相互のインターフェースの確認には有効である。 実開発の前のモデル 日本側、インド側ともモデルの内容は実質的に空、インターフェース部分は実装 日本側で開発す る部分のモデル インド側で開発 する部分のモデ ル 29 ブリッジSEの活用法とよくある問題 ブリッジSEは日本に常駐し、日本語（あるいは英語）で、日本側とインド現地と間 の橋渡しとなるSE。最近、日本語を話すインド人も増え、ブリッジSEを通してイン ドにソフト開発を発注するケースも増えてきた。 しかし、日本側の期待通りには進まないケースも多い。 活用すべき領域 開発初期 開発過程 開発後 ： インド側に仕様を理解させる作業 ： 問題点の整理 開発開始後はブリッジSEを介在させないで、直接インドの技術者と の間でコミュニケーションをとることが望ましい。 ： 課題を絞込みインド側に伝える作業 ブリッジSE活用のこつ 日本側がブリッジSEに過度に依存することから問題が生じるケースが多い。ブリッジSEはあく までも橋渡し役であり、仕様をインド現地に理解させることができたなら、それ以降は実務担当 者同士で進めることが望ましい。 30 ブリッジSEとのコミュニケーション（１） ブリッジSEを通してもコミュニケーションは容易ではない。ブリッジSEとのコミュニ ケーション上の問題点を簡単に整理してみたい。 （１）会話 インド人のSEには必ず主語、述語を添えて話すこと。またゆっくりと、平易な言葉、できれば、 やまと言葉で話すこと。 日本で働くインド人の大多数が南インド出身である。たとえばインドの公用語の一つでチェ ンナイなどでは一般的なタミール語は、その文法は日本語のそれに近い。タミール語も主語、 述語、目的語の順番は日本語と同じで「OOはXX を△△します」という順序をとる。また単語も 日本語に似たものが多い。そういうことから日本語の話せるインド人も多い。日本語の起源は タミール語であると言う説を学習院大学の大野晋教授は述べている。しかし、日本語をよく話 すインド人も漢字は苦手である。漢字が理解できないために漢字の音から意味を連想できな い。 やまと言葉のほうが会話の中では理解しやすい。 正しい日本語を学んできた人から見ると「日本の若い人はslangでしか話さない」ように見え る。普通の会話の方が、正しい日本語でより記述された専門用語による技術的な文章よりも、 はるかに難しいのである。 31 ブリッジSEとのコミュニケーション（２） コミュニケーションをとる上にも日本とインドとの文化や言語の違いがある。その ことを理解していると、誤解を減少させることができる。 誤解を招きやすい会話の例 1）“てにをは“は間違っても意味が通じるように話し方をすること “てにをは“は英語圏の人には難しく感じられるようである。 「には」と「は」 ： 「15日には」は、普通、日本人は“「遅くとも15日には」という意味で14日でも、あるいはもっと はやくてもかまわないが、１５日までには”という意味で使用する。しかし「15日に」と理解され ることも多い。 「できるだけ早く、遅くとも15日には必要である」と、こちらの考えを誤解されないように述べ た方がよい。日本人同士の会話でも、「15日には」 を 「15日に」 と聞き誤ることもある。 2）語順を意識し、主語から話はじめること 日本語は“てにをは“を駆使して語順を自由に変えることができる。英語や中国語は基本的 に語順のとおりの言語。次に「私」と「彼女」の順序の例を示す。 「私、彼女、好き」 「私は彼女が好き」 「私を彼女はすき」 英語圏の人は一般に「私は彼女が好き」を「私、彼女、好き」と聞き、「私は彼女が好き」と理 解する。「私を彼女はすき」も同様に「私、彼女、好き」と聞き「私は彼女が好き」と理解しがちで ある。 32 ブリッジSEとのコミュニケーション（３） 3）話す相手と組織とを明示的に伝えること 「インド側」、「日本側」という表現をしてきたが、実際には「インド側」は多くの組織から構成 されている。各組織間のコミュニケーションは一般にあまり良くない。 A さんに伝えたことは、同じチームのBさんには通常、伝わらない。Aさん、Bさんという複数 のブリッジSEを介してインドとコミュニケーションをとるとき、それぞれがインド側のどの組織と 役割を代表しているかを区別し、それに見合った内容と形式をとってコミュニケーションをとる こと。 （２）要求仕様のあいまいさ 日本語のあいまいさ、英語の誤りが原因で、要求仕様をブリッジSEが誤解するケースも多い。 日本人同士でも誤解はおきる。まして言語や文化が異なる人達とコミュニケーションをとるた めには努力が必要。相手が理解した内容を確認するなどが必要である。 33 ブリッジSEとのコミュニケーション（４） （３）具体的に指示することを嫌う日本人 多くの日本人は不具合を見つけたときに、「 XXが動作しない」という表現で“だからすぐに修 正しなさい”という意味を含ませる。しかし、「 XXが動作しない」とインド側に伝えただけでは普 通、すぐに修正されることはない。しかし日本側は指示したとおりに作業してくれないと感覚す る。 「 XXが動作しない」という表現は状況を説明しているだけ。作業を指示する表現ではない。そ もそも指示していないのである。かならず「 XXXXすること」とSEを通して指示すること。ブリッジ SEが日本語を理解してても、日本人の文化に習熟しているわけではない。 かつてon site で、日本人とともに作業をしている外国人（インド人ではなかった。仮にAさんと 呼ぼう）は技術者としては優秀であるにもかかわらず、Aさんは非常に評判が悪かった。彼と 一緒に作業している日本人によれば「Aさんは指示したことをやってくれない」という。上記の典 型的な例だった。実態は、事実を伝えるだけの日本人の話を、すぐに対策すべきだとはAさん は感覚してはいなかったのである。 日本側も論理的に話すクセをつけよう。 （４）担当者とみなす傾向 ブリッジSEを担当者と機能させる例も多い。日本にブリッジSEとして常駐する技術者は技術者 としても優秀であり、またマネージメント能力も高い。せっかくブリッジSEとして日本の職場に常 駐しているにもかかわらず、実務の多くは日本の設計会社に発注され、その業務の担当者と して機能させられることも多い。コミュニケーションの問題ではないが日本側によくある問題で ある。 34 参考 インド人との英語の会話について １ インド英語を理解する方法 インド英語は一般に次のような発音上の特徴をもつ。これを心得ておくとインド英語が 聞き取りやすい。 （１）“ｔｈ”は“ｔ”のように発音 ex. thirty “ターティ”、three “トゥリー”（木のtreeと同じように発音する）、south “サウトゥ” both “ボットゥ“、north”ノルトゥ“、length”レントゥ”、fort”フォルトゥ“ （２）“ｒ”は通常、巻き舌で“ル”というように発音 ex. fort “フォルト”、north”ノルト“、core”コラ“あるいは”コル“ （３） “e”や子韻の前の“s” は、しばしば“イエ“あるいは“イス“というように発音 ex. earth “イエルトゥ” 、 star “イスタール” cf. “トゥ”は、ツとトとの中間のように発音する。 ２ うなずき方の違い インド人は、合意していることを表現するとき、うなずく動作ではなく下あごをふるよう なしぐさをする。これは首を横にふる動作に近い。日本人がみると否定しているように見 えるので気をつけること。 35 インド人の見る日本 インドでソフトを開発する上での障害のなかにはインドと日本との文化の違いに起因するもの も多い。ここでは、彼らの感覚を理解するためにインド人の目に映る日本を紹介する。 １ インドとの文化の違いについて （１）時間を守る、約束を守る、規則を守るということについて 「日本人についてわかったのは、ほとんど、みんな日本人は忙しいし、働き者だ、約束した時間 を守り、あいてからもそれを期待する」 「日本人と一緒に毎日長い時間仕事をして私も働き者になってしまいました。日本人の約束を守 るとか時間に間に合うという習慣を教えてもらいました。」 「夜1時ぐらいでした。道に車は全然通っていませんでした。その時、車が私達の近くを通ってい きました。車はとても速かったです。その車は、信号の前で急に止まりました。こしょうしたのか なあ！なにか手伝おうかなあと思ってもう一度見ました。その時、信号は赤でした。だから車が 止まったんです。夜1時、交通は全然無かったのにどうして規則にしたがっているんでしょうか？ これはわかりませんでした。」 逆にいうと、普通インドでは、時間を守ることよりも、“論理的な理由があれば遅れるのはしょう がない“、あるいは“遅れるのが当然“と感覚しているようです。 36 （２）日本の仕事について 「せんぱいは日本のプロジェクトは残業が多くて、複雑だといっていました。それに日本人は仕 様と設計変更が多いそうです。」 USやその他の国の仕事に比較して日本の仕事は「仕様と設計変更が多い」という話しについ ては、よりよいものを作り上げていくことを追求している結果であるともいえると思いますが、同 時に上流設計を軽視している結果でもあるのではないでしょうか。 「成田空港につきました。・・・空港はとても静かでした、人はあまりいないかもしれないと思った んですが、ちょっとよく見るとたくさん人がいました。でも全然うるさくないんです。それを見てびっ くりしました」「皆さんは、仕事をしながら全然話していません。昼食と夕食のきゅうけいの時だけ はなしています」 インドの人は一般によく、話しをします。 「日本人を見ていいことをたくさん習いました。一つ目は年上の人を尊敬することです。二つ目 は時間はいつも戻らないので、時間を無駄にしないで使うことです。三つ目はいつも仕事を神様 とおなじように考えることです。英語でそれを“WORK IS GOD”と言います。そのように考えたら, 自分の国の困窮がなくなると思います。」 “日本が経済的に発展したのは日本人がよく働いた結果だ“という考え方を多くのインド人がし ているようです。また多くのインド人がインドを発展させ、困窮をなくしたいという強い思いを抱い ているように思います。 37 ２ 日本についてのイメージ 「日本は小さい島国で、じしんや火山で有名です。それと、広島と長崎のげんばくの話しです」 「何といっても日本経済はインドよりいいので、母国の経済を同じようにしたいです。」 「昔から私は日本が大好きでした。とくに日本の電気製品は大好き」 多くのインド人は日本(人)に一般に好感を持っています。 ３ 日本人の日本語について 「日本人は日本語だけで話していると聞いたけど、どんな理由でそうするのか今でも私はよく分 かりません。私が思ったのは、日本人は母国に大きい尊敬をしています。インド人は色々な問 題で母語の代わりに英語を優先しています・・・母国に愛情があるからこそ、なんと言っても母 語が一番すきなんだと思います。」 「日本にきてびっくりしたことは、日本の若い人はslangでしか話さないことでした」 日本人同士の間でも仲間内でしか通じない会話が多いようです。ともかく論理的なコミュニ ケーションを心がけましょう。 38 インドのソフト技術者による日本語のスピーチ（1） 次にインド人の日本語スピーチを紹介します（Wipro社 「SHINPO 2003-04」より） 。 20件ほどのスピーチのなかから、２つを抜粋ですが紹介します。数ヶ月の日本語教育によっ て、約1000字の漢字を使いこなし、通常のコミュニケーションには充分な能力を習得しているこ とがわかります。 また内容も、想像力にとみ、哲学的でもあります。インド人がいかに優秀であるかが理解でき ると思います。 39 インドのソフト技術者による日本語のスピーチ（2） ジャジーナ 私の夢 お正月の前の日、私の家に神様が来ました。神様は世界中で三人だけ選んでプレゼントをあ げようと言いました。三人の中に私もいました。神様のプレゼントは、死んだ人の中から誰か1人 だけ生き返らせてくれるということでした。これはお正月の日だけです。つまり二十四時間だけな んです。他に選ばれた人はアメリカ人と日本人でした。 アメリカ人はアブラハム・リンカーンを選びました。日本人はブッダを選びました。私は選ぶ前 に考えました。アメリカ人は政治家を選んだから私もそうしようと思って,私の国の自由のために 戦ってくれたガンディーを選ぼうと考えました。でももしガンディーを選んだら、今のインドを見て 心配するかもしれないと思って止めました。日本人は宗教の人を選んだから、私もキリストを選 ぼうと思いました。でもキリストはこの世界を見て、せっかく重い苦しみから助けた人が戦争など の悪いことをしていると思ってこの世界を壊してしまうかもしれません。だからこの人も止めまし た。それで最後に私のひいおばあさんを頼もうと思いました。 私の母と兄弟は私によく話してくれました。その人はとても面白い人だったそうです。子供と一 緒に歌を歌ったり踊りを踊ったりするのと料理を作るのが上手だったそうです。だからおばあさ んが来たらいいと思って神様にお願いしました。 出てきたおばあさんは初め私が分かりませんでした。おばあさんは95歳の時死に、そのとき私 は3歳でした。私は写真を見たことがあるから分かりましたが。おばあさんは若くてきれいでした。 私がおばあさんに「ジャジーナと申します」と自己紹介をするとおばあさんは私を見てうれしそ うな顔をしました。 40 インドのソフト技術者による日本語のスピーチ（3） インドとパキスタンが一つの国になったらどうなりますか？ インドとパキスタンが一つの国になったらどうなりますか？これは皆さんはちょっと無理だと思 うかもしれません。でも時々私はそう思います。 まず本当に一つの国になったら人びとの最初の質問は“名前はどうしましょうか？”と聞くかも しれません。名前について私ははっきりかんがえていませんけど、南アジアはどうですか？そう でなければインドパクはどうですか？イギリス人が来る前に、インドとパキスタンとバングラデ シュは全部でバラツ（Bharath）でした。その名前は同ですか。 ・・・・・・・・・・ 昔パキスタンから引っ越した人は今もインドに住んでいます。でも親戚が皆パキスタンにいま すから、お互いに会うのは大変です。それに今パキスタンに住んでいるインド人も同じです。例 えばパキスタンのムシャラフだいとうりょうの親戚は今もインドに住んでいるからです。 最後にインド人とパキスタン人は一緒に住むとたくさんいいことがあると私は思います。それは ゆめみたいな話しですけど将来多分本当になったらいいと皆さんも思いませんか？ 41 インドの文化概要 １ 多民族 ２ 多言語 ３ 宗教 ４ 身分制 ５ インド人の名前 ６ 国民性 ７ 食事 ８ インフラ （１）通信 （２）電力 （３）水道 ８ 技術者の人件費 ： 日本人に似た容貌をもつネパールに近い地方の人々から、アー リア人まで、多種、多様な人種の国。 ： インドは多言語国家で、一番使用されているヒンズー語でも通じ ない地方も多い。ヒンズー語はアーリア系なのでドイツ語と共通 の文法をもつ。 共通言語のなかでは全国で英語が一番共通性をもっている。 ： ヒンズー教が大多数、イスラム教、キリスト教、仏教 ヒンズー教では牛、猿などは神聖な動物 お釈迦様はヒンズー教でも神様の生まれ変わりの1人。 ちなみにキリストはイスラム教でも預言者の1人。 ： カースト制度は廃止となった。しかしまだ遺制が残っている。 ： 北部は西洋人と同様、南部は父親の名前と自分の名前 ： 一般に穏健。宗教が関係しない殺人事件はまれ。 ： ベジタリアンが多い（最近激減しているが、それでも約半数）。 ： ： ： ： ほぼ問題なくなった。 停電は日常的。ソフト会社は普通、発電設備のある建物を使用 給水時間はデリーでも数時間。普通、常備タンクの水を使用 会社のコストはソフト技術者あたり年間、初級者＄20000、 中級＄60000 程度。 42 インドと中国とソフト開発の相違（１） インドと中国とでは次のような文化的、技術的、社会的な相違が認められる。 １ 設計コスト 一般的に インド＄25－40/H程度？ 中国＄20/H程度？ とややインドの方が高い。 地域や出身大学などにより水準は大幅に異なる。 ２ 技術領域 インド ： 通信、情報処理が強い。技術者は技術志向が強い。 中国 ： 民生用製品用制御に強い。技術者でもビジネス志向が強い。 ３ ソフト品質 インド ： CMMレベル５取得会社も多く、一般に水準が高い。日本より仕組みはよいが実 際の運用レベルはそれほどでもないこともあれる。 中国 ： 日本の品質管理システムを中国にそのまま持ち込んでいるところも多い。そうで ないところでは仕組みはあまり整備されていない。 43 インドと中国とソフト開発の相違（２） ４ 日本人とのコミュニケーション インド ： 日本語によるインターフェースは一般には容易ではない。しかしインドに精通した 代理店をもつソフト会社や日本語の堪能な技術者がいるソフト会社も多い。英語によるコ ミュニケーションは全く問題がない。なおタミール語は日本語と共通性があり、タミール出 身者は日本語の理解がはやい。 中国 ： 日本語によるインターフェースが可能なソフト会社あり。ただし一般のソフト会社 は日本語はもちろん英語によるコミュニケーションにも難がある。日本への留学経験者も 多く、日本語の堪能な技術者や日本語通訳が日本との橋渡ししている会社も多い。 ５ 知的財産権 インド ： 最近、ソフトの知的財産としての認識、法的扱いが整備された。 中国 ： 以前よりは知的財産についての扱いは改善された。しかし、まだ不十分のように 見える。 44