ゼロから行った新規開発を振り返ってみる
はじめに
こんにちは、としまつです。
ここ数ヶ月、会社にてゼロから新規開発を担当しており、日々タスクに追われていました。
その開発が7月末にて本番リリースを迎えたので、ひと区切りとして学びになったことや苦労したことなどを手短に書き記しておこうと思います。何か一つでも参考になりましたら幸いです。
＞ 簡単な自己紹介
昨年5月に新しくweb自社開発企業に転職し、日々精進中の経験4年程のエンジニアで、未経験転職組です。本業で全社横断的な開発を行いつつ、個人で開発業務や制作などをやっています。
プロジェクトの概要
今回行った開発は既存業務フローを新たにシステムに置き換えて、業務効率改善と情報の一元管理を実現させるためのプロジェクトです。
一般的な0→1開発である新規事業開発とは異なり（市場調査やPoCなどはない）、既存の業務フローを置き換えるプロジェクトであるため1→n開発のプロジェクトとなります。
関係者は以下の通り。
・社内の当業務担当部署
・社内経理部
・社内法務部
・クライアント
・案件実施者
開発体制はエンジニア2人。
基本的に仕様決めと実装は自分が担当し、仕様や実装の相談はCTOへ行うという流れで進めていきました。終盤の実装はCTOとフロントエンジニアの1人も実装に取り組んでいました。
使用技術は大きく以下の通り。
・フロント&バックエンド：Remixフレームワーク (React, TypeScript)
・ORM：Drizzle ORM
・インフラ：AWS (aws-cdk)
学びや気づき
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の開発力を伸ばしていきたいなと思っている所存です。
想定外の出来事3選
毎度打ち合わせの直前に動かなくなる開発環境
開発環境へのリリースができ、実際のシステムを操作いただきフィードバックをもらいたいという段階で打ち合わせを数回組んだのですが、毎度直前でサーバーがダウンしてました。
打ち合わせ直前まではピンピンしていたのに、時間になると絶命していました。悲しい。
この要因としては、打ち合わせ直前まで行なっていた修正をせっかくだからとリリースしたそのバージョンにてエラーが潜んでいたことでした。
打ち合わせ直前にリリースをすな！という教訓です。
利用規約とプライバシーポリシー制定には時間がかかる
今回新システムということで、利用規約とプライバシーポリシーを作成していただいたのですが、思ったより時間がかかることを知りました。
まず社内法務部に利用規約とプライバシポリシーの作成を依頼し、作成が完了するまで1週間ほど。そして今回、社内のプライバシーポリシー制定のフローを新たに設置する必要があり、その稟議フロー作成に3日ほど。その後、稟議書を回していく段階で修正が入りつつ1週間ほど。
合計2週間ほどかかりました。
個人開発であれば稟議のフローなどが必要ないですが、企業のシステムとして制定するには当然時間はかかるなという学びです。
ただ自分の見積もり自体は甘かったけど、法務担当者や総務担当者の仕事は早かったです。エンジニアの僕としては「お願いします！」くらいしか言っていないので、すごいもう出来上がっているというような所感でした。ありがたい。
想像以上にシステムが好評だったこと
ある程度開発が進み、動作を見れる段階になったときに利用部署の対象メンバー全員を集めて打ち合わせをした時がありました。そこで想像以上に良い反応をもらえたことが意外でした。
エンジニアとしては劇的に難しい開発をしているわけではなく、良くて「便利になっているようだけど使うの大変そうだなー」くらいで悪くて「ちょっと使うの抵抗あります」くらいの反応をもらうかなと思っていましたが、実際は"感動！"というようなレベルで響いていました笑
ちょっと鼻の下が伸びかけてオランウータンみたいな顔になりかけました。危ない危ない。
今回を通してエンジニアの仕事の素晴らしさをより知ることができました。誰かの仕事をより良くできるモノづくりの仕事は面白い。もっと成長していきたい。
さいごに
今回の新規開発を通して、業務システム開発の一連の流れを掴むことができ、多くの学びを得ることができました。
・関係者へのヒアリングを通した仕様決定のプロセス
・利用者の導線を網羅した仕様、設計への取り組み
・新技術に対しての最短キャッチアップの感覚
・システム運用までに必要なドキュメントの作成手順（ユーザーへのシステム説明資料、開発者向けの仕様書、DB設計書、テスト仕様書）
などなど。
ここ数ヶ月はずっと働き詰めで、もう無理だ！詰んだ！！と何回思ったことか。結果論ですが、やってみれば何とかなりますね。
今回のドキュメント作成やタスク管理方法については別のnoteで書いていきたいなと思っています。
というわけでここまで読んでいただきありがとうございました！
またお会いしましょう。それでは。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？