プロジェクト報告書（最終） Project Final Report

提出日 (Date) 2021/01/14

ビーコン IoT で函館のまちをハックする-Beacon FUN 4

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter
Life1

プロジェクト概要

1.1

背景石澤大輔

宮田悠冶

Ishizawa Daisuke

Miyata Yuya
得することが可能になる．BLE ビーコンには Apple 社が提供する iBeacon，LINE 社が提供する LINE Beacon など様々な規格がある．iBeacon は，距離測定や領域内の入出の監視など

函館市は観光資源にあふれた観光都市である．この多様なを行うことができる．LINE Beacon は，コミュニケーション

観光資源をより多くの人に伝えるためにも，多角的に魅力を発

アプリ LINE がインストールされているスマートフォンに対信し，磨きをかけていく必要がある [1]．

して，広告やプッシュ通知を送信することができる [5]．

近年，通信技術の向上や通信機器の小型化・低コスト化のため IoT が普及している [2]．IoT デバイスの 1 つとして BLEビーコンがある．BLE ビーコンとは，低消費電力の近距離無線技術「Bluetooth Low Energy」（BLE）利用したデバイス

1.4

プロジェクト体制

1.4.1

週替わりのファシリテーター制度のことである．スマートフォンなど BLE 対応デバイスを所持

プロジェクト活動全体として，特定の人へのタスクの偏りしていれば，誰でも利用可能である．BLE ビーコンを利用しを減らすためにプロジェクトリーダーの役割を作らずに活動たサービスとして，スマートフォンと自動販売機を接続してドした．これにより，進行を務める人がいなかったためグループリンクを購入することでお得にドリンクを入手することができごとでの開発に入るまでは，週替わりのファシリテーター制度る「Coke On」などが存在する [3]．ほかにも様々なサービスを用いて活動した．1 週間に 2 人ずつファシリテーターを任命やアプリケーションが創出されている．そして，今後もその数し，その 2 人が 1 週間で何をどのように進めるかを決めるよは増加していくと考えられる．それに伴い，需要も高まっていうにした．

くと期待できる．

1.4.2

1.2

目的

大臣制度

グループごとの開発に入ってからは，大臣制度を用いて活本プロジェクトの目的は，ビーコンを用いて函館のまちの動した．週替わりのファシリテーター制度での，当事者意識の様々な魅力や新たな価値を生み出すことである．ビーコンの特欠落やタスクの偏りなどの問題点を解消するために導入した．

徴を活かしつつ，函館の魅力をさらに引き出せるようなサービ

大臣制度では，後期以降必要になると思われるタスクを洗い出スを考案する．

し，各タスクに対して担当する人を 1 人から 3 人任命した．

1.3

ビーコンについて

1.5

プロジェクト内における意思決定

BLE ビーコンとは，BLE に準拠した Bluetooth の電波を本プロジェクトでは，プロジェクトリーダーは存在せず，メ発信する機器であり，端末ごとに固有の情報を保持しているンバー全員の合意を取ることでプロジェクト内における意思[4]．以後，本報告書で述べるビーコンは，BLE ビーコンを指決定を行った．前期はファシリテーターがミーティングを主導

す．スマートフォンなどの電子端末でビーコンの電波を受信・し，意思決定の確認を行った．15 人全員の合意を取らなけれ検知することにより，固有 ID や受信電波強度などの情報を取ばならないため時間はかかってしまったが，全員が納得する形で意思決定を行うことができた．後期は，プロジェクト全体のンストーミングと，それらを付箋等にアウトプットして得られ意思決定は進行担当大臣が主導し，グループごとの意思決定はたアイデアを整序しグルーピングを行う KJ 法と組み合わせ各チームのプロダクトオーナーが主導した．前期に，全員必ずた方法である．今回は 4 人 1 グループを 3 グループ作成した．

1 度はファシリテーターを担当していたこともあり，後期は円

また，1 グループを 4 人に設定したのは，グループごとに異な滑に意思決定を行うことができた．

るアイデアを出すことができ，OST を実施することから，ほかの班のアイデアを見ることで新たな発見ができると考えたた

2

アイデア決定までのプロセス

2.1

