Categoryプログラミング

WWDC2016独断と偏見によるまとめ

WWDC2016(Appleの開発者向け会議)が終わりました。

昨年は、フリーランスエンジニアとして、友達と一緒に気楽にSFに遊びにいきましたが、今年は会社立ち上げ直後・絶賛プロダクト開発中ということもあり、朝食を食べながら、セッションビデオをApple TVにストリームしてキャッチアップしました。

発表内容は盛り沢山でしたが、その中で気になったトピックをピックアップしてみました。

なお、ちゃんと網羅的に内容把握されたい方は坂田さんのブログをどうぞ。

CallKitの解放で、MNO離れとMVNO人気上昇がますます進む

LINE、Whatsapp, ViberなどのVoIPアプリの無料電話で、着信に気付かず取れなかったという経験をした人は多いと思います。iOSではサードパーティのアプリが表示できる通知の作法が一律で決められており、電話の着信であろうとも、ロック画面にぴゅっと表示が出て、端末が一回震えるだけでした。これではなかなか気づかれないため、結局お店に電話するときや自宅に電話したりするときなどは普通の電話を使ってました。

しかし今回のCallKitの解放により、LINE等のVoIPアプリでも標準の電話UIを利用することができるようになりました。まだ実際に試していないので確実ではありませんが、電話着信時にロック画面を全部乗っ取って、電話を鳴らし続けることができるようになるはずです。

こうなると、通常の電話とVoIPの無料電話の間では「音質」しか差が無くなります。最近のVoIPアプリの音声圧縮技術の向上と、モバイルネットワーク回線自体の品質の向上により、普通に使う分にはほとんど差を感じないぐらいになってきていると感じます。

「電話がかけ放題だから」という理由で、MVNOに手を出さず、MNO(ドコモ・KDDI・ソフトバンクら)に残っているユーザも多いと思いますが、LINEの無料通話で十分となれば、ますます「データ回線」だけを求めるユーザが増えるキッカケになりそうです。

watchOS3が劇的に進化し、Appleの本気度が見えた

Apple Watchは1,000万台を出荷したとはいえ、まだ到底「成功」と言えるレベルには達していないと思います。

一部の人の間では、Google Glassのようにひっそりと見捨てられていくのでは・・・なんてウワサもあったなかで、多くの大改善が発表されました。

一番の改善ポイントはよく使うアプリが一瞬で立ち上がるようになったこと。

現状のwatchOS2ではアプリの起動に3-4秒かかることもあり、「そんなに待つんだったら、iPhoneをポケットから取り出したほうが早いヨ!」と叫びたくなることも。

watchOS3では、アプリがコンプリケーション(文字盤の上のウィジェットみたいなもの)に設定されたり、ドック(後述)に設定されると、よく使うアプリとして認識され、アプリがメモリに格納されるため、起動が7倍速くなります。実際デモでも一瞬で起動してて、体感上100倍ぐらい速くなっているように感じました。笑

次いで、インターフェースの改善も大きいですね。ぼくはこんな記事を書いて、インターフェースについて苦言を呈していたのですが、以下の様な改善が施されました。実際に使ってみないと分かりませんが、相当使い勝手がよくなる予感がします。

画面下からのスワイプ
全く使わないグランスが消滅して、iPhoneでおなじみのコントロールセンターに。

端末横のボタン
全く使わない電話帳起動が消滅して、ドック機能が割り当てられた。ドックにはよく使うアプリを登録して、スワイプして切り替えられる。(下図)

iMessageのテコ入れで何が起きるのか

しばらく放置状態だったApple純正メッセージアプリのiMessageに大リノベーションが施されました。LINEやWeChatのようなステッカーが入れられるようになるだけでなく、ステッカーストアも開設。

多くの人はLINEでよくね?とスルーかもしれないけど、意外にインパクトあるんじゃないかと思います。

うちの母親を例に取ります。まず彼女はアプリを自分でダウンロードしてセットアップすることができません。

さらにLINEやWhatsappとかってSMSで受け取ったピンコードを入力して、普通のアプリより一段難しいセットアップが必要だし、何かとマネタイズ攻撃をしかけてくるから、その度に不安になるようで、「こういう文言がでたんだけど、キャンセルしても大丈夫?」とか毎回聞かれるんですよね。

