約3ヶ月で新規サービスをリリースした当時を振り返ってみる

以前、とある仕事で開発着手から3ヶ月であるサービスの Beta 版をリリースしました。
今回はそこに至るまでの技術選定や、実際に使ってみてどうだったかという点について当時を思い出しながら書いてみます。

これは2022年前半ごろの話で、このプロジェクトが動き始めた段階でメンバーは代表と私の2人でした。

リリースまでにやったこと

チーム体制の構築（1週間程度）
デザイン調整・要件整理（2週間程度）
タスク管理ツールの決定（数日程度）
開発（2ヶ月程度）
リリース最終調整～リリース（1週間程度）

チーム体制の構築

まず、とにかく早くリリースしてユーザの反応を見たいという要件があったため、最低限の機能でリリースするべくやることを整理しました。
ただ、私自身他のクライアントでの稼働もあるため、1人でやりきるのは時間的に厳しい状況でした。
そこで、過去に別件で一緒に仕事してきたメンバー（フロントエンド1名・バックエンド1名）を誘ってプロジェクトにジョインしてもらい、スピーディーかつ最小限のコミュニケーションコストで開発を進められる体制をつくりました。

タスク管理ツールの決定

GitHub Projects (Beta) （以降 Beta）を利用しました。
Issue を表形式で閲覧でき、グルーピング/フィルタ/ソートもできる ~~とてつもなく Excel っぽい~~ 優れモノでした。
当時元々あった GitHub Projects ではカンバン形式で管理出来たものの、マイルストーンやスコープ単位で表示できないという問題がありました。
他のタスク管理ツールも検討したものの、ミニマムに対応するという点や開発にはどのみち GitHub を使うという点から Beta を使ってみようと思いました。

使ってみた感想

今回のチームではフロントエンド・バックエンドで担当者を分けていたこともあり、それぞれのチケットを一覧表示できる Beta とは相性が良かったです。

一方で、新規機能開発のように大きなタスクだと複数の Issue に分けることが多いので、（Beta というか GitHub の問題でもありますが）Issue の親子関係をうまく管理できる方法があると良いのになと思いました。
また、Issue 起票時には自動で Beta へアサインしてほしいのですが、GitHub の設定だとそれが出来なさそうでした。
こちらについては GitHub Apps を作成の上、GitHub Actions にワークフロー追加することで自動化しています。
現在はもう少しスマートに書けそうですね。

name: Add issue to Project

on:
  issues:
    types: [opened]

jobs:
  track_issue:
    runs-on: ubuntu-latest
    steps:
      - name: Generate github token
        id: generate_token
        uses: tibdex/github-app-token@v1
        with:
          app_id: ${{ secrets.APP_ID }}
          private_key: ${{ secrets.PRIVATE_KEY }}
      - name: Get project data
        env:
          GITHUB_TOKEN: ${{ steps.generate_token.outputs.token }}
          ORGANIZATION: xxx
          PROJECT_NUMBER: 1
        run: |
          gh api graphql -f query='
            query($org: String!, $number: Int!) {
              organization(login: $org){
                projectNext(number: $number) {
                  id
                  fields(first:20) {
                    nodes {
                      id
                      name
                      settings
                    }
                  }
                }
              }
            }' -f org=$ORGANIZATION -F number=$PROJECT_NUMBER > project_data.json
          echo 'PROJECT_ID='$(jq '.data.organization.projectNext.id' project_data.json) >> $GITHUB_ENV
      - name: Add issue to project
        env:
          GITHUB_TOKEN: ${{ steps.generate_token.outputs.token }}
          ISSUE_ID: ${{ github.event.issue.node_id }}
        run: |
          gh api graphql -f query='
            mutation($project:ID!, $issue:ID!) {
              addProjectNextItem(input: {projectId: $project, contentId: $issue}) {
                projectNextItem {
                  id
                }
              }
            }' -f project=$PROJECT_ID -f issue=$ISSUE_ID --jq '.data.addProjectNextItem.projectNextItem.id'

