DIST.11 「プロトタイピング」

概要

• 日時：2016年5月25日（水）19:00～22:00（18:30開場）
• 天候：晴れ
• 場所：ICTCO
• 申し込み：connpass

参加者

種別	参加	キャンセル
通常参加枠（本編のみ）	40	40
通常参加枠（本編＋懇親会）	38	24
スタッフ枠	10	1
合計	88	65

• 上記はconnpass上の数字
• 二次会: 17人（＠俺ん家）

参加者からの疑問・質問

• アニメーションにおける動き速さはどこまでプロトタイプで再現しますか？（私はたまにPixateを使います）
  • 私の文脈におけるプロトタイプでは動きや速さの質はまったく担保しません。必要な場合は、最終成果物を作るときと同じ技術で作ると思いますが、それはもはやプロトタイプというよりは専門家によるスタディに近い気がします（沖）
  • それが本質的なところを担っているのであれば、必要十分な状態まで追求します。案件によってはアニメーションのみで提案することもあります。沖さんの仰るように、それは今回の勉強会でいうプロトタイピングの枠というよりもスタディなのかも知れません。（奥田）
• Adobeのツールの実務のフローでの活かし方など
• Adobe XD。 数あるプロトタイプツールの中で Adobeが作るからこそのメリットを知りたい。例えばPhotoshopとの連携が強力とか。なんどか使ったがインポート・エクスポートができずあまりメリットを感じなかった。
  • Adobe XDは、月一で行われるベータリリースもまだ3回目で根幹を磨いている状態です。イベントの最後にAdobeの轟さんがハブになるアプリになると話していましたし実装を楽しみにまつ段階だと思います。作ってる段階の今こそ、こういうのがほしいは積極的に発言＆voteすると良いです。(湯口)
• デザイナー、エンジニアの方からマーケティングチーム・企画チームにプロトタイプ開発をツールから導入しようとしても（Prott、inVisionなど）操作の敷居が高かったり、積極性に欠け浸透しない。ツールから入るべきか？　開発手法の意識合わせからか？
  • 操作の敷居を下げるのであればペーパープロトタイピングがオススメです。ただ、恐らく問題の本質は、新しく導入しようとしていることを必要だと感じられていないことでは。本当に必要なことであれば、ワークフローに強制的に組み込むなどの手段も考えられます（沖）
  • 会議の時にしれっとAdobe XDの画面で開発メンバー以外の希望を再現してみせたりプレビュー画面を見せたりしています。動いているのを見る効果を徐々に実感してもらうのも手です。(湯口)
  • 打ち合わせの最中にツールを使ったデモをどんどん見せて、「これ手元で確認しながらデザイン／実装したいな」と思わせられれば勝利です。動いているモノの説得力は大きいです。なので、前提として動きベースで実装するでしょ、くらいのレベルまでガシガシプロトタイピングで提案するのがよいかと。（奥田）
• 誰が作るのか？（役割）
  • チームの人間であれば誰が作っても良いと考えています。むしろ共通認識を深めるために複数人で作るのもオススメです（沖）
  • ゴールイメージを一番想像できている人が作るのがいいですね。自分が作るのが一番楽しいと思いますが、みんなが作るのも楽しいです。（奥田）
• ProttとAdobe XDの使い分けはどうしていますか？　SketchとProttとAdobe XDの連携は？
  • Adobe XDは今のところパスワードなどの保護をかけてプロトタイピングを共有できないので、それが必要かどうかを一番の基準に。もちろんProttでしかできない動きを見せたいならProttを選ぶしかありません。現時点でProttの活躍機会を奪うのはまれだと思います。SketchとAdobe XDの間には特別な連携はないですが、Sketchから一方的にコピー＆ペーストでオブジェクトを持ち込むことはできます。ProttとAdobe XDの連携は、Adobe XDで出力した画面デザインを読み込んで使う手はありますが、Adobe XDのデザインビューがよほど気に入ってないかぎり旨味はないと思います。(湯口)
• デザイナー、エンジニアが見るときツールをインストールしない。見てくれーとするには？
  • 上記の質問の回答ともかぶりますが、基本的には動いていることが前提となるようにプロジェクトを持って行くのだと思います。そのためには先陣を切って動き（プロトタイプ）を提案し、それをベースにディスカッションするのだと思います。（奥田）
  • 例えばAdobe XDのようにブラウザベースのプロトタイピングを提供しているツールはありますし、インストールが必要なツールをお使いなら環境整備も旗振り役の仕事だと思いますのでサポートの時間を作るのがいいのではないでしょうか。(湯口)
