Recommandé
Contenu connexe
Tendances
Tendances (17)
Similaire à 企業報告会スライド
Similaire à 企業報告会スライド (20)
企業報告会スライド
- 1. ミライケータイプロジェクト Future Mobile Phone Project 2016 Project No.1
- 2. 本日の流れ 1 01 02 03 Presen Presen Demo ミライケータ イ全体の概要 について 各サービスに ついて 問題や展望も 含めた紹介 開発企画して きたサービス のデモ実演
- 3. 本日の流れ 2 01 02 03 Presen Presen Demo ミライケータ イ全体の概要 について 各サービスに ついて 問題や展望も 含めた紹介 開発企画して きたサービス のデモ実演
- 5. 概要 ミライケータイプロジェクトの目的 4 ❏ 数年後あたりまえとなっているサービスの企画 とそれを実現するための モバイル端末上で動作 するアプリケーションを開発をすること ❏ ビジネスモデルの立案も同時に行うことで, より実社会に近いプロセスを学ぶこと
- 6. 本プロジェクトの体制 5 理系12名 理系8名 理系12名文系7名 文理融合 の 遠隔地 プロジェクト
- 7. 概要 年間スケジュール 6 5 6 7 8 9 10 11 12 1 2 第1回合同合宿 仕様書の検討 第2回合同合宿 企業報告会 企画・設計 1st Sprint 2nd Sprint 3rd Sprint 4th Sprint サービス検討 成果報告会開発体制の検討
- 8. 概要 年間スケジュール 7 5 6 7 8 9 10 11 12 1 2 第1回合同合宿 仕様書の検討 第2回合同合宿 企業報告会 企画・設計 1st Sprint 2nd Sprint 3rd Sprint 4th Sprint サービス検討 成果報告会開発体制の検討
- 9. 概要 ミライケータイプロジェクト体制 8 ４大学 ３９名 協力企業 １１社 プロジェクト OB・OG サポート 成果報告
- 10. 協力企業・OB/OG 合同合宿 9 ディスカッション時 デモンストレーションを実施した． 実際に動くもに触れていただき， アドバイス をいただいた． サービス決定・ビジネスモデル検討 のディスカッションにおける ファシリテーション 機能の見直し・新機能検討
- 11. 各校の役割分担 10 企画 基本設計 ビジネス モデル 開発 企画・基本設計は4大学で取り組み，ビジネスモデルの提案 は文系の専修大学が主導で行った．開発は理系3大学が担当 4大学全てが担当
- 12. 本プロジェクトの体制 1
- 13. プロジェクトリーダー 本プロジェクトの体制 12 開発 ビジネスモデル 開発 ビジネスモデル 開発 ビジネスモデル 未来大 神奈工 未来大 未来大 法政大 専修大 法政大 未来大 未来大 法政大 未来大 法政大 神奈工 法政大 未来大 未来大 法政大 専修大 Motion Share RecoReco Revive Seat
- 14. 仕様書 1
- 15. 仕様書について 14 要求定義書 サービス企画書 アプリケーション設計書 昨年度 今年度ウォーターフォール型 アジャイル型 要件定義書 サービス仕様書 詳細仕様書 サービスの全体を可視化し，プロジェクト内外で認識を統一を図るため の仕様書2種類を作成．
- 17. 開発
- 19. 開発手法 ウォーターフォール型 18 ウォーターフォール型 アジャイル型 スクラム手法 昨年度までの開発手法 New! 今年度取り入れた開発手法 ❏システム開発全体を一括管理し, 要件定義→設計→開発→テスト を順番に実施し，当初の要求 仕様を満たす開発手法
- 20. 開発手法 アジャイル型 19 ウォーターフォール型 アジャイル型 スクラム手法 昨年度までの開発手法 New! 今年度取り入れた開発手法 ❏要件定義→設計→開発→テスト を短い期間で繰り返し，動くも のを迅速に開発することを重視
- 21. 開発手法 アジャイル型 20 ウォーターフォール型 アジャイル型 スクラム手法 昨年度までの開発手法 New! 今年度取り入れた開発手法 ◆導入した理由 【開発期間を短く区切る】 ・短い期間で開発を区切り，その期間 ごとに計画を立てるため見積もりや 計画が立てやすい ・改善事項を話し合い次に活かすプロ セスがあるため問題の検知が早い 【迅速に動くものを開発】 ・実際に動くプロダクトを見ながら 開発/修正ができる
- 26. 使用ツール 2
- 27. 概要 遠隔地間での作業の対策 26 遠隔地間 北海道 東京 700km以上 お互いが何をしているのか把握しにくい 意思統一が難しい 仕様書の作成 Face To Faceでの議論：合同合宿
- 28. 概要 遠隔地間での作業の対策 27 遠隔地間 北海道 東京 700km以上 お互いが何をしているのか把握しにくい 意思統一が難しい 仕様書の作成 Face To Faceでの議論：合同合宿 ツールを利用したこまめなコミュニケーション
- 29. 使用ツール 28 使用頻度 高低 Skype TM Google Drive メーリングリスト
- 30. 遠隔地間による活動を実現させたツール 29 成果物・提出物の共有 PUKI WIKI TM 即時性が重要な相談や共有 LINE サイボウズ Live 成果物・提出物のレビューや議論 Skype Skype ビデオ通話による会議
- 31. サービス紹介 データ交換を 楽しいものに 会話のドラマを 記録をする 新しい空席を提供 Motion Share RecoReco Revive Seat 30 企画・開発を行ってきた3サービス
- 32. サービス紹介 データ交換を 楽しいものに 会話のドラマを 記録をする 新しい空席を提供 Motion Share RecoReco Revive Seat 31 企画・開発を行ってきた3サービス
- 33. サービス紹介 データ交換を 楽しいものに 会話のドラマを 記録をする 新しい空席を提供 Motion Share RecoReco Revive Seat 32 企画・開発を行ってきた3サービス
- 34. サービス紹介 データ交換を 楽しいものに 会話のドラマを 記録をする 新しい空席を提供 Motion Share RecoReco Revive Seat 33 企画・開発を行ってきた3サービス
- 35. サービス紹介 データ交換を 楽しいものに 会話のドラマを 記録をする 新しい空席を提供 Motion Share RecoReco Revive Seat 34 企画・開発を行ってきた3サービス
- 36. サービス１ Motion Share データ交換を 楽しい ものに
- 37. Motion Share コンセプト 36 モーションで楽しくデータ交換 データの送受信のプロセスに，人間の動きを取り入れた 新しいデータの送受信方法
- 38. Motion Share 背景 37 友人・恋人・家族... 特別な人と「楽しい時間」を過ごしている時， よく写真・動画を撮ることはありませんか．
- 39. Motion Share 背景 38 従来のデータ交換方法 送信者 受信者 送信者はスマートフォンの画面をみて， 共有する写真を選択して送信．受信者は 待つだけ． SNS・クラウド・メール
- 40. Motion Share サービス概要 40
- 41. Motion Share サービス概要 41 対象ユーザ 世界中のリストバンド型デバイス、 スマートフォン所有者
- 42. Motion Share 実装機能 42 握手 グータッチ ハイタッチ 写真 予定 連絡先
- 43. Motion Share 利用シーン 43
- 44. Motion Share 実装機能 44 握手 グータッチ ハイタッチ 連絡先 予定 写真
- 45. Motion Share 実装機能 45 モーション作成機能 モーションを上下左右などに細かくパーツ化． パーツを組み合わせてモーションを判別を行う．
- 46. Motion Share データ交換プロセス 46 モーションに対応するデータが決まっている 送受信者のモーションが一致したとき送信 モーション一致 データ送信 送信者 受信者
- 47. Motion Share 専用デバイス 47 リストバンド型デバイスでモーションすることで より自然なモーションでデータ交換を行える スマホでハイタッチ リストバンド型デバイス でハイタッチ
- 48. Motion Share 専用デバイス 48 本プロジェクト史上初「端末からの自作に成功」 ARDUINOをベースに開発 加速度センサ、ジャイロセンサを搭載 →Bluetoothでセンサ値をスマホへ送信 全プラットフォームで利用可能
- 49. Motion Share ビジネスモデル 49 企業コラボ 課金モデル Motion Share 専用端末の販売
- 50. Motion Share ビジネスモデル 50 企業コラボ 知名度向上・顧客獲得 契約料 Motion Shareを使った イベントの企画・運営 ユーザ 提携企業 運営者
- 51. Motion Share ビジネスモデル 51 企業コラボ 契約料 提携企業 運営者 Motionの考案
- 52. Motion Share ビジネスモデル 52 企業コラボ 提携企業ユーザ オリジナルアイテム 特定のMotion
- 53. Motion Share ビジネスモデル 53 Motion Share専用端末の販売 モーションを判別するセンサや，データを送受信で きるモジュールが搭載された独自のリストバンド型 デバイス 販売価格：3,980円 Apple Watchなどより低価格に設定し ユーザの購入敷居を下げる
- 54. Motion Share ビジネスモデル 54 いくらなら専用端末を購入したいか (2014年 R25スマホ情報局調べ 20歳〜39歳 177名の男女を対象) ¥5,000未満 52% リストバンド型デバイス(UP2Y BY JOWBONE) 腕時計型デバイス「UP24 by Jawbone」 1位 5,000円未満（52.0％） 2位 5,000～7,500円未満（15.3％） 3位 7,500～1万円未満（14.7％） 4位 1～2万円未満（11.9％） 5位 2～3万円未満（4.5％）
- 55. Motion Share ビジネスモデル 55 ユーザ Motionストアから新たに モーションを購入できる 課金モデル 自作Motion枠は4つ目から¥100
- 56. Motion Share ビジネスモデル 56 収支予測 1510.9 (8,000) (6,000) (4,000) (2,000) 0 2,000 4,000 6,000 8,000 10,000 収入合計 支出合計 繰越利益 単位：万
- 57. Motion Share ビジネスモデル 57 収支予測(繰越利益) 3年目に15,109,848円の利益が出る．
- 58. Motion Share 開発工数 58 見積 120人日 実働 82 人日 見積 180人日 実働 234人日 見積 120人日 実働 118人日 見積 72人日 実働 71人日 HTML5 Android iOS Server
- 59. Motion Share 開発秘話 59 →メンバー同士が顔を合わせて長時間しっかり開発する 日を設け、タスクの確認をしたり開発で詰まった点を フォローしたりと協力しあうことができた 集中開発日の設置 →ひとそれぞれでモーションのやり方に差があるので 全てを網羅したセンサ値を手探りで決定 モーションの誤判別
- 60. Motion Share 展望 60 →リストバンド型端末にとどまらず、グラス型、指輪型 服などありとあらゆるデバイスで様々なデータを交換する ありとあらゆるデバイスでMotion Shareを 身につけているモノでMotion Share
- 61. Sharing Data Shares Your Heart.
- 65. RecoReco 背景 65 会話を記録するための手段 手書きで記録 レコーダーで録音
- 66. RecoReco 背景 66 会話を記録するための手段 手間や時間がかかる すべてを記録することは困難 鮮明に記録を取ることができない手書きで記録
- 67. RecoReco 背景 67 会話を記録するための手段 レコーダーで録音 会話をすべて記録できる 聞き返すのに時間がかかる 必要な部分を探しにくい 手軽に記録を振り返れない
- 68. RecoReco 背景 68 今ある手段では… 手書きで記録 レコーダーで録音
- 69. RecoReco 背景 69 今ある手段では… 手書きで記録 レコーダーで録音 手軽さや鮮明さが不十分
- 71. RecoReco コンセプト 71 会話のドラマ※ を記録します 鮮明にどのような会話をしていたかがわかる 手軽に記録して読み返すことができる ※会話の盛り上がりや話者の感情の起伏など、会話の雰囲気や場面のこと
- 72. RecoReco サービスの紹介 72 人の感情や会話の盛り上がりを表現 話者情報 感情の色分け 声のボリューム 書き起こし
- 75. RecoReco サービスの紹介 75 これらの3要素が必要な理由 話者情報 感情の色分け 声のボリューム
- 77. RecoReco サービスの紹介 77 ？？「ごめん！冷蔵庫のプリン食べちゃった」 or 佐藤「ごめん！冷蔵庫のプリン食べちゃった」 会話のドラマ - 話者情報 - 誰がその発言をしたかわからないと情景が伝わらない 話者情報は思い出の記録として必要不可欠
- 78. RecoReco サービスの紹介 78 申し訳ありませんでした or 申し訳ありませんでした 会話のドラマ - 声のボリューム -
- 79. RecoReco サービスの紹介 79 申し訳ありませんでした or 申し訳ありませんでした 会話のドラマ - 声のボリューム - 同じ発言内容でも声のボリュームによって 会話の雰囲気や話者の感情は異なる
- 80. RecoReco サービスの紹介 80 大好きだよ 大好きだよ 会話のドラマ - 感情の色分け - or
- 81. RecoReco サービスの紹介 81 大好きだよ 大好きだよ 文字に色が付加されていることで 鮮明に感情を連想することができる 会話のドラマ - 感情の色分け - or
- 82. RecoReco サービスの紹介 82 人の感情や会話の盛り上がりを表現 話者情報 感情の色分け 声のボリューム 書き起こし
- 84. RecoReco ビジネスモデル 84 会話の書き起こし 月額料金 収益の分配 ・仲介取引モデル 運営 一般ユーザ 有名人
- 89. RecoReco 収支計画 89 3年目には約5500万円の利益を出すことができる 1501.1 4547.6 12185.6 3282.3 4118.3 5238.3 1781.2 1352.0 5505.3 (8,000) (6,000) (4,000) (2,000) 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 収入合計 支出合計 繰越利益 単位：万
- 90. 開発工数 90 見積 60人日 実働 50人日 HTML5 見積 78人日 実働 71人日 Android 見積 66人日 実働 75人日 Server
- 91. RecoReco 開発秘話 91 Android・HTML5で発生したAPIの競合問題 設計のやり直しや追加開発が必要となった →HTML5班が進捗が遅れたサーバ班を補助した 気づいたときには法政大にいるサービスリーダー インターンシップや私用で東京を訪れた際に 法政大を訪れては開発を進めた →進捗の遅れを取り戻すことができた
- 94. Revive Seat サービス紹介 94 ※都内カフェチェーン43店舗での調査結果
- 95. Revive Seat サービス紹介 95 ※都内カフェチェーン43店舗での調査結果 デッドスペース
- 96. Revive Seat 生まれた背景 96 ※都内カフェチェーン43店舗での調査結果 カフェに座りたい人と席を余らせている人を、 マッチングさせるサービス
- 97. カフェを利用しようとしたが、 空席がなくて断念したことがありますか？ ある ない Revive Seat 生まれた背景 97 ※ミライケータイプロジェクトのメンバーが10〜20代の若者232名へのアンケート結果 混雑により席がなかった経験を持つ若者が約70%
- 98. Revive Seat 生まれた背景 98 都内カフェの満席時に、 全席数の約20％はデッドスペース ※都内カフェチェーン43店舗での調査結果
- 99. Revive Seat 生まれた背景 99 座れるはずの席が余っているのに、 座ることができずに入店をあきらめる客が多い 余っている席に座りたい人が座れれば解決
- 100. Revive Seat サービス紹介 100 「席のシェアリングエコノミー」 ホストユーザ (席を余らせている人) ゲストユーザ (席を求めている人)
- 101. Revive Seat サービス紹介 101 シェア登録機能 ホストユーザ（テーブルをシェアする 側のユーザ）が、自分が求める価値を 設定してシェア登録する機能。 登録後はゲストユーザが見るシェア テーブルリストに表示される。
- 102. Revive Seat サービス紹介 102 シェア参加機能 ホストユーザ（テーブルをシェアする 側のユーザ）がシェア可能テーブルに 参加する機能。 ゲストユーザ（シェアに参加する側） はホストユーザが求めている価値を提 供することで参加できる。
- 103. Revive Seat サービス紹介 103 ホストユーザー (席を余らせている人) ゲストユーザー 席を求めている人 価値設定＆募集 例）充電器を貸して欲しい 価値提供＆テーブル参加 例）充電器を貸す
- 104. Revive Seat 概要Movie 104
- 105. Revive Seat ビジネスモデル 105 メインターゲット 大学生・サラリーマン
- 106. Revive Seat ビジネスモデル 106 商品購入 利用料金 （購入額の10％） マッチングの手助け運営者 店舗 ユーザ
- 107. Revive Seat ビジネスモデル 107 から収益を算出 月間収入＝満席時デッドスペース予測数 ×デッドスペース活用ユーザの割合 ×１席の回転数/日×仲介料×30日 実地 調査の データ 都内 店舗数 利用回 転数 仲介料 ユーザ 割合
- 108. Revive Seat ビジネスモデル(収支計画)108 11,973 46,049 92,097 31588 60505 89373 (19,615) (14,457) 2,724 (100,000) (80,000) (60,000) (40,000) (20,000) 0 20,000 40,000 60,000 80,000 100,000 120,000 繰越利益(年） 収入合計 支出合計 繰越利益 単位：千円 ３年目で利益を出すことができる！
- 109. Revive Seat 開発工数 109 見積 182人時 実働 98人時 見積 182人時 実働 174人時 見積 182人時 実働 85人時 見積 49人時 実働 44人時 HTML5 Android iOS Server
- 110. Revive Seat 開発秘話 110 ３サービス内で最もスプリントバックログを使いこなせない • 他サービスを参考に自サービス独自の方法で解決 サービスリーダが仕事を分配できず開発が進まない時期 • 第2回合宿以降少しは振れるようになった センサをやめた • サービスの普及やより価値のある方法を考え，やめた
- 111. Revive Seat 展望 111 一定のユーザ獲得後は、どの年代のユーザが どんな価値を提供求めているかを解析し、 サービスの満足度を向上 大手カフェだけではなく個人経営のカフェな ど、すべてのカフェでのシェアリング
- 112. デモ実演 1 1 Motion Share → RecoReco → Revive Seat
- 113. まとめ【サービス】 データ交換を 楽しいものに 会話のドラマを 記録をする 新しい空席を提供 Motion Share RecoReco Revive Seat 113 企画・開発を行ってきた3サービス
- 114. まとめ【今年度新たに取り組んだこと】 114 ビジネスモデル 理系もメインで ビジネスモデルを検討 開発手法 アジャイル開発 スクラム手法 迅速に動くものをつくり スクラムの特徴を活かせた サービス数 2 → 3サービス 開発するサービス数の増加 ミライケータイ プロジェクト
- 115. まとめ【プロジェクトの成果】 115 ❏ 数年後あたりまえとなっているサービスの企画 とそれを実現するための モバイル端末上で動作 するアプリケーションを開発をすること ❏ ビジネスモデルの立案も 同時に行うことで, より 実社会に近いプロセスを 学ぶこと
- 116. まとめ【プロジェクトの成果】 116 ❏ 数年後あたりまえとなっているサービスの企画 とそれを実現するための モバイル端末上で動作 するアプリケーションを開発をすること ✔ ❏ ビジネスモデルの立案も 同時に行うことで, より 実社会に近いプロセスを 学ぶこと
- 117. まとめ【プロジェクトの成果】 117 ❏ 数年後あたりまえとなっているサービスの企画 とそれを実現するための モバイル端末上で動作 するアプリケーションを開発をすること ✔ ❏ ビジネスモデルの立案も 同時に行うことで, より 実社会に近いプロセスを 学ぶこと ✔
- 118. 質疑応答 1 1 ~20:30まで
- 119. 謝辞 119 本プロジェクトを進めるにあたり、 以下の方々に多くの助言を賜りました。 ここに深甚なる謝意を表します。 近藤弘康 様 鈴木道雄 様 高橋大斗 様 牧野友哉 様 赤石健一 様 浅沼佑紀 様 寺内茜 様 小笠原佑樹 様 牧野孝史 様 経沢優多 様 小泉真折 様
Notes de l'éditeur
- それではミライケータイプロジェクト2016 OBOG報告会を始めさせていただきます. 自己紹介
- 【OBOG / HP】 本日はご覧の流れで報告会を行います. まずはミライケータイ全体や各サービスの概要などについてご説明し, その後各サービスについて発生した問題や今後の展望も含めた詳細なご説明をさせていただきます. その後，企画開発を行ってきたサービスのデモ実演を行います
- ご意見ご質問などは デモの最中又はデモ終了後にお時間を取らせていただきますので よろしくお願いします
- わたしたちは、「ミライ」という言葉を、「数年後あたりまえとなっているもの」と定義しました。 このプロジェクトの目的は数年後当たり前になっているサービスの企画と、 それを実現するためのアプリケーションの開発を行うことです。 また、ビジネスモデルを考案することでじつ社会に近いプロセスを学ぶことです。
- このプロジェクトは、公立はこだて未来大・専修大学・神奈川工科大学・法政大学 理系3大学文系1大学の計4大学39名合同による 文理融合の遠隔地間のプロジェクトです。
- 本プロジェクトの年間スケジュールは、スライドのとおりです。 プロジェクト発足の4月末～7月までは、サービス案の企画と設計を行いました。 8月から学内の成果報告会がある12月までは、短く期間を３つに区切り開発を行ってきました。 成果報告会以降は、アプリケーションの質をより高めるために開発を続け、本日に至ります。
- 私たちはサービス企画段階の6月と開発中盤の10月に4大学合同の合宿を行いました.
- HP様をはじめとする協力企業11社の方々とOB・OGの方々には、主にその合同合宿において本プロジェクトをサポートしていただきました。 主なサポートととして…
- ファシリテ―ションや様々なアドバイスなどでサポートをいただきました. 第1回合同合宿では，各校が考えたサービス案をブラッシュアップ・決定するディスカッションにおいて、ファシリテーションを行っていただきました。 第2回合同合宿では、各サービスのデモンストレーションで実際に動くものに触れていただき，アドバイスをいただきました． 加えて、プロジェクトを進めていくうえでマネジメントや開発手法、技術的なアドバイス，そして各合宿やプロジェクト活動の時間で講演会などを通し多くの知識を提供してくださいました。 そのようなサポートがあり私たちはプロジェクトを進めることができました.
- そして私たちはプロジェクト開始後 3つの大きなタスクに対して役割分担を行いました。 企画・基本設計は全大学で行い、ビジネスモデルの提案は専修大が主導となり、開発は理系3大学が担当しました。 続いては本プロジェクトの体制について…
- です
- 今年度の本プロジェクトは、例年とは大きく異なりサービスが１つ増えて合計3サービスを企画提案することになりました。そのためプロジェクトの難易度が急激に上がり、体制も変化しました。 この図のように大きく3つのサービスを提案するためのグループに分かれました．一つのチームの中に様々な大学が混ざっており，頻度の高い報告，連絡，相談が必須となりました。 サービスの実現を行ううえで必要となってきたのが…
- 仕様書です
- 昨年度までは、ウォーターフォール型だったため 仕様書を4種類作成しておりましたが,本プロジェクト内でもその定義が曖昧でした. 今年度取り入れたアジャイル開発においては、ウォータフォール型にあるようなしっかりとした仕様書を作成する決まりはありませんが, わたしたちは、例年プロジェクトで発生していた、認識のズレを防止し、サービスに関する認識を統一するために、 サービスの全体を可視化する仕様書が必要だと考えました. 仕様書に関し再検討した結果…
- サービス企画書とアプリケーション設計書の2種類を作成しました. サービス企画書は、ウォーターフォール型でいう、「要件・要求定義書」に近いものを指します。ユースケースを明確にして、サービスの全体像を記すことで認識のズレを防止する仕様書です。 アプリケーション設計書、ウォーターフォール型で言う「外部・内部設計書」に近いものを指します。開発に向けて、実装方法やユーザーインターフェース設計など、必要な情報をまとめた仕様書です。 仕様に変更が発生したときは、スプリント終了時に修正を行い、メンバー全員で改めて、変更された仕様について確認・検討を行いました。
- 続いて開発手法や体制についてご説明します.
- 昨年度までは ウォータフォール型で開発を行っていたのに対し, 今年度はアジャイル型で開発を行いました.
- ウォーターフォールは，要件定義・設計・開発・テストを順番に実施し当初の要求を満たす開発手法です
- 一方でアジャイル型開発は 要件定義・設計・開発・テストを短い期間で繰り返し、動くものを迅速に開発することを重視します
- 導入した理由としては大きく3つ. ①開発期間を短く区切ることから その期間ごとに計画を立てるため見積もりや計画・詳細な要求などを決めやすい ②加えて、改善事項を話し合い次の期間に活かすプロセスがあるため問題の検知が早く, より良い体制やサービスにすることができる ③迅速に動くものを開発することを重視することから 実際に動くプロダクトを見ながら開発することができる. これらのことから 今年度アジャイル型開発を取り入れることとした.
- アジャイルスクラム手法は本来, スクラムマスターと呼ばれるアジャイル/スクラムに関して熟知したものがサポートします. また開発するタスクや優先順位はプロダクトオーナーが一人で決定し開発は行いません. 開発チームは，プロダクトオーナーが決めた要求に従い開発を行う，少数精鋭のプロフェッショナルであることが一般的です.
- しかし, ミライケータイの場合は少し異なり, アジャイル/スクラムの未経験者のスクラムマスターがサポートする. そしてタスクと優先順位はプロダクトオーナーが一人で決めるのではなく, 開発チームメンバーと共に要求を決定していき,初心者や中級者が中心のチームで開発を行います. また開発チームとともにビジネスモデルチームがビジネスモデルを検討していくことも特徴の一つです. ＊＊＊ 本来ミライケータイプロジェクトはPBLであり, 学生を中心とし 企業の方々をはじめ, OBOG・教員の方々がサポートに入っているプロジェクトであるため, このような体制にならざるおえなかった. またスクラムマスターである, プロジェクトリーダーは, その他プロジェクト全体のスケジューリングや発表会, イベントへの参加準備等も行うため, 開発は行わなかった.
- アジャイルを導入しうまくいったことは 動くものが早い段階で出来たことや，発生した問題を次のプロセスで迅速に解決できたことや，それぞれのサービスの良い部分を他サービスが取り入れることができたこと. うまくいかなかったことは 本プロジェクトは過去アジャイル型スクラム手法を用いたことはなく過去の情報がなかったため，スクラムで用いるツールの作成や活用ができない部分があり開発に影響が出たことなどがありました.
- 続いて本プロジェクトが使用したツールについてご紹介します.
- 未来大以外は全て首都圏の大学 北海道から東京までは700kmも離れている お互いが何をしているか把握しにくい 意思統一が難しいという問題があります. これらを解決するため 先ほどご説明させていただいた仕様書や 合同合宿などを行ってきました.
- そしてそれらに加え 様々なツールを利用することで, より多く コミュニケーションの機会を得えて 問題を解決しプロジェクトを円滑に進めてきました
- スライドにありますように、たくさんのツールを本プロジェクトでは使用しました。 右側に行けば行くほど使用頻度が高いツールとなっています. たくさんのツールを使用しましたが, それぞれのツールを利用する明確な線引きをしたため情報が混在しすぎることはありませんでした.
- Pukiwiki、サイボウズLive、LINE、スカイプの４つのツールはこれらの目的により使い分けを行いました これらのツールを使い企画開発を行ってきたのが…
- これら３つのサービスです.
- Motion Shareは、 データ交換に、モーションという人間の直感的な操作を加える事で、 ユーザが手軽にデータを交換することができるサービスです
- RecoRecoは 会話のドラマを記録することをコンセプトとし， 会話の盛り上がりや感情の起伏から文字に変化をつけ， 会話の雰囲気や場面を記録する新たなサービスです
- Revive Seatは、 カフェの余っているが利用できない空席 デッドスペースを用いて、 カフェに座りたい人と席を余らせている人をマッチングさせ ユーザに新たな空席を提供する 全く新しいシェアリングエコノミーサービスです
- 以上 私たちが企画開発を行ってきた3サービスについて それぞれ詳しくご紹介します.
- サービスの1つめMotion Shareをご紹介いたします。
- このサービスのコンセプトはモーションで楽しくデータ交換です。 いままでのデータ交換プロセスに人間の動きを取り入れた新しいデータ交換方法です。
- 友人・恋人・家族... 特別な人と「楽しい時間」を過ごしている時， よく写真・動画を撮ることはありませんか． みなさんはいままでどのようにしてスマートフォンで写真などのデータを交換していますか。
- 従来のデータ交換は、送信者はスマホの画面を見て、送信したい画像を選択してSNSやクラウド、メールを使って相手に送信する。 ただの作業になっていると思います。 そして、受信者はデータが送られてくるのを待つだけです。 送信者は目と指しかつかっておらず、受信者は待つだけという非常につまらなく無機質なプロセスです。
- Motion share は、ただのデータ交換という作業に、モーションという人間の直感的な操作を加える事で、「たのしさ」や「面白さ」が生まれると考えています。
- Motion share は、ただのデータ交換という作業に、モーションという人間の直感的な操作を加える事で、「たのしさ」や「面白さ」が生まれると考えています。
- 対象のユーザは、世界中のリストバンド型デバイス、スマートフォン所有者です。
- 基本となるモーションは3つあります。 握手・グータッチ・ハイタッチです。 それぞれ、写真・予定・連絡先を共有できます。 それでは３つある中のハイタッチの利用シーンについて動画でご説明します。
- 友達と楽しく遊んでいるシーンですね。 楽しい瞬間を残そうと写真を撮っています。 一人の彼は先に帰るみたいです。 写真を送ってもらう約束をしたようです 写真が送られてこないので、リクエストを 送っていますね。 遊んだ日の寝る前は楽しい時間を 振り返りたいですよね。 しかし、依然として送ってこられない写真。 楽しい思い出がちょっともやもや。 ではMotion Shareが変える世界を覗いてみましょう 先ほど同様写真を撮って、 Motion Shareなら撮ったらすぐ ハイタッチでShare リストバンド型端末でも、スマホでも 撮った写真をすぐ見れるので、 写真をみてまたそこで盛り上がれますね 楽しい写真は楽しいその場で Motion Shareはあらゆる場所で 利用が可能です。 さぁMotion Shareと出かけましょう。
- さきほどご紹介した３つのモーションのほかに…
- ユーザーがオリジナリティのあるモーションを作成する機能もあります。 上下左右やそれに対する斜め方向など、細かいモーションをパーツ化してそれを組み合わせてこの機能を実現させています。
- Motionによってデータが交換される仕組みを簡単にご紹介します。 送信者と受信者のモーションが同じタイミングで同じモーションがされた場合データ交換がされる仕組みです。
- 先ほどの動画にも有りましたように、スマートフォンによるハイタッチが不自然に見えたと思います。しかし、リストバンド型のウェアラブルデバイスを使えば、より自然なモーションでデータ交換を実現させます。
- そのウェアラブルデバイスですが、本プロジェクト史上初。 端末からの自作に我々は成功しました。 ARDUINOをベースに開発をすすめ、実際にモーションを行い、 正しくモーションを判別し利用可能な状態にまで開発を進めることができました。 開発した理由としてはiOSやAndroidなどのプラトフォームに縛られない 利用を目指して開発を進めてまいりました。
- 次にビジネスモデルの説明に移ります。 Motion Shareのビジネスモデルは 企業コラボ 専用端末の販売 課金モデル の三つです。 順にご紹介いたします。
- こちらがステークホルダー間で生じる主な要素の概要図です。 まずは提携企業と我々Motion Shareの間からご説明いたします。
- はじめに 提携企業からMotion Shareに契約料をお支払いいただきます。 そして提携企業と一緒に提携企業のご要望にあったモーションを我々が一緒に開発を進めます。 例えばアイドルグループとコラボした場合ですと、そのアイドルの曲のサビの振り付けをモーションにしたりといった 感じです。
- そして我々が提携企業とともに企画したイベントの運営を行い、 足を運んだユーザが提携企業と開発したオリジナルモーションを すると、ユーザは提携企業からオリジナルアイテム(モーションやクーポンなど) を獲得することができます。 先ほどのアイドルとのコラボを例にとりますと、ライブにいって サビの振り付けがオリジナルモーションになってますので、 オリジナルモーションをするとアイドルとの握手券が もらえたり限定待ち受けがもらえたりというアイテムが もらえます。 また、もらったアイテムがモーションだった場合 普段のデータ交換に利用することができ、そこでまた楽しさが生まれます 提携企業としては知名度の向上や新たな顧客の獲得が見込まれます。
- ２つめMotion Share専用端末の販売についてです 専用端末にはモーションを判別するセンサと、センサ値を スマートフォンに送信するためのデータ送受信モジュールが搭載されています。 他のウェアラブル端末よりも低価格で、スマートなデータ交換を可能にします。
- また177人の男女を対象とした独自のアンケートでは、リストバンド型デバイスが5000円未満だったら 購入したい層が52%いることがわかりました。 このアンケート結果から、5000円未満の価格設定と、専用端末の原価が3000円程度だったという ２点を踏まえ、先ほどの3980円という価格を設定しました。
- ３つめの課金モデルです。 先ほどご紹介したMotionの自作についてですが、 ユーザがモーションを作成できる枠は３つまでと決まっています。 ３つという枠のなかで作成と削除を繰り返す分には課金は必要ありませんが、 ４つ目にどうしてもモーションを作成したいというときは、１枠100円で購入して いただきます。 またMotionストアから提携企業が販売している モーションセットを購入して利用することも可能です。 イメージとしてはLINEのスタンプのようなイメージです。
- 収支予測です３年目から黒字になる計算です。
- 繰越利益です。３年目には1519万円ほどの利益が生じます。
- 工数はご覧の通りです。 *** 実装数(BC含め) HTML5/iOS/Android 29 専用端末 3 サーバ 12
- 開発秘話ですが、我々は人間の動きを扱うサービスですので、人間の動きを正しく判別しなければなりません。 しかし、なかなか判別が難しく、人それぞれハイタッチ一つとってもやりかが違うので 手探りでなんとかベストな判別値を設定しました。 そして集中開発日というものを週に一度設けていましたが、メンバーで集まって活動するのが 好きなメンバーが多く、フェイストゥーフェイスで開発を進めることができたので、 タスクの確認をしたり、開発で行き詰まったらフォローをもらったりとエンジニア同士で協力し合えたことが おおきな成功の要因だと考えています。
- モーションシェアはウェアラブル端末でもリストバンド型にこだわらず、IoT要素とグラス型や服、指輪などあらゆるウェアラブルコンテンツでの利用を展望として想定しています。 ですので、グラス型端末を装着して目線を移動させれば、目線を移動させた先にファイルを送信するなどといった時代を我々が作っていくかもしれません。 あなたが身につけているすべてのものはMotion Shareで利用できる可能性を秘めたアイテムなのです。
- 以上でMotion Shareの発表を終わります。
- これらから2つ目のサービス、RecoRecoのご紹介をいたします。 RecoRecoのコンセプトは「会話のドラマを記録します」となっています
- RecoRecoは、会話の思い出を文字で記録します。 日常やイベントなどのシーンで行った会話の思い出 を鮮明に思い出せるように、会話のドラマを記録するサービスです。
- そこでおききしたいのですが、みなさんは誰かと会話している際 「記録を取りたい」と思った場合はどのようにして 会話の記録を取っていますか？
- 方法はいくつかあると思います。 会話の記録を取る手段として、主流な方法で 手書きで記録とレコーダーで録音をする方法があります
- まず、手書きで記録を取る場合は 手間や時間がかかってしまいます。 また、会話を聞きのがしたり、書くのが間に合わなかったりして すべての発言を記録することは困難です つまり、鮮明に記録を取ることが出来ないといった欠点があります。
- また、レコーダーで録音した場合についてですが。 レコーダーは会話の内容をすべて記録することができますが、 2時間分記録した場合に、初めから聞き直す際はその分時間がかかってしまいます。 また、長時間の会話であればあるほど、特定の箇所だけを確認したいと思っても その箇所探し出すのは難しいです。 つまり、手軽に記録を振り返れないといった欠点があります。
- したがって 今ある手段では
- 手軽さや鮮明さが不十分といえます
- そこでRecoRecoは、会話の内容だけではなく 声の大小といった盛り上がりの変化や感情など、会話の雰囲気全体 つまり会話のドラマを記録することで
- 思い出を手軽かつ鮮明に思い出せるようにすることをコンセプトしました。
- 会話のドラマ、つまり人の感情や会話の盛り上がりを表現するために 話者の識別、感情の色分け、声のボリュームの3つの要素を 会話の書き起こしに加えています。
- ご覧のように、会話をただの文字として記録するのではなく、 話者や色・大きさの変化をつけることで、どのような会話が行われたかが鮮明にわかります。 また、文字に書き起こされてることで、自分のペースで読める手軽さがあります。
- では、これからRecoRecoをどのように使うか、 日常での会話シーンを例に取った紹介ムービーを御覧いただきたいと思います。 本だーびすを使用して会話の記録を取る場合，必要なのは会話のルームをアプリ上で立ち上げ、 会話メンバーとの会話を記録します。 また、思い出を振り返るしーんですがとても簡単で、一覧から振り返りたい記録を選択するだけで思い出を振り返る子tができます。
- なぜ会話のドラマを記録し、表現するために 話者・感情の色分け・声のボリュームの3要素が必要なのか これらの理由について説明していきます
- まず話者情報についてです。 会話において「誰が話したか」と言うのは会話の内容に並んで重要な要素といえます 誰がその発言をしたかによっては、会話の状況が変わってくる場合もあります。
- つまり、誰がその発言をしたかわからないと情景が伝わらないため、 話者情報は思い出の記録として不可欠なものと言えます
- 次に、声のボリュームについてです 小さい声で言った場合と、大きい声で言った場合では 同じ発言、例えば「申し訳ありません」という言葉でも 場の雰囲気や話者の感情が異なってきます。
- そのため、声のボリュームも会話のドラマを記録するために必要な要素といえます。
- 最後に、感情の色分けについてです 左の黒い「大好きだよ」と、右のピンクの「大好きだよ」では どちらの「大好きだよ」という言葉により愛情を感じ取れることが出来るでしょうか。 一般的により右のピンクのほうが感じ取れるといえます。
- つまり、文字に色付けを行うことで読んだ際に より鮮明に感情を連想できるようになります
- 以上の理由より、これら3つの要素を一般的な書き起こしに加えることで RecoRecoは会話のドラマを記録しています。
- 続いて、ビジネスモデルの説明に移ります。 RecoRecoの主なビジネスモデルは、フリーミアムモデルと仲介取引モデルの2つを想定しています。
- 仲介取引モデルでは、 お笑い芸人や俳優など芸能人の書き起こしを他のユーザに 有料で販売することにより収益を得ます。
- まず一般ユーザは 運営に一定の月額料金を支払います
- そうすることにより一般ユーザは 有名人が本サービスを使用して書き起こした会話を閲覧できるようになります。 会話は、有名人が楽屋で行っている日常会話やネタ作り中の会話など、 普段目にすることのないRecoRecoだからこそ取れる記録です。
- 会話の記録を提供する有名人には、 運営が一般ユーザの課金によって得た収益の一部を分配します。 有名人は、会話の記録を提供することによって利益を得ることができます。
- 続いて、フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こしは30分行うことができます。 このチケットは、ログインボーナスによって無料で入手することもできます。 しかし, 長時間または頻繁に書き起こしを希望するユーザは ・チケット6枚、3時間分を100円で購入もしくは ・月に540円払うことで書き起こしの制限を解除することができます
- この2つのモデルによる収益と、 設備投資などにかかる支出を元に試算を行った収支計画がこちらです。 3年目にはおよそ5500万円の利益を出せます。
- 開発工数は、このようになっています HTML5とAndroidは、見積もり工数より実働工数が少なくなっています。 それに対してサーバでは、見積もり工数より実働工数が多くなっています。 サーバの実働工数が見積もりより多くなった原因としては、 後ほど紹介致しますAPIの競合問題や HTML5やAndroidの通信連携を手伝うことが多かったからだと考えられます。 このような問題について開発秘話としてお話ししようと思います。 *** 実装数(BC含め) HTML5：3/3 Android：3/3 サーバ：5/5
- RecoRecoの開発秘話としてはまず、 Android・HTML5で発生したAPIの競合問題があります。 こちらは先程開発工数のときに申し上げた、サーバの実働工数が多くなった原因の1つです。 この問題は、スマートフォンで音声認識を行うAPIと音声の録音を行うAPIがあり これらを実装して同時に実行しようとした時に競合が起きて、プログラムが実行できないというものでした。 これにより、アプリケーションの設計をやりなおしたり、 主にサーバが開発を追加で行う必要がでてしまいました。 この問題に対しては、解決した方法の1つとして HTML5班のメンバーがサーバ班の開発の手助けを行うことで進捗を取り戻すことができました。 続いて、「気づいたときには法政大にいるサービスリーダー」についてです これは、RecoRecoのサービスリーダーは未来大の学生ですが、 インターンシップやその他の私用で東京を訪れた際に HTML5班がいる法政大を「度々」訪れては、開発を行っていたというものです。 そのおかげで、進捗の遅れを取り戻すこともできました。 以上で開発秘話の紹介を終わります
- 最後に、展望に着いてです。 RecoRecoの展望は、写真や動画に並ぶ 新たな思い出の記録形態となることです。 写真は写真、動画は動画、そしてRecoRecoはRecoRecoの良さを生かし 思い出を記録に残そうという時に「RecoReco」 という方法が広まることを展望としています。
- サービス３つめ、リバイブシートについて紹介します。
- 突然ですが、デッドスペースというものをご存知でしょうか？ この写真の中にもデッドスペースがあるのですが、わかるでしょうか？
- そうです。 このように4人席の余った3席のような利用できない空間のことをデッドスペースと呼びます。 私たちはこのデッドスペースを有効活用するサービスを開発してきました。
- Revive Seatとは、簡潔に言いますと、カフェのデッドスペースを用いて、カフェに座りたい人と席を余らせている人をマッチングさせるサービスとなっています。
- しかし、そもそも本当にカフェに座りたいのに座れない人はいるのかという問題があります。 これは、私たちが独自に１０～２０代の若者にアンケート調査をした結果です。 この約７０％とという数字から、まあ、２３２件という少ない母数かもしれませんが、 混雑時に席がなかったためあきらめたことがある若者はほぼ確実にいると思われます。
- また、実際にカフェにどのくらいデッドスペースがあるのかについてですが、こちらも私たちは調査してきました。結果として平均的な値ですが都内カフェチェーンでは 満席時に平均に全席数の２０％ほどの席がデッドスペースになっていることが予測されました。５０席あるとしたら１０席がデッドスペースになっているということです・ 一見少ないように見えますが、店舗数や顧客の回転数を考えると２０％というのは大きな数字だと思います。これら、二つのスライドの問題を整理すると、
- このように整理することができます。 座れるはずの席が余っているのに、座ることができずに諦めるお客さんがいるということになります。 この問題はあまっている席に座りたい人が座ることができれば解決します。 この考えをもとに私たちはRevive Seatの開発を始めました。次は、本サービスの詳しい説明ついてお名無しします。
- RiviveSeatとは率直に言うと席のシェアリングエコノミーサービスです。 席をあまらせている人と 席を求めている人を価値の設定、提供によってシェアしてつなげるサービスです。 私たちはこの席を余らせている人をホスト 求めている人をゲストと呼んでいます。
- ホストユーザは、シェアする席の設定をアプリ内で行いシェアの登録をします。 具体的には、タイトル、時間、求める価値などを設定します。 登録後は、ゲストユーザの参加を待つのみです。
- また、ゲストユーザ側の参加機能では、ホストユーザが登録したシェア情報の中から自分に合った席を見つけることができます。 シェアの相手が見つかった場合は画面のっ説明にそってシェアを開始することができます。
- これは本サービスの流れの一例です。 まず、ホストユーザがシェアの設定をおこない、参加者を募集します。ゲストユーザはアプリによって自分に合った席をさがします。 ホストが求める価値とゲストが提供できる価値がマッチングした時にシェアが開始されます。 Revive Seatではこのようなシェアリングがすべてのデッドスペースで行われることを想定しています。 今回は充電器でしたが、コーヒー、ポケットWi-Fiの貸し借りなど自分に合った価値の設定、ゲスト側であれば自分に合った席を探すことができます。 実際の流れのデモムービーをご用意したので是非ご覧ください
- こちらは実際に本サービスが使用されることを想定して作成しています。 ホストが価値を設定し、ゲストがその価値を提供し、シェアが開始される流れです。 マッチング後は双方ともに画面に沿って進んでいくことで、シェアを開始することができます。 今回は２人席で、コーヒー一杯が価値として設定され、シェアが行われています。 （終了後）これが一連の流れとなっています。
- 次にビジネスモデルの説明に入りますが、本サービスの メインターゲットは「大学生・サラリーマン」となっています。 メインターゲットとしてまず大学生を設定した理由としては、私たちが大学生なのでユーザの想定がしやすいことです。また、価値の設定とその提供や、空いている席を必要としている頻度などを考え、大学生がホストユーザとなったときにゲストユーザとして適しているのがサラリーマンの人々があっていると想定し設定しました。
- それぞれの関係はこのようになっています。 本サービスは出来高制の１本で考えています。 運営はユーザにデッドスペースを提供します。 ユーザはこのサービスを利用してデッドスペースに座る前に商品を購入します。 カフェは運営対してにこのサービスを利用して購入された金額の10%を仲介料として、支払います。
- 前のスライドでせつめいした出来高制とは私たちが行った都内カフェチェーンのデッドスペースの状況や学生アンケートから利用ユーザを予測しました。 また、それらをもとに月間収入を予測した結果。
- 本サービスではこのように３年目以降に利益をだすことができると考えています。 これでビジネスモデルの説明を終わります。
- Revive Seatの開発工数はこのようになっています。開発面で技術的に詰まることは少なかったため、全体的に想定していた開発工数よりも実働はかなり少なくなっています。Androidではサーバーとの通信の開発でつまずきかなりの時間を使いました。また、サーバ側の開発工数に関してですが、バグの処理や通信方法の変更、安定した通信をするための変更などをバックログで管理していなかったため、記録していた実働工数は少なく出てしまっています。 このように本サービスでは開発の管理に関して少し至らない部分がありました。最後に展望に入る前に、このよう開発内で起こった問題を開発秘話として説明いたします。
- まず、本サービスは３サービスの中で最もスプリントバックログを使いこなせていなかったと感じています。理由としては１stsプリントで作成したスプリントバックログの完成度が低いかつ２ndで用意した新たなドキュメントの方がチームメンバー的に使いやすく、それ以降うまく生かすことができませんでした。これについては勉強、経験が不を苦から生まれました。また、サービスリーダーが仕事を抱え込みやすかったため、途中進捗がなかなか生まれない時期がありました。後半この問題についてサービス内で話し合うことで少しは解消できたように思います。最後に、実はこのサービス最初はセンサーを使って空席を管理する予定でした。しかし、サービスの展開速度や必要性などを考えて開発をやめました。しかし、もし開発していたら技術的には今よりも成長できたかもしれないので成長の機会を逃した可能性あるとも取れます。このほかにも細かいトラブルがたくさんありましたが、何とか開発目標を達成することはできました。最後にこのサービスの展望について話します。
- 本サービスの展望としては一定のユーザー獲得後はサービス内で集まった情報をもとにサービスの満足度を向上させること。また、現状ではホストユーザーがシェア登録するときに価値を設定するのですが、その逆であるゲストユーザーからどんな価値を提供するのかをあらかじめ設定することもできるようにしたいと考えています。以上でRevive Seatの発表を終わります。
- それでは第1回合同合宿で決定し我々が企画・開発してきた3サービスをご紹介します
- プロジェクトの目的に対して，その成果を発表します． １つめの目的，「数年後〜開発」については，これまで紹介してきたご覧の３サービスについて企画・開発を行うことで達成しました． ２つめの目的，「ビジネスモデル〜学ぶ」については，各サービスについてビジネスモデル文書を作成することで達成しました．
- プロジェクトの目的に対して，その成果を発表します． １つめの目的，「数年後〜開発」については，これまで紹介してきたご覧の３サービスについて企画・開発を行うことで達成しました． ２つめの目的，「ビジネスモデル〜学ぶ」については，各サービスについてビジネスモデル文書を作成することで達成しました．
- プロジェクトの目的に対して，その成果を発表します． １つめの目的，「数年後〜開発」については，これまで紹介してきたご覧の３サービスについて企画・開発を行うことで達成しました． ２つめの目的，「ビジネスモデル〜学ぶ」については，各サービスについてビジネスモデル文書を作成することで達成しました．
- 【OBOG報告会】 本プロジェクトを運営するにあたり、以下の方々に多くの助言を賜りました。 ここに深甚なる謝意を表します。 1年間ありがとうございました。
- 【HP企業報告会】 本プロジェクトを運営するにあたり、以下の方々に多くの助言を賜りました。 ここに深甚なる謝意を表します。 1年間ありがとうございました。
- 【PS企業報告会】 本プロジェクトを運営するにあたり、以下の方々に多くの助言を賜りました。 ここに深甚なる謝意を表します。 1年間ありがとうございました。
- 【PS】 本日はご覧の流れで報告会を行います. まずはミライケータイ全体や各サービスの概要などについてご説明し, その後各サービスについて発生した問題や今後の展望も含めた詳細なご説明をさせていただきます. その後，企画開発を行ってきたMotion Share / Revive Seatのデモ実演を行います
- 開発時の各校の役割についてですが、未来大はhtml5・android・iosとサーバ。この全てを担当しました。 神奈川工科大学はそのうち、html5とandroid。 法政大学は、html5・androidに加えてサーバを担当しました。
- 続いて，サービス決定までのプロセスを説明します． なおこれは，未来大でのプロセスです． 未来大では、メンバー全員 合わせて、360 もあるアイディアの中から、結合とブラッシュアップを重ねて12個まで絞り込みました。 そのアプリのアイディアをもとに，サービスを企画し，プレゼンを行いました． そして多数決によって，４案に絞りこみました。
- そして，４案一つ一つのアイディアに対してビジネスモデルを考えました。 最終的に、プレゼンを見てアイディアを評価し、未来大として2案が決定しました。
- 初日は，各大学が事前に考えてきたサービスのプレゼンを行いました。 その後、サービス別に4大学混合のグループを編成して議論を行いました。 議論には企業・OBの方々にもアドバイザーとして参加して頂きながら、ブラッシュアップを行い、実現したいサービスについて内容を固めていきました。
- ２日目は、サービス別で議論した内容をプレゼンしました。 プレゼン後は、内容を評価し、多数決によって、、、、
- 複数のチームを作り，各自で考えたアイディアを持ち寄って，ビジネスモデルの再検討やアイディアの結合とブラッシュアップいました．
- 複数のチームを作り，各自で考えたアイディアを持ち寄って，ビジネスモデルの再検討やアイディアの結合とブラッシュアップいました．
- デモンストレーションから戴いたフィードバックをベースにして、機能の見直しと新機能を検討し、3rdスプリントプランニングを行いました。
- 発生した問題の１つめは、開発の進捗で大幅な遅れが生じたということです。この問題を解決するためにまず、進捗が最もいいサービスとその他のサービスの状態を比較しました．その結果、スプリントバックログに大きな差があることが判明しました。
- 進捗の良いサービスのスプリントバックログは、実装方法が具体的に記されていました．しかし、その他のサービスは実装方法が抽象的で、中にはタスク分担がされていないものも有りました。
- こちらは実際のスプリントバックログに記された ”いち機能”についてです。 見ての通り、進捗の良いサービスとその他のサービスとで内容量が全然違うことがわかると思います。
- スプリントバックログの質に差があることが判明したため、早急にスプリントバックログに記載されている実装方法を具体化する作業に取り掛かりました。また、進捗に大きな遅れが生じていたため、各サービス、週に１回の集中開発日を設けました
- ２つめの問題は「メンバーが全てのプラットフォームの開発進捗を把握できていない」ということです。 進捗がいいプラットフォームの開発状況に注目しすぎて，進捗の悪いプラットフォームの状況を詳細に把握できていませんでした。 気づいたとしても、週に一度あるビデオ会議のときに気付くため、どんどん進捗が悪化するということがありました。 この問題を解決するために、わたしたちは、リアルタイムに進捗を把握できる仕組みづくりを検討しました。
- その仕組とは、ソースコードのバージョン管理ツールであるgithubとコミュニケーションツールであるSlackを連携させることです。 この仕組を導入したことで、開発に進捗があれば各メンバーに自動で通知が行くようになりました。また、タスクを終わらせたときは、早急にスプリントバックログを更新することを徹底しました。
- 開発の進捗がどのように通知されるのか…
- この仕組によって、リアルタイムに開発の進捗をメンバー全員が把握することが出来るようになるとともに、進捗の遅れに素早く対応出来るようになりました。 そして、進捗の遅れが技術的問題であった場合は、メンバー全員でその問題の解決に取り組みました。
- 問題の3つ目は、ビジネスモデルの検討不足です。 理系3大学は開発タスクのために、ビジネスモデルの考案に携わる機会が少なく、少ない人数のビジネスモデル班に任せっきりになっていました。さらにプロジェクトは終盤であるため、早急に現状のビジネスモデルの見直しを行う必要がありました。 問題の４つ目は、遠隔地間のプロジェクト活動であるがために、現状で形になっているアプリケーションを他のサービスメンバーや他大学メンバーに実際に触ってもらってフィードバックを得る機会がなかったということです。
- 開発メンバーは実際にアプリを触ってもらい、そこでのフィードバックをベースにしてもっと良いアプリケーションにしていきたい。しかし、機会がない。ビジネスモデルチームは、新しいアイディアが欲しい。ブラッシュアップしたい、だけど、プロジェクト終盤で時間がなく開発メンバー大忙しの状態で頼りたくても頼れない。 この2つの問題を解決するために、F2Fの機会を設ける事を検討し……
- ビジネスモデルの再検討は、サービスにとって良いビジネスモデルとは何かを定義した後に行いました．そもそもサービスにとって良い、というのは、サービスの未来をよくする、つまりサービスにどうなって欲しいのかということを考える必要がありました．考えた結果，どのサービスも自分たちのサービスをたくさんの人に触れてもらうことがサービスにとって良いことだとした．たくさんの人に触れてもらうためには，まずはユーザ数を増やすことが必要である．結論として，良いビジネスモデルとはユーザ数を増やすことと定義しました．この定義に沿って，ビジネスモデルを再検討しました．
- 問題点は大きく２つありました。一つは、仕様の共有不足。もう一つはそれぞれの仕様書の位置づけが明確になっていないということです。 細かい仕様を仕様書に書き下ろすことができていなかったため、チーム内で仕様を共有できず、そのまま実装フェーズに移行したため、実装方法に違いが発生したり、仕様書の位置づけが決まっていなかったため、仕様書をどうやって使っていいか分からないということがありました。 以上2つの昨年度の問題点を考慮した上で、わたしたちは仕様書の内容・位置づけの検討を行いまいした。
- サービス企画書では、仕様の共有不足を防止するために、サービスの全体像を分かりやすく相手に伝えるために考えておくべき項目を網羅することで、メンバー間で認識を統一すとともに、この仕様書だけでサービスの全体像が把握できるようにしました。 この仕様書の位置づけは、企画を外部の方々にプレゼンすことを想定し、”通る”企画書を実現させるために必要な情報を記載する事を心がけました。
- アプリケーション設計書では、仕様の共有不足を防止するためにたくさんある実装部分をこの仕様書を見れば誰でも担当できる仕様書づくりを心がけました。また、アプリケーションの具体的なイメージを統一するためにワイヤーフレームもこの仕様書に含めました。 この仕様書の位置づけは、私たちがアプリケーションを開発するうえで，イメージの意識統一のためだけでなく，開発時に大きなトラブルが発生することを防ぐためのドキュメントである．
- 実装数(BC含め) HTML5/iOS/Android 29 専用端末 3 サーバ 12
- 実装数(BC含め) HTML5：3/3 Android：3/3 サーバ：5/5
- 開発で苦労した点として モーションの仕方の差異による誤判別です。 ハイタッチ一つとってもひとそれぞれやり方が違うので、 センサ値を手探りで調整し、いろいろな方のモーションを網羅できるように することに一番苦労しました。
- サーバは、取得した情報が一致しているか判別を行い、一致していれば、送信者に送信許可を送ります。 許可を受け取っ
- 専用端末の開発にかかる原価と先ほどのアンケート結果を踏まえ、3980円という値段設定としました。 また3980円という端数はニコラスゲガンの法則に基づいて端数を決定しています。
- Motion Shareはリストバンド型デバイスでの利用をファーストに考案された サービスですが、今日ではまだまだリストバンド型デバイス含む ウェアラブルデバイスの普及率はスマートフォンよりも低いのが現場です。 そこで我々はスマートフォンでの利用も可能とし、 今後の需要予測から専用端末の販売をビジネスモデルに組み込むことに しました。
- 録音は手軽ではないという問題点は 録音した音声を音声認識によって文章に書き起こすことで解決出来ます。 既存のサービスでも、録音されたものを文章に書き起こすものはいくつかあります。 しかし、ただ文章に書き起こしただけでは、 誰が発言したか、声量は大きかったのか小さかったのかなど 会話中の盛り上がりや人の感情などと言った、会話のドラマがわかりません。
- 一般ユーザや有名人ユーザ数の推移 フリーミアム及び仲介取引による収益 人件費やサーバ費などを考慮して計算した結果、このようになります。 2年目の上半期から利益が発生する見通しとなっています。
- 録音は手軽ではないという問題点は 録音した音声を音声認識によって文章に書き起こすことで解決出来ます。 既存のサービスでも、録音されたものを文章に書き起こすものはいくつかあります。 しかし、ただ文章に書き起こしただけでは、 誰が発言したか、声量は大きかったのか小さかったのかなど 会話中の盛り上がりや人の感情などと言った、会話のドラマがわかりません。
- RecoRecoの実装にあたり、 書き起こしを行う音声認識と、話者の識別を行う話者認識 これら2つの処理に関しては、技術力や時間、効率などを考慮してAPIを使用しました。 音声認識では、IBMのSpeech to Textを使用しました。 端末から送られてきた音声ファイルを元に音声認識を行って文章に書き起こします。 話者識別では、MicrosoftのSpeaker Recognitionを使用しました。 同じく音声ファイルを元に話者識別を行い、発言したユーザの特定を行います。
- 感情の色分けと声量の変化については、APIを用いずにプログラムを組んでいます。 感情の色分けは、あらかじめ感情を表現する単語と対応する色の組み合わせを データベースに登録しています。 書き起こされた文章中に、データベースに登録されている単語がある場合は その単語を対応する色に色付けします。 声量の変化は、音声ファイルをバイナリとして読み込み、解析して音量を取得します。 音量の大きさによって条件付けをして、フォントサイズを決定します。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- 続いて、課金/フリーミアムモデルについてです。 RecoRecoで書き起こしを行う際にはチケットが1枚必要となります. チケット1枚で書き起こし時間は30分です。 ユーザは、ログインボーナスによって無料でチケットを増やすことができます。 しかし, 長時間または頻繁に書き起こしを希望するユーザには ・100円で6枚チケットを購入もしくは ・月に540円払うことで制限解除を行うことが出来ます。
- Revive Seatというサービスは２度大きく変化してきました。まず、１度目は、サービス開発初期のサービス構想段階です。もともとはZaSpaceとして発案されていたのですが、男女の出会いという目的はユーザーを限定してしまう、カフェのイメージの低下につながる可能性があるということで考え直しました。そこで生まれたのがRevive Seatです。コンセプト、サービス内容に合わせてサービス名も変更しました。男女の出会いではなくコミュニケーションをとることを目的としたシェアリングサービスです。しかし、コミュニケーションとシェアリングによるマッチングからいまだ男女の出会い要素が大きいのではないかということで、再度シェアの仕方を検討し現状のRevive Seatになりました。それでは、先ほどの動画よりもより詳しく本サービスについてご説明させていただきます。
- Revive Seatというサービスは２度大きく変化してきました。まず、１度目は、サービス開発初期のサービス構想段階です。もともとはZaSpaceとして発案されていたのですが、男女の出会いという目的はユーザーを限定してしまう、カフェのイメージの低下につながる可能性があるということで考え直しました。そこで生まれたのがRevive Seatです。コンセプト、サービス内容に合わせてサービス名も変更しました。男女の出会いではなくコミュニケーションをとることを目的としたシェアリングサービスです。しかし、コミュニケーションとシェアリングによるマッチングからいまだ男女の出会い要素が大きいのではないかということで、再度シェアの仕方を検討し現状のRevive Seatになりました。それでは、先ほどの動画よりもより詳しく本サービスについてご説明させていただきます。
- Revive Seatというサービスは２度大きく変化してきました。まず、１度目は、サービス開発初期のサービス構想段階です。もともとはZaSpaceとして発案されていたのですが、男女の出会いという目的はユーザーを限定してしまう、カフェのイメージの低下につながる可能性があるということで考え直しました。そこで生まれたのがRevive Seatです。コンセプト、サービス内容に合わせてサービス名も変更しました。男女の出会いではなくコミュニケーションをとることを目的としたシェアリングサービスです。しかし、コミュニケーションとシェアリングによるマッチングからいまだ男女の出会い要素が大きいのではないかということで、再度シェアの仕方を検討し現状のRevive Seatになりました。それでは、先ほどの動画よりもより詳しく本サービスについてご説明させていただきます。
- Revive Seatというサービスは２度大きく変化してきました。まず、１度目は、サービス開発初期のサービス構想段階です。もともとはZaSpaceとして発案されていたのですが、男女の出会いという目的はユーザーを限定してしまう、カフェのイメージの低下につながる可能性があるということで考え直しました。そこで生まれたのがRevive Seatです。コンセプト、サービス内容に合わせてサービス名も変更しました。男女の出会いではなくコミュニケーションをとることを目的としたシェアリングサービスです。しかし、コミュニケーションとシェアリングによるマッチングからいまだ男女の出会い要素が大きいのではないかということで、再度シェアの仕方を検討し現状のRevive Seatになりました。それでは、先ほどの動画よりもより詳しく本サービスについてご説明させていただきます。
- こちらは、本サービスで想定される通常のサービスの流れです。 まず、座っている人について説明します。 座っている人はRevive Seatを使って座りたい人を募集します。 募集すると言ってもただ募集するだけではありません。 モバイルバッテリーが借りたいとか、コーヒーが一杯ほしい、 話し相手が欲しい。例えば、野球の話がしたいといった様々な価値を設定して募集できます。 続いて、座りたい人について説明します。 座りたい人はRevie Seatを使って募集されている席を探します。 自分にあった席が見つかったら実際の店舗へ訪れます。その後、設定された価値を提供することで席に座ることができます。 このようにしてカフェに座りたい人と座っている人をマッチングさせます。
- Revive Seatのミライ感は「日本のシェアリングエコノミーを推進」することです。 シェアリングエコノミー・・・物・サービス・場所などを、多くの人と共有・交換して利用する社会的な仕組み。
- 運営の収入としては出来高制
- それぞれの関係はこのようになっています。 運営はユーザにデッドスペースやクーポンを提供します。 ユーザはこのサービスを利用してカフェに訪れる時に商品を購入します。 カフェは運営にこのサービスを利用して購入された金額の10%を仲介料として、支払います。 以上でRevive Seatの説明は終了です。
- ①人件費 ・社長＋従業員７名 (24,600,000円 /年） ②広告費 ・店舗にステッカーを配布 （約1,800,000円/年） ・インターネット広告 （約480,000円/年） ③サーバ費 １年目：100GBのサーバを利用 （145,347円/年) ２年目：250GBのサーバを利用 (194,811円/年) ④テナント賃貸料・光熱費 ・テナント賃貸料 (120,000円/年) ・光熱費 (592,800円/年) ⑤リリース前支出 ・機材費、雑費 (2,100,000 円) ・開発費 (1,000,000円 )