投稿者: umemoto

テキスト読み上げアプリ Voicepaper誕生秘話

こつこつ開発してきたiOSアプリ、Voicepaperがようやくリリースされた!いやあ、めでたい。

これは僕の読書生活に革命を起こしたアプリであり、ほぼ毎日使っているんだけど、どういう価値があるのかを説明しようと思う。

このアプリは誰のためのもので、どういった価値をもたらすアプリなのかを説明しながら、最後まで読んだ人は見事に洗脳されているという状況に持っていきたい。

うるせえ、使う用途とかだけ知りたいという方は、一番最後の段落、”Voicepaperを使った読書体験”を読んでください。

まずは動画だ!という方のために、動画もご用意いたしました。

ちなみに、無料で試せるし、iPhoneとiPadどちらにも対応しているので、とりあえず使わせろという方はダウンロードしてみてください

さて、何よりもまず、なんでこんなアプリを作ったか、なんなのこれ?という事から始める。ストーリー仕立てになっているけれどもノンフィクションです。

あれは初代Kindleが発売される前、まだiPadも世の中になかった頃でしょうか。自分にはこういう悩みがあって、極度のストレスを抱えておりました。

読みたい本が溜まっていくけど、なかなか読めん!

世の中にはたくさん面白い本がある。本を読む事によって、いろんな人の経験を疑似体験できる。また、面白い小説を読むのは何物にも代え難い喜びである。

しかし、やっぱ本読むのって結構大変なんですよね。

静かな場所でじっくり腰を落ち着けて読まないといけないし、なかなかそんな時間はないし。

こういう悩みを持っていた頃、英語勉強していたのもあり、オーディオブックという存在を知った。

オーディオブックすげえ!

アメリカは車社会なのもあり、いろいろな本がオーディオブックになっている。もう最近の有名な新刊はほぼAudibleというサービスで人間が朗読したものを購入する事が可能だ。

「これはすごい!これなら、ランニング中も退屈な食器洗いの時も、楽しい時間が過ごせるぞ!」と当時思ったんだけど、僕は英語ネイティブじゃないので、さすがに難しい本を耳だけで理解するのは困難であった。

で、日本語のオーディオブックないかと検索してみたが、案の定、自分の読みたい本がオーディオ化されている事は、まあ、打率0.01ぐらいでした。

これはいかんわと思ったその時、明暗が浮かびました。

「あれ、これ自動音声読み上げソフトでmp3化したら、日本語の読みたい書籍を自作オーディオブック化できるんじゃないか?」

これを思いついた時は、もう興奮しました。

「おおお、これは俺の読書生活に革命が起こる!」と騒ぎ、部屋の中を走り回ったもんです。

自作オーディオブックを作る

今でこそ電子書籍の知名度が上がり、自分で買った本を裁断して自炊するのも珍しくなくなり、便利な代行業者もあるけど、当時は結構珍しかった。

でっかい裁断機を購入し、スキャナーを買い、まずは家にある読みたい本を自炊して電子化した。

普通はここで終わって、iPadのようなデバイスで読めたらいいんだけど、僕の場合は音声化するのが目的だから、写真からテキストに変換しないといけない。

そこで、画像の中にある文字を読み取り、テキスト化するOCRソフトを買って、テキスト化していった。その後、いろいろ調べて一番音質のよかった音声合成ソフトを使い、テキスト化した本からmp3を作成して、iPodで聞いてみた。

すると、見事に自作オーディオブックが出来上がったのです。

「おお、すげえ!この自動音声の品質なら全然聞ける!これでランニング中も、家事洗濯中も、通勤中も、読みたい本が楽しめるぞ!革命起きた!」と大騒ぎし、この小さな実験の成功に、またまた部屋の中を走り回ったもんです。

自動音声も使えば使うほど耳が慣れてきて、イントネーションも気にならなくなってくる。

しかし、自作オーディオブックができたのは嬉しかったのだが、様々な面で問題が起こった。。

座った時は目で読みたい!

そもそも、自炊して、OCR化して、音声合成ソフトでmp3化する作業もめんどくさいんけど、何よりも問題だったのは、耳で聞いていると、途中で目で読みたくなることだった。

