GIFTech Academy

日時

日付: 2024年3月16日（土）、2024年3月17日（日）
時間: 両日とも10:00 ~ 17:00（※17日のみ終了後、懇親会がございます）
場所: WESTALL四谷ビル 1F

スケジュール

1日目

9:00 ~ 10:10 : 受付
10:10 ~ 10:45 : 開会、概要説明
10:45 ~ 11:00 : ABEMA MVP Focus 上映
11:00 ~ 11:50 : AbemaTV取締役 長瀬 慶重氏 ~ ABEMAのMVP ~
11:50 ~ 12:00 : Kachaka MVP Focus 上映
12:00 ~ 13:00 : 昼休憩
13:00 ~ 13:50 : Kachaka開発責任者 寺田 耕志氏 ~ KachakaのMVP ~
14:00 ~ 14:20 : GIFTech Lab 佐藤 貴子 ~ N1エンジニアリングレポート ~
14:20 ~ 15:40 : ReazonHD執行役員 佐藤 裕一氏 ~ MVP開発手法 ~
15:50 ~ 16:00 : menu MVP Focus 上映
16:00 ~ 16:50 : menu開発責任者 友兼 諭史氏 ~ menuのMVP ~
16:50 ~ 17:00 : 1日目閉会

2日目

9:30 ~ 10:00 : 受付
10:00 ~ 10:30 : GIFTech Lab 大泉 共弘 ~ クリエイターとの共創 ~
10:30 ~ 13:00 : N1エンジニアリング体験
13:00 ~ 14:00 : 昼休憩
14:00 ~ 15:00 : GIFTech Lab 山口 暁亨 ~ デザイナーとの共創 ~
15:00 ~ 15:20 : N1エンジニアリング体験 ~ FB ~
15:30 ~ 16:00 : GIFTech Challenge ~ テーマ発表 ~
16:00 ~ 16:50 : GIFTech Challenge ~ 共創へ ~
16:50 ~ 17:00 : GIFTech Academy閉会
17:00 ~ 19:00 : 懇親会

講演者・登壇者一覧 (※敬称略)

1日目

AbemaTV取締役 長瀬 慶重 : 「ABEMAのMVP」
Kachaka開発責任者 寺田 耕志 : 「KachakaのMVP」
menu開発責任者 友兼 諭史 : 「menuのMVP」
ReazonHD執行役員 佐藤 裕一 : 「MVP開発手法」
GIFTech Lab エンジニア 佐藤 貴子 : 「N1エンジニアリングレポート」

2日目

GIFTech Lab クリエイティブディレクター 大泉 共弘 : 「クリエイターとの共創」
GIFTech Lab アートディレクター 山口 暁亨 : 「デザイナーとの共創」

GIFTech Challenge

スケジュール

開発期間：3月18日(月) ~ 4月27日(土)
発表日：4月28日(日) 終日オフライン
発表会場：東京都内の会場（後日ご連絡いたします）
4/28(日)発表当日のご案内は別途ご連絡いたします。

開発におけるルール

• 1チーム5名、全部で6チーム構成とさせていただいております。
• 各インフルエンサーに対し、2チームずつ割り振られます。
• 各チームにアイディエーター1名・デザイナー1名がアサインされます。
• 各チームにGIFTech Labサポーターが割り当てられます。何か相談したいことがあればサポーターにご連絡ください。
• 週に1回、チーム（アイディエーター、デザイナー、エンジニア、サポーター）の定例会を設定してください。（全6回）日程を決めていただき、サポーターがホストする形で、zoomリンクを発行いたします。
• 成果物としては、発表当日にN1インフルエンサーがプロダクトを体験（手元で操作）できることが求められます。
• 各チーム上限1万円の開発補助をいたします。
  • 開発補助はチーム内で開発に必要と判断できるものに使用できます。
  • ただし、4/28発表当日に領収書を提出でき、領収書に記載される日付が3/17〜4/28となるものに限ります。（PDF可）
  • 宛名は「株式会社FIELD MANAGEMENT EXPAND」でお願いいたします。
• 外部サービス利用によるアカウント等は各チームで作成願います。
• 発表当日まで開発内容を外部へ公開しないでください。
  • ソースコードはGitHub上にprivateで作成し、各チームのサポーターをリポジトリにインバイトしてください。
  • 4/29以降はpublicにしていただいても問題ございません。
• 発表形式については4月に追ってご連絡いたします。

審査基準

『GIFTechなチーム開発ができているか』

• プロダクト軸：N1にとって優れたUXを提供しているプロダクトであるか。
• チーム軸：個々人がオーナーシップを取れているか。

賞品

1. GIFTech賞（獲得賞金50万円）
2. N1賞（獲得賞金10万円）
   • インフルエンサーが「SNSで紹介したい」と言うこと

注意事項

• 会場内での写真撮影は可能ですが、他の参加者や周囲の人々に十分な配慮をお願いいたします。
• また、事故やトラブルが発生した場合には、主催者は責任を負いかねます。
• セッション中の録音、録画はご遠慮ください。
• 各チームごとにGIFTechオリジナルTシャツを用意しております。
• 4/28(日)の発表当日に着用をお願いいたします。

AbemaTV 取締役 長瀬 慶重氏 ~ ABEMA の MVP ~

• 数多くのサービスを経験したが、サービス的な失敗もしてきた。

テーマ 1: オーナーシップ

オーナーシップの定義

• 目標に向けて、チームに対して、何を与えられるか？を考える力 - 積極的に、

• ただ、与えられたことをやるのとは違う！ - 指示待ちの人間(作業者)ではない！

• 自分で決めたことの方が、力を発揮できる

