学生エンジニアのみで作り上げた実証実験システム開発の裏話

チーム開発の大きな指針になった名言、この開発を通して最も苦労したことです。詳しくは後ほど。

筆者について
松尾周汰（マツオシュウタ）。システム情報科学府・修士1年で現在大学6年目。ストレートな時系列でない理由は皆さんでご想像ください。荒川豊教授のヒューマノフィリック研究室でIoT × AIをテーマとした研究を行ったり、キャンパス中のバス停や食堂の混雑度が可視化されるシステム「itocon」の開発に携わっています。バンドとお酒が大好きで、酒神として崇められています。自己紹介はこれくらいにして本文に！

iQ Labエンジニア班の松尾です！
今回は九州大学とNTTドコモとの三密回避に関する共同実験における、プロジェクト立ち上げや運用についてエンジニア視点で記事を書いていきます〜
（多少技術的なことにも触れますが、基本的なチームプロジェクトの進め方の側面もあるのでエンジニア以外も対象になるよう書くつもりです）

この実験の公式LINEはこちらから追加できます！

※実験は終了いたしました。
ご協力いただいた皆様ありがとうございました！

三密回避実験って何？？

簡単にいうと

混雑時間を避けてお店に行ってお得にポイントをゲットしよう！

というサービスの効果を測定するための実験です。

今までの生活でももちろん、今のご時世で一番避けたいものといえば「混雑」ですよね。ズラーッと並んでいる長蛇の列に並ぶ、建物内に満杯に人がいる状態で席を探すためにさまよう、なんてことは過去も現在もこれからもできればしたくないです。でもやっぱり混雑はその場に行かないとなかなかわからない。。。せっかくそこに行ったのなら別の場所に行くのもめんどくさいし並ぶか。。。と思ったことが九大の学食でもありませんか？

実は今、九大では混雑している時間帯を避けて学食を利用すると、コンビニや各種飲食店などで実際に使うことができるポイントをゲットできるサービスが3月末から実施されています！

どうやってポイントもらってるの？？

前提情報
☝️上記、または最後に載せている公式ラインからユーザ登録をします
☝️実験参加者には実験専用のアプリをインストールしてもらいます
☝️ポイントがゲットできるお店・時間帯・取得できるポイントの情報がセットになったキャンペーンが平日は毎日お知らせ・実施されています
例）11:00 ~ 12:00にモスバーガーご利用で200ポイントGET !

ポイントゲットするまでの流れを簡単に説明します。

1. アプリからキャンペーンをチェック
2. 「キャンペーンに参加する」をタップしてキャンペーンにエントリー
3. 実際にその時間に対象店舗に行って設置されているQRコードをスキャン
4. ポイントゲット！

このサービスはすべてiQ Labに所属している学生のみで企画・運用されています。もちろん、データベースの設計やモバイルアプリの開発などもすべて0から学生エンジニアのみで行っています。とは言っても、開発経験も浅く、初めて触る技術ばかりだったので相当な苦労と試行錯誤を重ねました。

これからプロジェクト初期からのエンジニア班の働き方について振り返っていきます。

🏃‍♂️　　🏃‍♂️　　🏃‍♂️

プロジェクト発足初期

チーム開発スタート、全員初見の言語でチャレンジ

iQ Lab卒業生の先輩エンジニアのお力も借りながら、要件を満たす技術の選定を行い、モバイルアプリ開発、バックエンド開発、サーバ運用の分担を行いました。プログラミングの経験自体はある程度ありましたが、ほとんど全員が初見の言語を選び、各々でひたすらに調べながら実装を進めていく日々でした。

💬　うち1人は1年生でプログラミング完全初心者、すごく頑張ってたなぁ

エンジニア班の他にマネジメント・プランニング班、デザイン班があり、実験シナリオの策定、実験参加者の獲得、モバイルアプリのUI作成、ポスター作成などを並行して進めていました。

どの班もみんな脳みそが擦り切れるくらいアイデアを出し合い議論、コンテンツ制作、開発の調査、実装、バグ修正など爆走していた時期。

進捗破壊の機能変更地獄

そんな感じで各々突き進んで2か月程経ったとき、あの言葉を耳にしました。

👹 「仕様変更です」

本当にこんなことが起きるんだなぁ（都市伝説を目の当たりにした感）と思いつつ設計を見直していると、どうやらちょこっといじるだけでは修正できないことに気づき絶望。結果、2ヶ月弱の進捗を全て捨てデータベースの設計からやり直すことになりました。

