TUT内で新規サービス開発を始めたお話
こんにちわぁぁああ！！！！こんばんわあああ！！！！ころんでぇぇす！！！
なにこれ？
これはTUT Advent Calendar 2018 15日目の記事とCyberAgent 19新卒 エンジニア Advent Calendar 17日目(早く出してごめんなさい！)の記事です
豊橋技術科学大学 & 東京工科大学合同のアドベントカレンダーであり、CyberAgent 19新卒エンジニアのアドベントカレンダーという一大イベント。
SAPPORO CHU-HI 99.99を飲みながら書かせていただきます。
(クリア グレープフルーツおいしいね)
カラオケは好きですか？
自分の場合、なぜか好きな時と嫌いな時がありますが今は好き！
懐かしのボカロ曲やアニソンを聞くと行きたくなる時期です。
そんな中、ちょっとした問題が自分にはあります。
それは、出せる音域が非常に狭いこと
なので、大体の曲は原キーでは歌えないのでキーの変更を余儀なくされます。
Aメロは歌えるけどサビは無理。部分的にはいけるみたいなのが多いので自分に合うキーを探索、記録には苦労します。
アンケートにご協力いただいた方は見たことがあると思いますが、キー変更をよくする人が12.3%もいてちょっと安心しました。
こちらでやってます-->カラオケに関するアンケート
意地でも原キーな人も割といるんだなと実感
記録は以下のようにiPhoneのメモ機能を用いています(一部をスクショ)
じゃ、記録できるアプリがないのかと言われたら一応あります。
あるけどアプリの完成度としては自分は満足していません。
不満点でいえばこのような感じ
- そもそも落ちる。特定の動作で固まる
- UIが不便。とる大きさと得られる情報量が一致しない
- 音程解析がただのフーリエ変換の測定結果
- アプリの世界観が伝わらない
落ちるアプリはそもそも論外です。それも某大手のアプリですが。
UIと世界観ですが、個々のパーツをそのまま置いただけのような昔の業務用アプリが多いです。
最近のAWA、Tictok、Spotifyもそうですがアプリ１つ１つに世界観があると思っています。アプリを使用しているときの安心感があります。
音域解析ですが、これは本当にただのフーリエ変換で最大ピークをもつ周波数帯をグラフ化したものです。当然それで出せる音域は測定できますが、それが本当に気持ちよく歌える音域ですか？と言われたら違うはずです。
統計的、アカデミックな視点から解析できると思っています
このように(継続して)使ってみようと思うアプリが自分の中ではありませんでした。
無ければ作ればいいじゃない！！
自分のモットーでもあります「無ければ作ればいいじゃない！」
ようは自分の満足するアプリがなければ作ってしまおうという、考えです。
TUT内でサービス開発やってる話聞かないし、作っちゃえ！！
作りたいアプリを説明したうえで、同じTUT内の友達や後輩を巻き込んで一緒にアプリを作ることになりました。
サービス内容
残念ながら今回の記事ではまだ公開できません。
音楽関係であるため著作権に引っかかるなどの制限がありますが、それ以外でできる部分で勝負かけます
アプリの設計案
技術的内容
アプリ開発はスピードが大切だと思います。今できる最善の手で使えるツールがあるのなら積極的に取り入れるべきだと考えました。
AWS Mobile Hub（モバイルアプリケーションの構築、テスト、モニタリング）| AWS
AWS Mobileはユーザー認証を行うAWS Cognito、そのほかAPI gateway, Lamda, S3, DynamoDBなどモバイル開発におけるハブ機能を果たします。
各サービスで無料枠が使えるので
- 開発やリリース初期でも費用の問題がない
- サーバー構築に時間を取られない
- 開発メンバーがパブリッククラウドに触れられるいい機会
と思い選定しました。
また開発メンバーが初学者であるため自分もiOSの勉強をする必要があります。
たまたまチーム発足時にmac miniの発売が発表されたため、ローンを組んでポチりましたｗ
グラフィック以外はおおむね満足してます。到着が楽しみです。
あと基本チームの連絡はSlackで行い、タスク管理はtrelloで行うことにしました。
使い慣れた & 連携がスムーズにいくという点で決定。
進捗
現在の進捗ですが、コンセプト、アプリの基本機能、アイコンデザイン、サービス名、技術選定の案だしは終わりました。
ただ卒業研究と論文提出の月であるため、本格的に始動するのはクリスマス後になります。
目指すチーム像
ここからは自分がチーム開発するうえで大事にしていることの一部を書きます。
- いい意味でフラットな関係を作る
後輩、同年、先輩間で「年上だから意見を言うのやめよう」とか「自分より技術低くそうだからこの情報共有しなくていいっか」など勝手な価値観で情報共有をしないのはものすごいもったいないことだと思います。
「グループ」ではなく「チーム」なのだから共通の目的、達成すべき目標、アプローチ方法はチーム全員が共有されているべきです。
そのためにも、リーダーである自分からまず情報開示を行に信頼を得るように意識しました。
Gitの使い方、APIの共有、調査報告、etc...ググれば分かるかな？と思う内容も共有します。共有内容＋コメント(例：これここで使えそうじゃね？)があればよりgood.
この内容に関してはチームの技量にもよりますが、今回はチーム開発未経験者を含めて考えています。
情報共有とフィードバックを繰り返すことで共有することの大切さが実感でき、少しづつの成果が自信へと繋がり信頼につながると思っています。 - HRT(謙虚・尊敬・信頼)を持つ
謙虚(Humility)、尊敬(Respect)、信頼(Trust)の頭文字をとった言葉です。これはオライリーの「Team Geek」で書かれている、当時のGoogleのチームリーダーが優れたチームを作り上げるときに工夫したものに書かれています。
１つ１つ語ると長くなりますが、要約すると
自分は常に間違っているという可能性を考え、
相手に対する尊敬の気持ちを持ち、
信頼関係を育もう
ということです。詳しくはお酒飲みながらお話ししましょうｗ
まだまだありますが、このような思考を教えてくれたおすすめ書籍を紹介して終わりにします。
卒業するまであと3か月ちょいでリリースまでもっていけたらと思うのでよろしくお願いします！
明日(いや、実質今日)は、katura46さんですが何を書くのが気になりますね！乞うご期待！！
