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

提出日 (Date) 2019/01/16

ミライケータイプロジェクト [re:]Future Mobile Phone Project [re:]1016169 宮前冠汰 Kanta Miyamae
1 背景

数年後を見据えて今までになかったような 5 年 10 年後に日常的に利用されているようなサービスを提案し，そ近年，スマートフォンの普及が目まぐるしく加速してのサービスを実現するためのアプリケーションの開発いる．総務省が 2017 年 9 月末に発表された通信利用動を行う．これは，数年後スマートフォンの普及率はさら向調査によると，20〜29 歳では 2016 年度の年齢階層に上回ることを意識しするという意味と，さらに一部の別普及率は 90.0 ％であり，ほとんどの若者がスマートAPI が Web 上に無償で公開されているため，それらをフォンを使っていることがわかる [1]．さらに，50 代ま応用し今までにないようなサービスを提案することが意ででは個人のインターネット利用機器がパソコンより味として込められている．これを実現するために，既存もスマートフォンの利用が上回っていることがわかっのサービスを再考・再検討し開発するサービスに新たなた．加えて，50 代では普及率が 68.4 ％となり，初めて価値を付与する．さらに今年度はプロジェクトの進め方フィーチャーフォンの所有を上回ったことがわかった．

についても再検討を行い，冗長な作業は自動化，必要で60 代では普及率が 39.4 ％となり，もう少しで 4 割を超あるものは新規に追加している．また，アジャイル型開えそうなこともわかった．このことから，若者だけでな発手法を用いて，優先度の高い機能から実装テストを繰

く高齢者のスマートフォンの普及率も増えていることがり返し行い，動くものをつくることで，よりコンセプトわかる．利用用途は多岐に渡り，SNS・動画鑑賞・音楽にあったアプリケーションを開発する．しかしアジャイ鑑賞・読書に加え，買い物の決済もスマートフォンで行ル型開発では，開発スプリントが短いため個人スキルのうことができるために財布を持たない人も増えてきてい差によって進捗の差が生まれるなどの問題が発生しやする．このことが，スマートフォンの普及が進んだ理由のくなる．本プロジェクトでは，これら直面しうる問題に1 つとなっている．

対し解決方法を考え，実行していくことも学習の一環とスマートフォンの普及に伴い，スマートフォンを用いたサービス開発も進んできた．Android，iOS の各プ
ラットフォームに対応した開発環境は無償で利用するする．

2 課題の設定と到達目標ことができる．また，自己のソフトウェアを一部公開し本プロジェクトでは，次の課題を設定した．て，他のソフトウェアと機能を共有できるようにした

1 つ目は従来とは異なり，サービスごとの役割分担がAPI(Application Programming Interface)．API は一遠隔での連携を前提として組まれているため，共通認部 Web 上に無償で公開されているため，誰でも外部か識を得るための取り組みが必要である．例年，プラットら利用することができるようになっている．API を使

フォームは一つの大学が担う方式をとっていたが今年かうことで，あるサービスの良いところを自サービスと組ら 4 大学合同ということをより強めるために，できるだみ合わせて，新たな価値を創造することができる．これけ 1 つのプラットフォームに大学を織り交ぜて開発担らのことからサービスやアプリケーションの開発が行い当を決定している．これにより，プラットフォームごとやすくなっている．に動くためには遠隔でのコミュニケーションが必要にな

こうした背景から，公立はこだて未来大学 (以下，未るため，共通認識がとりにくくなると考えられる．さら来大)，専修大学 (以下，専修大)，神奈川工科大学 (以下，に，4 大学が 1 つのサービスに必ず参加している形がと神奈工)，法政大学 (以下，法政大) の 4 大学の合同で，られているため，サービス内の会議なども必ずリモートで行われることになる．そのような環境でそのサービスとがき，より新しいサービスを作り出すことができる．

がどのように過去のサービスと比較し優れているのか，既存のサービスとの差異をはっきりさせることで，開発どのようにして価値が付与されているのかを考えるコするサービスに強みを持たせることができる．また開発

ミュニケーションをしっかりと行わなければならない．

するサービスだけでなく例年のプロジェクトの進め方な

