私は非エンジニアですが、『売れるD2Cつくーる』の新機能や改修のリリースを担当しています。
今回の記事ではこれまでの経験から、「非エンジニアの開発担当」が、共通言語がない状態でプログラマー・外注・オフショアのエンジニアと関わりながらシステム開発するとどうなるのか？など、実際にあった事例とともに“コツ”をご紹介します。
Tôi không phải là một kỹ sư, nhưng tôi đang phụ trách việc release (phát hành) các tính năng mới và cải thiến cho hệ thống “売れるD2Cつくーる”.
Trong bài viết này, tôi sẽ giới thiệu cho các bạn bí quyết dựa trên kinh nghiệm thực tiễn mà tôi đã tích luỹ được khi tham gia vào việc phát triển dự án với tư cách là “ người phụ trách phát triển nhưng non-technical”, bao gồm việc làm thế nào để giao tiếp với lập trình viên, nhà phát triển thuê ngoài hoặc kỹ sư ở phía offshore nhưng lại không có ngôn ngữ chung.
Việc phát triển hệ thống chính là trò chơi truyền tải thông điệp
日本語は主語や目的語がなくても成り立ってしまう言語です。私たちは日本語を話すうえで前後の文脈や、相手のしぐさや表情を見て自然と読み取って解釈しています。
例えば、「大丈夫」にはOKとNGの意味が含まれます。実際に「大丈夫です」と答えた際に意図しない開発が進み、無駄な時間を使ってしまった経験があります。
ECのシステム開発では、現場のユーザー（消費者であるお客様や広告主）が抱えている課題をエンジニアに的確に伝える必要があります。外注やオフショア開発はブリッジエンジニアやコミュニケーター（通訳）を介してエンジニアに伝える伝言ゲームですので、誰がどう聞いても同じ意味で受け取ってもらえるように伝えることが必要です。
「大丈夫＝OK」という意味で伝えたい場合は、
・認識齟齬ありません。
・はい、開発を進めてください。
「大丈夫＝NG」という意味で伝えたい場合は、
・いいえ、対応不要です。
・検討して追って指示します。
などと、YES・NOの回答に加え、次の行動も回答することでさらに相手に伝わりやすくなります。
・分かりました
エンジニア／コミュニケーター：で、どうしたいですか？
POINT
分かりました、進めてください。など「大丈夫」と同様に次の動作も伝えましょう。
・AとB
エンジニア／コミュニケーター：andですか？orですか？
POINT
「AとB」や「A・B」と伝える場合、日本語ではなくandやorをあえて使いましょう。
・～以外
もはや質問さえなく、意図しない開発となる可能性が高いです。
POINT
「C以外を赤文字にしてください」と伝えた場合「AとBだよね！」と勝手な解釈で開発が進む可能性があります。
文字色の変更は例え話で、実際の開発ではもっと規模が大きなものになります。納品されたときに発覚すると修正を加えるもの時間がかかります。そのため、「C以外＝A/B/D/E」と置き換えて表現できるときは、必ず置き換えた方で伝えましょう。
Tiếng nhật là loại ngôn ngữ dù không có chủ ngữ hoặc tân ngữ vẫn cấu thành một câu hoàn chỉnh. Chúng ta thường đọc và lý giải được ý của người nói dựa trên ngữ cảnh và cử chỉ, điệu bộ của đối phương.
Ví dụ, từ “大丈夫” (không sao đâu) có thể mang ý nghĩa là “OK” hoặc “NG”. Tôi đã từng gặp trường hợp khi bên kia trả lời là “大丈夫” (không sao đâu) nhưng lại dẫn đến việc phát triển không đúng hướng và gây lãng phí thời gian.
Trong quá trình phát triển hệ thống EC, việc truyền đạt chính xác các vấn đề mà người dùng thực tế đang gặp phải (ví dụ như khách hàng là người tiêu thụ) là rất quan trọng. Khi làm việc với các công ty thuê ngoài, hoặc phát triển offshore đòi hỏi phải thông qua Bridge engineer hoặc communicator (thông dịch viên), vì vậy bạn cần phải truyền đạt sao cho bất cứ ai nghe đều hiểu cùng một nội dung như nhau.
Nếu bạn muốn truyền đạt từ “大丈夫” theo mặt nghĩa là “OK”, bạn có thể nói như sau:
・認識齟齬ありません。(anh hiểu đúng rồi)
・はい、開発を進めてください。(vâng, cứ tiến hành phát triển theo hướng như vậy đi)
Còn nếu bạn muốn nói dùng từ “大丈夫” theo mặt nghĩa là “NG”, bạn sẽ nói là:
・いいえ、対応不要です。(Không cần đối ứng)
・検討して追って指示します。(Để tôi xem xét lại rồi tôi sẽ chỉ thị sau)
その他にも、実際に伝わらなかった日本語をお教えします。
Bên cạnh đó, tôi cũng muốn chia sẻ với bạn những ví dụ tiếng Nhật mà thường gặp khó khăn trong việc truyền đạt.
・分かりました/Tôi hiểu rồi
Engineer／Communicator：Ủa, nếu khách trả lời vậy rồi rốt cuộc điều khách muốn là gì thì họ không nói
POINT
Thay vì đó hãy nói là “分かりました、進めてください” (à chúng tôi đã nắm được vấn đề rồi. Vậy team cứ xúc tiến theo hướng như vậy nhé) .
・AとB/ A và B
Engineer／Communicator：vậy là and ? hay là or đây?
POINT
Nếu bạn muốn truyền đạt là “A và B” hoặc “A・B”, hãy dùng “and” và “or” thay vì nói tiếng nhật
(Vì như thế đối phương sẽ rất hiểu là bạn đang muốn tiến hành cả A và B, hay là bạn muốn đối phương chọn 1 hướng trong 2 hướng mà bạn đã đề xuất chẳng hạn)
・～以外/Ngoài ra, không phải
Nếu nói như thế này thì người nghe sẽ không dám hỏi lại và có khả năng cao là sẽ phát triển theo nội dung khác với ý đồ mà người nói mong muốn.
POINT
Nếu bạn nói “C以外を赤文字にしてください” (Hãy làm cho những thứ không phải là C thành màu đỏ) thì có khả nănng người nghe sẽ hiểu là “à vậy tức là A và B sẽ được set màu đỏ, còn C là kông đối ứng” và khả năng cao họ sẽ phát triển theo nhận thức mà họ cho là đúng.
Việc thay đổi màu sắc của chữ là một ví dụ, trong thực tế, quy mô của việc phát triển thường lớn hơn nhiều. Nếu phát hiện khi giao hàng thì việc sửa chữa sẽ mất thời gian. Do đó, khi bạn có thể thay thế bằng cách biểu thị "C以外＝A/B/D/E" thì sẽ dễ hiểu hơn.
Việc báo bug phát sinh một cách chi tiết sẽ giúp việc fix bug nhanh chóng hơn
「エラーが起こってます！不具合かもしれません！調査できますか？」と伝えた場合、相手にはこのような規模で伝わっています。
「窓が壊れています！場所はスカイツリーです！修理できますか？」
この場合、エンジニアからは「わかりません。確認できませんでした」と回答されてしまい、欲しい回答まで遠回りしてしまいます。
システム開発は伝言ゲームですので、「あ！あのことね！」と、汲んでくれることは一切ないと考えましょう。汲んでくれたとしても正解とは限りません。そのため、窓で例えると、場所と詳細な位置情報を伝えることが重要となります。
「窓に亀裂が入っています。スカイツリーの1階。テナント『まきせ商店』の西側。窓に向かって左から3つ目の右下。段ボールが置いてあるので一度、段ボールをずらして確認してください。」
不具合の場合も一緒です。誰が見聞きしても特定できる情報を渡してあげることが重要です。
例えばこのように伝えると、エンジニア側も再現することができ解決が早くなります。
Khi bạn truyền đạt cho đối phương là
エラーが起こってます！Có lỗi phát sinh
不具合かもしれません！Có lẽ là bug
調査できますか？Có thể điều tra được không?
Đối phương sẽ hiểu về phạm vi vấn đề như sau:
"Cửa sổ bị hỏng! Địa điểm là Tháp Skytree! Bạn có thể sửa chữa được không?”
Trong tình huống này, phía kỹ sư sẽ trả lời là “tôi không biết và tôi cũng không thể xác nhận”, và kết cuộc là phải đi vòng vo mãi mới suy ra được câu trả lời mà bạn muốn.
Việc phát triển hệ thống cũng giống như trò chơi truyền tin, vì vậy nếu bạn cứ nói “à cái này nè” thì người nghe sẽ không hiểu được cái bạn đang muốn là gì. Thậm chí ngay cả khi họ hiểu cũng chưa chắc là đúng. Do đó, trong ví dụ về cửa sổ, việc cung cấp địa điểm và thông tin chi tiết về vị trí rất quan trọng.
“窓に亀裂が入っています。スカイツリーの1階。テナント『まきせ商店』の西側。窓に向かって左から3つ目の右下。段ボールが置いてあるので一度、段ボールをずらして確認してください。”
(Ở phía trên cửa sổ có vết nứt. Tầng 1 của Tháp Skytree. Phía tây của cửa hàng 'Cửa hàng Maki'. Là cửa sổ thứ 3 từ bên trái xuống và bên dưới. Có một thùng carton đặt ở đó, vui lòng di chuyển thùng để kiểm tra.)
Trường hợp phát sinh bug cũng tương tự. Điều quan trọng là bạn cần phải cung cấp bất kỳ thông tin mà ai nghe thấy cũng hiểu được vấn đề.
概要
まきせpayで購入すると完了画面遷移中に500エラーとなる。
再現可能URL
https://www.***
再現方法
１. 1円以上の商品ページを作成（PC・SPどちらでも可）
２. 支払方法にまきせpayを設定
３. まきせpayを選択し確認ページに遷移する
４. 確認ページの申込確定ボタンをクリックする
５. 完了画面が表示されず500エラーとなる
このように箇条書きで伝えることで、エンジニアからの回答は「再現できました。原因調査を開始します」と最短で解決の道をたどることができます。さらに、エラー画面のキャプチャや再現動画を共有することでより伝わりやすくなります。
Tổng quan
Khi mua hàng qua makipay, khi di chuyển tới màn hình hoàn tất mua hàng thì phát sinh lỗi 500.
URL tái hiện
https://www.***
Cách tái hiện
- Tạo page sản phẩm với giá trị 1 yen trở lên (có thể tạo trên PC or SP).
- Thiết lập makiPay là phương thức thanh toán.
- Chọn makiPay và redirect đến trang xác nhận.
- Nhấp vào nút xác nhận đăng ký trên trang xác nhận.
- Màn hình hoàn tất không hiển thị mà thay vào đó hiển thị lỗi 500.
Thông qua việc trình bày dưới dạng gạch đầu dòng như trên, phía kỹ sư sẽ trả lời là “chúng tôi đã tái hiện được bug phát sinh. Bây giờ chúng tôi sẽ start điều tra nguyên nhân” và giúp rút ngắn cách giải quyết vấn đề. Hơn nữa, việc chia sẻ hình chụp màn hình lỗi hoặc video tái hiện sẽ giúp truyền tải vấn đề một cách dễ hiểu hơn.
Tầm quan trọng trong mối quan hệ giữa Bridge engineer và Communicator trong việc phát triển offshore
オフショア開発をするにあたって、ブリッジエンジニアやコミュニケーター（通訳）を介して業務を遂行することのほうが多いと思います。ブリッジエンジニアやコミュニケーター（通訳）は、日本と現地のエンジニアとのコミュニケーションを円滑に進める役割を担っています。
ブリッジエンジニアとコミュニケーター（通訳）の大きな違いは、「システムエンジニアとしての開発スキルを持っている方」と「開発スキルを持っていない方」になりますが、コミュニケーター（通訳）さんの中にも多少のエンジニアリングを理解している方とまったく素人に近い方がいます。まずは、担当の方がどのようなスキルを持った方なのか理解しましょう。
そして、コミュニケーター（通訳）に対し「これくらい分かったうえで翻訳してよ！」という意識は捨てましょう。
もちろん、開発知識がないコミュニケーター（通訳）だったとしても、担当するサービスや機能の知識は日々勉強してくれています。
しかし……あくまでもコミュニケーター（通訳）は通訳することが仕事ですので、「この機能ありきで質問したんですけど」「仕様を伝えたうえでの回答ですか？」など、「知っているだろう」「わかっているだろう」という発言は絶対にやめましょう。
コミュニケーター（通訳）に「言わなくても分かってほしい」は自分勝手なショートカットです。
もちろん、過去の経験や担当者の言い回しの癖を補足して翻訳してくれることもありますが、書いていないことを翻訳することでエンジニアからも「どこに書いてある？」などとコミュニケーター（通訳）が板挟みになる可能性があります。
何度も言いますが、コミュニケーター（通訳）はあくまでも通訳することが仕事なので、質問や指示に前提条件や目的がある場合は、「このシステムの仕様は〇〇だと思っています。そこで、この質問をしています。」など、前置きを省かずに“わざわざ”伝えることを意識しましょう。そうすることで翻訳の精度も上がりますし、エンジニアとの認識のずれが明確になり一石二鳥です。
Khi thực hiện phát triển offshore, có nhiều trường hợp công việc được thực hiện thông qua bridge engineer hoặc communicator (thông dịch viên). Những người này đóng vai trò quan trọng trong việc giao tiếp trơn tru giữa kỹ sư tại Nhật và kỹ sư offshore.
Sự khác biệt lớn giữa bridge engineer và communicator là một bên là "người có kỹ năng phát triển như một kỹ sư hệ thống" (mình hay gọi là có technical) và bên kia là "người không có kỹ năng phát triển" (non-technical). Tuy nhiên, trong số những người thông dịch, có người hiểu một chút về kỹ thuật và cũng có người hoàn toàn không biết gì về nó. Đầu tiên, hãy hiểu rõ kỹ năng mà người đảm nhiệm công việc đang có.
Và, hãy dừng ngay cái suy nghĩ kiểu như "hãy dịch tương đối” đối với communicator.
Dĩ nhiên, ngay cả khi communicator không có kiến thức về technical, họ cũng đang học hỏi về kiến thức về dịch vụ hoặc chức năng mà họ đang làm hàng ngày.
Tuy nhiên... communicator cuối cùng vẫn là người làm công việc dịch thuật, vì vậy hãy ngưng nói những câu vô tri như là “biết rồi còn hỏi” đối với những câu xác nhận "Tôi đã log Q&A dựa trên chức năng này rồi mà", “có phải đây là câu trả lời dựa trên spec đúng không?”…
Bạn muốn comtor phải hiểu mà bạn không cần phải trình bày, giải thích này nọ chẳng khác gì một sự ích kỷ trong lối tiếp cận giao tiếp của bạn.
Lưu ý rằng công việc của communicator chỉ là dịch thuật, vì vậy nếu có điều kiện tiên quyết hoặc mục đích đằng sau câu hỏi hoặc chỉ thị, hãy truyền đạt rõ ràng, chẳng hạn như "Tôi cho rằng spec của hệ thống này là 〇〇. Vì vậy, tôi đã đặt câu hỏi này. ". Việc này không chỉ làm tăng độ chính xác của việc dịch mà còn làm rõ sự khác biệt về nhận thức giữa người thông dịch và kỹ sư, đạt được cả hai mục tiêu một lúc.