いや、もちろん、移動中とか寝ながらとか、手や目が使えない状況だといいんだけど、家に帰ってきて、座ってゆっくりしているのに、続きを耳でわざわざ聞くのはどうなのと思った。

「いや、今は目で読みたい。集中してじっくり読みたいわ!」という状況が絶対に出てくる。

しょうがないから、裁断した本をノリでくっ付けて復元して、家に帰って来たら、必死でどこまでmp3が進んだかページをめくって発見して、途中から目で読むとかを試した。

これはダメだった。めんどくさすぎる。。。

「家に帰ってきたり、電車で座ったりした時に、耳で聞いていた箇所の途中から、すぐに目で読む事に移行したいだよ!なおかつ、目で読んでいる途中から、すぐに耳で聞く事にも移行したいんだ。ダメだこんなんじゃ!」と憤慨したものです。

絶望に打ちひしがれ、飲んだくれの毎日を過ごしていた時、明暗が思い浮かびました。

「あれ、これ、自動音声でテキスト読み上げるiPhoneアプリを作って、読み上げ箇所をハイライトさせればいいんじゃないか?」

しかし、「うおお、すげえ!」と、今回ばかりはなりませんでした。

出来たらもちろん素晴らしいし、それは毎日使うアプリになるだろう。ところが、当時の僕は、プログラミングなんてやったこともないし、それどころか分数のかけ算も怪しい、数学に恐怖する文系人間だったからです。

アプリを作る決心をする

時がたち、ハッカーと画家という本を読んでプログラミングするぞと決心し、挫折を重ねながらPHPでいくつかWebサービスを作った後、次に何を作ろうか悩んでおりました。

あれはちょうど東日本大震災があった頃でしょうか。作りたいサービスはたくさんあったけど、どれが一番自分の情熱を傾けられるだろうかと真剣に考えていた。

あれもいいな、これもいいな、これは時流にあってるな、これは周りのウケもよさそうだ。とかもんもんと考えていたところ、当然、オーディオブックアプリの事を思い出した。

「うーん、でもiPhoneアプリってなんか難しそうだな。どうしよう。いやいや、でも毎日の生活を本当の意味で変えるのはこのアイデアしかない。今でしょ!」と思い立ち、MacbookAirとiPhoneアプリ開発の本を数冊買って、アプリ開発をスタート。

KindleやiBooksで購入した書籍は全部プロテクトついているし、自炊した本をOCR化までする奇特な輩は俺だけだろうという思いから、まずはWeb記事読み上げアプリのLisgoをせっせと作っていた。

そうこうしているうちに、AmazonがWhisperSync for Voiceというサービスを提供し始め、オーディオブックと電子書籍を交互に楽しむという、僕の思い描いていたサービスを始めてくれて興奮したのだが、いかんせん、リアルタイムでハイライトしないから、これが使いにくい。。

読むと聞くを繋げるというコンセプトのWhisperSync for Voice動画。

あと、もちろんオーディオブック分のお金を払うのも高いし、日本語の書籍はないし。

というわけで、「これは、もう待ってられないな。未来の読書の形はこれだというものを世の中に発表するか!」という気持ちになり、Lisgoで培ったノウハウを使ってVoicepaperを作ることになったのです。

Voicepaperを使った読書体験

とりあえず、Dropboxにtxtファイルを用意さえすればなんにでも使えるけど、想像できる範囲でVoicepaperの用途を書いてみる。

★ネット上にある論文やら長文のテキストやらをVoicepaperで読む。

★自分の書いたポエムやブログ記事の脱字チェックに使う。


★英文の文章を耳で聞きながら、ハイライトされた読み上げ中の箇所を目でも読む。(英文が読みやすい)


★テスト前に、暗記したいカンペノートを作って通学中に耳で聞く。


★自炊した本をOCRでテキスト化して、移動中に聞いたり、読んだりする。

やはりテキストはコンテンツが命なので、面白い本を使って、移動中に聞いたり、家に帰ったら途中から目で読んだりできるのが個人的には最高。