• 課題から定義して、提案する方が楽しい

オーナーシップのあり方

• どのレイヤーのエンジニアなのかで、あり方が変わると思います。

• ゴールに向けて、改善するための提案を実施するのに、立場は関係ない。

• ただの不満で終わらせないで、アクションできるか？

• 変えられないと諦めないで、提案できるか？

• エンジニアの待遇に対して、不満があるエンジニアが社長の藤田さんに対して、提案をした。

  • 実際に評価制度も変わるなど、いい影響を会社に与えた。

• オーナーシップとは、自分ごととして、行動していく姿勢だとも言えそうですね。

オーナーシップに関する質問

1. オーナーシップを持つことは大切だと思うのですが、それぞれが同じゴールを意識していないとバラバラな方向に向かうだけでまとまらないような気がしています。
   同じゴールを持つために意識されていることはありますでしょうか？

• 意思統一は、リーダーの役割としてある
• それぞれのオーナーシップがぶつかることは、ある？
• ゴールが同じなら、目的は一緒
  • 提案した中身や、意見が違うだけ
• 所属する組織で、オーナーシップが発揮できない環境があったりする
• オーナーシップが発揮できる環境とは？
  • 意見を受け入れ、取り入れてくれる環境
  • 成果が評価として、反映される環境
• 改善したくても、変えようがないと、愚痴になっちゃう。。。

2. オーナーシップが大事だと考えるようになった、きっかけなどは？

• 昔のサイバーエージェントには、各部署の受託開発を実施する部門があった
• 営業からの依頼に対する不満があり、営業と一緒に営業に行って、目的などに対する理解に繋げた。

3. 立場関係なく声出しできる環境をどのように用意していますか？発言しやすい環境にするコツは社風以外で、一人一人の振る舞いでどのようなのがあるか気になりした！

• 会社の文化は、醸成することができる
• 評価項目に、技術者に対しても、オーナーシップの項目を用意している
• 役員しか見れないアンケートがある
• 毎月、ボトムアップで、意見を吸い上げる
• 社員がチームを組んで、役員に意見 & 決議する機会がある

テーマ 2: 0->1 開発の極意

• 100 個以上の開発経験がある中で、0->1 回の開発の極意

0->1 回の開発で大事なこと

• 最高 or 最速 でないと、プロダクトは勝てない 🌟
• マーケットがまだ、未開拓なら、速度が大事
• マーケットに先行者がいるなら、それを超える強み、最高が大事
• 新規開発なら、最速でプロダクトを作ってリリースする
• ライバルがいるなら、ライバルを超える最高をリリースする

印象に残ったプロダクト

• Abema は、印象に残っているが、作ったものが多すぎて覚えてないものも多い。
• 3 年で、100 個ぐらいのプロダクトを作った時は、15 個ぐらい運用など携わっていた。。。

思い込みを排除する

• ものづくりのプロセスから、思い込みを排除する
  • 意思決定しないと、プロジェクトは進まない
• 少数だけのアイデアの裏付けを取るようにする
  • ユーザーのリサーチをする、定量的なアンケート

ユーザー・インタビューなど実際に取っている手法は？

• Uber が、エクスペリエンス・プラットフォームというものを作っている

• 意図どうりにグロースするのは、3 割とか 4 割ぐらい。。。

• プロトタイプの

• 機能を作って、チームで OK が出たら、1%など特定の User に先行公開して使ってもらう

• どんどん実験して、失敗していいよという前提のもと、ものづくりを進めている

• 渾身の想いの試作が当たるか、当たらないかを

• 失敗は、振り返って次の活かす、開発プロセス

• 世の中の反応に合わせて、チューニングしていく。

• 量と質について

• 一番大事なのは、質で、100 個の失敗より、3 個の成功プロダクトの方が会社としては嬉しい。

• 反面、組織が成長するために、量は大事

• 失敗の上に、成功確率を高めていくのが大事

3 年で 100 個のプロジェクト

• 人が育つという資産
• 越境する

話し合いと開発の割合など

0→1 開発をする上で MTG が多い気がします。
スピード感もった開発も求められる中、話し合いと開発の割合などはどのくらいなのかきになりました。

• 具体的な Mock を作る
  • みんなが、ワクワクするもの
• みんなが、これを目指せばいいんだと言う指標になるし、みんなワクワクして作れる 🌟
• ビジュアルをもとに、細かい話が進んでいく

会社として残った価値観や教訓など

3 年で 100 個プロダクトを作る取り組みにおいて、残ったプロダクト・終わったプロダクトがあると思いますが、会社として残った価値観や教訓などはありますか？

• 最高 or 最速 でないと、プロダクトは勝てないが、前提としてある
• それが、本当にスケールするものなのか？
• 継続性があるかどうか？
• 熱狂するかどうか？
• そういった、ネガティブ・Check も大事

今までで最大の失敗は？

• この前、亀田こうきさんに謝れた。。。
• 亀田こうきさんの試合の時に、Abema Server が落ちた時は青ざめた。。。
  • ゴングがなった時に、Server が落ちた。。。
• 冗長性が足らないことや、レイヤーでのチェックが足りていないなどの問題によって、起きた問題だった
  • 大量のアクセスを捌ききれなかった。。。
• その後のすごいアクセスを捌くことができるようになったのは、その失敗が活かされた。

Abema に関する質問

1. 業務要件と基盤要件は対立するかなと思いますが、どちらを優先しますか？
   abema のアプリでメイン画面の両脇に別チャンネルの動画を一部写すのは業務観点では簡単そうにみえる UI ですが、基盤要件の課題が多そうだなと思いました。
   基盤的に難しいという理由で業務要件を差し戻すのはありなのでしょうか？

