2016年年明けから、自分の仕事が大きく変わりました。
これまで対日本人への旅行ECサービス担当だったのが、外国人向けの旅行ECサービス担当となったのです。
また、関わるエンジニアや事業部のメンバーも日本人ではない人たちが増えました。

年明けから数か月、「グローバル化するサービスとオフショア開発環境の中で、webディレクターができることってなんなんだろう？」と模索をする中で、少しずつ見えてきたものがあったので記録にのこしておこうと思います。

まずは前編、グローバル化する開発環境とサービスの中でwebディレクターが悩んできたこと編。

前提条件

私：海外事業に携わるには弱い英語力。。

「仕事や海外で最低限のコミュニケーションがとれる」700点にはまっったく及ばないレベル。
学生時代英語は超苦手で一番足をひっぱっていました。特にリスニング。今もかわらねえ。

現在の開発の環境：ベトナム人エンジニアと関わることが一番多い

・通常会議では日本語が相当できるコミュニケーターおよびプロマネ（ベトナム人）がはいってくれる
・とはいえチャットやRemineのチケットでは、ベトナム人現場エンジニアと直接やりとりするので英語。英語でチケット書くのは日本語の2倍以上かかるぜハハハ！
・事業部側でデザイン依頼をしてくるメンバーは、日本人もいれば、日本語ができる他国籍メンバーもいる（アジア系中心）。

webディレクターとして抱えていた悩み

悩みは大きくくくると以下3点。

1:重要な要件のすりあわせがうまくいっておらず、手戻りが多発しやすい状況をどう解決するか？
2:細かい指示をだしすぎて、エンジニアの考える余地を奪っていないか？
3:ユーザー像はプロジェクトの皆で一貫しているのか？

1:重要な要件のすりあわせがうまくいっておらず、手戻りが多発しやすい状況をどう解決するか？

ベトナム人プロマネとすりあわせたものが、実はすりあってなくて、気づくのが受入テスト→手戻り多数ということがよくおきていました。

例えばECの肝の『金関係』。旅行業は特にここのお金関係の処理が複雑で、苦戦する部分です。またユーザーがトラブルにまきこまれるのがもっとも多いのもここ。
例えばUIを考えるときにこんな問題があります。

などなど。UI的に地味な割に超大変で超大事な部分です。

旅行業独自の商習慣、さらにグローバル化にともなうサプライヤーの多様化。
正直、日本人の間でもすり合わせるのが大変で、毎度最後まで泥沼化します。
対海外ならさらに難易度は上がります。

ここをどう手戻り少なく全体の認識をあわせていくか？が一番課題に感じていた部分でした。
必須の機能要件スムーズに解決しないことには、ユーザビリティの向上、ユーザーリサーチに伴うさらなる機能ブラッシュアップなんてできないのですよおうううう！！

2:細かい指示をだしすぎて、エンジニアの考える余地を奪っていないか？

上記の「重要な要件のすりあわせ」のために、現在のプロジェクトでは、画面の以下項目をすべて洗い出し、Excelでドキュメント化して伝えるという手法をとっていました。

• UIパーツ名
• どのようなときに表示するか(デフォルト表示/非表示、どんなロジックで表示するか、必須入力か)
• アクション時の挙動
• 議論がすすんで要件変更となった場合、その変更記録と理由を記載

それでも足りない部分は相応にあり、以下手法で補っています。

• アクション時の挙動について、1要素を変更すると一斉に画面内の挙動がかわる部分・グラフィカルで言語化しづらい部分（地図等）に際しては、ドキュメントに加えInvisionでプロトタイプを作成しました。
• 特に金関係、規約関係は別途詳細のドキュメントを作成。ユーザーの状況別のだしわけのパターンを整理し、何をどのような考え方でだすべきかを記載しました。
• また、こうした部分は重点的に会議をひらいて、ベトナム人エンジニアが来日しているタイミングにぶっこんだり、厳しくても画面共有しながら2時間以上質疑応答するなど、すりあわせには時間を投入。
• 毎日ベトナム人エンジニアとQAをつぶす朝MTG（スカイプ）を実施

ただ、私が伝達をやればやるほど、「一方的に仕様を押し付けているだけになってないか？エンジニア側が『いわれたものをつくるだけの人』になってしまう環境を自分が生み出してしまっているのでは？」と不安になることもしばしばでした。

また、そもそも資料が読まれていないということもあります・・・。
資料Aに「詳しいことは資料Bに描いた、ファイルのパスは～・・・」とかいても、見られていないことも。
うう、どうすべきなのか。

3:ユーザー像はプロジェクトの皆で一貫しているのか？

今回、プロジェクト立ち上げ時、定量データ/定性データフルに活用→ユーザー要求事項の可視化をしてストーリーボードを作成していました。

↑弊社採用ページにある写真。後ろが壁一面使ったストーリーボード。なお壁は勝手に占拠。

日本ではこの壁にストーリーボード作戦はやってよかったなーと思う作戦でした。
ビジネス背景・ユーザー像・ユーザー要求事項が明示されてるので、しゃべるのが苦手な自分でもどうにかなるのです。
デザイナーやコーダーと画面設計を考えるとき、新しくプロジェクトにはいった人へ内容説明するとき、社長へプレゼンするとき。どれもとっても楽でした。

指針が可視化され、全体が見えやすいおかげで「わかりやすい」といってもらえたし、何より一貫したユーザー像をもとに議論をすすめることができたのです。

でも、当然ながら、ベトナムでは日本にあるストーリーボードを見ることはできません。
「一方的に仕様を押し付けているだけになってないか？エンジニア側が『いわれたものをつくるだけの人』になってしまう環境を自分が生み出してしまっているのでは？」という不安と合わせて「一緒にユーザーについて議論ができるようになって、要件検討できるようになったらいいなあ」という願いも持つようになりました。

もちろん、ビジネス的な背景やサイトの全容は、エンジニアである上長や、現地のプロマネがエンジニアに説明はしてくれているんだけど。
UIを見てくれるユーザー像・ユーザー要求事項は、デザインを統括する自分が語り、かつチームで統一するよう動くべき最たる分野だと考えています。

そのユーザー像を伝えることで、判断材料が少しでもふえていってほしい。
グローバル対応のサイトなので、日本人がターゲットでない以上、自分以外の感覚をいれて考えていくのが絶対必要なわけで。

「ベトナム側エンジニアに伝えたら全体像がみえるのでは？」「一貫したユーザー像をもとに議論ができやすくなるのでは？」
すぐすぐできることではないんだけど、ユーザー目線で一緒にサービスを作るという土台を、少しずつ組み上げていく必要があると考えていました。

——

ひとことでまとめれば「旅行ECとして機能必須要件すりあわせに時間や工数かけてるけど。もっとユーザー目線で考える時間や工数増やして、ユーザビリティ・売上あげたい、チームで事業貢献したい！webディレクターとして、今私はどうすればいいんだろう？」という問い。

幸い、ベトナム出張にいかせてもらえることになったので。
「自分のプロジェクトの在り方をもう少し考えてみよう。」
そう思い、情報デザインフォーラムをぬけて、成田空港に向かいました。

というわけでベトナムにいっていろいろ考えたことは後編で。
【後編】グローバル化するサービスとオフショア開発環境の中で、webディレクターができること　～ベトナムで私も考えた編～