フィールドワークめである．グループごとにフィールドワークの共有結果を見ながら，Google Jamboard で付箋にアイデアを書いて，貼り付フィールドワークは，プレフィールドワークとフィールドけを行った．その後，乗り物，観光地，聖地巡礼，植物や動物などの様々な観点でグルーピングを行った．

ワークの 2 回実施した．COVID-19 感染への対策として体調の管理やマスク着用必須，人混みや他人との接触・会話を避けるなど注意することとした．プレフィールドワークは，6 月 19日に函館山で，フィールドワークは，以下の 5 つの地区でグループに分かれて 6 月 21 日に実施した．五稜郭地区では，五稜郭公園，五稜郭タワー，五稜郭交差点地下横断歩道，千代台公園，JR 五稜郭駅，函館市中央図書館，六花亭で主に調査を

2.2.3

ハッカソン方式によるアイデア出し

ハッカソン方式でのアイデア出しというのは，ハッカソンのような短期間で開発サービスのアイデアを考案する際の方法にちなんだものであり，より具体的なテーマと，5 分程度の制限時間を設け，その制限時間内で開発サービス案を出すものである．

行った．赤川・美原・昭和・富岡地区では，四季の杜公園，笹流ダム，四稜郭，住宅街で主に調査を行った．函館駅・西部地

2.2.4

区では，函館駅周辺，金森赤レンガ倉庫，朝市，西部地区で主OST（オープンスペーステクノロジー）によるアイデアの深堀りに調査を行った．七飯・北斗地区では，男爵ラウンジ，なないろ・ななえ，新函館北斗駅，大沼公園，山川牧場で主に調査を行った．空港・湯の川地区では，あいす 118，函館空港，トラピスチヌ修道院，香雪園，植物園，函館公園，十字街で主に調査を行った．

BSKJ 法とハッカソン方式を行った後に，関心のあるテーマについてに考え，より深い意見にするために OST を実施した．
興味のあるアイデアについて議論する時間に制限は設けず，考えがまとまったら他のアイデアを探す．これを繰り返し，それぞれのアイデアを深めていった．また，他グループのアイデア

2.2

サービスの提案

2.2.1

オンライン下での意見の共有方法の発想を持ち帰り，グループのメンバーに共有し，さらに議論を繰り返すことで，1 つ 1 つのアイデアを具体的にすることができた．OST を実施した結果，斬新なアイデアや何か要素を例年では対面で行っていた話し合いなどをリモートで行う

加えることで発展しそうなアイデアに関しては，議論が進んだ

必要があり，それぞれに最適なツールを選択して利用することものと，既に実装されているものに近いアイデアなど人が集まが重要である．例えば，ミーティングやチームで作業を行う

らず，議論がされなかったものとで明確に分かれたので，その際には Zoom や Discord の通話機能や，画面共有機能を用い後に行われたアイデアの絞り込みを容易に行うことができた．て行った．付箋に書き出して行うような意見共有は，GoogleJamboard というツールを用いることで，リモートでも似たような意見共有が可能になった．

2.2.5

アイデアレビュー

中間発表終了後，新たにアイデア出しを行った．考案した

29 アイデアに対し，プロジェクトメンバーが，「サービスの函2.2.2

BS（ブレーンストーミング）と KJ 法によるアイデア出し

館らしさ」「ビーコンである理由」「サービスの必要性」「サービスの新規性」「サービスの不変的な魅力」の 5 つを満たすか調査と振り返り後，ブレインストーミングを踏まえて BSKJどうかを議論し，満たさないものはそれを補う案を考えた．ま法ならびにハッカソン方式によるアイデア出しを行った．BSKJ

た，29 アイデアのうち，新たに考案した 21 アイデアに対し，法とは，思いつく限り多くの量のアイデアを出すというブレイ担当教員と TA に，前述の観点で，フィードバックをいただいた．担当教員と TA からのフィードバックと，5 つの観点を満単位での計画・設計・実装・テストを繰り返すことにより，継たせるかどうかを踏まえ，29 アイデアから 21 アイデアに絞り続的に動くソフトウェアを提供し続けることができる．また，込んだ．

できるだけ短い期間で上記のプロセスを繰り返し，関係者からのフィードバックを継続的に得ることで，トラブルや仕様変更

2.2.6