• 差し戻すという工程がない
• やり方は、
• 難しくは見えるが、こういう方法なら可能だと提案して

2. Abema の開発で、責任をもてば自由に技術選定ができるという話でしたが、その間に複数の人が複数の技術を提示したときにどのようにして絞り込みましたか？

• 最終的な意思決定は、各分野のスペシャリストが、決めている
• 経営層などに対して、技術選定の理由を説明する責任もある
• 提案するエンジニアも選定理由を語れないといけない

ハッカソン・チャレンジに向けたアドバイス

• オーナーシップと、フォロワーシップが大事 🌟
• フォロワーシップは、支え合いや、協調性、他者に対する想像力など
• 意見がぶつかったとしても、いい結末に導けるようにする

最後に伝えたい 3 つのこと

• 自分の考えを若い人にも伝えたかった

• 海外を見ていると、技術者に対する

• 未来は、どんどん残酷だけど、未来を切り開いていってほしい

• どういう人間だったら、価値のある人間なのか？ を考えて、動いていってほしい

1. 環境

• どこで働くかが、すべて
• どんな人と働くかが、すべて
• 成長産業(成長ドメイン)に身を置いた方がいい
  • チャンスが多い

2. 変化をおそれない

• 新しいものが出た時に使わないのは、
• 技術者にとって、一番大事な好奇心
• 変化に寛容で、変化を楽しむ

3. オーナーシップ

• AI 時代のスキルは、ハードスキルより、ソフトスキルの方が求められる
• T 型の技術領域
• 基礎力が求められる
• コミュニケーションや、チームワークは、人にしかできない
• 人としての価値が、よりフォーカスされる時代になる

Kachaka MVP Focus 上映

• スマートファニチャー・ロボット

• Kachaka 家庭用ロボット MVP 開発について

• お客さんに届けるために、腕を取るという判断

• 根源的なものは、ものを運ぶこと

• エンジニア視点ではなく、ユーザー視点

• 周りの人の困りごと、に対する解決策を考える

• UX 起点からのイノベーション

• 本当に売れるのか？

• 家の中で、試すことにした

• 試作機を家に持ち帰って、使ってみる

• エンジニア自らが、ユーザーとなって、試作機を検証する

• 自分で使ってみて、イラッとするポイント

• 売ることの難しさをエンジニアはわかってなくて、それを反省

• エンジニアの理想, マーケターの理想, デザイナーの理想

• エンジニアではない人たちとの連携

• コミュニケーション取れる関係性が、めっちゃ大事

• まずは、一番嬉しいところだけ、取り出して作る

• 0 -> 1 で作るときは、ユーザー観点・UX も考えられないと、いけない

Kachaka 開発責任者 寺田 耕志氏 ~ KachakaのMVP ~

• Kachaka開発責任者 寺田 耕志さん
• ロボットを製品化して、世に出すのが夢だった
• 趣味は、自転車など

Kachaka に関して、簡単に教えてください

• Kachaka は、家庭内で動く搬送型ロボット
  • 指定したものを持ってくる
• 取ってきて欲しいものをとってくる
• 家の中のものを棚ごと、持ってきてもらう

https://kachaka.life/

ハードウェアを作る難しさ

• ハードウェアを作る難しさについて、
• Webサービスと比べて、
• いろいろなロールの人が関わっている
• 生産・評価・認証のプロセスが
• ソフトウェアの Update は簡単
• ハードウェアの Update は大変で、失敗できない
• 売り方に関しても、クラウドファウンディングなど
• 量産する時には、コストを下げる工夫が必要
• 型だけで、数千万とかするので、デザインの決定に対する判断に緊張感がある

Kachaka プロジェクトのスタート地点

• (家庭向け)ロボット業界は、成功例がそんなにない。。。
  • 一番成功したのは、家庭用ロボットのルンバ
• 産業用ロボットは、工場でよく使われている
• MVP開発

プロダクトとして、お客さんに届ける

• 日本は、ロボット大国でやってきたが、海外が最近、強い。
• ロボット業界で、ビジネスの人も
• 研究ではなく、製品として、みんなが買えるものとして出したかった
• 日本は、toB 向けのロボットが多いが、toC 向けのロボットは少ない？
• 最近は、toB でも海外の方が強くなったりしている

マーケターとのやり取り

• エンジニアが、エンジニアリングだけにとどまっていては、いけない
• お互い常識や感覚が違うところがあるので、
• 作りやすさ, コスト意識,
• 任せられるところは、任せる
• Codeを書くだけでなく、マーケターの方と必要に応じて、交渉することもした。

ユーザー視点のきっかけ

• ユーザー視点の困りごとから、考えていく
• 一般の人も属性によって、使い方が全然違う。。。
• 自分の家に持ち帰って実際に使うのも、めっちゃ大事
• 家で、実際に使ってみると、気づくこともある
• 物理的に家庭に置かれる Kachaka の場合は、家で使わないとわからないことが多い。

売ることの難しさ 〜「価値を伝え、届ける」ことの難しさ〜

• 使うことが想像できない
• Web広告・Webマーケティングで、
• どういう時に嬉しいか？を伝える
• 体験会場, ショールーム
• 貸し出しなども実施している
• 何か、よくわからないものを買ってくれる人は、いない
• 使ってくれる人、1人1人に、

質疑応答コーナー

ハードウェアに載せるソフトウェアを作ることの魅力or難しさは何ですか？

• 物理的に、ものが動くのは嬉しい
• いろいろな物理現象を意識ながら、Codeを書くのは、面白いし、知識が広がる
• 音や振動など

ミニマムでものを運ぶ機能以外で、出ていた他のアイデアなど

