世界最大級のモバイル業界見本市「MWC Barcelona 2024」に参加してきました

こんにちは、デジナーレの原田です。

 

2024年2月26日(月)から2024年2月29日(木)の4日間、スペインのバルセロナで開催された世界最大級のモバイル業界見本市「MWC Barcelona 2024」に参加してきました。

 

今回、弊社のお客様のプロモーション施策の一つとして、
業界最大の展示会に出展し、ブース展示のみならず、重要な商談やステージ講演、
メディア取材などさまざまな活動を行いました。

この展示会は、これまでお客様と共に実施してきた数々のプロモーション施策の中でも、
集大成と言える大きなプロジェクトでした。

その中で、私はMWC出展におけるプロジェクトマネジメントや展示ディレクションなどを担当し、
現地バルセロナにも同行しました。

 

本日は、その様子を少し紹介します!

 

開催初日、まだ肌寒い夜明け前。出展準備のため、私たちは会場に向かいました。
正面に飾られた、“MWC” の迫力あるオブジェが目を惹きます。

緊張感もありましたが、2023年の7月頃から地道にMWCの準備を進めてきたので、
「無事にこの日を迎えられた!」と少しホッとしたことを覚えています。

 

こちらはエントランスの様子。
今回のMWC24全体の来場者は約10.1万人。過去最高のMWC19の10.7万人に迫る賑わいとなりました。

今回のテーマは「Future First」。
AIを絡めたソリューションや5Gの収益化などが注目を集めていました。

 

会場には、世界各国の名だたる企業がバルセロナに集結しています!
ものすごい迫力(°°)…!!

 

私自身、国内外ともに展示会は何度か担当し、国内展示会への同行経験はあるのですが、
海外展示会への同行は初めての経験でした。

担当した展示やステージ講演に関しては、残念ながらこちらに掲載することはできないのですが、、、
展示会は、無事大成功を収めることができました!!!

 

今回、本件に携わらせていただいた中で、特に印象的だったことをまとめてみました。

▼準備フェーズ

●今回、展示物の制作だけでなく、展示ブースや商談ルームのデザインにもメインで携わりました。「なぜこのようなデザインにするのか」というコンセプト設計からそれを実現していく過程や、各コンテンツがそのコンセプトと合致しているかを確認しながら検討することが、今までにない体験でとても印象に残っています。クリエイティブメンバーと何度も議論し、試行錯誤を重ね、チームの想いが伝わるデザインに仕上がりました。

●展示会では、その企業の社員がブース内で来場者にサービス案内を行うことがよくあります(以下説明員とする)。今回は大規模な展示会のため、説明員の人数が多く、かつ初めて説明員を経験するメンバーがほとんどでした。そこでサービス案内のクオリティを保つために、渡航前に「レクチャー会」と「ロープレ会」を実施しました。説明員経験者の方をお呼びしてレクチャーをしたり、海外メンバーをお呼びして英語の指導を交えながら行ったり、より本番に近い状況で練習を重ね、本番に備えられるようにサポートしました。

 

▼現地対応

●ロジ周りの準備や設計に大変苦労しました。展示、商談、講演、取材など施策が盛りだくさんだったため、それぞれにおける準備と、それを現地でスムーズに進行するためのロジ設計には多大な時間を要しました。また、海外展示会なだけあって、資料は英語と日本語の2種類を作成する必要があったり、英語でメール対応をする必要があったりと、海外の方とのやりとりも多々発生しました。

●どれだけ事前に想定で準備をしていても、実際に現地に行ってみなければわからないことがとても多いです。来場者の入り具合や巡回の導線、講演するステージや客席の位置、撮影カメラの位置など、事前に把握するのが難しいことも多く、現場で毎日打ち合わせを行い臨機応変に対応しました。

●展示ブースや商談ルームの施工において、国内と海外での施工技術の違いが大きかったです。日本では当たり前と思われるようなものが想定外の仕様になっているということがあり、驚きもありましたが、次回以降のデザインや施工指示をする際の参考になりました。

 

本当にたくさんの方々が関わり合い、力を一つにして作り上げた展示会だったと実感しています。
メンバーの一員として携われたこと、大変嬉しく思います。

そしてMWCを通して、
多くのことを学び貴重な経験させていただいたことに心から感謝しています。

 

本当にありがとうございました!!

AWSのサービスTranscribeについて変換精度の検証をしました。

どんなサービス?

音声データを入力し、音声をテキストに変換してくれるサービスです。

検証すること

音声データからどれくらいの精度で文字起こしができるかを検証する。

検証方法