利用アーキテクチャ・ツールの決定

開発時に利用したアーキテクチャやツールは以下のとおりです。

ワイヤーフレーム: Figma ※前述のとおりです
アプリケーション
- 開発環境: Docker
- フロントエンド: Next.js (React)
- バックエンド: Gin (Golang)
インフラ
- IaC: Terraform
- デプロイツール: ecspresso -> 途中からスケジュールタスクも出てきたので ecschedule も使っていました
CI
- GitHub Actions
ドキュメント
- 構成図: Diagrams
- ER図: PlantUML -> 途中からは tbls を使うようにしました

かいつまんで選定の理由を書きます。

Figma

ワイヤーフレームについては代表に対応いただいたのですが、その際に「どんなツールを使えばエンジニアと連携しやすいですか」という質問がありました。
Adobe XD や Photoshop などいくつか選択肢はあったのですが、

最低限の機能が無料で利用できる点
リモートワークが前提になるためオンラインで完結する点
複数人で同時編集ができる点

などから、Figma をおすすめしました。

使ってみた感想

とにかくコミュニケーションやフィードバックがしやすかったです。

コメント機能を使って問題箇所にフォーカスしたやりとりができる
スタイル情報がコピーできる
任意の形式で画像をエクスポートできる

など便利な機能が多く、スピーディーにコーディングを進めることが出来ました。

フロントエンド・バックエンド

新規構築するなら、エンジニアに興味を持ってもらえるようなモダンなアーキテクチャが良いよねという話が出ました。
上記を踏まえて、バックエンドについては Go を選択しました。
主な理由は以下3点です。

ビルド生成物が単一バイナリになるためコンテナと相性が良い
誰が書いても同じコードになりやすいシンプルさから未経験のエンジニアでも慣れやすい
私自身長く使ってきた経験があり、メンバーにレクチャーできる

フロントエンドについては、周辺ライブラリの多さやエンジニアの集めやすさという観点から Vue/React のいずれかを選択したいと考えていました。
最終的には参画してくれたフロントエンドエンジニアに比較・検討・提案してもらい、React(Next.js) を利用することになりました。
一緒にやっていた別件が Vue2 を使っており、ここで色々辛い思いをしたという背景も大きかったです。

使ってみた感想

ぱっと思いつくところだと以下3点でした。

React/Go ともにドキュメントが多くあったので、詰まることが少なかった
基本的にテストコードは常に書くようにしており、検証環境もあったため大きな手戻りが無かった
ライブラリも豊富にあり、その気になれば自前でも実装しやすかった

3ヶ月でリリースできたというスピード感を踏まえると、まあまあ良い選択だったのかなと思います。

インフラ

作業するのはほとんど私になることもあり、各種ツールについては私が使いやすいものを選択しました。
安価なレンタルサーバーや VPS といった選択肢も考えたものの、今後スケールすることを考えて AWS およびコンテナ技術を利用することにしました。

使ってみた感想

ecspresso や ecschedule は Terraform のリソースを参照できるので、これらのツールを採用したのは良かった点かなと思っています。
ちなみに、ecschedule と Terraform の連携は過去私が実装しました（詳しくはこちらをご覧ください）。
これらのツールは今後も使っていきたいと思っています。

ただ、terraform plan を GitHub Actions でテストする場合、実行する IAM Role の権限が足りずエラーになる→権限を足して再実行みたいなケースが多くありました。
強い権限を与える以外で良い解決方法があると良いんですが、ここら辺は要調査ですね。

まとめ

駆け足にはなりますが、リリースするまでのあれこれをまとめました。
このサービスは紆余曲折あって終了してしまったものの、リリース後の開発でも苦労した点・面白かった点がたくさんありました。
今後も書ける範囲で振り返っていきたいと思います。