これを作ってからというもの、読みたかった積ん読本がどんどん読み進められるようになり、書籍代がかさむようになってしまった。

今度、自炊した本からのテキスト化を説明する記事を書きたい。実は、自炊した本の画像さえ用意できれば、WinのOCRソフトで自動テキスト化するのはそんなに大変ではないので。(自分は読み取り革命というソフトを使っている)

まあ、そうは言っても、めんどいのは変わらないので、はやくDRMフリーの電子書籍増えないかなと節に願っております。オライリーの本とかだったらDRMフリーですね。

このブログ読んでいる人にとりあえずオススメするテキストといえば、プロジェクト杉田玄白の、スタートアップやハッカー関連の本とか面白いと思う。

これらの文章をtxtファイルにコピペしてDropboxに突っ込んで、Voicepaperで体験して欲しい。


Yコンビネーター創設者ポールグレアムが書いたハッカーと画家

スタートアップといえばグレアムさん。温和な表情とは裏腹にかなり挑発的な事をズバズバ書くから面白い。僕もだいぶこの本に影響されました。


山形浩生さんが翻訳したエリックレイモンドのエッセイ集

ハッカー文化の考察、リーナストーバルズがいかにLinuxコミュニティーをマネジメントするのが上手かったかとか面白い。

というわけで、iPhoneかiPadを持っている方は、無料なのでとりあえずダウンロードして欲しい。

要望や不満点などをumekun123(at)gmail.comか@umekun123にくれると、なおのこと嬉しいです。

Voicepaperのダウンロードはこちらから。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

目の見えないユーザはiPhoneをどう操作するか

本日、アクセシビリティの専門家である中根雅文さんに会ってきた!

中根さん自身も全盲であり、目の見えないユーザがどのようにiPhoneを使うか、アクセシビリティとはなんぞやなど、いろいろと教えてもらったので、それについて書いてみる。

と、本題に入る前に、まず、ここまでのいきさつを書いてみる。なんで、お前いきなりアクセシビリティの話するのよ?という疑問もあるだろう。

僕はLisgoという読み上げアプリをリリースしたおかげで、視覚障害者の方から使っているよというお褒めの声が届いた事があるのです。

その時は「アプリ作っててよかったな」と開発者冥利につきて幸せ気分だったわけだが、もともと自分が移動中にWeb記事を聞きたくて作ったアプリ。特に視覚障害者向けにカスタマイズとかはしてなかったのですね。

まあ、当初からそういうニーズがあるだろうと、ある程度は予測していた。しかし、ターゲットを絞るのが重要だという思いから、まずは自分専用、もしくは自分みたいな用途のユーザ向けに絞って開発をしていた。

そんな時、去年の夏頃だっただろうか、Instapaper作者のMarcoさんのPodcast、Build&Analyzeで、ひょんなことからVoiceOver対応の話が出てきたんです。

実演しながら、「VoiceOver対応するのは簡単だから、iPhone作っているなら対応しといて損はないぞ」という話だった。

いてもたっても言われなかった僕はすぐにPhoneのVoiceOver設定をONにしてみてました。

「なんだこれは!どうやって戻すんだ!おい!」と思いながら、こんな機能あったんだなと初めて知りました。

※試したい人は、設定➡一般➡アクセシビリティ➡一番下までスクロールしてホームをトリプルクリックをVoiceOverに。アクセシビリティ項目の一番上のVoiceOverをオンにすると、元に戻しにくくなって混乱するのでトリプルでやるように!

実は、iOSのコーディングも一行。UIButtonとかBarButtonのプロパティに付け足すだけ。

helpButton.accessibilityLabel = @"ヘルプボタン"

いやあ、アップルってこういうところ凄いなと思いながら、カスタムしたボタンとかをVoiceOver対応しておいた。ちなみに、デフォのUIボタン使っていたら大抵は自動で対応されるから、デフォルトのシンプルなアプリがVoiceOverには使いやすい事が多いらしい。

それからしばらく立ったある日の事、アクセシビリティ・ビギナーズを石橋さんにTwitter上で「You、君のアプリに関係あるYO!」と薦められ、先日ほいほい行ってきた。