「吾輩は猫である」の冒頭を音読した音声データを文字起こしする。
1.静かな場所で音読している音声データを用意
2.BGMとして雑音(風などの環境音)を流し、音読している音声データを用意(雑音は声と同じくらいの音量)
3.2つのデータをTranscribeで文字起こししてどの程度文章が異なっているかを検証

検証結果

解析結果はTranscribeの出力をそのままコピペしています。

静かな場所での音読

元の文章 解析結果
吾輩は猫である。名前はまだ無い。
 どこで生れたかとんと見当けんとうがつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。吾輩はここで始めて人間というものを見た。しかもあとで聞くとそれは書生という人間中で一番獰悪(どうあく)な種族であったそうだ。この書生というのは時々我々を捕まえて煮て食うという話である。しかしその当時は何という考もなかったから別段恐しいとも思わなかった。ただ彼の掌に載せられてスーと持ち上げられた時何だかフワフワした感じがあったばかりである。掌の上で少し落ちついて書生の顔を見たのがいわゆる人間というものの見始めであろう。この時妙なものだと思った感じが今でも残っている。第一毛をもって装飾されべきはずの顔がつるつるしてまるで薬缶(やかん)だ。その後猫にもだいぶ逢ったがこんな片輪には一度も出くわした事がない。のみならず顔の真中があまりに突起している。そうしてその穴の中から時々ぷうぷうと煙けむりを吹く。どうもむせぽくて実に弱った。これが人間の飲む煙草(たばこ)というものである事はようやくこの頃知った。
吾輩 は 猫 で ある 名前 は まだ ない
 どこ で 生まれ た か とんと 見当 が つか ない 何? でも すぐ 来 ジメジメ し た ところ で ニヤニヤ 泣い て い た こと だけ は 記憶 し て いる 我が家 ここ で 初めて 人間 という もの を 見 た しかも あと で 聞く と それ は 焼成 という 人間 中 で 一番 同 枠 な 修学 で あっ た そう だ この 焼成 という の は 時々 我々 を 捕まえ て 似 て くる という 話 で ある しかし その 当時 は 何? という 考え も なかっ た から 別に は 恐ろしい と も 思わ なかっ た ただ 彼 の 手のひら の 上 に 乗せ られ て ずっと 持ち上げ られ た 時 何ら か ふわふわ し た 感じ が あっ た ばかり で ある 手のひら の 上 で 少し 落ち着い て 焼成 の 顔 を 見 た の が いわゆる 人間 という もの を 見 始め で あろ う この 時 妙 な もの だ とか 思っ た 感じ が 今 でも 残っ て いる 第 一 系 を 持っ て 装飾 さ れる べき はず の 顔 が つるつる し て あれ で 夜間 だ その後 猫 に も だいぶ あっ たら こんな 形 に は 一 度 も 軸 は し た こと が ない 海 なれ ず 川 の 真ん中 が あまりに 突起 し て いる そうして その 穴 の 中、 から 時々 プププ と 煙い 洋服 どうも お 店 っぽく て 実に 終わっ た これ が 人間 の 飲む たばこ という もの で、 ある こと は ようやく この 殺し た

雑音をBGMにした音読

元の文章 解析結果
吾輩は猫である。名前はまだ無い。
 どこで生れたかとんと見当けんとうがつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。吾輩はここで始めて人間というものを見た。しかもあとで聞くとそれは書生という人間中で一番獰悪(どうあく)な種族であったそうだ。この書生というのは時々我々を捕まえて煮て食うという話である。しかしその当時は何という考もなかったから別段恐しいとも思わなかった。ただ彼の掌に載せられてスーと持ち上げられた時何だかフワフワした感じがあったばかりである。掌の上で少し落ちついて書生の顔を見たのがいわゆる人間というものの見始めであろう。この時妙なものだと思った感じが今でも残っている。第一毛をもって装飾されべきはずの顔がつるつるしてまるで薬缶(やかん)だ。その後猫にもだいぶ逢ったがこんな片輪には一度も出くわした事がない。のみならず顔の真中があまりに突起している。そうしてその穴の中から時々ぷうぷうと煙けむりを吹く。どうもむせぽくて実に弱った。これが人間の飲む煙草(たばこ)というものである事はようやくこの頃知った。
