ちなみにカスタマーサポートに「構わないからアカウントに紐づく全ファイルを消してしまってくれ」とお願いしてみましたが、セキュリティ上の理由で無理と断られました。無駄にしっかりしやがって・・・1,000枚やそこらならまだしも、私のように1万枚以上も同期してしまった後ですと1万連続クリックという高橋名人もびっくりの指先トレーニングをする羽目になります。諦めて名人になれというのも酷なので、1万クリックトレーニングを微妙に効率化するTIPSを伝授します。AmazonPrimePhotosのスマホアプリ(確認したのはiPhone版のみ)を立ち上げます。次に左上のチェックマークアイコンをクリックします。これで複数選択ができるようになるのですが、この時日付単位でまとめて選択できるようになっていますので、あとはひたすら日付をタップしまくるだけです。私の場合1万枚を3年とちょっとで撮っていたようですので、タップ回数は最大でも1,000回くらいまで圧縮されました。やったね・・・なお、この技が使えるのはPrimePhotosのアプリだけですので、AmazonDriveのスマホアプリでは出来ないです。正しい一括削除の方法をおさらいこれ以上野生の高橋名人が増えてしまわないように、AmazonDriveにおける正しいファイルの一括削除方法をあらためておさらいしておきましょう。クソ仕様すぎるので、全ファイル一括削除かフォルダに内包されたファイルの削除のどちらかが今後実装されると思います。それまではうっかりいつもの癖でフォルダを削除してしまわないように十分注意しましょう。いうかせっかく無圧縮+RAWの無制限保存可能というデジタル一眼ユーザーのための夢のストレージなのに、何でスマホで保存したただの画像やスクショなんかと混ぜて表示するような設計にしたんだろう・・・普通に考えて一眼の写真とスマホの画像を同じ画面で見たいと思う人居ないと思うんだけどなぁ。効率よくファイルをまとめて削除する方法があれば誰か教えてください。STUDIO」のクローズドβ版がリリースされました。STUDIOの何がすごいのか?従来のUIデザインツールとは何が違うのか?ということを紹介してみたいと思います。全員がMVPまで作れる時代まとめこれはプロトタイピングツールではないまず、最初にSTUDIOを「UIプロトタイピングツール」ではなく「UIデザインツール」と記載したのには訳があります。近年はプロトタイピングの重要性が多方面で説かれているのに呼応するように、冒頭で紹介したProttをはじめ国内外からたくさんのプロトタイピングツールが登場しました。何の事前情報もなしにSTUDIOを開いてみると、確かにそれらのプロトタイピングツールの派生系に見えるでしょう。触ってみるとこれが従来のプロトタイピングツールと設計思想からして全く異なるということがすぐに体感できます。実際にSTUDIOのUIに触らないで理解するのはなかなか難しいのですが、できる限りどういうことか説明してみます。アプリやWebサービスにおけるUIデザインは大まかに分けて4つのステップに分かれています。ワイヤーフレームプロトタイピンググラフィックデザインプログラミングこのうちプロトタイピングとグラフィックデザインは順序が前後する可能性もありますが、主だったポイントはこんなかんじではないでしょうか。これまで世の中に登場してきた代表的なツールに当てはめると、Prottはワイヤーフレームとプロタイピング。Sketchはグラフィックデザインの領域を得意としており、互いのツールを連携することで優れたUIをデザインすることを補助しています。STUDIOはこれらのステップのうちどこを得意としているかというと、私が触った印象としては1〜4の全ての工程をSTUDIOひとつで完結させようとしていると感じました。馬鹿げていると思いますか?しかしこれが事実であることは、STUDIOのサービスコンセプトが物語っています。STUDIOが目指している世界は「コードを書かずにサービスが作れる世界」すなわち、GUIでプログラミングまで含めたアプリ制作が完結する世界なのです。これに気付いたとき、ワクワクせずにはいられませんでした。GUIによってOS操作を実現したように、画面上でグラフィカルかつ直感的に要素を配置するだけでアプリやサービスが出来上がる世界がもうすぐそこまで来ているのだと。Layoutが、しれっとGUIで実装可能になっています。この時点で結構な驚きです。Layoutを優先して実装してくる時点でSTUDIOがXcodeに頼らず開発する未来を目指していることがよく分かります。そのほかにも、Sketch等グラフィックデザイン支援ツールではお馴染みのレイヤー表示順の概念とグループ化がSTUDIOでは(おそらく)意図的に実装されていません。これは、最終的にアプリとして出力(β版では出力機能はありませんが)される際にデータ構造を正常に保つためだと思われます。ちなみに、わざわざ自分でグループ化やレイヤー順変更しようと思わなくても見た目上でブロックの中に配置されたオブジェクトは自動的に正しい順序が保たれた入れ子のツリーのような状態になるため、コンポーネントの区切りを意識することなく想像以上に快適に操作することが可能になっています。なにより決定的なのが、要素に対してGUI上でAPI接続させる機能が標準で備わっていることです。ここまでで紹介した特徴だけではちょっと変わったプロトタイピングツールという認識になってしまいますが、β版の時点でAPI接続までサポートしようとしている時点でSTUDIOが本気でアプリ制作の全工程をカバーする気だということがひしひしと伝わって来ます。サンプルでspotifyのAPIを叩いてビートルズの名盤のジャケット写真を表示してみました。ここまでの紹介を読んで皆さんに誤解して頂きたくないのは、コードを書かなくてもサービスが作れる=エンジニアが不要になるということではないということです。プログラミングはデザインと同じく非常にクリエイティブな作業であり、ツールがあるからといってエンジニアの思考無しには成り立ちません。コードベースではなくGUIベースで組めるようになる点が革命的ということです。コードベースでなくなることの何が良いかというと、ビジネスメンバーやデザインメンバーがエンジニアと同じ目線でサービスを作ることができるということでしょう。ビジネスメンバーやデザインメンバーはエンジニアの書いたコードを理解することができませんので、デザイナーが形にしないといけないわけなのですが、デザイナーもエンジニアの実現したいことが100%理解できるかというと、そううまく行くことばかりではないと思います。エンジニアが素晴らしいアイデアを持っていたとしても誰にでも理解できる形にする手段が無いため誰にも理解されないまま埋もれてしまっているのです。その点において、GUIで機能と見た目を同時に作れることは非常に有効であると言えるでしょう。従来のプロトタイピングツールは、サービスづくりの「デザイン」の領域についてビジネスチームやエンジニアチームを巻き込んだ開発を可能にしてきました。STUDIOは、それらの特徴に加えて世界で初めてサービスづくりの「プログラミング」の領域についてエンジニア以外のメンバーを巻きもうとしているのかもしれませんね。特筆すべきはシームレスな操作感ここまでSTUDIOのコンセプチュアルな部分を紹介してきましたが、ここからはSTUDIOのUI/UXにフォーカスして紹介していきたいと思います。STUDIOを開発するオハコプロダクツ社はUI/UXデザイン会社であるオハコからスピンオフしたということもあって、こちらのプロダクトもインターフェース、特にインタラクションの部分について非常に細部までこだわって使用感が作り込まれています。最初に気付くのは、ブロックを配置しようとしたときの挙動の面白さでしょう。こればかりは文章で説明するのが難しいので、STUDIOの公式サイトの「やってみよう」から体験して頂きたいです。左右上下辺からの距離によって要素の座標と大きさを決定するこのUIはプレスリリースによると特許出願中のようで、これまでのどのツールにも無かった独自の操作感を提供しています。実際に触ってみると非常に直感的かつスピーディに要素の配置をすることが出来ることに驚きます。これからドラッグ&ドロップで要素を配置する系のツールのデファクトスタンダードUIになりそうな予感がしますね。β版ではまだLPで紹介されているスマートフォン同期プレビューは実装されていませんでしたが、それでも通常プレビューのシームレスさには驚きます。画像の再読み込みなどが極力走らないように工夫されているのか、一切の途切れなくまさにシームレスにプレビュー状態に移行します。画面遷移を行なっても画像の読み込みはほとんど感じられません。いうより通常編集モードですでにプレビューと同等の操作(横スクロールなど)ができるので、プレビューの概念が揺らぎます。他にも、要素をグリグリ動かすとalignがよしなに調整されてくれたり、画面上で順序を入れ替えるとレイヤー(ツリー)側の順序も入れ替わったり、色んな操作がシームレスに繋がっている感覚が新鮮でした。操作しているというよりもデュエットしているような感覚に陥ります。なんだその恥ずかしい表現。これだけ色々なことができるツールでありながら、テキストによる説明一切なしで直感的に使えるのはすごいと思いました。ユーザーに学習させてから使わせるのではなく、触りながら学習するというのはUIにおける理想の状態だと思っているので、もっとこういう説明に頼らないUIが増えると良いなぁと思ったのでした。各UIの操作感については、β版を終えて改善が進んだ製品版の方が出た段階で改めてレビューさせていただこうと思ってます。Product)であると考えられます。MVPについて改めて説明はしませんが、ここではプロトタイプとMVPとの明確な違いは何かということについて考えてみたいと思います。MVPもプロトタイプも本開発に入る前のテスト段階でユーザー検証のために用意するもの、という漠然とした認識だと思うのですが、私はこの2つで明確に違う点があると考えています。それは、MVPは「最小限の価値」を確認するための試作品であり、プロトタイプは最終形も含む「状態」を確認するための試作品であるという点です。MVPは最小限という制約があるため、作り込むことに重点を置いていません。プロトタイプは複雑に入り組んだサービスの後期段階でも用いられることから分かるように、最小限にすることに重点を置いていません。両者は包括関係にあるといっても良いでしょう。いうより、Prott等のトランジション再現型のプロトタイピングツールもプロトタイプという大きな枠の中のごく一部分(画面遷移)しか試作できないため、厳密にはプロトタイピングツールと呼ぶのは相応しくないのかもしれませんね。MVPにはプロダクトと名がつくくらいなので、基本的な画面遷移に加えて最小限の価値を得られる「機能」が必要であり、機能が入って初めてユーザーは画面から「価値」を体験することができます。『ここで音が出ます』とか書いてあっても、それは本来のユーザー体験ではないですよね?音が出ると決めたらちゃんと音を出すことが、MVPにおいては重要になってくるのです。MVPを作ることはサービスのスタート地点に立つことと同義です。考えると、STUDIOは最速でサービス開発のスタートを切らせてくれるツールと言えるかもしれませんね。STUDIOによって、非エンジニアも含めてメンバー全員がMVPまでは爆速で作り上げられる世界が作られることを期待しています。まとめ以上、一通りβ版STUDIOを触り倒してみて感じた率直な感想ですが、画面遷移の整合性チェックなどを素早くチェックするのが目的なら私はProttを使うなという印象でした。なんと華麗な手の平返し!やはりプロトタイピングという目的に特化したツールにはそれなりに工夫が詰まっており、使いやすいです。ビジュアルデザインについてもSketchの方がやはり出来ることが多く使いやすいと感じます。これらのツールはUIデザインの特定ステップに限定した場合に使いやすいのが特徴であるため、最終的なMVPの出力まで一気にやるようなケースではSTUDIOで作った方が総合的には早く形になるのだろうなということを強く感じました。STUDIOはまだβ版なのでこれから改善を繰り返していく段階であり、これからの動向が非常に楽しみなツールだと思います。ところでわざわざこんな長文レビューを書いている理由ですが、古巣のプロダクトということは実は全く関係なく「コードを書かずにサービスが作れる世界」というコンセプトに純粋に惚れ込んでいるためです。私自身が何度かプログラミングに挑戦しようとして言語を覚える段階で挫折を繰り返している身なので、GUIベースのアプリ統合開発環境を切望しているのです。この記事を読んでSTUDIOにすこしでも興味を持っていただけたのであれば、一度触ってみてください。触ればこのコンセプトとすごさが実感できます!そして、思ったことは良いことも悪いこともバシバシフィードバックしてあげてください!ユーザーとして一緒に作りましょう、コードが必要でなくなる世界を。ユーザー調査(この記事の読了目安:5分)せっかくブログをリニューアルしたのに全然更新できてませんでした・・・怠惰ですね。最近よくユーザーヒアリングのテクニックとかあるの?コツとかあったら教えて!と言われることが多くなったので、私がユーザーヒアリングを行う際に意識している事を備忘録的に書き出してみたいと思います。スタートアップ企業や、大企業のCSやCX部門などユーザーと直接接する機会のある方はよろしければ見ていってくださいな。勘所を知らぬまま長々と読んで頂くのもあれなので、先にアンチパターンをまとめます。気に留めながら自身のヒアリングを思い返して頂くと、かなりの確率で無意識にハマってしまっている方も多いのではないでしょうか。「やっぱりそうなんですね」と言ってしまうこと「それは○○ですか?」と聞いてしまうことこのユーザーにはニーズが無かったと諦めてしまうことなにが悪いの?と言われそうなラインナップですが、これらはすべて確証バイアスをはじめとした様々な認知バイアスがかかっている時に無意識的に発言されるアンチパターンになっています。意識しながら話すとすぐにボロが出てることに気付けるので、ユーザーに会う前に社内でロールプレイングをしていくことを強くおすすめします。この中でも特に確証バイアスは厄介で、意図的に排除しながらヒアリングをするためには結構な回数の実践練習をしないと難しいと思います。確証バイアスとは、平たく言うと仮説を裏付ける理由ばかりを優先して取り入れてしまい、反証する情報を無意識下で無視してしまう心理的な偏りのことです。あとで詳しく書きますが、バイアスがかかった状態でヒアリングを行ってしまうと、公平性を著しく損なう結果になってしまいます。一応3大落とし穴の何が悪いか具体的に書くと、「やっぱりそうんですね」発言は、予め自分の中にあった仮説にフィットしたことに安堵している証拠(確証バイアスにハマっている)。「それは○○ですか?」は相手より先に思い込みで勝手に決めつけた具体例を言ってしまうことで回答の幅を狭める行為(相手にフレーミングを与えてアンカー効果を誘発している)。このユーザーにニーズが無かったと諦めることは、会話の一端をかいつまんで仮説にフィットしていないと判断している証拠(これまた確証バイアスにハマっている)です。これを踏まえた上で『ヒアリングしてるときに何を考えてるの?』という冒頭のよくある質問についての回答ですが、何も考えてません。正確には、意図的に何も考えないようにしています。何も知らない子供になったつもりで、すべての発言に対して「なんで?どうして?」という好奇心を持つことを心がけています。子供にはバイアスはありませんから、それに習って同じように一切の事前知識や雑念を取り払って当たり前だと感じる発言でも必ず理由を聞くようにすることが大切です。ユーザーヒアリングの目的は仮説検証ではないユーザーヒアリングの目的は、仮説の検証ではありません。仮説を検証するために必要な情報を集めることが目的です。ここを勘違いして、ヒアリングの最中に仮説との付き合わせをしはじめる人が非常に多く居るように感じます。ある勘違いの例として質問項目をまとめた『ヒアリングシート』をあらかじめ用意し、その仮説に基づいてYesかNoかを問うというヒアリング手法が横行していますが、これはアンケート調査のように対面が現実的に不可能なボリュームに対して有効な調査方法であり、対面調査で用いてしまうと自分も相手も確証バイアスにどっぷりハマって結果が偏ってしまうため、私はおすすめしていません。ひとつ、ヒアリング中に具体的な提案をしてしまうのもよくありません。これは、アンチパターンの「それは○○ですか?」と同じくヒアリングしている相手をアンカー効果の罠にハメてしまうことになるためです。背が低い人の「ボタンが押しにくくて困っています」という発言に対して『じゃあ、この位置まで下げたらどうですか?』と提案してしまうと「いいと思う!」となってそこで会話が終了してしまいます。課題を深掘りできるチャンスだったのに、これでは非常に勿体ないです。背が低い=位置が高いから押しづらいのだと決めつけず、こういう場合は『なんで押しづらいんですかね?』と一見アホっぽい質問を投げてみましょう。それによって相手は今自分がそれを嫌だと思った原因を考え始めます。すると、実は思いもよらない原因によって嫌だと感じていることに気付くこともあります。どのボタンが何の機能であるのか理解してなかっただけとか・・・。いった具合で、せっかく対面でヒアリングを行うのですから、バイアスを全て取り払って「なんで○○なんですか?」「どうして○○だとダメなんですか?」と、仮説がすでにある部分であってもガンガン掘り下げていきましょう。仮説検証なんかオフィスに帰ってから議事録とにらめっこしてじっくりやればいいんです。表面的課題と本質的課題を見極めよう課題には表面的な課題と本質的な課題があります。ヒアリングで真に探らなければならないのは本質的な課題に至るヒントのほうです。表面的な課題というのは、『複合的な悪条件によって現出した課題の最も目立つ一側面』だと私は定義しています。ユーザーが最初に口にする課題はこの表面的な課題であることが大半だと思います。この本質的な課題と表面的な課題の関係性は、ちょうど本音と建前の関係性と同じようなものだと思うのですが、建前をいくら集めても本音に至れないのと同様に、表面的な課題をいくら議事録にしたためてもなかなか本質的な課題に至ることはできません。」とか言ってインテリぶって受け流さずに「それはなんでですか?」と掘りすすめる必要があるのです。掘れば掘るほど本質に近づいて行けるのです。このように、ユーザーの回答の第一声が課題の核心をついていると考えるのはナンセンスだと言えるのですが、唯一例外があります。それは質問に対して断言の形で即答ができた課題です。即答かつ断言できるということはユーザーが何度もその課題に直面した結果解決策を自分なりに考えた証拠であり、本質的課題に極めて近い情報として扱うことができます。ユーザーの発言が課題の本質を的確に表現しているとは限りませんので、即答された場合はチャンスと思って積極的に掘り下げて行きましょう。本質的な課題というのはユーザー自身も気付いていないことが多いので、一緒に掘り下げてあげる事で意外な事実に気付けたりするものですよ。結果の分析とよくやりがちなミスこうしてヒアリングから出てきたユーザーの発言の数々ですが、どの程度信用し、設計に反映したらいいのでしょうか。私なりの結論ですが、ユーザーが口にする「課題」や「解決策」は大抵ずれているので鵜呑みにしてはいけないというふうに考えています。ユーザーが言うことが正しくないということではなく、自分の直面している課題の原因を正しく言語化できないという方が正しいでしょうか。ヒアリングの結果は分析しないと意味を成しませんが、その際にユーザーの言うことを鵜呑みにしてしまうのは危険であるという具体例をひとつ。自動販売機のユーザビリティ向上を目的としてヒアリング調査を行なったとします。そこで「お札が入りにくいです。」という意見が多かったとき、『じゃあ読み取りセンサーの感度を大幅に向上しよう!すると偽札が使われる可能性も増えるので、偽札判別機能を追加しよう!ついでに投入口の形状も変えよう!』といったように、ちょっとした改修のはずがいつのまにか巨額のプロジェクトになってしまうという事がよくよくあります。これがクソだという理由は説明しなくてもわかりますよね。このミスを回避するには、ユーザーのペインを技術と根性で解消するよりも前にユーザーが自動販売機に求めている価値を解き明かす必要があります。私はこの例の場合「コンビニよりも時間をかけずに飲み物を手にいれることができる」ことだと解釈しました。ユーザーはお札が戻ってくると何秒かの時間を浪費するので、それが嫌だと言っているにすぎません。すると、そもそもユーザーは100円の飲み物のために(投入成功しても大量のお釣りが出る)1,000円札なんか使いたくないのだというシンプルな事実に気付くことができ、電子マネー決済の導入というソリューションに行き着くことができます。一つ「なんでお札が入りにくいと困るんですか?」という掘り下げの質問ができて、ユーザーが口にする課題を鵜呑みにするのは危険であるという前提があるだけで、巨額のセンサー研究開発プロジェクトが既成の電子マネーモジュールを組み込むだけでよくなりましたね。余談ですが、ユーザーが自動販売機に求めている価値は時間短縮であるという仮説は、実際に駅で電車がホームに入り始めてから飲み物を買ってみる体験をすればヒアリングなどしなくてもすぐに気付くことができます。自分が体験をする事の重要性はこのブログで何度も説いていますが、人間とは不思議なもので実際に体験しないとこの単純な事実になかなか気付く事ができない生き物なのです。ユーザーヒアリングはとても大切ですが、ユーザーの意見をどのように分析し、どう活用するか?という部分はまた別の思考法やスキルが必要になります。直接的なヒアリングのテクニックではないですが、ユーザーの意見の使い方として非常に重要な項目なので、あえて備忘録として書き残してみました。機能改善やモデルチェンジのような革新性の無い開発プロジェクトが巨額の予算になる場合それはすべてクソソリューションです。大事なことなので2回言いましたが、どうぞお気を付けください。まとめ途中で脱線したのでテーマがよくわからなくなりましたが、我流のヒアリングの極意としては確証バイアスを取り払え!子供になったつもりで掘り下げろ!ユーザーの発言は鵜呑みにはするな!という感じでまとまるでしょうか。一度言いますが、ヒアリングの目的は仮説を検証するために必要な情報を集めることです。効果的な仮説を立てるためには元にする課題が本質的なものでなくてはなりませんし、本質的な課題を探るためにはなるべく多角的なヒントが必要になります。多くのヒントを引き出すために皆さんにお伝えしたい最終奥義は何かというと、相手と相手の領域に興味をもつことです。ヒアリングテクニックでもなんでもないですが、興味を持つことで自然に「なんで?」「どうして?」ができるようになります。聞きたい領域について自慢をさせてあげられればベストですね。体感的には、相手8割自分2割くらいの割合で相手にずっと喋らせ続けるのが理想のバランスだと思います。これだけ喋っていれば本音がボロボロ出てきてヒントもたくさん手に入りますので、より精度の高い仮説を持って改善に臨むことができるでしょう。ヒアリングが上手になりたい皆さん、まずは冒頭で挙げた3大落とし穴を意識しながらテーマを決めて近くの同僚とロールプレイングしてみてはいかがでしょう。はてなブログProUXデザイン・UI設計・情報設計(IA)などを研究しているデザイナー。よろずデザインギルド「ENTAKU」代表。人間中心設計スペシャリスト。記事の内容は個人の思想であり所属組織とは関係ありません。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。