そしたら、もう、全然知らない事がたくさん知れて、もの凄くよかったですね。

最近、まだ知らないと自分が分っている事を知るより、自分が知らないと分らなかった事を発見するのを意識したいと考えていたのだが、まさに後者がいっぱいありました。

目が見えなくてもVoiceOver使ってPerlのプログラミングするとか、慣れると音声読み上げを爆速で使うとか、驚きの連続であった。

他にも、中根さんに、「PocketもDropboxも使っているよ、あれ凄くいいね!」とか言われた。自分のアプリはGoogleReaderに対応したら使いやすいかなと思っていたけど、まさかPocketを既に使っているとは。

アクセシビリティとはなんぞや

勉強会では、Webアクセシビリティ専門家である植木真さんも語ってくれてたけど、アクセシビリティって視覚障害者だけのものじゃなくて、あらゆる人に言える概念なんですね。

いろいろな状況でも製品が使いやすく、アクセスしやすくする。

htmlを正しく書いて機械がアクセスしやすくするとか、様々な用途で使う人間がいろいろな条件でアクセスしやすくするとか。

そういう意味で考えると、僕がiPhoneで読み上げアプリを作り始めたのも、読書のアクセシビリティを高めたいからだった。

他にも、海外の映画に字幕がついて理解しやすくなったり、英文読む時に辞書調べるのがめんどいからタップだけで辞書が出るとか、アクセシビリティを高めるのにITは大きな力を発揮している。

ITっていろいろ負の側面もあるかもしれないけど、素晴らしいな。人間が出来る事の可能性を拡張してくれる。

余談だけど、自分の専門から離れたイベントとかをたまに行くと、思っても見なかった発見とかをする。これから意識的にそういうランダム性を作ろうと思う。

これは、今読んでいるタレブのAntifragileって本の影響で、昔から影響を受けやすいので、最近そんな事ばっかりしったかしているわけなんだけど、その話はまた今度ブログで書きたい。

ちなみに、VoiceOver機能自体あまり知らない人が多いと思うので、iPhoneのTwitterアプリを操作している解説動画を撮影させてもらいました。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

アップストアの審査リスクを最小化する

ここ2,3ヶ月、精魂込めて開発していた“通勤中に聞ける太宰治”がアップストアでリジェクトされた。泣ける。

原因は「ブックアプリだからiBookStoreで出してね!」だった。。

もちろん、「いやいや、これは読み上げ機能とかあって、聞く事と読む事を繋げるアプリで、iBookStoreじゃできない」とか、いろいろごねて何回かアピールしたけど、無理だった。最後には、「そんなに言うならアピールボードがあるよ」と言われたけど、なかなか厳しそう。

アプリのコード自体は、次のDropboxのテキストファイル連携する本命アプリに流用するので無駄にはならないけど、それでも、結構な時間を太宰アプリのリリースに費やしたのでつらい。

アイコンだけは手を抜けないと思って、太宰のイラストとかもイラストレーターの方から購入して作成したし。アプリに入れる太宰作品の紹介文とかも書いたし。

調べてみると、最近は書籍アプリは基本的にリジェクトされる運命にあるらしい。ついつい、アップストアに並んでいる類似アプリを眺めながら、大丈夫だろうと思い込んでしまっていた。まあ、確かに書籍関連はそうなるのもしょうがないか。

そもそも、アップストアのガイドラインなんて刻々と変わるもんだし、アップストアで並んでいる類似アプリがあったからといってOKとは限らない。数日前に承認された類似アプリと同じような内容でもリジェクトされるリスクもある。

僕は反省しました。

もっと早くサブミットして、アプリがリジェクト対象になるかどうか確認しておけばよかった。

Webサービスを作る上での最大のリスクは、ユーザが欲しがらないものを作る事なので、最低限の機能でリリースするのは重要なんだけど、iOSアプリに関して言えば、なによりも、ストアリジェクトが最大のリスクなのに。。

可能な限り最低限の機能だけに絞って、できるだけ早くリリースすることを教訓としていたのに。今思えば、もっと省略できた。

