聴講メモ : 2014年12月13日 #cssnite_shift8 : 基調講演 : Webのスーパーヒーローになる方法 – 長谷川恭久さん (追記あり)

2014年12月13日に開催された CSS Nite LP38「Webデザイン行く年来る年(Shift8)」 から、長谷川恭久さん( @yhassy )の講演メモです。

テーマは、「基調講演:Webのスーパーヒーローになる方法」です。

メモは箇条書きで書いております。

(※ もしかすると後日加筆、修正する場合もしれません。予めご了承ください。)


はじめに

(最初に参加者席に座っていた長谷川さんの知り合いの方を3名立たせて、その方々の経歴を紹介しました。3名とも職種が少しづつ違う方々でした。メモはその後から……)

今日ここに来ている方でデザイナーをされている方、立ってください。

エンジニアやプログラマなど、その他の職種をされている方も立ってください。

(会場参加者ほぼ全員立つ)

今日ここに来ている方、みなさん「デザイナー」です。プログラマとか関係ありません。ここで今立っている方々は、世界を変えている人達。世界中で繋がっているWebのために何かもっといいものを作りたいと思って今も何かを作っているのだと思う。

週末にセミナーに来るなんて、他の業種から考えれば、ある意味異常なこと。それでももっと良くしたいという気持ちがあるから来るのだと思う。

Webは今年で25周年になった。

Webによって技術や考え方、暮らしがだいぶ変わった。一人一人が情報公開。知識を共有。

Webを一人でも多くの人達に使ってもらおうと、毎日仕事をしているのが私達の役割。先ほど立った皆様「デザイナー」はものすごい力を持った人達だと思ってる。

人々を幸せにするのも、ストレスを与えてしまうのも、考え方を変えてしまうのも、「デザイナー」の力があってこそ。このすごい力を、私達は責任を持って使わなければならない。クライアントやチームメンバーに対して、正しくデザインを使うように広めてかなければいけない。

スーパーヒーロー = 「デザイナー」

責任を持って力を使わなければならない。

スパイダーマン『大いなる力には、大いなる責任が伴う』

スーパーヒーロー達から学べる3つの事。実践している事。


スーパーヒーロー達から学べる3つの事

  1. 巨大な敵に立ち向かう。
  2. 継続する。あきらめない。
  3. 自分以外の事を考える。

1. 巨大な敵に立ち向かう – 皆さんに実践してほしい事

自分より大きな的に戦いを挑む。

「デザイナー」の敵は?

クライアント?丸投げする上司?

違う。真の的は私自身。

「どうせ無理」

行動を起こさないための「どうせ無理」

デザインのポテンシャルを最大限に生かさないまま世に出してしまう。

「どうせ無理」が私達「デザイナー」が戦わなくてはならないもの。

私は面倒臭いデザイナー。依頼をされてもすぐには作らない。クライアントに対してまずはみんなで一緒に考えましょうと言う。

理想のデザインプロセスができるように努力している。

その結果、クライアントに体するいろいろな方法論、解決案などが分かった。

私がこう喋る事で「貴方(長谷川さん)は有名だからうまくやっていける。私は「どうせ無理」だと思う。」……という思考が働くかもしれない。でもそこでスーパーヒーローの役割の2つ目の点。

2. まずは続ける。あきらめない。

スーパーヒーローは期間限定では働かない。巨大な敵が出てきて負けた。それであきらめるわけにはいけない。

続ける事で、信頼や信用を得る事ができる。

悩む。苦しむ。時には一緒になって目的のために進む。

スキルや実績ではない。続けていることが尊敬に繋がる。

CSS Niteは10周年。

10周年はモチベーションだけでどうにかなるものではない。

苦情、批判、悪口もある。

続けているから、信頼、信用があるイベント。

大阪で制作会社をやっているある方(※ 名前が出ましたが、筆者の判断で念のため伏せます)は、平日はブログを毎日書いている。

平日に毎日書いても誰もアクセスに来ない、時間の無駄……「どうせ無理」と思うかもしれない。

でも続けた結果、大きめの案件が取れるようになった。読んでくれている人が増えている。

