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

Final

Report

提出日(Date)

2018/01/19

ミライケータイプロジェクト[re:]Future Mobile Phone Project [re:]b1015006 佐藤敦也

1. 背景
日本の携帯電話普及率が 90%を超えて数年がたち，年齢や性別を問わず携帯電話を持つことが当たり前の時代となった．特にスマートフォンは，凄まじい速度で普及しており，日本のスマートフォン普及率は，2017 年度
現在 70%を超えている．特に若者は，スマートフォンを持っていることが当たり前となり，SNS・動画視聴・読書・地図・撮影など，アプリケーションを通じてスマートフォン 1つで行っている．スマートフォンの普及に伴い，スマートフォンアプリケーションの市場規模も拡大し，総務省が発表しているモバイ
ル向けアプリケーション市場によると，モバ
イルアプリケーションダウンロード数，売上高共に上昇傾向にあることがわかる．アプリ
ケーションストアの AppStore で配布されるアプリケーションも 2016 年度に 200 万本を突破した．一方で，アプリケーションストアでトップセールスに上がっているアプリケーションは年度別に比較しても大差がなく，恒常化している．モバイルアプリケーション
規模が拡大する中，サービスを開発してもストアに埋もれてしまうような状況となっている．
そこで，本プロジェクトでは，公立はこだて未来大学(以下，未来大)，専修大学(以下，専修大)，神奈川工科大学(以下，神奈工)，法政大学(以下，法政大)の 4 大学の合同で，過去のサービスを再考・再検討し，今までになかったようなミライ的なサービスの提案・開発を行う．また，実践的なソフトウェア開発を行うことも本プロジェクトの目的としている．具体的には，アジャイル開発を用いAtsuya Satoて，優先度の高い機能から実装テストを繰り返し行い，動くものをつくることで，よりコンセプトにあったサービスを開発することが挙げられる．また，常に動くアプリケーシ
ョンをデリバリーできるように，CI(継続的インテグレーション)ツールを用いることや，開発メンバーでコードをレビューしあうことで質の高いアウトプットを出せるような体制作りも行う．

2. 課題の設定と到達目標
本プロジェクトは，2 つの最終目標を設定した.1 つ目は，「[re:]の要素を含んだサービスを開発する」ことである.[re:]とは，既存サービスの再考・再検討を行うことを指す.[re:]の要素を取り入れることで，プロジェクトで開発するサービスにミライ性を持たせることができ，より新しいサービスを作り出すことができる. 市場に出ている似たようなサービスとの差異をはっきりさせることで，サービスに強みを持たせ，開発したサービスがストアに埋もれてしまう状況を回避する目的がある．
2 つ目は，「全員が作りたいサービスを作りきる」ことである.サービスを作りきるた
めには，マスタースケジュールを組むことで全体フローの見える化や，全員と共有するものはしっかりと共有するように心がけることが重要である.また，サービスを作りきることを目標に置くことで，一人ひとりのモチベーションを保ち日々の会議やアプリケーションの開発に注力することができる.実際にアジャイル開発を用いることで動く成果

物を常に目に見えるようにすることができ，モチベーションの維持につながる．さらに，Git やクラウドを利用した実践的なソフトウ
ェア開発を行うことも目標に置くことで，ソフトウェア開発の現場で用いられているような複数人開発や，セキュリティー・スケーリングなどの技術的な学びにも繋げることができる．

