僕のノート、見てってください

エンジニアリングや英語、趣味について徒然なるままに

とある上場企業のモバイルゲーム開発の流れ

エピソード ゲーム開発 開発

自分の仕事を人に話す練習として、また経験を一つ書き起こそうと思います。
話を聞かせる相手として想定するのは、全く畑の違う業界の人、生産業の方、何らかの教授をイメージして
なるべく好奇心を掻き立てる、興味を抱いてもらえるようなタネを埋め込むよう努力して見ます。

ということで、モバイル/スマホゲーム開発の流れについて
30分くらいで書けるだけ書いてみます。

ゲーム開発の流れ

  • 前提として、受託開発ではなく、自社製品の開発です。
  • 会社の体制としては、ゲーム開発プロジェクトはプロジェクト単位で所属するメンバーを束ね(project oriented)、
    広告、ミドルウェア管理は横断部署として存在、
    デザイナーは所属部署がありつつ、実質プロジェクトに所属し、ほぼつきっきりという状態。
項目 誰が 具体的に何をするのか 面白ポイント
プロジェクト発足 ゲーム開発部署の管理部門 - 事業面の理由からプロジェクト発足を決定。
- プロジェクトのリーダーを決定。
プロジェクト企画体制構築 プロジェクトリーダーを中心に - 管理部門から受けた基礎要件をもとに、必要なゲームプランナーやエンジニア(リーダー), デザイナーを集める。
- 以後の開発や承認フロー、ステークホルダーを事前に定める。		 - 新規立ち上げ時ほど重要な場面なので、招聘がかかるのは比較的有能なメンバー。社内的にも花形なので羨ましがられる。(特に昨今、ゲームの長寿化が進んでいるので、初期開発よりも運用に携わるメンバーの総数が圧倒的に多い)
企画開始 メンバー全員 - 競合/市場調査や未来の予測を踏まえ、儲かる x 新たなポジション のゲームを考える(目星や話の道筋を立てやすくするための制約の検討)。
- 簡単なペライチの企画書に始まり、ペーパーモックなどで検討を重ねる。		 -めっちゃ時間かけてしまいがちだし、時間がかかる気持ちもわかる。
-モック時点で面白くするのむずいけど、思えばこの時点で面白く無いと、結局面白い仕組みができてないということだと思う。
- システムとして動く形にすぐにできると、イメージが膨らみやすく話を展開しやすい。でも壊すことを躊躇う気持ちが生まれかねないので、そこは容赦無くスクラップ&ビルドする。
- ミーティングで却下、もしくは議題に挙げてないゲーム仕様を勝手に盛り込むデザイナーさんとか現れるので、機会と規律は保つ。
経過報告&承認 ゲーム開発部署の管理部門
プロジェクト		 - 決められた開発段階を卒業し、次のステップに進むにあたり承認を受けるための会議を設ける。
- 何ステップに分けて用意する。		 - 事前の期待値調整は大事。
- 偽りないポジティブなメッセージをもって管理部門をも仲間に引き込めると強い。
- 蜜月になって監査性能を潰すのはダメですが。
本開発 プロジェクト - お客さんに楽しんでもらう製品を作る。 - 過去の開発資産を使えるとやっぱり早い(けど、車輪の再発明しがち)。
- メインの遊びの部分を早く遊べる状態にし、何度も遊んでは仕様や演出の修正を重ねる。
品質担保テスト プロジェクト - 品質管理チームとともに協力して、不具合を無くし、仕様を定めきる。 - ゲームの品質管理だけを仕事にした会社もあるって、知らない人多そう。
- とあるIPの超人的な知識があったためにほぼ正社員的なポジションを手に入れた人もいたり。
- それくらいIPものの設定に関する知識は、デザインや素材監修の面で心強い(あのXXの顔の傷は、右頬じゃなくて左頬みたいな)。
社外βテスト プロジェクト&有志のユーザ - 完成したゲームを一般公開して遊んでもらう。
- このときに合わせて行うユーザの属性に関する調査データは、以降の広告戦略や事業データ分析上で超重要。		 - ゲームの面白さ自体を評価する声が大きく無い限り、結局すぐに飽きられるので要確認。
リリース プロジェクト - 一般ユーザに、β版から調整を加えた製品バージョンのゲームを公開する。 - どきどきするし、ユーザの声は嬉しいもの。
- GooglePlayやAppStoreの新着フィーチャーアプリとして取り上げられると数十万ダウンロードを期待できるものの、そうで無い場合、流入確保に多大な苦労と費用。
運用 プロジェクト - 事業データを監視しつつ、事業計画に基づき、ゲームを進化させていく。
- キャラクターの能力の上限を解放していくことでリソース価値を保ち続けるのが一つの手だが、陳腐化が前提となっており、自らの首をしめることや新規ユーザにとっての敷居をあげることにもなる。
- Cygamesとかは、面白く無い古典的なゲームをよくも広告でそれだけ売り続けるなという印象。褒めてます。		 - 運用中に、資金管理に関連する法律や制度等に変更が加わり対応を迫られることがある。
- いわゆる高額課金ユーザみたいな方もいらっしゃってありがたい話ではあったのですが、プロジェクト参画者も含め金銭感覚がずれていて、自分には居心地がよくなかったです。どうせの出費なら、家族とか恋人を喜ばすための出費に携わりたい、と。
サービス開発の一連の流れをありがたいことに十分経験させてもらえたので感謝していますが。
閉鎖 プロジェクト - 事業計画通りにことが運ばず、社内や市場環境の変化も後押ししたりで、生き残れるアプリはほんの一部です。
- ユーザにごめんなさいとありがとうをしながら、迷惑を最小限にする配慮をしながら店じまい。
- 利用規約に閉鎖時を想定した文言を含めておかないと、いざというときに結構怖いことに。		 - みんなお葬式ムードな時こそ、積極的に遺留品回収をして、組織の資産として今後に役立てるのが大事。

