INDEX of This Page
- 1 Appタイトル命名『源 -minamoto-』 源頼朝公、資源を活かす!をテーマに
- 2 私の結論|3つの狙い
Appタイトル命名『源 -minamoto-』
源頼朝公、資源を活かす!をテーマに
余談ですが…。
サービス運用のためのプラットフォームの構成に至った背景を下記に記載します。
この構成の発案には、チーム事情がキッカケだった
プログラマーにお子様が誕生されたため、応募締切前での開発リソースの確保が困難となった。急遽、自分で開発するも実装エラーが続く…。
もともとLINE-Message-APIにおけるLINE-Botの仕様の理解不足が根底にありました。「実装やソースコードの理解に時間を奪われて、だんだん企画や資料をまとめる時間が奪われていく」⇒「あれ?なんで動かないんだろう」⇒「こういうことできたらいいのに、できないのかな?」の繰り返しです。
この窮地となった状況でhachidoriの存在を教わり、この仕組みでBot構築できるシステム構成に大きなメリットを感じて、何処までできるのだろうか?という期待がおります。 開発での悩みが減ったことで、次はhachidoriの仕様を理解するのに丸2日かけて、ようやく企画を実装することをスタートし始めました。
一方で、9/28にLINE様が開催された「BOOT AWARDS直前!秋のBot開発者大LT祭り!」で高校生の発表を拝聴しました。 Google Apps ScriptとLINE bot連携して「時間割アプリ」を開発したことを知たことを学んでおりました。 「GAS」との連携で「Googleカレンダー」との連携ができないだろうか?
※実装する時間がなく、Bot(hachidori主体)でのノンプログラミング開発に計画変更 hachidroiでまずやってみよう!!!
冷静に考えてみると、これは“ピンチはチャンス!”の感覚だったのです。
つまり・・・。 「観光App企画を、自分で開発できれば救われるのになぁ!と思っている私の状況。 これって自治体や商店街、個人事業主、DMOの方々にとっても同じではないか?観光Appでの成功フローに使えるのではないだろうか?」 ユーザーが馴染みやすいLINEやGoogle Appを主力のプラットフォームとし、hachidoriで連携させる。
運用側の自治体、DMO、個人商店街の発信したい情報を、グループで発信できる。 これまでの観光Appといえば、自治体や法人では、数百万円~単位の開発経費がかかり費用対効果に合わないケースも多いです。
それとステークホルダーと、運営当事者が多数参加して作り上げる方が地方創生に繋がりやすい! と考えております。 ノンプログラミング概念でやるからこそ!の挑戦の先には…。 プログラミングができない自治体や商店街、個人事業主でも導入しやすい! 導入障壁を壊すことが、後のマネタイズやブランディングに繋がるはずだ! サービスモデルとしても、自治体やDMO、個人事業主の悩みは私と同じ方も多いはず。 「プログラミングができないからなぁ~。開発費はコスト高になるしなぁ」 「初期投資が高くなるほど、回収できるか?が怖くなる。特に観光はマネタイズが難しい」 GUIでやる上でhachidoriの仕様を覚える必要があります。 しかし、これをビジネス化するのであれば、観光サービスとしえテンプレート化をすれば良いかと思います。 操作性や導入障壁への発想の意識が高まりました。
参考資料:鎌倉草創塾様 平成25年度研究成果報告書
下記は資料引用より、図表のみを抜粋させていただき、赤枠記載は私が引用元からの学びメモでございます。 企画の参考とさせていただきました。
(課題2)ステークホルダーを探る
(補足)観光Appの利用課題を探る
(注意)下記は引用元は存在致しません。私の勝手な推測で列挙した資料でございます。
私の結論|3つの狙い
Bot App を観光Appにする
交通調査、観光客アンケート
アナログに調査員を雇ったり、母数が少ないデータを「〇%」と表記するのも大変。 しかし、BotやGoogleフォームでこの調査の実行しやすくします。
プロフィール(個性)や趣味嗜好、チーム構成、当日の状況などからBetterなスポット検出したい目的があります。
サービス普及や運用を視野に入れたプラットフォーム構成
運用側の導入障壁を下げる プラットフォームの構成。 かつ、ユーザーも慣れている“LINE”や”Google”だと普及しやすい。 さらにプログラムせずに構築できれば尚良し!だから“hachidori”!
LINE + hachidori + API + OpenData
この構成は、観光集客を考える商店街や個人事業主、自治体には運営関係者には大きなメリットがあります。hachidoriを主軸に開発することは、運営側が安価にテストリリースまで準備できることを可能にします。
私が考える観光アプリの成功とは? (ステークホルダーである)「皆が利用してこそ…。」
⇒導入障壁を如何にして下げられるか?
- ステークホルダーの各関係者が運用に参加できること
- 上記、参加のためには、UIや操作がわかりやすいこと
- 初期導入コストを安価にすること
- もっというと、運用コストや機能拡張開発コストも少額であること
ステークホルダーが自身の得意領域でに注力すること!が重要だと考える
- 自治体はAppの宣伝告知に注力する。
- 商店は、自分のサービス向上に注力する。
自分たちの業務や営業で手一杯な状況下で、個々が自由なタイミングで運営に参加し、手慣れたツールを活用できれば運営側にとってのストレスも減るのではないだろうか?
グループトークであれば、手軽さ!情報伝達が速く!そして操作が難しくない!
このシステム構成のウリは、開発プログラマーに依存しなくても、自分たちで構築できるメリットがあります。 つまり、導入障壁を下げることができます!
運営側は、BotやGoogle Apps にて更新する
下記は、あくまで誇張したイメージです。 実際は、ユーザーがスマホで、GoogleカレンダーやLINEでのpush通知を受け取るイメージです。
またAPIやOpenDataを活用することで、ユーザーも情報の一元管理が可能
上記に加えて、 hachidoriでLIFFやAIを使えたら尚良いのになぁと思いながら、
- 翻訳機能 => インバウンド観光に対しても宣伝しやすい
- LINEpayやPaypal => 鎌倉市の課題である1人あたりの消費額にも貢献
今回は、ノンプログラミング概念での挑戦としております。
当ページの内容は、【本題1】サービス普及や運用を視野に入れたプラットフォーム構成の続きとなります。
App目標=『鎌倉ツアーコンシェルジュ』
このAppでは、ユーザーの散策満足の向上を目指します。 プラン的には、同行する人数や友達、ぺルソナや趣味嗜好、気候や交通状況、アクシデントまで多岐の要素からBetterな計画を提案できればと考えますが、多種多様な人間の個性に応えるには千差万別です。現況ではAIは活用しない状態でのチャレンジとなります。 今回はその多様な人間に対して、王道ルート以外の情報を一元管理でお届けられる!の挑戦となります。
『【参考2】アプリでの解決策を考える』に明示したとおり下記の3つです。
API連携
リッチメニューボタン別にご紹介
今回は、hachidori(今のところフリープラン)のシナリオで可能な限りが基本となります。
スケジュール
地図と路線
スポットガイド
狙い2の実現は、今回は王道ルート以外の散策スポットをご紹介することで、混雑回避を図ることで課題解決とします。 ノンプログラミングの限界がありますが、hachidoriライブラリーでの表示を一旦、試みます。もしくは別途、スポット情報のjsonでGoogle地図上にプロットしたWEBサイトを読み込ませる対応に致します。 将来的にhachidoriさんに機能強化いただければ、個人プロフィールに応じた趣味嗜好に合わせた本格的な返答実現できる日がくるかもしれません。
狙い3の実現は、体験スポットの表示、返答がでれきばという状況となります。
天気API表示
設定
散策者のプロフィールや趣味嗜好にマッチングするスポット結果を返答する場合はプログラミングが必要となりますが、hachidoriのライブラリ機能でどこまでの表示が可能かになります。Google Appsとhachirodiの連携は可能な時間を見て挑戦したいと考えております。