このことを受け、それからの設計は仕様の変更を前提に考え、できるだけ柔軟な対応ができることを心がけました。このサービス自体も新しいものを作ろうとしている上に、実験シナリオも全くの0からの考案だったため、その後も何度か機能変更がありました。なんとか耐えた。

ブラックボックスからの脱却

開発を進めているうちに、次なる壁にぶつかりました。それが「作業進捗の共有」です。それまでの報告は作業をする日にSlackで今日やることを各自でポストする、という方法を取っていました。しかし、この方法だと個人任せになってしまうため、だんだんとポスト頻度が落ちいつの間にかフェードアウト。。。

その結果、自分の作業しかわからず、全体のタスクとの関連や締め切りが曖昧に。エンジニアと他の班だけでなくエンジニア班内でさえも作業がブラックボックス化していました。さらに、九大やドコモの研究者の方々と運営現場側とでも意見のすれ違いが起き、それぞれの立場で見ている方向が異なっているという危機に陥りました。

問題点を整理して浮き彫りになった最大の問題点は

言語化して記録しておかないと人は忘れる
同一の物を見ていても、自分の脳内と他人の脳内の認識は異なる

ことを自覚できていないことでした。

作業中に相談しながら口で決めたことは基本的にすぐ忘れます。加えて、なんとなく伝わって気になる、わかった気になっていざ作業を始めるとそれぞれの想定とは異なるものが出来上がります。

😱 このままだとまたあの悲劇が起きてしまう

ということで状況改善の策として、タスク管理ツール「Notion」の導入と、毎日30分の定例ミーティングの設定を行いました。

Notionでは想定されるタスクをGitHubのPull Request単位で1つのタスクとして切り分け、担当者、進行状況、実装完了までに予想される時間、作業を開始する日、作業終了目安日を設定します。ミーティングは進捗の有無に関わらず可能であれば参加し、雑談ベースで今抱えているタスクや次にやることをNotionをもとに話し合い、各種ステータスの更新、話したことの記録をとります。

👇 こんな感じ

これをひたすらに続けていき、以下のようなサイクルを毎週グルグル回しながら進めています。

現在は、週の初めに長めの時間をとり、KPTの時間を作っています。KPTとはそれぞれKeep, Problem, Tryの頭文字で、先週できたこと、今抱えている問題、次に挑戦することをみんなで共有します。元々はチームの中の課題を見つけるためにやっていましたが、回数を重ねるうちに、プライベートのことも話すようになりました。忙しさはもちろん把握できる上に、最近何に興味があるとか、何を頑張っているか、何で困っているかを共有できるようになったのが大きく変わったところです。それを踏まえて仕事の比重を変えたり、仕事以外の話もたくさんするようになったりと、よりチームの雰囲気が良い方向へと進みました。

現在はとにかく言語化し、文字として記録することが習慣付いているおかげで、以前のようなブラックボックスから脱却ができクリアな環境で仕事ができています。

これがプロジェクト発足初期から3ヶ月ごろまでお話しでした。

以下、先輩エンジニアの格言。

文字列しか信じない
Codeしか勝たん

💻　　💻　　💻

エンジニア班に聞いてみた！
大変だったことやその解決法、それからの学びについて。

iQ Labのエンジニア班は自分含め5人が在籍しています。
それぞれに聞いてみたことをピックアップしていくつか紹介してみます。

✋ エンジニア班紹介
かぜ：修士2年・主にバックエンド/サーバ運用担当・酒癖が悪い
しゅうた：修士1年・主にモバイルアプリ担当・これを書いています
ウン：学部4年・主にモバイルアプリ/バックエンド担当・マレーシアからの留学生で日本語がネイティブレベルに上手な聖人
きったか：学部4年・現在は主にaimo関連担当・自称妹キャラだけどここでは姉御肌
おっくん：学部2年・主にバックエンド担当・完全初心者で加入して現在圧倒的成長中

困ったこと、大変だったこと、辛かったこと

ウン
・始めてチームで開発した
・みんな学生で、仕事以外にもやることがいっぱいある
・他のメンバーも、自分も仕事とそれ以外のことのバランスを取ることが難しい
・タスクを管理するのが難しい

かぜ
・データベースを設計しなおすレベルの機能変更が多かった
・会社だったら必ず経験者がいるので聞けるが、死ぬほどわかんないことも自分たちで考えなきゃいけない

なんと言っても一番大変だったのはやっぱり、初めての本格的なチーム開発に挑戦したこと、1から学びながらなのでわからないことは自分たちの力のみで徹底的に調べあげないといけない点でした。特にモバイル開発もバックエンド開発も初めて触れる言語だったので、そもそもの構文の正しさや、安全で効率的な書き方ができているのかどうかの判断もかなり難しく苦労しました。