フォントサイズ変更、ナイトモード、ランドスケープロック、カスタムUI、文字検索も、あれもこれも省略できた。「この機能やこの機能は必須だな!」と思い、サブミットするのを遅らせてしまっていた。

全部すっとばして、とりあえずサブミットしていたら、一ヶ月以上は早くリジェクトリスクを確認できた。

ちなみに、アプリ開発者なら大抵知っているけど、ストアにサブミットして承認される=ストアでリリースされるではないのです。

例えば、5月10日にストアにサブミットして、5月17日に承認されたとしても、iTunesConnectのアプリのAvailable時期を一年後とかに最初から設定しておけば、ストアにリリースされる事はない。

もちろん、承認されれば、いつでもリリースできるようになる。だいたい数時間以内に反映される。さらに、アップストアに承認された時点で、TestFlightのような面倒なサービス使わずとも、プロモコード配布でβテスターにカンタンにアプリも試してもらう事ができる。

これは、アップストアのリリース時期は一年後にしてても、承認さえされればプロモコード経由でストアからダウンロードできるから。

ああ、なんてバカだったのだろうか。

これからは、もっともっと、「この機能は後回しにできるんじゃないか」と自問自答して、いかにやらないかを考え、まずはリジェクトリスクを確認する。ついでにリリースを早める事を徹底したい。

リリースする事で、いろんな事が分るし、使ってもらえる人の反応もわかるし。最初から大々的に宣伝して初動で回収するアプリを作ってるわけでもないし、最初は評価低くなっても、こつこつよくする予定だったらそこまで関係ないし。

とにかく、これからはもっと早くサブミットするよう気をつけよう。だって、アップストアって、すごい些細なメタデータ入力不足とかでリジェクトされて、速攻で修正してサブミットしても、平気で数日返事待たされたりするからなあ。

ちなみに、太宰アプリのティザーサイトに登録してくれた方は、次のアプリ「読み上げさん(仮)」が出た時お知らせしようと思います。これも、もうサブミットしたけど、今審査中。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

サービスにハマる過程とは

最近、以前は理解できなかった利便性に、どういう風に自分は気づき始めるかというのを凄く考えている。

もう、本当にこれは、切実に考えている。

なんでかというと、LisgoやVoicepaperで広めようとしている、”目で読んでいる読書の続きを、立ち上がった後に耳で聞く”という新しい読書体験が、とても理解されにくいからです。

一度理解してもらうと凄く刺さるし、この体験は読書好きじゃない人でも読書に親しむようになるぐらい大きな事だと思っているけど、そこまで理解してもらうのはとても難しい。

でも、これは、至極当たり前のことで、自分もいろいろなことにおいて、あるサービスや、製品の機能について、最初はさっぱり理解できなかったことが、それはもう、本当にたくさん、しょっちゅうあることに気づいた。

自分に最近起こった変化、さらには、自分がサービスを広める側なら、どうやってその変化まで持って行けばいいかを書いてみたい。

最初、理解できなかったもの

最近の例でいうと、iOSのフリック入力。

僕はキーボードでの入力に慣れ切っていたので、iPhoneを始めて買った数年前、携帯で文字を打つのを頑なに拒否してた。

いやいや、キーボードで打つほうが遥かに早いし、打ちやすい。こんな小さい画面でチマチマ打つなんて非効率すぎるわ。その時間は違うことしたほうが有益だな。とか思ってた。

でも、フリック入力に慣れてくると、キーボードほど速くも正確でもないけと、モバイルで文字を打てるメリットがありありと理解できてきた。

それは、もう、薄々理解してたつもりだったけれども、実際に習慣になるまで、本当の意味でしっくりきてなかったアハ体験。

外でもいろんな状況で打てるし、寝転びながらでもブログが書ける。なんで、長文書く時は、絶対キーボードじゃないと嫌だと、あそこまで、頑なに拒んでいたのでありましょうか。

もうひとつは、マニアックな開発ネタで申し訳ないのだど、CocoapodsというiOS開発のリーサルウエポン的なシステム。

これは、いろんなオープンソースライブラリを超絶簡単に入れたり出したりできる神ツールなんだけど、使い始めるまで設定とかめんどくさいし、今までのやり方で別に不満ないからなーと思ってた。

