福岡県で開催されたチャレキャラというイベントに、いいとみーというチームのメンバーとして参加していました。
半年間の開発期間が終わり、コンテストも終了したので、ここまでの振り返りとして筆を執った次第です。
実は昨年も参加していましたが、昨年はいろいろと忙しかったのと怠惰な性格のため、書いていませんでした。
アプリ開発の参考になれば幸いです。
全体を通して良かった点と改善点などを思いついた順番に書いていきたいと思います。
制作物
今回は、ノンセブというアプリを作りました。
命名は、否定を意味する"non"+保存を意味する"save"からノンセブとしました。
機能は、簡潔に表すとストレージに保存されない写真アプリです。
このアイデアの発端は、チームメイトがバイト先に自身の体温を測定し、その体温計の写真を毎回送らなければならないため、カメラロールに余計な写真が溜まって邪魔になってしまったり、ストレージを無駄に圧迫してしまうという悩みでした。
ここから、撮った写真をストレージに保存しないアプリがあれば便利なのではないかという着想を得、開発をしていきました。
上記の例以外にも、板書を書き写した後にそのまま破棄する、SNSに写真をアップロードした後に破棄する、Googleドライブに撮影したものを保存し、手元のストレージからは削除するなど、非常に汎用性が高いアプリになっていると思います。
開発にはFlutterを採用しました。
良かった点
ここからは、チャレキャラに参加して開発をしていく上で、個人的にうまくいった点などを書いていきます。
定期的に会議や勉強会を開けた
個人的にはこれが一番大きいです。
タスク管理ツールが数多く台頭し、様々なWebサイトや動画教材などで独学ができる環境が整ってきていますが、やはりリモートでも良いので会議を開いて直接進捗管理をし、学習した情報が共有できる場というものは設けたほうが良いと感じました。
実際、会議を定期的に開くことで、どこまで開発が進んでいるのかが明確になったり、それをメンバーから直接聞くことで、開発のモチベーションを上げることにつながったと感じています。
社会人の方からのフィードバックが得られた
これは学生ならではだと思います。
学生にとって、クラスメイトやサークルの仲間からのフィードバックは、普段の会話のついでにでも聞けば比較的簡単に得ることができますが、社会人の方からのフィードバックを得るにはそういう場を設けるなどの必要があり、ハードルが高くなります。
しかし、チャレキャラでは多くのメンターの方からアプリの機能やUIに対するフィードバックを得ることができ、さらに発表の際には、審査員の方からのフィードバックがいただけるなど、非常に多くの貴重な意見を聞くことができ、アプリの質の改善や、新たな需要を見出すことにもつながりました。
ネイティブアプリの開発の経験になった
僕がチャレキャラへの参加を決めたときは、ネイティブアプリの開発経験はほぼ0、Flutterも僕が3か月学習した程度でした。
メンバー全体を見ても、Webアプリの開発経験はあれど、ネイティブアプリの開発経験ほぼ無に等しかったです。
それでもネイティブアプリを開発することに決めた要因としては、メンバーが比較的ネイティブアプリの開発に乗り気だったのと、僕がFlutterを学習していたこともあって、かなり興味を持っていたためです。
実際開発してみると、Flutter自身が売りにしているだけあってかなりUIが組みやすく、初めてにしてはサクサク開発できたのではないかと思います。
Flutter最高。
改善点
ここからは、もう少しこうしていればよかった、と思う点について書いていきます。
アイデアが二転三転した
今回の開発期間は6か月ほど設けられていましたが、実は、アプリの構想が今のものに固まったのは、発表から1か月前です。
というのも、その空白の5か月の間に、最初はタスク管理アプリ、その次は言いたいけど言えない秘密が共有できるSNS、さらにその次は愚痴が共有できるSNSといった風に、何度もアイデアを没にしてきました。
こうなってしまった要因としては、アプリの機能をしっかりと決めるという、至極基本的なことを怠ったというのが一番ではないかと思います。
初めのタスク管理アプリに関しては、知っての通り、すでにGoogleなどの超大企業までもが参入しており、そういった企業がかなり完成度の高いものをリリースしていることもあり、シンプルなものでは到底太刀打ちできません。そうなると、当然タスク管理+αで機能を考える必要が出てきます。そこでいろいろ考えましたが、いまいちピンとくるものがなかったため、このまま考え続けても仕方ないのではないかと考え、断念しました。
次の秘密が共有できるSNSと愚痴が共有できるSNSですが、これはアイデアが面白そうという理由で開発を始めました。
実際にXDを使ってモックアップを作成し、Flutterに加えて、サーバーサイドにNode.jsを採用して簡単に機能を実装しきった段階まで行きました。
その辺りまで行った頃にメンターの方に現実を突きつけられます。
「秘密を共有したい状況がいまいちイメージできない」と。
ごもっともです。
秘密は隠しておくから秘密なのです。
言いたいけど言えない秘密というのがないことはないと思います。
ただ、いまいちこれといった具体例が思いつかず、これではあまりユーザーが得られないのではないかと思い、2度目の断念をしました。
その次が愚痴が共有できるSNSです。
秘密を共有するシチュエーションが思い浮かばないのは、「秘密」というものが表現する範囲が広すぎるためではないかと考え、秘密->愚痴へと範囲を絞りました。
知らない人に愚痴を言ってすっきりすることができるアプリということで、なんとなくイメージはしやすくなりました。
しかし、ここでも問題が浮上します。
「愚痴を積極的に聞きたい人はいるのか」と。
確かに。
人の悩みを聞いてあげたいような人もいなくはないと思いますが、決して多くはないのではないかと思います。
まして投稿する場はSNSです。愚痴の内容によっては誹謗中傷もあり得ます。
この方向性も厳しいのではないかと考え、3度目の方針転換をすることにしました。
この時にはすでに1か月前になっており、これ以上の方針転換はほぼ不可能です。
そこで、自分たちが抱える悩みに立ち返ることにしました。
そこで出てきたのがノンセブの構想です。
前述したことと重複になるので書きませんが、チームメイトの悩みからアプリの機能を考えました。
最後にうまくアプリに落とし込めたので良かったですが、最初から思いついていれば、より良いものができたのではないかと考えると惜しい時間でした。
コードが汚い
1か月前から急いで作ったということもあって、コードのきれいさをあまり意識する余裕がありませんでした。
そのため、変数名がわかりづらい、適切なファイル分割ができていないなど、今後開発していく上でネックになるであろう問題が浮き彫りになっています。
また、状態管理もStatefulWidgetを使ったものになっており、今のトレンドになっているproviderパターンを使ったものに書き換えたいと思っています。
負荷をあまり考えていない
Flutterの場合、適切な部分にconstキーワードを使うことで、再描画される際のリビルドを抑制することでパフォーマンスの改善が期待できます。
これも急いでいたためにあまり考える余裕がなく無視していたので、pedanticなどの静的解析ツールの導入も検討しつつパフォーマンスの改善にも力を入れていきたいです。
まとめ
チャレキャラでの開発を通して一番の学びは、アプリの機能を定義する段階でしっかりとユーザーストーリーを考え、使ったときにユーザーにポジティブな変化がもたらされるかどうかを検討するべきであるということだと思います。
今後も様々なアプリを開発していくつもりなので、今回の学びを生かして、より良いアプリづくりに役立てていきたいと思います。