計書の 2 部を作成して仕様を 1 箇所にまとめた．仕様書を作成するにあたっては，仕様書リーダーを中心に昨年度の仕様書及び世間一般的に作成される仕様書を調べ，全員で調べた内容を発表することで，知識習得に繋げることができた．コンセプトを元に，それを実現するためのアプリケーションの機能一覧や機能詳細を記載したサービス企画書を作成することができた．それによって，サ以上の目標から，本プロジェクトの目的でービス企画書を見るだけでサービス概要があるミライ的なサービスの提案・開発を実現理解できるようになった．サービス設計書でする.
は，サービス企画書の機能を実装するための具体的な設計や，画面遷移図を作成した．その結果，開発メンバー間での意識合わせがで3. 課題解決のプロセスとその結果きた．しかし，サービス内で仕様を理解し切2 章で述べたそれぞれ課題に対する解決プれていない部分も問題として残ってしまっ
ロセスを以下に記載する．
た．詳しくは今後の課題で述べる．アイディアに基づいて，ビジネスモデルも考案した．
1 つ目の，「[re:]の要素を含んだサービス専修大学主導でビジネスモデルを考案し，ビを開発する」という点では，ミライ性のあるジネスモデル文書を作成することができた．
サービスを提案するために，既存のサービス
また，作成したビジネスモデル文書は理系大を調査し，既存サービスとの差異を明らかに学も交えてレビューすることができた．
した．その上で，既存サービスと比べ，機能2 つ目の，「全員が作りたいサービスを作的な側面やビジネスモデル的な側面でどのりきる」という点では，早い段階で全体のスような優位性があるのかを示してサービスケジュールを提示することで，スプリントのを提案した．サービスの提案は各大学が 2 つ期間や回数の把握，発表会などのマイルストのアイディアを持ち寄って，第一回合同合宿ーンの把握に繋げることができた．ただ，ス内でそれぞれが持ち寄ったアイディアを 5ケジュール管理に関しては，全体の見える化個に絞り込み，4 大学混合チームでアイディはできていたものの，効率的なスケジュールアを練り直し，投票によって今年開発する 3を組むことは課題として残ってしまったた
サービスを決定した．また，3 サービスそれめ，後述する．全体の見える化を図るために，ぞれの参加メンバーが決まった後，サービス定期的にレビュー会を実施することや，全大内でサービス名を検討した．すでに登記され学が集まる合宿でデモ会を開くことで，進捗ている名前がないか，親しみやすい名前かどの見える化を図った．また，実践的なソフト
うかなどの項目から「まっぴん」「Mono-Chika」 ウェア開発を行うことで，学習意欲を保ちつ「Disaster kit」というサービス名を決定しつプロジェクトを進めることができた．具体た．サービス決定後は，サービスの特徴が一的には，以下のようなプロセスをとった．
目でわかるようなサービスロゴをコンペ形
学習リソースの集約化や，メンバー間での式で集め、投票を行い決定した．決定した仕知識の共有を行った．結果として，個々人が様に関しては，サービス仕様書，サービス設
アプリケーション開発に関する基礎知識を習得し，プラットフォームごとに知識共有できる環境を整えることができた．
アジャイル開発を用いることで，開発速度を保ち，常に動くアプリケーションを作り続けることができた．メンバーのアジャイル開発の知識習得のために，アジャイルセミナーに参加することや，プロジェクトリーダー主
導でアジャイル開発の知識共有を行った．知識習得はできたが，アジャイル開発の実践に関しては課題が残ってしまったため，詳しくは今後の課題で述べる．
アプリケーションの機能選定という点では，アプリケーションを実現するための必須機能，コンセプトを強めるための機能など，機能ごとに優先度をつけることで，機能選定を行った．アジャイル開発を行う上でも，優先度の高い機能から開発に取り掛かった．結果，早い段階からアプリケーションのコア部分が動く状態を作ることができた．各種発表会でも早い段階からアプリケーションを動く状態にできていたため，アプリケーションの使いやすさを高めるための踏み込んだレビューをいただくことができ，質の高いアプリケーションを作ることができた．
実践的なソフトウェア開発という点では，初期の段階から技術勉強を多く取り入れて，学習に取り組んだ．その結果，Git を利用した開発を理系大学全てで行うことができ，文系大学に最終報告書執筆時に GitHub を使ってもらうきっかけにもなった．最終報告書の執筆を GitHub 上で行うことで，複数人で同時に報告書を執筆，編集できるようになり，CI を用いることで，表記揺れの自動チェックや，PDF の自動生成などを行うこともできた．最終報告書の執筆環境も快適なものにすることができた．
2 つの最終目標を通して，特に文理融合を意識した活動を多数おこなえたのは大きな成果であった．文系の専修大学が理系大学の用語を理解できるように，専門用語をまとめたリストを作成した．ビジネスモデル文書の相互レビューを行うことで，理系大学もサービスの成長について考えることができた．また，合宿ではデモ会を開催して，文系大学も実際にアプリケーションを触ってレビューすることができた．最終報告書に関してはGitHub を文系大学も使用することで，複数人で最終報告書を同時に執筆することができた．
設定した目的に対し，上記のような解決を図ることでミライ的な 3 つのサービスの提案・開発を行うことができた．

