はじめに
ニフティでは新人エンジニアの研修の一環として「エンジニア定例」という勉強会を実施しています。
例年、開発合宿という形で学習の成果をアウトプットする機会があるのですが、今年度はコロナ禍ということもあり自宅から参加のリモート開発合宿という形で開催されました。
リモート開発合宿自体の概要に関してはこちらの記事をご覧ください。
毎週連続投稿されてきましたハッカソン合宿制作記、第4回の今回は私たちのチームで作成した「雑談ポータル」を紹介します。
メンバー紹介
- 清水
- 開発合宿 : バックエンド担当
- 普段業務 : セキュリティシステムの開発・運用
- 筑木
- 開発合宿 : フロントエンド担当
- 普段業務 : 社内システムの開発・運用
- 三井
- 開発合宿 : バックエンド担当
- 普段業務 : 課金請求系システム、資料発送系システムのバックエンドシステム開発・運用見習い
- 湊谷
- 開発合宿 : フロントエンド担当
- 普段業務 : 顧客管理システム、シングルサインオンシステム、ユーザーサインアップシステムなどの開発・運用
制作物紹介
コロナ禍でリモートワークが急速に取り入れられた昨今、皆さんは「雑談が少なくなった」と感じていませんか？
通勤時間がないことや休憩時間が有効活用できるなど、リモートワークにはコロナ禍であることを除いてもいろいろな利点がありますが、一方で物理的な接点がなくなったことで雑談を始める機会が減っているのではないでしょうか。
リモート環境でもSlackやGoogle Meetなど、さまざまなコミュニケーションツールで会話をすることはできます。しかし、いずれも参加者全員が予定を示し合わせて開始する必要があるため、すれ違いざまや席にふらっと立ち寄った時に始まる雑談とは少し異なる体験です。
このチームで作成したのは、雑談の入口となり、リモートワーク環境における「雑談の始めづらさ」を解消するためのアプリケーション「雑談ポータル」です。
雑談ポータルでできること
- コミュニケーションツールのURLを元にした雑談の作成、公開
- 雑談の一覧表示
- 雑談への参加
使い方
雑談を作る
タイトル、URL、有効時間を設定することで誰でも参加可能なオープンな雑談を作成することができます。
今回は、「開発の中で苦労したReactの学習をしてるけど、1人だと少し寂しい。誰かと話しながらやりたい。」という状況を想定して作ってみましょう。
- タイトル
- タイトルは自由に設定できますが、今やっていることや、雑談の立ち位置などを書いておくことを想定しています。
- 今回はReactの学習をしながら雑談したいので「React勉強中」というタイトルに設定してみます。
- URL
- URLには実際に通話をするコミュニケーションツールへの招待URLを設定します。
- Google MeetやZoomなど、URLでの招待できるツールであれば設定可能です。
- 有効時間
- 有効時間はあなたがいつまで雑談できるのかを設定します。
- 参加者に何時まで雑談ができるかを知らせるとともに、設定した時間を過ぎると一覧から削除されて新しく参加することができなくなります。
- 今回は1時間ほど勉強している予定なので60分を選択しておきます。
作成ボタンをクリックすれば部屋の作成は完了です。
どこかで招待URLを伝える必要はありません。勉強を進めながら誰かが立ち寄ってくれるのを待ちましょう。
雑談に参加する
作成された雑談は一覧に公開されていますので、このページを参照して気になる雑談を探しましょう。
雑談をクリックすることでアコーディオンメニューが展開し、いつまで雑談できるのかが表示されます。
自分の予定と合う雑談であれば、参加ボタンをクリックして会話に入ることができます。
プロダクトのこだわり
- 緑を基調とした目に優しい色合いや、優しい文言
- 誰かと予定を合わせる必要がなく、シームレスに雑談に入れる
- 時間を指定できることで、業務の合間でもメリハリをもって使える
システム構成
作成したアプリケーションは図のような環境で動作しています。
バックエンド側をFlask、フロントエンド側をReactを使って実装し、データベースとしてはAWSのDynamoDBを使用しています。
また、FlaskとReactの部分についてはDocker Composeでコンテナ化してEC2に搭載しています。
今回の開発は短期間であるとともに、不慣れな技術を扱う個所もあったため、アプリケーション自体の開発に時間を集中したい事情がありました。そのため、EC2上でコンテナをビルドすることで開発環境からほとんど手を加えることなく短時間でデプロイができる方法を採用しています。
開発上の工夫
今回は短い開発期間のハッカソンということで、アプリケーションの実装に時間を集中して使えるようにいくつかのツールを取り入れています。
API仕様定義とモックの活用
短い開発期間をできる限り実装にあてるため、今回はアプリの仕様から事前にバックエンド/フロントエンド間で使うAPIを設計して開発に臨んでいます。
標準仕様であるOASに基づいてAPIを定義したことで、
- VSCodeの拡張機能によってAPI仕様が読みやすい形ですぐに参照できた
- Prismというツールを使うことで開発初期からモックサーバーを用意できた
といった利点がありました。
API仕様が参照できたことで共通認識をもって実装を始めることができ、モックサーバーを提供することでAPIの開発完了を待たずにフロントエンドの開発を進行できた点は短期間での開発にとっても有効でした。
開発環境の共通化と構築の簡略化
環境構築の簡略化とメンバー間での環境の統一を目的にRemote-Containersによる環境構築を採用しました。
Remote-Containersは開発コンテナにリモートアクセスすることで、コンテナ内の環境で開発できるVSCodeの拡張機能です。
設定ファイルをもとにビルドすることで共通の開発環境を用意でき、使用したdocker-compose.ymlをデモの環境にも流用できるため、短期間での開発が求められるハッカソンで時間を有効に使えると判断しました。
実際の開発時にはDocker周りのトラブルシュート込みの1時間ほどで全員分の環境を整えることができ、各々のPCの差異に悩まされることが少ない点でスムーズな開発につながりました。
実際に構築した開発コンテナの構成は以下の図の通りです。
全体のコードは1つのリポジトリで管理し、それを元にフロントエンド用とバックエンド用の開発コンテナを立ち上げています。
また、DynamoDB localや前述のPrismをDocker Composeに組み込むことで、アプリケーション本体以外に必要な環境を一括で構築しました。
学び
チームの状況の把握と素早い判断の必要性
実は、今回のプロダクトの雑談を作成する画面や雑談詳細の表示はどちらもモーダルウィンドウで実装予定でした。
2日目の終盤までその実装を目指していたのですが、最終的に難しいという判断に至り代替手段に切り替えた経緯があります。
もっと早くに方針転換を検討できていれば、余裕を持った開発ができて追加機能の実装なども実施できていたかもしれないという反省もあります。
単に決めたことをこなすのではなく、メンバー同士が状況を客観視して状況を把握することが必要であったと感じました。
開発に必要な準備
工夫点としてAPI仕様を決めた点をあげましたが、それ以外の部分ではUIの設計がザックリとしていたり、DBのテーブル構造に不要なものがあったなど、あいまいな箇所を抱えていたために開発中に考えることが増えてしまいました。
また、事前に使うと決めていたMaterial-UIやFlaskの学習も不十分な箇所があり、躓きにつながった部分もありました。
日頃から技術や開発に触れてはいますが、改めて開発に必要な準備や要素を認識することができました。
ほかにも失敗したこと、学んだことはメンバー各位にあると思いますが、短期の開発であるからこそ日々の業務よりも顕著に影響を感じることができたのではと思います。
おわりに
毎日の終わりに実施したふりかえりではメンバー各位から前向きに意見発信し、学びを共有することができました。
反省点もありましたが、コミュニケーションを絶やさず、何より楽しんで開発に臨んだことで最終的にはプロダクトを形にすることができたと思います。
開発を通して得た学びや知識は今回限りのものではなく、今後の糧になる経験の一つです。業務や開発にも生かしつつ、さらなる学びにつなげていきたいと思います。
