読者です 読者をやめる 読者になる 読者になる

iOS Creators' Meetup #2 に参加しました

@kanamorit です。よろしくどーぞ。

iOS Creators' Meetup #2 に参加しました。

oi-study.connpass.com

オイシックス株式会社 さん主催の勉強会で「iOS に興味があればどなたでも!」というものです。
主催者の @akatsuki174 さんの挨拶で開幕。

f:id:kometubuo:20161015173302p:plain

勉強会心得

友達作るの大事だから!

  • 名刺交換はするでしょう
  • でも名刺交換した後、それ何度触る? 触らないでしょ!?
  • SNSで繋がろう

slackに参加して発言してね


発表一覧

  1. AutoLayoutのデバッグを試みる
  2. オブジェクト指向な人が RxSwift を試してみた
  3. スマホアプリディレクターが考えていること
  4. Realm Mobile Platform をさわってみた
  5. iOSアプリにおけるリリースフローとCI環境
  6. iOS10からのプッシュ通知再入門
  7. コンテキストを意識したアプリデザイン

内容も多様で、iOSエンジニアじゃないよって方も何人か発表されていました。
資料はこちらにまとめがあります。

iOS Creators' Meetup vol.2 - 資料一覧 - connpass

発表内容

AutoLayoutのデバッグを試みる

@akatsuki174 さん

実行時に AutoLayout でエラー出ることあるよね → どうデバッグしようか、というお話

  • 制約ミスっててもなんとなく表示はされてるけど、実際には一部制約を勝手に取り除かれてる
  • 制約問題の発見のために symbolic breakpoint を作成しよう!
    • 特定位置ではなく特定 条件 で処理を止めることができる
  • 処理が止まったら lldb で対象オブジェクトの背景色変更指定してみるとわかりやすいよ!

オブジェクト指向な人が RxSwift を試してみた

@grachro さん

関数型のライブラリ調べたところ RxSwift がしっくりきたので使ってみた

ココが良かった!

  1. オブザーバーパターンで理解可能
    • RxSwift も大体同じ構造じゃん!
  2. メソッドチェーンは「流れるようなインターフェース (fluent interface)」じゃね?
  3. マーブル図なら時間の流れ(経過)がわかりやすい!
    • UMLで表現するのは大変だったから嬉しい><

スマホアプリディレクターが考えていること

@kurikazu さん 噂のStoryBoard120枚女子は隣の席

世の中には様々な問題がある

  • 「全機能作って」問題
    • 例)SNSに仕事情報共有する機能欲しい
      • LINE、Twitter、Fb、メール、・・・それぜんぶ使う???
    • 誰がどう使うのかちゃんと考えよう
  • 「Webと同じで」問題
    • Webとアプリで揃える施策はある
      • でもなんでもかんでも揃えようって思考停止になってない?
    • アプリは一度機能追加すると取り除きにくい・・・
      • アプリに必要なのかはまずWebで様子を見てからにしてもいいよね
  • 「アプリって必要?」問題
    • アプリってインストールする手間があるよね
      • Web側の比率が高い場合割とネック
    • アプリならではの存在感出さないと!!
      • でも「スマートフォンのサービス」と捉えるとアプリって必ずしも要らないのかも?
  • 「開発と企画のゴール違う」問題
    • 開発としては新しい技術取り入れたい。でも企画は早く作りたい。
      • 理解してもらうにはどうすれば・・・
      • すごい人に聞いてみた → 「偉い人になれ!」
    • 判断する人に「あいつが言うなら」と言われるよう信頼を積み重ねよう

役割は違えど 思い は同じだよね

よろこばれるアプリを作っていきましょう!

Realm Mobile Platform をさわってみた

KinyoKou さん

データ同期が恐ろしく簡単にできる
  • でもサーバは自分で用意するんだよ
  • オフラインでも動作するよ(オンラインになった時に同期が走る)
  • 手順は公式のチュートリアル見ればもう何も心配無い
    • syncConfiguration で情報設定すればおk