こんな具合です。
本開発あたりで、制限時間: 30分がせまり適当になってますが、ご愛嬌で。
多分、時間あるときにちゃんと加筆修正します。
表形式、超見にくいので、普通に章立てて目次でも置きます。
感想等ありましたら、伺えると嬉しいです。ではでは。

PMP - Project Management Professional について調べてみた

PMP

しばらく現場を離れていたので、
現場に戻るに当たって、そして少し時間があるからこそできる、
関連資格の取得を考えているのですが、
その中で白羽の矢が立ったのがPMP(Project Management Professional)です。

なぜPMP

  • プロジェクトマネジメントのプロ認定の「国際資格」 by PMI(Project Management Institute)!!!
  • よく勉強した人が分母とはいえ、60%は合格している模様なので、資格取得も現実的。
  • 日本語でも受験できるらしい。(自分は多分、英語で受験するかなぁ。もしくは日本語受験者が英文も見れたようなことを書いてたような)
  • 資格は抜きにしてもPMBOK(PMPのバイブル)は、実際に学ぶべきもののよう。
  • 受験費用$500強, 3年ごとの更新日費用が発生するものの。値する資格かと。
  • 受験日の融通がきく。

受験資格

要件 大卒以上 高卒
認定PM業務カリキュラム受講時間 35時間 35時間
PM関連業務従事期間 36ヶ月 60ヶ月
その期間中のPM関連業務従事時間 4500時間 7500時間
=>つまり1ヶ月の平均必要PM業務時間/日(21営業日計算) 5.95時間 5.95時間

※申し込みを基準に、直近8年間の経験しか申告できない。
※PM業として申告できるのは、予算/期日/要件などの制約下、もしくは上位概念となる達成目標下で、プロジェクトを牽引した経験のこと。
※PM業に携わった期間は、1年間に2プロジェクトを掛け持ちしていても、申告上は1年分としてしか申告できない。
※申告のあった経歴は、その関係者に事実確認が行われる可能性がある。

ちなみに、35時間のカリキュラム受講については、
Udemyにて$30程度でオンライン受講可能なコースが紹介されておりおすすめです！

以下、原文。

PMP Requirements Overview
To be eligible for the PMP credential, you need to meet certain requirements for professional experience and education.


Project Management Experience

On the application, you will be required to document the experience you've accrued leading and directing projects under general supervision and within the constraints of schedule, budget and scope. 

The experience should indicate you can appropriately apply an approach to managing projects that have reasonable and well-defined requirements and deliverables.


Required Experience Levels

If you hold a four-year degree or the global equivalent:

You need a minimum of 3 years (36 months) of unique, non-overlapping professional project management experience.
Within that period, you need to have led or directed the project for at least 4500 hours.
OR

If you hold a secondary degree, such as a high school diploma, two-year degree or the global equivalent:

You need a minimum of 5 years (60 months) of non-overlapping professional experience in project management.

Within that period, you need to have led or directed the project for at least 7500 hours.
All of your project management experience must have been accrued within the last 8 consecutive years before the submission of your application.


Project Management Education

You need to document at least 35 contact hours of specific instruction that addressed learning objectives in project management. One hour of classroom instruction equals one contact hour needed to meet this requirement. 

Record all of the hours that you completed regardless of when you accrued them. All reported coursework must be completed at the time of your application.

In the next few sections we will be asking you to document your work experience and education to meet the above requirements. Each project to validate your experience must be documented separately.

受験日程

以下のページの、5. Schedule Test Appointment の通り、
世界中のプロメトリック試験会場で空きを見つけて受験できる模様。

https://www.pmi.org/certifications/process

必要費用

Cost Catagory PMI® Member Non-Member
PMI® 年会費 $139 N/A
PMP 受験料 $405 $555
PMP 再受験料 $275 $375
  • PMI会員になると、受験費の割引が発生する。
    単純に初回PMP受験費用の割引分で会費のお釣りがくるので、初年度だけでも会員となるのが良いか。

備考

2018年3月26日より、新要綱でのテストとなる模様。
新要綱の範囲も習得はしたいけど、資格取るにはその前に合格しておくのが吉と思われる。
PMP Certification Exam Changes 2018 | PMI

何かのお役に立てば幸いです。
おそらく、ブログ主は今年の3月26日よりも前に、従来試験の合格を目指します。
ちょくちょく、関連する記事も掲載するかもしれないので、その際にはよろしくお願いします。

金融系企業内の役割分担(フロント？バック？ミドル？)

エピソード 金融

特に職種の異なる人に対して、自分がどんな仕事をしていたか、
興味持って聞いてもらえるだけに話すのが苦手なので、その練習も込みで
自身のエピソードや、その業種に就いたことがないと知らないような知識をたまに書き残そうと思います。

第一回の今日は、大学卒業して初めて勤めた金融コンサルで学んだことの一端をご紹介します。
ググったら出てくるものかと思いますが、自分の言葉で伝えられるようになることが目的なので悪しからず。

金融系企業内の役割分担

みなさんも聞いたことがあるかもしれませんが、
銀行や証券会社など、金融機関は大きく以下の3つの役割で部門を呼び分けています。

部門名 役割
フロントオフィス 収益を挙げる部門の総称。いわゆる、株式債権、為替の取引等を行う部門のこと。
ミドルオフィス フロントオフィスは個人の精鋭の集合体。彼らの全体感、バランス感を司るのがミドルオフィス。
所有する資産(株式や為替等)の総量を管理し、かつ、それらが未来にどの程度の確率でどういった変化をしえるのか、リスクを予測・把握し管理する部門。
バックオフィス 上記に該当しないような、法務や財務、人事などの裏方部門。

世界の金融市場

世界には、東京、ニューヨーク、ロンドンなど数多くの金融商品の取引市場があります。
それぞれ、取引時間が現地時間の日中(雑)を基準に設けられているので、
同時に全ての市場が開いていることはなく、順々に世界の市場が開いたり閉まったりします。
徐々に取引時間の拡大も進んでいますが。

そもそもフロントオフィスはどうやって儲けてるのか

世の中には、たくさんの金利があります。
高利貸しが課すのも金利。銀行が住宅ローンで課すのも金利。カイジがよく悩まされるのも金利。

単純化すると、金融機関は、この金利差を見いだすことで利益を得ています。
ただ扱う商品が、株式や債権、為替といったものが主という点は異なりますが。
株式も債権も、結局は買った金額に対して、いくらの利益がつくか利率の世界に集約できます。
利率で評価できるということは、将来もたらすだろう価値から、現在それがいくらの価値なのかを逆算できることになります。

