コミュニケーション・バイパスはなぜ起きるのか
コミュニケーション・バイパス。コミュニケーション・デトゥアーとも言えるかもしれない。
迂回のコミュニケーションである。
Aさんをこうだと思う、Bさんはこうだよね。
こういった会話はポジティブな会話でもたくさん生まれる。
他人に対する賞賛を違う人に行うのは自然発生的だと思う。いいことだね。
以下この内容の目次です。
コミュニケーション・バイパスとは
これが、「Aさんにこう言ってはどうだろうか」「Aさんにこうしてほしい(と自分は言えないので言ってほしい)」といったことに繋がるケースがある。これを聞くと、「ああ、デトゥアーが起きているなあ」と感じる。いいでも悪いでもなく、起きたなと思うのです。
AからBに直線ルートがあるが、それを知っていてあえてCを経由する。
兵法や移動で考えると、「直線でいけなくはないが補給しておくことがリスクヘッジになる」ことだったり、「AからBに障害があるからCを経由する」「AからBへは行けなくはないが坂道がある」というようなケースに、「Detour」と書かれる道標を置く。
それでA→C→Bと経由するとBにいける。最短距離ではない。だがそれが効率的であると思われる。
これがコミュニケーションで発生するケースはどんな場合なんだろうか？
パターン化すると以下かなと思う。
コミュニケーション・バイパスが起きる瞬間に起きていること
なぜコミュニケーション・バイパス、デトゥアーが起きるのか？それは4つに分類出来るのではないかと思う。
- その人のコミュニケーション特性を理解していないので、伝え方や伝わり方が不透明である。それ故特性を理解している人へDetourする。
- その人の最近の状況がわからない。何をしていて、何に困っているのか、ネガティブ側の要素が見えない。それ故その人のネガティブ要素を理解している人へDetourする。
- そもそもコミュニケーションしたくない感情を持っている。コミュニケーションした際にネガティブな印象を持った。それ故コミュニケーションを回避するためにDetourする。
- 人間関係的に直接コミュニケーションをするルートが存在しない。本人ではない代理人によるコミュニケーションが望ましい、例えば弁護士が絡む問題などがあるためにDetourする。
例えば、「お父さんに直接言うのは嫌だな。ママに言うから、お父さんに伝えてもらえないですか？」こんな瞬間もバイパスが行われている。
コミュニケーション・バイパスには、バイパスしたい側のニーズがあると思う。
コミュニケーション・バイパスをする側の期待値
- コミュニケーションのトンマナがわからない。その理解をする時間を短縮する、関心がないから、お願いする
- その人の近況を人づてに聞いては本当の状況を理解できない。その前提でコミュニケーションしては思わぬ理解不足から、コミュニケーション・ロス(前提条件の不一致)が発生し得る。そのリスクを会費したいから、お願いする
- コミュニケーションを取るのが率直に嫌だ。過去に嫌な経験をしているので、それをもう再現したくない。だから他の人に依頼する。これは完全にコミュニケーションの代打的存在だ。
- そもそものルートがないために、効率的なコミュニケーション手段の代行をお願いしたい。
コミュニケーション・バイパスが発生した瞬間に、それがどのパターンなのか判断し、それが期待するものか？期待しないものか？よく考えてみる。もし期待しないコミュニケーション・バイパスが起きていたとき、Detourの道標が置かれまくっている道路を想像してみる。
・・・めちゃくちゃ混乱する。行っても行っても、「迂回せよ」だ。
迂回ばかり起きているコミュニケーションはとても難しくなる。電話の交換手状態だ。
誰かが交換手になって、それだけで一仕事になるし、「AさんとコミュニケーションするならCさんにお願いする」という謎のプロセスが生まれる。電子回路では最短距離が常に求められながらも、コミュニケーションではそうはいかないことがある。
意思決定のフローを登っていくのはコミュニケーション・バイパスではない。そもそもそれはルート上にあるからDetourではないのだ。
コミュニケーション・バイパスにどう向き合っていくか
これはなにも日本だから起きるとかそういうことではなく、インドでも中国でもアメリカでも起きている、人間社会の構造だと思う。
それが期待しないことだったなら、
- コミュニケーションしたくないようなオーラを持ち得る、発信者と受信者どちらにもバイパスしないようにお願いする。
- バイパスが起きる原因が相互理解の不足であれば、相互理解を深める情報を出し合うようにお願いする。
- そもそもコミュニケーションしたくないようであれば、どんなコミュニケーションは快適で、どんなコミュニケーションは不快なのか定義する。そのうえでお互い快適なコミュニケーションを取るように努める。
基本的に相互理解を深めることが大事である。相互理解を深めたくないようなら、そこからがスタートだ。
家族でも、学校でも、会社でも、組織である限りこれは起きる。
部活だったら、バンドだったら退部したり新規加入があったりで、その中でコミュニケーションが磨かれ、バイパスが少なくなり、「言いたいことが素直に言える」状況になる。これは至高の状態だ。わたしもあなたも止める人がいない。
そんなことは理想かもしれないが、小さな人数なら努力で、4-6名程度であればそれが実現できるのではと思う。
100人規模で言いたいことは言い合えないと思っている。組み合わせが無限に近いくらいあるし、相互理解がどんなに時間があっても足りないだろう。それ故の細分化だ。グループに分けていく。A班、B班、と特徴のあるチャンクを作る。目的ベースでもいい。
相互理解をしたいと思うためには、互いの尊重がなければそれは実現できない。いがみ合っているとか、卑下していては理解は進まない。お互いが「お前を大好きだな～」と思い込み、自分に何度も言い聞かせられるような人がその組織には必要だ。そのポジティブなパワーが波及していく。人は人の真似をする生き物だから。
簡単にネガティブなコミュニケーションは出来る。悪態をついたりするのはとても楽だ。
人間社会に求められるのはその逆で、自律できないとポジティブなパワーは出せない、もしくは天才的にポジティブな人もいる。
いい環境は黙ってやってくるほど甘美なものではなく、その中にいる人達の努力で実る、動物的集団の理想像だと思う。
そんな集団は強く、生き残る集団になるはずだ。
Adrollの感動対応 評価クチコミを・・
最近お客さん向けにAdrollの運用を始めた。特にリターゲティングの指定がなかったので、CriteoかAdrollでどうしようかなと悩んだ。
Criteo - ディスプレイ広告のパフォーマンスを活用する
どちらが良いかについては Adroll vs Criteoという記事がたくさんネットにあるのでそちらに譲るとして、今回のポイントは
1. すぐに始められるか 営業とかめんどくさいコンタクト無しに始めたい。
2. 明快な料金体系。営業にコンタクトして云々で料金を決めたくない。
3. Ads just work.それだけでいい。シンプル機能で簡単に始めたい。
日本の企業だと、FAXで申込書送って、法人の角印押して・・とか超絶めんどくさくて始めるだけで数日の工数を使ってしまうのはあるある話。営業が会ってお話を！とか、別に会って話さなくても、やりたいことは単にリターゲティングしたいだけなの。。
で、WebでJust startできそうなAdrollを選択。何が素晴らしいか書いておくよ
1. チャットでリアルタイムサポート
2. Pixelを埋め込む、広告のデザインイメージを送る。それだけ。
3. ガンガンリタゲしてくれる
チャットでリアルタイムサポートとは、現在英語だけなんだけどチャットで「これどうすればいい？」って聞くと、ラザニアさん、シリルさんとかが「わかった！こっちで高設定するから、このボタン押して！今ね！出来た？！良かったね！」みたいなノリで爆速で確実な対応をしてくれる。日本の製品だとメールで対応、質問は6時間おきに回答が来るくらいでしょう。一つの問題を解消するのに数日掛かるなんてザラ。そんな対応をしている日本企業は朽ち果ててしまうでしょう。
Pixelとは要はjsのスクリプト。とりあえずリタゲを埋め込みたいページにjsを挿入し、Adrollの画面上からActivateする。それで終了。次に、広告のデザインイメージ画像を送ると、Adroll側でサイズ別に広告を作ってくれる。"Ads requirement"という概念があり、こちらが送った画像をベースに、それを要件としてざっくりとした広告を作ってくれる。色んなサイズのバナーを作るのは正直しんどいので、これはすごく有り難い。
出来上がったバナーはどれも同じようなデザインで、どのサイズが一番CTRやら高いかは管理コンソール上で確認する。効果がありそうなサイズとデザインがあればそれを続けるし、改善が必要なサイズにはこちらでデザインを再度作りなおせばOK．注意点はロゴかサービス名を入れるように、とのこと。
リタゲは当然ガシガシやってくれる。しつこさはちょうどいいくらい？多分、1ユーザーに対する上限表示回数みたいな概念がありそうで、最初は1週間くらい張り付かれたけど、その後ピタッと止まった。ロジックは優秀そうです。
と、ここまでが一般的なレビュー。得てして良い！問題は日本人スタッフがいないことかしら・・Adroll運用代行事業でも始めようかな。
今日、「Adをアップロードしたんだけど、いつ承認されるの？アップしたの5分前なんだけど」ってチャットしたら「チャットありがとー！！今すぐ承認する！！」「終わった！注意点◯◯ね。良い一日を〜」と素晴らしい神対応してくれた。
チャットで話しかける心理として、おうおうに「今すぐ解決したい」なんだよね。
ユーザーって自分勝手。。でも、それをすぐに解決してくれるチャットサポートの担当者がAdrollに多いことが素晴らしい。これからもこのクオリティで、日本人スタッフがサポートしてくれるようになればいいね！
NGINX/php-fpm環境で出る自己防衛機能
この前NGINX上で作業していて、いろいろphpを動かしていた。
と、突然Webサーバにアクセスできなくなった。
これはやばいなと、でログを確認。
2016/04/27 13:05:09 [crit] 13600#0: *2101 connect() to unix:/var/run/php-fpm/php-fpm.sock failed (13: Permission denied) while connecting to upstream, client: hogehoge, server: www.hogehoge.hoge, request: "POST /xmlrpc.php HTTP/1.0", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:", host: "hogehoge"
こんな感じのエラーを大量に吐き出していた。あれーpermissionは適切なんだけど・・
でphp-fpmのログへ。
[27-Apr-2016 13:05:22] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
気づくとpermissionが変わっていた。
srw-rw---- 1 nobody nobody 0 4月 27 12:54 2016 php-fpm.sock
php-fpmはnginxがオーナーなんだが。nobodyはphp-fpmのwww.confでコメントアウトしてある。とりあえずオーナーをnginxに変更。php-fpmとnginxをリスタート、ことなきを得ました。
pm.max_childrenが最大値になり、何かの閾値が上がると、サーバのメモリリークを防ぐためオーナーを書き換えて自分が落ちるという、防衛機能なのか？と思いました。
サーバ自体は再起動せずに済んでいます。
原因はわからないけど、Crystalwomanさんの以下のブログが参考になりそうです。
自分のサーバでも早速確認。
780 php-fpm:
62408 php-fpm:
62292 php-fpm:
49320 php-fpm:
62456 php-fpm:
62656 php-fpm:
64752 php-fpm:
62564 php-fpm:
62568 php-fpm:
62784 php-fpm:
62572 php-fpm:
61484 php-fpm:
59804 php-fpm:
60916 php-fpm:
62320 php-fpm:
61592 php-fpm:
確保されているメモリの模様。余計なことはできないってことか。
決済周りがFintechと呼ばれて流行ってそうだ→Stripe評価・検証・実装→これはいい。。Paidyもよさげ！
決済周りはFintechとか呼ばれて流行っているみたいで、今更Paypalだよね！みたいな風潮が再度盛り上がってきたり、去年流行ったスマホクレジットカードリーダーの話はどこに行ったんだ感があったりしている。
比較はたくさん世の中に溢れているので、個人的な感想をまとめます。
もしどなたかの参考になれば幸いです。
Stripe --> ◎
結論、Stripeを評価、検証して実装しています。Stripeの実装はjsやphp、僕はちょっと苦手なjava等色々な選択肢があり、実装の選択肢は豊富。加えて、コミュニティのサポート力がものすごい。Stripeの決済関連のサードパーティアプリは結構あるし、Stripeも他社のモジュールをサポートすることに力を入れている印象を受けました。
先日サポートに問い合わせをしたら、伊藤さんという方が親切に回答してくれました。英語でのサポートでも全然いいんだけど、日本人が日本の時間に回答してくれるのはなんだか親近感がある。以下が実装した結果のサイトです。
・いわゆるStripeスタイルというものがあって、この青でこの標準的なフォントがStripeスタイル。別に格好良くもないし、格好悪くもない。
・継続課金の仕組みは、Stripeのプロダクト設計にきちんと盛り込まれている感じがする。いわゆるECで、単なる売買のケースももちろん、今増えてきているサブスクリプションモデルの決済もドキュメントに記載がある。Subscription add-onという項目だったかしら。
・ちなみにこの青on青は自分のテーマのCSSとバッティングしてる。また、{amount}というshort codeを使っているけど、それもまた正しく値を返してくれていない。ぼちぼち直します。(商用サービスインしちゃってるけど、そこまで大きなバグではないし、まだそんなに宣伝してないから、えいやっとリリース) 今気づいたけど、はてぶでこうやってURLコピーしたときに自分のサービスはちゃんと見えないんだ。直ぐに対処しておこう・・
ちなみに、CVCって日本語だとどう訳せばいいんだろう？セキュリティコード、だけど長すぎる。カード裏3桁 かしら？
Stripeが良かったポイントは、アカウント登録をお試しでやったら、直感的なダッシュボードがすぐに使えるようになったこと。商用サービスをすぐにイメージできて、加盟店の審査みたいなものもないし、トイサブみたいな小さなサービスを開始したいビジネスオーナーにはうってつけのサービスだと感じた。
例えばPleskみたいに、日本でどこか大きなホスティング事業者やらSP事業者が大々的にサポートしてくれて、EC-CUBEやWordpress、MTやWixなんかのプラグインを作ってサポートしていったら、Stripe決済は手軽だし流行る気がする。
https://www.gmocloud.com/basic/service/plesk/
だって決済手数料のみで、初期費用も何もかからない！トイサブみたいな低マージンのビジネスには本当に助かる決済モデル。今はクラウドペイメントのリンク形式を使っているけど、https化も終わったので、徐々に全ての決済はStripeに移行していければと思っています。クラウドペイメントのリンク形式でないやり方もきちんと検証しないと失礼なので、あとでやっておきます。。
総じてStripeいいね！ダッシュボードもドキュメントも、コミュニティもいい感じ。開発者にとっても利用者にとっても優しい。どんどん日本の決済はStripeみたいな簡単な決済になるといいよ。
僕はガチンコ開発者じゃなくて、超上級言語ならなんとか・・みたいなアマチュアプログラマなので、Stripeみたいにオープンでコミュニティ活動が盛んなサービスが出てくるのは超ウェルカム。Stripeのためにhttps化するのはガッツで何とかなった。
ここまで簡単に出来る時代、実行こそ全て！って感じですね。経営は実行。
能書き垂れてないで開発、開発。検証、実行。ってやってると、ビジョンがない！とか言われちゃうわけですが。
Paidy --->◯
Paidyは利用者からしてみると、すげーーーー！こんなのでいいの！！猫まっしぐら！みたいな印象を持つであろうサービス。本当に超絶簡単なユーザビリティ。でもStripeにユーザビリティが酷似している気が。。そういうものだと思えばいいのかしら。Paidyの会社自体は老舗のようなので、パクったとかはないんだろうけど。
ただし、これは決済をするその瞬間まで。決済後、コンビニに行くのがなんだかすごいだるい。このためだけにコンビニ行きたくない→他の目的でコンビニ行く→Paidyの支払い忘れる でずっとPaidy支払いを忘れていた。
Paidyは素晴らしい！継続課金もできるし。
開発側としてはどうか。PaidyはStripeよりも親切丁寧なドキュメントが準備されていました。これはデザイン的に可愛いし、なんだか女子開発者ウケしそう。
そしてjs読むだけ〜のお手軽実装。これもまた素晴らしい。ただ！
ただ！ただ！プラグインでさく〜っと入れたいなと思っていると入れられなかった。
REST APIを受けるサーバまでトイサブで作れない。。。
トイサブはNGINX+Fast CGI+MySQL+WPのあるある構成で、どうやってREST APIを受けるクチを準備しようかしら・・・スモールスタートにはちょっと厳しい印象。
中規模くらいのサービスで、決済金額が結構な額になるサービスには良いのでしょうね。Paidyを評価、検証、実装してみた、みたいなブログがあれば見たいけど、すぐには見つからなかった。これもさくっと入れられるプラグインが欲しいものです。
Paidyはコンビニに行ったらリマインドしてくれるみたいなものが追加されるとすげー流行りそうな気がしてる。僕は支払いますけど、忘れちゃうんです。。例えば、コンビニのWi-Fiを掴んだらアプリがプッシュ通知してくれるみたいなのはいいなあ。
SPIKE --> △
なんと継続課金は現在未対応。それってトイサブでは使えないということ。。なので今回はスルー。良いサービスなのかもしれないけど、継続課金が出来るようになったら、評価、検証、実装してみたいな〜と思います。
これからどんどんスモールビジネスが増えていく中で、僕みたいな小規模ビジネスオーナーが一人でサービス設計と実装するみたいなシチュエーションは増えてくる気がしています。思いついたアイデアを実装しよう！そのためにはマネタイズが必要。どうやって決済すればいいのかしら。そう思った時、自分の今のイチオシはStripeでした。Paidy も素晴らしいので、
・クレジット番号を入力させても、お客様は不満に思わないようなサービス
・クレジット番号を入力するのが億劫なお客様がいるようなサービス
色んな商売の形があるので、その時にどんな決済をおすすめ出来るか？それでお客様が買いやすいやり方でサービスをデザインしていく必要があるんでしょうね。
以上です。
ソラコムvEPCの衝撃：破壊的テクノロジーで今ある技術が「あの人は今」状態に
2004年くらいからITという産業に関わり始めて、その頃は主流はフレッツISDNくらいだった。そこからADSLになり、FTTHになって、FTTHが主流になったのは2007年くらいかな。体感として。わずか5年程度で主流が変わった。
ISDNの頃のATMの装置は切り替えられ、電話線がメタルに、ファイバーになった。
ファイバーになって収容装置は変わって、伝送距離、光の減衰を意識するようになり、考え方は大きく変わった。FTTH以上の固定回線技術はなかなか普及しないかも。
FTTHを効率的に使う技術は流行しても、それ自体は変わらなそう。GE-PONがG-PONに変わるくらいかな。
これと同じことがモバイルのパケットコアで起きていることに驚愕した。
EPCは従来、エリクソンやNEC、ノキアといった100年企業が作り上げてきたモバイルネットワークの完成系の一つで、これからはハードウェアをACTAベースからIntelベースに切り替え、仮想化していくvEPCが進んで行く。
ACTAベースのソフトウェアは、実は汎用ハードウェアに乗せにくい。
なぜなら中で動いているソケット通信やバッファの使い方が汎用機とは大きく違うから。NFVとか言っても、中を覗くとACTA時代の残骸残ってますがな！みたいなことは往々にある。
vEPCではソフトウェアも考え方が変わっていく。SLA99.9999%のソフトウェアから、Design for failureなソフトウェアに変わってしかるべき。
そしてDesign for failureであることで、開発言語も思想も変わっていく。
ソラコムという会社がM2M向けのMVNOとしてサービスインしたんだけど、
そのバックエンドは本当にすごい。vEPCを自分たちで開発したと聞く。
L2接続のMVNOの場合、vEPCと言ってもそれはP-GW以降の話だが、
それでもシスコやエリクソンがせっせと開発したP-GWを、アムドックスやコンバースがせっせと開発したOCSを、OpenetやTEKELECが開発したPCRFを彼らは自分たちで半年程度で開発してしまった。
言語はRubyの模様。確かに、やろうと思えばできないことはない。
所詮ソフトウェアは手作りでしかなく、重厚長大な資産がなければできないものではない。Javaでメモリのコンテナーを使って・・・とかやって99.9999%のSLAを実現していたものが、最近出てきたRubyに取って代わられた。そしてRESTなAPIがある。
これなら出来るな、と思う人もすごく増えたはず。
ハードウェアが安くなって、スケールやパフォーマンスは障害検知などに優れるクラウドプラットフォームで十分に出せる。完全性よりも冗長、事故後の復旧などに力を入れるなら、汎用機とC/C++とかでも出来ないことはない。けど、それを実現したということはとてつもないこと。
時代は重厚長大な会社がどんどん切り崩され、10人くらいのスーパーマンが数万人企業に挑戦したら、勝てる時代になっている。ソラコムができることを証明したことから、テレコム系のソフトウェア会社は「なんでライセンスを買わなければならないか。OSSやクラウドを組み合わせてできることとの違いは何か」の質問に明確に答えを出さないと。
HadoopとSPARKを使えば、ソフトウェア開発会社が一生懸命作った商品レベルのものが出来上がってしまうのも直視したし、今後のITはこういう汎用を組み合わせて、高い完成度と的確なニーズを捉える会社がオセロのように大企業をひっくり返していきそう。
アプリケーションベンダーは、UI/UXに徹底的にこだわり、ユースケースを磨き、ニーズを絞ってそれに明確な答えを出せないと、「上手に組み合わせる」ベンダーに勝てない。例えば日立や富士通みたいなベンダーが自社開発したもの。それは「上手に組み合わせる」ベンダーよりも魅力的か？
タイトルに「あの人は今」と書いたけど、もしかしたらテレコム系のソフトウェア会社はどんどん潰れて、基地局や伝送を作れるハードウェア会社だけが残って、「テレコム系に特化したソフトウェア会社ってあったねえ」という時代は確実に近づいていて、やもすると既にそうなり始めている。
追記：5年後に今の自分の仕事はなくなるんだなという衝撃を、ソラコムを見た瞬間に覚えた。
さらに追記：
多くの方に見ていただいたようでありがとうございます。
ATCAとACTAのTypoに対する指摘が結構あり、お恥ずかしい限りです。
恥ずかしいのでこっそり直そうかと思ったんですが、あえて残しておきますw
東京で車の二台持ち プントエヴォとエクスプローラー
プントエヴォ。http://www.toysub.net のShidaxです。
妻が車に乗りたい！でもエクスプローラーはこの前ガチャンとやったから怖い、と言っていてどうしたものかな〜と考えていたところに素晴らしい候補。
乗り換えではなくて二台持ちでコストはいくらか、考えてみました。
現行エクスプローラー：
ローン 50000円
保険 8000円
ガソリン 10000円
税金積立 5000円
車検積立 5000円
計：78000円 結構お金使ってますね・・・
これにプントエヴォを足すと：
ローン 70000円
保険 16000円
ガソリン 16000円
税金積立 10000円
車検積立 10000円
計：122000円
毎月5万円の支出増か・・・
住宅が15万、光熱費水道で2万、通信で2万(妻は9月でMVNOにしてもらおう笑)、貯金で5万、保険で1万、諸々支払いで10万くらい？幼稚園3万・・計算するとあんまり余裕なし。
駐車場は金額を考えなくていいのですが、東京でこれってなんだかなあ。
でもカーシェアも高いですよね。ちょっと乗ってたらすぐ数千円だし。
カーシェアで週に2回乗るとして月に4万円くらいか。そんなに乗るのか？笑
子供の年齢が上に行くと、地元で遊ぶことが増えてくるので、行動範囲が狭くなるんですよね。3人乗りのスーパー自転車とかのほうが効率いいような。
考えものですね。5万円だけではないです。
妻が出先で色々するわけで、飲食、ショッピング、駐車代・・
もろもろかかるわけで、7万円くらいは増えると考えていいわけです。
7万円今の生活費から削るのはしんどいな〜
毎日オニギリにしても2万円くらいしか削れないわけだし。
トイサブも配送の時に車を使いますが、郵便局まで行くのは台車でも
なんとかなるっちゃなるからな。
と、車は便利だけどお金がかかる。一張羅になっていくのも無理ないです。
車のスタジオとフォード エクスプローラーのツーリングサポート
トイサブの中の人,Shidaxです。
日に日に検索結果からずり落ちてしまうので、こうした形でブログ側にもアドレスを貼ることにしました。
やりたい商売が幾つかあって、そのうちの１つが車のフォトスタジオです。
結構投資が必要でなおかつ回収まで時間がかかりそうなので、当面はトイサブでお金を貯めてから考えたいと思います。こちらは親戚の家の駐車場で撮ったんですが、我ながらかなりかっこいいなと。スタジオ欲しくないですか？かっこいい写真を愛車で撮りたいと思うのは当然だと思うんです。外国車の利用が増えているのですから、こういったサービスはやったもん勝ちです。早くやりたい！
あと、この前インロックしてしまって。困ってフォード成城に電話しましたところ、ツーリングサポートという無料のサービスを呼んでくれて、1.5万円の支出を抑えることができました。何よりフォードブランドで一貫サポートしてくれるのは安心感があります。フォード、日本でもっと頑張ろう！いいサービスしてると思うんだけどな。(価格に織り込み済みだろうけど)
最近だとRSもリリースされ、日本でも新マスタングが現れるようになりましたね。
アジアの中心の１つである日本で、フォードが注力しないのは残念だけどフォードのターゲットであるアクティブな若年・青年層、やんちゃなシニア層は日本には多くない。
日本人ももっと元気になってどんどんお金を使わないと、魅力的なサービスが日本に来ないというのが如実に現れつつありますから、頑張ってお金を回していきたいものです。