その はい は 猫 で、 ある 名前 は まだ ない
どこ で 生まれ た バトン と 健康 を 伝える 何 でも 人 ぐらい ジメジメ し た ところ で やや 泣い て い た こと だけ を し て いる 我が家 これ 初めて 人間 という もの を 見 た しかも あと で 聞く と それ は 小説 っていう 人間 中 で 一番 どう 悪 な 人 くらい あっ た そう だ この 焼成 と 言わ れる 時々 我々 を 捕まえ て 似 て くる という 話 で ある と しかし その 当時 は 何? という 考え も なかっ た から 別段 恐ろしい と も 思わ なかっ た ただ 彼 の 掌 が 添え て ずっと 持ち上げ られ た 時 片 中 ふわふわ し た 感じ が あっ て も 借り で ある 手のひら の 上 で 少し 落ち着い て 焼成 の 顔 を 見 た の が いわゆる 人間 という もの が み 一 で あろ う こういう 時 嫌 な もの だ と 思っ た 感じ が いま で お 乗っ て いる 大 事件 を 持っ て 装飾 さ れる べき 元 の 顔 は ちょろちょろ し て まるで 夜間 その後 猫 リンゴ 大和 が あっ たら そんな 方 に は 一 度 も 陸 が し た こと が ない のみ なら ず 川 の 真ん中 が あまりに 時 し て いる そして それ から 時々 ぷぷぷ だけ で よく 道 も 積極 的 に 終わっ た これ が 人間 の 分 は たばこ っていう の ある こと は ようやく この 殺し た

結果について

両者共通の結果
・句読点はほぼつかない
・文字間にスペースが入る
・読み方が何通りかある単語については漢字の間違いがある

静かな場所での音読
・変換ミスはあるものの、なんとなく意味は理解できる

雑音をBGMにした音読
・はっきりと聞こえた単純な単語は認識できているものの、一気に精度は落ちあまり意味は分からない

所感

漢字の間違いなどについては、Transcribeのカスタム語彙という事前に語彙を登録しておくような機能でカバーできるのではないかと思います。
静かな場所ではっきり話していればまあまあの精度で、雑音などが入るとかなり精度が落ちるので人間の声をしっかり聴き分ける能力はまだ低そうです。
今回は純粋に解析だけをした場合の精度検証なので深くは調べていませんが、音声を学習させるような機能もあるので、それを使用して精度を高めることもできそうです。
またレスポンスから何秒時点で何を話したかもわかるので、用途によっては活用できると思いました。

はじめに

Lambdaで外部モジュールのPillowを使おうとしてエラーが出ました。
今後も同じ状況が生まれる可能性があるので書き記します。

環境

ローカルPCのOS:Windows
言語:Python
外部モジュールはLambda Layerにデプロイして使います。
今回の外部モジュールの例はPillowです。(Pythonで画像を取り扱うモジュール)
Lambda Layerのデプロイ方法などはたくさん記事があるので本記事では割愛します。

エラー内容

エラーが出た箇所は以下です。

実際に出たエラー内容は以下です。
Unable to import module '関数名': cannot import name '_imaging' from 'PIL' (/opt/python/PIL/__init__.py)

原因

結論としては、モジュールのビルド方法がLambdaを動かしているOSに合っていないことです。
普段SAMを用いてLambdaにデプロイしているのですが、
Lambda Layerにデプロイするときは、ローカルでpipインストールしたモジュールファイルをデプロイしています。
調べていて知ったのですが、Pythonのモジュールによってはpipインストールするときに、
インストールしようとしているOSによってビルド方法が違うものがあるようです。
今回はWindowsでpipインストールしたものをデプロイしてエラーになっています。
requestsなど上記手順でデプロイしても動くものもありますので、モジュールによるのかと思います。

ゴール

Lambda LayerもしくはLambdaへのデプロイ時に使用する外部モジュールのファイル群の入手方法を記載します。

入手方法

調べていて、Amazon Linuxが入ったEC2でpipインストールする方法や、同じくAmazon LinuxをDockerで立ち上げて入手する方法が結構出てきましたがそれでもうまくいきませんでした。
そんな中たまたま開いた公式の記事に入手方法が書いてあったので、そちらを参考にしました。

1.https://pypi.orgを開くと上部に検索ボックスがあるのでモジュール名を入力し検索します。
2.検索結果です。任意のモジュールを選択します。今回はPillow8.4を使うので一番上を選択しました。

3.左のナビゲーションからDownload filesを選択
4.ファイルのリストが出てくるので、任意のWheelファイルを選択します。
左から3列目がPythonのバージョンです。
今回はPython3.9なのでcp39のうち
Pillow-8.4.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
を選択しました。
ものにより差はありますが、「manylinux_2」「x86_64」と入っている名前のものだとLambdaで動くようです。

5.ダウンロード&展開してファイルを使用