コンフリクト解消が重要
  • 基本ルール
    • Deleteは常に最優先
    • 同じプロパティのUpdateは後勝ち
    • Insertは時系列順
  • 「Update後勝ち」が曲者
    • 同じプロパティを同期
      • 何度か試すと先勝ちパターンもあった!?
      • タイムスタンプ以外のロジックも働いているのかも
    • 同じオブジェクトの別々のプロパティを同期
      • 同期はプロパティ単位で行われる
      • あっちとこっちで変更されて思いがけない状態になる可能性も!?
  • コンフリクトの解決についてはしっかり理解してからやるべき
    • 今後の公式ドキュメント要チェック

iOSアプリにおけるリリースフローとCI環境

@tarappo さん iOS Test Night #1 よろしくね!

リリースフローでコスト多くない?
  • 作って端末渡して検証してバグ出た報告して端末返してとかとかとか
    • コミュニケーション多い?手動多い?
    • CI環境を開発メンバーしか知らないとかない?
    • 開発環境全体でコンテキストスイッチ多く無い?
検証フェーズとにかく早くしよう!
  • 開発は Git への Push だけ意識
    • アカンかったら Jenkinsおじさん が怒ってくれる!
    • コードレビューはコストかかるので静的解析やら何やらの自動でできるものはおじさんに任せる!
      • ビルドやら何やらで時間がかかるなら マシンパワーを良くして時間を短くする
    • 問題があれば slack に飛ぶ
  • 検証は頑張る
    • DeployGate での配信作業もおじさん
    • バグ報告は手動><
    • 報告があれば slack に飛ぶ
  • アップロード
    • おじさんボタンをポティットナ!

コンテキストスイッチを「その人に仕事がある時」だけにしよう
そのためには CI 環境をプロダクトに関わるすべての人に必要なものとしよう

iOS10からのプッシュ通知再入門

@jollyjoester さん Tシャツで語る「すべて熟知」

プッシュ通知は「リテンションのための唯一の手段」とも言えるくらい重要

(送信方法の紹介とともにデモも準備されていたが、時間が足りずだったので)

プッシュ通知送ってると楽しくなってくる
  • Repro ってサービスが通知送るのにいいらしい
  • 効果的な送り方もわかっちゃう メディア もあるらしい!

コンテキストを意識したアプリデザイン

@3mp さん

UX MILK への寄稿 & UX JAM への登壇 募集中!

UX MILK 立ち上げの理由は UX がわからなかったから
  • UXという言葉大嫌いだった
  • オリジナリティ溢れる、イケてるアプリを作りたい
    • 自分のアプリが特別にみえちゃう病
      • 独りよがりな開発
    • 馴染みのない UI でユーザーが混乱
      • 認知負荷 = Cognitive load
    • ユーザーが欲しいのは便利なサービス体験!
  • どう独りよがりデザインから脱するか・・・?
プライドを捨てて、パクるべし(但し、正しく)
  • コンテキスト意識
    • ライフスタイル
      • いわばユーザーの利用状況
      • 明確に把握すれば「MUSTな機能」が明確に
    • マーケット
      • 周辺サービスのトレンド・スタンダード
        • フリマアプリって商品の並び方こんな感じだよね、とか
      • トレンドに乗れば「戸惑いを減らせる」
  • 例)UX MILK App
    • 平日朝、通勤時に電車内で
    • タブレイアウト、ミニマルデザインを採用
既存のアプリをパクる
  • = 先人たちが切り開いたUXをリスペクト
    • 通称: Paku-Respect
  • ユーザーは自然に使えるものが「使いやすい」
    • 考えさせないのがいいUX
  • 工数削減にもなる
    • モチーフあるから意思疎通が明確
    • エンジニアがUIデザインを進められる
      • ある程度できてから細かい部分の調整をする
こんなのはダメパクリ
  • サービスのアイデンティティをパクる
    • 象徴的なものは避ける
      • ロゴ / マスコット / カラー / トーン など
  • 同じアプリからいくつもパクる
    • 全パクリになっちゃう!

トレンドを踏襲するという気持ちが大事

まとめ
  • 変なこだわりは捨てて、まずはトレンドに従う
  • その上で、オリジナリティを盛り込む
    • あまり主張しない程度がちょうどいい塩梅なのかも
      • ローディング中とか未ロードサムネとか
    • メインのユーザー体験は損なわないように!