Kachaka のプロトタイプ作りの際に、ミニマムでものを運ぶ機能以外で、出ていた他のアイデアなど、動画で伝えていただいたもの以外で、差し支えなければ教えてください。
また、なぜそれらの機能を削っていったかを教えていただけると幸いです。

• 最初に、User に意見を聞くと、いろいろなロボットにしてほしいことが出てくる
  • 例えば、お風呂掃除ロボット
  • でも、お風呂掃除ロボットを作ろうとすると、
• ある程度、作って、User に見せて、User の意見や要望を聞いてみる

AIがよりコードを書いていく時代で、必要なロボットエンジニアのスキルとは？

• 有用なAIツールは、どんどん使っていく、キャッチアップしていくのが大事だと思います。
• 使えるものは、何でも使ってみよう

Kachaka の製品名の由来はありますか？

• Kachaka は、ドッキングする時に、かちゃと音がする

Kachakaに反映させるユーザーの声はどのような基準で取捨選択するのか？

ユーザーから色々な声が集まると思うのですが、Kachakaに反映させるユーザーの声はどのような基準で取捨選択されていましたか？

• より多くの人に使ってもらえそうな機能を優先度高めにして、対応していった

ロボット業界にビジネスの人が入ってこない理由は？

ロボット業界にビジネスの人が入ってこないとおっしゃっていましたが、その理由には何があるとお考えですか？

• 単純に、マーケットの大きさの問題だと思います。
• 市場を作っていくことも、ロボット業界の楽しさだと思います。

toBとtoCでのMVPは結構変わりますか？

• toC向けに、Kachakaは作成していますが、toBでも買ってくれたりします。
• Kachaka Pro もある
• toBだと制約条件が家庭と変わってくるので、その制約条件に合わせたカスタムをしたりする
• toBとtoCでも、共通するものがあるので、その普遍性をベースにカスタムしていく

マーケターとの調整で、大変だったことやエンジニアとして譲れなかったこと

• マーケターとの調整で、大変だったことやエンジニアとして譲れなかったことがあれば、教えていただきたいです。
• 機能要求は、マーケターの方から、出してもらうことが多かったです。
• 説得性を一般の人、マーケターの人に対して、

エンジニアがユーザー視点を持つ上で、学ぶべきことありますか？

• ユーザー視点って、誰にでもできそうで意外にできない、、って認識がありますが、エンジニアがユーザー視点を持つ上で学ぶべきことありますか？
• どんな工程であっても、User視点は活きてくる

新しいプロダクトを作る上で、どんなことをヒントに開発したりしてますか？

• 新しいプロダクトを作る上で、どんなことをヒントに開発したりしてますか？kachakaの開発のヒントになったものがあれば教えてください。
• 常識を疑って、開発に取り組む

これからロボットで成し遂げたい夢とかゴールはありますか？

• 人の代わりになって、家庭を手伝ってくれるロボットを作れたらと思っている
• ロボットがすべての家庭に入ってくる未来を目指している

ハッカソン・チャレンジに向けたアドバイス

• 「N-1開発」では、早めにプロトタイプを作って、声を聞くのが大事だと思います。
  • ユーザー視点
  • 早めに、プロトタイプを作って、サイクルを回していく🌟

最後に伝えたい3つのこと

1. 思い込みを捨てて、データ・ドリブンで決定・判断する
2. 自分の想像のお客さんでものを作らない
   • 実際のインサイトなど、お客さんの声を聞くなど
   • お客さんとのコミュニケーション
3. 仲間をリスペクトして、いろんな意見の人を取り入れたり、話し合うこと

GIFTech Lab 佐藤 貴子 ~ N1エンジニアリングレポート ~

• N1エンジニアリングとは？

• たった1人に向けて、開発するということ

• モンスター育成ゲーム： ダスもん

• 面倒なゴミ出しを楽しくするゲーム

• ゴミの画像を撮影して、食べてもらうと成長する育成ゲーム

N-1のターゲット像

• 新社会人1年目
• 慣れない日々で、身の回りのことまで手が回らない
• アイデア出し,
• 「掃除の習慣化をサポートしてくれるアプリ」とかいいのでは？
• アイデアを出して、ブラッシュアップしていく

0から、N1 だけに寄り添った開発が理想的な体験だった

• 0から、N1 だけに寄り添った開発ができる🌟
• ポイントは、用途の習慣化

MVP機能の棚卸し

• Level1〜Level3で、機能アイデアの実装・優先順位を立てる
• Level1 の ゴミをキャプチャーする機能や、ゴミ出し日の通知機能など優先順位が高いものから実装

技術選定

• Unityを選びました
• Unityエンジニアは、5名中、1人になりました

クリエイター × プランナー × デザイナー × エンジニア での協奏関係

• クリエイター × プランナー × デザイナー × エンジニア で、協奏関係
• 画面遷移図で、動きを共有する
• 常に開発中でも、共通認識を合わせるのが大事
• 動くものができたら、共有する
• N1のことを意識した開発体験
• N1のためのプロダクトであることを忘れないことが大事🌟

MVPの開発速度について

• 基盤をすぐに作って、機能は役割分担して、個々人で作っていった
• 2週間ぐらいで、MVP開発1つができた

ReazonHD執行役員 佐藤 裕一氏 ~ MVP開発手法 ~

• MVP開発のアプローチについて説明します。
• Menuの取締役兼 CEO 佐藤 裕一 さん
• 大学の研究は、技術的な研究をしていた
• 戦略コンサルティング・ファームで働いていた

N=1 開発に向けたアプローチ