この、今までのやり方で満足してるからなーというのが結構重要なポイントだと思う。

やはり、別に満足してるもののを、面倒なコストかけて新しいことを覚えるのは疲れる。だから、はっきりとしたメリットを自分がイメージできないと、人間なかなか以前の習慣から移ることができない。

しかし、恐ろしい事に、一度使い始めて、最初は、「まあ、便利だけど、別に以前のやり方でもいいかな」とも思ってた。

そんな自分が、cocoaPodsをしばらく使っていると、「あれ、これないと俺もう死んじゃうぐらい便利だわ、これなしではオープンソースの管理めんどすぎ。もう戻れない。」とまでなってきた。

新しいサービスを提供する側になった時は、どうやって、この状態まで持っていくか、出来る事はなにかを考えてみたい。

利便性に気付くプロセス

自分が新しいものの利便性に気付くまでは、いくつかのプロセスを辿っていると思う。

まず、誰かがそれについて薦めてくる。気付く。気になる。使い始める。まだよくわからない。でも、とりあえず続ける。慣れて来て、利便性にはっきり気付き始める。習慣になる。

例えば、フリック入力なら、だいぶ前にどこかのブログでフリック入力が絶賛されていて、出来るだけ使うように努力し始めた。とりあえず、使い続けてたら、慣れて来た。だんだんとツイッターとか、長文のブログでも使い始めた。

CocoaPodsなら、iOSTokyoMeetupで絶賛されてたから、これは時代に乗り遅れそうだぞと思い使い始めた。で、あまりよさが理解できないまま使い続けてたら、離れられなくなった。

さて、サービスを提供したい側なら、どうやってこのプロセスを促進できるんだろうといつも悩んでいる。

まず、サービス自体に価値があって素晴らしいものだという前提で話を進めてみる。

どう持っていくか

もっとも重要なのは2つの部分だと思う。

1つ目は導入がいかにカンタンか、2つ目は、まだよくわからないけど、とりあえず使い続けてもらうこと。

1つ目はとても、とても難しい。特に、なかなか利便性が理解されないようなサービスであるほど難しい。

ParseとかCrashlyticsのようなサービスは、導入でいかにつまづかないか、本当に細かいところまで気を配って手順が設計されていると思う。

モバイルアプリなら、開いた後に、いかに離脱せずに、らくらく前に進めてもらえるか。

2つ目の、とりあえず続けてもらうという部分も結構難しい。

一度使ってみて、ああ、これいいなと思っても、しばらく使ってなかったら忘れられるというのがよくある。

これに対処するには、Webサービスだと、メールアドレスを登録してもらえるようなインセンティブを作って、忘れないように定期的にお知らせを送るのがよくある。

スパムにならないように、ユーザが開きたくなるようなものがいい。

モバイルアプリだと、定番なのが、Push通知。家計簿アプリのZaimはしばらく使ってないと、「お金の入力最近してませんよ」というような通知がいくらしい。これはユーザも納得の通知だし、上手いなと思う。

他に思いつくのは、ゲーミフィケーションで、利便性がまだよくわからない段階でも、なんか気持ちいいから続ける仕掛けを作るとか。

気持ちいいからなんとなく続けるという意味では、効果音とか、アニメーション自体が気持ちいいというのもある。

とにかく、考えだしたら本当に細かい部分までいろいろある。

ちなみに、まずは、誰か製品を欲しがる人がいるかどうか、これを確認できた後に優先度を上げる項目なので、どのタイミングでこれらの事柄に力をいれるかも難しい。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

一番リスクの高い部分から始める

僕は、新しいアプリを作る時は、一番リスクの高い部分をまず考えるようにしてます。

これは、一番不確実な部分をまず確かめるという意味です。

でも、一番リスクの高い部分を確認するための方法は、一番簡単に、速くわかる方法を探すようにしている。

アプリやサービスのアイデアでも、プログラミングでも、全部そういうふうに考えるようにしている。

Continue reading


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

iPhoneの月額課金はツール系で使えるか

※追記 2013/06/15