感想

実践的な内容もあれば教訓的な内容もありで楽しかったです。
一番場が湧いたのは「全機能作って問題」などの苦労話だったかも。
個人的には「パクリ大事」という再確認?が納得感あって良かったです。

しかし、弊社内では「OSの世界観」と「周辺サービスのトレンド」がズレてしまっているがためになかなか悩ましい状況になってしまっていたり。。。
どういうユーザが使ってくれているか、を考えるとどうしても周辺サービスに合わせる結果となりなんだか古くささが抜けない(>_<)
新しいユーザーを獲得するためには意思決定者を説得しなければ。

そのためにはやっぱり 偉くなって 提案するしかないのだろうなぁ・・・


懇親会ではお野菜が出ましたが、これがまた美味しい。

  • 生で食べられるカボチャ : カボッコリー
  • 瑞々しくてほんのり甘いピーマン : アップルピーマン

f:id:kometubuo:20161015182848p:plain

(なぜラップを外して撮影しなかったのか)

特にカボッコリーは色んな味付けで楽しめるし、シャキシャキとした食感も良くて本当に美味しい!!
クックパッドにも調理法載ってるのでぜひぜひ!

カボッコリーを食べたい方は注文しよう!

www.oisix.com

CollaboTips #2 でデザイナさんと仕事して学んだことを発表してきました

CollaboTips #2 で発表させていただきました。

collabotips.connpass.com

デザイナさんとの仕事はただ開発者同士で仕事をするのとは異なる経験や悩みを多く得られます。
内容は良くも悪くも色々ですが、そこでの体験を通じて貴重だったと思うものについて書いてみました。

というより「それなくして協働できない」というものだと思っています。

発表資料はこちらです。

speakerdeck.com


資料の中で「うまくいった」と感じた時はいくつかの条件が重なったのも大きかったと思っています。

  • 少人数(2人)だった
  • デザイナさんとのやりとりのリズムが合った
  • 誰からも検討の邪魔をされなかった

だからこそ、お互いの良いと思うことをそのまま実践でき、「関係者の確認待ち」だとか「共有ミーティング」だとかいった余計な手間を排除できました。

当時利用したコラボツールとしては POP や Prott などがありますが、最終的には Prott に落ち着きました。
この辺りはデザイナさんが使いやすいものが選択されるのが一番だと思います。

また、プロトタイプ開発においてはビルドしたものをすぐに見せに行き、
そのまま端末を置いて帰る→端末を返してもらった時に意見交換する、といった流れが多かったです。
端末を渡すことでそれぞれの作業を止めることもないですし、「うっかり確認忘れ」が起きることも減るのかなと思います。

本当は配信して多くの人に見てもらって意見もらって、って方が良いとは思うのですが、
説明が面倒だったり、確認待ち時間が発生したりといった微妙な「ラグ」が作業リズムを狂わせてしまうように感じます。
この辺りは今後の課題として優先的に解決したいです。

こうした経験を通じて、時間的にも精神的にも「ラグ」を発生させない為に最も重要なことは

相手の考えを受け入れること

だと思っています。

今回の資料では各項目を列挙しているに過ぎないため、別の機会でいくつか掘り下げてみたいと思います。


iOS 界隈の人が多いのか、 Storyboard を使うかどうかという話をちょくちょく見かけます。
ですが、 Android ではどうなの?触らない?触れない?触らせたくない?という疑問もあったりします。
(積極的に触ろうとは思わないので、そんなものなのかな、くらいの感想ですが。。。)

ただ、デザイナさんが色々触れるようになるのは素敵なことだよなーと思う反面、その必要性に迫られているとしたら "変更内容の共有や確認" がネックになっているという気もします。

どのような解決策が将来においても有効なのかはわかりませんが、個々人のスキルセットの充実度に頼るやり方よりもそれぞれの専門性が活かされる仕組みの方が素敵だと感じます。

SIMトレイを別機種のものに挿した結果 解決編

@kanamorit です。よろしくどーぞ。

SIMトレイを別機種のものに挿した結果 - kometubuo’s diary の続きです。