私はさすがに毎日ではないけど、10年間プログは続いている。Podcastもやっている。

最近はブログ記事の画像はSketch.appでやっている。

ブログを書く限られた時間で新しいスキルを得ようとやっている。本を読むよりいい。

私は失敗ばっかり。うまくいかないこともある。

敗戦はある。それでもあきらめないでつづけているからこそ、今でも自分がやるべき事をやっているのではないかと思う。

みなさんも何かやってみてください。続けてみてください。

3. 自分以外の事を考える

では、続けるためのモチベーションは?

一回成功しても「次は無理かも」と思ってしまう。それでも続けていくには?

スーパーヒーローは「自分をかっこ良く見せたい」とか「モテたい」とか考えていない。

家族の事や、コミュニティ、地域、社会、世界の事を考えて戦っている。今の自分には何ができるのかを考えて、敵と戦っている。「デザイナー」も同様。

自分がこうしたい、ああしたいということを考えるよりも、同業者達からチヤホヤされたいと考えるよりも、ここのサイトに来る人たちの事を考えているはず。サイトを運営する企業にとってベストな事とはなにかを考えるはず。

ここでも新たな敵が出てくる。

「どうせ無理」という思考はクライアントも持っている。プログラマ、マーケ、営業なども持っている。

色々な理由をつけて、あきらめる。するとデザインが不本意な形でサイトが世に表れる。

ソーシャルメディアを見ていると、よくないサイトの批判、批評をよく見る。

そういうサイトは必ずしもデザイナー、制作者だけのせいではない。ワークフローの問題が多い。

「どうせ無理」と考える人が責任を転嫁している。

誰が責任を持つべきなのか。私は「デザイナー」だと思う。

「私には関係ありません」「ディレクターの◯◯さんがなんとかしてくれる」「御社だからこそできる。弊社ではできないよ。」他人に期待する。

「どうせ無理」という(内面的な)敵と戦ってほしい。

でも一人でやるのは辛いと思う。

一人では無理と思う場面はある。仲間と一緒に戦うこともあるだろう(スーパーヒーローも「デザイナー」も)。

一人が無理だと思ったら、上司やチームメンバーなどに協力を求める。断られても、何度でも求める。分かってもらえるまで色んな手を使う。

おわりに

CSS Niteなどのような外部の集まりはいい場所だと思う。今日立ってくれた皆さんは、ふだんの職種を超えてみんなスーパーパワーを持っている。

先ほどは大まかなくくりでみんな「デザイナー」といったけれど、実際の皆さんは一人ひとり、仕事上での立場・役割が違う。

その違いをみんなで共有する事で、「こういう視点があるんだ」という気づきもあるはず。

それが明日への糧になるだろうと思う。

今日学んだ事は、ビルの小さなセミナーの空間から外に持っていかないと、何も変わらない。ただメモを取っただけでは、皆さんのやりたいデザインは実現できない。

仕事場に、クライアントに、広めてってください。

スーパーヒーローは皆様一人一人です。Webを良くしていきましょう。

(プレゼンテーションここまで)


感想

今回の長谷川さんのShiftでの講演は非常にメッセージ性、啓発性の強い、力のある内容だったと思います。過去のCSS Nite Shiftシリーズのみならず、長谷川さんの過去のこれまでの講演でもかなり突出した「熱さ」だったと思います。

今回長谷川さんが仰った「デザイナー」というのは、普段の業務におけるデザイナー(Webデザイナー)とは異なり、クライアント担当者をも含め、Webサイトづくりに携わるすべての職種の人を指し示していると解釈しました(なので上記のメモではあえて鍵括弧「」をつけました)。

そういう意味では、この日の2週間前に行なったMTDDCでの「好みや多数決で決めない、デザインとの正しい付き合い方とほぼ似通った内容だったとも思います。

ただし今回は、MTDDCの時よりもはるかに参加者のメンタリティに踏み込んだ力強さがありました。

皆さんはすごいパワーを持っている……これは立場や職種を超えて、誇りを持って「私はこれがいいと思う」という意見をみんなで出し合えば、あらゆる問題を突破できるということなのだろうというメッセージだと思いました。

