ku-sukeのブログ

Just another hatena blog

新規機能要望をトリアージする10の質問

 どうも。プロダクトオーナーを普段やってるのですが、業務の何割かを占める、改善といいますか、エンハンスメントについて書きたいと思います。

前提として私のプロダクトはB2B2Cで、とある施設に導入いただき、そこのスタッフの方と一般のユーザーがアプリを利用してやり取りをするようなゆるめの業務システムです。エンジニア10名程度の小さめチームで、ゲーム・エンタメや基幹システムとは少し違うと思います。また、日々の改善なので新規企画とも違います。

○○機能を××してほしいです。

お客様や現場担当者からこのような要望を日々よくいただきます。その要望の中からチームのリソースを用いて最良の投資対効果を出すのがぼくの仕事なのですが、ご要望を頂いてチームに落とすまでプロダクトオーナーとして自ら行っている質問を言語化してみたいと思います。

■Clarify(クラリファイ・明確化・深掘り)

1.なんでそれがほしいと思ったの?

→たいていの場合、チームに寄せられる要望はすでに実現手段まで考えていただいていることが多いです。

例)「アプリのグローバルメニューに、AA機能を追加してください。

しかしながら、多くの場合で実現手段を考えるのはその道で食ってきてる我々のほうがよく知っているはずです。なので、実現手段を思いついた「理由」を深掘りするようにしましょう。

→「なぜAA機能を追加したいの?」→「よく使うからです」→「え、なんでその機能を頻繁に使ってるんですか」→「うちはXXだから、AA機能でZZしてるんです」→「いやーそれ確かにそういう使い方もできますけど、それだったらBB機能にCC用意したほうが嬉しかったりします?」→「たしかに!そのほうが最高ですね」みたいな事がよくあります。

背景にある課題や行動は、利用者のほうがプロであることも多いので、そこは利用者の行動を尊重しつつ、解決手段は作りてのプロが考えるというわけです。

■Volume(ボリューム・量・頻度)

次に、要望の真意がわかったら、同じような要望を持っている人がどの程度いるか考えます。ここはあくまで仮説ベースになりますが、ごくごく一部のユーザーのために全体の改善が滞ったりするとあまり良くないので(ときには必要ですが)量や頻度を見極めます。投資対効果の効果の量です。

2.それを希望している人はどれくらいいるの?

→まずその機能を使っているユーザの人数や割合をみます。できればデータで見ましょう。ヒアリングベースだと人間の肌感は意外とあてにならないことが多いからです。Analyticsなどで該当機能のPVをみたりデータベースの件数をとったりします。

→そして、その上で当該機能に要望を持っているユーザが何割くらいいるかを、こちらはヒアリングベースでアタリをつけます。

3.その行動をする頻度はどれくらい?

→1日3回使う機能が10%良くなる方が、1年に1回しか使わない機能が200%良くなるよりも嬉しいものです。また逆に、高頻度なものは下記の副作用にも慎重になる必要があります。

■Return(リターン・目標到達・効果)

投資対効果のうち効果の「質・方向性」です。

4.それを満たすことで我々の目指す世界に近づく?

→プロジェクトのビジョンや存在意義があるはずです。我々はXXを通して○○を支援し、ZZな社会を実現します!みたいなやつです。それと照らし合わせて方向性がずれていないかを考えます。

あまりいい例えが見つかりませんが、暗算力を向上するという存在意義があるのに、計算ドリルに電卓機能をつけてくれという要望は方向性がずれているといえるでしょう。

5.それを満たすことでビジネス成果が出る?

→リソースは有限なので、安定して長期に渡りこのプロジェクトが運営できるだけのビジネス成果を出す必要があります。それは会員登録数だったり、売上だったり。直接ではなくても「ユーザー満足度が高まることで解約数が減る」などとビジネス成果にどうつながるかは意識しましょう。

■Method(メソッド・手段)

