photo: Cristiano Betta
※追記 2013/06/15
これはだいぶ前の記事だけど、結局、Auto-Renewing Subscriptionsは今まで通りの気配。。最近、アップルの課金関係のエバンジェリストにメールで聞いたら、「最終的に決めるのはReveiw Teamだからわからないけど、基本的に機能にたいしてはAuto-Renewableは使えないよ。」みたいな返信をもらった。残念すぎる。
どこまでが機能で、どこまでがMediaと認識されるかという線引きはよくわからないけど、特に今までとルール適用の方針は変わらないのだろうか。
—— ここから以前の記事
知り合いに教えてもらったんだけど、ちょっと前にApp Store Review Guidelinesが変更されてたみたい。これ読む限りでは新聞とか雑誌系のアプリ以外でも自動継続課金(auto-renewable subscriptions)が使えるようになったのかも。まだわからないけど、これは期待！
photo: telwink
最近プログラミングを初めて楽しそうな友達とお茶漬け専門店でメシ食いながら、「本当はコードなんて書かずにモノが出来上がるぐらい簡単になればいいのに」という話をした。
一緒にお茶漬け食いにいったJ君は最近iPhone開発を始め、自分が旅行中に必要だったニーズを満たすものを実際に作って嬉しそうだったのですが、iPhone開発する時の不便さに怒り心頭らしい。
僕は、「プログラミングって奥が深くて、綺麗な設計ができるようになるたび楽しいなあ」とか、「プログラミング始めたのは人生で最良の決断だったなあ」とかいきって真夜中にTwitterで呟いたりしちゃうんですが、確かにもっと簡単になればいいとは思う。
まあ、NavigationControllerとかいろいろと細かいプログラミング用語をここで羅列してもなんのこっちゃわからなくなるので、簡単にまとめると、「なんでこんなカンタンな事が、カンタンに実装できないの！」という愚痴を延々と僕に浴びせかけていた。
J君「もっと直感的に、画面上で操作できるようになってほしいんだよ！」
俺 「まあ、一応、iPhone開発もストーリーボードとか最近は出来て、楽になったよ。」
J君「ストーリーボードは結局細かい事ができないからコードで書かないといけないじゃないか！」
俺 「まあまあ、エクセルのショートカットみたいなもんだよ。なれるとコマンドのほうが便利になるのは万有引力の法則と同じぐらい自明なんだよ。」
J君「その最終的にはコマンドで打つのが楽というのがおかしい。結局、作業なんだから、簡単にわかりやすくできるようにならないと。。」
まあ、数年前に比べてARCとかできてiPhone開発はだいぶ楽になったから、やろうぜ、楽しいよと周りに言いまくっている自分ですが、実のところ、結局プログラミングは面倒な事のオンパレードです。
本来ならば、こういうものを作りたい、こういう順番でUIを見せて、こういうデザインで、こういうわかりやすくする心理的しかけがあってと言ったような人間様がやるべき仕事に集中したいんですよね。
最近は、「デザイナーもプログラミング覚えるべきだ」とか、「テクノロジ系スタートアップのファウンダはコードが書けないといけない」とか、なににつけてもプログラミング重要といった風潮です。
僕も、プログラミングできるとUIデザインに凄く役立つよみたいな記事を最近書いたばかりだ。
人間、なにか新しいことをちょっとかじったら、これは○○にも役立つとか、○○できないやつはダメ！とか言いたくなっちゃうんですよね。
たぶん、僕が統計学を本気で勉強したら、統計学は最強の学問だとか言うと思うし、歴史学だったら、歴史に学べないやつはクズだとか言いそう。
最近、なんかみんなコードを習うべきだみたいなカッコいい動画も海外で作られてもいたし。
これに対してJ君いわく、いやまてよと。現状でそうなるのはしょうがないし、プログラミング行為自体の楽しさは認めるけれど、進むべき方向としては、プログラミングなんて不要になるぐらいカンタンにモノが作れる世界だろと。
確かに、僕もプログラミングがもっと簡単になって、全部直感的な操作で自分が欲しいものを作れる世の中になったらいいなあとよく思う。
今でも、子供でも簡単にプログラミングが出来るようなものが出来つつあるけど、まだまだ教育用の枠組みだ。
理想を言えば、GUI操作さえもいらなくなって、「こんな感じに操作できて、データはこう記録されて、画面のアニメーションはしゅっとこんな感じ！」といったように、長嶋監督もびっくりの身振り手振りでコンピュータに要求すれば、「こんな感じでしょうか？」と提案された実装がすぐに出来上がるのがいいな。
こういう未来の話をしても、現実世界ではテクノロジーが追いついてないんだからしょうがないんだけど、こういう視点を忘れないようにするのは意味があるとは思うんですよ。
つまり、なにかを実現したくて、それにむかっていろいろな作業に没頭していると、本来の作業自体の効率化に目が行ってしまうというか。
僕は見た目が綺麗で分りやすいコードの書き方とか、綺麗な設計とか、メソッド名は何がいいかとか、プログラミングの奥の深さが好きなんですが。
ちなみに、文系人間だからプログラミングなんて無理無理と思っていて僕に、「プログラミングは手に職つくし、論理的思考が高まると思うからお勧めだ。それになんか楽しそうじゃん。」と数年前にプログラミングを勉強するよう薦めて来たのもJ君であったりする（笑)
ただ、現実にはコードを書かずにモノが簡単にできるほどテクノロジーは進化してないんですよね。
簡単になるまで待つという選択肢もあるけれど、それが待てないなら、実際に手を動かして作るか、作ってくれる人を探すしかない。
今、このブログもキーボードで打っているけど、出来れば自分の思った事をそのまま入力してくれる技術ができればいいとは思う。
でも、そういう未来は待ってられないし、とりあえずキーボード打つのはそれほど難しい事じゃないから、ぺちぺちとマックでブログを書いている。
プログラミングに関しても、すげえ適当に書いても勝手に綺麗に整理してくれたり、マシンパワーで非効率な設計も補えるようになるかもしれない。
でも、現時点では綺麗な設計で効率的なコードを書くのはもの凄く重要だし、このことはそんな簡単に変わらないと思う。
もちろん、数十年後にプログラマーという職業の需要が今程あるかどうかは定かではなくて、その時々に要求されるスキルってそういうもんだし、ずっと続くものなんてないからなあ。
これはスキルだけじゃなくて、サービスの市場もビジネスモデルも、ずっと現状と同じように続くものなんてないし。
現実世界の制約を忘れて未来の事を想像するのが重要だから、SFとか読むのって大事なんでしょうね。
ちなみに、文系の人向けのプログラミング勉強方法を昔書いたので、紹介。
photo credit: hackNY
UI・UXデザイン方面だと”動く”モックアップが作れると大きいなあと以下の記事を読んで思った。
翻訳：Railsを学んだことで私はより良いデザイナーになった
インターフェイスは、動かない画面に貼り付けられた書類の束では決してなく、それは、インプットとアウトプットのフローなのだ。それが本当によいインターフェイスなのかどうかは、自分で使ってみるまで評価は下せないし、使ってみるにはまず作ってみないといけない。正確な評価・判断をしたかったら、実物に勝るものはない。
それまで私たちデザイナーは、動かないモックアップと、いくつかの動く部品を作って、それからプログラマの助けを呼んでいたが、この時の私達は、およそ2ヶ月もの長い期間を、プログラマの手を煩わせることなく、コンセプトの検証や新しいアイデアを実験するためのプロトタイプフェーズに費やすことができた。プログラミングの基礎知識は、私達デザイナーに dance without a partner のための手段を授けてくれる。
動かないモックアップ、例えば、パワポとかペーパープロトの段階で分ることと、シンプルでも実際に動いて機能するモックアップで分ることってもの凄く情報量が違うからのう。
特にiPhoneやiPadのようなモバイルデバイスだと、情報量の違いが100倍ぐらい大きくなるんじゃないだろうか。いや、100倍は言い過ぎかもしれないから、そこは突っ込まないで頂きたいけど。
僕がCakePHPでWebサービスを作ってた時は、まず紙でさささっとUIやら全体のイメージを書いて、その後はパワポに落とし込み、リンクをクリックしたら次の画面に動くようなモックアップを作っていた。
その後、htmlとcssで画面を作り、あとからバックエンドの動きを実装していた。コードを書く前に”実際に動いているような”デモをパワポで確認できて、今でも有効な手法だと思う。
そんなにこった動きとかはしてなかったし、ちょっとJQueryとか使う程度だったので、「うーん、ここの動きが使ってみると使いにくいなあ。」と言って後戻りするようなことはあまり多くなかった。
ところが、iPhoneとかiPadなどのモバイルデバイス向けに作るアプリになってくると、”動くものを実際に触ってみないとわからない”という部分がめちゃくちゃ多い。
最近はだいぶ過去の経験とか、いろんなUIの動きを脳みそにインストールしてきたおかげで、そこそこ実装前でも先が見えるようになってきたかなと思ったりもするけど、それでも触ってみないとわからないことだらけ。
Webサービスでも最近ではJavaScriptガリガリ使って動きを工夫したりするし、HTML5とかでモバイル対応したりしてきたら、もう大変だと思う。
iPhone開発では、iPhoneシミュレーターというPC上で動きを確認できる便利な機能があるんだけど、最近あまり使わなくなった。Xcodeの実機へのBuildが高速になったというのがでかいけど、実機で触らないとわからないことが多い。
まず、手で握って触った時に、ボタンの位置が押しにくいかとか。
アクションボタンをタップしてにょきっと画面が下から出て来て、それを閉じる時に左上、もしくは右上のボタンを押す時に届きづらいから、たまにiPhone落としちゃうとか。
移動中にポケットからiPhoneを取り出し、ネットワークが不安定になった時にどういう動きをするかとか。
寝る前に寝転んで、画面が横画面になった時に、縦画面の時、どういう握り方で持つか、その時の使いやすさとか。
こういう事を検証するには、デザインは全部デフォルトでいいから動くものをささっと作るのが一番。
僕が新しいアプリのUIを検証する時は、アイデアだしの段階で、まずは紙に簡単に書いて、その後コード書いて動かして検証してます。
自分しか理解できないかもしれないLIsgoのUIを考えてた時のメモ書き。
そこから、もうちょっと突き詰めて、自分を第三者の視点で観察するとか、ユーザを観察するとかの話はこちら。
これは悩むところです。人間の時間は有限だから、各自で一番最適だと思うことに時間を使うしかない。
これができたらいいよー、これもできたらいいよー、この知識があるとないとでは全然違うよーというのは、どれも正論であることが多いですよね。
でも、自分が今やる価値はあるかとか、これから覚える意味はあるかとか、必要になった時に勉強したほうがいいか、他人に任せて自分が得意な事に集中するかは人それぞれの状況に応じて違ってくる。
結局、”これからは英語勉強するべき”とか、”○○もコードが書けないといけない”とか、そういうのは自分でやりたいと思ったらやればいいし、必要でなければやらなくていいと思うのです。
だから、この記事も、そんなもんかと思って読んでくれたらこれ幸いです。
余談ですが、最近はデザイナの定義が広すぎて、デザイナーですと言ってもどれが専門か聞かないとよくわからない。
photo: foshydog
この前たまたま夜中にプログラミングに疲れ果てて死にそうだったんですよ。そして、ちょっと気晴らしでもするかと思ってネットを徘徊していたところ、ちきりんさんがはてなのオフィスを訪れたという話を読んだ。
これがサービス提供者とユーザ視点という観点でみると非常に面白いなあと思いまして、いつものごとくサービス開発にどう生かせばいいかとうんうん考えた事を書いてみたい。
この記事のなにが興味深かったかを説明すると、ちきりんさんがはてなダイアリーを使い続けている最も重要な理由が、”日付が分りやすい”という理由らしい。
これには「そんなことが理由なんですか？」みたいな顔をされましたが、私に言わせると、「それ以外にはてなでブログを書く理由って何があるんですか？」って感じです。
もちろんはてなダイアリーはブログとして最低限の水準をクリアしてたんだろうけど、ちきりんさんにとっては”日付が分りやすい”という部分が何よりも大切で、これが決定的な部分だったらしい。
こういう、サービス提供者側が想像してない理由、使い方などで、ユーザがそのサービスを選んでいるという事は本当によくあることだと思う。
サービス作っている側からすると、”他の競合サービスにはないこの機能でユーザに選ばれてるのだろう”とか、”うちのアプリを使ってもらっている理由はUIデザイン”だろうとか、こう思ってていても、実際のユーザ側としてはまったく違う理由だったりする事がある。
自分がなにかの商品を使い続けている理由も、結構ささいな部分が多かったりするもんな。
もちろん、どのターゲット層に最適化するかでニーズに答えるかどうかは変わってくるから、ちきりんさんがこういっているからそこを重視しろっていう事が言いたいわけではなくて、そういう理由で選ばれているのかと知るだけでもすごく参考になると思う。
このはてな訪問の記事を読んで、37SignalsのJasonFriedが2012年で一番影響を受けたとTwitterで呟いていた、クリステンセンのビデオを思い出した。
※クリステンセンって誰よ？っていう人に説明すると、イノベーションのジレンマを書いた有名なハーバードの教授で、ジョブズも非常に影響を受けた人
簡単に内容を紹介してみるとこんな感じ。
あるミルクシェイクの会社が商品を良くしようと思って、ユーザーインタビューを実施した。”フレイバーはどれがいいか、チョコレートの配合はどうするといいか”とかいろいろなユーザーフィードバックをもらい、その調査を参考にミルクシェイクの味を改善したらしい。
しかし、まったく売り上げには影響がなかった。
そこで、ミルクシェイクの会社は、実際に商品売り場に調査に行き、お客がどういう時間帯に商品を買っているか、どの時間帯に売れているか、どういう人達が買っているかを一日中調査することにした。
すると、ミルクシェイクの売り上げの半分は午前８時前に売れていた不思議な事実が判明。
ミルクシェイクを購入した人達はみんな一人で、ミルクシェイクだけを購入し、みんなが車に乗っている人達だった。
そこで、その人達に”不思議なのですが、なんでミルクシェイクを選んだんですか”といったような質問をしてみた。
“もしミルクシェイクを買わなければ、どういう理由でなにを選んでいましたか？”といったような質問もすると、それぞれがみんな、退屈な長い通勤時間を我慢しなければならないことがわかった。
片手でハンドルを握り、空いている片手で退屈な通勤時間になにか気晴らしになるものが必要だった。
朝早いからまだお腹は減っていないけど、10時頃にはお腹が減り始めるから、ちょっとだけお腹を満たしてくれるものが最適だった。
お客さんが言うには、”バナナはダメだった。バナナはすぐ食べ終わる。ドーナツも試したけど、ドーナツは手が汚れて運転中には向かない。ベーグルも味がなくて退屈でダメだ。”
“ミルクシェイクはこんな時ぴったりで、手も汚れないし、持ちやすい。空腹も解消される。”
お客がその商品になにを期待しているかを理解できれば、商品を改善するのは非常に楽になる。（終わり)
いやあ、これは言われてみるとそうかそうかと思うんだけど、開発側はついつい近視眼的になってしまうから、常に意識しないと忘れちゃうなあ。
この機能を完成させれば、競合製品と差別化できるからユーザが増えるはずだ！とか思ってても、今のユーザにとってはそれはたいして重要な部分ではなく、もっと違う部分を良くして欲しいと思っているとか。
むしろ、どうでもいい機能が増えたら、それを特に重要視してないユーザにとっては複雑さがまして逆にマイナスになったり。
ユーザのフィードバックをもらう時は、”使い続けている理由で一番重要な部分はなにか”、または、”使うのを止めてしまった理由の決定的な要素はどこか”。とか知りたいんですよね。
UXの専門家とかだったら”当たり前の話だね、うん。”ってなるかもしれないけど、ついついこういう視点を忘れちゃう事って多いからなあ。
こういう事を答えてもらえるようにはどういう聞き方がいいかとか、いろいろと悩ましい。
photo: Andres Rueda
ちょっと前にリーンスタートアップが流行り始めの時、僕はとりあえずRunningLeanとかAsh Mauryaのブログを参考にしながらユーザーインタビューもどきの事をやってみました。
結構準備してやったので、ずっと聞き役に徹したりと当時としては結構上手くできたんじゃないかと思ってるのだけど、その時勘違いしていたのが、まだ出来てない製品にいくら払うか聞いていたということだった。
製品も出来てなくてお金をもらえる準備が出来てない時点で、ユーザにお金を払うか、いくら払うかを聞いても基本的に無駄だと思う。（代替手段にいくら払っているかのほうが意味ある)
最近37SignalsのHow to price somethingというブログ記事で似たような事が書かれていた。
この記事の中でも重要な部分はここだと思う。
ユーザが製品にお金を払うかどうかは、実際にユーザがお金を払った時点でしかわからない。ユーザにいくら払うかを聞いてもしょうがない。なぜなら、20ドル払うと言われても100ドル払うと言われても同じ事だからだ。どちらも口だけなら一切コストがかからない。
唯一、本当の答えがわかる瞬間は、ユーザが実際にお金を払った時のみだ。ユーザがお金を払った時が、本当の答えがわかる時だ。
まあ、言われてみたら当たり前のことなんだけど、製品開発前のユーザーインタビューでいくらなら払いますかと聞いた事がある人は少なくないと思う。
この事については僕もいろいろ考えました。このブログのサーバも速くなって気分がよいので長文を書いてみたい。
製品が出来る前の段階で、ユーザがお金を払うか払わないかは誰にもわからない。
例えば、”うーん、興味はあるけど、その値段は高いなー”って言っていた人が、使い始めたら気が変わって余裕で払ってくれる場合もあるし、”おお、絶対払うよ、喜んで！”と言ってくれても、製品使い始めたら “ちょっと違うんだよなー”と言ってそれで終わりの場合もある。
無料サービスだったら、”そんなのあったら絶対使うよ！”と、”いやあ、それは興味ないな。使わないわ”に置き換えられる。
自分の体験に置き換えてみると、そんなものにはお金払わないなーと思っていたものだけど、使ってみたらいいと思って喜んで払うように気持ちが変わっている事もあるし、その逆も多々ある。人間の気持ちは移り気なもんですよね。
体験する事ができない製品に対する未来予測を聞いても正しくない答えが返ってくるから、いい答えが返って来ても油断はできないし、残念な答えが返って来てもあまり気にしなくてよいと思う。
むしろ、重要なのは、今現在そのターゲットユーザーがどういう行動をしているかだと思うのです。
具体的に言うと、代替手段であるサービスにいくら払っているか、無料サービスだったら、代替手段となるものを使っているかどうか。
まあ、これも当たり前なんだけど、製品が出来上がって、実際にユーザーがお金を払ってくれたとしてもまだわからない。
なんでかというと、その人はたまたまパチンコで勝って気分がよかった日だっただけかもしれないし、”迷ったら買いなさい”とかいう怪しい自己啓発書を立ち読みした直後だったのかもしれない。ブランドもののバッグを買った直後で安く感じたのかもしれない。
”今でしょ！”っていうCMを見た直後だったのかもしれない。つまり、行動経済学でいうアンカリングってやつで、なにかにお金を払う直前に見たり聞いたりしたものによって、製品に対する値段の感受性が変わってくる。
例えばSaaSみたいな月額課金サービスだったらわかりやすいけど、継続して使い続けてくれるかどうかを見ないと、本当に製品に価値を見いだしてくれてお金を払ってくれているかはわからない。
こういうと天の邪鬼なお方は、”いやいや、月額課金サービスで継続して使い続けているユーザでも単純に解約し忘れてるだけかもしれないよ”と言ってくるかもしれない。
その通りだと思う。
なので、継続課金してても、実際にその製品に満足してもらって価値を見いだしてくれているかは聞かないとわからない。
その人が製品を周りに薦めていたりすると、これはいい感じなんじゃないでしょうか。
じゃあ、結局、どうやって価格を決めればいいのか？ここは本当に難しいので誰もが悩むところですな。
価格付けはユーザに聞いて決めるものでもなければ、費用から逆算するものでもない、自社製品のポジショニングを決定するとても重要な要素なのでよく考えて決めないといけない
といつかの記事に書いておりました。
高い値段をつければ、そういう高い製品だというポジショニングになって、相手とするユーザー層も変わるし、安い値段でいくならまた大きく変わる。
いやあ、難しいですなあ。重要で難しい部分であればあるほど方程式なんてものは存在しないし。いろんな人の話を聞く限りでは、価格付けに関しては悩んだ末にえいやっと決めるパターンが多いとか。
photo: Johan Larsson
アプリを作っていて思うのは、何かを作って、何かを捨てる作業の連続だということ。
例えば、アプリが少し使いやすくなるようなUIを考えついたとする。
頭の中でも、経験則からでも、他のアプリを参考にした経験からでも、この小さな機能はいい感じになりそうだ、よしコーディングするぞと決心するとする。
もちろん、デザインとか細かい部分は後回しにして、大雑把に最も重要な部分を優先して、とりあえず自分でアプリを使える最低限の部分をプログラミングする。
この後、この機能を採用するかどうか、しばらく使って試す期間が出来る。
もし、作っているアプリが自分が欲しいものだったとしても、この時、本当に使い始めるまでどうしても分らない細かい部分がどうしても発生する。
アプリ開発でコストがかかるのは、やはりコーディングの時間であり、技術的な調べものの時間だから、コードを頑張って書いた後、ボツにするというのは出来る限り避けたい。
でも、ささっとコーディングした後、実際に触ってみて新たな発見がある割合は凄く多い。
Webサービスを作っている時に比べて、様々な生活のシチュエーションに密着しているiPhoneアプリは使ってみて気づく部分が圧倒的に多い気がする。
Webサービスはブラウザ間の違いはあるものの、基本的にパソコンの前に座っているシチュエーションが多かったからかもしれない。
でも、モバイルアプリは、寝転がりながら、歩きながら、座りながら、走りながら、雨が降っている時にかさを指しながら、冬の寒い時でポケットから手を出したくない時など、数えきれないシチュエーションがある。
僕は、可能な限り先人の知恵や、経験則を使って、やる前からわかる事は把握したいと思っているけど、結局、アプリ開発は何かを作って、捨てるという作業の連続になる。
当たり前の事だけど、何かを作らないと捨てることもできないなとこの前ふと思った。捨てるものをたくさん作るまで、捨てるものを選ぶこともできない。
最初はいろんなアプリのUIや様々なデザインを参考にして、頭の中で作っては捨て、作って捨て、こねくりこねくりする。
次に、ある程度頭の中で固まったら、紙に簡単に書いて、捨て、書いて、捨て、こねくりこねくりする。
次にコーディングして、実際にプロトタイプを作って、いろいろなシチュエーションで使ってみて、改善したり、捨てたり、こねくりする。
ここまでやっても、結果的にユーザにとって利便性がよくなかったりする場合、頑張って作ったものを捨てるのは本当につらい。
とりわけ、コーディングが大変だったりして時間がかかった場合はなおさら。
でも、これはしょうがない。
このこねくり過程を支えるには、やはり、作っているアプリに対する情熱が一番大事だと思う。いいものを作るという情熱がないと、こねくり過程に魂を込めることができない。
ちなみに、チームでやっている場合は、このこねくり過程をみんなで共有しないと、開発担当のほうは納得できなくてきついんじゃないかと思う。
Copyright © 2024 うめのんブログ
Theme by Anders Noren — Up ↑