なので、その現在あるべき価値と、実際の市場価値にずれがあるところは、つまり利鞘/損がでる場所となるのです。
賢くないとできないし、理性的な仕事なのですが、金を転がしているだけで何も生んでいないと言う人がいるのも分かります。
その人たちのおかげで、日々の生活を豊かにできている人々がいるのも事実です。
が、自分もその意義を見出せずに、その業界から離れた一人でした。

ミドルオフィスの魅力

ミドルオフィスの業務支援ソフトウェアの開発に携わっていたことがあるのですが、とても面白かった記憶があります。
金融機関に古くからあるシステムや、同時に開発をしているシステム、それらを統合する中心人物となるのがミドルオフィス向けのソフトウェア。

あのシステムではあの数値は小数点N桁まで扱っていて、あそこではあの数字はゼロ埋めM桁になっていて、
そんなシステムがいくつも連なっていて、、
といった具合で、システム間のインターフェースを整えることだけで十分に一大事業。
それを受け取って初めて、内部の計算に至れます。
(銀行内のシステムは1社で全て構成されている訳でなく、システム毎に入札?なのか複数のメーカーにより各システムで構成されています。)

ミドルオフィスでは、取り扱っている全株式や債権の終値などの情報を一気に取り込み、
資産価値を再評価し、LIBOR, TIBORといった金利データ等の要因も取り込むことで、
現在保有する資産の、統計的な安全度/リスクの程度を算出することを可能にしています。
当時は新人で、途中参加だったので根っこの部分には関われず、
システム間インターフェースのテスト設計/実施が主務でした。
なので、今思うと少し残念でしたが、要件定義などはきっと挑戦的で好奇心を刺激されるものだったことでしょう。

働く女性

そういえば、なぜか金融機関のシステム統括部門では、女性が活躍しリーダーとなっているケースを多く見かけました。
もしかすると、男性には現場一筋かその延長で働かせたい反面、出産などで現場を一度離れたフロントオフィスの女性には、
業務を理解した上でシステム部門などの、当時は少し亜流な部門で活躍してもらうことが
金融機関としてのリソースの最適配置だったのかもしれません。
(それを支持するわけでもなく、単純に想像した結果)

おまけ

全然関係ないのですが、ミドルオフィス向けのシステム案件で不真面目エピソードとして最も記憶に残っているのが、
先方の部長さんも含めた飲み会で二次会でカラオケにご一緒した際に、
その方がアニソンが大好きで、一緒に「ライオン / マクロス・フロンティア」を熱唱したのが印象的です。

「ピープルウェア(第2版) ヤル気こそプロジェクト成功の鍵」- 「第1部 人材を活用する」を読んで

読書 プロジェクト管理

最初に勤めた会社で、エンジニアリング研修の指導者が推薦していた
トム・デマルコの著書を空いた時間で読んでみることに。

なるべくの速読を目指しつつ、
振り返り用のメモとして残します。

なぜピープルウェア(Peopleware)を選んだか

人と一緒に働くのが好きなものの、少しブランクが空いてしまったので
なんとなく、そういった記憶の喚起に効きそうな一冊を選択。

枝葉なのですが、このいかにもっぽい副題は日本独自なのですね。
原副題は Productive Projects and Teams とシンプル。
お客さんの手に取ってもらいやすくするっていう意味では、日本の副題はマーケティング戦略として正しいのか。

第1部: 人材を活用する の論点と著者の意見

要約:「互いに尊重し、協調し合い、十分に会話をすることで、高品質/高生産性を目指すことのススメ」

第1章: 今日もどこかでトラブルが
問題意識の喚起

  • 執筆当時の1980年頃、20%前後のプロジェクトが失敗に終わるという現状。
  • プロジェクトの失敗は、技術面でなく社会学的な原因に由来するところが大きい。
  • しかし、管理者はその「社会学的」な課題の解決に取り組めていないという現状の提示。
  • 管理者のそういった態度の原因は、単に技術的な課題が解決しやすい明快な問題であるため。

・現在は、こういった書籍の影響も積み重なったからなのか、管理者も一定成長している。