これはだいぶ前の記事だけど、結局、Auto-Renewing Subscriptionsは今まで通りの気配。。最近、アップルの課金関係のエバンジェリストにメールで聞いたら、「最終的に決めるのはReveiw Teamだからわからないけど、基本的に機能にたいしてはAuto-Renewableは使えないよ。」みたいな返信をもらった。残念すぎる。

どこまでが機能で、どこまでがMediaと認識されるかという線引きはよくわからないけど、特に今までとルール適用の方針は変わらないのだろうか。

 

 —— ここから以前の記事

知り合いに教えてもらったんだけど、ちょっと前にApp Store Review Guidelinesが変更されてたみたい。これ読む限りでは新聞とか雑誌系のアプリ以外でも自動継続課金(auto-renewable subscriptions)が使えるようになったのかも。まだわからないけど、これは期待!

Continue reading


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

未来を待てないからプログラミングする

最近プログラミングを初めて楽しそうな友達とお茶漬け専門店でメシ食いながら、「本当はコードなんて書かずにモノが出来上がるぐらい簡単になればいいのに」という話をした。

一緒にお茶漬け食いにいったJ君は最近iPhone開発を始め、自分が旅行中に必要だったニーズを満たすものを実際に作って嬉しそうだったのですが、iPhone開発する時の不便さに怒り心頭らしい。

僕は、「プログラミングって奥が深くて、綺麗な設計ができるようになるたび楽しいなあ」とか、「プログラミング始めたのは人生で最良の決断だったなあ」とかいきって真夜中にTwitterで呟いたりしちゃうんですが、確かにもっと簡単になればいいとは思う。

プログラミングの面倒さに怒り浸透のJ君

まあ、NavigationControllerとかいろいろと細かいプログラミング用語をここで羅列してもなんのこっちゃわからなくなるので、簡単にまとめると、「なんでこんなカンタンな事が、カンタンに実装できないの!」という愚痴を延々と僕に浴びせかけていた。

J君「もっと直感的に、画面上で操作できるようになってほしいんだよ!」

俺 「まあ、一応、iPhone開発もストーリーボードとか最近は出来て、楽になったよ。」

J君「ストーリーボードは結局細かい事ができないからコードで書かないといけないじゃないか!」

俺 「まあまあ、エクセルのショートカットみたいなもんだよ。なれるとコマンドのほうが便利になるのは万有引力の法則と同じぐらい自明なんだよ。」

J君「その最終的にはコマンドで打つのが楽というのがおかしい。結局、作業なんだから、簡単にわかりやすくできるようにならないと。。」

まあ、数年前に比べてARCとかできてiPhone開発はだいぶ楽になったから、やろうぜ、楽しいよと周りに言いまくっている自分ですが、実のところ、結局プログラミングは面倒な事のオンパレードです。

本来ならば、こういうものを作りたい、こういう順番でUIを見せて、こういうデザインで、こういうわかりやすくする心理的しかけがあってと言ったような人間様がやるべき仕事に集中したいんですよね。

最近は、「デザイナーもプログラミング覚えるべきだ」とか、「テクノロジ系スタートアップのファウンダはコードが書けないといけない」とか、なににつけてもプログラミング重要といった風潮です。

僕も、プログラミングできるとUIデザインに凄く役立つよみたいな記事を最近書いたばかりだ。

※デザイナーはプログラミングも覚えないといけない時代なのか

人間、なにか新しいことをちょっとかじったら、これは○○にも役立つとか、○○できないやつはダメ!とか言いたくなっちゃうんですよね。

たぶん、僕が統計学を本気で勉強したら、統計学は最強の学問だとか言うと思うし、歴史学だったら、歴史に学べないやつはクズだとか言いそう。

最近、なんかみんなコードを習うべきだみたいなカッコいい動画も海外で作られてもいたし。

これに対してJ君いわく、いやまてよと。現状でそうなるのはしょうがないし、プログラミング行為自体の楽しさは認めるけれど、進むべき方向としては、プログラミングなんて不要になるぐらいカンタンにモノが作れる世界だろと。

確かに、僕もプログラミングがもっと簡単になって、全部直感的な操作で自分が欲しいものを作れる世の中になったらいいなあとよく思う。