まとめ

上記手順で入手したファイルを使用することで見事Lambdaで動かすことができました。
今後も同じようなエラーが出た時はまずこの方法を試したいと思います。

こんにちは、エンジニアの野田です。
今回はAWSのサービス「RDS Proxy」について試してみたので
その結果を書いていきます。

RDS Proxyとは
その名の通りRDSの前に置かれるプロキシです。

使う目的
RDSではインスタンスタイプによって同時接続数が決まっています。
この接続数が埋まっている状態でアクセスが来た場合には接続失敗となります。
この接続失敗を避けるために、RDS Proxyを置きます。
こうすることによりRDS Proxyが同時接続数を超えた分の接続を待ち状態にし、
RDSが接続可能になるとRDSに接続してくれます。

いつ使うか
Lambdaでサーバーレスなシステムを構築するときです。
EC2などからRDSを使うときはいいのですが、問題はLambdaでサーバーレスな構成にしたときです。
Lambdaは性質上アクセスが来た分だけ起動します。
つまり大量アクセスが来てしまうと、その分全部RDSに接続しようとしますが、
ここで同時接続数を超えてしまいます。
なので今まではLambdaとRDSはアンチパターンとされてきました。

実験
実際ちゃんと動くか検証してみました。
方法としてはRDSからSELECTするプログラムをLambdaで書き、
apache JmeterからAPI Gateway経由でこれを叩きます。

条件
RDS:Aurora MySQLを使用、インスタンスタイプはt3.small
デフォルトの同時接続数は45(あくまで目安で実際は違います)
軽い処理だとさばいてしまうので、
10万レコード用意したテーブルからindex貼っていないカラムを指定してSELECTします。

計測ツール:apache Jmeter
100スレッド
10ループ
Ramp-Up 10秒

結果

RDS Proxyを使わない場合
1000リクエスト中
成功:637
失敗:363
成功したリクエストの処理時間は100ミリ秒~1000ミリ秒でした。

RDS Proxyを使った場合
1000リクエスト中
成功:1000
失敗:0
リクエストの処理時間は
同時接続数内のリクエストについてはRDS Proxyを使わない場合と同じ100ミリ秒~1000ミリ秒。
同時接続数を超えて待ちになった分のリクエストは2000ミリ秒前後でした。

まとめ
RDS Proxyを使うことで確かにすべてのリクエストをさばくことが確認できました。
注意点としては同時接続数を超えて待ちになった分のリクエストが2000ミリ秒前後かかることです。
実際にはもっとたくさんソースコードが書かれたプログラムになるのでもう少しかかると思います。
ただ同時接続内だと時間は変わらないので、非ピーク時は大丈夫だと思います。
判断基準としてはピーク時に時間がかかっても大丈夫かどうかだと思いました。
そこをクリアできれば今回のようにLambdaでもRDSを使った構成が実現できると思いました。

こんにちは、野田です。
1年以上ぶりの投稿になります。

今回はLambda×Pythonのフレームワークについて書きたいと思います。

最近AWSのLambdaで開発をすることが多く、何かフレームワークがないか探していました。
Pythonのフレームワークはいくつかありますが、特にAWSのLambdaに特化したフレームワークが
見つからなかったので、最小構成でアプリケーションを作るにはどうするか考えてみました。

結論からいうとSAMを使った開発が効率がいいかなと思いました。
SAMはAWSでサーバーレスアプリケーションを作るためのフレームワークです。
AWS SAM CLIを使用して開発を進めます。
SAMの使い方についてはほかにたくさん記事が出ているのでここでは割愛します。

ディレクトリ構成は以下です。
SAMを使う上で最低限必要なファイルと、アプリケーションを構成するファイルでできています。

├─ Application/
│ ├─ application/
│ │ ├─ __init__.py
│ │ ├─ config.py
│ │ ├─ dynamo.py
│ │ ├─ mod1.py
│ │ └─ mod2.py
│ │
│ ├─ Func1.py
│ ├─ Func2.py
│ └─ requirements.txt

└─ template.yaml

SAMを使ってデプロイする際に必要なのは
template.yaml
requirements.txt
の2つです。
普通、SAMを使う場合は最初にコマンドでプロジェクト作成して、
自動的にディレクトリやファイルが作成されたあと開発していきますが、
この2つがあれば動きます。

【template.yaml】
SAMはデプロイするときにCloudFormationを使ってLambda関数を作ります。
CloudFormationで使用する関数の設定ファイルです。