さらに，ただリモートで会議を行えばよいというものでども再考・再検討しより良い活動に変えていくことも目もなく，4 大学合同ということをメンバーが意識して会標に加えている．これにより例年形骸化してしまってい議に臨まなくてはならない．それをしなければ，4 大学たものを必要でないならば作成せず，必要あるものは工がただ，会議に参加しているだけで発言をしないなどの夫して活かせるように議論するなどプロジェクト自体を問題につながるからである．それらをどのように解決しよりよく進められるように工夫する．さらに，今年度はていくかが課題となる．

チーム開発経験者が 15% としかいないため，そのメン

2 つ目は今年度のチーム開発経験者は，全体の 15 ％とバーを中心に他のメンバーが開発について学ぶことをし少数であるため，サービス配属のリソース分配と技術力なければ，3 つのサービスは作り切ることができないた向上させる取り組み．これは，全体の 15% と少ないた

め，新たな価値を付与するだけでなく開発することも意めに程よく分配させないと，開発の進むプラットフォー味として含む．

ムと進まないプラットフォームが極端に分かれてしま

2 つ目は，「未来大・専修大・神奈工・法政大の 4 大う．また，分配だけでなく残りのチーム開発経験がない学合同プロジェクトであることを意識し自発的連携を行ものにも何かアプローチをとらなければ，3 つのサービう」ことである．例年，未来大のメンバーがプロジェクスを完成させることは難しいと考えられる．開発だけでトリーダーに就任することや未来大のみが必修であるとなく，ビジネスモデルを考える際も同じようなことを意いう点から未来大が中心となりすぎてしまい，他大学の識しなくてはならないと考える．専修大が中心になって意見が抽出されないという問題点が上がっていた．そこ

考えるもののメンバーはそれがどのような物なのかを把で 4 大学合同である強みを今年度はさらに活かしたいと握するためにはコミュニケーションが必要である．それ考えたためである．自発的という言葉を用いることでメらをどのように解決していくかが課題となる．

ンバー 1 人 1 人がこの目標を達成するために他大学の3 つ目はプロジェクト初動時にプロジェクトリーダー意見を抽出することや他大学のメンバーも自分から発言とプロジェクトマネージャが別々にアサインされ，のちしようと意識することができる．サービス内やプラット片方はチーム開発経験者であるため，開発リソースが減フォームで，大学間の連携をすることが前提となっていることを考慮した取り組み．これは，プロジェクトリーるため，リモートでの会議にて，自発的に連携を行ってダーとプロジェクトマネージャが別々の人で役割を分けいくことがとても重要になってくる．それらを意識してていた課題とさらにプロジェクトマネージャを担当して取り組められるように工夫していく．

いた戸澤が，15% の数少ないチーム開発経験者であった

3 つ目は，「様々なケースのビジネスモデルを研究し，ため，プロジェクトマネージャとして置いておくと，さアプリケーションの性質に沿ったビジネスモデルを提案らにチーム開発経験者が少なくなってしまうということする」ことである．実社会でサービスを企画し，開発すが考えられる．それらをどのように解決していくかが課るということは利益を計上するために行われることが題となるほとんどである．そのため，本プロジェクトでは実社会

これらの課題を含め本プロジェクトは，3 つの最終目標を設定した．

1 つ目は，ミライケータイプロジェクト [re:] のプロジェクト名のもと，「既存のサービスの再考・再検討を行い，開発するサービスの質の向上や新たな価値を付与する」ことである．再考・再検討を行うことにより，本プロジェクトで開発するサービスにミライ性を持たせるこでサービスを企画し，開発することを想定し，開発するサービスの性質に沿ったビジネスモデルを提案するために様々なビジネスモデルについて調べ，メンバーで議論し選定する．
以上の目標から，本プロジェクトの目的であるミライ的なサービスの構築を実現する．

3 課題解決のプロセスとその結果2 章で述べたそれぞれ課題に対する解決と目標達成プロセスを以下に記載する．

2 章で述べた３つの課題に対して対策及び施工を行った．