自分の「肩書き」にとらわれすぎて、自らの可能性を狭めてしまうのが、最も勿体無いことなのだろうと思います。

参考リンク

追記 (2014-12-19): 長谷川さんによるエントリーが出てきました。

聴講メモ : 2014年11月29日 MTDDC : 好みや多数決で決めない デザインとの正しいつきあい方 – 長谷川恭久さん

2014年11月29日に開催された MTDDC Meetup TOKYO 2014 から、長谷川恭久さん( @yhassy )の講演メモです。

テーマは、「好みや多数決で決めない デザインとの正しいつきあい方」です。

メモは箇条書きで書いております。


今の私の仕事は「デザインをする前をデザインする」という仕事が多い。

イベントで色々な職種の人が集まるのは、いい機会だと思う。

色々な業種の人が一緒になってデザインを考えるということは、あまり無いのではないか。エンジニアとかウェブ担当者とか。

私も普段はデザイナーがよく集まるセミナーでの出演が多いのが現状、それ以外の職種が集まる機会が少ないのが残念に思ってる。

いまはウェブの制作・開発がすごく難しい時代になっている。なぜなら今は「全国民デザイン評論家時代」になっているから。

「自分はデザインなんて分からないですよ。」とは言いつつも、実際は後からこんな事を言ったり……

  • 青ではなく赤のほうがいい。
  • インパクト足りない
  • すごく使いづらい。
  • なんかわかんないけど、なんかちょっと違うんだよねえ。

『ユーザーの声がいいですよー』→みんながみんが「あれがほしい」「これがほしい」「使いづらい」→『では投票にしましょう」……こんなんだとプロジェクトはおかしくなる。

……だからと言って、専門家以外の人の意見を聞かないのはよくない。デザイナー以外の人がデザインを語ろうとするのは、すごく意味がある。そこからじゃないと分からない事はすごくたくさんある。

なので、デザイナー以外の人がデザインを語れる環境を作るのは必要。

(それでもみんなの意見をそのまま取り入れてデザインをする → スケーリングはしません。)

納品した後にデザインが崩れるサイトがある。サイトローンチ後にセンスを持った担当デザイナーがプロジェクトから離れてしまっても、デザインが破綻しないように、メンテナンスができるデザインが必要。

色んな人たちが「同意」ができるデザインの方向性を示さなければならない。

「同意」ができることが重要。

自分の視点、自分のテイストでデザインを語ってしまう傾向がある。でも、このプロジェクトでは(たとえ自分は嫌いでも)正しいと分かる何かが必要。

例えば……「ユーザー的には……」と言ったとしても、そのユーザーって、誰なの?……とか。

だからこそ、まずは議論をするための基盤を作る事。

正しい質問ができてない。「これどうですか?」 ← そういう風に言われたら『自分の感想』を述べるしかない。

理解ができる表現かどうか ≒ 同意ができるかどうか

私的には好きではないけど、このプロジェクトとしては正しいものであるという「同意」が必要。何を見ればその「同意」の基準ができるのか。

議論ができる仕組みを作ることが重要である。

(ここまでの要点)

  1. 議論の基盤を築いているか。
  2. 正しい質問をしているか。
  3. 理解ができる表現かどうか(≒ 同意ができるかどうか)

DESIGN

デザイン(Design)という言葉もいろいろある。

一般的には……

  • アーティスティック
  • 職人芸
  • センス

……それぞれが色々な切り口で『デザイン』という言葉を使っている。

例えば、営業の人が『デザインは単なる装飾』と言ったら、ヘタするとデザイナーに求めるオーダーはピクセルを変えるだけの仕事だと見られてしまう。

デザインというものは一体なんなのかというのを組織の中で定義する必要がある。

私の場合は……

  • コラボレーション
  • 提案
  • 葛藤

みんなで一緒に作るためのデザインというのはどういうものなのかというのを私の場合は意識している。

デザインの定義は人によって違う。だからこそ合わせなければいけない。

葛藤という点が、デザインの中で重要。

葛藤という言葉は健康的ではないように思うが、実は、葛藤というものが無いと、各人が持っているデザインのニュアンスやセンスを意見として表にに出してあげないといけない。