• 誰かにめちゃくちゃ好きになってもらえるプロダクトを開発しましょう🌟
• 顧客の選択
  • 顧客の理解
  • 仮説の検証
  • 仮説の構築
• チーム全員で、ユーザーの反応を観る

どのように顧客を理解するか？

• デプス・インタビュー ( Depth Interview )
• 過去の行動や事実を聴きながら、その人の価値観を客観的に把握する
• 時間やお金の使い方 / 過去のエピソードなどを、他者の影響を受けないように、1 on 1 で聴く
• 価値観や、購入意向を聞くような、抽象的な質問には、事実とは違う自己イメージが返ってくるので、注意🌟
  • 週、何回ぐらい、これを買いますか？
  • 最初に、いつこの商品を知りましたか？

インタビュー後のアウトプット例

• 時間や、お金を何に使っているのか？

  • ある日の行動
  • 家計簿

• 意志決定要因は、何か？

  • 情報源と、意志決定への影響度
  • 購入/導入のきっかけと、判断理由
  • 人間関係と意思決定への影響者

• 何から、情報を取得しているのか？

  • Xは、ものを買うときに、どのように影響しているのか？

解決すべき課題をどのように設定するか？

• ユーザーが抱える困りごとを洗い出す
• pain point (痛点) = 困りごと, 解決したい悩み
  • 生活の中で、感じている pain point (痛点) を書き出していく
  • すべて書き出したら、個々の pain point (痛点) をグループ化したりして、構造化に理解する

自分たちが向き合う「課題」の着眼点を模索する

• How might we 〜 ？：どうすれば私たちは、 〜することができるだろう？

• どこを「課題」とするか？ どこに「着眼」するか？

• 事例： 前日、お酒を飲みすぎて、朝起きるのがつらい

• どうすれば私たちは、 翌朝アルコールが残らないようにできるだろうか？

• どうすれば私たちは、飲み会に行かなくていいようにできるだろうか？

• などなど、いろいろ「課題」が考えられる。。。

どういった観点で、課題を絞るのか？

1. ビジネスとして、検討して、決めるパターン
2. N=1 開発のように、プロダクト志向でやる場合は、投票で決めたりする

チームセッション

• Userの声: チームの輪を乱す女性がいて、困っています。いつも文句や陰口などばかり。。。
• どうすれば私たちは、 〜することができるだろう？

自分軸での解決グループ

• どうすれば私たちは、 彼女の愚痴を聞かずに過ごすすることができるだろう？
• どうすれば私たちは、彼女の闇を解決できるだろうか？

その人を排除して、解決するグループ

• どうすれば私たちは、彼女を会社から排除できるか？

仕組み化で解決するグループ

• どうすれば私たちは、 彼女の愚痴を聞かずに過ごすすることができるだろう？
  • 物理的な距離を

-わるぐちを言わないように、ポジティブにできるか？

• わるぐちを言う機会を減らせるか？
• わるぐちを面白くできるか？

どのように MVPに落とし込んでいくのか？

MVP ( Minimum Visible Product )

• MVPは、仮説絵お検証できる最低限の「何か」

-はじめのアイデアは、だいたいミスっている

• 最初の一歩は、いかに開発せずに、雑な実験を行うことが重要

• MVPへの具体的な不満を解決していくとこによって、

• このプロダクトに

MVP 開発のアプローチ

1. プロトタイプ
2. オズの魔法使い
3. コンシェルジュ
4. スモークテスト

1. プロトタイプ

FBをもらえる「最低限の要素」に絞って、実際に動く「モノ」を作る

• あったらいいな、は徹底して入れない！

2. オズの魔法使い

アプリや、サイトの「フロント面」だけを開発して、裏では人間が対応する

• 画面遷移だけを用意して、まるで、プロダクトが完成しているかのようにアウトプットを届ける
  • Zappos, DoorDash, Optimus
• 最初から、すべてを作る必要はない！

3. コンシェルジュ

まずは、人間が解決して、顧客の要望や解決した時の反応を蓄積する

• SNSなどで、直接依頼を募集して、人間が解決する
• 予約サイトや、マッチングサービスなど、カスタム性の高いニーズを理解するには、特に有効

4. スモークテスト

サービスを紹介する動画や、企画書を作成して、ユーザーの反応を観る

• フロントすら作らずに、開発前に反応を観る
  • ローンチ前に、登録や購入を募る：「プレオーダー」
  • ランディングページや紹介動画をターゲット層に見せる
• DropBox (動画), AirBnB(LP) など

Work：架空のサービスを検討する

• 日本では禁止されている、スポーツ賭博ですが、アメリカでは合法な州があります。

• もし、日本でスポーツ賭博が合法になったら？

• 事例は、Uber と AirBnB

• 規制緩和によって、浸透されるサービス

1. Userのペルソナ： N=1決定

• スポーツ賭博
• スポーツ好き,
• スポーツ,
• 女性でも、好きなものなら、
• ファン心理: 観に行く
• 貢ぐ感覚
• ウマ娘をやって、
• ギャンブルは好きだけど、スポーツ沼に落とす

N=1は、ギャンブルは好きだけど、スポーツに興味ない人

• 男性
• ギャンブル好き
• スポーツ観戦には、今まで興味がない
• 彼女がいる

2. ユーザーの pain point を整理しましょう

• 公営ギャンブルのカテゴリーが限られている
• ギャンブルに対するイメージが、よくない
• 彼女とデートするときに、連れて行けるようなものではない。
• お金を大量に失ってしまうのでは、ないか？
• どのギャンブルなら、安全なのか？

3. 課題の切り口を決めて、解決のアイデアを出しましょう

• どうすれば私たちは、 彼女とデートでギャンブルに行けるか？