メッセージの表現能力ではほぼLINEに追いつき、セットアップが要らず、今後のサポートも軽そうだから、親にはiMessageを使わせようかと思ってます。

こういう人結構いるんじゃないかなぁ。

ちなみにギークの皆さんには信じられないかもしれませんが、iOSデバイスではGoogle Mapsの3倍Apple Mapsが使われているとのこと。プリインアプリの力、恐るべし。

アップルの中で進むオープン化とリーンアプローチ

俺様の後について来い!スタイルのスティーブ・ジョブス政権下と比較し、ティム・クック政権下では以下の3つの方針が透けて見える気がします。

リーンアプローチ
AppleWatchをギリギリ使えるレベルで出荷。ユーザフィードバックを集め、マーケットとの対話によってプロダクトを進化させていく。
スティーブジョブス存命時であれば、Apple Watchのリリースは1年遅らせて彼が十分満足するものになってから出荷したかもしれない。

オープン化
API(WebKit, SiriKit, CallKit)、プログラミング言語(オープンソースSwift)などを続々と公開

重要ドメインは自分で抑えに行く
地図、コミュニケーション、ニュースなど、プラットフォームとなり得るドメインは自分でもやる。

独裁者政権から、民主政権にスムーズにトランジッションされた感があります。キーノートのエンタテイメント性がスティーブ存命時に比べて著しく低下してしまったのは致し方のないところでしょうか・・・

個人的に

自分がいま作っているアプリの大前提が根本から覆るような発表があったらどうしよう・・・と内心ビクビクしていたのですが、それが杞憂に終わり、とりあえず向こう1年は安心して邁進できることが確認できたことが一番の収穫でした。ホッ。

 

プロダクトづくりの観点から見た理系・文系の区別の弊害

理系・文系のくくり方をもう止めた方がいいんじゃないの?と思います。特に高校で決めたら、基本的にそれが一生ロックされるというならわし。

僕はハード・ソフト含めて10年あまりプロダクト作りに携わってきたので、その経験をもとに、どうしてそう思うのかを書いてみます。他の業界のことはよくわからないので、ぜひこのエントリーを読んでご意見くださいませ。

この区別の起源

Wikipediaの「文系と理系」の項を読むと、文系・理系という区別は、旧制高校の制度に起源があるようです。
 

そもそもこんな区別があるのは、発展途上国の特徴である。黒板とノートがあればすむ文系にくらべ、理系は実験設備に金がかかるので、明治時代の日本は、学生数をしぼらざるをえなかった。そこで数学の試験をし、文系/理系をふり分けることにした。入試問題が別々なので、その前の段階で文系/理系を選択しなければならない。

— 橋爪大三郎、『橋爪大三郎の社会学講義2』(夏目書房、1997)63頁

 
なるほど、結構納得感のある説明。でも、旧制高校って今から100年以上も前の話。いったいこの制度いつまで続けるの?という点はしっかり考える必要はありそうです。

ものの作り方が変わってきている

ものづくりは、
  • 自分の得意なこと(技術)
  • 世の中に求めてられていること(ニーズ)
  • 自分のやりたいこと(意思)

の重なる部分でやるわけですが、最近この3要素間の比率が急激に変わってきているように感じます。

 
これまでのものづくりでは、自分の得意なことを最重要視して、それをいかに売るかというアプローチが多かったと思います。うちは液晶が強いからテレビ作ろう!とか。こういう風に、何を作るのかがビシッと決まっている時は完全に分業するのが正解で、技術者(理系の人)が技術を突き詰めた商品を作り、それを営業(文系の人)が売ってくるモデルが成立していたのでしょう。
 
しかし昨今、ものを作るための手段は、だんだんとコモディティ化が進んでいます。ハードウェアでは、チップセット、メモリ、基板、液晶、バッテリ、外装を組み合わせればそれなりの商品を作ることができます。ソフトウェアでは、開発フレームワーク、API、OSSライブラリなどを組み合わせることである程度のプロダクションサービスを作ることができます。
 
そんな中で今最も大切なことは、ユーザー体験を起点に考え、世の中に求められているものをいかに作るかなのですが、この「世の中に求められるもの」を掘り当てるのが非常に難しいわけです。文系の人が、「これがニーズあるものです」という企画を作って、理系の人が「はいわかりました。それ作れば売れるんですね。頑張ります」というモデルは成り立ちませんw
 