たとえば『20代の若いOL』と言われても、人によってそれぞれ詳細なイメージは違ってくるはず。

人々のイメージを絵や文字にして共有・意見をぶつかり合わせて、ビジネスでのゴールや人間像などを出して、導きだしていく。

デザインで一番難しい部分とは……

皆が正しい意見を言っている。立場が違えば優先順位は異なる。

ありとあらゆる言葉が共有されていない。(家族やごく小さなチームでは問題ない(感覚・ツーカーでもいい))

クライアント関係や大きな組織(10〜20人以上)でのやり取りだと、感覚・ツーカーは通用しなくなる。そこをどう共有していくか。

目的と言葉。当たり前は何もない。

「かわいい」「シンプル」などのキーワードでも、人によって見えているものは違う。それで「デザインどうですか」と言われても感想に違いが出るのは当たり前。

何をもって「シンプル」なのか、人によってはさっぱり分からない場合もあるだろう。

何も共有されていないのに、さあデザインを作ろう!といっても無理がある。

「みんなが同じ感覚を持ってるよね!」というのが間違っている。

  • チーム各自の人それぞれの感覚をたくさん出して、デザインアイデアを洗い出し、共有して、良いデザインを作り出していく。
  • 基本的にプロジェクトに携わる者は、皆が正しい意見を言っている。

共有するためのツールを誰かが(デザイナー、プロデューサーなど)作る必要がある。

下手をすると……

  • 好みやトレンドで決まってしまう。
  • エラい人が決める
  • センスのあるデザイナーが一人で作る

そうならないために、運営ができる、続けられるデザインを作る必要がある。ちょっとしたニュアンスもきちんと共有する。

What is “Good” — プロジェクトにおける「良い」を決める

チームとしてデザインを考える・進める(・評価をする)

デザインをチームで考える・評価をする。

  • A. 前提を整理・共有する
  • B. デザインが話せるように工夫をする。

A. 前提を整理・共有する

前提には2種類ある

  1. 企業・配信者側が考えるゾーン
  2. 顧客・利用者に抱いてもらいたいもの/ターゲットにしている利用者

それぞれのイメージを共有する

1. 企業・配信者

  • キーワードを書き出す
  • キーワードについて話し合う
  • 選別・グループ分け
  • 共感できる言葉を

簡単なワークショップで自分たちの企業が考えているそれぞれの感覚的な言葉をアウトプットしてもらって、共通している言葉・テーマを見つける。

単語・キーワードに込められる想いを社内で共有する。

言葉

  • 言葉 → タグラインではなく、ビジョン
  • 言葉 → 短くて明確なキーワード
  • 言葉 → ニュアンスを共有する

言葉→イメージ→デザイン

デザインのやり取りを経て、初めてパーツデザインの話・デザインガイドラインの話に取りかかれる。

2. 顧客・利用者

そもそも利用者側はどういった人たちなのかということを分析するのも重要。

やり方はいろいろあるが、インタビュー、アクセス解析を通してペルソナをつくるなど。

ペルソナ……4つのセクション

  • 動機になるポイント
  • 利用シーン
  • 解説
  • チェックポイント

ペルソナのポイント

  • ちょうど良い情報量
  • ブランドと合う人間像
  • 機能ではなく、ニーズを基に

なるべく利用者視点で「こう考えているだろうね」と考えるようにする。

B. デザインが話せるように工夫する

デザインの話をコントロールするのは、ファシリテーター、議長など、リーダーシップをとる者の役割。

批判と批評は違う。批評をしよう。

作ったものに対して、評価をする。

こういう話し方だと、作った者は傷つく。なるべくこうした言葉は使わない。

  • 〜に変えてください (NG)
  • 〜のほうが良いです (NG)
  • 〜にしてください (NG)

ポイントは……

  1. 傾聴
  2. 探索
  3. 意訳

1. 傾聴

  • まず黙って聴いてみる
  • すぐに結論に結びつけない
  • 話し手の意図や背景を知る

2. 探索

  • 聴いた事を深堀りする
  • 意図をより明確にする
  • 話題をフォーカス

3. 意訳

  • 聞いたことを自分なりに解釈
  • 複雑かつ誤解を生みそうな話題
  • 次の話題へ移る前に