• プロジェクトのどのタイミングでプロトタイピングするのがいいか
  • 私の場合、クライアントからのオリエンテーション後に着手することが多いです（沖）
  • オリエンテーション後、最初のプレゼンテーションのときにほぼ完成像をイメージできるプロトタイピングを提案するのが、トータルのコストパフォーマンスが最高になります、経験上ですが。（奥田）
• プロトタイプってどこまで作り込むのが最近の主流ですか？
  • 今も昔も、見せる相手に伝えたいものが伝わるまでかなと思います。それ以上のこだわりを見せると、さらなる凄みを与えることができます。（奥田）
• レスポンシブデザインを作るとき、スマホから見た目を作ることはありますか？（PCよりスマホで閲覧されるシーンが多くなっているのでこういうこともあるのかなって）
  • 主流は全く追えていませんが、見せる相手の文脈で理解できるものをつくるのが最低条件でしょうか。なのでそのときどきによります。（奥田）
• ワイヤーフレームとカンプの間に一段階増える印象ですが、プロトタイプをすることでどのくらいプラスやマイナスになるのか、伺いたいです。
  • Axure RPを使う場合、プロトタイプがワイヤーフレームを兼ねていることになります。ほとんどワイヤーフレームを作る手間と変わらず、ある程度動作するものが作れるので、メリットしかないと思っています（沖）
  • 役割を区切るのではなく、繋ぐと考えると、むしろ工数は減るかも知れませんね。ワイヤーフレームが果たすべきもの、プロトタイピングが果たすべきもの、カンプが果たすべきもの、はそれぞれオーバーラップしていると思うので。（奥田）
• Webサイト（コーポレートなど）の制作時に、効率とクオリティーが上がるプロトタイピングって？
• SPサイト（Webサイト）をお客さんに見せるのに便利なツール、または確認しやすい見せ方に悩みます（ページ全体のjpgをHTMLにはりつけて、テストサーバにあげてお客さんに送ることが多い）
  • jpgということはビジュアルデザインの段階ということですよね。であれば、jpg自体をブラウザで見てもらうのはどうでしょうか？（沖）
  • ビジュアルデザインで主要画面を先に作って、invisionなどでそれっぽく遷移イメージ（触れる感）をつくったりします。（奥田）
• プロトタイプから本番へスムーズにシフトするコツはありますか？（激しい戻しがある前提で）
  • 激しい戻しが想定される場合は、プロトタイプではなく最初から本番用の技術で作ってしまいます（沖）
  • 最も重要な部分、つまりコンセプトに直結する部分をミニマルに見せるプロトタイプでプレゼンテーションしながら、徐々に実装範囲を広げます。初期のフィードバックが、表現やフローを超えたコンセプトレベルでの相違とイコールになるようにプロトタイプの内容をコントロールしていくことで、プロジェクトを骨子から確定していきます。そうやって確実に大黒柱から建設することで大どんでん返しを防ぎます。（奥田）
• ぶっちゃけプロトタイピングが一番おもしろいよね？
  • 最大MPを引き上げてくれるのはプロトタイピングによる試行錯誤なのかも知れないですが、HP/MPを全回復させてくれたり、次の旅の扉に飛び込みたくさせてくれるのは、最終成果物を体験してくれる方々が喜ぶ姿です。（奥田）
• 案件にフルスタックするのが前提のように思われますが、そうでない案件についてはどうなのでしょうか？
  • 案件にフルスタック = 全行程への参加、という意味合いであれば、むしろ願ったり叶ったりです。そうでない案件に関しては「こいつには全行程にいてほしい」と思わせるくらいのものを提案します。（奥田）
• 動きをどういう風につけていくか？　どのようにクライアントに見せるか？
  • 映像制作をしたり、プログラミングでインタラクティブ表現を実装してプレゼンテーションします。プロジェクトによって何を重要視するかでペーパープロトタイピングと動きの提案は前後すると思いますが、どちらにせよお互い補完関係となるように（感覚的に繋がりを感じられるように）提案します。（奥田）