エンジニア、デザイナー、企画者、経営者、という役割の境界線さえも一旦忘れ、ユーザーの価値を作るというゴールからの逆算でアプローチする必要があります。境界線の中にこもったきりでは既存の思考の枠を出ることはできず、境界を超えて思考することで、はじめて破壊的なアイディアの可能性が生まれてきます。
 
一人ですべてをやろう、というのではありません。得意分野(major / expertise)はもちつつ、より幅広い分野の知見を貪欲に吸収していかなければ、得意分野の強みが活きない時代になってきているのです。

思考停止の遠因

もちろん、自らその境界を突破して知見を獲得しようとする人たちもいます。でも、多くの人は、自分のコア領域の周辺には進出するものの、理系・文系の境界線に差し掛かると、無意識にそこで歩みが止まる人が多いのではないでしょうか。
 
たとえば、マーケティングを専門にしていた人が、営業や商品企画に進出することはあっても、「今後のマーケティングではプロダクトの中身もある程度理解していないといけないな」とエンジニアリング領域の勉強をするところまで行く人はあまり多くないと思います。そのリターンは非常に大きくなっているにも関わらず。
 
このように無意識に境界線の前で立ち止まってしまうことこそが、理系・文系区別の一番のデメリットだと思います。
 
多くの場合において、高校2年ぐらいで理系か文系を決めると思いますが、そのときなんとなく決断を下した結果、「あ、ぼくは文系なんだ」「あ、きみは理系なんだね」というレッテルが貼られ、自分でも意識しないうちに上記のような非合理的な決断を一生続けることになるのです。
 
実際のところ、ぼくがプログラミングを勉強してる話なんて言うと、まわりの反応は「あれ、文系だよね?」が決まって第一声の反応です。
 
僕のプログラミングスキルは大したことが無いのですが、これまで培ってきた商品企画・プロダクトマネジメント・プロダクトマーケティングのスキルとプログラミングスキルをかけ合わせることで差別化を図ることが可能で、サラリーマンとしても組織の中で差別化を図ることができましたし、個人としてリリースしたTennisCoreもApple Watch Best of 2015アプリに選んでもらうなど一定の成果をおさめることができました。境界線を超えた「掛け合わせ」のメリットは非常に大きいなと実感しています。
 

組織づくりまで理系・文系ベース

理系・文系の区別は、そのはじまりは実利的な理由によるものだったかもしれませんが、今では、ほぼ宗教かと思うほど盲目的な信仰です。その証拠に、理系・文系の境界の延長線は高校、大学のみならず、実社会においても続きます。文系の人は企画部へ、理系のひとは開発部へ。
 
何を作るかが明らかな時代においては、この機能切りの仕組みがワークしていたかもしれません。しかし、ユーザー視点から逆算してモノを作るべき現代、新たな価値を生み出さなければならないフィールドではことさらに、プロダクトごとの組織をつくるほうが成功確率は圧倒的に高いと思います。

教育を逆算方式に

では、どうすればよいのか?
 
まずは個々人が、無意識に持っている理系・文系を壁を意識的に取り払う必要があるのは言うまでもありません。とはいえ、個人の努力に頼るだけではなく、仕組みの改善も必要です。
 
ぼくは、学校教育も実社会のように達成したいことからの逆算方式にするべきではないかと思います。
これまでの教育は、いろいろな経験をした大人たちが、将来こういうツールが必要になるからいまから勉強しておくといいよ、というのを考えて子どもたちに「与える」というスタイルの教育でした。その結果、ぼくたちは、数学や物理や古典など理由もわからず学んできました。なんとか自分で意味を見いだせた科目はよいのですが、そうでない科目は苦行以外の何物でもありませんでした。
 
今後は、この「これなんの役に立つの問題」を撲滅し、
 
世の中ではどんな問題があるという点を気づかせる。
その解決方法にはどんな方法があるのかを発見させるためのサポートをする
そのためにはどんな知識・能力が必要なのかを考えさせる
目的と意味付けを理解して学習する
 