おわりに

「Why?」 : 「なぜ」こうなったのかというところをきちんと理解する。相手を納得させるための理由を提示する。そのためのツールや根拠・データを用意する。

デザインは個人で作る時代ではない。チームで作る時代です。


感想

主な要点としてまとめると、以下のような感じだろうと思いました。

  • デザインは個人ではなく、チームで作る。
  • デザインを語ってよいのは「デザイナー」だけではない。誰でもよい。
  • チーム内でのデザインの意見を可能な限り洗い出して、必要とされるデザインを導き出し、それをチーム全体で共有する。
  • そのために必要なアウトプットの仕方にも工夫やルールとかが必要。

とにかく長谷川さんはプレゼンがうまい、ということで、自分は何回も長谷川さんのプレゼンを聴いております。

セミナーや勉強会などのイベントにおいて(日本で)わりと一般的にありがちなプレゼンテーションのパターンは、あらかじめスライドに書いた内容を話していくというスタイルですが、長谷川さんの場合は基本的にトークによるコミュニケーション・語りかけでプレゼンを進めていくスタイル(わりと欧米的・TED的)です。

この日の会場はマイクやプロジェクターなどの設備面のトラブルが多く、長谷川さんもそれに巻き込まれました。しかしながらそういった状態でも長谷川さんは冷静に場つなぎのトークをうまくやっており、さすがだなぁと思っていました。

プロジェクターが表示されない状態が数分続いていたまま話を続けていたのですが、どうやら長谷川さんは事例の紹介をしたかったらしく、そこでは(長谷川さんにしては珍しく)事前に作っていたスライドのビジュアルを見せる必要がありました(公開されたスライドの10〜12枚目についてです)。その際に、「スライドに頼っているプレゼンはよくないですね」とひとこと言ったのが印象的でした。

参考リンク

聴講メモ : 2014年12月8日 Inspired to Code – Apple Store, Ginza : Flask 小川秀子さん、堀内敬子さん

2014年12月8日にアップルストア銀座で開催された、Appleのイベント「Hour of Code」シリーズの中の「Inspired to Code」から、Flask LLPのお二人の講演メモです。

アップルのサイトより → Apple Store – Hour of Codeワークショップ

メモは箇条書きで書いております。


主な内容

プログラミングやUIデザインの出会いを語る。

  • Flask LLPを立ち上げたきっかけ
  • iOSアプリ「FitPort」のアイデアが生まれるストーリー

Flask LLP

ウェブサイト: フラスク(Flask LLP)- iPhone/iPadアプリ開発会社

  • 小川秀子さん (お)
  • 堀内敬子さん (ほ)

(※ 念のため記しておきますが、堀内敬子さんは同姓同名の女優さんとは別の方です。)


はじめに – アプリを作りたいと思った経緯

お: 堀内さん、どうしてiPhoneアプリを作りたいと思ったのですか?

ほ: 以前はWebデザインをやっていた。ウェブを見ているうちに、サイトよりもアプリやウェブサービス……「見る」より「使う」もののデザインが好きになってきた。ある日iPhoneのアプリの仕組みに感銘を受け、自分でも作りたい(デザイン)したいと思った。

お: 私はエンジニアなので、iPhoneを手に持つとなにか作りたいという気持ちになる。ウェブはある程度UIの規則が固まりつつあるが、iPhoneアプリはまだはっきりしたもの(ルール)がない。そんな状況で作れるのは面白そうだと思った。

Flask について

これまで7つのアプリをリリース。

Flaskより

  • Desk Clock Calender
  • FreshPantry
  • PicTack
  • PopWeight
  • Timelet
  • Timesheet
  • FitPort

最新リリースのFitportでは、各メディアで好評を得た。

FitPort

iOS公式のHealthKit(ヘルスケアアプリ)と連携し、HealthKitにある健康データをきれいに表示させるアプリ。カジュアルなビジュアル表現。

Health Kitの発表があった時に、私達はわくわくした。

Health Kitリリース当日の提供を目指した。

発表からリリースまで2ヵ月しかない。当時はまだまだ情報も少ない。