第2章: チーズバーガーの生産販売マニュアル
頭脳労働者の扱い方の基本

  • 頭脳労働者と工場労働者は別物。
  • 工場労働者の場合は、決められたルールの中でミスなく最大効率で労働することが資源の最大活用になるが、
    頭脳労働者の場合は、 Try&Errorありき、自発性が認められる環境で労働することが資源の最大活用になる。
  • 人員は部品のように替えが効くものではない。
  • ユニークな人材(触媒)交流による化学反応の有意性。
  • エンジニアやアーティストなど、スキルを武器に生きている人間の採用こそ、
    静的能力(レジュメに書けるスキル)でなく、実際にチームに馴染めるかを意識するべき。(社会学的な課題に直結)
  • 頭を使う仕事の重要性は、リスクが大きくなるほど増大する。

スッと入ってきた言葉:
「人は誰しも仕事に愛着を持っている。管理者は、むしろ働きすぎないように、時折、気を配らなければならない。」

・人材交流や採用については、チーム加入後に実際に触媒反応を起こさせることに至っていないケースを多く見かける。
・本当は経験があるのに言わない、本当は興味があるのに言わない、などもったいないケースが多い。
・基本的な頭脳労働者への態度については賛成だが、
年俸制度などの賃金体系と合わせて考えないと労働効率については一概には論ずることができないと思う。
・プロジェクトが実現するべきことは必ずあるので、その中でいかに自由度を高め、その自由を謳歌してもらうかが重要。
・別途、本当に現場のプログラミングが他の労働よりも過酷な頭脳労働なのか、とは思う。例えば弁護士などと比べて。

第3章: ウィーンは君を待っている
搾取されない労働のあり方

  • あなた自身も"犠牲"と思ってしまうほどに、人生のバランスを崩す必要は無いし、
    あなたの部下にも当然それを強いるべきで無い、という思想。
  • 残業は、同等の無業時間を要するという考え方。
  • 仕事中毒者は、どこかで我に返った時、社内で配置換えを望むこともなく、退職する。本当の意味での教育コスト管理(生産性)の話題。
  • 生産性向上への取り組み(標準化や機械化)が、退職率を向上させる可能性がある。(※1)
地域 価値に関する思想
スペイン流 地球上の価値の総量は一定(ゼロサム)なので搾取することで強者になれる
イギリス流 価値は才能と技術で生み出すもの

・請負開発では、大体初期契約時点で大枠の開発費などは決定しているので、スペイン流に陥りがち。
・どうにか、納得と安心を届けつつ開発費用を動的に計上できるようにするか、もしくは、高い精度でいかに見積もるかが大事。
・仕事中毒者=能力者の可能性も高いので、ふとした時に、容易に他に移動する。
※1の示唆は、他の人に野暮な仕事を任せて自分が自由に活動するための対価なので、これを払えないエンジニアは個人的には結構NG。単体テスト書きたくない人とほぼ一緒。

第4章: 品質第一 時間さえ許せば
高品質は労働者も製品もユーザも幸せにする

  • オフィスにおける感情の主な構成要因は、自尊心。
  • 大抵の人は製品の量でなく、質で自尊心を満たす。
  • 極端な時間的プレッシャーは、品質劣化につながる。期待する品質を短時間で得ることはできない。
  • 開発者にとっての最低品質は、その人の過去最高品質とイコール。
  • ユーザにとっての品質の方が、よほど開発者が望む品質よりも低い。
  • 高品質が高生産性/低コスト化をもたらす。
  • 品質に対して予算を組み、相応の覚悟を決める。
  • 出荷拒否権限。日立や富士通で採用されているリリースルール。

・著者曰く、「高品質が高生産性をもたらす」らしく、日本がその例として挙がっているが、
日本のそれは「職人気質/本物指向」と「規律/(死ぬほどの)真面目さ」といった国民性が為せる業であって、例として不適切。
・品質向上が、どれだけコスト抑制や生産性向上に影響するか、計量・明示できると方針が定めやすい。
・顧客の手にものを届けることを楽しみにできるだけの、意義を参画者と共有することが重要。

第5章: パーキンソンの法則の改定
現場目線の目標設定がもたらす高生産性

  • パーキンソンの法則: 「労働者はあるだけ時間を使ってしまう」は間違っている。
    労働者も、作ったものが早く顧客の手に届くことを期待するため、その分、熱心に仕事をする。
    労働が期待通りでない場合、例えば、力不足感、自身の無さ、同僚とのコミュニケーションロス等が要因として考えられる。
  • 目標設定者と生産性の関係について、生産性は、優れたものから以下の順となる。
    目標なし > システムアナリスト > プログラマー > プログラマー+管理者 > 管理者
  • 組織の管理業務は、時間がいくらあっても足りない。

