こんにちは、AIQ株式会社のフロントエンドエンジニアのまさぴょんです！
今回は、GIFTech 2024 春 の GIFTech Academy に参加してきましたので GIFTech と GIFTech Academ で学んだ内容についてご紹介します。
今回の記事は、1日目に、GIFTech Academyで学んだことについて、まとめます。
GIFTech とは？
GIFTechはプロジェクトで、GIFTech2024春が、株式会社レアゾン・ホールディングスが主催する次世代型ハッカソンです！
次世代型ハッカソンと銘打っているのは、技術志向よりのモノづくりだけでなく、Userに対する価値創造にも重点を置いた、プロダクト志向・ユーザー志向の実践にも力を入れたハッカソンである点にあると思っています🧐
2日間の GIFTech Academy で、MVP開発や、N1エンジニアリングといった、プロダクト志向・ユーザー志向の開発手法を実践的に学び。
その後、1ヶ月間の GIFTech Challenge で、N1のターゲットとなるUserの課題を解決するアプリをチームで開発(MVP開発)していくというハッカソンになります💪🥺🔥
(GIFTech Challenge がハッカソンであり、GIFTech Academy は、実践型の講義というイメージで、認識しています)
上記は、あくまで私が実際に参加してみて(まだ参加期間中)の要約であるため、
GIFTech公式からも、引用させていただきます👀✨
『GIFTech』とは、エンジニアの創造性を刺激し、モノ創りの喜びを再発見するためのプロジェクトです。
例えば、アカデミーや次世代型ハッカソンを実施し、仲間と共にプロダクトやサービスをゼロから開発するアイデアや技術を深堀りしていきます。
本プロジェクトでは、この体験を通じて“テクノロジーとモノ創りを楽しむ才能”を伸ばすことが目標となります。
また、『GIFTech CH』という動画チャンネルを開設し、プロジェクトの過程を公開することで、多くの人々に知識と情熱を共有していく予定です。
モノ創りの楽しさを再認識し、更なるステージへステップアップできるようなものになれたら嬉しいです。
引用元: GIFTech 『N1エンジニアリング』レポート
上記の引用にあるように、アカデミーと次世代型ハッカソンを通して、仲間と共にプロダクトやサービスを、0->1で開発する技術を実践・深堀りしていくハッカソンであることが、通常のハッカソンと違うポイントだと言えそうです🌟
そして、このハッカソンを企画した根本的な目的・設計思想として、「0→1を生み出すエンジニアへ成長するためのきっかけ作り」 をするという想いがあるようです🔥
仲間と共創して、プロダクトを0から開発できるエンジニアが人気
また、「あなたがなりたいエンジニア像は？」というアンケートを実施した結果、「仲間と共創して、プロダクトを0から開発できるエンジニア」という回答が最も多いということでした。
つまり、データ的にも、今回のテーマの裏付けを取っているようですね👀
(データ・ドリブンで、ハッカソンの企画も決めている🌟)
画像・引用元: GIFTech 『N1エンジニアリング』レポート
GIFTech Academy 1日目のタイムテーブル🌟
GIFTech Academy 1日目のタイムテーブルは、次のような内容でした👀
豪華出演者による、MVP開発の裏側、考え方について、じっくり聴ける貴重な機会でした。。。😭
(ありがたすぎて、全力で、メモを取りました。。。😭)
| 時間 | 内容 |
|---|---|
| 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日目閉会 |
MVP開発とは？
実際に、セッションで聴いた内容についてのレポートをご紹介する前に、そもそも、MVP開発とは、なんぞや？
という疑問を解決しておきたいと思います。
MVP（Minimum Viable Product） とは、顧客に価値を提供できる最小限のプロダクトのことを指します。
ちなみに、日本語訳は 「実用最小限の製品」(Minimum Viable Product、MVP)になります。
MVPの本質は、その名前のとおり、Userの課題を解決する最小単位のプロダクトの企画・設計・開発をすることにあります。
MVPは、製品開発の最初のステップとして位置づけられることが多く、「新規開発」(0->1開発)を実施する際のアプローチとして、非常に有効です。
MVPを用いて開発することのメリット
MVP開発の意味がわかったところで、MVPを用いて開発することのメリットについて、まとめてご紹介します。
1. ユーザー視点でプロダクトの価値を最大化できる
MVP開発では、必要最低限の機能を備えたプロダクトを企画・設計・開発・リリースすることで、ユーザーのFB(フィードバック)をはやい段階で得られます。
そして、ユーザー・フィードバックをもとに、少しずつ新たな機能の実装や改善を実施するサイクルを回すことで、アジャアイル的に ユーザー駆動開発 ができます🌟
2. 効率よく最適なプロダクトを作成できる・コストとリスクを最小化できる
MVP開発では、必要最小限の機能しか備えなくていい分、開発にかかるリードタイム(着手から完了までの期間)が短くなります。
そのため、MVPは仮説の検証をスピーディに進めることが可能です。
つまり、もし仮説が正しくなかったとしても、次の検証に素早く取り掛かることができます。
こういった、検証スピードの速さによって、コストとリスクを最小化できる点でも、メリットがあります。
3.新たな市場に速く参入することで、競争優位性を高められる
MVP開発では顧客ニーズに対応するプロダクトをスピーディーにリリースすることが可能なため、マーケットに先行者がいない場合は、先行者利益を得ることができます。
先行して、リリースできれば、後から参入する競合他社に対して認知度で差をつけることができ、競争優位性を高められるという、メリットがあります。
MVP開発に関する、ここまでのまとめ🌟
ここまでで、MVP開発の意味と、メリットなど要点の一部をご紹介させていただきました、
その他にもMVP開発についての調査内容は、こちらのレポートにまとめています👀🌟
MVP開発の実践事例
ここからは、GIFTech Academy 2日目で、登壇してくだっさった方々のMVP開発についてのセッション内容についてご紹介していきます🌟
ABEMAのMVP開発について
最初のセッションは、誰もが知るあのサービス「ABEMA」のMVP開発について、
AbemaTVの取締役である長瀬 慶重さんが、ご紹介してくれました。
テーマ 1: オーナーシップ
長瀬さんのセッションでは、最初にテーマ1として 「オーナーシップ」 というKeywordが上がりました🌟
長瀬さん流のオーナーシップの定義として、
「目標に向けて、チームに対して、何を与えられるか？」を積極的に考える力、それがオーナーシップであるとありました🔥
つまり、ただ、与えられたことをやる作業員とは違い、自発的・積極的に目的達成のために動く人である
(指示待ちの人間(作業者)ではない！)
オーナーシップのあり方
オーナーシップのあり方は、どのレイヤーのエンジニアなのかで、あり方が変わると思います。
ただ、ゴールに向けて、改善するための提案を実施するのに、立場は関係ない🔥
- ただの不満で終わらせないで、アクションできるか？
- 変えられないと諦めないで、提案できるか？
とオーナーシップのあり方について、語ってくださいました👀✨
オーナーシップに関する質疑応答コーナー
ここで、いったん、オーナーシップに関する質疑応答コーナーが入りました🌟
1. 同じゴールを持つために意識されていることはありますでしょうか？
まず前提として、ゴール・目的の設定と意志統一(共通認識)が、リーダーの役割としてあります。
その上で「それぞれのオーナーシップがぶつかることは、あるかも？」と考えるかもしれないが、ゴールが同じなら目的は一緒です。
つまり、提案した中身や、意見が違うだけで、向いている方向(ゴール・目的)は一緒になります🌟
2. オーナーシップが発揮できる環境とは？
オーナーシップが発揮できる環境は、次のような、特徴を持っていると考えます。
- 意見を受け入れ、取り入れてくれる環境,
- 成果が評価として、反映される環境
また、所属する組織によっては、オーナーシップが発揮できない環境があったりすると思います。。。
改善したくても、変えようがないと、愚痴になっちゃう。。。🥺
それは、避けるべきことです。
3. オーナーシップが大事だと考えるようになった、きっかけなどは？
昔のサイバーエージェントには、各部署の受託開発を実施する部門がありました。
そこで働いていた時に、営業からの受託開発の依頼内容に対する不満があり、営業と一緒に営業に行ってみました。
すると、営業さんの苦労や考え方などを理解したことで、開発に営業サイドのドメイン的な問題を解決する対応などをしたことを覚えています。
つまり、他の部署とも、積極的に連携して動くこと(現場を知ること)で、意味のある受託開発ができた経験が原体験としてありました。
4. 立場関係なく声出しできる環境をどのように用意していますか？
会社の文化は、醸成することができます。
例えば、次のような取り組みで、会社の文化・環境づくりをしています。
- 評価項目に、技術者に対しても、オーナーシップの項目を用意している
- 役員しか見れないアンケートがあり、毎月、ボトムアップで、現場の意見を吸い上げている
- 社員がチームを組んで、役員に意見 & 決議する機会が定期的にある
テーマ 2: 「0->1」開発の極意
テーマ2は、「0->1」開発の極意という内容でした👀✨
長瀬さん、ご自身が3年間で、100個以上の開発に何かしらの形で関わっていたという経験がある中で、「0->1」開発の極意について語っていただきました🌟
まず、印象だったのが「0->1」開発では、最高 or 最速でないと、プロダクトは勝てないというお話でした。
どういうことかというと、
- 最速： マーケットがまだ、未開拓なら、最速が大事
- 最高： マーケットに先行者がいるなら、それを超える強み、最高が大事
「0->1」開発では、思い込みを捨てる
「0->1」開発では、ものづくりのプロセスから、思い込みを捨てるようにしてください。
判断基準が事実ベースであるために、ユーザーのリサーチをする、定量的なアンケート取るなど、アイデアの裏付けを取るようにしてください。
実際に取っている開発手法について
Uberが、エクスペリエンス・プラットフォームというものを作っています。
アプリの中で、意図どうりにグロースするものは、3 割とか 4 割ぐらいだとか。。。🥺
プロトタイプの機能を作って、チームでOKが出たら、1%など特定のUserに先行公開して使ってもらうなどのやり方があります。(いわゆる、ベータ版など)
このように「どんどん実験して、失敗していいよ」という前提のもと、ものづくりを進めています。
量と質について
どちらも大事ですが、ビジネス的に一番大事なのは、質だと考えています。
例えば、100 個の失敗より、3個の成功プロダクトの方が会社としては嬉しい。
反面、組織が成長するために、量も必要です。
つまり、失敗の上に、成功確率を高めていくのが大事だということです🌟
「0->1」開発の極意に関する質疑応答コーナー
ここで、いったん、「0->1」開発の極意に関する質疑応答コーナーが入りました🌟
話し合いと開発の割合などについて
具体的なMockを作ることを大事にしている。
具体的なMockがあると、みんなが、これを目指せばいいんだと言う指標になるし、みんなワクワクして作れる🌟
ビジュアルをもとに、細かい話が進んでいきます。
会社として残った価値観や教訓など
まず、「最高 or 最速でないと、プロダクトは勝てない」 という考え方が、前提としてある。
その上で、ネガティブ・チェックをすることも大事であることが、価値観・教訓としてある。
- それが本当にスケールするものなのか？
- 継続性があるかどうか？
- 熱狂するかどうか？
長瀬 慶重さんから、ハッカソンに向けたアドバイス
ハッカソンでも、オーナーシップと、フォロワーシップが大事です🌟
フォロワーシップは、支え合いや、協調性、他者に対する想像力などのことを言います。
意見がぶつかったとしても、いい結末に導けるようにしていってください🔥
AbemaTVの取締役である長瀬 慶重さんから、最後に伝えたい3つのこと
AIの台頭で、世界は、どんどん変わっています。
技術者の仕事は、そのうちAIにほとんど取って代わられるかも知れません。。。
未来は、どんどん残酷だけど、未来を切り開いていってほしい💪🥺🔥
という熱いメッセージの後に、AbemaTVの取締役である長瀬 慶重さんから、最後に伝えたい3つのことは、次のような内容でした。
- 環境
- どこで働くかと、どんな人と働くかが、すべてです🌟
- チャンスが多い成長産業(成長ドメイン)に身を置いた方がいい
- 変化をおそれない
- 新しいものが出た時に使わないのは、技術者としては、致命的かも知れない。。。
- 技術者にとって、一番大事な好奇心
- 変化に寛容で、変化を楽しむようにしてください🌟
- オーナーシップ
- AI 時代のスキルは、ハードスキルより、ソフトスキルの方が求められる
- コミュニケーションや、チームワークは、人にしかできない
- 人としての価値が、よりフォーカスされる時代になる
KachakaのMVP開発について
続いて、MVP開発について、語ってくれたのは、Kachaka開発責任者である寺田 耕志さん🌟
ロボットを製品化して、世に出すのが夢だったとのことで、実際に、Kachakaが発売されているし、すごいと思いました🔥
Kachaka は、家庭内で動く搬送型ロボットで、指定したものを持ってくることがコア機能になります。
MVP開発として、取ってきて欲しいものをとってくることに、焦点を置いたプロダクトだと言えそうです。
ハードウェアを作る難しさについて
ハードウェアを作る難しさについて、寺田さんが語ってくれた内容を聴き取り整理しました。
ハードウェアは、Webサービスと比べて、いろいろなロールの人が関わっている。
また、生産・評価・認証のプロセスが厳格だったり、
ソフトウェアの Update は簡単だけど、ハードウェアの Update は大変で、失敗できない。。。🥺
生産にコストもすごくかかるので、量産する時には、コストを下げる工夫が必要です。
(型だけで、数千万とかするので、デザインの決定に対する判断に緊張感がある)
Kachaka プロジェクトのスタート地点
続いて、Kachaka プロジェクトのスタート地点(マーケットの状況)について、お話ししていただきました👀
- (家庭向け)ロボット業界は、成功例がそんなにない。。。
- 一番成功したのは、家庭用ロボットのルンバだが、ルンバは、海外企業。。。
- 研究ではなく、製品として、みんなが買えるものとして出したかった。
- ロボット業界には、あまりビジネスの人が入ってこない。
- 日本は、toB 向けのロボットが多いが、toC向けのロボットは少ない？
- 日本は、ロボット大国でやってきたが、海外が最近、強い。
- 最近は、toB でも海外の方が強くなったりしている。
ユーザー視点のきっかけ
MVP開発では、ユーザー視点の困りごとから、考えていくといい。
一般の人も属性によって、使い方が全然違う。。。
自分の家に持ち帰って実際に使うのも、めっちゃ大事で、家で、実際に使ってみると、気づくことがあります。
物理的に家庭に置かれる Kachaka の場合は、家で使わないとわからないことが多い。
例えば、ボタンのランプ機能などが夜も常時ついていると眠れないとか。。。
売ることの難しさ 〜「価値を伝え、届ける」ことの難しさ〜
「価値を伝え、届ける」ことの難しさについても、お話がありました。
使うことが想像できないと、人は買ってくれない。。。🥺
(何か、よくわからないものを買ってくれる人は、いない)
そこで、マーケティングをする必要があり、Web広告・Webマーケティングで、どういう時に嬉しいか？を伝える施策を打ちました。
また、体験会場, ショールームや、貸し出しなども実施しています。
Kachaka に関する質疑応答コーナー
ここで、Kachaka に関する質疑応答コーナーが入りました🌟
ハードウェアに載せるソフトウェアを作ることの魅力or難しさは何ですか？
- 物理的に、ものが動くのは嬉しい。
- いろいろな物理現象を意識ながら、Codeを書くのは、面白いし、知識が広がる🌟
- 音や振動などまで、考慮する点が難しいです。。。
ミニマムでものを運ぶ機能以外で、出ていた他のアイデアなど
- 最初に、User に意見を聞くと、いろいろなロボットにしてほしいことが出てくる
- 例えば、お風呂掃除ロボット
- でも、お風呂掃除ロボットを作ろうとすると、価格が高くなるけど、それでもUserが欲しいかどうか？
- 機能とコストのバランスも大事
- ある程度、作って、User に見せて、User の意見や要望を聞いてみるのもありだと思います。
AIがよりコードを書いていく時代で、必要なロボットエンジニアのスキルとは？
有用なAIツールは、どんどん使っていく、キャッチアップしていくのが大事だと思います。
使えるものは、何でも使ってみましょう🔥
Kachaka の製品名の由来はありますか？
Kachaka は、ドッキングする時に、かちゃと音がすることが由来です。
Kachakaに反映させるユーザーの声はどのような基準で取捨選択するのか？
より多くの人に使ってもらえそうな機能を優先度高めにして、対応していきました🌟
ロボット業界にビジネスの人が入ってこない理由は？
単純に、マーケットの大きさの問題だと思います。
市場を作っていくことも、ロボット業界の楽しさだと思います🌟
toBとtoCでのMVPは結構変わりますか？
toC向けに、Kachakaは作成していますが、toBでも買ってくれたりします。
Kachaka Pro もあります。
toBだと制約条件が家庭と変わってくるので、その制約条件に合わせたカスタムをしたりします。
toBとtoCでも、共通するものがあるので、その普遍性をベースにカスタムしていく感じです。
これからロボットで成し遂げたい夢とかゴールはありますか？
人の代わりになって、家庭を手伝ってくれるロボットを作れたらと思っている🌟
ロボットがすべての家庭に入ってくる未来を目指している👀🔥
寺田 耕志さんから、ハッカソンに向けたアドバイス
「N-1開発」では、早めにプロトタイプを作って、声を聞くのが大事だと思います。
ユーザー視点で、早めに、プロトタイプを作って、サイクルを回していくようにしてみてください🌟
Kachaka開発責任者である寺田 耕志さんから、最後に伝えたい3つのこと
Kachaka開発責任者である寺田 耕志さんから、最後に伝えたい3つのことは、次のような内容でした👀
- 思い込みを捨てて、データ・ドリブンで決定・判断する
- 自分の想像のお客さんでものを作らない
- 実際のインサイトなど、お客さんの声を聞くなど
- お客さんとのコミュニケーション
- 仲間をリスペクトして、いろんな意見の人を取り入れたり、話し合うこと
menuのMVP開発について
最後のMVP開発事例について、語ってくれたのは、menu開発責任者 友兼 諭史さんでした🌟
テイクアウトAppから、デリバリーAppへ
元々作っていた、TapGo というテイクアウトApp を改修する形で、フードデリバリー App 「menu」を企画・開発しました。
(TapGo というテイクアウトApp が全然使われなかった)
最初は、アルバイトの人を時給制で雇って、常に配達員がいる状態からスタートさせました。
リリース後の問題について
リリース後に、触った感じ、カクツクなどの問題が起きました。。。
これは、ライブラリの問題で、リリース後に、React から React Native に変えて、改善しました。
また「ダブルピック」という物理が絡むサービスだからこその難しさ・失敗もありました。。。
このようなフィードバックから、プロダクトをどんどん改善していくことが重要です。
失敗したとしても、チャレンジすることに意味があります。
また、サービス自体を理解する・当事者になることが大事で、自分自身も配達員をやって、分かったことがありました。
とりあえずプロダクトを世に出すことの重要性について
どうしても、リリースしてみないと、わからないことが多いです。
やってみて、初めてわかる課題が、たくさんある
最低限の機能でもリリースすれば、フィードバックや課題がどんどん出てくる
そのフィードバック、改善点から、どんどんUpdateすればいい。
「Code的な美しさより、リリース速度やユーザーが満足するかどうか？」の方が重要で、Code的に100点でなくても、70点でもリリースはできます。
タイミングがよく、コロナが拡大した時にちょうど、リリースしていたため、順調に伸び、どんどん User が増えていきました。
その経験からも「いかに早く、いいものを提供できるか？」を実感しました。
早くリリースして、早くフィードバックもらって、改善するというCycleを速く回すことが重要です。
menuのMVP開発に関する質疑応答コーナー
ここで、menuのMVP開発に関する質疑応答コーナーが入りました🌟
どこまでで、リリースすべきかの判断のコツについて
- 100点って、誰も出せないと思います。。。
- 明確なゴールラインを決めて、この機能まで実装できたら、リリースする。
- チームで、明確なゴールラインを決めることが大事かと思います。
Uber Eats との差別化ポイント
- Uber を超えるUXを目指すのが、1つ。
- 店舗の人や、配達員の人が使うAppに関しては、先行者であるUberと同じような業務Appにした。
- 変えると、学習コストが上がってしまう。。。
- Userアプリ側で、差別化するために、ガチャなどのエンターテイメント性を持たせるなども実装したりした。
React から React Native のリプレイスについて
- Web App か Native App だと、どうしても触り心地が、ぜんぜん違うものとなってくる
- ラグの問題など
- Web View を使用していた、React の方が開発が速くできました。
- UIはリッチになるけど Nativeだと審査の影響で、開発が遅くなるデメリットがある
- React から React Native のリプレイスの苦労点は、運用しながらだとキツかった。。。
- React から React Native を同時に新規追加やメンテなど
- 並行期間がキツかった。。。
- 2ヶ月ぐらいで、できました。
「とりあえず出す」のリスクについて
- クリティカルな Bug は、絶対に出さないようにするが、完璧に Bug がない状態を目指してはいない
- User からフィードバックをもらえるラインが重要
MVP開発 のデメリットについて
- 人数が増えてくると、同じやり方が通用しなくなること
- チームの規模が大きくなると、Docをちゃんと用意することが重要
- その時、必要なDocなどを用意することが必要
リリース前に予期せぬ使い方を防ぐための取り組みについて
- システム上と、物理で変わってくる問題
- 速く配れると思って、やっちゃってましたね。。。
- 事前に予測するのにも、限界がある。。。
- リリースして、検証しないと、わからないこともある
- スピード感のために、一部、完璧なTestは犠牲にする
- 「後々、リカバリーをどれだけ、速くできるか？」が重要
SES / ゼロイチ開発の長短
- プロダクトとの向き合い方が、変わります
- SESの時は、実際に使用する User のことを考えなかったりもする。。。
- 納品することが目的になっちゃう。。。
- 自社開発のプロダクトでは、User にいいサービスを届けることが目的になる🌟
後発のサービスに追いつかれないための工夫など
- リリースして、フィードバックを受けて、素早く改善するというCycleを回すというやり方は変わらない。
- 複数人で開発する上で、必要なものを徐々に取り入れていくなどもしています。
- 開発生産性や、開発体験の向上にも取り組む
ライフワークバランスとのバランスについて
- 少ない人数の時は、わりとハードワーク
- 徐々にスケールしていく中で、負荷が減っていきました
- 自動化の導入など
- CI/CDを導入するのもコストがかかるし、安定しないサービスでは逆効果になります。
- リリース・タイミングを長くして、バッファーを設けたりもした。
自動化しすぎると、逆に問題になる場合もある
自動化しすぎると、逆に問題になる場合もあります。
自動化は、ルーティン化されたものを手動から、自動化することをオススメします🌟
中でも、安定化したフェーズだと、自動化が効果的になります。
つまり、まとめると次のような感じです。
- 手動の方が、いいタイミングは、開発初期の安定していない状態
- 自動化した方が、いいタイミングは、安定しており、ルーティン化されたTaskがある状態
他業種との連携について
それぞれの立場の人と連携・コミュニケーションを取ることで、最適なAppを作れるようにしました。
- 運用メンバーの場合
- Push通知が欲しい
- クーポンが欲しい
- 店舗運営のからのヒアリング(情報聴取)
- 運用上の課題、解決の聞き込み
- 配達員の方からのヒアリング(情報聴取)
- どんな使い方をしているのか？
- 他のAppを使いながら、バックグラウンドで、使ったりしている
- どんな使い方をしているのか？
ヒアリング(情報聴取)について
一緒にサービスを作ってくれる仲間として、素直なフィードバックを聞けるように質問などをしている。
対面すると、やはり一緒にプロダクトを作る仲間として、話を聴きやすかったです。
プロダクトから機能を捨てることの重要性
多数の機能から、どれか当たればいいやぐらいの感覚だと、当たらない。。。
他の機能は、やってもいいけど、
「いる/いらない」を選ぶことで、刺さる機能にだけ、リソースを割くことができる
友兼 諭史さんから、ハッカソンに向けたアドバイス
エンジニアは、作ることに集中しやすいですが「お客さん・User が本当に何が必要で、求められているのか？」を考えてほしいです🌟
menu開発責任者 友兼 諭史さんから、最後に伝えたい3つのこと
menu開発責任者 友兼 諭史さんから、最後に伝えたい3つのことは、次のような内容でした👀
- 本当に必要な機能に絞ること
- これがあれば、User は満足するというものだけ、ピックアップする
- 動くものを見て考える、動かして考える
- なるはやで作って、動かしながら、ブラッシュアップする
- 実際に動くアプリの感覚を大事にする
- 担当する範囲を制限しない
- エンジニアの範囲は、プロダクトに対する、すべて
- すべてのセクションに興味を持つ
N=1エンジニアリングとは？
MVP開発と合わせて、この記事のテーマとなっている「N=1エンジニアリング」についても、ここでご紹介します👀🌟
N=1エンジニアリングとは、1人のユーザーの課題を解決することに焦点をあてて、プロダクトの企画・設計・開発をする開発スタイルです。
つまり、たった1人に向けて、刺さる開発するということ🔥
MVP開発を実践するための具体的なアプローチの1つだと言えそうです。
N=1エンジニアリングの実例は、この後ご紹介します。
GIFTech公式の説明も引用します👀🌟
「N1エンジニアリング」は、複雑なプロセスをシンプルにするアプローチです。
一人のユーザーを満足させることに焦点を当てることで、N1の好みが全ての答えとなり、ビジネスとクリエイティビリティの面では簡易化が、テクノロジーの開発面では効率化が実現されます。
ビジネス、クリエイティビティ、テクノロジーの各要素を将来的にバランス良く習得するためにも、このような特訓は非常に有効だと考えます。
GIFTechも“エンジニア視点” “Z世代視点”など、インサイトをとても重要視して、20代から40代の仲間が共創して生まれたプロジェクトです。
N1エンジニアリングで、実際にモノ創りを純粋に楽しみ、N1対象者から「ありがとう」をもらって喜んでるエンジニアやクリエイターの姿を見て素直に感動しましたし、更に「モノ創り」の楽しさを伝えていきたいなと思ってます。
引用元: GIFTech「N1エンジニアリング」レポート
GIFTech Lab 佐藤 貴子 ~ N1エンジニアリングレポート ~
GIFTech Lab の佐藤 貴子さんによる「N1エンジニアリングレポート」では、MVPおよび、N1エンジニアリングを実践したチーム開発と、成果物である「ダスモン」について、ご紹介いただきました🙌
アプリイメージなどは、次のとおりです👀✨
引用元: ダスモン
N1が掃除を習慣化するために“開きたくなる”アプリを作成することにこだわりました。
キャラクターデザインなどグラフィック周りでN1の「好き」を研究し、細かくフィードバックをもらうことでN1ならではのアプリが完成したと思います。
また、エンジニアは技術選定から挑戦してみたり、ロジックはできるだけシンプルにしたりと注力したい箇所に集中できるよう作業を調整しました。
チーム全員が積極的に新しいアイディアを提案し、この短期間でとても良いアプリを開発出来たと思います！
引用元: ダスモン
モンスター育成ゲーム： ダスもん
「モンスター育成ゲーム： ダスもん」は、面倒なゴミ出しを楽しくするゲームであり、ゴミの画像を撮影して、モンスターに食べさせることで成長させられる育成ゲームとのことでした✨
ダスモンは“面倒くさいゴミ出しをちょっと楽しくする”モンスター育成ゲーム。
“自分のためにはできない掃除も誰かのためならやってあげたくなる。”そんな想いからこのアプリを作成。
「掃除の習慣をつける」ために思わずまたエサをあげたくなるようなキャラクター、モーションを追求。
ごみ収集日にモンスターのお腹が空くように設定し、忘れがちなゴミ捨ても日々のルーティンに。
モンスターへ愛着が湧くことで掃除の習慣化だけではなく、ちょっとした心のよりどころにも！
分別されたゴミの種類によってモンスターの進化姿が変化。
将来的には進化形態を増やし、モンスターのコレクションをできるようにする予定。
その他機能面でもゆくゆくはカメラの性能を上げてゴミを検知できるようにしたり、他のユーザーと通信で戦わせたり結婚させたり...！
引用元: ダスモン
N1のターゲットについて
N1のターゲット像は、ペルソナを設定したわけではなく、実在する方からヒアリングした情報とのことでした。
N1のターゲットの人物像は、次のような感じです👀
- 女性 23歳 社会人1年目
- 新社会人として、ひとり暮らしをはじめたりと慣れない環境で忙しい日々を過ごしている。
- 仕事や日々の生活に手一杯になってしまい、身の回りの掃除まで手がまわらない。
N1から導き出した課題
自宅の掃除ができないことで、心身ともに健康が損なわれ、体調を崩しがちに。
忙しい中でも掃除をするという習慣をつけたい。
アイデア
掃除して出たゴミを袋に入れて、カメラで撮影。
撮影したゴミをアプリ内のモンスターが食べて成長していく。
MVP機能の棚卸しについて
Level1 〜 Level3 で、機能アイデアの実装・優先順位を立てました。
中でも、Level1のゴミをキャプチャーする機能や、ゴミ出し日の通知機能など優先順位が高いものから実装しました。
ちなみに、Level1 〜 Level3 のカテゴリーの内容は、次のとおりです👀
- Level1: 必須
- Level2: できれば欲しい
- Level3: 将来的に欲しい
0から、N1 だけに寄り添った開発が理想的な体験だった
0から、N1 だけに寄り添った開発ができたのは、理想的な体験だったと語ってくれました🌟
また、次のようなことを意識・実践していったとのことでした。
- 「クリエイター × プランナー × デザイナー × エンジニア」と違う立場・役割で、協創関係を築いていった
- 画面遷移図で、動きを共有する
- 常に開発中でも、共通認識を合わせるのが大事
- 動くものができたら、共有する
- N1のためのプロダクトであることを忘れないことが大事🌟
技術選定
技術選定で、Unityスキルを持ったエンジニアが1人だけだったがN1のための開発をする上でUnityを採用し、皆で開発したとのことでした。
MVPの開発速度について
基盤をすぐに作って、機能は役割分担して、個々人で作っていました。
2週間ぐらいで、MVP開発1つができました。
と語ってくれました。
(おまけ)GifCat が可愛い🐱
公式キャラの GifCat(ギフ・キャット)が、可愛い。。。🥺
ねこ好きには、たまらんぜよ。。。🤤
まとめ・1日目終了後の感想🌟
めっちゃ有意義な濃い内容が、連続した1日だった。。。🌟(語彙力)
Input過多で、家に帰った後、すぐに爆睡しました😇
あと、有意義な情報が多すぎて、この記事書くのに、めっちゃ時間がかかりました。。。🥺
Xやっております！よかったらフォローしてください🐱
注意事項
この記事は、AIQ 株式会社の社員による個人の見解であり、所属する組織の公式見解ではありません。
求む、冒険者！
AIQ株式会社では、一緒に働いてくれるエンジニアを絶賛、募集しております🐱🐹✨
詳しくは、Wantedly (https://www.wantedly.com/companies/aiqlab)を見てみてください。
参考・引用
AIQ 株式会社 に所属するエンジニアが技術情報をお届けします。 ※ AIQ 株式会社 社員による個人の見解であり、所属する組織の公式見解ではありません。 Wantedly: wantedly.com/companies/aiqlab
Discussion