こんにちは！
入社1年目の加藤、南、深田、舟久保です。
前記事に続き、本記事でもハッカソン合宿にて制作したアプリについてご紹介いたします！
※ハッカソン合宿について詳しくはこちら！
本チームでは、レシピサイトから材料を一括で登録することができる買い物リストアプリを作りました。
メンバー紹介
加藤
フロントエンドを担当。
業務では社内インフラの運用などを担当。
南
フロントエンドを担当。
業務では光コラボサービス申込システムや社内ツールなどの開発/運用を担当。
深田
バックエンドを担当。
業務では@niftyメールの運用などを担当。
舟久保
バックエンドを担当。フロントもお手伝いしました。
業務では課金請求システムなどの開発/運用を担当。
プロダクトについて
皆さんは食材の買い出しに行く際に、買い物リストを作りますか？
おそらく、多くの方が買い物リストのメモを作成して管理していると思います。
では、買い物リストのメモを作成しているとき、こんなことを思ったことはありませんか？
- 参考にしたい料理のレシピが複数ある場合、書き出す材料が多くて大変
- メモだと何を買い物かごに入れたのかわからなくなる
これ以外にもさまざまな苦労や不便さを感じていると思います。
そこで、私達は「買い物リストに一括登録できれば便利なのでは？」という発想の元、「クックリスト」を開発いたしました。
使い方
アプリを起動すると、リストに登録しているものをリスト表示で見ることができます。
メインの機能ですが、レシピサイトから一括登録ができます。
右下の+ボタンをクリックし、レシピサイトのURLを入力すると、そのレシピの材料を一括で登録できます。
さらに、購入済みに対してチェックを付ける機能もあります。チェックをつけると自動的に1番下に移動します。
これで、買い物中でもどれを既に買ったのかが分かるようになっています。
その他には、手動で追加・編集・削除の一般的な機能についてもカバーしています。
手動で追加する場合は、右下の+ボタンをクリックし、材料名と数量を記入すれば追加できます。
編集・削除は、右側の編集ボタンからできます。
そして、このアプリはプログレッシブウェブアプリ（PWA）に対応させました！
なので、端末にインストールすることもできたり…
1度アクセスしてしまえばインポート機能以外はオフラインでも使ったりすることができます！
裏でCache Storageに静的コンテンツのキャッシュを、IndexedDBにリストの内容を保存しているので、インターネット接続がなくても使えるんですよ。
バックエンドの構成について
本チームでは、バックエンドにも力を入れました。
全体の構成図は以下の図のようになっています。
APIは合宿1日目で開発を終えることができましたので、将来的な運用も考え、デプロイ環境や監視フローなどの構築に注力しました。
その中でも、勉強も兼ねてAWS AmplifyやAWS Codeシリーズ、GitHubActionsの3つのサービスを用いてCI/CD環境を構築しました。
特にGitHubActionsでデプロイする時のAWS IAM認証周りは苦戦しました。
面倒くさいときはAdministrator権限を付与したくなりますが、適切なポリシー設定ができるようこれからも心掛けたいですね。
工夫したところ
チームの環境
チーム環境で工夫した点として、いつでもコミュニケーションが取れる環境を維持したことが挙げられます。
いつでもコミュニケーションが取れることで、技術面で不安要素がある人に対する不安の払拭や、こまめに進捗確認を行うことができ、結果としてスムーズに開発を進めることができました。
また、他の人がどんなことをしているのかが分かるため、自分の担当外の知識についても得ることができました。
フロントエンド
フロントエンドでは、使い方で書いたこと以外にも、デザイン面にも工夫をしました。
できるだけシンプルで、かつ直感的に使いやすいデザインを心がけることで、初めての方でも使いやすいアプリにすることができました。
デザインフレームワークにはMATERIAL-UIを用いました。これにより、開発がしやすく、かつシンプルで直感的な統一されたデザインに仕上げることができました。
バックエンド
前述したとおり、バックエンドのインフラ面にも力を入れました。
当初は、AWS EC2にデプロイしようと考えていましたが、AWS Lambda + API Gateway + S3のサーバーレスアーキテクチャを用いることで、費用面でも工数面でも無駄なくサービスをデプロイすることができました。
仕様書の準備
その他にも本チームでは、事前準備でテスト仕様書やAPI設計書を作成しました。
テスト仕様書を作成したことで、システムの完成だけでなく品質も意識して開発をすることができました。
API設計書を事前にチームのみんなで作成したことで、システムの全体像を共有することができ、フロントエンドとバックエンドで並行して作業することが容易になりました。
認識のずれがほとんどなくなったため、結合時に大きな問題も起こらずスムーズな開発ができたと思います。
ハッカソンを通じた学び
今回のハッカソンでは次のような学びがありました。
しっかりとした事前準備と役割分担の重要性
今回、本チームでは、事前にしっかりとした仕様検討と役割分担を行いました。そうすることで、フロントエンドとバックエンドそれぞれの開発に集中することができました。
また、フロントエンドではモジュールごとにファイルを分割し、どのモジュールを誰が開発するのか認識を合わせていたことで、Gitのコンフリクトに悩まされることが少なく、その分開発時間に当てることができました。
チームでの開発では、事前にしっかりと認識をあわせ、仕様を決めておくとかなりスムーズに開発ができると感じました。
コミュニケーションがいつでも取れる環境の大切さ
開発中は、チーム内でNeWorkを常に繋ぎ、いつでも会話ができる環境としました。
これにより、細かい進捗報告や質問、他の人がどのような開発をしているのかの把握を行うことができ、ミスや手戻りが少なくなったと感じます。
また、適度に雑談を挟みながら開発をしていたため、ストレスも少なく開発ができたと感じました。
終わりに
今回は例年とは異なるオンラインでのハッカソンとなりましたが、オンラインだからこそ、コミュニケーションの大切さを感じることができたと思います。
今回学んだ技術面やコミュニケーション面について、今後の業務にも生かしていきたいです。