アイデアのブラッシュアップに柔軟に対応することができる．これらのことから，開発初期から継続して価値のあるソフトウェアを作り続けることができプロジェクトの内部レビューの後それぞれのアイデアのドると考え，この手法を採用した．本プロジェクトでは，アジャキュメントを作成し，それをもとに，KJ 法などを用いて 8 つのアイデアに絞った．また，それぞれのアイデアに興味のあるプロジェクトメンバーを偏りの少ないように振り分け，各グイル開発を導入するにあたり，アジャイル開発の手法の 1 つであるスクラムを採用した．Ken Schwaber らによると，スクラ
ムとは「複雑な問題に対応する適応型のソリューションを通じループの詳細なサービス案についてのブラッシュアップを行って，人々，チーム，組織が価値を生み出すための軽量級フレーた．各グループごとに詳細なサービス案をまとめたスライドを作成し，プロジェクト内でプレゼンテーションを行った．評

ムワークである」と定義されている [6]．スクラムでは，プロダクトバックログと呼ばれる，実現したい機能を，価値やリス価の方法として各アイデアに対して「サービスの函館らしさ」
ク，必要性を基準にして並べ替えたリストを作成する．この順「ビーコンである理由」「サービスの必要性」「サービスの新規番が上位の機能から開発に取り掛かることで，成果を最大化す性」「サービスの不変的な魅力」の観点から意見を出し合い，アイデアをさらに絞った．最終的なアイデアは，「ビーコンバることができる．また，スクラムでは最長 1ヶ月までの固定の期間に区切って，開発を繰り返す．この固定の期間をスプリントラー」「俺を食ってくれぇ!!」「造語シェア」「函館のここ，おトと呼ぶ．この期間内に，小単位での計画・設計・実装・テス

すすめかも」「未来大のライブラリをよくしよう」「函館を舞台トを行い，プロダクトバックログの機能を完成させる．これをとした ADV」の 6 つでそれらの改善を行った．

繰り返すことで，段階的に，そして継続的に動くソフトウェアを提供し続けることができる．

2.2.7

アイデアの決定

アイデアのブラッシュアップを終え，最終的に出揃ったア

3.2

開発の流れ

イデアをスライドにまとめ，各アイデアについてのプレゼンテーションと評価を行った．また，担当教員，TA の方にも参加し評価を受けた．評価の方法としては，各アイデアに対して，ブラッシュアップで用いた 5 つの観点について，1〜10 点の 10 段階で点数づけを行った．プレゼンテーションを行った
アイデアは，ブラッシュアップをもとに残った 6 つのアイデアであった．
これらのサービスについての得られた評価の結果を踏まえ，自分たちがどのアイデアの開発に携わりたいかという観点で投票を行い，「俺を食ってくれぇ!!」「ビーコンバトラー (のちに「でももに！」)」「函館のここ，おすすめかも (のちに「MET.」)」の 3 個のアイデアを今年度のプロジェクト学習で開発することに決定した．

スプリントを有効に活用するために，私たちはスプリントを 1 週間と定めた．そして毎週金曜日のシステム情報科学実習の時間を用いて，スプリントレトロスペクティブ，スプリントレビュー，スプリントプランニング，の順にスクラムイベン
トをプロジェクトメンバー全員で集まって取り組んだ．スプ
リントレトロスペクティブでは，KPTA と呼ばれるフレームワークを用いて今週の活動について振り返った．K（Keep）では，今週行ってよかった取り組みや，来週の活動でも続けたいことを書き出した．P（Problem）では，今週の悪かった取り組みや，不安に思っていることについて書き出した．次に，T（Try）に関しては，先に Keep と Problem で書き出した取り組みから，来週の活動で行ってみたい取り組みを書き出した．
最後に，A（Action）では，Try の中から来週のスプリントで実際に取り組む内容を決定した．作成した KPTA は各グルー

3サービスの開発

3.1

アジャイル開発とスクラムの概要

プごとに発表し，共有した．共有することで，自身のグループ
では気がつかなかった問題点や，良い取り組みについても気がつくことができた．

本プロジェクトでは，ソフトウェア開発の手法の 1 つである，アジャイル開発を導入した．アジャイル開発とは，小さなスプリントレビューでは，今週のスプリントで作成した成果物を教員，TA，他のグループにレビューを受けた．レビュー

