create-nuxt-appのエラー解消
初めてcreate-nuxt-app
してみたけどいろいろエラーがでた・・・。
初めてだったからいろいろ盛ってみた。
エラー1
error eslint@5.16.0: The engine "node" is incompatible with this module. Expected version "^6.14.0 || ^8.10.0 || >=9.10.0".
どうやらnodeのversionが古く怒られたのでnodeのversionをあげて解決。
エラー2
DeprecationWarning: Tapable.plugin is deprecated. Use new API on .hooks instead
ぐぐるといろいろ出てくる。
どうやらNuxtのPWA Moduleが原因っぽい。
いろいろ調べたら下記Issueを発見。
Versionを上げれば治るらしいので試す。
自分のところだと"@nuxtjs/pwa": "^2.6.0",
だったので、"@nuxtjs/pwa": "^v3.0.0-beta.16",
に変更して、yarn instal
(5分くらいかかった)。
無事解決
エラー3
12:11 error Replace `⏎··········href="https://nuxtjs.org/"⏎··········target="_blank"⏎·········` with `·href="https://nuxtjs.org/"·target="_blank"`
今度はESLintに怒られる。
どうやらindex.vueのaタグの書き方悪いらしい。
<template> <div class="container"> <div> <logo /> <h1 class="title"> nuxt-sample </h1> <h2 class="subtitle"> My wonderful Nuxt.js project </h2> <div class="links"> <a href="https://nuxtjs.org/" target="_blank" class="button--green" > Documentation </a> <a href="https://github.com/nuxt/nuxt.js" target="_blank" class="button--grey" > GitHub </a> </div> </div> </div> </template>
1 error and 0 warnings potentially fixable with the `--fix` option.
と言われるのでyarn lint --fix
を叩く。
<template> <div class="container"> <div> <logo /> <h1 class="title"> nuxt-sample </h1> <h2 class="subtitle"> My wonderful Nuxt.js project </h2> <div class="links"> <a href="https://nuxtjs.org/" target="_blank" class="button--green"> Documentation </a> <a href="https://github.com/nuxt/nuxt.js" target="_blank" class="button--grey" > GitHub </a> </div> </div> </div> </template>
Documentation
のaタグだけ治って、GitHub
のaタグは治っていないんだけど、とりあえずこれで全エラーは解消された。
余談
ビルド中が可愛い
RUNNING LEAN
RUNNING LEANを読んだので備忘録として残す。
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)
- 作者: アッシュ・マウリャ,渡辺千賀,エリック・リース,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/12/21
- メディア: 単行本(ソフトカバー)
- 購入: 3人 クリック: 14回
- この商品を含むブログ (19件) を見る
著者はAsh Maurya。
そもそもこの本はブログに顧客開発やリーンスタートアップについて書いていたのをまとめた書籍。
リーンスタートアップの実践的な手法のガイドという立ち位置。
なお、THE LEAN SERISというエリック・リースがキューレーターを務める企画?の1冊目。
イントロダクション
- 製品の構築コストは下がったが、スタートアップが成功する確率は上がっていない
- スタートアップの多くは失敗している
- 成功したスタートアップの2/3は当初のプランを途中で大幅に変更している
- 当初のプランが優れていたのではなく、リソースを使い切る前にうまくいくプランを見つけた
- Running Leanはリソースを使い切る前に、プランAからうまくいくプランへと反復的に移行するプロセス
- 顧客の要求を収集後、リリースまで顧客から離れる
- この離れている期間が問題
- 車を作る際に顧客に要望を聞いていたら「速い馬が欲しい」と答えていただろう
- つまり、顧客から本当に欲しいものを聞き出すのは難しい
Running Leanとは
- 速度・学習・集中
- 顧客の行動を計測して、ビジョンをテストする
- 製品開発サイクルを通じて、顧客と関係を築く
- 短いイテレーションで製品と市場の検証を同時に行う
- 規律のある厳格なプロセス
- 数々の方法論や思想家を参考にしている
顧客開発
- スティーブ・ブランクが作った
- 製品開発サイクルにあわせて、顧客との継続的なFBループを構築する
リーンスタートアップ
- エリック・リースが提案
- 顧客開発とアジャイルソフトウェア開発とリーン手法を統合したもの
- リーンは無駄を省くという意味
- 単位時間あたりの顧客に関する学習量の最大化が目的
ブートストラッピング
- ビジョイ・ゴスワミが提唱
- 顧客からの収益で資金をまかなうという意味
メタ原則
- 原則は何をするか導く
- 戦術はどうするか示す
プランAを文章化する
- 強いビジョンと実現するプランAがあるが、ビジョンは信念で裏付けされている
- ビジョンを事実で裏付けする必要がある(ビジョンはテストされていないので
- 最初にすることはビジョンを書き出して、誰かと共有をする
- 1枚にすべてが収まるリーンキャンバスがおすすめ
- 数時間で書ききることができる
- 短い文章で書く必要があるので、本質が抽出できる
- 1ページなので共有も楽
- ソリューションの面積は1/9しかない
- 起業家はソリューションに目を向けがちだが、顧客はソリューションには興味がない
- 最高のソリューションを作るのではなく、ビジネスモデルの全体を把握しまとめることが大事
- ビジネスモデル自体を製品と扱う
- リーンキャンバスとはビジネスモデルを9つの部品に分解し、各項目をテストするもの
プランで最もリスクの高い部品を見つける
- ソリューションは基本的に最もリスクの高いものではない(製品はなんとか作ることができる
- 最も大きいリスクは「誰も欲しくないものを作る」こと
- 「課題・解決フィット」→「製品・市場フィット」→「拡大」
課題・解決フィット
- 解決に値する課題はあるか?
- それは顧客が必要としているか?
- 顧客は金を払うか?誰が金を払うのか?
- 解決可能か?
製品・市場フィット
- 必要とされるものを構築したか?
- MVPがどれだけ解決しているかテストする
拡大
- どうやって成長を加速させるのか?
ピボットと最適化
- 「課題・解決フィット」、「製品・市場フィット」と「拡大」で分ける
- ピボットとは学習し方向性を変更すること
- 最適化はプランを加速すること
- 最も学習できる状態は50%の状態
- そのため大胆な成果を狙って学習をするべき(小さいテストは後で
プランを体系的にテストする
Running Leanの実例
- この書籍を書いたときの例
いかにして書籍を執筆反復したか
- 何人かに本を書いてと言われたが無視していた
- たくさん言われ始めたので本を書くことを考えた
- 読者に電話をして、どうして本を書いほしいか聞いた
- 本書のUVP(独自の価値提案)を理解する
- 顧客開発・リーンスタートアップの実践に苦労している人が多い(課題)
- ブログを段階的なガイドとして読んでいる(ソリューション)
- webの製品を開発している(アーリーアダプター)
- 目次と書名と書影のサイトを構築
- 本のリスクの高いところは目次
- 顧客に目次を聞いてFBもらって、目次を改良した
- しかし顧客が10人くらいなので、ブログで告知した(解決に値する課題ではなかった)
- 1000個のメアドが集まったので、先に進むことを決めた
- ブログのコピペをしようとしたが満足できるものにはならなかった
- 目次をもとにワークショップを3回行い、中身を改良していった
- 2週間ごとに2章ずつPDFでリリースする方式をとった
- 半分は好きな端末で読みたがっていた
- しかし、半分(アーリーアダプター)は同意した
- 2週間ごとにリリースし、FBをもらい、推敲して誤字を修正していった
- 実際に1000人くらいに売れてから、出版社からお金をもらい、出版した
リーンキャンバスの作成
見込み客を考える
- 最初はぼんやりとしたアイデアしかない
- この時点で製品を作ったり、ビジネスモデルを決めるのは危険
- 複数のモデルを同時にテストしていく
- 顧客はお金を払うが、ユーザーはお金を払わない
- 顧客のセグメントを細かく分ける
- 最初は一枚のリーンキャンバスを書く
- その後に顧客セグメントごとにリーンキャンバスを書く
リーンキャンバスをスケッチする
- 一気にスケッチする(15分以内くらい)
- 正しいことを書こうと議論するより、適当に書くか、空欄にする
- リスクが高いことがわかる
- 短く書く
- 現在の分かる範囲で書く
- リーンキャンバスの書き方は顧客主導型で
- ターゲットとなる顧客セグメントに対して、課題を1~3位まで書く
- もしくは、顧客に必要なジョブ(作業)の観点から課題を考える
- 代替品を列挙する(オンラインコラボツールの代替品はEメール)
- ユーザーを特定する
- UVPを決める
- ソリューションはゆるく書く
- 課題とソリューションの統合はできるだけ遅らせる
- チャネル(顧客への経路)
- 収益の流れは最初から考える
- 学習時は大勢の顧客はいらない
- 課金のシステムを考えているなら最初から実装して課金させるべき
- 価格は製品の一部(似たような水でも高いほうが品質が良いと感じてしまう)
- 価格が顧客を決める
- 課金は難しい行為だが、早めに検証ができる
- コスト構造をリストにする
- 主要指標はAARRRで見る
- 獲得(Acquisition)は何も知らない訪問者が、見込み客になった時点を表す
- 花屋なら店に入ること
- ウェブサイトは登録ページを見た訪問者と定義(サイト次第
- アクティベーション(Activation)は見込み客が満足の行くユーザー体験をした時点を表す
- 花屋なら入った後店がしょぼかったら駄目
- ウェブサイトは使ってみて期待(UVP)と製品を結びつける
- 定着(Retention)は製品の反復利用
- 花屋ならまた来る、サイトならまた来る
- 収益(Revenue) は課金イベント
- 花の購入やウェブなら製品の申し込み
- 紹介(Referral)は口コミとか
- 圧倒的優位性は最も難しい
- 機能数とかは関係ない
- 先行性もあまり関係ない
- コピーする価値あるものはコピーされる
- 本当に優位性のあるものはコピーされずらい
- 内部情報、専門家の支持、ドリームチーム、信頼性、巨大なネットワーク、コミュニテイ、既存顧客、SEO
ビジネスモデルの優位性
- リスクの優先順位を間違えるのは最も無駄
リスクとは
- 不確実は複数の結果が存在する状態
- リスクは好ましくない状態になりえる不確実な状態
- 機会費用と実質費用の両面から数値化し、優先順位をつける
- 本の場合は価格がリスクではない
- 良い本を書けば買われないリスクは下がる
- なのでリスクは顧客が欲しい良い本が書けるか否か
- 製品リスク:正しい製品を作る
- 顧客リスク:顧客への経路を作る
- 市場リスク:実現可能なビジネスを作る
- 計測や定量化は確率統計的手法を利用
- インタビューなど定性的計測はダグラスハバードがおすすめ
ビジネスモデルの比較
- 十分に大きな市場を持ち、製品の周りにビジネスを構築でき、必要とする顧客に近づけるビジネスモデルを見つけるのが目的
- 顧客の不満レベル(課題)
- 顧客セグメントに優先順位をつける
- 近づきやすさ(チャネル)
- 価格と粗利益(収益の流れとコスト)
- 市場規模(顧客セグメント)
- 技術的実現可能性(ソリューション)
- いろいろな顧客セグメントごとにリーンキャンバスを書いて、どの顧客セグメントから検証するか決める
- 決定したら誰かに見てもらう(アドバイスを鵜呑みにしてはいけない
- リーンキャンバスを見てもらおう
- 2割説明して残りは聞き出すのに時間を使う
- 最もリスクが高いと思われるのはどこか?
- 似たようなリスクを克服したことはありますか?
- リスクをどうやってテストしますか?
- 他に話を聞いたほうがいい人はいますか?
実験の準備
課題チームと解決チームを作る
- 部署をぶち抜く
- 課題チームはユーザーインタビューやユーザビリティテストなど
- 解決チームは開発・テスト・リリース
- メンバーが重なっても良い
- 1つのチームで両方の役割を担っても良い
- 顧客とのやり取りは全員の責任
- 小規模でなく最小でチームを作る
- コミュニケーションが楽でコストが低い
- 課題と解決のバランスが大事
- 開発・デザイン・マーケの3つがチーム作りで必要
- 基本外部委託しないほうがいい
効果的な実験
- 最適な実験をするには、速度・学習・集中が必要
- 速度と集中しかないと高速に学びのないところをぐるぐる回るだけになる
- 学習と集中しかないと速度がないのでリソースを使い切ってしまう
- 速度と学習しかないと早すぎる最適化をしてしまう(製品がないのにLPを最適化したり
- 実験するときは1つの指標と目標にする
- 反証可能な仮説にする(間違いがはっきりわかる文)
- あいまいな仮説「専門家になってアーリーアダプターを集める」
- 反証可能な仮説「ブログに投稿して100人集める」
- 最初は強いシグナルを受け取る(5人の顧客のインタビューで十分)
- 肯定的な意見は仮説を定量的データで検証してもいいということ(定性的から定量的へ)
- 計測結果を具体的で反復可能な行動に結びつけて製品を変更するのは難しい
- インタビューはパターンが見えるまで同じ方法を繰り返す
- 定量的検証はコホート分析やスプリットテストなどを使う
- わかりやすいダッシュボードを作る
- コンバージョンダッシュボードとリーンキャンバスなどを1つのダッシュボードで管理する
イテレーションのメタパターンをリスクに適用する
- 中途半端な学習や否定的な学習でやる気を無くす
- 肯定的な学習から楽観的になってしまう
- 正しい製品かつ拡張性のあるビジネスモデルを作るのが大事
- 学習自体を目的に実験せず、目標のための実験にしていく必要がある
- 単位時間あたりの学習量(どのリスクが高いか)を最大化する
- 課題を理解→ソリューションを決定→定性的に検証→定量的に検証
- 製品リスク:正しい製品を作る
- 解決に値する課題かどうか確認する
- MVPを決める
- MVPを構築し、小規模に検証する(UVPのデモ)
- 大規模に検証をする
- 顧客リスク:顧客への経路を作る
- 不満を持っている人を特定する
- 製品を今すぐ欲しいと思うアーリーアダプターに範囲を狭める
- アウトバウンドチャネル等から始める
- インバウンドチャネルの構築
- 市場リスク:実現可能なビジネスを作る
- 既存の代替品から価格を設定する
- 顧客の声を聞いて価格をテストする(口約束)
- 顧客の行動を聞いて価格をテストする
- コスト構造を最適化する
顧客インタビューへの準備
学習するには顧客と話すこと。
アンケート調査もフォーカスグループも不要
- アンケートは正しい質問があることが前提
- 正しい質問を作るのは難しい
- 顧客インタビューとは何がわからないのさえわからないことの探求
- アンケートは正しい答えがあることが前提
- 正しい答えの選択肢を用意するのが必要
- 最初は「自由回答形式」の質問を使って学習する
- アンケートはボディランゲージが見えない
- フォーカスグループは「集団思考」を形成してしまうのが問題
- アンケート調査は顧客インタビューから学習したことを検証するのに効果的
- 統計的有意性の実証に使う
人と会話するのは難しい
- ピッチではなく学習を中心に考える
- ピッチの問題点は顧客が「正しい」製品の知識を持っている前提になっていること
- 「正しい」ソリューションの前に、「正しい」課題を理解する必要がある
- 顧客に何が欲しいか効かず、行動を観察する
- 嘘つくかもしれないし、儀礼的に答えることもあるので、インタビュー中に行動から言葉を検証する
- 口約束ではなく行動を示す(課金など
- 台本に合わせて会話をする
- 広く網を広げて局所化を防ぐ
- サンプルを厳選するのではなく、結果から厳選をする
- インタビューは直接会うこと
- いきなり知らない人でなく、知り合いから始める
- 誰かと一緒に行って、第三者目線を取り入れる
- コーヒーショップなど中立的な場所でやる
- 謝礼などはしない(お金を払う客を見つけるのが目的なので)
- 録音をすると自意識過剰になったりするので、録音は基本無しで
- インタビュー後すぐに文章化をする
- 4~6週間で30~60人インタビューをする
- スケジュール調整は無駄な作業なので委託しよう
見込み客を探す
- 知人バイアスがかかるが、誰とも話さないよりはいいので知人から
- 紹介による顧客探し
- 親近感は大切なので地元で探す
- 予告ページでメアドを登録してもらう
先制攻撃と反論
- 顧客インタビューに対する反対意見
- 顧客は自分の課題を把握していない
- 数10人と話しても統計的に有意がない
- 定量的指標で十分
- 自分が顧客だから、誰かと話す必要はない
- 友達が良いねと言っている
- 週末でなにか作れるのに、インタビューする必要はあるのか
- すでに課題を把握しているからテストは不要
- 課題がわからないのでテストができない
- 誰かにアイデアを盗まれる
課題インタビュー
学習すべきこと
- 製品リスク:何を解決するのか?
- 市場リスク:競合は誰なのか?
- 顧客リスク:誰が困っているのか?
課題のテスト
- 最初は課題に対する顧客の反応を計測すること
- 現時点で解決できているか?どのように解決しているのか?
反証可能な仮説
- 反証可能な仮説 = 具体的で反復可能な行動 → 期待する計測可能な成果
課題インタビューの実施
- 歓迎、顧客情報の収集、ストーリーの伝達、課題の優先順位、顧客の世界観の探求、まとめ、結果の文章化
- 歓迎:インタビューの流れを簡単に説明する
- 顧客情報の収集:アーリーアダプターを選定するために、顧客情報に関する基本的な質問をする
- ストーリーの伝達:上位の課題をストーリーで説明する
- 課題の優先順位:課題を1 ~ 3つ選んで、見込み客に優先順位をつけてもらう
- 顧客の世界観の探求:インタビューの中心
- まとめ:引き続き興味を抱いてもらえるようなフックを提供と今後の協力のお願い
- 結果の文章化:記憶が新しいうちに文章化する
課題を理解していますか?
- 結果を週次でレビューする
- アーリーアダプターから始める
- 最も賛同してくれる顧客セグメントを特定する
- 課題を洗練する
- 必要ないというシグナルを受け取ったら削除して、絶対に必要と受け取ったら追加する
- 既存の代替品を理解する
- アーリーアダプターは既存の代替品と比較する
- 顧客が使う言葉に注目する
- UVPの鍵となる単語は顧客の言葉に耳を傾ける
- 最低10人にインタビューをして下記が可能になれば終了してもよい
- アーリーアダプターとなる顧客が特定できた
- 「絶対に必要」な課題が見つかった
- 現在の顧客の解決方法がわかった
ソリューションインタビュー
- 製品を作る前にデモを使ってソリューションのテストをする
学習すべきこと
- 顧客リスク:誰が困っているのか?
- 製品リスク:課題をどのように解決するのか?
- 市場リスク:どのような価格モデルにするのか?
ソリューションのテスト
- デモは実現可能でなければいけない
- デモを最終的な製品で使用しない技術を使って作ってはいけない
- デモは本物に見えないといけない
- デモは高速に反復する必要がある
- インタビューの結果をすぐデモに反映して、次のインタビューでテストできるようにする
- デモは無駄を最小化する
- デモは本物に見えるデータを使う
- デモはYotutubeとかに出しても良い
価格のテスト
- 価格のことは顧客に聞かず、ただ伝えるだけ
- 適正な価格は説得することができる
- 価格は顧客セグメントを定義するもの
- 登録の障壁を下げずに上げる
- 希少性:どっちつかずな100社より、やる気のある10社に注力をする
- アンカリング:価格は相対的だが、新しいカテゴリの製品は別の製品と比較して安く見せる
- ソリューションインタビューのAIDA
- 認知(Attention):効果的に認知を集めるためには、顧客の課題を突きつける
- 興味(Interest):デモを使って興味を引く
- 欲求(Desire):欲求は段階的に引上げる
- 行動(Action):製品に対する口約束・書面の契約・前払い金をとりつける
- ピッチは「オール・オア・ナッシング」の提案
- フレーミングは仮説を使って顧客の反応を引き出す
ソリューションインタビューの実施
- 既存の見込み客にお願いする
- 課題インタビューのときに今後の協力を依頼しておく
- 新規の見込み客を入れる
- 歓迎、顧客情報の収集、ストーリーの伝達、デモ、価格の検証、まとめ、結果の文章化
解決に値する課題はあったか
- 機能を追加・削除する
- 抵抗がなければ価格を上げる
- ソリューションインタビューは以下の革新が持てたら終了
- アーリーアダプターの顧客情報が特定できた
- 「絶対に必要」な課題がわかった
- 課題を解決するのに必要な最小限の機能が定義できた
- 顧客が支払ってくれる価格がわかった
- (概算で)うまくいきそうなビジネスがわかった
バージョン1.0をリリース
製品開発は学習の邪魔
- 開発やQAは学習できていない
- リリースまでのサイクルを短くして学習を加速させる
MVPの縮小化
- MVPのスコープを減らすということは、製品メッセージを希釈する不純物を取り除く
- 白紙から始める:機能を追加するたびに正当性を検討する
- 最上位の課題から着手する
- 「あれば嬉しい」「必要ない」機能は削除する
- 初日から課金するようにする(ただし、徴収は30日後)
- 最適化ではなく学習に集中をする
- 継続的デプロイ
アクティベーションの流れを定義する
- 顧客がサービスに登録をしてから最初の体験に満足するまでの道筋
- 顧客に速くUVPを体験してもらうこと
- 登録の障壁を下げても学習を犠牲にしてはいけない
- 手順を減らしても学習を犠牲にしてはいけない
マーケティング用のサイトを構築する
- 売るのを目的とする
- 最初の8秒が大切
- 概要ページで「会社」から製品を購入する理由を作る
- 利用規約プライバシーポリシー
- 製品ツアーページ(スクショなど
計測の準備
- 顧客ライフサイクルは可視化するだけでなく、計測できる必要がある
行動につながる指標
- 製品/市場フィット前の目的は、CVの最適化ではない
- 顧客ライフサイクルにおけるホットスポットの特定と、その解決
- インタビューなどでは、顧客の声に耳を傾けたが、これからは顧客の行動を計測する
- 行動につながる指標 = 観測結果を具体的で反復可能な行動につなげるもの
- DL数やPVは製品の現状を表すが、単体では次に何をすればいいかわからない
- これらは、計測対象ではなく、計測方法
指標は人が重要
- 評価尺度の実態は人である
- 数字の裏にいる人に話しかける必要がある
- 理想的なCVダッシュボードは、分析とカスタマーリレーションシップマネジメント(CRM)を併せ持つ
- 指標はそれ単体では何も説明しない
- 指標はどこが間違っているか教えるが、なぜ間違っているかは教えてくれない
- ユーザーの方からやってくることはない
- ユーザーはソリューションを丁寧に見てはいない
- うまくいかないことがあれば、すぐ不信感を抱いて、興味を失う
- すべての指標は等価ではない
- 多くのユーザーやBOTが来るので、指標を異なるバケツに分ける必要がある
単純なファンネルレポートは十分ではない
- ファンネルレポートはLPのCVのようなミクロレベルに適している
- 6月の、獲得、アクティベーション、収益のCVファンネルレポートがある場合
- 収益は5月の数値になるので、歪みが出る
- 7月の登録数が減ると、CVRがあがるかもしれない
- 新機能のリリースなどと結びつけるのが難しい
- いずれのファンネル分割が発生する
コホート
MVPインタビュー
- MVPの販売の前にアーリーアダプターに直接販売をして、デザインや価格などを改良する
学習すべきこと
- アーリーアダプターに20分インタビューで説得できないのであれば、LPに来た訪問者を8秒で説得できない
- 製品リスク:製品の魅力はなにか?(独自の価値提案)
- 顧客リスク:十分な顧客はいるか?
- 価格は適正か?
MVPインタビューの実施
- 歓迎、LPの提示、価格ページの提示、登録とアクティベーション、まとめ、結果の文章化
顧客ライフサイクルの検証
フィードバックを楽にする
- 顧客から学習する近道は、顧客に話しかけること
- 気にかけていることが伝わる
- 問い合わせが多すぎるという問題はない
- テクニカルサポートは継続的な学習のフィードバックループ
- テクニカルサポートは顧客開発
- テクニカルサポートはマーケティング
- 投票ツールによるフィードバックは使わない
試用期間中に問題を解決する
- 試用期間は顧客ライフサイクルを制限できる
- 試用期間の最初の目的は離脱を減らす、次に定着やエンゲージメント、課金
獲得とアクティベーション
- 優先事項:学習できるだけのトラフィックを稼ぐ
- ファンネルを掘り下げる
- どこかで離脱をしていないか?パターンを探す
- 離脱したユーザーをリストで持っておき、分析をする
- よきせずエラーをキャッチして通知させる
定着
- 優先事項:試用期間中にユーザーに戻ってきてもらって、使ってもらう
- 丁寧なリマインダーを送信する(メールなど)
- インタビュー相手に協力を求める
収益
- 優先事項:課金
- 決済システム
- 支払った顧客に電話をする
- (売りそこねた)見込み客に話を聞きに行く
紹介
- 優先事項:推薦の声をもらう
ローンチの準備
- 結果を頻繁にレビューする
- 最も重要な課題から着手する
- 可能な限り小さなことをやる
- 確実に改善する
- コンバージョンダッシュボードを監視する
ローンチ条件
- アーリーアダプターの80%がコンバージョンファンネルをうまく抜けたらOK
機能の押し売りをやめよう
機能は押し付けず引っ張ってもらう
- 追加機能は独自の価値提案(UVP)を薄める
- すぐにMVPに見切りをつけてはいけない
80/20ルールを実施する
- 80%既存機能の計測と改良
- 20%新機能の開発
機能の流れを抑制する
- かんばんで管理する
- バックログ
- MMF(市場価値最小限の機能:Minimum Marketable Feature)とバグを区別する
- 作業中
- 作業中のタスクの数を制限するのが大切
- 完了
- ほんとうの意味での完了は、顧客の検証により学習ができること
機能要求を処理する
- Getting Things Done方式のワークフロー
- 正しい行動で、適切な時期か?
- 小さな機能、またはバグか?
- 緊急か?
機能ライフサイクル
製品/市場フィットの計測
製品/市場フィットとは
- 市場を満足できる製品がある状態
ショーン・エリスのテスト
- 製品が使えなくなったときにどう思うか?
- 非常に残念、少し残念、残念でない、使っていない
- 40%が非常に残念と答えたならよい
- アンケートは学習より、検証に効果的
- 統計的有意性を得るためにはサンプル数が膨大である
「適切な」マクロ指標に集中する
- 一度きりのサービスはサービスの体験が重要
- アクティベーションの指標で計測できる
- SaaSのような何度も使うサービスも体験が重要
- 本当の成功は繰り返しの利用
- 人が欲しがるものを作る指標は、定着である
- アクティベーションの済んだユーザーの40%が定着すれば、トラクションがあると言える
収益について
- 価格は製品の一部
- ただし、収益は検証の1つの形にすぎない
- 収益は最初の検証だが、定着は究極的な検証
人が欲しがるものを作ったか
- コンバージョンダッシュボードを毎週レビューする
- 目標とバックログの優先順位をつける
- 大胆な仮説を作る
- 機能を追加・削除する
- 価値指標を監視する
- ショーン・エリスのテストを実施する
- 40%のユーザーが定着・ショーン・エリスのテストを通過したら初期は終了
製品/市場フィットにおける市場
- 解約率、ウィルス係数、顧客獲得コスト、顧客生涯価値などがビジネスモデルを拡大させる要因
- 初期のトラクションを実証する前に、ビジネスの拡大をするのは無駄
- 3つの成長のエンジン
- 粘着型:高い定着率
- ウィルス型:高い紹介率
- 支出型:高い利益率
- 価値指標の検証から着手する
- 顧客の製品に対する態度を理解する
- 調整するエンジンを選択する
ネットワーク効果のある製品
- 製品の数はユーザーの数
- 定着は王様
- 成長させる前に検証
マルチサイド製品
- 売り手がいないと買い手がいなく、買い手がいないと売りてはいない
- 両サイドのキャンパスを作る
- ミクロ単位で仮説検証をする
- 仲介処理の自動化は後
結論
拡大
- 製品/市場フィットの達成が最初のマイルストーン
- 重点が学習から、拡大になる
- 成功の指標を使って進捗を計測し、成功の確率をあげる
低燃費スタートアップの作り方
- ブートストラッピングは外部資本なしに企業を設立する(正しい行動を適切な時期に)
早すぎる資金調達は無駄なのか
- 資金調達は検証ではない
- 検証がなければ大きくできない
- 投資家は進捗を別の方法で計測する
- 資金調達は思っているよりも時間がかかる
- お金を持つとダメになる
- アドバイスや人脈は?
- 製品/市場フィットまでどうやって生き残ればいいか
- 本業は続ける
- バーンレートを節約しよう
- 初日から課金しよう
- 関連する商品を売ろう
リーンスタートアップにおけるフローの達成方法
- リーンスタートアップの基本原理は、無駄の削除
- 建物の外の活動は創業者が参加する
- 建物の中の活動も参加する
- 2つのスケジュールの綱引き問題が発生する
- 綱引きの均衡点を見つけるときに、フローという概念が約立つ
- 絶好調な精神状態を表す:フロー状態
- 明確な目的がある
- 高度な集中力を必要とする
- 中断や妨げるものがない
- 明確で即時的なFBがある
- やりがいがあって挑戦できる
毎日のフローを作る
- 予定しているクリエイターの活動
- 予定しているマネージャーの活動
- 予定していない活動
- クリエイターの仕事は中断されない時間を作る
- クリエイターの目標は早い時間に達成する
- マネージャーの仕事は遅い時間に設定する
週単位のフローを作る
- 顧客開発に最適な曜日を見つける(火〜木)
- 顧客の休止時間にクリエイターの仕事を入れる(月、金)
ソフトウェアの無駄を排除する
- 製品は顧客にプルしてもらう
- 顧客が要求するまでは製品を作らない
- 80%は既存機能の最適化に費やす
SaaS製品の価格設定
- スタートアップの最初の目標は、最適化ではなく学習
- 最初は「無料のお試しプラン」だけを用意する
- 最初は料金プランは1つ
- コストを考慮に入れる
フリーミアム
- 無料で提供し、顧客獲得後付加価値サービスをつける
- コンバージョンが低い
- 価格設定は売り手ではなく、買い手の気持ちが決める
- 検証サイクルに時間がかかる
- 間違った指標に集中してしまう
- 無料ユーザーは無料ではない
- フリーミアムの有償部分から始める
- 優れた無料プランは、無料体験版のようでなければいけない
予告ページの作り方
- 興味のない訪問者に興味のある見込み客になってもらう
- 大きな約束をする(UVP)
- 即効性のある明確な見出し = 顧客が望む結果 + 明確な期限 + それが達成されなかったときの代替案
- 顧客に結びつけて考える(課題)
- 関心と欲求を生じさせる(ソリューション)
Ginza.js #1 で登壇してきた #ginzajs
Meguro.es, Gotanda.js, Roppoingi.jsに続き、Ginza.js!
ご当地JSシリーズ的な感じになってきた
Ginza.js
# 目指す価値 - 主にJavaScript関連技術について、様々な人から多様なトピックに関する発表や議論が生まれるようにする - そのために、開催頻度を高く維持し、なるべく多くの人に発表機会を提供する - そのために、なるべくイベント形式をシンプルにして、開催コストを最小限にする # シンプルさを保つために、なるべくやらないこと - 参加費を取ったり、お金を管理したりすること - 飲食物をまとめて発注し提供すること - 会場提供以外のスポンサーを募ること
目指す価値、シンプルさを保つための方針を明示的に書いてあるのいいなと思った
会場は株式会社プレイド。
芝生があってお洒落味が強かった
芝生すご#ginzajs pic.twitter.com/bEyqpiAhUa
— Taguchi Wataru (@tiwu_official) 2019年5月22日
LT後に、登壇者を囲んで座談会をするという形式。
今回は前職の知り合いも来ていて、一緒に聞いていた。
LT
LTはVue.jsとFirebaseでサイト作成、チャートライブラリ、StoryBook、LineBot、Vue Pulgin等々
僕はweb componentsの話を。
私定時で帰りますの種田コスプレしてきましたと言ったらウケたので大満足のLTでした
Web Componentsの盛り上がりを感じたい
Gotanda.js #11 in MobileFactory で登壇してきた #gotandajs
1年ぶりに帰ってきたGotanda.jsで登壇してきました。(僕は初参加)
人生初の五反田駅。
Gotanda.js
会場はモバイルファクトリー
ありがとうモバイルファクトリー!#gotandajs
— Taguchi Wataru (@tiwu_official) 2019年5月10日
乾杯してビール飲みながらスタート。
LTはトップバッターでした。
Meguro.esとかでは勢いに任せた資料でしたが、今回はWeb Componentsの基本的なところや、最新のブラウザ関連の情報を載せました。
そのためギリギリの7分でした。
詰め込み過ぎたらスライド飛ばしたりしてギリギリ7分だった#gotandajs
— Taguchi Wataru (@tiwu_official) 2019年5月10日
グーグルスライドにコードを埋め込むときのいい方法を知りたい。
LT
他のLTはNode.jsの再起検索やGatsby.jsやdockerでnodeの開発の話やAWS CDKの話など割とサーバーサイド?よりの話が多かったかなと感じます。
全然知らない話が多くて、AWSの設定?をJS(TS)で書けるあたり、もう何でもありだなJS・・・とか思う
懇親会
休憩中にピザは消滅
ピザった🍕#gotandajs
— Taguchi Wataru (@tiwu_official) May 10, 2019
懇親会以前にピザの気配が消えた #gotandajs
— 猫鳩柔工業 (@nekobato) May 10, 2019
最後に
勉強会を継続して開催するのはかなり大変なんだろうな・・・
PWA Night vol.4 ~PWAのミライや活用方法をみんなで考えよう~ 参加してきた #pwanight
PWA好きなのでvol.4も参加してきました。
vol.3はCache APIについて登壇してきました。詳しくはこちら。
PWA Night vol.4 ~PWAのミライや活用方法をみんなで考えよう~
会場は株式会社ウルフさんでした。広くてお洒落・・・!
来ました #pwanight pic.twitter.com/aNKYAc3FAO
— Taguchi Wataru (@tiwu_official) May 15, 2019
株式会社ウフル自体は今回はじめて知った。どうやらIoTの会社らしい
デモではGUIでIoTの開発をしていた。
昔アルディーノとか触った記憶が蘇ってきたw
こえのブログのPWAについて
Frontrend × Bonfire Frontend でも聞いた原さんのLT。
以下メモ
- こえのブログ!
- PWAのキャッシュ周り?
- PWAのロゴって自由に加工していいのかw
- ライトハウス高し
- PWA = UX
- サーバーサイドキャッシュ
- 物理的距離・ネットワーク状況
- 安定させるためにCDN
- CDNのキャッシュヒット率を高める
- できる限りキャッシュ -TimeToLiveはかなり長くしている
- サロゲートキー
- イベント駆動パージ
- デプロイをキーにサロゲートキー使ってキャッシュをパージする
- エッジコンピューティング
- CDNでできるなら処理をCDNでする
- workbox使っている
- PRPLパターン
- index.html
- SWを動かしキャッシュに貯める
- UIパーツ
- web components
- lit-element
- ボタンはshadow domに隠す
- button自体の拡張はしない -ライブラリ不要で軽い
- 下書きはIndexedDBへ
- オフラインでもレコーディングできる
- オンラインか否かを検知できるofflineイベントも有る
- iOS12.2で外部ドメインいけるようになった
- cssカスタムプロパティ
- NetworkInformation APIで回線速度を取得
- intersection observer
- web share api
- clipboard api
- vibrate API
- web workerでwasm
- 画像はブラウザで圧縮
share、vibrate, clipboardなどよりアプリになれるAPIがあって驚いた
やっていこう。PWA
@oliver_diary
以下メモ
- PWA2015年スタート
- downasaur(オフラインのときに出てくる恐竜)
- Fast, Integrated, Reliable, Engaging
- Androidは対応状況いい感じ
- iOSは残るはpush
- Twitterログインできないからmanifest.jsonを取り除く
- 通知の許可の設計
- 初見の通知はほぼ許可しない
- 一度拒否したサイトを通知させるのもかなりつらい
- 通知の前に独自モーダルとかを挟むケースが多い
- OneSignal(pushできるサービス
- PWABuilder(マイクロソフトが出している支援ツール
- web share target api v2 ファイルも共有できる
- shape detection api 顔検出・バーコード検出・テキスト検出
- BadgeAPI バッジだせる
- Wake lock API 操作していないとき画面のロックを防ぐ(動画とか?
- native file system api ローカルのファイルをいじれる
- serial api マイクロコントローラとかと通信できる
- Web HID ゲームパッドとか触れる
- Contacts Picker 連絡先にアクセスできる
- Font Access API
知らないAPIが多い。。。
業務システムでこそPWA
@goofmint
以下メモ
- 運営の一人
- PWAは徐々に対応ができる
- 最近いろんな許可を求めるダイアログが増えた(ダイアログヘル
- 確認系のダイアログはキャンセルしがち
- 旅行先で低快速のときにjQuery読めず詰んだ
- 実際のSIerとかはアプリ化とか・・・うん・・・関係ないよね となりがち
- iPad登場移行、タブレットの業務アプリが増えた
- Cordovaが盛り上がる
- オフラインでも動くが、OSアップデートに追われたり、審査があったり
- そこでPWA
- 業務アプリは利用者が限定的
- 長期間保守するからweb標準技術のPWAは適している
- webauthのハードウェアトークン
PWACompatを本番導入してみた話
gatchan0807
- PWACompat
- iOS用のA2HSを自動挿入するライブラリ
- GitHub - GoogleChromeLabs/pwacompat: PWACompat to bring Web App Manifest to older browsers
PWA作って満足していないか?という話
iret_oyamatsu
- PWAの保守
- どうやって運用をしていくか?
- 体験向上のウォッチ
- 効果測定の話
- matchMedia display-mode standaloneでmodeのチェックができる
- しかしデスクトップIEもマッチする?!?!?!?
- PWAディベロップメントエージェンシーに登録しよう
PWAManager
kindback
- one signal
- プッシュのサービス
- 無料でもまあいける
- 社内用にPWA系のソースを自動を生成するサービス作ってみた
- がしかしバグっている
- onesignalの無料だから使いすぎると死ぬ
懇親会
🍺🍕 #pwanight pic.twitter.com/sJMIWJgJ7v
— Taguchi Wataru (@tiwu_official) May 15, 2019
vol.5
LTで喋ろうと思います〜〜〜〜
次回も楽しみです
Inside Frontend行ってきた #insideFE
先週土曜日にInside Frontend行ってきたのでレポート。
Inside Frontend
CyberとYahooの共同主催のフロントエンドのイベント。
国内だとHTML5 Conferenceに次ぐくらいの大きさかな??
会場はAbema Towers。
行く途中で中本でラーメン食べたから、イベント中腹壊したらどうしようと思っていたが杞憂で終わってよかった・・・
TypeScript: Why and how we adopted it at Slack
- SlackをTypeScriptで作り直した話
- Reactも導入しているっぽい
- 2017年4月ごろっぽい
- JSはVanila JSで書くのが好きで、ライブラリとか入れない予定だったけどTSで書いたらTS最高だった
- Battle Field 1のUIはReactとTSで作っているらしい
- 他にもNvidia,Adobe,Skype,Visual Studio InstallerとかもJS(Electronっぽい)
- C++で書かれたnode.jsモジュールがある
- JSDoc書いていたけどメンテされないし、Objectで渡ってきたら中身わからないし・・・
- そこでTS、TS書いても既存のJS破壊しない(JSにコンパイルされるから)
- エディターがTSを強力にサポートしている
- JSは実行するまでエラーに気づけない(コンパイラを求めていた
- Coffeeは使ったことない
- TSは実行せずともエディターがエラーを出してくれる
- 最初は.jsを.tsにかえるだけでOK
- デモでJSをTSにして、コンパイルしたJSを見せる
- コンパイル後のJSが美しくて読みやすいのも魅力
- 少しずつTSに移行していった
- TS書いていたらVanila JSが汚く見えてきた
- TSで型が定義されるのでメソッドのサジェストが助かった
- koa使うときほとんどドキュメント見なかった
- 当時TSLintにはお世話になった
- 今はESLintのほうがいい
- 想定より早く移行が終わった
そもそもSlackってElectronで作られているのが初耳だった
TS最高だぞという話。結構エディターのサポートが強力という話が多かった気がする。
Introduction to Lucet
- LucetというFastlyが開発したWebAssemblyのコンパイラであり実行環境
- https://github.com/fastly/lucet
- C,C++,Rust,TSを対応
- TSはAssemblyScriptというコンパイラが存在する
- WASI(WebAssembly System Interface)
- wasmをlucetかましてx86-64
- parser->verifier->tranlater->cranalift->codegen->artifact ->runtime
- コンパイラはめちゃくちゃ複雑でCをRustに書き換えた
- Terrarium
- エッジコンピューティングをFastlyは提供をし続けたい
- 安全に提供するためにLucetを作った
- 強い熱量で2年で作った
前提のwasmの知識がなくかなり難しかった
途中からコンパイルの仕組みとかの話でかなり難しかった・・・
Nuxt.jsで中規模サービスを統合した話
www.slideshare.net
- 無料まんが・試し読みが豊富!eBookJapan|まんが(漫画)・電子書籍をお得に買うなら、無料で読むならeBookJapan
- フロントはYahoo
- バックはEBJI
- Yahooのデザイナーはマークアップまでできる
- Vue.js,Nuxt.js,Node.js,Express
- 他社で分担しているので風土が違う
- Yahooは属人化をさけるが制約が多い
- EBJIはスピードが速く自由度が高いが属人化しがち
- そこでスクラムを導入し吸収した
- 1週間スプリント
- 部署や役割ごちゃ混ぜでAとBチームを作った
- Atomic Designを導入
- デザイナーがHTML,CSSをエンジニアにわたす
- エンジニアはAtomicデザイン通りのVueファイルを作る
- エンジニアとデザイナーで溝ができた(アトミックデザインの共有とか)
- デザイナーはAtomic Designの共有を受けていなかった
- 最初からデザイナーに共有をしてデザイナーがAtmoic Design通りにVueファイルを作る流れのほうが良かった
- 大は小をかねるので大量の項目を返すAPIを作っていた
- でかすぎるのでmixinで絞る処理を書いた
- Vueファイル以外で使ってバグった
- 直列でAPI叩いていたからタイムアウトしていた
- 目に見えるものをスクラムで作りまくっていたので目に見えない処理とかが後手後手だった
- 比較的若いエンジニアが多かった
- 名古屋チーム(一人)を作った
- スクラムは機能追加
- 名古屋チームは、スクラムに入らずFEのサポート、レビュー、相談、パフォーマンス改善
- FEエンジニアで会話する場を作る
- 新しいこと、実装時の課題を拾う(スクラムで拾えないのを拾う
- 直列でAPIを呼んでいたところをリファクタリング
- APIを小さくした
- webpack bundle analyzerでJSを削る
- 7MBくらいあった
- 名古屋チームもスクラムに混ぜた
- 7割機能追加、3割改善
- Q APIのドキュメント方法
- A エクセル、swaggerなどAPIによって違う(辛い
- GrapshQLは検討中
- NuxtにしたのはSSRしたいのとwebpackメンテが嫌だった
- 1週間スプリントは実装の割合が減るが、仕様等がコロコロ変わるので1週間スプリントにした
- 機能開発はJIRAで管理、改善系はGitHubで管理
- スクリュードライバーというCIでデプロイ
- UnitTestは書いてあるが、e2eはない
- 2つのチームは同じPO
Nuxt.jsがメインと言うよりは、チーム作りや開発体制などの話がメインだった。
違う会社を同じスクラムに混ぜて開発するのめっちゃ大変だったんだろうなという印象。
いちからデザインシステムを作ってみて学んだこと
- Yahooの広告配信管理ツールのデザインシステムを作った話
- 20社以上1000人が関わる
- それぞれ独自に作るのでばらばらになってしまう
- デザイナー4人で開発
- スタイルガイド
- 原則定義
- 色とかの定義
- モーションの定義
- デザインキット、コンポーネントライブラリ
- コンポーネントを洗い出して名前をつけた
- 名前付けは時間がかかった
- Card?Panel?Plate?
- シンプルが故に難しい
- サービス特有の謎パーツも難しい
- 見た目ではなく機能・役割を考えて言葉を選ぶ
- 全員が納得するまで議論
- Sketch使ってAbstract?でレビュー
- 全員の承認が必要
- エンジニアがレビューに入っていたから実装目線でも会話ができてよかった
- ホバー
- エラー
- 入力量
- HTML,CSS,JSスニペット提供(BEM記法
- Fractal(スタイルガイドジェネレーター
- 作ったはいいがReactのコンポーネントで提供してほしいと言われた
- npmで提供できるようにした
- TSは有識者いなかったが導入した
- Storybook
- sassの型解決できずなやんだ(typings-for-css-modules-loaderで解決
- スタイルガイドはGatsbyで作って、自動的に同期して更新漏れが発生しないようにした
作ったあとにReactコンポーネントで書き直すのはなかなかつらみがあるな・・・
Web Componentsもこんな感じで配布したい
BFFのDeveloper Experience
- Backends For Frontend
- 全然詳しくない
- BFFはUXのためにある
- Micro ServiceとUXをつなぐ
- MSはドメイン注力、シンプルなAPI、サービスごとに技術最適
- API Aggregation(node.js/koa)
- SSR(React, Redux)
- バックエンドはドメインごとの開発に注力
- フロントはUI要求をAPI化
- フロントの仕事が増えている・・・
- そこでBFFをサクサク開発する必要がある
- APIのインターフェイスの合意をバックエンドとフロントエンドで取る必要がある
- Interface Definition Language e.g. Swagger
- Thriftを採用
- 並行開発をよりよくする
- モックデータを作る
- Cross cutting concern(関心ごとの分離
- マイクロサービスのモックデータは横断として考える
- インターセプターする
- Aspect Oriented Programming
- Dev用の画面もBFFで作る(デバッグにつかう
- フロント複雑になっているからエンジニアリングで解決していこうな
BFFは単語だけ知っていたので興味本位で聞いていた
手を動かしてみないと実際のところはわからないが・・・
フロントエンドの仕事が増えてきたのは同意
node.jsの存在がフロントエンドの垣根を壊しているイメージ
Loading Performanceとの向き合い方
- 日経電子版は7月に2度目のリニューアルをする
- LightHouse100点だけどユーザーの状況によっては低くなる(速度制限とか
- 広告のスクリプトが速度低下の原因
- 簡単に導入でき、確実に表示され、正確に計測ができるが
- document.write...
- 自由度がない
- 外せないので最適化をする
- minifyされたコードを読みデバッガーで頑張る
- スクリプトを読み込む処理を探し、スクリプトをダウンロード、呼び出しを潰して、連結してminifyしFastlyで配信
- onScrollも上書きしてintersectoin obseverにする
- UIの表示以外はWebWorkerに任せる
- comlinkを利用
- どこかで失敗したら従来どおりの読み込みをする
- 最適化もレベルを分けて実施して、効果を図る
- handlebarsからJSX
- vanila jsはそのまま
- 通常のSSRサイトなのでReactとかいらなかった
- Web Components使う
- 泥臭いの作業は業務後にやっている
- Edge,IE11はスルー
- lit-elementは使わない
- なお、リニューアルは天の声が・・・
広告最適化の泥臭さやばい
広告のJSはドキュメントがほしいと言っていた
それにしてもリニューアルでWebComponents使うの楽しそう・・・
懇親会
寿司!ビール!ピザ!
終わり
node.jsが存在するおかげで、フロントエンドもサーバーサイド書くっしょみたいな風潮がより強くなってきた気がする
個人的にはWeb Componentsが好きだからデザインシステムとかもWeb Componetsとかどうだろうとか思いながら聞いていた
実はCall For Proposalで2つほど申し込んだけど残念ながら、落選していた(・∀・)
次回こそ・・・
Frontrend × Bonfire Frontend 参加してきた #frontrend_bonfire
Frontrend × Bonfire Frontend 参加してきました
FrontrendもBonfire Frontend参加したことなかったけど、名前だけ知っていた(うっすら)
Frontrend × Bonfire Frontend
会場は何かと話題のAbema Towers
なう#frontrend_bonfire pic.twitter.com/SBEPltvRey
— tiwu (@tiwu_official) April 15, 2019
広い・綺麗
アベマタワーズに入りたかったから開催したらしいですw
テーマは「新しい挑戦と学び」のため、新人が多い
ライブ配信もしていた。
Roppongi.vue開催時はライブ配信LT会あまりないかなーと想っていたけど最近のLT会はライブ配信めっちゃしている(・∀・)
新卒3年目、ヤフーで学んだ2年間を振り返る
以下メモ
- 濱田唯
- 1994年
- ヤフーの2年間の振り返り
- 6ヶ月OJT
- 未経験
- 10月からFrontEnd
- 3ヶ月基礎研修・OJT
- いろんなチームの雰囲気把握のためローテしたりする
- TS,Atomic Design,Redux
- TSカンペキニリカイシタ
- インプットアウトプットの習慣づけ
- チーム内LT
ローテはいいなって思った
チーム内LTの合意の取り方気になる
AbemaTV 新卒1年目エンジニア実録
以下メモ
- 野口 直寛 @nodaguti
- 新卒2年目
- 560PR
- 10万行くらい
- Prettierで2万行稼いだ
- 1ヶ月くらいが新卒採用
- 研修でSlack作った
- 小さいUI変更を最初やっていた
- 2週間スプリント
- Flux独自実装
- intersection Observerを使う
- スマホ実装
- 仕様固まっていたからひたすら実装をする
- モバイルブラウザをどうプロダクトとして伸ばすか
- 再生前の離脱ユーザー
- 数字をあげるのが課題
- 12月は負債返したりリファクタリングしたり
- 機能開発がどうKPIに影響するか見ている
- テックリードを目指す
- リーダーシップ
- 専門性
- 技術から事業に貢献
- パフォーマンス改善とリファクタリングは優先度さがりがち
- パフォーマンスがビジネスの指標にどう貢献できるか見える化する
HTML5Conferenceで新卒研修でSlack作ったネタで登壇していた人だった
機能に重きをおかず、開発スタイルに重きを置いた(テスト・カバレッジ・英語で書くなど)話をしていて印象に残っていた
Webフロントエンド&デザインで学んだ2年間を総括
以下メモ
- 内藤 秀彦 @innovate_7110
- ヤフーショッピング
- 3年目
- 機械学習・デザイナー・フロントエンドエンジニア
- デザインにおける改善
- 解決したい課題を探す
- チームで解決する課題を決める
- ビジネス貢献考えUIを作る
- ABテスト
- 抽象的キーワードが多く、商品にたどり着けない
- CTRが多い(ページネーションが多くクリックされる
- その他で絞り込むからではなく、もっと絞り込むに変える
- FVで商品見えるようにした
- 1テストで1つの変更にしないと勝った理由がわからない(勝つだけが目的じゃない
- モジュールとエレメントで管理
- gulp
- テスト→勝ち筋→施策
- KPI分解
- CVRめっちゃ追うチーム
- CSS上書きで調整
- ストーリーブック
- PHP,jQuery
- 独自jQueryライブラリ
- React Atomic Design Next Redux
- D3.jsでデータビジュアライズ
UIのABテストをまわす話とか前職を思い出した
こえのブログでのPWA 〜開発現場編〜
以下メモ
- 原 一成 @herablog
- IE 6対応。。。。
- なぜwebアプリ
- クロスプラットフォーム
- 小さくリリースできる
- ブラウザ機能の充実
- ネイティブアプリに近づけた
- 早い・オフライン
- クライアントサイドレンダリングでつよつよに
- time to interactive(操作可能
- 遅くなりがち
- HTML読んだあとにすぐJS呼ぶ(初期表示に必要なJSは減らす
- ネットワークの速度(CDN使おう
- PRPL Pattern
- Push,Render Pre cache , Lazy Load
- type moduleで
- HTTP2 server push
- HTML返却と同時にHTTP2 PUSH
- スクリプトをとにかく読む
- on loadでSW
- SWがその後読み込む
- CDNヒット率がとても高い
- イベントドリブンでCDNのキャッシュパージ
- ビルド時とか
- LitElement
- 捨てやすさ>再利用性
- cssのカスタムプロパティ
- 166kb
- LHつよい
- マイク関連
- 音声の圧縮
- 開発フロー
- 細かく出す
- 間違ったら直す
- 再利用より捨てやすさ
- 最速でプロトタイプ
- FireBaseでプロトタイプ
- HTML, Pure JSで作って、コンポーネント下
- アクセシビリティ
- デプロイ
- 心理的安全性を・・・高める
- パフォーマンスバジェット設定
- FCP,TTI,SpeedIndex
- 競合より20%早いと差が出る
- OSSのように社内で開発
こえのブログの開発ブログは読んでいて、今回一番楽しみだった
「捨てやすさ>再利用性」これに結構頭ガツンと殴られた
懇親会
エンジニアイベントだから寿司とピザとビール(* ‘ω’)
— tiwu (@tiwu_official) April 15, 2019
#frontrend_bonfire pic.twitter.com/iYMFNNBzj9
寿司うまー
まとめ
PHPerKaigiもそうだったけど勉強会のつなぎのBGMいいな#frontrend_bonfire
— tiwu (@tiwu_official) April 15, 2019
BGM良かった