4. MVPの手法を意識して、何をどう検証するか決めてください

1. ギャンブルに、

• Gameウイイレ上から、
• 観戦に行ったら、

フィードバック・タイム

• User に好かれるか？
• N=1 の絞り込み方について
• N=1 をどう選ぶかの時点で、勝負としての要素が大きい
  • マーケット(ターゲット)の母数を代表する具体的なペルソナ
• N=1 を決定する際のデータの集め方は？
  • 調査会社を使ったり
  • 人づてにターゲットに近い人から話を聴いてみたり。
• N=1 から始まるスタートアップは結構、ある。
  • AirBnB

menu MVP Focus 上映

• 4ヶ月で Menu のアプリを開発するという話
• 今回のMVPを作った経緯
• TapGo というテイクアウトApp が全然使われなかった
• Menu は、
• 競合他社のアプリを研究
• 必要な機能に絞る
• 飲食店 -> クルー(配達員) -> ユーザー
• 競合アプリで、
• デリバリーフードサービスで、使用実績のある OSSを活用する
• 触った感じ、カクツクなどの問題が起きた。。。
  • ライブラリの問題。。。
• React から React Native に変えた
• 失敗したとしても、チャレンジすることに意味がある
• ダブルピック
• 物理が絡むサービスだからこその難しさ
• 自分自身も配達員をやって、分かったことがある
• エンジニア
• サービス自体を理解する
• 当事者になる
• Code的な美しさより、リリース速度やユーザーが満足するかどうか？ の方が重要
  • Code的に100点でなくても、70点でもリリースはできる
• コロナが拡大した時にちょうど、リリースしていた
• どんどん User が増えていった
• いかに早く、いいものを提供できるか？
• 早くリリースして、早くフィードバックもらって、改善する
  • Cycleを速く回す

menu開発責任者 友兼 諭史氏 ~ menuのMVP ~

• 友兼 諭史 さん
• Sler に就職して、SESとしてシステム開発に従事する
• ゲーム会社に転職して、ソーシャル開発に従事する
• 人の心を動かすサービスづくりを目指している

Menuとは？

• フードデリバリー App

テイクアウトから、デリバリーへ

• 最初は、アルバイトの人を時給制で雇って、常に配達員がいる状態からスタートさせた
• 元々作っていた、TapGo というテイクアウトApp を改修する

とりあえず出す

• スピード感について
• 事業側から、求められていたのか？エンジニア組織として？
• お互いに
• リリースしてみないと、わからないことが多い
• やってみてわかる課題が、たくさんある
• 最低限の機能でもリリースすれば、フィードバックや課題がどんどん出てくる
• そのフィードバック、改善点から、

どこまでで、リリースすべきかの判断のコツについて

100点でなくていい、とおっしゃっていましたが、どうしても気を使ってしまいます。。どこで切り上げるべきかのコツなどをアドバイスくださると嬉しいです！

• 100点って、誰も出せないと思います。。。
• 明確なゴールラインを決めて、この機能まで実装できたら、リリースする。
• チームで、明確なゴールラインを決める

Uber Eats との差別化ポイント

新しいプロダクトを世に出す際はスピードが大切とあったのですが、既にUber Eatsが出ていたと記憶しています。スピード以外に差別化したポイントはありますでしょうか？

• Uber を超えるUXを目指すのが、1つ。
• 店舗の人や、配達員の人が使うAppに関しては、先行者であるUberと同じような業務Appにした。
  • 変えると、学習コストが上がってしまう。。。
• Userアプリ側で、差別化するために、ガチャなどのエンターテイメント性を持たせるなども実装したりした。

デザイナーとのやり取りについて

デザインの一括変更でデザイナーからキツめの指摘をうけたときはどんなことを言って納得させることができましたか？

• Web App か Native App だと、どうしても触り心地が、ぜんぜん違うものとなってくる
  • ラグの問題など
• React から React Native だと

フレームワークの刷新について

1. React から React Native のリプレイスの苦労点など、教えてください！
   また、最初に React を選定した理由も教えてください。

• Web View を使用していた、React の方が
• UI はリッチになるけど Nativeだと審査の影響で、開発が遅くなるデメリットがある
• React から React Native のリプレイスの苦労点は、運用しながらだとキツかった。。。
  • React から React Native を同時に新規追加やメンテなど
  • 並行期間がキツかった。。。

2. どれくらいの期間でReactからReact Nativeに書き換えたんですか？

• 2ヶ月ぐらいで、できました。

「とりあえず出す」のリスクについて

「とりあえず出す」のクオリティーが低いとユーザからの評価が下がり、後からの挽回が難しい、というリスクもあるのではないかと考えます。
このリスクについて、どのように考えて「とりあえず出す」に取り組んでいるのか、お伺いしたいです。

• User
• クリティカルな Bug は、絶対に出さないようにするが、完璧に Bug がない状態を目指してはいない
• User からフィードバックをもらえるラインが重要

MVP開発 のデメリットについて

MVP開発から始まると、修正を繰り返しつつプロダクトを運用していくことになりますが、大規模修繕などをする際にMVP開発したことがネックになることってあるのでしょうか？

• 人数が増えてくると、同じやり方が通用しなくなること
• チームの規模が大きくなると、Docをちゃんと用意することが重要
• その時、必要なDocなどを用意することが必要

リリース前に予期せぬ使い方を防ぐための取り組みについて

「ダブルピック」を予想できなかったとありましたが、ユースケーステストなどはされていたのでしょうか？
自分が今開発しているサービスでも同じように想定外の操作をされることが多いので、リリース前に防ぐ術があればご教示いただきたいです。