・参画者が熱量をもっていることが前提となっているが、その点の温度合わせが難しいところではある。
・熱を感じさせ、巻き込むのが管理者の仕事。とはいえ、熱で労働を強いるのでなく、知的好奇心を刺激するようなスパイスを与える形で。
・目標設定は、少なくともエンジニアや第三者を交えて行うべき。
・管理業務は、全般的にシステム化を図るべき。
・ここで言う「生産」されたものが、果たして「ユーザが享受した価値」なのか、「ソースコードの量」なのかが気になる。

第6章: ガンによく効く?「ラエトライル」
堅実な改善が功を奏す

  • 生産性は飛躍的に向上しない。
  • 実際の製造工程全体は壮大であるため、その内の開発工程のみをN倍速にするテクニックを用いても、全体としてはやはり相応の時間を要する。
  • 技術の進歩はめまぐるしいが、年間で生産性の向上は3~5%程度。自動車産業より少しましな程度。
  • プログラミング言語の変化で生産性が大幅に変わることはない。
  • 機能やプロジェクトの取捨は、収益ベースで行い、バックログ/やりたいことに流されないようにする。
  • プレッシャーは薬よりも毒になる。
  • 管理者は、人を働かせるのでなく、働く気にさせるもの。

・実際のものを扱うこともなく、仕入れも無いにも関わらず、自動車産業と同程度の進化速度なのは、産業としてだらしなさすぎる。
・逆に言えば、もっと改善の余地がある。
・人を働く気にさせるもの。は気にしてやってたけど、改めて大事なんだろうなと思った。

知らなかった概念

英会話サンプル - 自動車保険会社 GEICO への契約に関する問い合わせ

英会話

今回は、掲題の件を電話で問い合わせした際のカンペを公開します。
海外滞在当初の拙いメモですが、まだテキストエディタのタブが生き残っていたのを見つけました。
なんか、イケテナイ/生きてない英語ですが、参考資料ということで。
どこまで、どう使えるかわかりませんが貼っておきます。

▪️▪️ GEICOへの問い合わせの筋道 ▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️

・やりたいこと
　・自動車保険に加入したい
　・国際免許のみで加入が可能か
　　・OKなら
　　　・Webの申告内容を訂正してもらう。（web formの都合上、国内の免許の取得情報の記入が必須だったため、要訂正。）
　　　・それに伴い、見積もり費用に変化があるかを確認する。
　　　・アンブレラ保険への同時加入の方法を確認する。（見積もってもらえるなら、それを受け取る）
　　　・契約手続きは、再度電話をしたほうが良いか、それともオンラインで可能かを確認する。
　　・NGなら
　　　・仮免をとれば申込めるかを確認する。

=> 結論、国際免許のみで、電話で契約までこぎつけました。
アンブレラ保険の取得には、米国での運転免許取得が必須であったためそれは後回し。(というか結局手続きしなかった)

▪️▪️ 英文カンペ ▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️
Hi, I already got a quate of car insurance in your web site.
// どうも、オンライン見積りを受け取ったものですが
I have some questions about it.
// 質問があります。

// 照会用
My name is hogehoge.
Date of Birth is 何月 何日, 何年.
The quate number is ________.

// 要するに、これ。
Can I make a contract only with international license issued in Japan?

// 必要に応じて、質問の背景を伝える。聞かれなかったら答えない。
I wanna explain my background of driver’s license.

// わたしは、日本で発行された国際免許を所持している。
I have an international driver’s license issued in Japan.

// わたしは、2年間アメリカに滞在するためのビザも所持している。
And I have a VISA to live in United States for two years.
So, I’d like to contract a reasonable car insurance with you.

then, I will stay in california but I don’t have a driver’s license issued in california yet.
And I saw some notes telling that “here in california, driver’s license will not be issued soon.”.

=> 返答がNo :
// GEICOで自動車保険を契約するには、international drivers license では不十分なのか？（再確認）
Is the international drivers license insufficient to make a contract with you?

// 仮免を取得すれば、申請権利として十分か？
Is a temporary driver’s license in U.S enough to make a contract?

