webディレクターの阿呆な研究

Read Article

【前編】グローバル化するサービスとオフショア開発環境の中で、webディレクターができること ~現場の悩み編~

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

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

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

前提条件

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

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

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

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

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

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

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

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

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

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

(1)GROSS(全体価格)を構成するものが商材によって異なる

券面、宿泊料、税金、手数料、付加運賃、割引は何があるか?航空券、ホテル、ツアー、船舶、高速バスなど商材によって全く違うのです・・・。

例えば燃油サーチャージ(特別付加運賃)。多くの航空会社は券面に燃油サーチャージが含まれていませんが、マレーシア航空の券面は燃油サーチャージ込となります。また、海外航空券では券面に燃油サーチャージが含まれていないJALやANAも、国内線の券面は燃油サーチャージ込。

毎度料金表つくるときにはゲロ吐きそうです。
料金表要件定まったときの達成感はんぱない。超地味な作業なんだけども!!

(2)サプライヤーによってパターンの把握が必要となる

航空会社やホテルのサプライヤーよって異なる『券面、宿泊料、税金、手数料、付加運賃、割引』は何があり、どんなパターンが存在するのか?が必要です。

さらに海外サプライヤーの商品を販売していることが多いので、キャンセル料規定等『海外時間』での記載があるのも落とし穴。ユーザーとサプライヤーのタイムゾーンに差がある場合、どういうロジックでユーザーに見せるとユーザーが混乱せずすむか?いつも悩まされます。

(3)事前決済か、現地決済が及ぼす影響の把握が必要となる

事前決済時に支払うもの、現地支払いが発生する可能性があるものは何か?の把握も必要です。

例えばホテルでは事前決済だけどリゾート税だけは現地で、というのもザラにあります。ユーザーの「そんなのきいてない」が発生やすいパターン。

また、事前決済では円で決済できるけど、現地決済だと現地通貨になるなどのパターンも。
加えて、適用される契約形態も『ユーザーと旅行会社』なのか『ユーザーとホテル』なのかも、決済方法でかわってきたり。
契約形態がかわれば、キャンセル条件も当然かわります。

カスタマーセンターとの連携して要件検討したり、テストは綿密にやったりと、時間をかけてユーザーがトラブルにあわないようすりあわせをしている部分です。

(4)商習慣や決済方法にともなう事情の把握と、その事情を勘案した要件定義&UI設計が必要

割引が存在する場合、それは何から引かれるものか?GROSSからひいてよいのか?・・・といった、商習慣や決済方法にともなうだしわけの把握もあります。
一部の商材や決済方法によってはGROSSからひくのではなく、明示的にこの項目からひくようにみせるというものもあります。もうここまでくると相当マニアック。

(5)取得レートによるキャンセル後の処理の検討が必要

取得レートによっては、キャンセル後の対応で返金できる/返金できないパターンが様々発生します。

例えばパッケージレートとよばれるセットでの割引適用(いわゆる「セットで安い」てやつです)。
航空券とホテルを予約し片方キャンセルした場合、「割引価格は消滅するか、残すのか?返金処理はどのように行うか?手数料はどうするか?」など、要件定義やだしわけ、テストが相当大変となります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

——

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

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

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

URL :
TRACKBACK URL :

Leave a Reply

*
* (公開されません)
*

Facebookでコメント

Return Top