というアプローチを取っていくべきではないでしょうか。この際、今学校で教えられている国語、数学、外国語などと同じような知識が使われるはずですが、生徒の学習意欲、習熟スピードの観点で言うと現在の数倍の学習効果が上がるのではないかと思います。
 
また、この時に取り組んだ「問題」が10年後、20年後に存在しない問題になってしまったとしても、問題から逆算して必要なことを自ら学んでいくというユニバーサルなスキルは廃れることはありません。
 
そんな教育においては、理系・文系という区別は意味不明なシロモノでしか無いと思うのです。
 
 

iOSアプリの配布サービスは結局Test Flight(公式)がいい

アプリではValue Proposition(提供価値)やUX(ユーザー体験)が大切なことはもちろんですが、致命的なバグや・初歩的なユーザビリティの欠陥が無いことが大前提です。なので、公式のアプリストアでアプリを配る前に、友人や同僚にアプリを配って試運転をしている開発者の方は多いかと思います。
 
公式ストア経由以外でアプリを配布するためのツールとしては、Test Flightというサービスがデファクトスタンダードでした。しかし、Test Flightサービスを運営するBustly社がAppleに買収されたことによって、状況がちょっと変わってきました。
 
iOSではTest FlightサービスがAppleの開発者向け管理画面(iTunes Connect)の一機能として組み込まれ、Android向けのサービスは残念ながら終了となりました。
 
これからどうすればいいか?AppleのTest Flightを使ったほうがいいのか。何かほかのツールを探したほうがいいのか。
 
元祖TestFlightと比べると別物になった感がありますが、僕の結論としては、生まれ変わった公式Test Flight (iTunes Connect)を使い続けることにしました。
 
ただ、実際に使ってみて、ちょっとトリッキーな点もいくつかあったので、それらのTIPSも含めてシェアしたいと思います。
 
Apple公式Test Flight on iTunes Connectの概要はこんな感じ。
  • Internal Test(内部テスト)とExternal Test(外部テスト)がある
  • Internal Testはその名の通りチーム内(開発者、デザイナー、マーケターなど)にアプリを配布するためのもの。登録15名まで。アップルの審査が要らない。
  • External Testは1000人までアプリを配ることができる。アップルの審査が必要。

詳しい使い方はこちらを見ていただくのがよいかと。

 
まずは、このサービスのメリットをまとめてみました。
 
  1. 完全無料(開発者登録してれば)
  2. プロビジョニング気にしなくていいから開発者がラク
    • iOSアプリでは、Appleのプロビジョニング(身元保証書みたいなもの)がないとアプリをインストールするができませんでした。なので、アップル以外が提供するアプリ配布サービスでは、こんなながーーいプロセスを経ないとアプリを配布することができませんでした。
    • 公式Test Flightではこんな感じでだいぶシンプルに使えるようになりました。ステップ数で言うと半分くらいですかね。何よりも新しいユーザーを追加するたびに、provisioningを追加してビルドし直す、という作業をしなくてよいのが素晴らしいです。
  3. テスターさんもラク
    • 今までは、Appleのタイトコントロールのおかげで、ユーザー(テスター)さん側でも、アプリの「プロファイル」を端末に入れてもらう必要がありました。こんな感じのことをお願いする必要がありました。技術に明るい人ならいいのですが、アプリを本当にテストして欲しい人って、そうじゃないケースのほうが多かったり
    • 公式Test Flightでは、これも必要無くなりました。Test FlightというアプリをApp Storeからダウンロードすると、この辺のことをあとはよろしくやってくれるのです。
  4. Internal Testではアプリ内課金(IAP)のテストができる
    1. 僕自身はIAPを自分のアプリにいれたことが無いのですが、先日参加したiOS All Star勉強会で教えてもらいました。
 