の観点は，私たちの作った成果物が事前に作成したユーザース

発手法を用いて「MET.」，「でももに！」，「俺を食ってくれぇ」

トーリーと同じものであるかや，成果物の使いやすさなどでの 3 つのサービスを提案，開発した．これらのサービスを開あった．スプリントレビューを行うことで，ステークホルダー発したことにより，函館のまちのへの魅力や価値を向上するこからの客観的な意見を成果物に取り入れることができた．スプとに貢献できたと思う．また，1 年という短いプロジェクト活

リントプランニングでは，事前に作成したプロダクトバックロ

動の中でファシリテーター制度，大臣制度，スクラムを活用すグや，スプリントレビューで頂いたレビューから次週の活動でることでオンライン下での活動を自分たちなりにできたのでは行うタスクを選別した．

ないかと考える．しかし，サービスの開発時間が非常に短かったということもあり，先生，TA からのレビューをもらうこと

3.3

アジャイル開発の効果と課題

本プロジェクトにアジャイル開発手法を導入したことで，私たちは，1ヶ月という短い開発期間でありながらも，サービスを作ることができた．これは，スプリントを行い，毎週ごとに優先度の高い機能から実装し，成果物を完成させ続けたからはできたが，第 3 者へのレビューをもらうことができなかった．また，それぞれのサービスでも納得のいくまで作り込むことができなかったと考える．今後外部発表会があるので，それに向けてこれから各サービスをより良いものにできるよう努めたい．

こそ成し遂げられたことだと思う．課題としては，スクラムイベントを開催する条件をプロジェクトメンバー全員が集まっているところと定めてしまったため，システム情報科学実習の 3時間という時間でしかスクラムイベントを行えなかったことが挙げられる．もちろん全員が集まっているという条件は良いと

参考文献[1] 函館市総合計画（2017〜2026）について，
https://www.city.hakodate.hokkaido.jp/docs/2016122100014/ （2021 年 1 月 8 日閲覧）ころもある．全員が集まって同時にスクラムイベントに取り組むことで，メンバーのスクラムイベントを重要視する意識や，[2] 総務省｜平成 30 年版 情報通信白書｜IoT デバイスの急速

KPTA を作成する過程での気づきなどである．しかし，3 時間な普及，https://www.soumu.go.jp/johotsusintokei/という時間では，満足に今週の成果物をレビューしてもらうこ

whitepaper/ja/h30/html/nd111200.htmlとが難しく，何度も事前に想定していた時間を超えてしまった．

（2021 年 1 月 8 日閲覧）

3.4

開発したサービスについて上記の節の開発手法を用いて本プロジェクトでは，「MET.」，「でももに！」，「俺を食ってくれぇ！」の 3 つのサービスを考案・開発した．
「MET.」は，思い出を交換して観光客に新たな旅行の楽しみ方を提供するサービスである．
「でももに！」は，家族みんなでパズルのピースを集めて，思い出を観光地に残[3] Coke ON（コーク オン），
https://c.cocacola.co.jp/app/ （2021 年 1 月 7 日閲覧）
[4] ビーコン — IT 用語辞典 — 大塚商会，
https://www.otsuka-shokai.co.jp/words/beacon.html（2020 年 12 月 20 日閲覧）

[5] ビーコンを使う — LINE Developers，すサービスである．
「俺を食ってくれぇ！」は，海産物自身がhttps://developers.line.biz/ja/docs/messaging-

鮮度に合わせた調理法をアピールしてくれるサービスである．

api/using-beacons/ （2020 年 12 月 21 日

これらのサービスは，リリース可能とまでは言えないものの，閲覧）

それぞれユーザーに最低限体験して欲しい，提供できる最小限のプロダクトである Minimum Viable Product の状態を満たし，最も必要なサービスの根幹に関わる部分は開発完了となっている．

4

まとめと今後の展望
本プロジェクトでは，ビーコンを用いて函館のまちの様々な魅力や新たな価値を生み出すことを目的として，アジャイル開[6] Ken Schwaber・ Jeﬀ Sutherland，スクラムガイド Scrum Guides，https://www.scrumguides.org/
docs/scrumguide/v2020/2020-Scrum-GuideJapanese.pdf（2021 年 1 月 6 日閲覧）