=> 返答がYes :
// webフォームで正しい入力ができなかったので、訂正してほしい。
OK, I wanna continue to purchace.
But, In your web form, I can’t inform my exact license status as I explained now.
To process my quate in web site, I temporary informed that I already obtained United state’s driver’s license.
Cloud you remove my United States driver license information in my quate?
Please do same operation for my spouse’s information.

// その結果、quateが変わるか？
As a result of the processing, does my quate change?
If it’s changed, Could you send the latest quate to me by email?

// さらに、アンブレラ保険を追加することも可能か。
In addition, can I add umbrella insurance to my car insurance?
Could you send the quate including umbrella insurance?

// 可能であれば、見積もりを二つもらいたい。
If possible I want to get two quates.
one is only for car insurance.
the other is including umbrella insurance.

// 総括
OK, I wanna organize information.
- I can contract with international driver’s license.
// I can contract quate #_ with $ written in quate.
- I can add umbrella insurance to the car insurance.
- You will send me two latest quates of my car and ubmrella insurance by email.

// クロージング
I will continue the purchase processing in web or phone call with the latest quates.
Thank you for your kind consultation! bye.

// 名前をもらっとく
Can I have your name, again?

▪️▪️ 聞かれるかもしれない情報 ▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️▪️
// 一月以内には、米国の免許を取得する予定です。
I’m going to obtain united states driver’s license within a month.

// 携帯番号は、XXXです。
My phone number is XXX-XXX-XXXX.

ちなみに、電話の中で、こんなことを復唱させられる瞬間がありました。
“ I, (私の名前), swear ~” (私、hogehogeは、~ を誓います)
復唱させられてることにしばらく気づかなかったのは秘密。

ではでは。

ディズニーワールドリゾート スワンホテル でのファストパスの取り扱い

ディズニーワールド

少し前にディズニーワールドのスワンホテルに滞在した時の話をシェアしたいと思います。
情報がまばらだったり、スワンホテルが準公式ホテルなせいで取り扱いがグレーな感じもあり大変でした。

ファストパスプラスとは？

日本で言うファストパスを、ディズニーワールドではファストパスプラスと呼びます。
違いは、オンライン(スマホアプリ)でファストパスの取得や使用、閲覧ができるというもの。
さらにはディズニー公式ホテルに宿泊すると、本来、来園30日前からしか取得できないはずのところ、
なななんと、60日前からでも予約することが可能です。

(注意: それでも最新のアバターのVRライドとかは一瞬で予約が埋まるので
来園60日前の米国東海岸時間(たしか)午前7時に、ちゃんとPCの前で待ち構えておく必要があります。)

まあとにかく、ファストパスプラスは便利。
ファストパスプラスには日本には無い特性もあります。
+ 来園1日につき、合計3つのライド/ショーまで、ファストパスを事前予約できます。
+ ライド毎にA(人気)とB(その他)みたいな2つのランクがついており、ライドAは1日1つまでしか取得できません。計画時にはご注意を。
+ 各日、事前に取得した3つのファストパスを使い切ると、同日のファストパスを追加取得することが可能です。
その後は、追加取得したファストパスを消化するたびに追加取得することが可能です。 (追加で1つまでしか取得できなかった日(園?)と、追加で複数取得できた日(園?)があったような気がします。未確認。)

スワンホテルとは？

そして、スワンホテルとは、エプコットやハリウッドスタジオにはフェリーで、
ほかのランドにもシャトルバスでスイスイ行ける素敵なホテル。
ホテルの雰囲気は、言ってしまえば清潔で品のある(ビジネス)ホテルであるものの、
特に滞在先でいわゆる"ディズニー体験"を求めず、キチンと基本機能を押さえて欲しい方にはおすすめ。 そして、オフィシャルホテルではなく、準オフィシャルくらいの位置付けのホテルであり価格面でも空室率でも有利です。

ファストパスプラス x スワンホテル、問題ない？

そんなスワンホテルですが、準公式であることから、ファストパスプラスに不安を覚える方も多いのでは？
結論から言うと問題なしで、来園60日前からファストパスプラスを予約可能でした！