を開発リソースに分配するために役割を考慮する必要があった．これに対し，宮前がプロジェクトリーダー兼プロジェクトマネージャを務め，戸澤は開発者リソースとして分配された．なお，宮前がプロジェクトマネージャの職務で困った際には戸澤に相談する旨でこの決定がなされた．結果として，多少の問題は発生したが，宮前が1 つ目は，遠隔でのサービス活動となるので共通認識

戸澤と相談することで解決することができた．最終的にの確立に対する取り組みが必要であることである．こは，宮前ができる限り 1 人で仕事をこなすことができてれに対し，週に１度サービス毎，プラットフォーム毎にいた．

定例会議を設けるよう対策をとった．その中で，各メンこれらの課題を最初は躓いてしまっていたが，メンバーの進捗やこれからのタスクなどを各自で共有し，今バー全員で解決策を考え，対処することにより解決する

誰が何をしているのか，何をしなくてはいけないのかなことができた．

どを共有することを行った．また，何かサービス内で議論を行う際には自発的を意識し，各メンバーが発言しさらに 2 章で述べた 3 つの目標に対して行ったことを以下に記載する．

合った．しかし，議論で意見が出にくいなどの問題が発

1 つ目の「既存のサービスの再考・再検討を行い，開発生した際は，サービスリーダーが他大学のメンバーに意するサービスの質の向上や新たな価値を付与する」とい見を求めるなど会議のファシリテートを行うことによりう点では，ミライ性のあるサービスを提案するために，会議が活発になった．これらの結果として，サービス内既存のサービスを調査し，既存のサービスとの差異を明での成果物に対する共通認識の差を起こさないようにらかにした．また，例年のプロジェクトとしての進め方することができた．さらに，会議での決定事項などもスについて再考・再検討を行い，毎年議論されている内容ムーズに決定することができた．

に関して不要であると判断したものは，昨年度通りに行

2 つ目は，チーム開発経験者が全体の 15% と少ないうなど時間の節約を行った．さらに今年度は，例年，スため，リソースの配分と技術力向上に取り組む必要があ

クラムイベントで形骸化してしまっていた「スプリントることである．これに対し，今年度はサービス毎に均等レビュー」と「スプリントレトロスペクティブ」をよりに技術力を配分し，経験者はプラットフォームを兼任す活かせる方法を考えた．スプリントレビューとはスプリるようにした．また，勉強会またはペアプログラミングント終了時に成果物のレビューを行うものである．今年を週に一度設けるよう対策をとった．さらに，経験のな度は価値を高めることを意識し，議論し合うことに重点いメンバーはわからないことを自分で調べ，それでもわを置いてレビューを行ったこれにより，スプリントレからない際は経験者に聞き，スケジュール通りに成果物ビューが有効活用され次のスプリントに何をするべきかを挙げるように努力していた．これは，メンバーがしっを明確にすることができた．その結果を意識してスプリ

かりとコミュニケーションをとることにより成し遂げらントを回すことができるためスプリントの回数を重ねるれたことである．これらの結果として，当初は経験者にごとにより良い成果を出すことができた．

タスクが集中したが，随時経験のなかったメンバーが知2 つ目の「4 大学合同プロジェクトであることを意識識を積み，経験者のタスクをカバーできるようになり最し自発的連携を行う」という点では，最初は意識するこ終的にチームで成果物を作り上げることができた．とができず，コミュニケーション不足から起きる様々な3 つ目は，プロジェクト立ち上げ時に，プロジェクト問題に直面した．その問題の 1 つとして共通認識の差異

リーダーである宮前が，チーム開発の経験がなかったたがあげられた．これによりプロジェクトとしてのゴール

め，補佐としてチーム開発経験者である戸澤をプロジェ

認識が人により違うことで開発の見積もりを誤ってしまクトマネージャとしてアサインさせていた．従来はプロうことがあった．それらを解決するために第 2 回合同合ジェクトリーダーとプロジェクトマネージャが 1 人で宿を開催した．この合宿では各サービスで現状起きてい兼任するところであったため，貴重な開発経験者の戸澤る問題点を洗い出し，それに対して解決する問題を分類

し解決策を見出した．それを踏まえたうえで，残された1 つの理由としてあげられる．実際のスクラムマスター

