私は非エンジニアですが、『売れるD2Cつくーる』の新機能や改修のリリースを担当しています。

今回の記事ではこれまでの経験から、「非エンジニアの開発担当」が、共通言語がない状態でプログラマー・外注・オフショアのエンジニアと関わりながらシステム開発するとどうなるのか？など、実際にあった事例とともに“コツ”をご紹介します。

システム開発は伝言ゲーム

日本語は主語や目的語がなくても成り立ってしまう言語です。私たちは日本語を話すうえで前後の文脈や、相手のしぐさや表情を見て自然と読み取って解釈しています。

例えば、「大丈夫」には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」と置き換えて表現できるときは、必ず置き換えた方で伝えましょう。

不具合は詳細に伝えるほど解決が早い

「エラーが起こってます！不具合かもしれません！調査できますか？」と伝えた場合、相手にはこのような規模で伝わっています。

「窓が壊れています！場所はスカイツリーです！修理できますか？」

この場合、エンジニアからは「わかりません。確認できませんでした」と回答されてしまい、欲しい回答まで遠回りしてしまいます。

システム開発は伝言ゲームですので、「あ！あのことね！」と、汲んでくれることは一切ないと考えましょう。汲んでくれたとしても正解とは限りません。そのため、窓で例えると、場所と詳細な位置情報を伝えることが重要となります。

「窓に亀裂が入っています。スカイツリーの1階。テナント『まきせ商店』の西側。窓に向かって左から3つ目の右下。段ボールが置いてあるので一度、段ボールをずらして確認してください。」

不具合の場合も一緒です。誰が見聞きしても特定できる情報を渡してあげることが重要です。

例えばこのように伝えると、エンジニア側も再現することができ解決が早くなります。

概要
まきせpayで購入すると完了画面遷移中に500エラーとなる。

再現可能URL
https://www.***

再現方法
１. 1円以上の商品ページを作成（PC・SPどちらでも可）
２. 支払方法にまきせpayを設定
３. まきせpayを選択し確認ページに遷移する
４. 確認ページの申込確定ボタンをクリックする
５. 完了画面が表示されず500エラーとなる

このように箇条書きで伝えることで、エンジニアからの回答は「再現できました。原因調査を開始します」と最短で解決の道をたどることができます。さらに、エラー画面のキャプチャや再現動画を共有することでより伝わりやすくなります。

オフショア開発ではブリッジエンジニアやコミュニケーター（通訳）との関係性が重要！

オフショア開発をするにあたって、ブリッジエンジニアやコミュニケーター（通訳）を介して業務を遂行することのほうが多いと思います。ブリッジエンジニアやコミュニケーター（通訳）は、日本と現地のエンジニアとのコミュニケーションを円滑に進める役割を担っています。

ブリッジエンジニアとコミュニケーター（通訳）の大きな違いは、「システムエンジニアとしての開発スキルを持っている方」と「開発スキルを持っていない方」になりますが、コミュニケーター（通訳）さんの中にも多少のエンジニアリングを理解している方とまったく素人に近い方がいます。まずは、担当の方がどのようなスキルを持った方なのか理解しましょう。

そして、コミュニケーター（通訳）に対し「これくらい分かったうえで翻訳してよ！」という意識は捨てましょう。

もちろん、開発知識がないコミュニケーター（通訳）だったとしても、担当するサービスや機能の知識は日々勉強してくれています。

しかし……あくまでもコミュニケーター（通訳）は通訳することが仕事ですので、「この機能ありきで質問したんですけど」「仕様を伝えたうえでの回答ですか？」など、「知っているだろう」「わかっているだろう」という発言は絶対にやめましょう。

コミュニケーター（通訳）に「言わなくても分かってほしい」は自分勝手なショートカットです。

もちろん、過去の経験や担当者の言い回しの癖を補足して翻訳してくれることもありますが、書いていないことを翻訳することでエンジニアからも「どこに書いてある？」などとコミュニケーター（通訳）が板挟みになる可能性があります。

何度も言いますが、コミュニケーター（通訳）はあくまでも通訳することが仕事なので、質問や指示に前提条件や目的がある場合は、「このシステムの仕様は〇〇だと思っています。そこで、この質問をしています。」など、前置きを省かずに“わざわざ”伝えることを意識しましょう。そうすることで翻訳の精度も上がりますし、エンジニアとの認識のずれが明確になり一石二鳥です。

おわりに

いかがでしたでしょうか。非エンジニアの開発担当がまず直面するのが共通言語の壁です。

ユーザーと、ビジネスサイドやエンジニアとでの共通言語がありません。同じ日本人でも同じ言葉を理解するとは限りません。ビジネス的な背景を理解していない外注エンジニアの方であればなおさらです。

さらに、海外の方に発注するオフショア開発では文字通り言語の壁が存在します。日本語には曖昧な言葉があるので、そういった言葉たちを極力使わないようにすることから意識してほしいです。簡潔で、やさしい日本語。長文より短文の方が伝わりやすいです。

★売れるネット広告社HP★
https://www.ureru.co.jp/