KPTT

Keep

• 配信関連のワークフローは、マニュアル化によってだいぶ知の共有ができた（沖）
• Wifiの一般開放は止めたので、スピーカーおよびスタッフは問題なく接続できた（沖）
• YouTube配信、画質が良く、アーカイブしやすいので続けたい！（沖）
  • YoutTube Live いいですね（五十嵐）
• フロー改善によって受付時の手間は大分軽減できた（熊谷）

Problem

• 司会がスピーカーを兼務するとタイムキーパーが不在になる（沖）
  • 今回は準備の時間があまりにもなかった＆予定にない兼務だったため、次回以降は気をつけます（沖）
    • 今後、沖さんがスピーカーに入る場合、本編の司会進行を他のスタッフに任せてはいかがでしょう（五十嵐）
      • 仕事の状況にもよるので、それも含めて考えておきます〜( •̀ㅁ•́ฅ)✧（沖）
• 片付けに思ったよりも時間がかかってしまった（沖）
  • 元のレイアウトの写真を活用するのを失念していた。レイアウトについて、ひとつひとつ指示を出していると時間がかかりすぎるので、写真を活用する（沖）
  • 特に機材の片付けに時間がかかった。ライブ中継のスタッフは、準備＆片付けともに機材のみに集中したほうがよさそう（沖）
• スピーカーおよび司会を捉えるカメラの露出が不適切（暗い）だった（沖）
  • 事前にチェックする手順をワークフローに加えましょう（沖）
• 受付
  • 個人の出欠を取らないことへの、参加者の困惑があったかも（熊谷）
    • 何らかの説明があっても良かったか（熊谷）
    • 前回まで受付票提示をお願いしていたので、初めてじゃない人からすると？となったかも。次回、注意事項に記載するようにします（沖）
  • 懇親会費支払いの集計がギグバンド数だけに依存しているのはちょっと不安（熊谷）
    • 別途、紙でカウントしてもよいのですが、数が合わなくなるなど別の問題が発生するリスクの方が高そうな気がします。今のところうまくいっているので、何か問題が出たら対処しましょう（沖）
  • 細かい部分の収支管理で漏れや思い違いが起きた（熊谷）
    • 金庫の中に入出金の履歴を残すようにする(領収書のないものだけでも)（熊谷）
    • 今回Tシャツの集計が先にあったみたいでWikiに残されている収支よりもプラスから始まったので、領収書を残す+各会の入出金で１枚のメモ用紙を使いまわして複数人で疑問が出ないように疎通を図るのがいいのではと思いました（井上）
  • ギグバンドは先に切り離したおいたほうが手間は省けると思いました。ただ切り離すことによって厚さはましてしまうので保管管理がしづらく、曲がってしまうという問題も出てくるかもしれないので、当日の出席簿をみて2/3ぐらいのリストバンド数だけ先に切っておくというのはありかと感じました。実践したときの問題としては受付が少し散らばりやすくなるというのもあるので、切り離したリストバンドを入れるための縦長のボックスも必要かもしれません。（井上）

Try

• BGMを再生する環境がほしいので、iPad＋ミキサーで何とかできないか検討する（沖）
  • 配信中のBGMの場合は著作権をクリアしないと、youtubeに音声を消される恐れアリ（熊谷）
    • 開演前、休憩中、懇親会時のみなので、その間だけミュート or 配信終了すれば良さそうですね（沖）

Thanks!

• 当日お手伝いいただいたスタッフの皆さん、前日打ち合わせを急遽キャンセルしたにも関わらず上手く動いていただいてありがとう！（沖）

ギグバンド枚数

色	初期枚数	使用枚数	残り枚数
ピンク	10	3	7
イエロー	95	38	57

会計

今回の収支

摘要	金額	支払先他
懇親会費用	38,000	-
募金	4,050	-
スタッフTシャツ送料	-500	SUZURI
リストバンド	-2,900	ギグバンド・ドットコム
飲料	-9,960	カクヤス
ピザ	-8,424	ドミノ
オードブル	-10,340	弁天
オードブル	-3,380	ガスト
印刷代	-20	ICTCO
二次会お釣り	1,700
小計	8,226

総計

摘要	金額	支払先他
今回収支	8,226
前回までの残金	42,099
総計	50,325