14
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

建築塗装業向け見積書作成ツールを開発するにあたって苦労した話

Last updated at Posted at 2021-05-07

背景

私は2020年10月から6ヶ月間、エンジニア起業家養成スクール「ジーズアカデミー東京」のLABコースを受講し、起業目的の同期(発案者)とチームを組んで、建築塗装業向け見積書作成ツールを開発しました。
開発にあたって特に苦労した①サービス設計②データベース設計③開発体制構築の3点(コードを書く以前の話)について、個人的な振り返りとして、概要を整理します。

#作成したプロダクト
建築塗装業の零細企業向けに見積書作成ツールを開発しました。発案者は、塗装業界に16年間従事しており、その現場経験から着想を得たプロダクトです。また、発案者の人脈からテストユーザーが存在しており、テストユーザーへのヒアリングと改善を繰り返しながら開発しました。

###プロダクトの機能
建築塗装業では、現場調査(現場で塗装に必要な材料の確認)を行った後、事務所に戻って見積書を作成します。本プロダクトを使用すると、現場調査時にスマホで見積書を作成できるので、大幅な時間短縮となります。

※プロダクトサムネイル
白色バージョン-small-15666.png

①サービス設計について

###設計開始時の課題

  1. 発案者は、これまでの経験から建築塗装業界に対して、多くの課題感を持っていたが、どの課題から解決していくべきなのか、整理できていない状態だった。
  2. 私が建築塗装業についてあまり知らなかった(合板関連の案件に携わったことがあったので、建築現場の雰囲気は知っていましたが、、)

###設計方法
下記の手順で整理を行い、また自分自身の業界理解を深めました。

  1. 発案者の最終ゴール設定
    発案者のゴールを言語化するために、ディスカッションを繰り返し、「建築業界の下請けを強くする」を最終ゴールと設定。

  2. 建築業界のビジネスフロー/プレイヤー等を整理し図式化
    建築業界にはどんなプレイヤーが存在するのか?
    案件の起点は誰か? 
    建築物はどの様に作られるのか? 
    お金は誰から誰に支払われるのか?
    ...などなど湧いて出る疑問を、発案者やテストユーザーへのヒアリングを行い整理。複雑な多重下請け構造に驚愕しました、、、

  3. プレイヤー毎の課題の洗い出し
    洗い出した各プレイヤーが抱える課題を発案者の経験や推測で洗い出しました。ここでは、塗装業において未使用在庫のロスが多いなど、様々な課題が浮き彫りになりました。
    ※建設業許可区分の整理
    スクリーンショット 2021-04-28 14.06.18.png
    ※ビジネスフローとプレイヤー整理の一例
    スクリーンショット 2021-04-28 14.07.20.png

###サービス内容の決定
最終ゴール「建築業界の下請けを強くする」への第一歩として適正であること(=サービスの拡張性が高い)、またチームメンバーのスキルで実装可能であること、から見積書作成に焦点を当て、開発を行いました。

#②データベース設計について

見積書の出力に必要なデータの整理と正規化を行い、ER図やテーブル定義書を作成しました。

###データの整理
見積書作成の疑似体験やヒアリングを行いデータを約900通りに整理。ある項目が決まれば何が決まるのか?を一つ一つ紐解いて行きました(ここが一番大変だった、、)。

※データの一例
スクリーンショット 2021-04-28 14.31.38.png

###データの正規化
整理したデータを基に第1正規化〜第3正規化を行い、データの重複を排除したテーブルを設計。

  1. 第1正規化
    非正規形から繰り返し項目を削除する。

  2. 第2正規化
    部分関数従属を別テーブルに外だしする。部分関数従属とは、主キーを構成する一部のカラムによって決定するもの。

  3. 第3正規化
    推移的関数従属を別テーブルに外だしする。推移的関数従属とは、主キー以外のカラムによって決定するもの。

#③開発体制
開発期間が2ヶ月と短いこと、テストユーザーの意見を柔軟に取り入れる必要があることから、アジャイル開発のスクラムのような方式で開発を進めました。具体的には、タスクを洗い出すことで、プロジェクトを小分けに区切り、タスクごとの担当とスケジュールを設定し、タスクの進捗管理を実施しました(Notionを利用)。
また、チーム間でのコミニケーションを重視する為に、slackにチームの日報チャンネルを作成し、日次のtodoと進捗を共有することで、チーム内でのコミュニケーションを活発化させ、問題の即時共有等を行いました。

※タスクの洗い出し
スクリーンショット 2021-04-27 18.38.46.png
※タスク毎のスケジュール設定
スクリーンショット 2021-04-27 18.40.22.png
※タスクの進捗管理
スクリーンショット 2021-04-27 18.37.52.png

振り返り

今回、起業目的のプロダクト開発に携わり、複雑な業界/データ構造の整理など苦労は多々ありましたが、その分、たくさんの学びがありました。特に、テストユーザーへヒアリングできる環境はありがたく、ユーザーが求めていることは何か?という目線を常に意識する大切さが身にしみて分かりました。今後の開発においても、ユーザー目線の重要性を忘れず、またユーザー目線を持てるように業界理解や情報inputを怠らないようにしたいと思います。また、今回は、手探りの状態でデータベース設計や開発体制を構築したので、さらに経験を積んで、拡張性のあるデータベース設計方法や体系だった開発手法を学んでいきたいと思います。

14
9
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?