また、もちろん学生ですから、授業や課題、部活サークル活動との兼ね合いもあります。理想のスケジュールを立てても想定外の予定が入ったり、課題や研究のために仕事ができなかったりなど、タスク・スケジュール管理の方法もアドバイスをいただきながら自分たちの働き方に合うように試行錯誤しながら進んでいきました。

問題が起こったときの解決方法

きったか
・わかる人に教えてもらう
・プログラミング演習サイトを利用する
・開発や話し合いの記録をしっかり残す
・作業を分担し、しっかり共有する

かぜ
・出来るだけ機能変更しやすいような設計を行った
・プロトタイプを作成して，機能の確認を出来るだけ細かく行った
・自分たちで分野を分け合って勉強・開発をした

問題が次々と出てきましたが、しっかりと課題に向き合い、どうしたら解決できるかを全員で考えることができることもこのチームの強みだと思います。

個人的に大事だなと思っていたのが、わからないこと・できないことははっきり伝える雰囲気づくりです。ある実装について2時間悩んでわからないことも、他の人に聞くとものの10分で解決できることが多々ありました。
他の人の時間を使ってしまうのが申し訳ない気持ちがあるのは確かですが、チーム全体の時間で見ると、すぐに聞いてすぐに解決し、次のステップに進むことが一番効率の良い方法です。

経験の差でわからないのは当然、仕事ができない時もちゃんと理由があれば再分担をすることを心がけることで、無駄な時間を無くすことができました。

学んだこと

おっくん
・想像以上に開発が大変であること
・バグが大量に発生する
・最初からしっかり設計を考えておかないと、作り直しになったりする
・できた時の達成感

ウン
・みんな生身のある人間
・みんな頑張って生きている、えらい　（💬  聖人っぷり全開）
・「文字列しか信じない」→ 全部書き残す

チーム開発ってやっぱり大変！
自分の進捗が他の機能の進捗に関わったり、全体の状況を見てスケジュールを組んだり、現状の共有をしたり、と個人で開発するだけではできないことをたくさん経験しました。それだけの苦労もある分、ちゃんと動くものができた時の達成感はかなり大きいです。

開発の経験だけでなく、KPTを繰り返していくことで相互理解も深まり、お互いを尊重することの重要性も改めて気付きました。

💬 みんな圧倒的な成長したよね

🍺 　🍺 　🍺 

システム構成について

ここからはエンジニアリング的な話をちょこっとだけします。
と言ってもざっくり使用技術の紹介くらいにしときます。

モバイルアプリはFlutterを用いてiOS, Android対応のものを開発しています。
バックエンドはAPIサーバをRuby on Rails, 各種機能をFirebase, データベースとしてMySQLを用いて開発をしています。

 Flutterの選定理由はこんな感じ

- iOS, Androidの開発経験ゼロだがどちらにも対応させる必要がある
- 両方対応できるフレームワークの候補として、React Native, Vue Native, Flutterが挙げられた
- 基本的なデザインUIがWidgetとして提供されているので、CSSをゴリゴリいじる必要がない
- DartはStatic Type Analysisがあるから、ミスを早期発見できて、開発しやすい
- 比較的新しく注目されていることや好奇心からFlutterを選択

細かいことはここでは書きませんが、時間があれば技術について深掘りした記事も書くかもしれません。

⚡️ 　⚡️ 　⚡️ 

おわりに

最後まで読んでいただきありがとうございました！
長々とエンジニア班の活動について書き記しましたが、チームで開発を進めることの難しさについて気づけたことと、学生のうちにこんなに貴重な経験ができていることのありがたさを実感しています。
もちろんエンジニア班以外のマネジメント・プランニング班やデザイン班もこのプロジェクトを成功させるために必死に頑張っています🔥
この実験について詳しく知りたい！自分も参加してポイント稼ぎたい！という方はぜひ以下の公式ラインから登録をお願いします🙏

詳しくはこちらの記事も参考にしてみてください！

登録は5分程度ですぐできるのでみなさんのご参加お待ちしています！

※ ポイント交換時にはdポイントアカウントの登録が必須です。
※ docomoユーザー以外も参加できます。

▶︎ よくある質問はこちら
▶︎ 実験の詳細はこちら（九州大学プレスリリース）

本実験に関するお問い合わせ
📞 TEL：050-3700-0451（運営事務局 担当：神尾）​

本実験は九州大学COIと株式会社NTTドコモによる共同研究の一環です。