背景
私は2020年10月から6ヶ月間、エンジニア起業家養成スクール「ジーズアカデミー東京」のLABコースを受講し、起業目的の同期（発案者）とチームを組んで、建築塗装業向け見積書作成ツールを開発しました。
開発にあたって特に苦労した①サービス設計②データベース設計③開発体制構築の3点(コードを書く以前の話)について、個人的な振り返りとして、概要を整理します。
作成したプロダクト
建築塗装業の零細企業向けに見積書作成ツールを開発しました。発案者は、塗装業界に16年間従事しており、その現場経験から着想を得たプロダクトです。また、発案者の人脈からテストユーザーが存在しており、テストユーザーへのヒアリングと改善を繰り返しながら開発しました。
プロダクトの機能
建築塗装業では、現場調査(現場で塗装に必要な材料の確認)を行った後、事務所に戻って見積書を作成します。本プロダクトを使用すると、現場調査時にスマホで見積書を作成できるので、大幅な時間短縮となります。
※プロダクトサムネイル
①サービス設計について
設計開始時の課題
- 発案者は、これまでの経験から建築塗装業界に対して、多くの課題感を持っていたが、どの課題から解決していくべきなのか、整理できていない状態だった。
- 私が建築塗装業についてあまり知らなかった(合板関連の案件に携わったことがあったので、建築現場の雰囲気は知っていましたが、、)
設計方法
下記の手順で整理を行い、また自分自身の業界理解を深めました。
発案者の最終ゴール設定
発案者のゴールを言語化するために、ディスカッションを繰り返し、「建築業界の下請けを強くする」を最終ゴールと設定。建築業界のビジネスフロー/プレイヤー等を整理し図式化
建築業界にはどんなプレイヤーが存在するのか？
案件の起点は誰か？
建築物はどの様に作られるのか？
お金は誰から誰に支払われるのか？
...などなど湧いて出る疑問を、発案者やテストユーザーへのヒアリングを行い整理。複雑な多重下請け構造に驚愕しました、、、プレイヤー毎の課題の洗い出し
洗い出した各プレイヤーが抱える課題を発案者の経験や推測で洗い出しました。ここでは、塗装業において未使用在庫のロスが多いなど、様々な課題が浮き彫りになりました。
※建設業許可区分の整理
※ビジネスフローとプレイヤー整理の一例
サービス内容の決定
最終ゴール「建築業界の下請けを強くする」への第一歩として適正であること(=サービスの拡張性が高い)、またチームメンバーのスキルで実装可能であること、から見積書作成に焦点を当て、開発を行いました。
②データベース設計について
見積書の出力に必要なデータの整理と正規化を行い、ER図やテーブル定義書を作成しました。
データの整理
見積書作成の疑似体験やヒアリングを行いデータを約900通りに整理。ある項目が決まれば何が決まるのか？を一つ一つ紐解いて行きました(ここが一番大変だった、、)。
※データの一例
データの正規化
整理したデータを基に第1正規化〜第3正規化を行い、データの重複を排除したテーブルを設計。
第1正規化
非正規形から繰り返し項目を削除する。第2正規化
部分関数従属を別テーブルに外だしする。部分関数従属とは、主キーを構成する一部のカラムによって決定するもの。第3正規化
推移的関数従属を別テーブルに外だしする。推移的関数従属とは、主キー以外のカラムによって決定するもの。
③開発体制
開発期間が2ヶ月と短いこと、テストユーザーの意見を柔軟に取り入れる必要があることから、アジャイル開発のスクラムのような方式で開発を進めました。具体的には、タスクを洗い出すことで、プロジェクトを小分けに区切り、タスクごとの担当とスケジュールを設定し、タスクの進捗管理を実施しました(Notionを利用)。
また、チーム間でのコミニケーションを重視する為に、slackにチームの日報チャンネルを作成し、日次のtodoと進捗を共有することで、チーム内でのコミュニケーションを活発化させ、問題の即時共有等を行いました。
※タスクの洗い出し
※タスク毎のスケジュール設定
※タスクの進捗管理
振り返り
今回、起業目的のプロダクト開発に携わり、複雑な業界/データ構造の整理など苦労は多々ありましたが、その分、たくさんの学びがありました。特に、テストユーザーへヒアリングできる環境はありがたく、ユーザーが求めていることは何か？という目線を常に意識する大切さが身にしみて分かりました。今後の開発においても、ユーザー目線の重要性を忘れず、またユーザー目線を持てるように業界理解や情報inputを怠らないようにしたいと思います。また、今回は、手探りの状態でデータベース設計や開発体制を構築したので、さらに経験を積んで、拡張性のあるデータベース設計方法や体系だった開発手法を学んでいきたいと思います。