デメリットも結構ありますw
 
  1. Internal Testは、プロジェクト掛け持ち不可
    • ある人を僕のプロジェクトに登録したところ、Appleさんから「すでに他のプロジェクトのメンバーだから登録できません」と言われました。普通に複数のプロジェクトを掛け持ちしている人なんて沢山いると思うのですが・・・
  2. External Testはアップル審査が必要
    • そもそもβ版の配布になぜ審査が要るんですかね?Androidなんて公式リリースでも審査無いのに・・・ただ、審査期間は通常の審査に比べて著しく短かったです。だいたい1日から長くても3日程度。おそらく審査基準も通常審査よりも甘め。年末の審査すごく混みあう時でも、External Testの審査は即日OKが出ていたりしたので、違うチームが審査しているのかもしれません。 ちなみに、Appleのカスタマーサポートには、βテストなのにそもそも審査するのがおかしい、とメールしておきました。
  3. テスターのデバイスがiOS8以降でないとダメ
    • iOS8は浸透が遅いので、未だに結構iOS7の人がいます・・・
  4. Xcode Beta versionでビルドしたアプリは受け付けてもらえない
    • なのでWatchアプリとかはまだ配れません。
 
注意事項
 
  • テスター登録はApple IDのメールアドレスで
    • テスターを友達にお願いするときには、Apple IDとして使っているメールアドレスを聞いて、それを使うようにしてください(これによってprovisioning / profileまわりをよろしくやってくれるので)
  • 招待状はApple標準メーラーで開いてもらう
    • テスターさんのメールアドレスがgmailだった場合、招待状をGmailアプリで開くとなぜかテスト用アプリがインストールできませんでした。Apple標準メーラーで招待状を開くとインストールできました。
 
まとめ
 
というわけでバラ色のソリューションという訳ではありませんが、僕にとってはprovisining/profileまわりを一切考えなくてアホアホ配布できるというのは、デメリットを補って余りある利点だと思ったので、このまま公式Test Flightを使っていくことにしました。
 
おまけ情報ですが、アプリのバイナリファイル(IPAファイル)をウェブにアップロードするだけで、ウェブ上で擬似的にアプリを実行できるappetize.ioといイケてるサービスもあるみたいです。
 
実機で体験するとのは違うとは思いますが、目的によってはこういうものを使ってもいいかもしれないですね。
 
あと、Androidは?という声が聞こえて来そうですが、Androidはprovisioning / profile等の面倒がないので、正直どのサービスを使ってもそれほど変わらないかなーと思います。配るだけなら、ツールを使わなくても、apk本体をメールで送ることもできますし。
 
候補としては、hockey app, ubertesters, deploygate, crashlyticsあたりがメジャーな選択肢で、値段・ユーザー数・プロジェクト数・その他の付加機能等を比べながら選んで頂ければよろしいかと。
 
以上、アプリビジネス/アプリ開発やってる方々の参考になればうれしいです!

文系人間もプログラミングを学ぶべきか?

最近、プログラミング(コーディング)を勉強しよう、という記事をよく目にするようになりました。

でもさー、プログラミングって難しいんでしょ?

いくら頑張っても結局エンジニアの人にはかなわないんだから、そんなものに手を出さないで自分の得意分野に集中したほうよくない?

という考え方もありますよね。この記事では、俗に言う「文系」人間がプログラミングを学ぶメリットについて考えてみたいと思います。

何を隠そう私自身も、生粋の文系人間なのですが、1年前にiPhoneアプリづくりを始めて、なんとか2つのアプリをリリースすることができました。

Mail Now – ワンタッチメール送信

TreasureBox – 好きなものを一か所に集めてあなただけのランキングを作ろう

たった1年でありますが、この経験をもとに、タイトル「文系人間もプログラミングを学ぶべきか?」への結論を書くと、

たしかに大変だけど、それを補って余るくらい楽しい。

全ての人が勉強する必要はないけど、少しでもテクノロジーに触れる仕事をしている、もしくはテクノロジーを使って世の中を楽しくする・便利にするのが好き、という人は一度トライする価値があると思います。

もうすこし具体的にどんな人にオススメかというと、下の3つの質問のうち2つ以上がYESならかなりオススメです。全部YESなら今日からはじめましょう 🙂

  1. テクノロジーを使って、実現してみたいことはありますか?

  2. 新しいことを学ぶことは好きですか?

  3. 好きなことは、とことん突き詰めてやるタイプですか?

では、この3つの質問にそって、話を進めていきたいと思います。

作りたいものを思いのままに作るための武器

いま、ITの世界はものすごく面白いことが毎日起きていて、この先少なくともあと10年はさらに進歩が進んでいくと思います。そんななかで、あーこういうサービスがあれば、こんな風に問題が解決できるなぁ、というアイディアを思いついて、今日からでも動き出したいような人にとって、プログラミングは絶好のツールです。