では、やったほうが良さそうだ。となったらどう実現するかを考えます。ここはエンジニアさんに相談したりします。投資対効果の「投資」を最小化する方法を考えます。なんでもかんでも死ぬほど残業して解決するのはスマートではありません。

6.システム開発でしか解決できない?

→顧客がほしいのは1/4インチの穴が開けられるドリルではなく、1/4インチの穴である。というのは名言ですが、意外とマニュアルを整備するとか、シールを貼るとかQuick Fixのほうが実用性が高い場合があります。

7.どのような実装方法が考えられる?

→松竹梅で考えます。毎日使う機能であれば松案、あまり使わない機能だったり、ほしいと思っている割合がそこまで高くない改善なら梅案など使い分けます。

■Quality(クオリティ・品質)

作る方法がざっくり決まったら、念のため再検証します。本当にそれで良いんだっけ?と一度振り返りを行いましょう。UIUXデザイナーさんやマーケ担当にも場合によっては確認します。

8.改修したことによる副作用はない?

→そこに機能追加することで、初心者が迷うのでは?学習しなければいけないことが増えるのでは?構造が変わることによってマーケの計測値がブレるのでは?「出来ること」が増えることにより「やらなければいけないこと」が増えてしまうのではないか?保守性が下がって今後の開発がスローダウンするのではないか?

→さらに、あちらを立てればこちらが立たず、という改修もあると思います。だからといって管理画面で好きな方法を選べるようにしようなどと安易に逃げると、管理画面でお好みの設定を選ばないと使いづらい玄人向けシステムになってしまいます。

9.それは「あたり前品質」を満たしていない?

→ここまでで投資対効果が見えてきました。しかしながら投資対効果が低くても加点した方がいいものに「当たり前品質」を満たしているかがあります。ユーザーさんの期待値によって異なるのですが、これを満たしていないものは計測しにくいダメージをプロジェクトに与えていることが多いので、納得の行くロジックが思い浮かばなくても経験上加点するようにしています。

→たとえば0.1%のユーザーに致命的ではないエラー画面が出てしまう。投資対効果でいうとあまり高くないので、本来は「1年以内に直します」が妥当だったとしたら、加点して「3ヶ月以内に直します」に格上げすると言った具合です。

qiita.com

■そして最後に

10.今までの話を総合して、投資対効果の度合いは他の課題と比べてどう?

ここまででだいたい投資対効果が見えてくるので、今までに積み上がっている作業タスクとくらべて優先度付がなされ、チームに落とされます。

 

(ボーナス!)11.とは言えたまにはウェットな判断も

個人的には、チームメンバーとの関係性とか日本的なウェットさも好きなのでたまに判断を捻じ曲げます。

もってくる営業さんの熱意に負けて要望をえこひいきしたり、この要望をやるのはこのエンジニアで、彼の現在の興味とも合致するから優先度あげちゃっていいやといった、やりすぎると良くないけど適度(10%以下くらい)にそういう「余裕」も入れたいなと。

だって、あくまで仮説だしどこまでいっても完璧な判断はないから、チームが楽しく働けるほうが総合的にいい仕事できる気がするんよね。

ブコメなどでツッコミお待ちしております。

エンジニアキャリアのためのアーキテクチャ選定権という報酬

こちらの2記事を読んだのと、社内でエンジニアに一定の時間なにかに打ち込む時間を提供するという案について先週議論したので、常々考えている報酬(あるいは福利厚生)としてのアーキテクチャ選定権というものについて書きます。

 

blog.yuku-t.com

paiza.hatenablog.com

なお、paizaさんのベース記事による「ITエンジニア」は非常にスコープの広いエンジニアを対象としていると思われますが、私が対象にしているのは大手SIerなどではないWebエンジニアです。

学び続けないと死ぬんだけど、学ぶの大変すぎ問題