今でも、子供でも簡単にプログラミングが出来るようなものが出来つつあるけど、まだまだ教育用の枠組みだ。

理想を言えば、GUI操作さえもいらなくなって、「こんな感じに操作できて、データはこう記録されて、画面のアニメーションはしゅっとこんな感じ!」といったように、長嶋監督もびっくりの身振り手振りでコンピュータに要求すれば、「こんな感じでしょうか?」と提案された実装がすぐに出来上がるのがいいな。

こういう未来の話をしても、現実世界ではテクノロジーが追いついてないんだからしょうがないんだけど、こういう視点を忘れないようにするのは意味があるとは思うんですよ。

つまり、なにかを実現したくて、それにむかっていろいろな作業に没頭していると、本来の作業自体の効率化に目が行ってしまうというか。

僕は見た目が綺麗で分りやすいコードの書き方とか、綺麗な設計とか、メソッド名は何がいいかとか、プログラミングの奥の深さが好きなんですが。

ちなみに、文系人間だからプログラミングなんて無理無理と思っていて僕に、「プログラミングは手に職つくし、論理的思考が高まると思うからお勧めだ。それになんか楽しそうじゃん。」と数年前にプログラミングを勉強するよう薦めて来たのもJ君であったりする(笑)

未来を待ってられないから手を動かす

ただ、現実にはコードを書かずにモノが簡単にできるほどテクノロジーは進化してないんですよね。

簡単になるまで待つという選択肢もあるけれど、それが待てないなら、実際に手を動かして作るか、作ってくれる人を探すしかない。

今、このブログもキーボードで打っているけど、出来れば自分の思った事をそのまま入力してくれる技術ができればいいとは思う。

でも、そういう未来は待ってられないし、とりあえずキーボード打つのはそれほど難しい事じゃないから、ぺちぺちとマックでブログを書いている。

プログラミングに関しても、すげえ適当に書いても勝手に綺麗に整理してくれたり、マシンパワーで非効率な設計も補えるようになるかもしれない。

でも、現時点では綺麗な設計で効率的なコードを書くのはもの凄く重要だし、このことはそんな簡単に変わらないと思う。

もちろん、数十年後にプログラマーという職業の需要が今程あるかどうかは定かではなくて、その時々に要求されるスキルってそういうもんだし、ずっと続くものなんてないからなあ。

これはスキルだけじゃなくて、サービスの市場もビジネスモデルも、ずっと現状と同じように続くものなんてないし。

現実世界の制約を忘れて未来の事を想像するのが重要だから、SFとか読むのって大事なんでしょうね。

ちなみに、文系の人向けのプログラミング勉強方法を昔書いたので、紹介。

※挫折確率を下げるプログラミングの覚え方


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

動かしながらデザインする

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ペーパープロト

自分しか理解できないかもしれないLIsgoのUIを考えてた時のメモ書き。

そこから、もうちょっと突き詰めて、自分を第三者の視点で観察するとか、ユーザを観察するとかの話はこちら。

使いやすいiPhoneのUIを作るために気をつけていること

でも、プログラミング覚えるのは大変でしょう?

これは悩むところです。人間の時間は有限だから、各自で一番最適だと思うことに時間を使うしかない。

これができたらいいよー、これもできたらいいよー、この知識があるとないとでは全然違うよーというのは、どれも正論であることが多いですよね。

でも、自分が今やる価値はあるかとか、これから覚える意味はあるかとか、必要になった時に勉強したほうがいいか、他人に任せて自分が得意な事に集中するかは人それぞれの状況に応じて違ってくる。

結局、”これからは英語勉強するべき”とか、”○○もコードが書けないといけない”とか、そういうのは自分でやりたいと思ったらやればいいし、必要でなければやらなくていいと思うのです。

だから、この記事も、そんなもんかと思って読んでくれたらこれ幸いです。

余談ですが、最近はデザイナの定義が広すぎて、デザイナーですと言ってもどれが専門か聞かないとよくわからない。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

Copyright © 2025 うめのんブログ

Theme by Anders NorenUp ↑