社内の人間(マネジメントやチームメイト)を説得すること無く、会社を起こすために資金を集めることもなく、今すぐ作り出すことができるのです。

IT系の会社で働いる方は、本業にも必ず活きます。IT系の会社にとってのプロダクト開発は「本業」です。メーカーにとっての「生産現場」と同じです。ここでどのようにものづくりがされているかを知らずして、会社の戦略を立てることはできないと思います。企画・プロダクトマネージャー・ディレクターなどの仕事に従事される方はもちろん、管理部門や営業など直接関係のない職種の方でも、必ず本業のクオリティーを上げることができるはずです。

たしかに難しいけど、英語よりカンタン。

幸いなことに、開発の敷居はどんどん下がっていて、あなたがコンピューターを持っているなら、ほとんどの開発環境を無料で整えることができます。(スマホアプリをリリースしたいなら、AppleやGoogleに開発者登録をする必要がありますが。前者は約1万円、後者は約3000円程度。)

ご存知かもしれませんが、プログラミングをするにはプログラミング言語を学ぶことになります。「言語」なので、英語などと比較したくなりますが、英語より断然カンタンです。英語だと読む、書く、話す、聞く、が必要ですが、プログラミングは読んで、書ければOkです。それにリアルタイムで反応を返す必要もありません。何か分からなければ、うーん、うーんと悩みながらGoogleを検索したり、詳しい人に聞いたりしながら、答えを出せばいいのです。

さらに言うと、最初は「書く」ことさえできなくても大丈夫です。ある程度アプリ作りの仕組みを理解したら、ウェブや参考書で自分が望む動作と似ているコードを頂戴してきて変更していきます。またプログラミングでは「ライブラリー」という便利な道具があって、多くの人が共通で使うようなコードは、ただ部品を組み込んで呼び出すだけで目的達成です。まずは自分が作りたいものを手段を選ばず作っていき、そのうちに少しずつ自分のオリジナルのコードが書けるようになればいいのです。

目的を達成するために新しいことをどんどん学んでいくプロセスは楽しいものです。スポーツで試合に勝つために、新しい技術を習得していくプロセスにも通ずるものがあると思います。

最後は情熱

さんざんハードルを下げておきながら、相反するようなことを書きますが、プログラミングをしてると、必ず「ハマリ」ポイントがやってきます。自分では絶対動くはず、と思っているコードが思い通りに動かなかったり、どうやって目的を達成するコードを書くのか皆目検討がつかない状況です。そんなときにはひたすらドキュメントを漁ったり、識者にアドバイスを求めたり、自分が書いたコードを穴が空くほど見なおしたりして、なんとか迷宮から抜け出す必要があります。そんなときには、くじけそうになるのですが、「このアプリをなんとか作って世の中に出したい」という思いだけが心をつなぎ止めてくれます。そして、何日か頑張っていると、不思議と光が見えてきます。

私の場合、そもそもiPhoneアプリを作りたいと思ったのも、TreasureBoxのようなアプリを作りたいと考えたからです。でも、いきなり作るのは難しそうだったので、まずは一つ練習をということで、3ヶ月かけてMailNowを作り、それから3ヶ月間MailNowの改善をしながらTreasureBoxの具体的な構想を立て、その後6ヶ月程度かけてTresureBoxの開発をしました。日曜プログラマーなので、こんなに長い時間かかりましたが、学生の方とかならこの半分の時間でいけると思います。

自分はとても飽きっぽくて怠け者のの人間なのですが、自分のアイディアに興奮して世の中に本気で出してみたい!と思ったのと(興奮しているのは自分だけですがw)と、アプリを作るために新しいことを学んでいく過程がとても楽しかったです!

さてさて、思ったより長文になってしまいました。

最後になりましたが、プログラミング初心者の僕のハマリポイントで幾度も助けてくれた、のんちゃんOgaogaに深くお礼して、このエントリーを締めたいと思います。

このブログが誰か一人でも多くの方をインスパイアして、プログラミング仲間が増えることを願ってます。

Mobile Analytics

© 2024 プロダクト道

Theme by Anders NorénUp ↑