Webエンジニアは技術のトレンドの移り変わりや進化が早く、また雇用も他職種に比較すると流動的なので、学び続けないとキャリアが頭打ちになりやすいわけですが、年々難しくなっています。

範囲広すぎ!

ほんの10年前は、Webサイトを構築するプログラミング環境といえば、Perl / PHP / JSP / ASP そしてRailsの芽が出始めた頃でした。jQueryもまだ世の中に無く、フロントエンドエンジニアという職種はありませんでした。

ところが、いまエンジニア向け求人サイトをみてみるとこういう状態なわけです。

f:id:ku-suke:20160830225701p:plain

(例:CodeIQ JOBS https://codeiq.jp/jobs/ の検索画面)

言語だけでなく、インフラエンジニアであっても同様です。前佛さんのスライドをいつも引用させていただくのですが、このような状況です。

f:id:ku-suke:20160830230256p:plain

SlideshareRe: ゼロから始める監視設計

「インフラを学びたい」といっても、AWSなのかGCPなのかオンプレなのかで学ぶ内容の優先度が異なりますし、それぞれ奥が深いわけです。

語弊を恐れずカンタンに言うと、300種類くらいの技術要素のどれが流行るか(雇用やキャリアアップに直結するか)わからない中から、自分の限られた時間をどれとどれに投入するべきなのか超悩むのです。

特にフロント界隈は、コレが定番というのがなかなか現れずに地獄と化していますね。

フロントエンドでみた、情報系ブログとはてブの地獄メカニズム - エモくありたい

高度すぎて個人で学べない・コストかかりすぎる

学ぶべき対象が広すぎて悩む問題を乗り越え、これをまじめに取り組もうと進んできた時にぶつかる壁が難易度の高い学習は個人でやりにくいという点です。

本当に必要とされる人材というのは1番目の id:yuku_t 氏のエントリにある通り、「あの人はプロフェッショナルだ」と呼ばれる人だと思うのですが、たとえばWeb言語(golangとか新しいものを想定して)において以下の様な知見は個人の机上の開発では身につきにくいでしょう。

  • 10人以上のエンジニアで作るときに保守性を保つには?
  • サーバを分散した時のベストプラクティスは?
  • いまのX年メンテしたPHPのコードをリプレースするほどの価値がある?

インフラでも同様です。企業レベルのAWS操作スキルを身につけようと各種製品をいじっていたら、あっという間に月額数万円かかってしまう可能性があります。(無料枠も初年度だけだし、毎年新機能出るし)

そこで企業によるスキルアップの支援を求めるようになる

ここまでのおさらい

  • 学んだほうが良さそうな技術要素が世の中にあふれている
  • 全く無駄にならないとはいえ、できるだけ雇用やキャリアに直結するものを選定したほうがコストパフォーマンスが良い。
  • プロフェッショナルと呼ばれるレベルの知見を個人の机上で獲得するのは難易度が高い

そのような状況で、ミドルクラス以上のエンジニアは、自分が伸ばしたい技術要素を採用している企業に転職したりするわけです。

企業サイドとしては、出来るエンジニアに抜けてもらっては困るので、転職しなくてもうちでそのキャリアアップできますよ。という点が補強できればより定着してくれるのではないでしょうか。

(※もちろん、転職時には技術キャリア以外の要素も多分にあると思いますが)

 

そこで、報酬、あるいは福利厚生としてのアーキテクチャ選定権です。一定以上のレベルのエンジニアが「おれはgoが来ると思うからgoで書きたいんだ」「Erlangだ」「React.jsを実戦投入するんだ」という希望を自社のプロダクトで満たしてあげる。それはなにも大きいものでなくても、社内向けツールでもいいわけです。

やりかたは20%ルールみたいなものでも、本当にプロダクトでやってみるのも良いのですが、エンジニアの「時間」と「サーバ代などお小遣いの範囲では厳しいコスト」を会社としてサポートしてあげることは、組織として検討してもよいのではないでしょうか。

 

「検討して」というのは、やはり個の要望の数だけ聞いていると、メンテする人がいない、プロダクトや事業として本来のゴールを満たすスピードや質が低くなる、などのデメリットが出てくるためです。

なので、その技術要素をやりたい人を募る投票制にしたりテーマ制にしたりして、個人のキャリアも伸ばしつつ組織の知見としても活かせる方向の解決が良いと思います。

 

もっと小さな組織の場合は、「この人!」という人を一本釣りするためにチーム側をすべて合わせていくという属人性MAXなハイリスク採用戦略としても使えると思います。

NewRingとかジギョつくみたいな新規事業コンテストの運営課題

Facebookに書こうと思ったけど長くなったのでブログで。

今日は、RecruitVenturesにてNewRingという新規事業企画のメンターをやって来ました。事業企画を持ってきた人に対して壁打ちみたいに詰めてアドバイスしたり質問して気づきを得ましょうってやつを3組ほどさせていただいてたのです。

あと、その前に社内でエンジニアがこういう新規事業企画系に応募したくなるにはどうすればいいかみたいな課題について何人かで話をしたりもあって以前から思ってたところを整理してみようと思います。

企業が求める新規事業案のレベル感合わない問題

CAのジギョつくのころから感じてたけど、募集する側からすると応募の質を上げて欲しいんだけど、かといってハードル上げすぎると参加が減ってしまうからポテンシャルがある人の芽も潰したくなくて敷居を下げちゃう。(どんな案でもOK!)

なんだけど、敷居を下げ過ぎると、なにそれなんにも深堀りしてない、ジャストアイデアやんけ!みたいなのが増えてきて運営コストばかり増えて最終事業化する案って結局少ないよねってなる。

特に上場企業なんかだと「事業サイズ」の問題があって、イノベーションのジレンマほどではないんだけど、年商3000億円の企業からすると、年商2000万円くらい、めっちゃ頑張って5年で年商3億くらいにしかならないビジネスって、ぶっちゃけいらないわけです。

とはいえ、経営経験もない人がいきなり10億100億のビジネス考えれるかっていう問題と、たとえば100億規模でホラ吹きにならない程度に説得力のある事業企画書作るスキルって、ハードル高いし普段の仕事もある中で業務負荷高いよねって思うのです。

解決策は座学と素振りではないか

自分は今BBT大学院で卒業をかけて(危ういけど)2年次の講義を受けてて、その大半が新規事業系の講義なわけです。それをやってみると、やっぱり最低限のところはクリアしたうえでの議論ができる気がしてるんです。

座学である程度「新規事業を作るとは」っていう理論やケーススタディで、開始地点のボトムアップを図ってから、「後は本人の情熱でいってまえ!」っていうのが最適解なのではないかとおもい始めてます。

かつ、いきなり甲子園みたいなところに「皆さんの熱い応募お待ちしてますね!」っていっても良くないので、マッシュアップアワードが全国キャラバンやってるみたいな、事前にピッチイベントとかやって素振りさせるのが良いと思うんですよね。

一般的な(誰でも参加できる)コンテストと異なり、社内のものは社員しか参加していないので、広報をしっかりしてネットワーキングを充実させれば確度も上がってくるんじゃないかなと。

そもそも企業における新規事業コンテスト的な奴の位置づけは

2つあると思ってて、ひとつはもちろん新規事業やっていかないとゆるやかに死んでいくから新規事業を公募形式でやってきたいってのもあるんだけど、どちらかと言うと事業責任者をまかせられるポテンシャルがある人間を発掘することもウェイトとしては大きいんじゃないかなって思います。後は企画やりたい欲を満たすとかも一応。

だからといって勢いだけでロジックのないやつを引っ張りあげちゃうと周囲のヘイト値が貯まることにもなりかねないので、「情熱・知識・経験」のうち経験が少なくても知識ですこしは補ってあげればより質の高い事業企画コンテストになるのではないかなって思います。

とはいえ、運営コストに専任で人間を何人も貼り付けるっていうコスト投下もいきなりは難しいので、教材の整備とかを進めるのはどうでしょうかね。でもそこまで絶対新規事業やりたいっていう情熱がないとその教材も読まれないのですが・・

 

※固有名詞を出しましたが個人の見解です。

事業サイドがAMPに乗っかるか考える事

AMP、Googleさんが猛プッシュしてますねー。個人的にも表示が早いので、たとえばFBのInstantArticleが好きなのですが、このような軽量版記事がGoogleの検索結果にもAPMによって普及するのは歓迎です。

おさらい、AMPってなに?

Accelerated Mobile Pagesの略で、高速化モバイルページという直訳になるのですが、通常のHTMLページとは別に、APM用のお作法に従ったページを作ることでGoogle検索エンジンが検知して、検索結果の上部にプレビュー表示される可能性があるというものです。Twitterでのリンククリック時もAMP対応がなされる模様です。

AMPはGoogleだけが開発しているのではなく、上述のTwitterほか著名なパブリッシャーも参加を表明しています。このブログもはてなブログProなので対応しています。(さっきオンにしたので反映はもうちょっとかかる)

参加企業:

Accelerated Mobile Pages Project

なんでAMP対応する必要があるの?

ユーザーのため:低速かつ混雑しやすいモバイル回線でも、さくさく表示されて快適なページをユーザが閲覧できることでハッピーになる。

ビジネスのため:そのためユーザはあなたのブランドに良い印象をもったり、そもそも表示が遅すぎて離脱することが減る。それだけでなく、GoogleがAMPを優遇し検索結果にAMP用の場所を上部に確保するとアナウンスしている。絶対クリックされるでしょ。

AMP対応版を作るデメリットは?

1. 基本的には、メインのページと別管理になるので、PC用画面、スマホ用画面、AMP用画面の3つを構築・保守し続ける必要が有ること。

2. 制約があるので、AMPの仕様書(日本語化されています)みながら、対応タグだけを用いてページを作る必要がある。いくつかのブログパーツや広告、解析タグは諦めないといけない。

3. 仕様がどんどん追加されるので、まだしばらくはキャッチアップが必要そうなこと。(でも基本機能はでそろったので、Google対応の恩恵はすでに受けられる)

4. 検索順位が上がるわけではない。Googleさんもランキングシグナルには使わないと言ってます。

AMPを作るべき業種やシステム

業種では、ニュースなどのメディアは100%恩恵がありますので絶対やるべきでしょう。

なお、通常のメディアであればGoogleニュース登録も行いましょう。ソーシャル系ならAMPもそうですがFBのInstantArticle対応を検討しましょう。

ブログなどのCMSプラットフォームも対応するとよいですね。はてなや、アメブロはすでに対応を始めています。Wordpressプラグインがあります。

EC系では、DB系とよばれる、大量の商品を扱うベンダーが対応すると良いでしょう。AMPをメンテする以上、ある程度ページ記述内容をシンプルに切り落として、自動生成しないとメリットでないと思うので、いわゆる詳細ページが1000商品以上あるようなECサイトはやると良いでしょう。

注意点としては、AMPで商品を見せる、カートに追加するくらいまでは構築できたとしても、そこからログインして購入するというフローはAMP対応難しいんじゃないかなと思うので、そこでのカート落ちを防ぐ仕組みは考慮したほうが良いと思います。

システムの実装方式

PC/スマホ切り替えであればUserAgentなどで切り替えることが出来るのですが、AMPはそのような「閲覧デバイス」による切り替えではないので、パラメータやURLベースでテンプレートの切り替えとなることが多いでしょう。

ざっくりとしたイメージで言うと

https://example.com/hoge/article/123456.html がある場合、このページにAMPへのリンクをmetaタグで貼ります。

<link rel="amphtml" href="https://example.com/hoge/article/amp_123456.html" >

URLはなんでも良いのですが、別URLになります。あるいは内部的にはこんな感じかも

 <link rel="amphtml" href="https://example.com/hoge/article.php?id=123456&mode=amp" >

これで、CMSなりシステムにAMP用のHTMLを返せよーということが伝わるので、システムがAMP用のHTMLを生成します。

そのHTMLは、これに準拠したものになっています。

Accelerated Mobile Pages Project(日本語ドキュメント)

AMP実装後の運用について

AMPを実装し、本番公開したら、アクセス解析を注視します。検索結果からのトラフィックの一部が、通常ページにいかずにAMPページに飛ぶからです。非対応の広告や解析ツールでは、単純にインプレッションが減りますので、事前に報告者に対して共有しておく必要があるでしょう。

また、システムが老朽・複雑化などして、とりあえず別ドメインや別サーバで運用する場合は、読後の画面遷移時にパラメータをつけたり、同一サイトと認識されるようなアクセス解析の設定を構築する必要がありそうです。

前職のCAでも、AMPはビジネス的にも悪く無いと位置づけているので、みなさんぜひAMPやりましょう

ameblo.jp

 

DellのInspiron 11 3000(Pentiumモデル)を購入しました

 おくさまのパソコン、LenovoのIdeapadを未だに使い続けてたんだけど、さすがにWindows 10にしたら厳しくなったので買い換えることにした。条件は以下のとおり

  • デカすぎないこと(13インチ以下)
  • 高すぎないこと(ほぼネット見るだけなので5万程度で)
  • HDDでないストレージ64GB以上であること(LenovoですらSSD換装した)
  • メモリ4GB以上、できれば換装可

このへんでしぼると、DellマウスコンピューターAcerくらいしか残りませんでした。また、いくつかタブレットを使った経験では、eMMCだとディスクI/Oがちょっと厳しい印象でしたので、SSDにしぼるとAcerも消え、Dellかマウスの2択になります。

kakaku.comで比較するとこんな感じ

価格.com -ノートパソコンの比較表(Inspiron 11 3000シリーズ 価格.com限定 エントリー・プラス Pentium N3700・128GB SSD搭載モデル、LuvBook LB-C242B-S2-KK 価格.com 8GBメモリ/240GB SSD/11.6型HD液晶搭載モデル)

 

メモリ8GBには惹かれたのですが、kakaku.comの人気1位であることと、子供もいる環境ではあまり丁寧な扱いでないことから、なんとなくの印象でDellが頑丈そうということで決めました。

届いてみての換装

まずはフォトギャラリー。白か赤かを聞いたら一瞬で赤と帰ってきました。結構良いです。

f:id:ku-suke:20160731225739j:plain

f:id:ku-suke:20160731225757j:plain

f:id:ku-suke:20160731225826j:plain

なかなかよいです。

画面はノングレアの1366x768で狭めですが、Windows10はいわゆるRetina Displayへの対応がほとんどと言っていいほど徹底できていないので、このような低解像度端末のほうが快適だったりします。あと3年ほどしたらデベロッパー側も対応が進むと思うのですが。

タッチパッドはMacからするとゴミレベルですが、IdeaPadと比べると良くなっている気もします。

入出力にUSB-Cがないので、USB-PDも使えなさそうですが、そもそも旅先に持ち歩くことも少ないので問題無いでしょう。

処理速度としては快適です。Chromeで20タブくらい開いてもマシン全体が引っ張られるようなことはありませんでした。CPU・メモリ・ストレージI/Oのバランスが良いのでしょう。

また、Dellに決めた理由として、メモリとディスクの換装が頑張れば出来る点です。3年後も頑張れば、eBayなどで新品バッテリーも入手できる可能性がありますし、グローバル機種の恩恵にあずかることができそうです。(ググったらサービスマニュアルのpdfもありました)

価格.com - 『メモリ・SSD換装しました』 Dell Inspiron 11 3000シリーズ 価格.com限定 エントリー・プラス Pentium N3700・128GB SSD搭載モデル のクチコミ掲示板

 

というわけで、コンパクトで5万円以下でネットくらいの利用で、コスパ・技術力があれば長年活用できる機種としては非常におすすめの機種です。

機械学習とかディープラーニングやって見たメモ

 顔認識まわりで機械学習とかディープラーニングのライブラリを触ってみたので、実務者向けにメモを残す。

 

多くの場合ディープラーニングは不要

だいたい、バズワードだからディープラーニングでAI使いたいみたいなのは、基本的にはプレスリリース打って人々の注目をあつめるためだけに利用すればよくって、概ね旧来からある機械学習でも問題ないことが多いです。これがたどり着いた結論。

 

そもそも、ディープラーニングの問題点として、なんで正しい答えを出してるかが人間みたいに説明できないので、予想もしないような学習結果をだすことがある。

memo.sugyan.com

まさかノイズ画像をアイドル顔だと認識するとは思わなかった。ということがあるので、突飛な結果を出してしまうと困る分野には使いづらいです。

それだったら、ディープじゃないラーニング(機械学習)でも便利なライブラリはたくさんあるので、やってみると良いです。

実務者が使いそうな用途はだいたい研究されとる

とはいえ、ディープラーニングのほうがすごいんでしょ?いい結果出るんでしょ?というのはあってるけど間違ってる。

ディープラーニングのすごいところは、例えば上述の顔認識ならば、画像を放り込むだけで学習し、結果を返してくれるのがすごい。

ディープラーニング以前はどうしていたかというと、

  • 顔検知ライブラリで目と鼻の位置をまず抽出し
  • 目と鼻の座標の組み合わせを機械学習ライブラリに学習させる

という流れでやってました。これのデメリットは「人間の顔を識別させるのは、眼と鼻の座標を使うのが良さそう」ということを知ってないと機械学習がうまくいかない点です。

しかしながら、実務者がまず取り入れたい分野であれば、だいたいはもう理論が研究され尽くしているので、ディープにラーニングしなくてもその用途に応じたものさしを人間が与えることで十分実用的な精度が出るのです。

さらには、分野にもよりますがディープラーニングのようにGPUをぶん回して大量の学習をさせなくても、少量の学習からでも比較的すぐに学習結果がうまく利用できるみたいです。

いままで判断できなかったところに使う

じゃあディープラーニングのいいところってなんだろうというと、いままでどのパラメータが、答えを決定する要素なのかがわからなかった分野。だと思います。少し調べた雑感ですが。

なので、既存の機械学習で精度が低かったもの(かつ、大量のサンプルが用意できるもの)は、ディープラーニング化の恩恵を請けられそうというわけです。

 

以上、専門家から見たら違うかもしれませんが、事業企画とかでとりあえず「AI」って言いたい場合にはうまくご活用ください。いまはバズワードなので、なんでもかんでも人工知能って言っておけばすごいねって言ってくれると思います。が、裏では最小コストで即時にパフォーマンスが出る方法を利用すると良いでしょう。

安く早くなるからプロトタイプを作ろう #アプリマーケ本

[New] Kindle版が出ました!フォーマット一覧から、「リフロー版」を選んでお買い求めください。

スマートフォンアプリマーケティング 現場の教科書」を解説したり書ききれなかったことをブログで書いてみるシリーズ第3弾。プロトタイプについて。

プロトタイピングの章の細かい手法については、共著者の荻野さんに譲るとして、発注者視点でのプロトタイプの意義について。

初期プロトタイプは実現したい人(発注者)が作るとメリットだらけ

アプリ開発においては、もはやプロトタイプはなくてはならないほどに浸透したと思ってるんだけど、まだまだ制作サイド以外には認知が薄いと思うので、今日はそのメリットについて書こうと思います。

ちなみに、プロトタイピングと言っても最初は紙に各画面の四角を書いて、線を引っ張るだけのペーパープロトタイピングがおすすめです。

プロトタイプを作るとモヤッとしたアイデアがクリアになる

「なんかfacebookみたいに簡単に仲間とコミュニケーションできたら良いのに」と思いついたとします。そこで紙に必要な画面を書いてみると、以下の様な考えに至ります。

  • えっと、まず、自分の友だちを招待できて
  • そのメンバーで画像とか動画とか投稿したり
  • ファイル共有したり、そこにいいねできたりして

このようなことを考えながら紙に起こしていくと、なんとなくイメージが湧いてきます。facebookの画面と見比べながら、「既読数っていらないよな・・」とか「仲間内だから他人の画像とかに書き込みたい」とか、実際の画面イメージを考えながら、紙を書いては捨てながら本当に自分がほしい物を思い浮かべることが出来るようになります。

f:id:ku-suke:20160704235930p:plain

(書籍より。ここまでキレイにかけなくても、最初は書きなぐってOK)


または、「いろいろ考えた結果、やっぱfacebookでいいや」と思い至ることもまた重要な事です。頭のなかだけで考えていると、ふわっとしたイメージが、紙に書きながら考えるだけでなんともリアルに浮かび上がってくるのがプロトタイプの効果です。

プロトタイプで早く安く開発委託できる

今日一番言いたいのはこっちです。プロトタイプを書くことで、ヘタすると100万円以上見積もりが安くなります。だいたい制作会社をやっていて、危険な顧客のパターンは以下のとおりです。

  1. とにかく期限が短い(時間や契約の管理が雑なリスク)
  2. 全てに上役の承認が必要(担当者がOKでもあとで反故にされるリスク)
  3. とりあえず思いついたアイデアを投げてくる(軸が定まってない)

他にもありますが、1はほんとうに危険なので製作者の皆さんは逃げましょうとしか言えないのですが、2,3は、発注前の相談時点から完成までの間に変更がある(=余分な時間と作業が発生する)リスクがあるため、制作会社も見積もりにバッファを載せて対応します。だいたいこんな感じです。

f:id:ku-suke:20160705001250p:plain

どちらも開発費が300万円だとしても、社内でプロトタイピングまで済んでいると、劇的な変更はかからないだろうと安心できるので、オレンジの「事前に聞いていた要件と違った場合の保険」を低く抑えられます。

さらに、そのプロトタイピングを上長も承認している場合は、グレーの「リリース直前で偉い人がちゃぶ台返しする保険」も低く抑えることができ、結果的に納期の予測も正確になり(3ヶ月vs3ヶ月+バッファ2ヶ月)その分工程管理費も低減されます。

これで、発注側は30%ほどの安値で発注することができ、かつ受注側も健康的な制作環境が整うため、おたがいの余剰リソースを、アプリをより良くするために割くことができるようになるのです。

 

また、事前にプロトタイピングを用意しておくと、発注先業者のスキルを見極めるのにも有効です。どこにどの程度掛かりそうという「ヨミ」の鋭さはその業者の実力と言っても過言ではありませんし、素人である発注者が作ったプロトタイプを見て、足りない部分やイケてない部分を提案できる会社とご一緒できると良いと思います。

 

ちなみに内製開発の場合は?

そろそろプロトタイプ無しでアプリ開発をしている組織はないと思うので、もしそのような場合は、パソコンを即刻閉じて紙に書くようにしましょう。デザイナーさんがいる場合は、Sketch→Prottという流れが比較的ラクにできますので、ディレクターが簡単なワイヤーフレームを書いたら、デザイナーさんに依頼して作ってもらい、社内レビューすると良いでしょう。あとでZeplinにも書き出せるし!

 

スマートフォンアプリマーケティング 現場の教科書

スマートフォンアプリマーケティング 現場の教科書