時間や個人のスキルを考慮しどこまでを開発するかといはスクラムについて実践して十分理解がある人が行ううゴールを設定した．これによりメンバー間での共通認が，今年度のスクラムマスターである宮前は初めてスク識を持つことができた．さらにコミュニケーション不足

ラムについて触れるということもあり十分にメンバーのという問題点の解決策として，週に 1 度サービスごとに補助をすることができなかったことが原因としてあげら定例会議を設けるようにした．これにより定例会議内でれる．最低限プロダクトオーナーとコミュニケーション自発的にコミュニケーションを交わすことができるようをとりスクラムマスターとプロダクトオーナー内では意になった．

識を統一していくべきであった．今後は企業報告会に向3 つ目の「様々なケースのビジネスモデルを研究し，アプリケーションの性質に沿ったビジネスモデルを提案すけて開発手法について意識統一を行い全員が同じ答えを言えるようにならなければならない．

る」という点では，ビジネスモデルを考える役割が唯一本プロジェクトでは 1 つのプロジェクトで 3 つのサーの文系である専修大にのみ集中してしまっていたことがビスを開発しているが最終的に意識統一をしきること問題であった．さらに開発の役割を担った理系の 3 大学ができず，ミライケータイプロジェクト [re:] としてのは慣れない開発に奮闘していて，ビジネスモデルについサービスではなく 3 つのプロジェクトとして独立してして考える余裕がなかった．これらを解決するためにビジまっていたことも課題としてあげられる．これにより，ネスモデル班のリーダーとプロジェクトリーダーで会議プロジェクトとしての決定を待たずに各サービスでバラを行いビジネスモデル選定までのスケジュールを作成しバラに動いてしまっていた．さらに，4 大学合同であるた．また，開発班はビジネスモデルに対しての知識がなことを意識しきることができておらず，各サービス内でく調べる時間を作ることができなかったため，レビューも 1 つの大学だけで動いてしまうという問題も浮上してさせる際には専門用語を使わないで説明させることを意いた．これらの問題は，プロジェクトリーダーである宮識させた．これらの取り組みにより，専修大がビジネス前を中心にサービスリーダーと話し合い，企業発表会にモデルについて研究し開発班の作り上げたいサービスに向けて再度 3 つのサービスはミライケータイプロジェク

沿ったビジネスモデルを提案することができ，成果物とト [re:] に属しているということを意識する必要がある．

してビジネスモデル文書を作成することができた．

スケジュール管理についても課題が残ってしまってい上記のような課題の解決や目標に向けた取り組みによる．大まかなマイルストーンに向け準備期間などを想定

り，設定した 3 つの目標を達成することができ，ミライしたガントチャートを作成してきたが，想定できるタス的な 3 つのサービスを企画・開発することができた．

クをすべて洗い出すことができず，直前にタスクを振っ

4 今後の課題てしまうというような事態が起こってしまった．さらにスケジュール管理を各リーダーにまかせていたため同タ

1 年間を通したプロジェクト活動の中で，目標に向けイミングで複数の作業が発生してしまうこともあった．て取り組み 3 つのサービスを開発することができた．一

今後の企業報告会に向けては予測できないタスクがある方で 1 年間というプロジェクト期間の短さから達成できかもしれないということを念頭に置きスケジュールを立なかった項目を，今後の課題として，以下に記載する．

案することと，過去の資料などを調べつくし起こりうる今年度の開発手法で選定したアジャイル型スクラム手タスクを洗い出すことを行い，メンバーが最善を尽くせ法についてメンバー間で理解の差があることが課題の 1るようなスケジュール管理をできるようにメンバーと議つとしてあげられる．スクラムイベントをこなす際，知論していく必要がある．

識量の差により成果物に差異が出てしまっている．さらに，今年度から目標であった再考・再検討を行った
ことにより，スクラムイベントである，「スプリントレ参考文献[1]平 成 29 年 通 信 利 用 動 向 調 査 の 結 果.

総務ビュー」と「スプリントレトロスペクティブ」のやり方

省, 2018. http://www.soumu.go.jp/menu_news/

を変えたため，例年の資料を参考にできなかったこともs-news/01tsushin02_02000128.html