• システム上と、物理で変わってくる問題
• 速く配れると思って、やっちゃってましたね。。。
• 事前に予測するのにも、限界がある。。。
• リリースして、検証しないと、わからないこともある
• スピード感のために、一部、完璧なTestは犠牲にする
• 後々、リカバリーをどれだけ、速くできるか？

SES / ゼロイチ開発の長短

今SIerでSES中心で仕事をしていますが、ゼロイチの開発にも興味を持っています。 それぞれの長短などアドバイスがあれば教えてください。

• プロダクトとの向き合い方が、変わります
• SESの時は、実際に使用する User のことを考えなかったりもする。。。
  • 納品することが目的になっちゃう。。。
• 自社開発のプロダクトでは、User にいいサービスを届けることが目的になる🌟

後発のサービスに追いつかれないための工夫など

初速だけ早くても後発のサービスに追いつかれてしまうと思うのですが、追いつかれないためにどのような工夫をされていましたか？

• リリースして、フィードバックを受けて、素早く改善するというCycleを回すというやり方は変わらない。
• 複数人で開発する上で、必要なものを徐々に取り入れていくなどもしています。
  • 開発生産性や、開発体験の向上にも取り組む

チームのモチベーション管理について

スピード感重視の開発では、チームのやる気が非常に重要だと考えられますが、チームのモチベーション管理などで意識したことはありますか。

• 開発者自身が、当事者意識を持って、取り組むことで、モチベーションが

ライフワークバランスとのバランスについて

スピード感のある開発をする中で、どうしてもエンジニアのライフワークバランスとの兼ね合いになってくる部分もあると思います。どのようにバランスを取ったりメンタルサポートをしたりしましたか？

• 少ない人数の時は、わりとハードワーク
• 徐々にスケールしていく中で、負荷が減っていきました
• 自動化の導入など
• CI/CDを導入するのもコストがかかるし、安定しないサービスでは逆効果になります。
• リリース・タイミングを長くして、バッファーを設けたりもした。

自動化しすぎると、逆に問題になる場合もある

• 自動化は、ルーティン化されたものを手動から、自動化する
• 手動の方が、いいタイミング
• 自動化した方が、いいタイミング
• 安定化したフェーズだと、自動化が効果的になる🌟

他業種との連携について

1. 運用メンバーの場合
   • Push通知が欲しい
   • クーポンが欲しい
2. 店舗運営のからのヒアリング(情報聴取)
   • 運用上の課題、解決の聞き込み
3. 配達員の方からのヒアリング(情報聴取)
   • どんな使い方をしているのか？
   • 他のAppを使いながら、バックグラウンドで、使ったり

ヒアリング(情報聴取)について

• 一緒にサービスを作ってくれる仲間として、素直なフィードバックを聞けるように質問などをしている
• 対面すると、やはり一緒にプロダクトを作る仲間として、話を聞きやすかった

プロダクトから機能を捨てることの重要性

• 多数の機能から、どれか当たればいいやぐらいの感覚だと、当たらない。。。
• 他の機能は、やってもいいけど、
• いる/いらない を選ぶことで、刺さる機能にだけ、リソースを割くことができる

工数管理・進捗管理について

短い開発期間の中でリリースするために、予実管理やエンジニアの工数管理・日頃の業務での進捗管理などで工夫した点を知りたいです

• 最初は、アナログ看板で、可視化しました🌟
  • Jiraとか、Backlogを使ってもいたけど、
• よく見えるところに、現状を置いているのは、すごく重要

ハッカソン・チャレンジに向けたアドバイス

• エンジニアは、作ることに集中しやすいですが、お客さん・User が本当に何が必要で、求められているのか？を考えてほしい

伝えたい3つのこと

1. 本当に必要な機能に絞ること
   • これがあれば、User は満足するというものだけ、ピックアップする
2. 動くものを見て考える、動かして考える
   • なるはやで作って、動かしながら、ブラッシュアップする
   • 実際に動くアプリの感覚を大事にする
3. 担当する範囲を制限しない
   • エンジニアの範囲は、プロダクトに対する、すべて
   • すべてのセクションに興味を持つ

GIFTech Academy 2日目

GIFTech Lab 大泉 共弘 ~ クリエイターとの共創 ~

• 実験の中で、発見した、実践にすぐにつながるようなフォーマットを用意しています。
• 早速、開発アイデアだけ考え始めちゃうのは、なし！
• ちゃんと、N=1を明確にするプロセスを実践する🌟
• カラーコンテなどで、イメージを表現する・掴むのもいい
  • プロに頼むと、数万 & 数日かかる。。。
• 価値検証フェーズでは、市場調査・競合サービスなどの状況について知ることが必要
• 何ができるか？の前に、何が求められるのか？

インタビューのスキル

• インタビューのスキル
• 限られている時間の中で、何を聞くべきか？
• 考えて、事前準備する
• 引き出したい内容を聴けるような質問を準備する
• 相手のレスポンスまで想定して、さらに先の展開まで考える

インタビューのスキルについて

• 好きなことをしている上で、もっとこうだったら、ハッピー
• 課題、困りごとについて聴く

• 最短で、求めるような答えを

1. 自己紹介、経歴
2. ハマっているもの、悩み事

• 要所、要所で、質問をする

• 聴きつつ、メモをとる

• どういう視点で考えて、質問していたか？

• 聞き上手

• いい感じに引き出すように、質問をしていく

• ないものを作ることに意味がある前提

• ないものを作ろうという意識

• パーソナリティーをふかぼって行く🌟

インフルエンサーさんに対するインタビュー

• 限られた時間の中で、4〜10 個の質問を事前に、用意しておく

• 事前に情報収集をして、あたりまえの情報は、理解しておく

  • あたりまえの情報については、質問しない

