（約6万字）大学で起業に2回失敗した自分が、就職せずにアプリを作るまでにやった全てのこと
「もうすぐ大学卒業か………自分はやりたいことをやっていけるのだろうか。」
周りの皆は、就職して社会で活躍する人材になろうと大企業に入っていく。そんな中で、自分は就職活動もせずに大学4年を迎えていた。
「どうしよう。このままじゃ中途半端な人材にしかなれない。」
このnoteは、中途半端にプライドだけ高い23歳が、大学卒業まで根拠のない自信で戦い続けた結果中途半端に失敗し続けたので、一念発起して卒業後就職せずに、まずは簡単なアプリを作れるようになるまでの道のりを描いたものです。
ちなみに約半年前までは、プログラミングやデザインの経験はほとんどありませんでした。
なので、後述するアプリを作れるようになった半年後の自分が、半年前に大学を卒業したばかりで、何もできなかった自分に読ませてあげたいようなまとめ記事にしました。
簡単な内容としては、
1. なぜ就職せずにアプリを個人開発するという選択に至ったのか（経緯）
2. こういう道のりでアプリ開発のための勉強しました（学習法などのまとめ）
3. やっていて引っかかった、躓いた点！（アンチパターン）
の3つを中心に書いていきます。失敗したことを全公開する理由は、成功談より失敗談の方が役に立つ貴重なものなのに、ネットには意外と載っていないからです。しかも起業や学生団体のマネジメントに失敗したという生々しく、しかも登記前に2回も頓挫した学生の話は意外と稀有なのではないでしょうか。
だから自分は恥ずかしくても、自分の失敗が誰かの参考になればなという想いで書きます。
この記事が、誰かの役に立つことを願って。
（約60,000文字くらいあるので、忙しい人は保存してゆっくり読まれることをお勧めします。）
プロフィールと経緯
自分がいかに何もできなかったかを知って、なにもできないけど、今から何かを始めようという人に勇気を出してもらうために。
そして自分はこれだけ成長したんだということを再確認するために。ここに自分の略歴を書き残しておきます。
1. 高校〜大学入学
自分の高校時代というのは、1年間海外留学していた経験以外は、何の取り柄もない高校生でした。部活も留学後に幽霊部員化し、どちらかというと受験に力を入れていました。
実は、高校時に1年間留学していたという実績は、高校2年当時では意外と稀有な存在だったらしく、ある予備校に行ったら「絶対にここが合うよ！留学という経験を活かして、大学でやりたいことを伝えられれば絶対に合格できる！」と言われて、その予備校スタッフ達の言葉を信じました。英語も帰国子女みたいに得意なわけじゃないですが、TOEICもそこそこ取れていたので、天狗になっていた自分は、実際は受験よりも恋に現を抜かしていました。
気がつけば志望校も、「好きな人が行くから」という理由で選んでいました。無意識に、自分もそこに行くんだと無理やり理由を自己暗示していました。結果、薄っぺらい志望理由ができて、そのまま見事に「不合格」。
よく就活であるような「お祈り」もないような無機質な「不合格」という文字。そして好きだった相手は書類を突破するというまさに悲劇。
絵に描いたような展開に、一時は落ち込みましたが、それでも諦めきれない。自分はAOが向いていなかっただけ、と言い聞かせて一般受験に専念することにしました。
そしてどうにか無事に合格。泣きました。「やっぱり自分はやればできる。」と。
しかし、合格したこと自体はよかったのですが、それが中身のない自分のプライドを助長するきっかけになっていました。
高校時代を超ざっくりまとめるとこんな感じ。
2. 大学入学〜大学2年秋
入学後は、みんなプライドの高い人たちばかりで、キラキラした共学出身のイケメンや美女ばかり。彼らのマウントの取り合いの中で必死こいていました。自分はプライドだけはやたら高かったので、リア充風を装って頑張って中心的なグループの輪に入っていました。
サークルも6つ掛け持ちしてみたりして、とにかくリア充になろうと頑張っていました。
でもやっぱり、身の丈に合わないことをすると疲れるものです。夏休みが終わるとすぐに、殆どのサークルに行かなくなり、授業も中心グループではなくて、サークルの気の合う友達と受けたり。結局、大学で自分は勝ち組にはなれないなと痛感しました。
それでもモテる男＝リア充という概念を脱ぎ去れなかった自分は、女子大の文化祭に行ってナンパしてみたり、合コンをしてみたりと、とにかく大学以外のところで活躍(苦笑)の場を広げればいいと思い、サークル以外はどんどん外に目が向くようになっていました。
サークルの合宿に向かうバスの中
すると大学2年になる頃には、サークルも一番居心地のいい所だけになって、自分は授業後はアルバイトかサークルで遊ぶ。そんな生活になっていました。
それなりに大学生活を謳歌できるようになった2年生の夏休みには、インターンシップの情報を集め始めていました。「どうやらインターンというものに参加していると、就職に有利になるらしい。」ちょっと意識高い大学生あるあるですね。
長期インターンを募集しているITベンチャーに応募してみました。すると、トップから２番目という社員の人が出てきて、君はなにをしたいのか。どんな経験を積みたいのか。と色々と質問されて、さらに、サービスを売るプランを立ててみて。と課題まで課されたんですが、一応クリアできたみたいで、正式にジョインすることができるようになりました。
しかし、なぜか自分はモヤモヤしていました。
そのベンチャーは、自分たちの運営している30万円のプログラミングスクールを受講すれば、裁量を持てる仕事やらせてあげるよと言われていたんです。
自分は30万円払えば、という言葉に引っかかり、インターンへの参加を少し考えさせてほしいと言いました。
そして大学で起業している友達に相談したり、自分でもググってみたところ、「そのインターンは詐欺だ。」という結論が出ました。その後適当な理由をつけて参加を断った自分は、ベンチャーはなんか怪しいから、大企業のインターンに行こう！と決めました。
秋には、学年不問のインターンをひたすら外資就活ドットコムで探してみたり、企業からオファーが来ないかなあ、なんて考えてビズリーチキャンパスに登録してみたりしていました。
しかし、中身のない自分が何をアピールしようとも、大企業に響くことはありませんでした。
そう、インターンは4つほど受けて書類審査の時点で全滅でした。
3. 大学2年冬〜大学3年
年も明けて、期末試験も終わった1月末。
「このままじゃ冬休みはバイトで終わってしまう…！」
と、意識とプライドの高い自分は、就活の準備が何もできずに大学3年になることを危惧していました。周囲には起業して少しずつ結果が出始めている友人もいました。プログラミングがとても得意で、開発で稼いでいる友人もいました。しかし自分は遊び呆けていただけ・・・せめて就活の準備を頑張らないと。。。と言っても、具体的な準備なんてインターンに参加して勉強するくらいしか思いつかなかったのです。
その時期、マーケティングやプロモーションなんて言葉は、何のことだかわかりませんでした。
普段使っているサービスが、どのように世の中に生み出されて、広められているのかなんて知りませんでした。
自分がこれまでやってきたのは、「ただのお勉強」と「モテるための努力」だけです。
趣味は映画や洋楽、ダーツ、旅行、小説、アニメなどありますが、仕事にしたいと思えるほどの情熱を傾けられるものもありませんでした。
でも、ある日Facebookを眺めていたら、「第一線で活躍する起業家から思考法、企画、マーケティング、事業計画などのビジネススキルを一気に学ぶ、3週間のブートキャンプ型インターン」という記事を見つけました。
「これだ！！」縋るもののなかった自分が、希望の光をみた気がしました。
ここから自分の人生は大きく変わることになります。
そのインターンでは、全くなにも知らない無知な自分でもわかるように、本当に1から思考法や学習法などのベースとなる武器を教えてもらえて、さらにビジネスモデルの作り方などのビジネス知識も懇切丁寧に教えてもらえました。
そして最終日には、チームで考えたアイデアをプレゼン。残念ながら1位になることはできませんでしたが、企業賞を頂くことができました。
参加したインターンシップの3週間の流れ
そこで得たのは、
「企画」というものがとても面白いことだということ。
そして世の中には「企画」というのを生業にして戦っている人たちがいるということ。しかし大企業にいては、企画のお仕事に就かせてもらうのに最低でも10年はかかる、下手したら一生チャンスが回ってこないという事実。
それだけで十分でした。
「企画」で生きていきたいなら、「起業」するしかない。
それに起業には、M&AやIPOによって、創業者が夢のような大金を手にできることもあると知ったら、止まる理由はありませんでした。
しかし、実績ゼロ、バックグラウンドゼロ、実務能力・経験ゼロ、人脈ゼロ、お金はバイト代くらい、という一介の学生が起業をするのは、アイデアだけでお金が手に入るなんていう夢物語ではありませんでした。それは、数え切れないほどの壁を乗り越えなければサービスを始めることすらできないという、生々しい現実だったのです。
そのいくつもの厳しい現実は、すべてできるかぎり詳しく後述します。
インターンが終わってすぐの3月、自分は教えて頂いた講師の方に弟子入りをして、インターン生として企画のお手伝い（という名の修行）を始めることになりました。そしてその方のアドバイスの元、起業を行うことを決意しました。
起業アイデア自体は、講師の方からいいね！と言って頂いていたものでした。
なので、まずはチームを集めなければ。と思い立ち、インターンで仲良くなった友人たちに声をかけました。
具体的に役職などは決めていませんでしたが、敢えてC職に置き換えてみるなら、自分がリーダーとしてCEO、友達2人がCTO、COO(Operation)というポジションでした。
4月に入り、師匠の指導の下、事業企画書を作る鬼の日々が始まりました。
自分は初めてやりたいことができた！！どんどん新しいことを覚えて試すのが楽しい！と、おもちゃを与えられた赤ん坊のように、事業企画書を作るのに必要な知識を学んでいきました。
その知識は、師匠に直接教えて頂いたり、事業計画書の作り方という本を読んだり、様々なネットの情報を組み合わせて作っていました。
最初期に作っていた事業企画書のデザイン（デザインのデの字もない）
自分にとって一番大変だったのは、
・企画書としての全体のクオリティを出すこと
・見やすい資料や構成であること
・細かい文章のチューニング
・そもそも用語や業界知識がゼロスタート
ということです。
企画書としての全体のクオリティとは、そもそも「企画書として必要事項が網羅されていて整理されている、いわゆるMECE（漏れなくダブりなく）、且つ、質がよい」ということです。質が良いというのも曖昧ですが、あえていうならその企画が素晴らしいものだと伝えきれる内容ということですね。
全く企画書なんて作ったことのない自分は（というよりも企画書は普通社会人になって、何か仕事を任されるようになってから作るものだと思います）、ひたすらやれるところからやっていきました。
最低限の必要事項、例えばサービス自体についての解説や料金について、プロダクトの目玉やシステム、市場規模、ビジネススキームなどについては予め教えて頂くことは出来ていたのが幸いでした。
まるで意味不明な計算式をしたり、プロダクトについて浅はかな説明をしたり、散々やらかして失敗を繰り返しながら、何回も部分最適と全体最適を繰り返して、1ヶ月ほどそれをずっと行っていました。
それくらいしても、まだまだ素人からは抜け出せないのだから企画という仕事は先が長すぎるとも感じたくらいです。でも同時に、こんな面白いことを自分たちで計画できるなんて最高！とも思っていました。
資料のデザインについてもとても苦労しました。とりあえず見やすい資料にするために、なんとなく字だけにならないようには気をつけて画像を配置したりしたのですが、最初は完全に見辛い資料になっていました。
そもそも、Windowsユーザーでパワポすらまともに使ったことがないような学生だったので、Macbook PROに切り替えてからは慣れるので精一杯でした。
Keynoteの使い方が最初は分からなすぎて大変でしたが、後から慣れればものすごく便利なツールだと気づきます。
そこから師匠に教えて頂きながら、自分なりの資料作成術を身につけていきました。
最終的にはフォントのサイズ1ポイントの違いや、果てはX軸とY軸のポジションを揃えるなど細かい鬼のデザインをするようになりました。
これが後々の、アプリデザインに活きてきます。
最後には少しだけマシなデザインに（※Sobroは例です）
そんな風にひたすら勉強しながら企画書を作る怒涛の日々が大学3年生の4月でした。
大学でもこんなに勉強したことない自分が、人生で一番必死こいて勉強していました。努力していました。毎日毎日、休むことなく企画書のことばかり考えて、ほぼ毎日電話しながら仲間と作業していました。
普通は就活に向けてノロノロと準備を始めたり、インターンに申し込み出す人が多いと思います。自分は大学でゼミにも所属していたので、そちらも3年からスタートして、充実した日々を送っていました。
5月に入ると、大学の友人伝手にデザイン学校に行っている学生を紹介してもらって、彼に夢を語ったところ、デザイン担当としてジョインしてもらえる運びになりました。
しかし。
やりたいことが見つかって、さらに誰かが夢に共感してジョインまでしてくれた。
そんな有頂天な気分もすぐに急降下を見せ始めます。
まず、リーダーとして一番時間を費やしていた自分は、
「自分がこんなに頑張っているんだから、みんなももちろんやるよね？」と自分のことを鬼軍曹かな？と笑いながらチームメンバーにコミットを強要していました。
チームメイトに大学を休むことを強要してしまっていた
起業をするんだから、チームメンバーの熱量が同じなのは当たり前。
だからみんな同じだけ頑張るべき。
マネジメントという言葉こそ知れど、その正しい意味なんて知らなかったこの時期の自分は、一人で突っ走るワンマンチームになりかけていました。
始めて3ヶ月も経っていないのに、コアメンバーの3人が隠れてお互いの悪口を言い合うような事態になっていました。しかも自分と技術担当だった仲間は、それが良くないことであると気づきもせずに、ストレスを感じるがままに発散してしまっていました。
きっと社会人の職場でも愚痴を言わずにはいられないとは思います。
しかしそれでもぐっと喉元で飲み込んで、発散はバッティングセンターやカラオケのようなところに行ってやるのが大人なのかなとも、今は思っています。そもそもストレスが出ない対策をするべきでした。
自分たちは全員が、始めたばかりの起業未経験者で、なんならインターンの経験もありませんでした。だから当然のことですが、そもそもの働き方やマネジメントについての知識が皆無だったのです。
チームメンバーはこういう性格だから、こういう働き方が向いている。お互いを尊重し合おう。という行動が一切ありませんでした。ただガツガツした若者が集まると、マウントの取り合いが始まり、負けた人は去る。そんな結果になってしまうのは当たり前です。
ただでさえ起業をしたいなんていう学生は少ないのに、せっかくやる気になってくれた貴重な仲間が去るというのは、リソースの面からしても大きな痛手。
結局6月に入ってしばらくして、技術担当の仲間は去ってしまいました。5月中旬ごろから、自分いなくてもいいんじゃないか。本当にこれをやりたいのかという気持ちがあったそうで、どんどんそこから悩む状態になり、やる気がなくなって作業が進まなくなってしまったと、残った仲間から聞きました。
チームメンバーが辞めた時のLINEメッセージ
それを本人の口から聞けなかった自分は、それでもその時後悔していませんでした。
やる気がないならいいんじゃない？くらいに言っていた最低な勘違い男です。
もっと自分たちの夢や、本音を面と向かってぶつけ合う。それが仲間との向き合い方であるべきだと、今では思います。大人の配慮を持って、相手のことを気遣いながら時にはぶつかり合うくらいの気持ちが大事で、影でこそこそ悪口なんていうのはもっての外でした。
そうでないなら、圧倒的な力を見せて自分についてくれば大丈夫、というような状態にするしかありません。人はリスペクトした相手の言う事は聞く生き物です。しかし同年代の仲間をリスペクトするのは意外にも難しい。全く違うスポーツの分野で活躍している人を見ると尊敬する！となりますが、同じようなスペックの人間だけになると、リスペクトするような尖った部分がなく、結果無意味なマウントの取り合いになるんですね。
そして夏まで全く結果の出ない日々が続きました。その原因はこの時期、仲間のマネジメントが上手くいかなかったことと、そもそもビジネスの実務知識が圧倒的に足りなかったことです。
それでもやれることは全てやろうとしていました。何十冊も大学の図書館で本を読み漁って勉強しました。プログラミングもprogateをやってみたり、ドットインストールをやってみたりしました。少しずつできることが増えて、同時にビジネスの準備も進めていました。
自分たちは当時、音声認識を使ったプロダクトを考えていて、資金集めの方法としてクラウドファンディングを検討していました。自分たちで音声認識の勉強をしたりもして、さらにクラウドファンディングの成功事例についてもひたすらまとめていました。
それらをほぼ全て、3人チーム（途中から入ったデザイン担当合わせて）のうち2人でやっていました。デザイン担当の彼は、前述のリスペクトの話や、そもそも自分たちが彼にこういうデザインをしてほしいというディレクション能力が皆無だったために、何をしたらいいのかもわかっていませんでした。しかも、自分たちの語った夢に賛同したはいいものの、結局自分の夢ではないし、自分も学校の課題が忙しいなどの理由でほとんど動いてはもらえませんでした。
さらに、自分たちは技術担当がいなくなったので、本格的なプロの方にお願いすることまで考えました。しかし、デザイン担当の現状をみてさすがにお願いしても言う事を聞いてくれる保証がないしお金が無断になるだけだと気づいていました。
そこで、同じように夢に賛同してくれる、今度はちゃんと自分でタスクを考えてこなして行ってくれる起業に興味があるエンジニアの学生を探すことにしました。
エンジニアといえば某大学だろうということで、そこの技術系のサークルにメールを送り、興味がないか内部で聞いてみてもらったところ、2人が興味あると言ってくれて、うち1人と面会して会ったところ、お試しでやるということになって、無事技術担当が決まりました。
彼はとても優秀で、本当に彼なしでは開発は絶対に進まないだろうと言うことが確信できるくらいには凄かったので、全く悪口も言うことなくリスペクトしていました。
ただリスペクトしたのは良いのですが、今度は彼にしかできないが故に、彼の進み具合に全ての進捗が委ねられてしまうような状態になったのです。
他の全員が何かしらできることがあればよかったのですが、彼に開発をまるっきり任せる以外には進むことも出来ず立ち往生。彼も学業があるので、こちらに傾けることも出来ず仕舞いでした。
その立ち往生の期間は自分はインプットにこだわってしまい、アウトプットをまるで出来ていませんでした。
それ以外にできることが本当になかったのか。マーケティングの戦略を考えたり、テストマーケティングの候補先に行ったり、クラウドファンディングの資料を準備したりとできることは色々とあったはずです。
それでもアウトプット出来ないのは、アウトプットよりもインプットの方が遥かに気楽だったからだと思います。アウトプットはひたすら脳を捻る、脳に汗をかく行為です。
それを大学時代全くやってこなかった自分は、必要性に駆られないとアウトプットできない性格でした。夏休みの宿題でもなんでもギリギリでやる性格、といえば聞こえは少しは良いですが、とにかく逃げ癖がありました。
ただ、好きなこと（たとえばテレビゲーム）であれば、食事も忘れて集中することができます。
集中力はあるし、やればできることはなんとなく自分でも理解していたのですが、インプットしていればきっと後で役に立つ！と言って、今できることを先延ばしにして、いつまでも結果が出ず、そしてやる気も下がって結局またインプットしかしない。そんなジレンマに陥っていました。
アウトプットをから逃げる「負のインプットループ」
そうして行動できないという結果が夏休み中ずっと続いた後に、チームは自然解散してしまいました。段々とミーティングの頻度も減り、LINEでの会話も減ったあとに、です。
全てが終わってしまった後になって、あれ。もう続けられないのか。と考えてしまいました。もう一度人を集めてやればいい。そのはずなのに、もう自分はこの事業を失敗したんだと決めつけていました。
結局自分の中ではこの計画は凍結した扱いにして、深く振り返りもせずに、ここでも逃げるように何かを行わないと。。。と次のプランを考えていました。
その間、師匠は事業についてのアドバイスをくれることはあっても、自分たちの進捗具合などについては一言も文句を言いませんでした。まるで最初から、失敗するであろうことが目に見えているようでした。
師匠に相談したところ、これは早すぎたのかもしれない。ワンチャン出来ると思ったが、まだまだマネジメント力など基礎的なところが足りていない。だから起業という難易度から一歩引いて、まずは学生団体などでチーム作りを経験したら良いのではないかという話になりました。
しかし、ただ学生団体をやるわけにはいきません。適当な○○同好会を大学3年の秋から始めてもなあなあで終わるだけです。さらに、周りは就活を本格的にスタートさせていて、自分はどうしたらいいのか迷っていました。
浮かれて周囲に起業をするんだと豪語してしまっていた自分は、半端で終わるわけにはいかないと、高いだけのプライドを保つために、しかし逃げ癖のある自分はこう決めたのです。「学生団体だけど、学生が社会問題を解決するような崇高な目的を保つ団体を作ろうと。」
起業ではなくても、起業に近いことを学ぶというのは、学生団体でもできるのはおそらく事実です。社会で実際に起きていて、かつ学生が関係する問題を考えて、そこに対して解決策を考えていく。いわばデザイン思考が使えます。
そして、学生という会社で働く義務感ではなく、モチベーションや目的に共感して動く存在をどうマネジメントして、課題の実現に動くのかというマネジメント力。
社会人と関わり、実際にプレゼンを行って共感してもらって、参画してもらう巻き込み力。
計画を実行に移し、実現まで導く実行力。
Webサイトの開発なども含めれば、営利でないだけでほとんど社会起業とやっていることは変わらないので、起業の基礎固めにはぴったりだと思っていました。
そうして大学3年の9月に創設したのが、「BACKDOOR」という学生団体です。
BACKDOORには裏口という意味があります。大多数の学生が社会と関わりはじめるのは、「就活」です。しかし就活は、他の大勢と同じ時期に、同じスキームの中で選考されるだけのものです。
一方では、インターンで活躍してそのまま入社パスを獲得したり、起業をはじめとする0→1の経験やクリエイティブな技術を買われてヘッドハンティングされる人もいます。
そのような就活という「正面玄関」に対する「裏口」は存在しているのに、あまり知られていません。それなら、自分たちは裏口自体を増やして、裏口を普及して、裏口が裏口と呼ばれない当たり前になる世界を目指そうというコンセプトを掲げました。
メンバーは、起業を一緒に行おうとして最後まで残ってくれた同年代のメンバーと、彼が紹介してくれたコミュニケーション力抜群で営業やマネジメント経験豊富な学生、そして春のインターンで同期だったクリエイティブな才能溢れる学生の4人です。
自分たちがデビュー戦として行おうとしたのは、2つのプロジェクトです。
1. 学生による企業PRのアイデアソン「PRソン」
2. 女子大生広報ユニット「PRJD」
PRソンは、社会的にとても価値ある商品を保有するが社会認知度が低い中小企業のPR課題を、学生の目線から解決するアイデアソン。
PRJDは、PRパーソンという企業の広報を務める職業は比較的女性が多いが、個人で行なっているために出産や育休など、止むを得ない休暇によってPRパーソンを務めることが出来なくなってしまう問題を、ユニットにすることで解決。さらに所属女子大生（PRJD）がインフルエンサーとなり、企業の広報を務めることによって若者をはじめとする消費者の認知度向上。PRパーソン自体が不足している時代なので、PRJD自身のキャリアにも繋がります。
この2つのプロジェクトを考えたのが9月ですぐに動き始めて、計画では10月下旬に差し掛かる頃にはPRJDメンバーを決定して、11月中旬にはPRソンを実施する予定でした。
記者会見をする機会も頂くことができました。
スケジュール的には周囲の助けもあり、なんとか成し遂げることができて、PRソンというプロジェクト単体で見ても成功したと言える成果が上がりました。しかしそれでも、内部的には成功したとは言いづらい状況になってしまったのが現実です。
それは、またしてもチームメンバーとの不和です。マネジメントを勉強するために始めたつもりでしたが、多くの社会人を巻き込んでいる故に、気づけばPRソンを遅らせるわけにはいかない、失敗するわけにはいかないという強迫観念に全員が取り憑かれていました。
そして、全員がマネジメントを気にかける余裕を失いました。またしても、他人の悪口を影で言い合いながら進める日々。さらには、関わってアドバイスをくださっていた社会人に対するアピールのためのマウントの取り合い。
学生団体を名乗っていたので、高校時代の友人も含めて多くの学生をBACKDOORにお誘いしたため、10人くらいのメンバーが集まってくれました。
そんな彼らのマネジメントを誰も行う余裕がなく、ひたすら関係各所との調整や打ち合わせ、プレスリリース、集客、オーディションなどの山積みのタスクをこなす日々でした。
そしてPRソンが終わるまでの3日間ほどは創設者全員が仮眠だけで過ごすような、壮絶なスケジュールとなってしまっていました。
審査員に向かってプレゼンをする学生達（当時）
なんとかイベント自体は成功したものの、その後チームはやはり崩壊して、集まってくれていた10人のメンバーもほぼ解散。PRJDと数人だけが残って、自分を除いた3人はBACKDOORを続けていく気力をなくし、残ったメンバーに団体を託してそれぞれの道に進むことを決意しました。
4. 大学4年
起業プロジェクトも失敗、学生団体もマネジメントに失敗した自分は諦めきれずに三度目の挑戦を始めます。しかし今度は、自分にはスキルも経験もないから誰もマネジメントする力はない。だからまずはスキルと経験を身につけるために1人で挑戦しようと決意します。
師匠に相談して、新たに起業のアイデアをいくつか考えた後にFBを頂いた結果、ある分野においてSaaSのサービスを作ろうと考えました。
それが大学4年の春から始まりました。
最初は事業計画書を作るところから再スタートしました。前年に経験していたので、作り方自体については問題はありませんでした。
資料の見栄えも少しはマシになってきていました。
しかし、ここでも壁にぶち当たります。もう何回目なんだと自分でも数えていられないくらいですが。
それは、セルフマネジメントとアウトプットからの逃げ癖です。
アウトプットから逃げてインプットに逃げてしまう癖は、前からありました。インプットしてるだけでも偉いと言ってくれる人もいるかもしれませんが、無駄に完璧主義でプライドの高い自分は、下手にアウトプットしたものを世間様に評価されてボコボコにされるのが怖かったんです。
理由は他にもありますが、それは後述します。
一番の課題はセルフマネジメントです。
チームからのマネジメントから解放されたから、自分のペースで進められる！と思いきや、責任感が消失して自分の行動力が激減してしまったのです。
チームメンバーがいた頃はまだ、自分が引っ張らないとチームが終わる、失敗するという危機感の中で行動できましたが、大学4年で授業もあまりなくて時間がある中では、逆に仕事に集中することができませんでした。
大学の授業に行ったり、ゼミに行ったり、課題をやってみたり、卒論を書いたり、飲み会に行ったり、卒業旅行に行ったり。大学最後の年になると急に、もう今しかできないことをしたくなるのです。しかも、就活が終わると途端に周りは一斉に遊び始めます。
前述したようにリア充を目指していた自分は、同じように卒業旅行はヨーロッパやアメリカに行って、友達を友情を深めたり、今しかできない経験をしたい！など、とにかく大学生活をとことん最後まで楽しんでやると、開き直って仕事そっちのけで遊んでしまいました。
友達にかっこいい写真を撮ってもらえました（ロサンゼルス）
それ自体は後悔していませんし、本当によい思い出でした。
しかし一方で、自分のやりたいと思っているはずのことが一向に進まないことにフラストレーションも溜まっていました。
このまま失敗だけで自分の大学生活は終わってしまうのか。
あれだけ時間を使ったのに、何も成し遂げずに終わってしまうのか。
何度も自分の不甲斐なさや、能力のなさに泣きそうになりました。
周りはこれから大企業に勤めるバラ色の人生を送ることが決定している上で、遊んでいるのに、自分はやりたいことをやるって言い聞かせているだけ。
このままじゃあ、本当に何もできない。
未来に怯えた自分は、ある決断を下します。
それは「アプリを作ること」。
【経緯編まとめ】
自分は大学生活を通して、3回大きな挑戦をして、3回とも大失敗しました。
なぜ毎回上手くいかないのか。この失敗を分析して、大きく5つの要因があることがわかったので、みなさんにシェアできれば幸いです。
1. その分野に関するスキルと経験がないと、必要なスケジュールやバッファーを見誤る可能性が高い
2. チームマネジメントについてPDCAを回していない
3. 同年代は圧倒的な能力かスキルが1つでもないと、お互い尊敬できない
4. セルフマネジメントができない
5. アウトプットを避けてしまう
1つ目ですが、井の中の蛙大海を知らずというように、スキルや経験のない状態では、どれくらいの猶予を見込んでスケジュールを組めばいいのかまるでわかりません。どれくらいの工程でどれくらいの時間がかかるのかという見積もりは、経験した人にしか基本的に出せないのです。
それにも関わらず、自分は実績欲しさに生き急いでスケジュール通りに結果が出ず、そして落ち込んでよく振り返りもせずに次に進む。そんな負のループに陥っていました。
これを解決するには、新しい挑戦をするときは目標を立てるのはもちろんですが、スケジュールを大幅に長く見積もることが大事だということです。もちろん余裕のない時もあると思いますが、そんな余裕のない中での成功は何度も続かないんです。その場しのぎではなく、一度立ち止まってきちんと長期的なスケジュールをアップデートし続けるくらいでいいと思います。思ったより長くかかりそうだったら、しっかりスケジュールをできる範囲で調整することが大事です。
同じくらい大事なのが、２つ目のチームマネジメントについてのPDCAです。メンバーによって適切な働き方や関わり方というのはそれぞれで、正解というのはありません。個性を組み合わせたチームを作るのであれば、毎度PDCAを回してマネジメントのその時の最適解を見つけるべきです。チームの力が最大限に発揮できなければ、計画はいくらでも遅くなりますし、そもそも失敗しやすいと思います。逆に、全員がのびのびと働けて連携が上手くなれば、ゲームでいう絆スキルや連携奥義が発動して、100%以上の力を発揮できるようになるんじゃないでしょうか。
そしてPDCAを回す余裕を持つためにも、スケジュールというのは大目に見ておくに越したことはありません。
３つ目ですが、これは非常に難しい問題です。大学3年時の話の中で言及しましたが、改めてまとめます。自分はチームが男性だけだったので、女性が入っていればまた別の問題が起きるかもしれませんが、同年代の男性だけのチームについて言及します。
学校の友人とチームを組むということは、学生起業ではありがちで、そうでなくても学生団体やサークルの運営も同様です。同年代の男性が集まると、しかも学生だと能力が偏っていないことが大半なので、なんとなく役割分担をせざるを得ません。
本当に仲がいいのなら良いのですが、超親友同士と言える仲でもない限りは問題が発生すると思います。例えば私が経験したように、自分が一番行動している人と思えば、なんで他のやつは努力しないんだとなります。それは相手を尊敬していないからです。自分には出来ないことをやってのけるメンバーがいれば、尊敬もしますし、文句も言わないでしょう。
だからこそ、もし超人的なカリスマを持たないのに同年代を引っ張りたいと思うなら、圧倒的な能力で尊敬させて引っ張るしかありません。リーダーになりたい訳ではない時でも、チームを同年代と作るときには、誰もが平均でバランスがいいではダメで、多少アンバランスでも誰もがどこかで尖がっていて尊敬できる方が大事です。
そして４つ目。セルフマネジメントは一生の課題ですよね。いかにモチベーションを生むかというのは最適解がありませんが、とことん自分がそれを行う理由を納得して、その先にある報酬がワクワクするものであるか、計画やプロセス自体がワクワクするかが決め手になると思います。人はワクワクを感じられなければ、行動できない人が大半です。どんなにめんどくさがりでもゲームやアニメ鑑賞は行動に移せるというのは、それをしている自分はとても楽しんでいる、ワクワクしていると容易にイメージできるからであり、さらに行うことによる報酬もワクワクするものだと確信しているからです。
自分も最近やっと、セルフマネジメントがほんの少しずつだけできるようになってきました。
以前は期限に追われてやっとギリギリではじめて、何となくでこなすことが多かったのですが、最近は徐々に、毎日少しずつでも前に進むことができています。大学時代には、サークルやゼミなど大量にやることがあったのに対して、今はこれ以外の全てを切り捨てたことによって、やっと進めています。自分はそこまでしてやっとマネジメントできるくらいキャパが狭いので、少しずつこれからキャパを増やしていけたらと思っています。
５つ目はアウトプットですが、これに関しては、この後のデザイン編の学習方法の部分で言及するため、詳しくはここでは記載しません。
最終的に、自分が学生起業に失敗したことにアイデアの良し悪しは関係ありませんでした。そのアイデアが面白いかどうかを検証する前に、これら5つの壁を乗り越えなければ、サービスを出すことすら学生にとっては難しいです。
どんなにいいアイデアでも、実行と結果が伴わなければ、誰にも見てもらえません。学生であれば、信用も実績もないのでなおさらです。そして実行において重要なのが今までお話した教訓なので、ぜひこれから起業するという方は、これらを念頭においてチャレンジしてみてください。
【アプリ企画編】
ここまでいくつも失敗を重ねてきて、しかし大学卒業を迎えて就活もしなかった自分はある決断をしなければなりませんでした。
それは、
1. 就活浪人になり、卒業後に就職活動をする
2. 大学院を受験して、9月入学か翌年4月の入学を目指す
3. このままどうにか、自分で頑張ってみる
上記3つの選択肢のうち、1と2を選んだ方が、無難な人生になっていたのは間違いないでしょう。といっても、表立った実績のない自分がいい会社に就職できるのかと言われれば、全くわかりません。
そうでなくても大企業に就職すれば、
・やりたいことをやれるまでに時間がかかる。（自分の場合は新規事業企画職）
・範囲内でしか物事を考えて実行できない人間になる。
・理不尽な上下関係や飲み会
などの可能性が高いことが分かっていました。
大学院に関しても、特に現状勉強したいことはなく、モラトリアムを伸ばすために自分の親にとても高い学費を払ってもらう価値はあるのかと自問した結果、まだ早いという結論に至りました。
それよりも、
・ものづくりをしていたい
・自分で考えたサービスを世界の人に届けてみたい
・自分のサービスで誰かを幸せにしたい
・そもそも好きなことをして生きていきたい
と自分が心の底から感じている感情を無視は出来ませんでした。
正直就職しない怖さよりも、このままなにもできない、市場価値のない人間になる怖さの方が大きかったんです。体力もあって、失うものが少なく、やりたいことをやれるのは20代のうちだけなのだから。
それに、費やしてきた大学3年からの2年間の経験が無駄になることも恐れていました。
ただ、
・開発力がない（HTMLとCSS、JavaScriptを少し勉強したくらい）
・自力でアウトプットを出したことがない
・セルフマネジメントができない
自分からしたら、
「できるだけシンプルで単機能、だけど自分が欲しいと心の底から思えるもの」
を「収益云々は一旦度外視して」作ってみるしかないと考えました。
意識高いフリをして、インプットばかりしてアウトプットから逃げてきた自分は、
何かここで1つアウトプットしないと、これからもずっと逃げ続けてしまう気がしたんです。
だから、身の丈に合ったものでいいから、腰をどっかりと落ち着けて0から作ってみる決断をしました。
ここで重要なのは、
・身の丈にあったもの（実現可能性）
・自分は本当に欲しいと思えるもの（情熱、モチベーション）
・最後までやりきること（セルフマネジメント力、GRIT）
の3要素です。どれが欠けても、自分にはハードルが高くなってしまったり、中途半端で投げ出してしまう可能性が高いと感じました。例え就職せず卒業したという背水の陣だったとしてもです。
ここから企画と設計の話に入ります。
どうやってこのアプリを思いついたのか。それをやろうと決断したのかについて話たいと思います。
自分のLOVEとHATEを書き出す
大学4年の秋に、TOKYO DOCANという東京都が主催する起業家育成講座に応募して、2ヶ月間週1回受講をした経験があるのですが、そこはアメリカのMITの起業家育成メソッドを採用していたそうです。そこで第1回に行ったのがこの、LOVEとDHATEを書き出すという作業。
自分が好きなLOVEやHATEをひたすら書き出していきます。
これは紙とペンさえあればできるものです。
とにかく自分の「好きなこと」「嫌いなこと」を書いていくのですが、その理由は、
自分が好きで好きで仕方のないことや、嫌いでどうしても変えたいことというのは、必然的に情熱を持って取り組めるからです。
TOKYO DOCAN 当時に書いたLOVEとHATE
そして、その情熱が根幹にあれば多少途中でアイデアが変わったとしても、モチベーションを落とさずに続けていけるという理論でした。起業家は新大陸を探そうと大海原に飛び出した16世紀の探検家のような存在です。多くの困難に立ち向かう中で、それでも新発見をするんだという信念を胸に突き進む。それがなければ途中で泣いて帰ってきてしまうでしょう。
これはその「信念」を見つけるワークショップといっても過言ではありません。
いくつか書いていると、LIKEにとある共通点が浮かび上がりました。
それは、自分は「人に喜んでもらえることが好き」ということ。
確かに、やってみれば人が喜んでくれそうなことをたくさん書いています。
そこで考えてみました。
「自分はどうやったら喜ぶのか。」と。
それは、「何かをしてもらった時」だと思いました。
人は何かを与えられると、喜びを感じる生き物だと思います。
ここでピンときました。
「何かをしてもらった時」の喜びが最大化されるようなシチュエーションとは、
サプライズされた時だろうと。
サプライズといえば、誕生日だったり卒業だったりと言った「お祝い事」だなあと気づきました。ちょうど3月に、所属していたゼミの後輩たちから卒業のお祝いに小さな手作りのアルバムを作ってもらえて、とても嬉しかったのを覚えています。
ただ嬉しかったのではなくて、自分は他の人よりも参加できていなかったから、当然撮られていた写真とかも相対的に少なくて。だけどそれでも、精一杯手作りで作ってもらえて、他の卒業生と同じようにお祝いしてもらえて。
そんな「サプライズ性のあるお祝い」はみんなを幸せにするんだと考えました。
そしてお祝いということに関して、自分は大学4年間でずっともやもやしていたことがあったことに気づきました。
大学ではリア充を目指していたと前述しましたが、これはどのような尺度で測られるのかというと、一つに誕生日のお祝いメッセージやプレート、アイテムをいかに貰えたか。というものがありました。
誕生日が1ヶ月前にもなれば、Twitterで自分の誕生日がもう少しで近づいているのを匂わせるために、「去年の誕生日の思い出！今年はどうなるかな〜」なんてツイートする人や、友人にもうすぐこいつの誕生日があるぞって拡散させたり企画させたりする人も。
なんなら、自分でパーティを企画しちゃう人もいましたね。笑
大学2年生の時に、サークルの友人達からもらえた誕生日メッセージ
つまり、大学生にとって誕生日が1年の中でも重要なイベントであることは間違いありません。そして、自分がお祝いされるには人気であるか、自分が相手のことをお祝いしたことがあるか、がその成否を分かつと言っても過言ではありません。
他の人の誕生日をお祝いして、後に自分も祝ってもらうwinwin型作戦が一番安定するでしょう。
しかし、他人の誕生日というのはいつの日も、気づいたら前日。気づいたら翌日。なんてことはしょっちゅうですよね。Facebookで誕生日機能というのもありますが、1ヶ月前から教えてくれたりはしません。
確実に覚えているのは、家族と恋人の誕生日や何回も祝っている親友の誕生日くらいなものです。
忙しい人であれば、一回思い出してもすぐに忙しさで忘れてしまい、家族の誕生日が過ぎてしまった。と後々お詫びメールを入れることもあるでしょう。
さらに結婚記念日のような、誕生日以外の記念日も覚えているのは難しいことがあります。
自分は両親の銀婚（結婚25周年）をお祝いしたことがあるのですが、その時は日付を思い出せなくて、祖父母に確認したことがあるくらいです。
ましてや、友人などの結婚記念日はとても覚えていられそうにありません。
前置きが長くなってしまいましたが、私は
「記念日を祝いたいけど、覚えていられない、思い出しても忘れてしまう、そもそも思い出せない」
というのは、全人類にとって損失じゃないかなと考えました。
皆がたったお祝いのスタンプを1つでもメッセージで送り合うだけで、世界はもっと明るく温かいものになるんじゃないかなと思っているからです。
反面、記念日を覚えているためにみんなが現状使っている、手帳やカレンダー、Facebookでは限界があるなと感じました。
つまり、
「記念日を簡単に追加できて、あとは放置するだけで毎年リマインドしてくれるアプリがあればいいんじゃないか」と考えました。
作って広めることができれば、きっと「たくさんの人が喜んでくれる」。
これが、今回開発した「remindary」というアプリ企画の経緯です。
名前の由来は、「remind（思い出させる） + anniversary（記念日）」
【要件定義編】
ここからは少し真面目に解説していきます。
アプリを今回作ろうと決めた後、
・単機能でシンプル
・ほぼノンプログラマーな自分が開発できるレベル
という条件を達成するような要件定義をする必要がありました。
以下に自分が定義したものの一覧を載せます。
1. アプリ要件
①アプリ名
②コンセプト
③ターゲットユーザー
④ユースケース
2. 技術要件
⑤開発言語
⑥開発プラットフォーム
⑦UIライブラリ
⑧対象OS・ストア
⑨その他技術要件
3. UI・機能要件
⑩デザイン思想
⑪デザインランゲージ
⑫主な機能
それぞれどうやって要件定義したかを解説していきます。
1. アプリ要件
①アプリ名
アプリの名前については、記念日というanniversaryであったり、祝うというcelebrate、他にもmemoryなど、とにかくキーワードをひたすら考えてmacbookのkeynoteにたくさん羅列しました。しかし列挙して組み合わせてみてもしっくり来なかったので、このアプリの本質だけに焦点を当てることにしました。
このアプリは「記念日」を「思い出させる」ために「通知」することが本質です。
であれば、「anniversary」「remind」「notification」といったものがメインのキーワードになると考えました。
そしてそれらの組み合わせを試した結果が「remind」＋「anniversary」＝「remindary」です。
②コンセプト
コンセプトとは、キャッチコピーのようなものです。このアプリを一言で表すなら、どんな言葉になるか。その言葉1つで、アプリ全てを言い表すことができる。そんな言葉がコンセプトになると考えました。
「もう、どんな記念日も忘れない。」
たった1行ですが、「もう」「どんな記念日も」「忘れない」という3つの言葉でこのアプリの本質を言い表すことが出来ていると思っています。
絶対にもうどんな記念日も忘れない。お祝いをするんだ。そんな強い意志を感じ取れるような文章にすることで、ユーザーさんに共感してもらうことが大事だと考えました。
コンセプトの決め方は、いくつかのwebサイトを見て学びましたが、やはり「コンセプトの出し方」よりも、「色々な商品のコンセプトそのもの」を見て学ぶ方が効率が良かったです。
特に、大好きなappleのコピーを参考にしました。
「1000曲をポケットに」「シンプルで、魔法のようなワイヤレス」
これは素晴らしいと。こんなに一言で製品を言い表して、かつワクワクする言葉はないなと今でも思っています。
だから自分も、コンセプトは
・ワクワクする
・一言で表す
・語呂がいい感じに
なるように心がけて作ってみました。いいコピーこそが、いいコンセプトになって、それだけは達成しようという確固たる方針となるなということを、開発中に何度も感じました。
コンセプトを最初に決めることで、開発中に何があっても、最初の思想と最高の体験とは何かを忘れずにいることができます。自分は個人ですが、チームであればコンセプトさえ共通認識があれば、大人数いても方向性を間違えることなく進むことができると思います。
③ターゲットユーザー ④ユースケース
remindaryは「どんな時」に「誰」に使われるのだろうか。と思考した時に、やはり
・記念日を忘れたくないから、追加しておく
・通知が来て記念日を思い出す
・記念日には何かお祝いをする
という3つの使われるタイミングがあると思いました。
この3つのタイミングをコンセプトと照らし合わせることで、具体的にどのような機能要件が必要なのかを考えることができます。
そしてターゲット。世界中の誰しもに何かしらの記念日があると思います。
しかし、このアプリはスマートフォンで使われるもの。そして記念日を忘れがちだけど、お祝いはしたいと思うような年齢の人がターゲットだと考えました。それは、
・14歳くらいからのスマホ世代
・年齢や職業は問わない
この2つを考えました。他にも、社交的でサプライズ好きだけど多忙。みたいな特徴も考えましたが、このようにユニバーサルに使ってもらいたいアプリであるならば、敢えて特徴を限定してはいけないと考えました。
特徴を限定してしまうことによって、アプリのデザインに「癖」や「味」と言ったものが出てしまいます。もちろん、特定のターゲットに使ってもらいたいサービスであれば、そのペルソナに合わせた設計が必要になります。
しかしremindaryは、世界中の人に使ってもらって、記念日を忘れないことで少しでもお祝いする、される人が増えて、世界がもっと温かくなると信じています。なので、特定の誰かにターゲットを限定してしまうと、自分のアプリは一部にしか届かないアプリになってしまいます。
だから、できるだけ「無個性」であること。これが重要でした。
まとめると、ターゲットやユースケースを想定することは、具体的な機能やデザイン思想を固める助けになるということです。
2. 技術要件
⑤開発言語
自分は大学3年の時にHTMLとCSSをprogateやドットインストールで学び初めて、その後少しずつN予備校のプログラミング入門コースやオライリーの本を読んだりして勉強して、少しずつJavascriptもできるようになっていました。
といっても正直にお話すれば、よくあるTODOリストすら自力で作るのは難しいレベルでした。
スコープ？クラス？なにそれ？というレベルです。さらに、関数の引数とか戻り値とかもよく分かっていませんでした。ES2015以降のアロー関数とかもなんとなくそう記述するといいらしいぞ、くらいでした。
オライリーの本を熟読して写経しても、なんとなく分かった気でいただけです。
唯一作ったことがあるのは、後輩の入ゼミ試験の合格発表用に、自分の学籍番号を打ち込むと合格か不合格か出るような、まさに大学受験の合格発表システムのようなものを簡易的に作ってみたくらいです。
といっても、配列に学籍番号を入れて、for文とif文を組み合わせただけのものです。
あとは、自分でネットに落ちている教材を見ながらチュートリアルで色々と作ってみたくらいなんですね。タイマーとか、電卓っぽいものとか。
しかし、1から作れと言われたら正直できる自信がない。
つまりほぼノンプログラマーだった自分がアプリを作るには、どうしたらいいか必死で調べました。
基本的にはiosやandroidのアプリはSwiftやJavaで作られると知って、少し調べましたが。。。
まあJavascriptを読むのがやっとのような人間では、普通に無理ゲーだと思いました。
これをやっていては、絶対に2つのプラットフォームでの開発なんて無理だと。
であればどうにか、Javascriptで作れないかと模索していたところ、Facebook社が開発しているReact Nativeというのが良いらしいぞと知人から噂で聞きました。なんだそれはと思い調べてみると、Javascriptベースのライブラリで、1つのコードでiosとandroidの両OSで動くアプリが作れるという素晴らしいものでした。
いざ試してみようとチュートリアルを始めてみるも、当然の如くチンプンカンプン。
というのも、React NativeはReactというライブラリの延長線上にあるものだったのです。
Reactとは、「Learn Once, Write Anywhere」というのを謳っていて、一度学習すればどこでも使えるというものでした。Reactはコンポーネントベースといって、コンポーネントと言われるパズルのピースを組み合わせることで、様々なアプリケーションを作れるという代物。
これは自分にとてもしっくりきました。
必要な機能を持つパーツを作ってそれを組み合わせるというのは非常にわかりやすくて、実際に自分でもどうにかチュートリアルをクリアすることができました。
こんなに面白いのかと。
しかし、propsやstate、ライフサイクルなどの意味がわからず、またJSXのような独特な書き方に慣れる必要もありました。
普通のJavascriptでは変数を使っていくのですが、素人目にはpropsやstateも同じような動作をします。そもそもpropsがPropertiesのことだというのも分かっていませんでした。。
ただ、それでもSwiftやJavaをやるのは、まだ自分のレベルでは無理だと思ったので、とりあえずどうにかReact Nativeでやってみようと決断しました。
どうやって自分が開発できるまで成長したのかについては、開発編で後述します。
⑥開発プラットフォーム
よく開発する時に、初心者が一番つまずくのは環境構築だという話を聞きます。
それはそうですよね、HTMLやCSS、Javascriptなどのフロント言語しか知らないような人間が、babelやらwebpackとか言われても意味わかりません。
なんとかbabelだけは、バベルの塔にちなんでReactの特殊な書き方を普通のJavascriptに直してくれるのかな？という推測ができたくらいです。
そして自分も例に漏れず、環境構築で真っ先につまずく人間の1人でした。
Reactでチュートリアルをやってみた時に、create-react-appというコマンドをターミナルで打つだけですぐに始められるということが書いてあって、それでやってみたら本当にすぐに試すことができたので、とても感動したのを覚えています。
そこで、React NativeにもExpoという素晴らしい開発プラットフォームがあるのも知りました。
Expoは
・実機で簡単にデモを確認しながら作業が可能
・多くのライブラリを内包しているため、かなりの度合いでExpoだけで開発が完結する
・ビルドをはじめとする難しい工程を安全に、確実に自動化してくれる
という至れり尽くせりのプラットフォームです。
ただ、自分はその良さを伝えられても当時はまるで理解できなかったので、とりあえずExpoを使えば面倒ごとなく、create-react-appのようにすぐに開発ができると聞いたので、深く調べもせずにExpoにしようと決めた。くらいのノリでした。
ただ結論を先に言ってしまえば、自分のような開発初心者がExpoを使うのはほぼマストな気がしました。本当にこれがなければ、開発できなかったと言っても過言ではないです。
というのも、後述する開発編では、react-native-initのコマンドでも一応学習してみたことをお話しますが、ここでは割愛します。
⑦UIライブラリ
UIにもライブラリがあって、それらを使うと簡単にアプリを作れそうだということが、調べていく中で判明しました。といってもどの程度簡単になるのかも想像がつかないレベルだったので、
ここでもなんとなく、Qiitaの皆さんや色々なブログがおすすめしているから「Native Base」というものにしようと決めました。
Native Baseは1つのUIを書くだけで、iosとandroidそれぞれに最適化してくれるというものでした。なんか凄そう。そう思ったのも束の間で、
・チュートリアルを見てもさっぱり。どう使うのか理解できない。
→そもそもReact Nativeに慣れていない時だったので当たり前でした。
・iosとAndroidでそんなにUIの差がないアプリを作りたいから、それぞれに最適化されたら困ってしまう。
の2つの理由で、Native Baseは結局使いませんでした。
これも失敗の1つですね。
安易にライブラリを決めても、実際の開発になると使わなかったりするので、非常にここは難しいです。特に初心者は、このライブラリはここで使えそう。なんていう判断ができるわけもないので、意外とこれは開発しながら学んでいくしかないなと思いました。
まとめると、無理に最初からライブラリは選定しなくてもいいということです。
ただ後述しますが、選定はしなくても、ライブラリによる機能の実現可能性については調べておかないととんでもない目に遭います。。。泣
⑧対象OS・ストア
ここはとりあえずiosとandroidだなと考えました。
なぜWebにしなかったのかというと、「リマインド」するためには「通知」の機能が必要だったからです。アプリにすれば、プッシュ通知を飛ばせるというのは流石の自分も分かっていたので、アプリに決定しました。
また、リスト管理などの使い勝手を考えるとやはりアプリ以外にはないなと思いました。毎回webでアクセスして、ログインして、追加して、、、というのはあまりに体験を損ねるというか、記念日を管理するのに手間取っていては、使ってくれる人も使ってくれないだろうと思いました。
なので、iosとandroid対応にして、それぞれのストアに配信することが良いだろうという結論に至りました。
⑨その他技術要件
ここが企画に関して、というよりも今回の開発全般における一番のミスでした。
まず、今回のアプリはデータをアプリ内のローカルストレージに保存することで、
・サーバーとの通信は行わない
・オンラインのデータベースにデータを保存しない
・ログイン機能は実装しない
ことを実現しようと考えました。
その方が絶対に開発コストが下がると考えたからです。
フロントしかできない自分にとっては、ローカルストレージにデータを保存したり、そもそもReact Nativeを使うこと自体がハードル。開発コストを低減させることは何よりも重要課題でした。
ここで作りきらなければ、自分は絶対に中途半端で終わってしまう。
そう決めて臨んだアプリ開発で、開発コストが高くて途中で絶望してしまっては意味ないだろうと思いました。
なので、これでどうにか開発ギリギリできるかな？と少し安堵していました。
しかし、素人の要件定義が如何に甘いかを後に思い知らされることになります。
結論から言うと、iOSでは「通知」の設定は仕様上最大で64個までしかできないのです。
これが大きな痛手でした。なぜ通知が64個しか設定できないと問題なのかなどは、詳しくは開発編で後述しますが、このことを調べていなかったことによって、結局連鎖的にサーバーやデータベースなどのバックエンドの実装が不可欠になってしまい、途中で絶望することになります。
フロントエンドでメインの機能がどうにかできた…！データもローカルに保存できたし、あともう少し…！と思った矢先に判明したので、この時の絶望は本当に計り知れません。
とにかくここで学んだのは、「その機能は本当にそのライブラリなどで実現できるのか？」「ネイティブの仕様」の2つを事前に徹底的に調べ上げることです。
通知だけでなく、時間を選ぶpickerのライブラリも、iosは30分ごとの表示ができるのに、androidはそれができない。などの問題も多く発生しました。
正直、初心者はこういう壁に当たって、それを乗り越えられるか否かで、開発力というのが大きく変わってくる気がします。
壁を乗り越えた経験があれば、自分流の問題解決方法が出来上がってくるので、できるできないの判断や、どれくらい実装の時間がかかりそうなどの判断も少しずつできるようになってきます。
それでも、今回ぶつかった壁はあまりに自分にとっては大きくて、乗り越えるのにとても苦労しました。
これができないと、自分は前に進めない。就職せずに作りたいものを作るという、背水の陣を張ったからこそ、気合いで乗り越えられたのかなと思っています。
当時の要件定義。痛恨のミスでした。
3. UI・機能要件
⑩デザイン思想
アプリを万人に使ってもらいたい。そういう設計のためには「無個性」である必要がありそうだ。
というのは、ユースケースやターゲットの要件定義の部分で解説しました。
デザイン思想を決めようと思ったのは、コンセプトがプロダクト全体の方向性であるように、もっとそれを具体化して、ユーザーの体験を設計する上での思想を固めないといけないと思ったからです。
色々とアプリのデザインやUI、グラフィックのデザインについて調べていくうちに、アプリには、
・iOSのようなフラットデザイン
・googleなどのマテリアルデザイン
という大きく分けて2つの潮流があることを知りました。
そしてどちらもデザインガイドラインを出していて、英語でしたがとても参考になりました。
もともと自分はiphoneとandroidのどちらも使った経験があったので、両方の良さを知っていました。しかし、「無個性」という点ではフラットデザインの方がそのゴールを達成できる確率が高いと判断して、基本的にはフラットデザインを採用することにしました。
そして、アトミックデザインという概念があることも知りました。
これは主にReactの勉強をしているときにたどり着いた概念です。UIのコンポーネントをatom（原子）やmolecule（分子）といった階層構造してデザインパターンを統一することで、デザインがブレないようになります。
つまり、予めデザインされたパーツを組み合わせていくことで、自然とデザインに統一性が生まれます。これはフラットデザインを達成するために非常に重要であると考えました。
といっても、自分のアプリは最終的にそれほどページ数も多くないので、アトミックデザインと胸を張って言えるほどにその思想をフル活用できた訳ではありません。
ただ、その考え方は確実にremindaryのデザインの方向性を指し示してくれました。
自分はこのフラットデザインと、アトミックデザインの考え方を融合させることで、
・ひたすらシンプルに、機能的に。
・使っていて楽しい、ストレスのないデザイン
・統一されたモジュールやアイコン、色相でブレないアプリへと昇華
というデザイン思想を設定しました。
無個性とは、味がなくシンプルであること。シンプルであることは、機能的であること。
そして使っていて楽しく、ストレスを感じないゆったりとしたデザイン。さらに色や丸みなどをできるだけ統一することで、違和感のない自然なアプリになることを目指しました。
⑪デザインランゲージ
デザインランゲージとは、従うべきデザイン原則を定義しておくことで、
・迷いなく開発ができるようになり、意思決定の負荷を減らすことができる
・ユーザーにとってはデザインがパターン化されていることで、そこに親しみやすさや安心を感じる
というメリットがある、デザイン言語と呼ばれるものです。
自分はアトミックデザインを学んでいる最中に、ふとこの方法論に辿り着きました。
というのも、当たり前のように使うパーツや色がバラバラだとユーザーは無意識に不快感を覚えてしまうだろうし、調和が取れないアプリは人気がでないだろうと感じていたところ、ちょうどデザイン言語という方法論を知ったのです。
しかし自分はそれに挑戦したことがなかったので、プレゼンテーションの資料を作るKeynoteなどで親しみが深かったfont-familyやfont-weight、colorなどはせめて定義しようと考えました。
そして最初の時点で定義したものがこちらです。
最終的にアプリでは使っていない色ももちろん含まれていますが、真っ黒(#000)ではない少しグレーになることで、万人に受け入れてもらえるフラットなデザインを達成できると考えました。
やはり黒は主張が強い色なので、少し薄めてあげるだけで、背景色の白（#fff）とより調和できるようになります。
フォントについても、明朝体のような少し堅いものは避けて、やはりヒラギノ角ゴシック系統が、文字の明瞭度や温かい優しい印象という意味で最強だなと判断しました。
実際にデザイン言語を予め定義しておくことで、ぐっと開発が楽になったのは間違いありません。こういうパーツにはこの色、この重さと決まっているので、迷いなく作ることができました。書類化はできていませんが、余白部分（margin, padding）の使い方や角丸（border-radius）などは自分の中でも、デザイン言語が作っている間に出来上がっていました。
⑫主な機能
UI的な要素については、次のデザイン編で詳しく解説していきますが、ここでは最低限ベースとなる機能を定義した時の話をします。
重要な機能として挙げられるのは、
・記念日の追加、編集、削除機能
・写真・名前・日付・記念日の種類・重要度の設定機能
・簡単な設定だけで繰り替えしてくれる通知機能
・記念日のリスト表示と、重要度順・残り日数順による並び替え
の大きく分けて4つです。
これらが揃って始めて、remindaryとして成立するだろうということは疑いようがありませんでした。
この機能群は、
・ひたすら自分であればどういう機能がこのアプリに欲しいかを考え抜く
・様々なリマインドアプリや記念日アプリなどを研究する
ことで導き出しました。
１番の肝はやはり、「簡単な設定だけで繰り替えしてくれる通知機能」と「重要度」です。
記念日によっては、毎月通知して思い出させて欲しいくらいのものもあれば、1ヶ月くらい前に知りたいものもあれば、1週間前に思い出せば十分というような、重要度に違いが出てきます。
例えば、家族の誕生日はちょっと早めに思い出したい、少し仲がいいくらいの知人であれば1週間前に知れればいい。と思いますよね。
それらは、いちいち全て通知の時間や曜日を設定していてはキリがありません。
であれば、重要度を設定してあげるだけで、あとは通知を許可している限り自動でリマインドしてくれるというようなのが、何度もリマインド設定を毎年する必要もない、最高のユーザー体験になるんじゃないかなと考えました。
他については、自ずと記念日であればリスト表示だろう、追加や編集はもちろんあるだろうといった具合に、芋づる式に出てきました。
ここでも大事なのは、コンセプトから外れていないかを確認し続けることです。その機能は本当に必要なのか。それを自問し続けることが重要です。
そしてもちろん、定義したところで開発を進めていれば、思っていたのと違うこともあります。
しかし、重要で外せない機能というのは、最初に定義しておくべきだと思います。
【デザイン編】
企画と要件定義をした後は、画面のデザインを行いました。
こんな機能があればいい、というのは決まっていたので、あとはそれを画面に落とし込むだけ…とナメていると痛い目に遭います。
世の中には沢山の、イケてないデザインをしたアプリが沢山あります。
でも、その「イケてない」理由を深く考えたことはありませんでした。しかし実際には、その深く考えるプロセスというのが非常に重要だということを今回学びました。
例えば問題のいくつかはきっとこんなものです。
・色が多色すぎる
・文字の大きさが一定でない
・空白が少なくて読みづらい
・左揃えと中央揃えが共存しているように見える
・操作の方法がまるでわからない。
など。
私たちは毎日幾つもの洗練されたアプリを使っていると思います。でも毎日使うアプリ、例えばtwitterのようなものは、とても研究されていて、ユーザーが快適に使えるような設計がされています。ただでさえ便利なのに、日夜改善が未だに続けられているというのは、もはや想像がつかないレベルです。
しかし普段私たちはそのサービスを消費するだけで、それを消費するかどうかを、「使いやすいかどうか」「自分のニーズに合っているか」この2つくらいでほぼ決めているのではないでしょうか。だから、デザイナーでもない限りは深くこのデザインはこうなっているなーと考えることもありません。
話が逸れてしまいましたが、自分も例に漏れず、ただサービスを消費していただけの人間なので、ユーザビリティとかアクセシビリティとか、そんな言葉とは無縁の世界に生きていました。
ただ、幸いにも大学生の時にインターンや起業をしようと修行しているうちに、資料のデザインというのは少し齧っていたので、どうすれば綺麗に見えるか、くらいはなんとなくコツを掴んでいました。
ただ体系的に勉強したことはなかったので、ここで一度色彩論などから全て学び直す決意をしました。と言っても、やはりどこから勉強をしたら良いのかわかりませんでした。
自分と同じようにデザインを勉強したいと思っている人や、何かアプリなどのUI/UXを作りたいと思っている人のちょっとしたコンパスになればいいなと思います。
最終的にこんなに多くの画面をデザインできるようになりました。
1. 学習方法のまとめ
①基礎的なデザイン原則の載った本を読む
まずはデザインの基本的な考え方を知ることが大事です。そもそも、デザインとは何か？と聞かれた時に普通は絵を描くこととか、とにかくグラフィックの事だと思われがちです。
そして、デザインとアートがどのように違うのかについても、大体の人は説明できないのが現実です。そして勿論自分も同様でした。
そこで取っ掛かりとしたのが、基礎的なデザイン原則の載った本をいくつか買ったり借りたりして読む事です。いきなり実践に入るのではなく、教科書的なものを頭に入れてから、それをアウトプットしていくだけで全然習得のスピードが違ってきます。
例えるなら、教科書を勉強せずに数学の方程式を解こうとしても、いつか解けない問題がでてくる。そんな感じです。
逆に、人間の体の作りや認知に基づいて形成された原則であるので、センスがなくても誰でも、適切な時に適切な原則を使いこなせればデザインができる。その事実を知って、自分でもデザインができそうだなと思えました。
なぜなら、自分の美術の評価はいつも中の下くらいだったからです。笑
自分の場合は、本をkindleや大学の図書館で買ったり借りたりしました。
ここに5冊ご紹介します。
・なるほどデザイン＜目で見て楽しむ新しいデザインの本。＞ 筒井美希
・UIデザインの教科書 マルチデバイス時代のインターフェース設計 原田秀司
・世界の成功事例から学ぶ、スマホ以降のインターフェースデザイン BNN社
・Design Systems デジタルプロダクトのためのデザインシステム実践ガイド アラ・コルマトヴァ
・インターフェースデザインの心理学 Susan Weinschenk
それぞれがどのような本か、というのはリンク先のamazonのページで見てもらえればなんとなくわかると思います。
残り2冊はkindleで購入しています。
特に上2つは基礎的で、下3つは中級レベル、という感じがします。
全てデザインの基本的な考え方を教えて下さっているのですが、アプローチの仕方が本当に体系化された原則（色彩論とか）だったり、心理学だったり、システム論だったり、とにかくわかりやすいです。
ただ、基礎レベルからやることをお勧めします。基礎的な考え方を知った上で、中級レベルの本に進むとより理解が深まると思います。
②学んだ原則を既存のサービスから見つけ出して、イメトレを行う
学校の数学の教科書には、方程式とともに、具体例が必ず載っていましたよね。
あのように、何か新しいことを学んだら、それは実際どのような使われ方をするのかを見てみないと、頭の中でピンとこないんですね。
もちろんご紹介した本はデザインの本なので、事例もたくさん載っています。
しかし、本を読んでいる最中なので、あくまで「本を読んでいる気分でしかない」んですね。
だからどんなに事例をたくさん見ても、それが実社会のサンプルであっても、実践にに近い具体例として認識することは難しいと思います。
だからこそ、既存のサービスの中から学んだ原則を見つけ出して、イメトレを行うのが非常に重要なプロセスになると考えています。
自分がこれをやったのは、この段階をすっ飛ばしていざ実践してみようと思っても、分かったつもりがまるでデザイン出来ない現実に直面したからです。学んだはずなのに、どうしてか上手くできないんですね。
その点、例えば自分の好きなサービスやよく見ているウェブサイトで、
「あ、この原則が使われてる！」と発見するだけで、理解度が一つ上がります。
なぜなら、そのデザインがもたらす効果をリアルタイムで感じることで、逆に自分もこうデザインすればこういう結果が得られるというイメージトレーニングになるんです。
だから、Instagramでもなんでも、本当に毎日のように使うアプリやサービスはどんなデザイン原則を適用しているのか、それを研究してみるだけでも全然理解度が変わってきます。
そうしてやっと、練習に入ることができます。
③模倣練習
UI/UXデザインを行うにはいくつかの方法やツールがあると思います。
代表的なもので言えば、adobeのillustratorやphotoshop、XDなどが挙げられるでしょうか。
自分は、Udemyというオンライン教材を使ってillustratorやphotoshopの使い方を動画で学びました。やはり、真似をしながら基本的なデザインを練習していくことは非常に効率がいいです。
そして動画というのも素晴らしいです。Udemyは2倍速にできるので、例え40時間のコースだったとしても、単純な視聴時間で言えば20時間で終えることができます。作業も合わせれば30時間くらいでしょうか。
photoshopとillustratorで作った自作のグラデーション
睡眠・入浴・食事など以外を全て捧げれば、2日間で終わる計算になります。楽勝ですね！笑
でも本当に、それくらい集中して一気に覚えることは重要です。まず30時間もやり遂げたという自信が付きますし、なにより「できることが増えるのはとてつもなく楽しい」です。
なので、illustratorやphotoshopなんて違う世界の話だと思っていた自分が、少しずつだけれどデザインを作れるようになっていったのは非常に自信になりましたし、デザインの世界に足を踏み入れることができた！という実感が持てます。
自分は調べていく中で、デザインにはどうやらまずillustratorなどの使い方を覚えなければならないと判明したので、とりあえずインストールしてみたのですが、全く持って使い方がわかりませんでした。
本当に意味がわからないんです。ネットの勉強方法を見ても、まるで何から始めたらいいかわからないし、なにより記事だとここのボタンを押して、ここを押して…という指示が何処のことを指しているのか全くわかりませんでした。
それで泣きっ面になって探した結果、Udemyにたどり着きました。
プログラミングでも動画学習は非常に有効です。Udemyを見つけたのも、実はプログラミングを勉強している時でした。
自分が実際に行ったコースはNEST社の提供する、
「未経験からプロのWebデザイナーになる！400レッスン以上の完全マスターコース」
です。
合計41.5時間のコースですが、Udemyはなんとセールの時期に買うと本1冊分（¥1400くらい）で買えてしまいます。正直、やばいと思います。絶対に中身の価値は何十倍もあるのでおすすめです。
HTMLやCSSも一緒に学べるので、入門にはぴったりで、とにかく教えてもらいながらできるという安心感のお陰でスイスイ進めることができました。
当時はevernoteにメモしていた
こういう教材で大事なのは、途中でつまづいたり、分からなくなってもとりあえず一旦置いておいて、前に進むことです。
前に進んでいると、突然「あの時詰まっていたのはこれが原因か！」となる瞬間があります。本当にこの課題がクリアできないからと、ずっとそれと格闘し続けて40時間もあるビデオが進まない終わりが見えないなんていう方が気が削がれます。
自分も実際デザインや開発で上手くいかないことは沢山ありましたが、一回置いておいて、できることからやっていくだけでも全然進度が変わってくるので、進捗が少しでもあると気が楽になって、それが結果的に問題解決につながることが多かったです。
上記の教材でphotoshopの使い方を勉強した後は、adobe製品に少しずつ慣れてきている状態なので、adobeが提供している公式チュートリアルでillustratorの使い方も覚えました。
これも動画で学ぶことができるので、すぐに基本的な操作方法は覚えることができました。
といっても、この時点ではまだグラデーションを重ねたり、変形させたりのような実践的なテクニックは使えませんでしたが。
こうしてphotoshopとillustratorを学習した後は、いよいよadobe XDを勉強します。
イラレやフォトショは聞いたことあるけど、XDってなに？という人は多いと思います。XDは、Webサイトやアプリケーションのプロトタイプ（試作品）を作るためのツールです。
実際に画面を寸分違わず作り、さらにそこにボタンやスライドのようなインタラクションをつけて画面が実際にどう動いたり移り変わったりするかを、試すことができます。
このXDで先に画面を作ることで、プログラミングが非常に楽になるのは間違いありません。
XDの勉強には下記の1冊で十分でした。
・Adobe XD プロトタイピング実践ガイド 境裕司
この本は本当に懇切丁寧や解説を行ってくれる本です。ここまで動画でadobeツールに親しんだ後であれば、たとえ文章と写真しかなくても基本的に間違えることなく進めていくことができます。
プロトタイピングやデザインガイドライン、スプラッシュスクリーンなどの用語についても説明をしてくれているので、初心者必読の一冊です。
amazonの評価はぼちぼちですが、おすすめの一冊です。
ここまで、
・デザインの基本原則を本で学ぶ
・動画を見ながら模倣練習を行いデザインを理解する、ツールを学ぶ
というステップを行いました。
いよいよ実践ですね。
と言いたいところですが、このインプットの段階で自分がどんなことに失敗したのかをお話ししておきたいと思います。
・本を読むことに時間をかけない
・動画でつまづいても手を止めない
・作りたいものに関係ない、記事をいくつ読んでも意味がない
というあたりです。
・本を読むことに時間をかけない
とりあえず何も知らない段階なので本を読み込んで理解しようと、どうしても努めてしまいますよね。でも気を張らずに、楽しく読み流すくらいがちょうどいいと思います。あ、デザインってこういうものなんだ、こういう考え方があるんだ、こういうところに使われているんだ。というのをさらっと理解するのが大事です。一つ一つの原則を記憶しようというのは、本を読んでいる段階では無理です。
記憶だけならできるかもしれませんが、物事には理解度のレベルというのがあります。
これは英単語などと同じなのですが、英単語には、
・知らない
・知っている（見聞きしたことがある）
・理解している（読める）
・使える（話せる、書ける）
という段階がありますよね。
初心者が本を読むだけでは、どうしても知っているレベルまでしか基本的には到達できません。
なので、本はサラッと理解するために読んで、「後で辞書として参考にする」のが正解です。
実践の段階になった時に、要素要素を参照しながらやってみて、理解していく。それを何度も繰り返しているといつのまにか、参照しなくても使えるようになる。
そのステップを正しく踏むことが重要だと思います。
とにかく、本はサラッと読みましょう。実はその方が、圧倒的に早く成長できるんです。
・動画でつまづいても手を止めない
これについてはUdemyの説明をしていた時に説明したので、二度はお話しません。
とにかく動画では、模倣練習することで理解のレベルを「理解している」、あわよくば「使える」のレベルまで反復練習するのが目標です。1つのことにつまづいていると、無限にあるようにも思える道のりをいつまで経っても、消化できずにストレスが溜まるだけなので、適度に進めていくようにするのがオススメです。
・作りたいものに関係ない、記事をいくつ読んでも意味がない
デザインに関する記事を、調べればいくつも見かけると思います。ただ、それが自分の作りたいプロダクトと関係ない内容であれば、正直読んでも仕方ないです。
もちろん、後々参考になるかもしれません。けれども、インプットに時間を費やせば費やすほど、先ほどの理解レベルで言う「知っている」の幅が広がるだけで、いつまでも役には立ちません。読んで「理解する」レベルまで持っていけるなら話は別です。
例えば、adobeのXDを普段業務で使っていて、そのアップデートや使い方、トレンドを追うために記事を読むのであれば、すでに理解度が高いところにインプットをしているので、「理解している」レベルまで持って行きやすいです。
それは、「使える」「理解している」のレベルにある知識や技術があればあるほど、脳のシナプスが結びつくように、既にある理解と連携して整理して、理解まで落とし込めるからです。
自分はインプットを沢山してできる気になっていました。記事を沢山読むことで、勉強をした気になっていた時期がありました。どうしてもアウトプットは負荷の高いことなので、必要に駆られたり、強い目的意識がない限りはすることが困難です。
しかし大学時代の自分は、いかにそれが危険であるかを身を以て失敗して学んだので、今回のデザインに関してはその学びを活かすことができました。
もちろん、趣味程度や気晴らしに読むことは自由です。ただ、それを過度にして本来の目的が一向に進まないことだけは避けるべきです。
記事を読むより、手を動かした方が、断然成長できます。騙されたと思って、やってみてください。
②実践
ここまでデザインについての理解を深めて、いざ実践の時がきました。
remindaryをデザインする時のデザイン思想やコンセプトは固まっていたので、
あとは学んだ知識とツールを使って、実際にUI/UXを作るだけ！と思っていました。
ここでも案の定、上手くいかないんですね。やはり理解度が「知っている」「理解している」のレベルがほとんどなので、いざ「使う」となると、全くできませんでした。それでも、一つ一つのステップに分けて、自分がどんな失敗や試行錯誤を重ねてUI/UXを設計したかをお話しして行きたいと思います。正直、ここが一番晒すのが恥ずかしい部分です。笑
黒歴史と言っても過言ではないほどに、下手くそな状態からのスタートだったので、暖かい目で読んでいただければ幸いです。
そして、まだ何もデザインとかやったことない人も安心してください。
こんな下手くそだった人でも、ちゃんとこういうステップを踏めばそれなりにできるんだということを証明します。
①ペーパーモック
じゃあ早速画面をadobe XDで作ろう！と思っても、どんなページを作ればいいのかがそもそも分かりませんでした。なので、定義した機能に合うように、いくつか画面を紙に書き出してみることにしました。
紙で試作品を作ってみることをペーパーモックと呼びます。
ペーパモックのことを知っていたのは、大学時代に起業しようとしていた時に、試作品を作る方法の1つとして学んだからです。学んだと言っても、こういう使い方があるんだ、というくらいで、実践したことはほとんどありません。
ただ、私たちは普段生活しているだけでも、何かを説明する時に紙やホワイトボード、黒板にこういう感じ！という具合に説明する図を描くと思います。あれを自分の確認用に使う感じです。
実際にペーパーモックを行うために自分は最初、普通のA4のチラ裏になんとなく枠を書いてみていましたが、それだとこのボタンを押すと、このページに飛ぶというのを矢印で書けます。しかし、実際のスマホのように、持ったりすることはできません。
ここがポイントで、自分はそこからスマホの大きさより少し大きめのPost-itを100均一で買ってきて、1枚1枚にとりあえず適当に書き出していきました。
スマホと同じくらいの紙なら、実際に手にもって（薄っぺらいですが）試すことができます。
このボタンは押しやすい、押しづらい。意外と使いにくいぞ、なんていうのがすぐにわかります。
実際に書いた当時のPost-itの写真
それに100均一のpost-itならひたすら使い捨てにできるので、何枚も書けますし、
何より速さがあります。adobeXDも確かに高速プロトタイピングができますが、
あくまでデジタルなので意外と時間がかかります。なぜなら細かい配置やサイズのバランスを地味に気にしてしまうからです。
adobeXDなら大体10分で1枚の画面を試せるとしても、ペーパーモックなら4 ~ 5枚くらいは書けます。それだけPDCAを多く回せるというのはすごいことです。
使い方は、1画面につき1枚という感じです。ただ、これがいいあれがいいと試行錯誤するうちに、同じ機能の画面でも、何枚か書くことになると思います。
こうして色々な画面を書いたら、よさそうだなと思った渾身の1画面につき1枚を、
並べてこれで全てこと足りるかということを考えます。
今回重要なのは、こういう機能は大体こういう画面で実装する。そして、全て網羅しているということが重要です。このボタンを押せばこのページに行くというのが、全て書かれていることで、後でXDを使う時にページ漏れがなくなります。
自分は並べるのに自分の部屋のドアにペタペタと貼っていました。
下の写真は、その時の一部です。ホーム画面のパターン出しとかをしている写真ですね、字も絵も汚くて本当に恥ずかしいですが、皆さんのデザインに感じているハードルを下げるお手伝いができれば幸いです。
ペーパーモックの次に行うことは、adobeXDで実際にサイズや細かいデザインのパターン出しをします。例えば、remindaryであればこの下の写真のようにカード式かグリッド式にホーム画面に記念日一覧を想定した方が良さそうなことまでは、ペーパーモックでわかっていました。
しかし、厳密にスマホの正確なサイズに合わせて作ったわけではないので、1画面にカードが何枚入るのか、などはadobeXDで細かく行った方がよいです。
ほぼ白黒の最初のモックだけで、これだけのパターンを出しました。
XDの良い点は、グリッドシステムと言って、一つカードなどのコンポーネント（部品）を作ればそれを簡単に複製できることです。さらにページ自体も複製が簡単なので、使いまわして少しの変更を行い、パターン出しを行うにはもってこいです。
このことによって、些細な変更を繰り返したパターンをいくつか用意して、それを使ってスマホで実際に確認する機能を使い、画面を決定していきました。
ここまでは割と迷いなく進むことができました。白黒で色も使っていない本当にデザインの基本原則だけを試してみていただけだからです。
本当に文字と形を組み合わせただけの、パターン出しでした。
タップのしやすさや、角丸による柔らかさ、文字の大きさや太さの調和、シャドウをつけるかつけないかなど、とても練習になりました。
何よりも自分でアプリのデザインを始められている！という感動が大きかったです。
少しずつ自分のアイデアが形になっていく時の喜びが尋常ではないことに、ここで気づくことができました。
と、調子に乗っていたのですが、自分はメイン機能は網羅していたものの、サブのメニューやそこに付随する通知設定や言語設定をど忘れしていました。
次の本格的なUIデザインではそのど忘れに気づき、それも急ピッチで作らなければなりませんでした。
本格的なデザインになると、色を使いこなしたり、UIkitを使っていくことになるのですが、それもどこから始めればいいのかわかりませんでした。既存のアプリのような完成度の高い画面を作るには何が足りないのか。再現性の高いUIを作るにはどうしたらいいのか。
「アプリデザイン XD」
などで検索をかけると、意外とすんなり解説記事が見つかって、プロトタイプにはこういうUIKitを使おうとかも書いてあります。
それに、前述したXDの解説本にも実は同じことが書いてあるので、それを見ながらやれば済みました。
ただ気をつけたのは、一応appleやgoogleのデザインガイドラインを読んでから行ったことです。英語なのでわかりづらいですが、日本語でもちらほら解説記事があるので参考にします。
そして、いくつかのページを見ていく中で、どうやら色彩はこういう色を使えばいいとか、そもそもappleなどがiOSのUI作成Kitを無償提供していたりました。
それと自作のパーツの組み合わせると、かなり本格的なデザインを作ることに成功しました。
色やUIKitを使った実際のモックアップ
やはり、ヘッダーなどはUIKitから持ってくると明らかに違いが明白になりますね。
こうして自分のデザインが本物のアプリでありそうな感じになってくると、初学者としては喜びを隠せません。
さらにデザインするときは、様々なアプリをダウンロードしてみて参考にすると良いです。特に同じような記念日のアプリだったり、リスト形式のTODOアプリはめちゃくちゃ参考になりました。
例えば並び替えのアクションシートや、左上のアイコンを押すと出てくるドローワーメニューなどは、既存のアプリによく見ることができます。
並び替えのアクションシートのモックアップ
既存のアプリでよく見るということは、すでにユーザーはその動作やデザインに慣れ親しんでいることになります。ここを押せばこれが表示される。というような選択肢をユーザーが把握しているなら、それを使うことがベストです。
なので、「カードならスワイプすれば何か起こるだろう」というのをユーザーは肌感覚で理解しています。自分もXDで作ったものをスマホで体験することで、それが不自然でないことを確認しました。
XDで作るときに難しかったのは、
・アートボードを適当に複製したり、コンポーネントの名前を共通化していないと、アニメーションなどのプロトタイピングで動かないことがある。
・パターン出しをすると、その分プロトタイピングのための設定が膨大になってしまう。
という2点で、これらは非常にやっかいでした。
解決策というのは特にありませんが、あえていうなら、
・コンポーネントはグループ化をして共有の命名を行う。例えば、追加ボタンなら、「add button」のように、わかりやすく共通の命名を心がける。
くらいです。
2つ目の課題の解決策はいまだに見つけられていません。
とりあえず時間を使ってパターン全てに適用させていました。ただ、数パターンに留めておくのが正解だとは思います。何十パターンも検証していたら、その設定作業だけで日が暮れます。
粗方のデザインが出来上がってきた後に、デザインを更に磨くよい方法としては、
誰かに見てもらって、フィードバックを受ける。
ことが挙げられます。
ただしフィードバックはあまりに多くの人に聞いたり、素人に聞いてもこうしたらいいんじゃないかという意見が同一ポイントにおいて衝突したりして、余計なストレスになったりします。
以前にそのような経験がある人は、そこを避けることができると思います。
自分は略歴のところで出てきた師匠がいたので、その人に見てもらいました。すると、いくつかの問題点が上がってきました。
・色盲の人対応も含めて、コンセプト的にオレンジ色は本当にメインカラーとして適切なのか？
・重要度の表示は文字や数字である必要はあるのか？
・重要度は設定の時に、頻度も一緒に確認できたら便利ではないか？
大きく分けてこの3点です。
逆にそれ以外のUI/UXについては高評価を頂くことができたので、上記の問題を解決すべく、新たに、
・メインカラーは、個性が出ないグレーに変更。
・重要度は文字や数字ではなく、色のみで表す。
・重要度設定を独立した画面で行えるように設計。
という対策を考えて、XDでもう一度実行に移しました。
特に色盲対策については、ユニバーサルデザインのガイドラインを調べて、4色を使った時に見分けられるパターンについて調べて、この4色のセットを導入しました。
こうして、改善したものを改めて師匠に見てもらい、これは行けそうだと判断してから開発に移ることになりました。デザインは、おそらくクオリティを上げようと思えばキリのない勝負です。いかに短期間で想定されるUXを最大まで高めるデザインを行えるかが勝負だと思います。その後は一気に開発して、ユーザーの実際のフィードバックをもらうのが最善でしょう。
つまり、一定のクオリティを見極めて、短期間で落とし込み開発に移すというのも、優れたデザイナーなのではないかということです。
自分のような初学者には学習から含めるとかなりの時間がかかってしまいますが、一定の世間に出せそうなクオリティまでくればあとは、ユーザーが教えてくれると知り、高速でPDCAを回すことが最短で最上のUXにたどり着く方法だと思います。
以上のデザイン編（実践）をまとめると、
・まずは紙で機能に合わせたページを描いてみる
・そしてページごとにUIのパターン出しを行い、
・XDで本格的に設計して、プロトタイピングまで行う
・その際にも必ずパターン出しを行う
・他者（理想は詳しい人1〜2人）にフィードバックをもらう
・PDCAを回して、ある程度のところまできたら開発に移る
というポイントにまとめられるかと思います。さて、ここからはいよいよ開発です。
【開発編】
プログラミングは企画編で前述したように、HTMLやCSS、Javascriptの文法がなんとなく分かっていただけで、静的なWebサイトすら、ペライチの文字と画像だけのようなサイトも作ったことがありませんでした。
そんな自分が、仮にもiOSとAndroidアプリを作ろうというのだから、道のりはとても長いはずです。実際に、めちゃくちゃ勉強しました。
プログラミングの勉強に関しては、自分は大学3年次から含めてたくさん遠回りをしてきたので、今から逆算すればこれなら最短ルートかもというのがなんとなくわかります。
なので、ここからは自分がどうやって勉強して、こういう失敗や成功を感じたから、みなさんはこうするといいかも。というのをお話していきます。
まず、実際に自分がremindaryを開発するのに使ったのは、
・React Native
・Expo
・Firebase
というライブラリと、開発プラットフォームです。
つまり以下では、この3つを使ってアプリ開発できるようになるまでの学習方法やツールがわかります。ちなみにエディタはVSCodeを使っています。
ただ、自分はなんとなく英語が聞き取れたり、専門用語だらけでなければ英文を理解できる英語力があったことだけは、前提としてお伝えしておきます。何故なら、プログラミングの学習には英語は避けては通れないものであり、自分のこの前提をお伝えしておくことで、これを読んでいる皆さんが自分自身の学習計画を立てる際に、自分の英語力を計算に入れる助けになると思ったからです。
それでは、一つ一つ順を追って説明していきます。
学習方法のまとめ
①HTMLやCSS、JavaScript、LINUXの基礎学習
【使うツール・必要金額】
・progateとドットインストールの無料版
・Udemyの「未経験からプロのWebデザイナーになる！400レッスン以上の完全マスターコース」（セール時¥1400、買い切り）
・N予備校のプログラミングコース（約¥1000/月）
まず私自身が行ったように、HTMLやCSSでプログラミングを触ってみるところから入るといいと思います。
それには、progateとドットインストールの無料の範囲内で、基礎的なプログラミングの体験を行うのが手っ取り早いです。有料会員になれば中級編やPHPなども勉強できると思いますが、自分は有料編もやってみて思ったのは、「ちょっとプログラミングができるようになった気分」になるだけです。正直に言えば、あまり実践レベルの内容はありませんでした。
progateやドットインストールだけいくらやっても、いつまで経っても本格的な開発には辿り着けないと思います。
確かに、始めた頃の自分は本当にゼロからだったので、1つ1つのレッスンが短く構成されているこれら2つのサービスで勉強をしていると、すぐに結果に表れてすごい！となるんです。だから、課金すればもっとできるようになるのかも。。。？と期待を抱きます。
そして課金をして、でも開発ができるようにいつまでもならないからだらだら続けてしまう。
そんな構造になっているんじゃないでしょうか。0から1になるサービスとしてはすごいと思いますが、それはあくまで無料の範囲内で十分だなと思ったのが正直なところです。
はっきり言って、約¥1000/月の価値はありません。
なので、Progateとドットインストールの無料範囲内で、
・HTML&CSS
・Command Line（ターミナル）
を学習しましょう。
大きなモニターがあるとめちゃめちゃ捗ります。
PHPやRubyなんかは、それらを使って開発したいものがある人は触ってみてもいいかもしれませんが、今回自分はあくまでReact Nativeなどを使ったアプリ開発ができるまでの道のりをお話ししているので、これ以上は何も言いません。
自分はProgateを始めてから2ヶ月ほど課金しても、何も作れませんでした。
作りたいものが明確に決まっていないのに、なんとなくプログラミングを勉強しても効率的な学習はできない。
ということに、さらに半年ほどしてやっと気づきました。これほどに、たった初歩のHTMLやCSSをだらだら学んでしまったのは、まさに開発したい目標がなにもなかったからです。
アウトプットの目標すらなければ、インプットの量も増えません。なぜならやる意義がなければやる気も起きないからです。
ここで自分は失敗を活かし、大学3年の冬には作りたいものがないけどとりあえず勉強をするには独学は向いていないかもしれないと思いました。
それで、プログラミングスクールを調べたり、「誰かに教わる」ことがあれば、強制的にやるようになるんじゃないかなとも期待しました。
しかし、幸いなことにUdemyという素晴らしいオンライン学習サービスを知り、そこで沢山のプログラミングコースが格安で提供されていることを知ります。
動画で講師と一緒に何かを作り上げるなら、自分でもできるだろうと考えて、少しでも実践的なことをお金をかけずにするのはこれだと、Udemyでの学習を始めました。
まとめると、プログラミングというものに触れることができたら、次は動画で指導を受けながら、講師と一緒にプログラミングをしていくUdemyのオンライン学習が良さげだということです。
後述するN予備校ももちろんオンライン学習なのですが、レベル感的にUdemyのコースから始めることをお勧めしています。
さらに、この
「未経験からプロのWebデザイナーになる！400レッスン以上の完全マスターコース」
は、デザイン編でも前述したphotoshopの使い方も一緒に学べて、プログラミング含め、基礎から一歩一歩丁寧に実践しながらレベルアップしていくコースです。
是非セール時に買って、このコースで基礎的なWebサイトのデザインから開発までをこなしてみてください。自分はこれをやったことによって、少し自信もつきましたし、講師の真似とは言え、自分も同じものが作れるようになったのだと感動したものです。
特にHTMLやCSSだけならわかりやすいので、表面的なサイトだけならなんとか作れるようになって、それもまた進歩として嬉しくなると思います。
その後は、コースでも学んだけれどよくわからなかったJavaScriptについて勉強を深めることになると思います。
JavaScriptの学習教材は世の中にこれでもかというほど溢れていますが、本などが必要になるのは、N予備校で勉強した後じゃないかなと思っています。
本は初回学習用ではなく、あくまで復習用に使うくらいでよくて、それも1冊で十分だと思います。
本を買うなら、これがわかりやすかったです。
N予備校は、ドワンゴというニコニコ動画を運営している会社が運営しているオンライン予備校のようなものです。プログラミングコースだけでなく、大学受験コースもあって、これも難関私大や国公立に対応できるくらいのレベル感です。正直、独学で進められる人なら有名予備校に何十万ものお金を払って通う価値がなさそうなくらいです。
プログラミングコースの出来は、自分的には神がかっているのではないかと思うくらいです。というか、本当に約¥1000/月とかでいいの？と思ってしまうくらい質が高いです。
執筆時点での私が思うに、プログラミング入門コースに十万円とか払うTechなんちゃら系の方が恐らく質が低い気がします。
つまり、N予備校の費用対効果は巷のプログラミングスクールに比べて10000%を超える可能性が十分にあります。単純計算で100倍ですね。笑
話がN予備校信者のようになってしまいましたが、本当に内容は素晴らしいです。
無料分だけでもかなりのボリュームなので、是非騙されたと思って試してみるといいと思います。
第1章〜第5章までこれをやりきれば、かなりの自信が付いていると思います。
なにせサーバーサイドまでやるのですから。サーバーサイドって何って人もいると思いますが、とりあえず、プログラミングを本気で覚えたい人がいれば、何も言わずにやってみてください。
これ初学者にとっては初見だろうな〜という用語もほとんど全て解説付きです。
2倍速もできるので、とりあえず2倍やってわからなければ一時停止すればいいです。
N予備校のプログラミングコースをクリアすることで、Web開発の知識がかなり一通り網羅されます。そして初めて、次のステップであるReactなどを学習することができるようになると思います。
もちろん、ここまでたった3つのツールを使うだけで、ある程度の知識がつくことは間違い無いです。おそらく、全部合わせると200~300時間くらいはこなすことになるんじゃないでしょうか。
早朝に起きてコーヒーを飲みながらだと、自然とパソコンに向かえます。
ただし、本当の意味でプログラミングができると自信を持つには、1人で試行錯誤して、バグが出まくったけど全部修正してやっと1つ開発できた。という経験が必要だと思います。
なのでReactなどのライブラリを学習する前に、ここまでで一度実践に移るのもいいかもしれません。それには、
1. 短期間で集中的にこなして終わらせて、自分だけのサイトやWebアプリを開発を進行させる。
2. ぼちぼちやるけど、同時に自分だけのサイトやWebアプリを開発を進行させる。
のどちらかのアプローチがいいと思います。
プログラミングはどんなにインプットしても、アウトプットの段階になって初めてわかるような苦労がものすごく多いです。
自分は実践にいつまでも進む勇気がなかったので、だらだらとN予備校をこなしても一向にプログラミングで開発ができると言えるレベルには達することができませんでした。
皆さんはぜひ実践も同時に行ってみてください。
②ReactとReact Native、Expoの学習
前述のステップでプログラミングに入門、または実践的な開発まで行って基礎ができたら、次はReactやReact Nativeのようなライブラリを学習します。自分はReactを知人から薦められて、JavaScriptがまともにできない時代（大学4年夏くらい）に勉強を始めました。
基本的に公式チュートリアルで学習したり、Qiitaの記事を読んでみたりしたり、オライリーの本を買って読んでみたりしましたが、その当時は全くReactの理解ができませんでした。もはや文法すら、わかりませんでした。というのも、JavaScript単体をやっていても出てこないような、ライフサイクルや、stateとpropsの違いがどうしても分からなかったのです。
その解決策としては、「覚えるまでひたすら量を実践的にこなす」ことしかないと思います。いくらQiitaなどのわかりやすい解説記事を読んでも分からなかった自分は、手を動かしながら覚えるのが一番性に合っていたみたいです。
ここからは、本当に前述のHTMLやCSS、JavaScriptをある程度までは使えるようになった人が進まないと、新しいことが沢山出てくるので進みが遅くなったり、使いこなせなくてやる気がなくなってしまう可能性があります。自分は本当に、分からなすぎてやる気が出ずに大学生活に逃避してしまったくらいです。なので是非、せめてN予備校のプログラミング入門コースは全て終わらせてから行うことをお勧めします。
【使うツール・必要金額】
・公式チュートリアル、ドキュメント
・Udemy 「Master React & Redux」（セール時¥1400、買い切り）
・Udemy「React Native - The Practical Guide」（セール時¥1400、買い切り）
Reactの公式チュートリアルは学ぶなら、絶対試してみるべきです。
ここでReact自体がどのようなライブラリなのか、などの内容を説明することはしません。ただ、VueなどよりもReactをお勧めするのは以下の理由です。
・「Learn Once, Write Anywhere」は本当だから。
一度学べば、どこでも書ける。Reactの特徴的な記法や文法などの使い方を一度覚えてしまえば、React Nativeでアプリも作れます。事実、ほとんど新規の学習コストなくアプリを作れると思います。
・JSXの記法がすごいしっくりくる。簡単。
自分はReactのJSX記法がとてもしっくりきたので（ HTMLより簡単かもしれないと思った）、Reactをお勧めします。React Nativeになると、さらにDOMなどを意識しなくても意外と書けたりするので、非常にお勧めです。 Vueも触ったことがあるのですが、いわゆるHTMLタグが半端なく入れ子状態になったりして、意外と見辛くなってデバッグも大変なことがあるので、DOMやHTMLが苦手な自分は、極論を言えばReactしか使いたくないと思っているくらいです。笑
最初の入りとしては、公式チュートリアルが神がかっています。React系列を学習するときには、日本語訳もあるので一度は行うことをお勧めします。
公式チュートリアルを行うと、ざっとReactの使い方について触れることができると思います。その思想や基本的な使い方に触れて、こういうものなんだな。と覚えられればいいと思います。
React Nativeについても同様の手順ですが、しっかりとReactを先に学習してからにしましょう。
公式チュートリアル後は、基本的に何かを一度作ってみるといいと思います。そのために、いくつもの実践があるUdemyのコースはオススメです。ここまで読んだ方はわかると思いますが、Udemyに本当にお世話になっています。
Udemyのコースは、
・Udemy 「Master React & Redux」（セール時¥1400、買い切り）
・Udemy「React Native - The Practical Guide」（セール時¥1400、買い切り）
の2つで、それぞれReactとReact Nativeについてです。
React Nativeのコースの一部
注意点はどちらも英語なので、英語で解説を聞いて理解するレベルがないと、難しいと思います。質は本当に保証したくなるくらい上質なコースなのですが、私達日本人には言語の壁がここでものしかかってきますね。自分も完璧に理解しながらではないですが、手を動かしているうちにこういうことか、と納得の連続だったので、挑戦してみる価値はあると思います。
もちろん、日本語のコースであれば、
・「フロントエンジニアのためのReact・Reduxアプリケーション開発入門」
・「React NativeでiOS / Android アプリ開発をゼロから始めよう！」
の2つがありますが、ボリュームがやはり英語のコースに比べると薄いです。
英語のコースは平均して40時間くらいなのに対して、日本語のコースは10時間くらいです。
やはり40時間のコースを頑張って最後までついていく方が圧倒的にスキルは伸びると思います。
自分の行なった上記の英語のコース2つは、先生もわかりやすく、ステップバイステップで進めてくれます。さらに、コースの中で実際に作る作品の数や、使うライブラリの数も非常に多いので、ライブラリってこういう風に使うんだ！というのが身にしみてわかります。
というか自分はここまで来てやっとライブラリについて理解したくらいです。
日本語のコースでもきっと大丈夫だとは思いますが、ようは自分が量をこなせるかが問題です。ただ、コース内容を見た感じによるとあまり実践的な開発は行わない、チュートリアルの延長線上のような解説しかないなという印象です。なので、日本語のコースで進める人は、ぜひ何かご自分でも実践練習をコースが終わった後に行うようにしてみてください。
ぜひ英語を勉強してプログラミング学習を効率化しましょう。
Udemyのオンラインコースを進めていて失敗したのは、途中で一度時間をあけてしまうと、内容を忘れてしまってもう一度見直しになってしまうことです。本であれば、その章をちょっと見直すだけで割と思い出すことも、復習することも簡単ですが、オンラインコースだとどのレッスンにその内容があったかをまずは思い出して、その後にさらに視聴し直すという手間がかかります。自分はReactを学習する段階で、最初に「React - The Complete Guide」というReact Nativeのコースの講師と同じ人が講師をやっているコースで勉強していました。
しかし、最初のうちはやはり慣れないので、なんとなくで進めてしまっていて、やる気が起きずにどんどんレッスンを行わなくなって、折角勉強したことをまるっと忘れてしまうこともありました。Reduxも含めて、内容が本当に理解できないと、なぜか進めなくなるんですね。
ただ、どこかでReactの使い方が腑に落ちるタイミングがくると思うので、そこまでの辛抱です。
あと、先述の「React - The Complete Guide」コースは、講師も素晴らしいのですが、いきなりReactをこのコースで始めるのは正直敷居が高いなと思ったりもしました。なので、「Master React & Redux」のコースをオススメします。こちらはReduxに入るまでの実践をたっぷりを行なって、本当に素のReactをステップバイステップで教えてくれます。講師の人がインド系？なのか訛りがちょっとありますが、内容は本当にわかりやすいので安心してください。
同じようにReact Nativeも公式チュートリアル→Udemyのコースという手順を踏めば、あとは実践的な開発に移るだけです。
「React Native - The Practical Guide」のコースは、ExpoというReact Nativeでのアプリ開発をめちゃくちゃ簡単にしてくれるプラットフォームを使って教えてくれるので、非常に実践的かつ取っ付きやすい内容になっています。実は、自分が始めた今年3月の時点ではExpoを使わずに難しい環境構築を行うコース内容になっていたのですが、5月くらいになって急にアップデートをしてExpoメインで教えてくれる内容に大幅アップデートがありました。
これによって、環境構築をほぼする必要がなく、いきなりReact Nativeでの開発を行うことができます。Expoを使うのは本当にコマンド1つで出来てしまうので、あとは画面を見ながら進めればいいだけです。
たったこれだけのコードで環境構築が終わってしまう。
こういう機能を実現したいと思っても、意外と英語ですら殆どヒントが載っていないこともあります。そういう時にめげずに、考えて工夫して開発できるかはあなた次第です。
ただ、バグがいくつ起ころうとも、機能の実現方法がわからなくても、調べまくって、考えまくって開発できるかが、プログラミング学習の1つの壁だと思います。
英語でも、文法や単語を学ぶだけならどうにかできると思います。しかし、さらにライティングやスピーキングとなると、学んだものを組み合わせていかないといけないので、出来る人はさらに限られてきます。つまり、そのような壁がプログラミングにもあるということです。
ただ、この①から②のステップを確実にこなすことさえできれば、絶対にアプリを作れるレベルになると思います。Webも勿論です。
自分は1年半という時間があったにも関わらず、だらだらと進めてしまった結果、習得に時間がかかりました。それは、最後までプログラミングを使って作りたいものが明確になかったからです。
つまり一番大事なのは、これを開発したいという明確な目標を持つことです。それに必要なスキルセットはなんなのか、それを学ぶための学習教材はなんなのか、逆算しましょう。
目標があれば、最短で学習できて、しかも実践まで行えます。実践さえできれば、自ずと壁は超えられます。
大学生であったり、集中して時間を使える人なら3ヶ月くらいで終わらせられると思いますので、ぜひ目標を持って挑戦してみてください。
開発
いよいよ開発です。
自分は企画からデザインを経て開発に至るまで、約2ヶ月ほどかかっています。
実質的な開発期間は、だいたい3.5ヶ月くらいです。
勿論、今この記事を書いている瞬間にも改善点はあるので、開発は終わらないのですが、一定の区切りという意味で3.5ヶ月です。
今年の6月中旬くらいまでに、一通りのプログラミングの学習を済ませて、やっと開発に取り掛かることができました。
それまでアウトプットからひたすら逃げてしまっていた自分にとっては、本当に開発できるのかどうか。というのは大きな不安でした。
ただ、要件定義をして、サーバーやデータベースとのやりとりも行わずに開発できるだろうと思い込んでいたのと、「ここで1つやり切らないと、いつまでたっても中途半端の半人前」で「就職をしなかった」という背水の陣があったことで、どうにか着手することができました。
いざ作り始めるとなると、やはり最初に取り掛かるべきは表面の部分だと思います。
アプリは機能の関数自体を先に作ったとしても、表面的なパーツが動いたり、ページ遷移したりといったインタラクションがないと、デバッグしづらいです。
なので表面のパーツだけ先に作って、細かい機能（例えばフォームのバリデーション）はもう後から作ればいいかなと考えました。
実際にそれは半分正解でしたが、ページを作っていく上で、結局機能も実装しなければならないこともありました。
しかし、大体のボタンは（alert(‘押されました’)）など適当なフィードバックがあるように設定しておいて、とりあえず押せば動くというのを確かめられるようにしておきました。
ボタンの動きは、最初は適当な関数を実装してコンソールを確認。
それとExpoで自分はシミュレータは最初使わずに、自分の使っているiphone7にExpoのクライアントアプリをインストールして、実機で確認しながら行っていました。
この機能は本当に便利で、新しく更新したらcommand + Sで保存するとすぐに実機で更新したものを確認できます。
これがあるのとないのでは大きく開発速度に違いが出てくると思います。Expoを使わずに行う開発もできますが、環境構築をしたり、新しいライブラリを使う時にxcodeで追加操作をしたりと大変です。
もちろんExpoにもデメリットはありますが、初心者な自分が行うにはExpoはもうこれしかないと言えるものでした。
自分はまず、
記念日の一覧が並んでいるホーム画面を作るところから始めました。
といっても、初手から既に難しかったです。
そして、その中でも最初はヘッダーから作ることにしました。
ただどうやって作ったらいいのかも分からなかったので、安直に「react native header」で検索しました。
なにか実現したいけどどう作ったらいいのか分からない時は、とりあえず検索をかけてみるといいと思います。大体アプリで基本的に必要とされるようなものについては、既にライブラリがあるものです。
今回ヘッダー部分では、react-native-elementsというライブラリにお世話になりました。
いわゆるNative baseのようなUIライブラリですね。これをディレクトリにインストールして、使いたいところでimportして、propsをいじってあげるだけ。簡単ですね！
本当に、ヘッダー以外でもこのライブラリには超お世話になりました。Native Baseよりも使い勝手が良さそうだったので、こちらにしたのは正解でした。
ライブラリってそもそもどうやって使うの、というのはそれぞれのライブラリに、「このコマンドでインストールして、その後はこうやって使ってね」というのが書いてあるので、そのままやるだけでした。だいたいIntroductionやGet Startedというページに書いてあります。
英語が苦手でも、qiitaの記事を探せば使い方を日本語で説明してくださっている方が多いので、ぜひ調べてみてください。
そうして調べてヘッダーを作ってみました。
こんな感じですね。
かなりいい感じのUIが作れました。
ヘッダーは割とすぐにできたので、次にカードを作ることにしました。
記念日カードもやはり、react-native-elementsにお世話になって、ListItemというコンポーネントを使いました。これは自分が実現したい、左に画像を置いて、真ん中には文字を置いて、右には重要度を置くというのを簡単にleft avatarなどで設定できました。カード1つのUIを作るのはそれほど難しくはなかったです。
ただ、カードはLINEのように左右のスワイプを実現したかったので、それ専用のライブラリを探すことになりました。ここでもgoogleで「react native swipe」みたいに検索します。すると、いくつか候補が出てくるので、ライブラリのreadmeを読んでみるのですが、いまいち使い方がピンと来ませんでした。そこで、youtubeを使って同じように検索すると、実例を見せてくれている動画があるので、それをみながら「こうすると左スワイプが実現できるのかなるほど！」と理解して、先ほどのListItemをreact-native-swipeoutというライブラリで括ってあげると、簡単に実装することができました。
中のpropsもやはり、今はreact-native-elementsから持ってきたIconを設定してあげて、タップしてもalertが出るくらいにしておいてあげました。
うちの実家の猫のロイです。笑
ここまではどうにかなったのですが、次が非常に厄介でした。
記念日のカード1枚はできたので、次はそれのリスト表示を作る必要がありました。
このリスト表示はとても難しかったです。React NativeのライブラリにビルトインであるFlatListのコンポーネントを使ったのですが、必要なpropsにkeyやdata、extraDataなど様々あって、どれをどう使えば実現できるのかまるで分かりませんでした。
こればっかりは、本当に試行錯誤を重ねるしかありませんでした。検索して、使い方の事例をたくさん調べながら、あーだこーだとテストをしてやっと開発できました。
結局、この時はListItemのコンポーネントをFlatListへ持ってきて、それをdataとして入れてあげながら、propsとしてデータを一緒に渡してあげる作業が必要でした。
最初はデータを配列の中にJSON形式で別ファイルで適当に日付や名前、重要度を設定して、それを5人分くらい用意していただけだったので、インポートして配列としてそのまま使ってあげるだけで大丈夫でした。
しかし実際の機能開発になって、ローカルストレージに保存したデータを配列に格納する処理が非常に難しかったです。これは空の配列を作って、持ってきたデータをmap関数で入れてあげることでどうにかなりましたが、その処理を調べて、開発できるまでにまるまる2日間かかりました。
自分は配列の処理が非常に苦手で、今までまともにforEachやmapを使ったことがなかったんです。だから、今回めちゃめちゃ苦労して使いこなせるようになったのは良かったです。
日付はうる覚えなので適当ですが、しっかりとリストになっています。
そうしてどうにかリストが完成したら、次に新しく記念日を追加する部分に突入しました。
newCard.jsというファイルを作って、そこで新しく記念日を追加登録できるページを実装します。
まず、react-native-elementsやビルトインのコンポーネントを使って、表面を作っていきます。
ただ、日付を設定するdate-pickerだけはreact-native-datepickerというライブラリを新しく使いましたが、react-native-elementsとreact-native-swipeoutでライブラリの使い方は理解できていたので、date-pickerはスムーズに導入することができました。
そうしてUIデザインは割とすぐに出来ていたので、あとはコンポーネントやライブラリを組み合わせるだけで表面を作ることができました。
ここまで順調でしたが、ある壁に直面します。
・記念日の種類や重要度は別ページで行うこと
・データの保存にローカルストレージを使うこと
の2つです。
前者はreact native navigationというページ遷移用のライブラリ。後者はsqliteというローカルデータベースのライブラリを使う必要がありました。
これらを使わないといけないのは想定していましたが、navigationはapp.jsというルートで管理し、かつその他のライブラリよりも圧倒的に使い方が特殊なライブラリでした。sqliteについても、SQLを書いたことはなかったので、データベース初挑戦だったのです。
こうして初挑戦が一気に2つもきたので、1つずつ片付けていくことにします。
まずはreact native navigation。これはページごとにクラスを作って、app.jsでそれをimportして、ページ群を組み立てる、という使い方のイメージです。それだけならいいのですが、どうやったらページ遷移する時に、そのデータを一緒に渡せるかが問題でした。実際には、ページ遷移の関数を呼び出す時に、同時に第二引数に渡したいpropsを設定するのが正解なのですが、これに非常に苦労しました。さらにpropsを渡すだけではなくて、渡した後のページで何か変更をした場合に、渡した前のページで関数を呼び出してそちらで変更するという方法をとる必要があり、理解した今ならスムーズにできますが、これにも理解に2日ほどかかってしまいました。
例えば、重要度は5段階で設定しているわけですが、それを変更するのには重要度変更ページにいきます。これは、追加画面で設定してある重要度を、重要度変更ページに移った際に反映しなければならないということです。追加画面で3なのに、変更ページに行ったら常に4から変更になってしまったら意味がありません。なので、3というデータ変更ページに渡してあげて、そちらで反映し、それを変更したら、追加画面の関数を呼び出してそちらで変更を反映してあげるという流れが必要になります。しかも、ただタップして変更したら反映されるのではなく、キャンセルやOKといった変更確認も重要となります。
このように、システムに漏れがないように設計するのが非常に大変でした。1つ綻びが見つかったなと思っても、芋づる式にここも変えて、あそこも変えてとなります。必然的に。
どうにかナビゲーションを導入したら、次に待ち受けているのはローカルデータベースです。sqliteやAsync StorageなどいくつかのローカルデータベースライブラリがReact Nativeでは使えるようですが、自分は最初sqliteを選びました。
正直、ローカルを使うのにもAsync Storageを使えば良かったと後悔しています。sqliteは、本当にデータベース的になっていて、テーブルなどの概念があって追加や削除なども、SQL（的なもの）を書く必要があります。しかし、Async Storageならgetやsetのように、JavaScriptベースでデータベースに追加や削除ができるので、とっつきやすさは正直Async Storageの方があると思います。なので、Async Storageを全力でオススメします。
どちらにせよ、最初はsqliteを使ったので、その学習をまずしなければなりませんでした。ただ、簡単な追加はできてもなぜか複数の変数を追加しようとすると一向にできなくて、その原因調査に何十時間もかかりました。本当にしょうもないです。
結局、原因はわからないままUdemyで講師が使っていたコードをほぼ丸パクリして内容を変えたらできたので良かったです。なにがいけなかったのかは未だにわかりません(汗)
それに比べてAsync Storageを後で導入した時は一瞬で使いこなせたので、もう浮気はしないと誓いました。笑
そうして、どうにか追加画面で設定した記念日の詳細データをローカルストレージに保存することまではできるようになりました。
これでやっと動きました・・・
そして、次の壁はその保存したデータをホーム画面にリストとして反映させることです。
ただデータベースから引っ張ってきただけでは、配列になっていないので、配列変換処理をする必要があります。配列にしないとFlatListには反映されないからです。
なので、どうにか配列にするために試行錯誤します。console.logを駆使しながら、データベースからとってきたデータを配列に格納しようとするのですがなかなかできません。そこで、やはりgoogleで似たようなFlatListとsqliteを同時に使っているようなサンプルを探して、それをベースに応用してどうにか作り上げることができました。
これにも2日ほどかかっています。ほとんどが、あーしたらこーしたらの繰り返しだったんですね。
こんなにも時間が毎回デバッグにかかってしまうのは、ひとえに開発経験がないからどの辺りで問題が起こっていそうなのかわかっていなかったり、そもそもコンポーネントの使い方やpropsとして渡すには配列変換処理をしないといけないなどの、型の知識がなかったりするのが原因です。最初にコピペできるようなサンプルを探すのではなくて、自分で原因を考えて、その原因を解決できる方法を探すというのが正しいアプローチだと思います。
自分がsqliteの時にやってしまったように、結局原因がわからなかったけど動いたからいいや、というのは本当に最終手段で、後から痛い目に合う確率が高いと思います。なので、ライブラリを使うならその知識をしっかりと学んだり、どのデータがどういう処理をされるべきなのかというのを常に把握するのが大事です。
ホーム画面がどうにかして完成したら、次は追加画面のUIをベースに、ホーム画面で記念日をスワイプした時に現れる編集ボタンを使って移動できる記念日編集ページへのnavigationとpropsの引き渡し、そしてデータベースのアップデートや削除機能の実装です。
スワイプ時に出てくる編集ボタン
これについては、navigationもデータベースもすでに使い方が分かっているので、うまくデータの受け渡しさえできれば簡単に実装ができました。
ただ引っかかったのは、
・データを変更した時に、キャンセルを押したらしっかりと変更前に戻らないといけない
・上を踏まえて、変更や削除があればホーム画面に戻った時にそれが反映されないといけない
という2点です。
前者は当たり前ですが、変更をキャンセルしたなら前の状態に戻るように、それを保存しておいてOKが押された時だけ変更するように開発する必要があります。自分はそこを気にせずに開発してしまっていたので、途中で気づいて修正しました。
大きく引っかかったのは後者です。Reactはstateに変更があった時だけ、その差分をアップデートするわけですが、編集画面で変更しても、それがホーム画面のstateを同時に変更しなければ、ホーム画面に戻った時にその変更が反映されていないことになります。もしも削除したはずの記念日がそのまま現れていたら使い物にならないですよね。
自分はそれに対して、ホーム画面でローカルストレージを読み込む関数をcomponentWillMount()関数の中に設定して、それをさらにpropsとして編集画面に渡し、さらにOKボタンが押されればホーム画面に戻る操作と同時にそのライフサイクルメソッドが発動することでページ読み込みを強制することで対応しました。もちろんstateを間接的に変更することもできますが、簡単なのは一度データベースを読み込み直す事だと思います。
しっかりデータの受け渡しができました。
これでやっと一通りのメイン機能と画面が実装できたので、あとは通知の実装が必要でした。
通知は幸いにもExpoにビルトインで機能があったので、それを読み込んで使うことにしました。
たまにExpoのビルトイン機能を使っていると、別でまたインストールしてくださいという指示が現れることがあるので、その時は素直にインストールすれば使えるようになります。
Expoが提供している通知の実装方法は2種類あって、
①ローカルプッシュ通知
②Firebaseと連携したオンラインプッシュ通知
の2つです。
自分はここで最大のミスを犯しました。
本当に叫びたいくらい、あの時は絶望しました。
最初はExpoのビルトインの関数を読み込んで、プッシュ通知をローカルでスケジュールして通知する実装をしました。remindaryは企画編で画像を掲載したように、重要度は5段階に分かれていて、上3つに設定されていると通知が決められた頻度で飛ぶ設計でした。
設計ではそうだったのですが、いざ実装をした後に調べてみると、iOSではローカルでの通知のスケジュールは最大で64個しかないということを知ったのです。
つまり、iOSでは最大で64個の最新の通知しか来ないことになります。
64個も記念日を登録する人は少ないかもしれませんが、65個以上になると自動的に通知スケジュールが消されてしまうんです。
ここでの問題は、
・記念日を少なくとも65個以上に設定できないこと
・記念日が64個以下の場合でも、重要度が5や4に設定されていれば、もう一度アプリを起動しない限り、1ヶ月前や1週間前の通知スケジュールが発動しないこと
でした。
そもそも、ローカルでは絶対に65個以上の通知を設定できないのと、アプリを頻繁に開かなければならないというのは、自分の求めるコンセプトやUXが達成されないのと同義でした。
ここで、自分は大きな決断を迫られます。
つまり、Firebaseを導入して頑張ってマスターして、ローカルストレージを使わずにオンラインデータベースに切り替えるということです。なぜ通知機能だけでなく、データベースもオンラインに切り替えないといけないのか。
それは、記念日の〜ヶ月前や〜日前といった頻度で自動的に通知するには、Firebaseのデータベースに記念日の情報がないといけないからです。それを参照して、〜日前だったら通知を送るという実装が必要だからです。
そしてさらに大変なのは、データベースだけでなく、不必要だと思っていたサインアップ、ログイン処理やそれに伴うユーザー情報の再設定やバリデーションです。
匿名の使い方もあるようですが、データを永久に保存して使っていきたいのに、携帯が壊れたり、なくしたり、アプリをアンインストールしたりなどの何かの表紙で、匿名ユーザーとしてのログイン情報が途絶えてしまえば、折角設定したデータに一生アクセスできないことになります。
だから、サインアップやログインの機能を作る必要性も出てきました。
ログアウト機能が必要になって、急遽作ったログアウトメニュー。
通知の実装も同様です。通知にはFirebaseのcloud functionという機能を使っていますが、それについても新しく覚える必要がありました。
そもそも、Firebase自体が自分は初めてなので学習コストが以上に高いように見えてしまったのです。何故なら、もはやバックエンドに手を出すのとあまり変わらないと感じたからです。
しかし、このミスは自分が要件定義をした後に、本当にこの機能は実装できるのかという確認を怠ったのが原因です。iOSのローカル通知数制限は、例え初心者だったとしてもローカル通知を使うと定義したのであれば調べることができたと思います。
なので皆さんは是非、機能を要件定義した後には本当にそれが実現できるのかを調査してみてください。それによって膨大な時間を節約することができます。しかし例え失敗したとしても、それは大きな学びにつながるのは間違いないです。もう二度と同じ失敗をしなければ、その失敗はきっと活かされたということです。
こうしてFirebaseを使うことに決めた自分は、夏をナメた結果食中毒になりながらも、泣きながら以下の手順でfirebaseを導入しました。
1. ログイン処理を実装して、userと記念日データを結びつけるデータベース設計を行う
2. sqliteのデータをfirestoreに保存するように置き換える
3. firestoreに保存したデータを読み込んでホーム画面で反映させる
4. 記念日の追加や変更とfirestoreを連動させる
5. cloud functionで通知を実装する
6. cloud functionでスヌーズ機能を実装する
7. ユーザーの削除やパスワード再設定機能の実装
まずログイン処理ですが、これについてはqiitaの記事がいくつかあり、さらにはfirebase自体の公式ドキュメントも日本語で書いてあるので、それなりに簡単です。
しかし自分が躓いた点として、
・ログイン機能単体でLogin.jsなどのファイルを作ってエクスポートしても、その関数でthis.props.navigation.navigateは使えない。
・firebaseのモジュール自体をなぜか毎回インポートしないといけない。
という点です。
Login.jsなどのログイン周りの機能専用のファイルを作って、機能をそれぞれエクスポートしてもそのファイルはreact native navigationのスタックに組み込まれていないので、ログイン処理をした後にそのメソッド内で違うページへの遷移を試みても、Login.js自体にthis.props.navigation.navigateのメソッドが含まれないから遷移できない。そのため、自分は仕方がなくログイン処理のUIと機能は同一のファイルで開発しました。
もしかしたら、遷移だけUI側で行えばよかったのかもしれません。たとえばボタンのonPressのpropsにログイン処理の後に遷移の処理を書くイメージです。
また、firebaseのモジュールは一回読み込んだファイルの機能を他で使う時は、もう一度読み込む必要がないと考えていました。
しかし、仕様上の問題かわかりませんが、データベースも含めて毎回読み込む必要があり、あまり綺麗なコードとは言えない状況になってしまっています。
今後改善していきたいですが、読者の方でアドバイスあれば教えてください。
ログイン処理を書いたら、個別のユーザーが存在することになるので、それは個別の識別子（user.uid）などが使えることを意味します。このuidもログイン確認のfirebaseメソッドを使えば一発で取ってくることができるので、それをデータに結びつけるだけです。
そのためデータベース設計は簡単だと思っていたのですが、なんだかんだで慣れるまでに相当な時間を要しました。まずcollectionとdocument、fieldというものの概念が新しすぎて理解が難しかったです。しかし、図を使ってイメージで解説してくれている記事を見つけたりして、どうにか腑に落ちました。
セキュリティ的な関係であまり詳しく言えませんが、めちゃめちゃ苦労しました。userと記念日のcollectionを結びつけて管理する方法が全く分からず、本当に四苦八苦してそれでもわからなくてやっぱり通知64個の制限は諦めようか悩んだ時もありました。
それでもなんとか運用できるデータベース設計を思いついて、それを実行したところ作ることができました。
やはり自分だけのアプリになると、必然的にデータベース設計もサンプルとしてネットには載っていないものが多くなってきます。そこから使えそうなポイントを抽出して応用する作業も必要です。
ここで重要だったのは、諦めない心とひたすらに実現したい機能と必要なメソッドについて深く理解し、一つ一つこれはこうすればできる。というのをしらみつぶしに問題解決していくことです。この時はデータベースとデータベースのメソッドについて理解することが重要でした。バグを直す時もそうですが、アテのない時はひたすら実験して、しらみつぶしにやってみる時もあると思います。
そうしてどうにかデータベース設計さえ終われば、あとはデータをあちこちで読み込んだり書き込んだりするだけです。sqliteにしていたとはいえ、使う変数自体は変わらないので、メソッドをデータベースに移し替えるだけですみました。
ただここでも問題が生じて、具体的には、firebaseのgetメソッドに関係するsnapshotを理解するのに時間がかかりました。
snapshot周りの実装は非常に厄介でした。
getメソッドでは色々なデータをsnapshotというのに格納して取ってこれるのですが、
・それのどこを参照して、どうすれば配列に格納できるのか。
・.thenで繋げて返ってきたsnapshotをいじってあげないと、Promise Objectを拾ってしまう。
という2点に非常に時間を取られました。
どちらもどうにか、エラーコードを読んだり、console.logでsnapshotの中身を読み込んだり、あとはVScodeを使っているので、snapshot.まで打つと使えるメソッドや変数の候補が出てくるので、それを参照しながら本当に実験の繰り返しでした。
最終的には、ネットに落ちていた記事を参考に実現することができました。
ここまでで、かなりfirebaseについて理解したつもりになっていましたが、cloud functionはさらに大きな壁でした。
ExpoはExpo Push Notificationというモジュールを使ってExpoサーバーにメッセージの内容や送信先のtokenを渡すと、あとは勝手にFirebaseのFCMと連携してユーザーのiOSやAndroid端末などに通知を送ってくれる優れものです。
このExpoの部分については、自分の関数内に本当にほとんどコピペでできます。
それよりも、メッセージを「誰に」「どのタイミングで」「どのような内容で」送るかが非常に重要です。
これらはremindaryの場合、全てfirestoreに保存してあるデータを参照して決めています。重要度が5以上の記念日を探してきたり、その中からさらに記念日がその日から何日前であるかを計算したりしています。そして取ってきたsnapshotの中から必要な名前やtokenなどをメッセージのボディに埋め込んでいく感じですね。
躓いたのはただ1点。
・adminを設定し忘れたことで、権限が付与されていなくてfunction失敗しまくったこと。
です。
この真ん中の1行を入れ忘れるだけで、何時間もネットをさまようことに。
これ以外についての実装は、それこそ3日ほどかかりましたが、それでもどうにか検索しまくって先人たちの知恵を解読することでどうにかしました。
問題は出来たと思っても何故か一向に読み込みができなかった原因が、権限の設定し忘れにあったことです。
Cloud funtionの関数外でadminとして権限を持たせるコードを書いておかないと、例え権限が全てreadもwriteもtrueになっていたとしても、読み込みも書き込みも出来ないことには驚かされました。というかたった数行のコードのために10時間とか費やしました。
なんで出来ないんだろう。頭を抱えながらあーだこーだ調べて、どうにかたどり着いたのですが、この時は本当に泣きそうになりました。全く原因がわからなかったので。
そうしてcloud functionを書き終わったら、あとはスケジューラーの設定です。普通のcloud functionだと、データベースに書き込みなどの変更があった際にトリガーされる設定しかできないのですが、自分が作るときにはスケジューラーの機能が組み込まれていました。GCPというGoogleのサービスと連携していて、これを使うことで毎日何時に、というのが実現可能になりました。
これもひたすら「firebase function schedule」みたいに調べまくって、英語の記事を読みまくった結果どうにか作ることができました。
こうして通知も完成すれば、同じようにスヌーズ処理も作るだけです。
スヌーズは、重要度2の記念日の日付を確認して、すでにその日付が過ぎていれば重要度を2から4に戻すような機能をcloud funtionで実現しています。
ここまでで、細かい機能以外のメイン機能は完成しました。
あとは、
・ユーザーの削除やパスワード再設定
・お問い合わせ機能
・よくある質問とプライバシーポリシー
・英語化
・スプラッシュスクリーン
・オンボーディング
・通知時間の個別設定
・UIの調整（iPhone X以降や小さい幅の画面に対応）
などの細々とした実装を行なってやっと、ほぼ完成させることができました。
【まとめ】
開発もひと段落して、今日からiOSのapp storeでDLできるようになりました！審査に一度落ちはしましたが、再提出した後に無事合格することができました。(androidはまだリリース準備中）
自然任せでもダウンロードがあるかもしれませんが、こういう頑張った経緯に需要があるかもと思って、これを読んでくれた人がダウンロードしてくれる、、、正直そんな下心ありきで書きました。笑
しかし、まだブログなども書いた経験がなく、メールやLINEすら苦手なほど文才のない自分の、拙い文章を読んでくださってありがとうございました。
改めてですが、この記事では、たった1つのシンプルなアプリを作るまでの道のりを描きました。
自分がいかに中途半端で、何も出来ない人間だけど、どうにかそれを乗り越えて1つでも世に自力でアウトプットできるまで成長した。それを半年前と少し前の卒業を控えて将来に怯える自分に伝えたいという気持ちで、全力で書きました。
結果的に全体で約60,000字の記事になってしまいましたが、「経緯」「企画」「デザイン」「開発」とそれぞれ章立てしたことで、少しでも読みやすいようになっていれば幸いです。
そして特に、学生の皆さんにとってチーム/セルフマネジメントはこれから経験していかなければならないことですが、自分の失敗から少しでも何か気づきを得て成功に繋げてくださればと思います。
大学に頑張って入ったのに、しかも親御さんもお金を払っているのに、就職もせずにやりたいことをやるんだ。まずは一回企業に入って社会を学ぶべきだろう。
そう言って心配をしてくださる方もたくさんいます。ごもっともです。
何も反論はできませんが、一つ言えるとすれば、
20代のうちに目標にチャレンジして、何回失敗を経験したかで、
「好きなことを仕事にして、好きな人たちと幸せにいきていく」
ことができるかどうかを左右するのではないでしょうか。
だから、自分は何回でも失敗して、そこから学びを得て、昨日の自分よりも少しでも成長する毎日を重ねていきます。
【さいごに】
いくつかの話はあえて超具体的な解決策などを書かずにいますが（ただでさえ長文なので）、開発編で最後お話できていない実装や審査をどう乗り越えたのか、なども含めてもし企画編やデザイン編、開発編それぞれ需要がありそうなら続きを書こうと思います。
なので、僕のTwitterアカウント（@RyoheiHasegawa）のフォロワーが100人を達成すれば、上記の続編を書いてみたいと思います。その時もし要望があれば、DMやリプで書いてくだされば、それを参考にさせていただきます！
本当にここまで読んで頂きありがとうございました。
もう、どんな記念日も忘れない。
remindary開発者 長谷川リョウヘイ
この記事が気に入ったらサポートをしてみませんか？