入札資格管理サービス新規立ち上げ及び運用

入札資格を管理するサービスを新規で立ち上げを実施。 インフラ構築からバックエンド、フロントエンド側の開発を一貫して担当。 ■機能 ・新規ユーザー登録 ・アンケート ・アンケート回答チェック ・ダッシュボード ・資格検索 ・資格の後で登録 ・資格登録/編集 ・資格の統合、分割、廃合に対応する機能 ・ユーザー招待/管理 ・企業管理 ・資格マスタ管理 ・資格検品機能 ・フェーズログ ・E2Eテスト ・endpointテスト ■インフラ AWSのAmplify/App Runnerを軸に構築。 導入ハードルが低く、小規模サービスには向いていると感じたが、以下調整及び懸念があった。 ・Amplifyは内部でCloud Frontが動いているが、それに対してWAFを当てられないため、Cloudf Front2台構成になってしまう。 ・App Runnerをパブリックネットワーク構成にした場合、DBとの接続がオープンになってしまうためプライベートネットワーク構成にしたが、外部へのリクエストをVPC Endpointを返す必要があり、料金が高くなってしまう。 ・App Runnerのauto scalingはCPUやメモリのトリガーではなく、同時実行数をトリガーにスケールするため、アプリケーション側の実装をより気をつけなければいけなかった。 ■提案 ・Qiita Teamの導入 ドキュメント管理が全てスプレッドシートで管理されており、ナレッジの共有や将来の検索性において懸念を感じ、Qiita Teamの導入を提案し採用された。 Jira Confluenceが望ましかったが、既に他部署で採用されており採用ハードルが低かったためQiita Teamを選択した。 ・PRD（Product Requirements Document） 仕様に関して、会議での議事録やslack、スプレッドシートなどで分散してしまっており、言った言ってないが発生している状況だったため、PRDや詳細設計などをQiita Teamにテンプレート化し、機能開発時にステークホルダーとこの資料を見て認識合わせする様提案した。 ・API仕様書をPostmanで表現 API仕様書をスプレッドシートやswaggerで管理していたが、メンテナンスされておらず正確な情報として誰も信用していない状況になってしまっていたため、必ず動作確認で利用するPostmanでAPIドキュメントを表現するよう提案し採用された。 Postmanで進んでいるが、最近はApidogが良さそうで利用を考えている。 ・sourcetree等でGitのコミットグラフを見る文化の普及 チームにてgit管理はコマンドで行なっていたが、コミットグラフを見る文化がなく、rebaseやcherry pickなど便利な機能を使いこなせていなかったり、破壊的な操作をしてしまうことがあったため、グラフを見る文化及び先述した機能の使い方を普及した。これにより無駄なコミットが入らず、レビュアーの負担が減ったりなどチーム開発がより円滑に進む様になった。 ■コメント ・別企業が実装途中だったアプリケーションを引き継ぐ形で実装 ・チームリーダーとして進捗管理や設計を行い、全てスケジュール通りにリリースした ・リリース後も大きな不具合なし ・リリーススケジュールの合間の時間を使い、2週間という短い間でデフォルトのexpressアプリケーションからオニオンアーキテクチャ&Typescriptへリプレイスすることができた ・使用する言語は全て新しいものだったが、素早くキャッチアップし開発することができた