4. 今後の課題
1 年間を通したプロジェクト活動の中で，多くのことを学べた．一方で 1 年間というプロジェクト期間内の短さから達成できなかった項目を，今後の課題として，以下に記載する．
1 つ目として，サービス内で意識合わせができていないところがあり，サービスの方針についてもめてしまうことがある．原
因としてはサービス内で議論を行った際，しっかり議事録を取れていなかったこと，変更点があった際に仕様書を合わせて修正できていなかったことが挙げられる．サー
ビス内での会議において議事録を必ず取るようにして解決を図りたい．また，本プロ
ジェクトでは協力企業への企業報告会が残っている．企業報告に向けて準備する必要があるため，企業報告会で全員がプロジェクトのことを語れるように，意識統一を図りたい．
スケジュール管理についても課題が残ってしまった．本プロジェクトにおいて必要な作業が同タイミングで複数発生することが多かった．そのため，スケジュール管理を各イベントリーダーに任せてしまったことで，同じタイミングで複数作業が平行し，プロジェクト時間外におけるタスクがかなり発生してしまった．そのため，スケジュールを立案する上で，いくつの作業が並行して動いているのかしっかり見える化した上でスケジュールを立案できるようになる必要がある．
レビューや進捗の共有がおざなりになってしまったことも課題である．スプリント
期間内でレビューできる状況までサービスを開発することができないことがあり，進捗を報告する体制を取っていなかったのが原因だと考えられる．速度を保ちつつ，1つ 1 つのスクラムイベントを確実にこなすことで，スプリントごとの活動に一貫性を持たせられるようにしたい．
また，大学間活動の難しさも課題として残った．それぞれの大学のプロジェクトに参加する目的が異なっていたため，プロジェクトに対してのモチベーションの違いが発生した．普段実施している合同会議が実施できない状況や，必要な提出物を提出期限までに間に合わせられないことが多数発生した．大学間連携で問題が発生した場合にどのようにリカバリするのかをしっかり話し合う必要がある．
上記に関連してリスク管理についても課題として残ってしまった．第二回合宿では，計画立案が遅れてしまい，スケジュールについて完全に詰め切ることができなかったために，当日活動やスケジュールを大幅に変更することになってしまった．普段の活動でも，遠隔のメンバーと連絡が取れなくなって提出物の締め切りまでに必要なコンテンツを用意することが難しくなってしまったことがあった．事前にリスクを洗い出し，リスクが発生したときに範囲を小さくできるようにしたい．
協力企業との関わり方も課題として残った．以前のミライケータイプロジェクトでは，ガラケー用のアプリケーションを作成したいたこともあり，協力企業から技術支援を得られていた．しかし今年は協力企業との関わりは合宿がメインで，プロジェクトの方針についてのアドバイスやサービスについてのレビューがほとんどだった．今後の課題として，協力企業とどのように関わりながらプロジェクトを進めていくのか考える必要がある．
AWS サーバに関しても問題もあった．今
年度は従来プロジェクトで使用していたWiki を学内サーバからクラウドに移した．
従来の環境では，学内停電やドメインの更新で問題を抱えていたため，そのような制約を受けないクラウドサーバ上に移した．
しかし，クラウドサーバを利用することで毎月の運用費用がかかってしまい，プロジ
ェクトの資金だけで運用ができなかった．
さらに，クラウドサーバのインスタンスも自由に利用できるわけではなかった，本年度は AWS EC2 インスタンス上に Nginx という Web サーバを立て，その上で複数台のアプリケーションサーバを立ち上げることで対応したが，インスタンスの容量が膨れ上がってしまい，別の問題を抱えてしまった．
また，開発ライセンスに関しても問題が残った．iOS アプリの開発に当たって，未来大の Apple Developper ライセンスを使用させてもらっていたが，デバイスの追加が自由にできなかったり，他大学の学生が使用できなかったり，アプリの審査についても権限を持っている先生方にお願いしないと使えず，自由度がかなり低く，満足に使用できなかった．ミライケータイプロジェ
クトとしてライセンスを保持できる状況を作りたかった．