お:(なぜ開発を決断したか?)先行者メリットを狙った。リスクもあったが「私達だからできるんじゃないの」と思った。ライバルもいるけど、2ヵ月だとすごくたくさん出てくるとも思わない。

ほ: わたしもこれはチャンスだと思った。

UIについて

ほ: 没になったUIデザイン案はたくさんある(特に配色面・フォントとか)でき上がったUI案は小川さんに見せる。でも小川さんには「その情報は本当に見たいものなのか?」と冷静にダメだしされる。

小川さんにとってuIで印象的なのは?

お: 一番見たい項目がドーンと大きく表示されるというデザイン案が(堀内さんから)出たとき、これだ!と思った。実際外に持ち歩いてみると、使いやすさ、使いづらさが分かる。画面の半分を占めるくらいの重要な情報の表示は「これだ」と思った。

ほ: たくさんの情報をぎゅーっと一画面に入れるよりは、一番大切なものを大きく見せたのがよかった。そこで突き抜けた感があった。

背景について。

ほ: デザイン開発中はずっと白背景にしていたが、アプリ申請の当日に突然黒(ダークグレー)の背景色に変更した。結果、スクリーンショットも見栄えがするし、実際触っていても使いやすい。アプリへの愛が高まる。

ストーリーボードについて

「ストーリーボード」を用いて画面のデザイン、レイアウトをする。(筆者注 : Xcodeか?と思ったがイベント中はソフト名が聴き取れなかった、後で調べたらおそらくXcodeの「ストーリーボード」機能でほぼ間違いない。というか、Appleの公式イベントなので、よそのソフトウェアは基本的には出さないか。また、このイベントは具体的な技術用語はほとんど聴き取れなかった。)

堀内さんもストーリーボードを用いる。

お: レイアウト面もエンジニアが担当するケースも多いと思うが、デザイナーに作ってもらった方がより緻密なデザインができるのではないだろうか。

ストーリーボードでのデザインは堀内さん、内部の実装は小川さんが担当する。(この後に触れるが、最初のざっくりとしたプロトタイプは小川さんがつくる)

開発作業の流れ(小川さん)

まず大まかな画面構成を考えたあとに、エンジニアの私がストーリーボードの大枠も含めて、プロトタイプ(実際に動くもの)を3日程度で作る。

操作の流れをしっかり見えるものを優先して作る。とにかく動くものを短期間で素早く作る事が大事。

円グラフ、棒グラフの色や太さなど、最初に小川さんが大まかに定義した後、堀内さんにビジュアルの細部面を投げる。

ストーリーボードを堀内さんに渡した後、小川さんが内部実装作業を行う。

ずっと二人で並行作業を続けていった。

二人の作業比率

今までのアプリ
エンジニア(小川) : デザイナー(堀内) = 7:3

FitPortの時は……
エンジニア(小川) : デザイナー(堀内) = 4:6

ほ: ストーリーボードの作業は慣れると変更が簡単にできるため、時間をかけて納得ができるまで作業ができる。大変だけど、とても楽しんで納得ができるまでやり込んだ。先に述べた申請当日の変更も、ストーリーボードが楽に作業できるから可能だった。

リリース後の話

Apps with HealthKit integration start appearing in App Store following iOS 8.0.2 fixes | 9to5Mac

9to5Macですぐにニュースになった。HealthKitの記事の一部として。(HealthKitを使ったアプリがAppStoreに出てきたという趣旨の記事)

私達の狙いとしていた申請と同時のリリースをしたから、海外のいくつもの大きな有名ITサイトで紹介された。

その日は寝れませんでした。

なぜできたか?

  1. チャレンジ – 謎の多かったHealthKitへのチャレンジ
  2. タイミング – 注目されようという想い
  3. UIのこだわり – 見た目だけではないアプリの本質的な部分や、シンプル性の追求

UIのこだわりによって、わかりやすく伝わりやすい形になったので、ニュースメディアに取り上げられやすくなったのではないか。

各ニュースサイトで紹介。AppStoreでBest New Appsとして紹介。各国のヘルスケア特集でも紹介。フジテレビのめざましテレビでも紹介。

