この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
プロジェクトの具体的な内容や実装例はこの記事には含まれません。
このコロナ禍においてフルリモート環境で私たちが実際にどのようなツールを使ってどんな流れで開発をしているかを WEB アプリ開発に使っている技術も含めざっくりとご紹介してみたいと思います。
私はフロントエンドエンジニアとして案件に参加しているので、コードレビューの流れなどはフロントエンドチームのものをご紹介しています。採用しているツールや進め方はプロジェクトによって違うので弊社内に多数ある案件の中の一例として読んでほしいです。
クラスメソッドの現場の雰囲気が少しでも伝われば良いなと思っています。
超ざっくりした案件概要
- データテーブル、グラフ、検索機能が満載の管理画面の開発
お客様から提供される大量データを可視化するダッシュボードを構築しています。インフラの構築から API 開発、フロントエンド開発、セキュリティ対策、等を開発チームで担っています。
メンバー構成
- フロントエンド 4 名
- サーバーサイド 3 名
- デザイナー 1 名
- PO チーム 3 名
これだけの情報で案件の規模感を説明することは難しいですが、社内でも比較的大きな案件になります。
プロジェクト管理
- Github Issue
- Github Project
タスクの管理は Github Project で行っています。新規機能やバグなどは全て Issue に起票され、仕様やタスクの詳細などは Issue に記載されます。Issue はラベルで管理されており、どの分野のタスクなのか、どのスプリントのタスクなのかが一眼でわかるようになっています。
お客様にも不具合や要望の Issue を作成していただいたり、Issue に直接コメントいただけるため、タスクに関する情報はここに集約されます。
デザインツール
デザイナーさんが書き起こしてくれた Figma の仕様に沿って実装を進めます。「選択リストのデータにはどんなものが入るのか」、「ここのグラフに指定できる値はどんなものか」等のサンプルデータがあらかじめ反映されたデザインは詳細な仕様の理解に欠かせない存在です。
機能実装の際に作成される Issue にも Figma のスクリーンショットが貼られることで全員が機能の詳細な仕様を理解することが容易になり、”どう実装するか？”の部分に集中することができます。
ソースコード管理
コードレビューは必須でフロントエンド、バックエンドチームに別れてそれぞれ基本的には全員がレビューを行います。
フロントエンドのコードは１つのプルリクエストが大きくなってしまいがちなのですが、新機能の雛形作成やリファクタリングをした場合などのどうしても仕方がない場合をのぞいてはコンポーネント、Redux、Sagas などのまとまった単位に切るなどしてなるべく小さいものになるようにしていました。
大きなプルリクエストは AWS Amplify Console のプレビュー機能を利用して実際に動くかどうかを先に確認し、不具合がありそうな箇所をコードを読む前に確認したりしていました。
プロジェクト進行方法
スクラムについての詳細な説明はここでは割愛します。
毎朝お客様を含むプロジェクトのメンバー全員が参加する朝会があり、タスクの進捗状況や仕様の確認などを行います。実装が完了したものからステージング環境に反映されるので、それをお客様にも実際にさわっていただき、朝会の場でフィードバックをもらって Issue に起こすことでより詳細な要望を素早く汲み取り、反映します。
スプリントの最終日には振り返りを行い、よかった点やもっと良くできた点を共有して次のスプリントに活かします。
コミュニケーションツール
お客様にもチャンネルに入っていただき、朝会で共有できなかった事項や質問などの細かいやりとりを Slack で行っています。
コミュニケーションツール(社内のみ)
上記の２つに加えバックエンドとフロントエンドの進捗具合や仕様確認などのリアルタイムでの把握が Github Issue や Slack 等の文面コミュニケーションだけでは不十分だったため、Gather のバーチャルオフィスに常駐するようにしました。
Gather に行くと案件メンバーがいるので音声で雑に質問をしたり、画面共有機能を利用してそのままペアプロやタスクの確認をしたりととても便利です。
Gather については以下の記事に詳細に書かれているのでぜひ参考にしてみてください。
ここから先は開発に利用している技術スタックをそれぞれフロントエンド、サーバーサイド、インフラ、と順にご紹介します。
フロントエンド技術スタック
フロントエンド構築は React と TypeScript でコンポーネントフレームワークは Material UI を採用しています。状態管理に Redux と Redux Saga を利用しています。
テストツール
Jest での単体テストと StoryBook によるコンポーネントの動作確認を必要に応じて追加しています。
その他開発環境設定
チーム開発なので、共通の ESLint、Prettier のルールを設定して、個人の環境ごとの異なるルールが適応されてしまわないようにしています。
デプロイの際に AWS Amplify でも ESLint のチェックが走るので、ルールに沿っていないコードはマージされない仕組みになっています。
CI/CD
プルリクエストが main ブランチにマージされたタイミングでテストとデプロイの処理が AWS Amplify によって実行されます。その後に CloudFront の Invalidation が Github Actions によって実行され、最新のソースが CloudFront 経由で閲覧できるようになります。
サーバーサイド技術スタック
- Node.js + TypeScript
- WEB フレームワーク: Fastify
- ORM フレームワーク: TypeORM
- Swagger
-
CI/CD ツール: GitHub Actions
- テスト: Jest
- linter: ESLint
- formatter: Prettier
サーバーサイド API の実装には Node.js(TypeScript)を利用しています。API ドキュメントは Swagger で管理されており、仕様の確認や実装されているのかの有無を確認することができます。
テストツールと Linter はフロントエンドと同様 Jest、ESLint、Prettier を使っています。
インフラ技術スタック
- Node.js + TypeScript
- AWS CDK
インフラリソースの構築は AWS CDK と TypeScript で行っています。
インフラ構築、サーバーサイド、フロントエンドで利用する言語を全て Typesctipt で統一することで、エンジニア間でのソースコードの読み解きが異なる言語で記述されている時よりも容易になったといえます。
まとめ
１つの案件で使っているツールや技術をまるっと全部ご紹介してみました。案件やお客様の性質によってベストなツールやプロジェクトの進め方などは変わってくるかとは思いますが、１つの例として参考になれば幸いです。
最後に
クラスメソッドでは様々なポジションでエンジニアを募集しています。少しでも興味が湧いた方はぜひ一度弊社の採用サイトを覗いてみてください。よろしくお願いします。
5