• 本音で話してもらうためには？

  • 何で、話してもらえないのかを分析する
  • その問題を解決する

• 広く質問して、気になる点を深ぼっていく

• 共感ポイントは、ちゃんと共感する

• 悩みがある場合は、どういう悩みよりかは、今までどうやって解決しようとしてきたかを質問したりする

• 事例を紹介したり、

1. 1回目は、ヒアリング・ターン
2. 2回目は、

GIFTech Lab 山口 暁亨 ~ デザイナーとの共創 ~

• 山口 暁亨さん
• クリエイティブ & Techスキル
• クリエーターになる前は、エンジニアをしていた
  • PHP, MySQL
  • 当時は、Flashエンジニア
• Flashエンジニアのその後の進路は、映像系や、JS系などをしていた
• 映像系に進路を進んでいった。
• レアゾンホールディングスで、デザイナーを今はしている

GIFTech の logo について

• 団結を表す、行間の近さ
• 力強さとして、太めの フォント
• みんなが、GIFTech であることを表現したい

エンジニアとデザイナーが共創する時代

• エンジニアとデザイナーの共創で必要なもの
• 大事なのは、共通認識を持つこと

1. 画面遷移
2. ワイヤー
3. デザイン

1. 画面遷移

• 画面遷移をいきなり作らず、まずは妄想してください
• UX目線、ユーザー目線での妄想力
• 「いかにシーンを妄想するか？」が大事
  • みんなで、いろいろなシーンを想像することことで、さまざまなユースケース・パターンを想定することができる

妄想の観点・軸

1. 時間軸で、妄想する
2. 場所軸で、妄想する
3. 気持ち軸で、妄想する

共通認識のポイント

• ひとつのシーンから、妄想する
  • 同じシーンを共通認識として持つ🌟
  • 同じシーンをみんなで、共有しながら、考える
• 気持ちの妄想
  • 生の User の気持ちを想像・妄想する

使うアイテムについて

• 大型の付箋
• 中型の付箋
• 吹き出し

実践フロー

1. シーンを妄想する
   • どんなシーンなのかを妄想する
2. 画面を妄想する
3. 遷移を妄想する

取捨選択

• ユーザーの意見を聴きながら、何を取り入れる/取り入れないの選択が必要

ターゲットとなる N=1 がどういう人

• ターゲットとなる N1 のかたを知ることから、始めます

デザインは、ヒアリングが5割 残り5割が技術など

ヒアリングで重要なポイント

1. ターゲットを誰にするか？
2. 流行り・トレンド・競合
   • マーケットの状況を調べる
3. 自分たちの意志
   • どういったものを作るのか？作りたいのか？

イメージの共有から、始める

• 目的として、デザインイメージを絞りたい
• どういうトーンを目指すのか？

イメージボードの制作

• Logoや、イメージなどのボードを用意して、好きなタイプのデザインを選んでもらう
• 複数のプランを用意する
  • 可愛い系, シンプル系, クール系
• ターゲットに刺さるデザインを探ることが目的🌟

イメージボードで、コミュニケーション・相手を知る

• Logoだと、どういう方向性がいいですか？
• イラストに関しては、どういう方向性がいいですか？

ブランド・アイデンティティー

• いろいろな要素のブランド・アイデンティティー

GIFTech Challenge ~ テーマ発表 ~

• GifTech 2024 春 のインフルエンサーは 3名

開発におけるルール

• 1チーム5名、全部で6チーム構成とさせていただいております。
• 各インフルエンサーに対し、2チームずつ割り振られます。
• 各チームにアイディエーター1名・デザイナー1名がアサインされます。
• 各チームにGIFTech Labサポーターが割り当てられます。
  • 何か相談したいことがあればサポーターにご連絡ください。
• 週に1回、チーム（アイディエーター、デザイナー、エンジニア、サポーター）の定例会を設定してください。（全6回）日程を決めていただき、サポーターがホストする形で、zoomリンクを発行いたします。
• 成果物としては、発表当日にN1インフルエンサーがプロダクトを体験（手元で操作）できることが求められます。
• 各チーム上限1万円の開発補助をいたします。
  • 開発補助はチーム内で開発に必要と判断できるものに使用できます。
  • ただし、4/28発表当日に領収書を提出でき、領収書に記載される日付が3/17〜4/28となるものに限ります。（PDF可）
  • 宛名は「株式会社FIELD MANAGEMENT EXPAND」でお願いいたします。
• 外部サービス利用によるアカウント等は各チームで作成願います。
• 発表当日まで開発内容を外部へ公開しないでください。
• ソースコードはGitHub上にprivateで作成し、各チームのサポーターをリポジトリにインバイトしてください。
  • 4/29以降はpublicにしていただいても問題ございません。
• 発表形式については4月に追ってご連絡いたします。

審査基準

『GIFTechなチーム開発ができているか』

1. プロダクト軸：N1にとって優れたUXを提供しているプロダクトであるか。
   • N1を喜ばせることができるか？
2. チーム軸：個々人がオーナーシップを取れているか。
   • 個々人のオーナーシップ

賞品

1. GIFTech賞（獲得賞金50万円）
2. N1賞（獲得賞金10万円）
   • インフルエンサーが「SNSで紹介したい」と言うこと

定例について

• コミュニケーションが目的
• 定例は、週1回を推奨
• チーム・リーダー
  • チームの開発進捗
  • 会議の設定
  • チーム開発の進捗報告・共有を実施する

チーム ✖️ インフルエンサー発表

• インフルエンサーに対する質問を考える

N=1 ヒアリング

• 3/28〜3/29 にインフルエンサーに対する