プログラミングを勉強したい人へメッセージ

小川さん

プログラミング言語は情報が色々転がっているので、簡単なものでは2〜3週間でできると思う。プログラムを書くのは簡単な事。

アプリ開発はそれ以外に難しい事がある。

プログラムを学んだのは社会人の頃。その頃は知識が足りないと思って、デザインや人間工学も学習した。

システム開発の会社だったので、作る物の業務の内容を勉強するのが大切。

システムを作るということは要件をどのように整理して、表現するのか、というものつくりである。プログラムはそれを実現するための手段でしかない。

「書く」以外にも、「整理」する、「表現」するということは大事。

表現するという部分に関しては、アプリ開発は手段や選択肢がたくさんある。難しいけれどそこに良さがある。

FitPortでは、画面が切り替わる際に、アニメーション表現でユーザーが覚えやすい形で切り替わる。

画面が切り替わるアニメーションの表現は私がお気に入りな表現のところ。

画面が切り替わってもユーザーが覚えやすく分かりやすいUI。

アニメーションはデザインラフの時点ではイメージしにくいところだが、とても効果を発揮する表現。

堀内さん

デザインやプログラミングだけでなく、想像力や観察力、発想の転換なども大切になってくる。

  • 想像力
  • 観察力
  • 発想の転換

→ こだわりにつながる。

現在AppStoreではたくさんのアプリがある。

アイデアは思いついたとしても、たいていは他で実現されたものも多い。しかし、アイデアというのは全く同じではなく、他の人、よその所との違いも絶対あると思う。
その人ならではの何かこだわりを入れる事が、アプリ・プロダクトの価値に繋がると思う。

FitPortはシンプルなアプリ。そのシンプルにたどり着くまでに、たくさんの試行錯誤をしてきた。

貴方の「信じる価値」にこだわる事で、アプリはできると思う。(小川さん: 信じる価値に共感してくれる人はきっといる)

アプリ開発に一人でも多くの人がチャレンジしてほしい。

(以上、トークセッション終了)


Q&A

質問: 二人だけで作る事で、良かった所はありますか?

以前は趣味で作っていたところがあった。二人でよかったと思う点は、素直な意見を相手から貰える。おたがいに歯に衣着せぬ意見を言い合える。

質問: 1. フリーランスではなくLLPなのは? / 2. 普段どういうものを見たり、意識したりしている?

お: Flask設立のきっかけは……二人でやっているので、AppStoreの表示で出る「開発者名」を個人名ではなく企業名(組織名)でやりたかった(二人でやるのでどちらか片方の個人名だけというのは避けたかった)。企業名だと信頼性が増す。

ほ: デザインは、いいアプリを知りたくなったらアメリカのランキングを見たりする。海外の方がデザインレベルが高い。アプリ以外だとDribbbleとかを見る。

お: 私もDribbbleやPinterestを見て、インスピレーションやアイデアを得る。

質問: 今回から何故ストーリーボードをデザイナーが弄ろうかと思ったか?

ほ: いままでもちょっとずつストーリーボードを触っていたが、Flaskで本格的に触った。

お: Flaskは初めにデザインのアイデアがなかったので、堀内さんに細かいところまでお願いしようと思っていた。そこでストーリーボードを本格活用してもらおうかと思った。

ほ: iOS8向けの仕様になって、ストーリーボードが使いやすくなった。大きなサイズの変更とかも簡単にできるようになった。


感想

アップルからの発表ではコード(Code)に関するイベントだと思っていったので、プログラミング面の話が出てくるのかと思っていましたが、蓋を開けてみると意外にもUI面に関するお話が多めだったような印象でした。

開発ヒストリーのお話としては、とても興味深く聴けた内容でした。

話の内容としてはHealthKit発表というやってきた「チャンス」をしっかり確実にものにしたという感じのストーリーでしたが、「チャンス」を確実にものにするには、プログラミングやデザインのスキルの研鑽や実績など、それまでの積み重ねが必要なのかもと思いました。

無題

今は2014年5月下旬。

このドメインをいつ取得して、その後 WordPress をいつ入れたのかも忘れてしまった。

本日 Google Analytics を一応入れた。