はじめに
こんにちは。株式会社トリドリでバックエンドエンジニアをしている松田です！
今年は会社にてゼロからのシステム開発を担当しており、その開発が7月末に本番リリースを迎えていました。現在はそのシステムの改修や運用保守を行っている段階になっています。
今回の記事ではひと区切りとして学びになったことや苦労したことなどを残しておこうと思います。何か一つでも参考になりましたら幸いです。
プロジェクトの概要
今回行った開発は既存業務フローを新たにシステムに置き換えて、業務効率改善と情報の一元管理を実現させるためのプロジェクトです。市場調査やPoCなどはない、既存の業務フローを置き換えるプロジェクトとなります。
関係者は以下の通りです。
- 社内の当業務担当部署
- 社内経理部
- 社内法務部
- クライアント
- ユーザー
開発体制について、基本的にメインの仕様決めと実装を自分が担当し、仕様や実装の相談、そして技術的に難しい実装はCTOが行うという流れで進めていきました。また、途中でフロントエンジニアの1人も実装に取り組んでいました。
（運用保守段階である現在は体制が変わり始めています）
使用技術は大きく以下の通りです。
- フロント&バックエンド：Remixフレームワーク (React, TypeScript)
- ORM：Drizzle ORM
- インフラ：AWS (aws-cdk)
補足
なぜNext.jsではなくRemixを採用したのかについて聞かれたことがあります。
Next.jsでは少し前にapp routerがリリースされており、以降のNext.jsの新規で立ち上げるプロジェクトでapp routerを使うのが推奨されている状況でした。ただapp routerについての知見はまだ溜まっておらずまだ経験が浅い自分が取り組むにはキャッチアップに時間がかかることが想定されたのが大きな理由です。その点Remixは社内に知見があるエンジニアがいたため一定の安心感がありました。
学びや気づき
1. 作業の置換ではなく、目的が達成されているかが重要
「それ何のために必要なんですか？」という言葉を今回のプロジェクトで1番聞いたかもしれません。仕様を考えてCTOへレビューをもらう際にこの質問をもらい仕様のブラッシュアップを繰り返していました。
純粋に作業をシステム化するだけなら業務効率は上がらず、そのまま作業がシステム上に移動するだけになります。開発コストや運用コストを考えると投資効果はマイナスになります。システム化によってこれまでの手間を大幅に改善し担当者の作業コストを下げ、売上を立てる業務に集中できるようにするのが業務改善システムの大きなゴールです。
今回の例では、これまでGoogle SheetsやGoogle Formを用いて顧客情報や業務情報を管理しており情報が分散しているような運用になっていました。これらの情報管理や業務運用が担当者の手腕で何とか成り立っている状態で、いつ作業量が氾濫するか分からない状態でした。
この業務をそのままシステムで操作できるようになったところで価値はないです。一連の業務に関わる登場人物（モノを含む）をマスタデータ管理するのは当然として、情報の一元管理、不要な業務フローの削除、細かな業務効率向上の仕様を積み重ねていくことで目的達成へ近づけていきました。
仕様を考える際に、その作業が本当に達成したいことは何なのかを深掘りして仕様に落とし込んでいく。深掘りするには想像ではなく、実作業者に念入りに意図を聞いていくことが大事だと痛感しました。
2. やるべきことが想定の数倍に膨れ上がる
こればかりは正直甘く見積もっていたなーという反省点です。
このプロジェクトは当初支払い情報をシステム管理することを第一目的として、その目的達成に合わせて業務の効率化をしていこうという温度感で始まりました。そのため2ヶ月ほどで終わらせよう！という目標値でスタートしていきました。
ただ、ヒアリングを重ねていくとどんどんやるべきことが増えていきます。支払い情報の一元管理という本来の目的が変わっているわけではないけれど、その目的を達成するためには細かな業務フロー改善にも目を向け仕様に落とし込む必要があるといった状態でした。
- 業務の中で発生しうる例外ケースをどこまで想定しカバーできているかを考えること
- 仕様を詰めるために業務担当者、経理部、法務部の作業フローを担当者レベルで理解する必要があること
- 使ったことがない新しい技術のキャッチアップをしつつ実装すること（正直これが1番重たかった）
他にも、利用者が分かりやすいようなドキュメントの整備、開発者向けのドキュメント<ER図、画面設計、仕様設計、テスト仕様書>の作成などもボリュームある作業でした
作業ボリュームの見積もり精度に関しては、経験がものを言う領域だなと体感しました。プロジェクト実施経験、扱う技術の習練度、新技術へのキャッチアップ速度など足りないところは多くありました。
また、今回大きな学びになったことは上記二つ目に書いた「担当者レベルで業務を理解すること」の大事さです。既存の業務を改善するためのシステム開発であるため、重要なのは現場の担当者の仕事をどうやって楽に（簡潔なフローに）するかが
経験を積んで強くなるしかねえ！といったところです。
3. 技術的な話、RemixとDrizzleORMの知見が増えた
今回初めて実装に取り組んだものにRemixとDrizzleORMがありました。
Remixはフルスタックのフレームワークであり、社内でも導入するのが初めての技術でした。DrizzleORMも同様です。Remixに関しては、知見があるエンジニアが1人いて教えを受けつつ実装を進めていけていました。ただDrizzleORMは誰も知見がなく、ドキュメントやGitHub Issueとにらめっこする日々でした。
軽量のORMなのでSQLがかければキャッチアップにはそう時間がかからないものなのですが、軽量が故に何でもあるわけではなく、seedの仕組みやマイグレーションを環境ごとに適切に動かすための仕組みがなく困りました。ですが、その課題に対する解も今回構築することができました。具体的には以下の記事を参考ください！
今回でRemixに興味を持ったので、今後Remixの開発力を伸ばしていきたいなと思っている所存です。
まとめ
今回の新規開発を通して、業務システム開発の一連の流れを掴むことができ、多くの学びを得ることができました。
・関係者へのヒアリングを通した仕様決定のプロセス
・利用者の導線を網羅した仕様、設計への取り組み
・新技術に対しての最短キャッチアップの感覚
・システム運用までに必要なドキュメントの作成手順（ユーザーへのシステム説明資料、開発者向けの仕様書、DB設計書、テスト仕様書）
などなど。
開発を進めていた数ヶ月はずっと働き詰めで、もう無理だ！詰んだ！！と何回も思っていましたが、CTOをはじめとして開発部のエンジニア、業務の関係者の方に助けられなんとか運用に乗るシステムを提供することができました。今後も新たに業務フローを回収して行ったり、改善が行いやすいプログラムにしていったりとやることはたくさんあります。引き続き学びをアウトプットできていければと思います。
ここまで読んでいただきありがとうございました！
それではまた。
Discussion