1行目AWSTemplateFormatVersionはテンプレート形式バージョンで
2020年11月現在有効な値は2020-09-09です。
2行目TransformはCloudFormationがテンプレートを処理するためのマクロで、こちらもこのままで大丈夫です。
3行目Descriptionはこのテンプレートの説明で任意の文字列です。
特に機能に関与しません。
4行目Resourcesの下から、関数の数分定義していきます。
6行目のFunctionsNameとしているところはこのテンプレート内で使用される名前です。
9行目のFunctionsNameはLambdaに登録される関数名となります。
12行目CodeUriで関数のファイルの場所を相対パスで指定します。
この例で使う関数ファイルはFunc1.pyとFunc2.pyでApplicationの直下に置いているので./Applicationとなります。
10行目は、ファイルの中のどの関数を実行するかの指定です。
例ではFunc1.pyのlambda_handlerという関数を実行したいので、Func1.lambda_handlerになります。
13行目以下はLambdaの設定です。
Environment(環境変数)でTZに対してAsia/Tokyoを指定しておくと
pythonのプログラムの中でタイムゾーンを気にする必要がなくなります。

【Func1.py】
これが実際にLambdaで動く中身です。

やっていることとしては、
・標準ライブラリの読み込み
・自作モジュールの読み込み
・ログ設定(logging)
・メイン処理
です。

application/に機能ごとにモジュールを作って置いてます。
application/は__init__.pyでパッケージ化しています。
例えばDynamoDBを使う場合は↓のような感じでモジュールを書いて、Func1で呼び出して使います。
application/dynamo.py


Func1.py

モジュール内でログを使う場合は、モジュールのファイル内でログ設定を書きます。
定数などの設定値はすべてconfigにまとめています。
なのでほぼすべてのファイルでconfigをimportしてます。

課題としては、
・よく使う機能(S3やRDSなど)を汎用的に使えるようにモジュール化する。
・本番やSTGなど複数環境がある場合にどうするか考える(現在は環境分ファイルを作ってます。)
といったことが挙げられます。

サーバーレス案件はこれから増えていくと思うので、
より効率的に開発できるフレームワークを作りたいと思います。

こんにちは、東京のサービスプロデューサー水野です。

11月23日から4日間、台北國際旅展(ITF2018)に行ってきました!

この展示会は世界60の国・地域の団体が参加(出展数は1,700ブース!)し、37万人以上が来場する台湾の巨大な旅行博です。

今回はクライアント様のインバウンド向けWebメディアのPR兼リリースほやほやのアプリDLをミッションに、
ブースディレクション・デザイン・運営、チラシ・ノベルティ制作を弊社にて担当させていただきました。

本展示会、一般の方は入場料を払って入場するため、 1つでも多くのノベルティを貰って帰ろうとする方が多いです。DLもどんどん進みました。

デジナーレでのUI/UXの企画・提供事業はWeb制作だけではなくリアルのデザイン提供も行っています。
もちろん今回のように展示会運営の企画・支援も行っています。
まるっとご相談くださいませ。

お問合せはこちらから

台北の展示会に行ってきました!(裏)

※ここからは私的な内容がメインです

今回の旅行博、いろいろなことがありました・・・

  • 作業中にズボンががっつり破ける。(腰から膝裏ぐらいまで破けました。)
  • 腕時計のベルトが切れる。(全く亀裂もなかったのに、スパッといきました。何故?)
  • 正面ブースのモニター付き壁がこちらに倒れてくる。(怪我人もなく無事でした。モニターも無事でした。)
  • 朝来ると、ブースの倉庫との仕切りの蛇腹式扉が真っ二つに破られている。(事務局が作業で倉庫に入りたかったらしいです。合鍵とかもってないんですね。。。)
  • ある日PR中サービスのFBフォロワーが一気に減る。(システム的な感じがします、スタッフの士気上げも一苦労。。。)


しかし、

最終日、自ブースのノベルティ配布も終わり、ふらふらと会場を回っていいコトが2つ!

スターフライヤーさんの素敵なノベルティシールをもらった!
他にもノベルティをいろいろ見ましたが一番のお気に入りです。 福岡オフィスとの行き来に是非スターフライヤーさん使わせていただきます!

愛媛・大分県ブースで松山マドンナ大使の冨士菜々香さんと出会った!
撮影をしようとしたら、「一緒に撮りませんか?」と声をかけていただき、全ての疲れが吹き飛ぶぐらい癒されました。松山行きます!

こんな私と東京で一緒に働いてくれる仲間を募集しています!
Webディレクター、Webデザイナー、フロントエンドエンジニアの方々、ご連絡お待ちしております!

採用情報はこちら