ただ、注意点(焦らないでポイント)として、予約システム上でホテル情報を紐付けて初めて60日前予約権を得るのですが、
システム上であなたが予約可能に見える日程は特典なしの来園30日前以降のままのように見えるはずです。
「え！？」と焦る方、ままいらっしゃると思います。私もその一人。でもご安心を。
はい、ではいつから正しく表示されるようになるかというと、実際に来園60日前(の東海岸時間の朝7時かも?)になってからです。

どういうことかというと、こういうことです。

2017/9/19 : 来園の61日前 => 予約システム上、来園予定の30日前(2017/10/20)以降分しかファストパスを取得できない。
2017/9/20 : 来園の60日前 => 予約システム上、来園予定の60日前(2017/9/20)以降分もファストパスを取得できるようになる！
2017/11/19 : 来園予定日

、、、伝わっているといいのですが。

ちなみに、ホテル一階にディズニーワールドの派出所的なカウンターがあり親切丁寧に案内してくれます。空いてます。
さらには、マジックバンドも販売しており、あなたのアカウントのバンドへの紐付けもしてくれます！(涙)
※ マジックバンドは、腕時計型みたいな形をした電子チケットみたいなもので、園内ではこれをかざしてファストパスを行使できます。

あえて問題点を言うなら

スワンホテル滞在について、問題といえる欠点はありません。
マイナスかな、と言えるのは、公式ホテルだとマジックバンドをルームキーとして使えたり
園内での決済手段として使用できるのですが、スワンは準公式であるため、マジックバンドにはこれらの機能は付属しません。(のはず)

わざわざフロリダにまで行くからには
みなさんのディズニーワールドの思い出が少しでも楽しいものになることを祈っています。
何かのお役に立てば何よりです。

for search: disney world resort swan hotel fast pass plus

英語Tips - 意外と空気を読む英語

英語Tips

この記事では、我々日本人が構えてしまって
脳内でテストをしてしまいがちな英語について、 実は日本語の会話と同じように手抜きをして空気を読ませているケースを紹介します。

Let’s 手抜き。

例1. ホテルに滞在中、ゲストが増える旨を事前に伝える
実際の例:
My friends are going to stay with us for 3 days, but it’s gonna be only me and my wife after that. // 友人が3日ほど一緒に泊まる予定だけど、そのあとは私と妻だけになる予定です。

日本人が考えそうな文章:
My friends are going to stay with us for 3 days, but after that only me and my wife are going to stay at the room.
// 友人が3日ほど一緒に泊まる予定だけど、そのあとその部屋には私と妻だけが滞在する予定です。

文章の長さはほぼ変わらなかったり、ちょっと文章の構成要素が増えていたりで単純比較になっていないものの、
前者の方が “it’s gonna be (it is going to be)” という口をついて出てきそうな表現で勝手が良さそうです(よね?)。

二文目のように、主語 + 動詞 を意識した節を作らずとも、
“it is” = ゲストの話(空気を読んで) と “me and my wife” = ゲストが誰か を置くだけで成立するので楽ちんそうにも見えます。

例2. 引越しやに荷物の量と金額について質問した際の回答
実際の例:
Anything under that space will be the same price.
// そのスペース以下であれば、同じ料金です。

日本人が考えそうな例:
Anything under that space will be delivered with the same price. // そのスペース以下であれば、同じ料金で配達できます。

この例は、以前のこちらの記事とも関係してきますが、
naosk8.hatenablog.com

“Anything under that space” という名詞で、二文目のif節を丸っとカバーしていてスッキリしてますね。
おそらく、本当は「日本人が考えそうな例」の方が"be delivered"という料金発生理由を含んでいるので正確な英文な気もしつつ、
ネイティブさんの例では、空気を読んでbe動詞を挟んで主語と補語が「なんでも」「同じ値段」と並べられています。
この文章を自分で思いつくのは至難かもしれませんが、日本語でも「トラックに載るなら同じ値段ですよ」などと言うので、
直感的には日本語の感覚と遠くないような気もしますね。

ということで、今回の学びは(書きながら自分でも整理しているのですが)、
- 英語でも空気は読まれる/日本人は日本語で話すとき以上にしっかりとした英語を話そうとしすぎないこと。
- if 節などの条件節を含む文章を頭の中で構成しようとしたら、anythingの名詞節で考えてみる。
- “it’s gonna be"は魔法のフレーズかもしれない。

ではでは。