SIMトレイを取り出すため App Store 渋谷店 に行きました。
予約していた時間に到着すると Genius Bar は超満員でしたが 5 分程で Genius が担当してくれました。


爽やかなお兄さんGenius(以下Genius)「なるほど、つまりSIMトレイを取り出したいと。」

私「はい!」

Genius「んー・・・」(SIMピンを挿してみたり爪を引っ掛けてみたり

Genius「無理ですね。。。」

私「ですよね。やっぱりサイズ違うせいですかね。」

Genius「ええ、トレイのサイズは端末種類で異なりますので。」

Genius「技術者に持っていってガチャンとやってみていいですか?」
Genius「データ無くなったり損傷したりする可能性あるんですが・・・。」

ガチャンってなに!!?!?

私「はい、大丈夫です。」

Genius「わかりました!ちょっとやってきますね!」

スタスタスタスタ

〜10分後〜

Genius「kanamoritさん!」

私「はい!」

Genius「取れましたよ!!!

私「おお!!」

SIMトレイの外れたiPhoneを置きながら、

Genius「いやー、スタッフ数人がかりでなんとか取れました!」
Genius「(トレイの)サイズ違うんでね、ほんと気を付けてくださいね!」

私「ありがとうございます!ありがとうございます!」

Genius「他に何かありますか?」

私「大丈夫です!!」

Genius「では気を付けてくださいね!!」

私「ア、ハイ」


そして次の方を担当しに別の場所へ去っていくお兄さん。
念押しで注意を受けながら Genius Bar を後にしました。

本当にありがとう!
App Store 渋谷店 Genius の方々!!

いったいどうやって取り出したのかを聞き忘れたことだけが心残りですが、解決できてよかった。
もしやってしまったって方は Genius Bar を頼ってみてください。

SIMトレイを別機種のものに挿した結果

@kanamorit です。よろしくどーぞ。

iPhone の開発をしていると、β版インストールするためにリストアする、なんてことがよくありますよね。

私も何度かリストアを行っていたんですが、その度に必要となるのが アクティベート です。

そのためには SIM を挿している必要があるんですが、そんないくつも回線契約をしているはずもなく、リストアの度に入れ替え作業が発生します。

そこで犯してしまった SIM トレイを別機種のものに挿すというミス。。。

(解決した時の話を見たい方は こちら


今回は iPhone6s の SIM トレイを iPhone6Plus に挿してしまいました。

わずかな抵抗を感じたものの、大体いつもそんなものなので奥まで押し込みそのままアクティベートも完了。
じゃあ元の端末に戻そうか、と SIM ピンをぐっと押し込んだところ、、、

抜けん!!!

押しても押しても反応しない!!!!!

お察しの通り、端末によって SIM トレイのサイズが異なるため、無理に挿した結果抜けなくなってしまいました。

6Plus も使えるけど、普段使うには 6s の方がいい。。。
そもそももうすぐ iOS10 出るのに、今後入れ替え出来ないとかキツイ。。。
やばい。。。


ということで、 Genius bar による解決を図ることにしました。
予約をしたかったので以下の流れで選択選択。

  1. Apple Store のページから Genius bar を選択
  2. 機器の問題 - その他の問題 と進み、自由入力欄に「SIM」と入力
  3. 選択肢に「SIM が取り出せない」が出てきたので選択
  4. AppleID に紐付いた端末選択かシリアル番号入力を求められる
  5. 該当の端末を選択して解決方法(電話、チャット、予約など)を選択

とここで、チャットだとどんな感じになるのだろう、と思いチャットにすることに。
チャットを選択すると以下のような画面になります。

f:id:kometubuo:20160906223706p:plain

そして、別ウィンドウで以下のページも開きます。

f:id:kometubuo:20160906223712p:plain

じーっと待ってると「フオン」通知音が鳴り、画面に以下のメッセージが出ました(5分くらい)。

f:id:kometubuo:20160906223821p:plain

忙しそう。

ということで、何か別のことでもしてようかなと考えていたら数分後、

「フオン」

!! キタ!

思ったより早く連絡がきました。
最初に定型文的なメッセージが送られてきて、状況確認へ。

f:id:kometubuo:20160906223907p:plain

「なるほど...」となったものの解決するには店舗に行く必要があるとのこと。
店舗候補を出してもらえるとのことで郵便番号を伝えしばらく待つと、リンクが貼られました。

良い候補があればこちらで予約するので教えて、ということでリンクをクリック。
するとチャット画面が別ページに切り替わり、右側に地図、左側に候補(AppleStoreや代理店など)が表示されました。 候補の目星をつけて戻ろうとすると・・・

「戻る」ボタンが見当たらない!!

えー。。。

チャット画面に戻れなくなり、どうしてよいかわからなかったため、「新たなチャットセッションを開始する」を選択してみたところまた最初の待機画面になってしまいました。
(今思えば (メニュー)表示 - 戻る を選択すればよかったのでしょうけど、過ぎてしまったものはもうどうしようもないので忘れます。)

新たなセッションを開始してから数分。。。

「フオン」

!!! キタ・・・!(2回目)

今度はさっきと違う担当者になり、またも定型文的なのが流れ出した後状況確認へ。
さっき切っちゃったけどSIMトレイ出ないやつなんですと説明すると、

f:id:kometubuo:20160906224339p:plain

や、優しい。。。

その後やり取りしていた内容の続きから、ということで再度リンクを案内され、(今度はリンクを踏まずに)予約したい店舗を告げたところ、予約の空き時間を確認してそのまま予約 Done!!

あーよかった。と思っていたら、最後に心配性な発言が。

f:id:kometubuo:20160906224413p:plain

しっかり十分な対応を頂きました。
ありがとうございました!

ということで結局店舗に持ち込むことにはなりましたが、チャットでのやり取りもスムーズだし、丁寧でしっかり説明してもらえるので悪くないなーと感じました。

店舗への持ち込み編 に続く...

iOSDC Reject Conference day2 参加レポ

@kanamorit です。よろしくどーぞ。

iOSDC RC に参加しました。 day1はこちら

iosdc-reject-conference.connpass.com

今回も個人的に気になったものだけピックアップします。


iOSアプリ開発のテスト環境

@tarappo

アデノウイルス

  • 4day~7day 高熱に耐える病気
  • 罹ったら耐えよう!
  • tarappo さんは耐えた!そして今日来た!!

SWET (Software Engineer in Test)

  • ミッション
    • サービス全般の品質向上
    • エンジニアの開発生産性向上
  • 事業サポートチーム / テスト基盤チーム に分かれる
  • DeNAが取り組む Software Engineer in Test
  • テストを書く、伝える、浸透させる、場合によってはプルリクも出しちゃう
  • DeNA さんの中ではゲーム系を担当することが多いが、ツールも言語も幅広く対応できることが求められるとのこと

大事なこと

開発について

  • (Apple的な)制約はたくさんある
    • 過去から比べるといろいろ出来るようになってきた
    • ただし、「コレさえあれば!」というものは無いのでプロジェクトに応じて選ぼう
  • いくつかを駆使してテストを書くとよい
    • 1個でやろうみたいな変なこだわりは要らない
  • テストの関数名は test~ となっていればよい
    • テスト内容は日本語でおk
    • クラス名も日本語でおk
    • 名前付けで困ってコミットできないなんて現象とはおさらば!

環境について

  • リリースフローも自分たちに合うものを考えよう
    • 基本的にテスト結果は目に入るところへポスト
  • テスト結果は JUnit 形式を選択するとよい
    • Slack へのポストもいい感じになる
  • お金出せるなら実行環境はクラウドでいいでしょう
    • 端末用意も要らない
    • テスト時間長ければどんどんお金かかる!

お知らせ

  • 9/14 (Wed) 19:00~ Test Engineers Meetup #1
  • SWETメンバーも募集しているみたい!

JSON-RPC on APIKit

@_ishkawa

よくある悩み

  • リクエストとレスポンスの組み合わせをいい感じに解決したい!

解決

  • APIKit
    • リクエストの型に応じてレスポンスの型を変える
  • JSONRPCKit
    • リクエストとレスポンスを JSON で表す
    • 1回の通信で複数リクエストが可能
      • Array で送る
      • リクエストとレスポンスは id で紐付け
    • JSON-RPC のための library

それぞれの思惑も解決

思惑
Server APIはシンプルにしたい
Client 1画面1リクエストにしたい

 →利害が一致!

Swift の落とし穴

  • Swift には可変長の型パラメータがない
    • 任意の個数の型の組み合わせができない
  • 標準を参考に Equatable の実装を確認
    • 事足りる分のパラメータ数までオーバーライド
    • Swift4 or later で Variadic Generics (可変長) が実現されるかも?

魅せるデバッグ技術

@dealforest

デバッグ方法

  • プリントデバッグ
    • ログを仕込んで動かす
  • 脳内デバッグ
    • あれかな?これかな?と原因として考えられそうなものを考える
  • LLDB
    • そのタイミングでの変数情報などが得られる

この中だと LLDB 使えば幸せになれそうだね。
とはいえ、何かある度に同じような作業を何度もするとなると・・・

LLDB の Plugin を作ろう!

メリット

  • デバッグ時に debug / release ビルド分けるとか気にしなくていい
    • #ifdef DEBUG マクロの呪いからの解放
  • プロジェクト変わっても同様に使える
  • debug 用コードも必要ない
    • debug の為に private method 呼ぶ必要もない
    • うっかりそのまま審査に出すみたいなこともない!

Plugin の開発方法

dealforest.hatenablog.com


初っ端のスピーカーが遅れるというトラブルがありつつも、本日も楽しく盛り上がっていました。 ざっと見た感じですが、 day1 よりも参加人数が多かったように思います。

これにて iOSDC Reject Conference は終了となりました。 主催の @akatsuki174 さん お疲れ様でした。 そして会場提供してくださったメルカリさん、スタッフ、スピーカー、参加者の方々、ありがとうございました。とても楽しめた会でした!

iOSDC Reject Conference day1 参加レポ

@kanamorit です。よろしくどーぞ。

先日 iOSDC RC に参加しました。

iosdc-reject-conference.connpass.com

  iOSDC にトーク応募したけど採択されなかったよ;;

という発表を対象にした会で、主催者である @akatsuki174 さんが「こんなのあったら面白そう」と Tweet したことから開催されるに至ったものです。

1日目は当日スタッフとして参加しましたが、会場準備などはメルカリさんがやってくださってました。結果、タイムキーパーとしてベルを鳴らすだけの簡単なお仕事だったのでその辺は割愛します。(ベルが鳴っても発表が終わらないことが 1, 2度、3度くらいあった気もしましたが大丈夫でした。)

ということで、 day1 のなかでも個人的に楽しかった発表について調査も含めて記します。


Swiftで日本語プログラムに挑戦

@codelynx1

将棋を題材に

  • enum で 歩、金、角、などを定義
  • 盤上のひとマスの状態も 空、先歩、など
  • 局面も日本語で表現

将棋盤Kit

気づいたこと

  • 日本語だとクラス名と変数名が同じになる
  • 名前に単数系・複数形がない
  • そもそも日本語だと命名やりにくい。。。
  • でも型名・enumなどはいい感じに設定できる
  • 違和感はあるけどノウハウたまればなんとかなる・・・?
  • でも国際対応狙ってるなら日本語は向かない!

遭遇した問題

  • storyboard に日本語名使えない
    • Apple にバグレポ中
  • 文字化けするシーンもある

まだJPEGで消耗してるの?〜WebPで創る快適新聞ライフ〜

@TamaObject12

少しでも画像の通信量減らしたい・・・

WebP (ウェッピー)

iOSでの利用

性能/画質検証

  • JPEG vs WebP
  • 128px ~ 2048px まで 5 種類用意

ダウンロード 〜 表示 までにかかる時間

形式 性質(比較)
JPEG DL 長め(ファイルサイズ大), デコード短い
WebP DL 短め(ファイルサイズ小), デコード長い
  • 画像サイズが大きいほど時間短縮になる(DL時間の影響)
  • 素数が多い画像を多用する場合は有用そう

画質判定

  • SSIM
    • 2つの画像がどの程度似通っているかを判断する手法
    • 0.95 以上なら OK と判断
  • サイズが何%減少と言っていたのは、この SSIM での判定で OK となった画像に対して

watchOSでモーション認識

@shu223

iOSDC も出てます

モーション認識

CMDeviceMotion

  • Apple のサンプルにテニスのフォア・バックハンドを検出するものがある

ポイント

実演

  • スピーカーと BT で接続し、判定結果を音声再生

ゆっくりじっくりと構え、ウォッチをつけた右手をスイング!(ゆっくりめ)

スピーカー「フォアハンド」

さらに右手を左手側に回してからスイング!(ゆっくりめ)

スピーカー「バックハンド」

会場中拍手!!!

  • 後で聞くところによると、発表中も繋ぎっぱなしにしていたようで、ネタバレしないよう慎重に動いていたとか
  • サンプルなので誤検知も多いが、サンプル量を増やしたりログ解析をすればよりよいデータが得られるのではないかということでした

当日は台風の影響もあってやや参加者は少なめかなと感じましたが、それでも会場内に 50 人くらいはいたと思います。
スピーカーも聴衆もお酒を飲みつつ始終和やかで楽しげな雰囲気でした。

day2 に続く

iOSDC 2016 参加レポート(当日スタッフ:受付)

@kanamorit です。よろしくどーぞ。
iOSDC 2016 に当日スタッフとして参加しました。

iosdc.jp

「ブログを書くまでが iOSDC です。」

というお達しがあったので、その時のことを書こうと思います。

私は 当日スタッフ として参加したのですが、コアスタッフと呼ばれる初期の頃から参画されている中心人物達とは別に、当日のお手伝いをする形でした。
その当日スタッフもいくつかの仕事に割り振られるわけですが、希望した「受付」を担当させてもらえたのでそこで感じたことをつらつらと書きます。
(セッションの内容などは他の方の記事を見ていただけたらと思います。)

受付作業

概要

今回、受付で行った作業は以下の 5 つです。
午前中はこれらを12~14人くらいで分担しました。

  1. チケットの QR コード読み取り
  2. ノベルティの受け渡し
  3. ネームカードの受け渡し
  4. 懇親会用リストバンドの受け渡し(参加者のみ)
  5. Tシャツ受け渡し

作業がそこそこあるとは言え、そんなに人数が必要かな?と思われるかもしれませんが、
3.~5. までの作業は参加される方に応じて個別対処の必要がありました。

  • 3.はチケット購入画面を確認して特定のネームカードを渡し、
  • 4.は懇親会に参加するかどうかをネームカードに貼った付箋で判断してリストバンドを渡し、
  • 5.はネームカードに書かれた参加区分+服のサイズを確認して適切なものを渡す

という作業を来場者本人にも間違いがないか確認しつつ進めています。

【全体図】 (手書きで見にくいですがご了承ください) f:id:kometubuo:20160825011112j:plain

受付改善作業

前夜祭の日に集まってその場で受付の流れを確認し、スタッフ同士で練習し、あれやこれやと改善案を出し合ってという具合で進行しました。
前夜祭は平日ということもあり人が少ないことが想定され、練習にはうってつけだったというのも幸いしました。
そこで実際に改善したのは以下です。

ノベルティ受け渡しの場所変更

もともとは以下の図 2 番の位置でノベルティをお渡しする、という手順でした。

【最初の構成】 f:id:kometubuo:20160825011249j:plain

  • 渡すものが連続しすぎて説明が追いつかない
  • 受け取る側もあれやこれや次々に渡されて大変
  • 来場者が増えると捌ききれないと判断

ということで必ず渡すノベルティについては受付最初で渡すことにしました。

案内板の設置

来場者ごとにネームカードが別となっているため、購入チケットの 区分番号 を確認して
所定のカードが置かれた列へ振り分けるという行程がありました(その役目が分配役)

これについて以下の役に立つのでは?と案内板を設置して書き込みをしていました。

  • 各列のカード情報
    • 分配役が誰をどの列に誘導すべきかを知るため
  • 受付開始〜終了までの流れ
    • 列への振り分けを待っている方が現状を把握するため

そしていざ受付開始となったら、各列のカード情報については役立ったようですが、
受付の流れに関してはあまり役立った印象はありませんでした。

列への振り分け待ちが発生するほど大挙するという場面がなかったんです!!!

ネームカードの置き方調整

100 枚くらいの束を 20 枚くらいずつに分けて置いた、というだけです!
カードの束から目的の 1 枚を探すのはなかなか大変だったのです!

細かな配置の修正

  • 来場者が進行方向間違えないようイスでブロックしたり
  • Tシャツの受け渡しをしやすいように箱の位置を動かしたり
  • 受付スタッフ用にイスを持ってきてみたり
  • 人の入りが少なくなったら作業スペース縮小したり

などなどそれぞれで気づいたところを細々と調整しています。

改善余地

何度もスマホ画面を見せてもらう必要がありお互いに面倒

受付番号と購入区分の確認のため

  • 1.QR読み取り と 3.ネームカード受取 を同じ場所で行えば、その先はネームカードの確認のみで済むためスムーズだったかも。
    • つまりは、 受付ゾーン と ノベルティゾーン の分離
  • 問題は作業スペースの確保

ネームカードを受け取った方が、Tシャツに目もくれず進もうとする事が何度か発生

受付に人だかりが出来ると、それを迂回する形になるためそのまま進んでしまう結果に。。。

  • 一応案内板に書いてたけど見てもらえてなかった
  • これも 受付ゾーン と ノベルティゾーン の分離で解決できていたかも

【迂回する図】 f:id:kometubuo:20160825011253j:plain

どこで人数を減らしてよいのか、交代タイミングはどうするか、がうまく決まらなかった

来場者の流れが掴めない、というところがあったため人数調整が曖昧な感じでした。
(エンジニアは基本昼くらいに来るんじゃない?みたいな説も飛び交っていました)

長めに受付作業を続けた方もいて、時間分配次第では柔軟に休憩するなり他の場所へ目を配れたりといったことも出来たかもなぁと思います。

当日進行

当日は TL 監視をしながら slack で連絡を取り合っていました。
主に全体に気を配る担当の方々が中心となり、

  • 空調の調整をしたり、
  • 会場のライトの加減を変えてみたり、
  • 発表者の飲料水を調達したり、
  • アナウンスの内容を伝達し合ったり、
  • 人手が必要になった所へ要請をかけたり、

といった具合です。

その場での気づきをすぐに共有し、次々に改善していく、スタッフのレベルの高さが感じられて非常に刺激になりました。

また、実行委員長の長谷川さんが方々に出現し、トラブルを小さなうちからスピード解決していただけたので大きなトラブルとなるものはありませんでした。(さすが!)
(受付作業自体にいくつかミスもあり、ご迷惑をおかけした方々にはこの場をお借りして謝罪申しあげます m( )m)

全体を通して

楽しい(^q^)

1日まるまる本当に楽しかったです。
それなのに前夜祭もあれば、事前準備会(親睦会)もあって全部楽しい!
何が楽しいって「同じく成功を願う人たちと活動できる」という空気感がイイ!
そして友人も増えました!やったね☆

美味しい(^p^)

懇親会の食事がすごかった。。。
その場で作るチーズバーガー(潰れてない)やケバブサンドに数々の料理、鞠花のビールサーバがあったり BrewDog が飲み放題(に近い状態)。
当日スタッフも美味しく召し上がらせていただきました(^p^)
スポンサー様ありがとうございます!!

無理がない(^-^)

これはひとえにコアスタッフの方々と周りのみなさんのおかげでした
しっかり段取りされており、それぞれが役目を果たし、終始順調に進みました。
サポートしあえる人数がいたこともとても良かったです。

まとめ

つらつらと感じたことを書いてしまいましたが、つまるところ、

iOSDC 最高でした!

スポンサーとして支援いただいた企業様、個人の方々、本当にありがとうございました。
委員長の長谷川さんはじめ、コアスタッフや当日スタッフのみな様、ご苦労様でした。
参加された方も楽しんでもらえたのなら私もスタッフ参加してよかったと思えます。

きっと来年も開催されると信じています!
来年もみなさんで盛り上げましょう!!
そのために今から iOSDC スゴイ感を吹聴していきましょう!!!

リンク集

iOSDC

https://iosdc.jp

AbemaTV

Youtube