GASで業務アプリ作成

Google Workspace

Google Apps Script(GAS)で「部品一括見積システム」を作ることになった経緯をまとめました。…

開発記録 vol.1

GASで「部品一括見積システム」を作ることになった経緯

Google Apps Script(GAS)で構築した「部品一括見積システム」の開発過程の記録です。完成した機能だけを書くのではなく、なぜこの仕組みを作ることになったのか、どのように業務フローを整理したのか、実装途中でどんな課題が出てきたのかも含めてまとめていく予定です。

きっかけは、部品見積業務の手間でした

部品の見積業務では、整備工場から部品の問い合わせを受け、複数のサプライヤーに在庫・価格・納期を確認し、その回答を整理して整備工場へ案内する必要があります。

一見すると単純なやり取りに見えますが、確認する情報は多岐にわたります。車台番号、型式指定番号、類別区分番号、エンジン型式、必要な部品名、希望する部品区分など。中古部品・リビルト部品・社外新品・純正新品など、部品の種類によって確認先や回答内容も変わります。

さらに、サプライヤーごとに回答のタイミングも違います。価格は出ているが納期が未回答、納期は早いが価格が高い、部品ごとに最適なサプライヤーが異なる——そういったケースも少なくありません。

これをメール・電話・FAX・Excelなどで管理していると、どうしても手間が増えます。

人が判断すべき部分と、自動化できる部分を分けたい

この業務で大切なのは、すべてを自動化することではありません。部品の適合確認や、どのサプライヤーの回答を採用するかは、最終的に人の判断が必要です。

一方で、案件IDの発行、フォルダ作成、見積依頼の配信、回答の回収、PDF作成、ログ記録といった作業はシステム化できる余地があります。そこで、まず考えたのが次の流れです。

  1. 1整備工場がWEBフォームから見積依頼を入力する
  2. 2入力された内容をもとに案件IDを自動発行する
  3. 3Google Drive上に案件ごとのフォルダを作成する
  4. 4サプライヤーへ見積依頼を一括で送信する
  5. 5サプライヤーは専用URLから価格や納期を回答する
  6. 6管理者は回答を比較し、採用する部品を選定する
  7. 7最終的に整備工場へ見積書を送付し、自社受注サイトから購入できるようにする

このように業務の流れを分解していくと、GASでかなりの部分を実現できそうだと感じました。

GASを選んだ理由

GASを選んだ理由は大きく2つです。

1つは、イニシャルコストがかからず、当面の運用コストも抑えられること。新しく専用サーバーを用意しなくても、Googleスプレッドシート・Google Drive・Gmailなど、既存のGoogle環境をそのまま活用できます。

もう1つは、別の業務でGASを使った開発経験があり、実現イメージを持ちやすかったことです。フォーム入力、データ記録、メール送信、PDF作成といった処理の感覚をあらかじめ持っていたことは、設計を進める上で大きな助けになりました。

最初は小さな構想でした

最初から現在のような形を想定していたわけではありません。当初は「整備工場からの見積依頼を受け付け、サプライヤーへ効率よく回せればよい」という程度の構想でした。

しかし考えていくうちに、必要な機能が少しずつ見えてきました。

  • 整備工場用の見積依頼画面
  • サプライヤー用の回答画面
  • 社内で回答を比較・選定する管理画面
  • 案件ごとのステータス管理
  • サプライヤーごとの回答状況
  • 部品ごとの採用判断
  • 見積書PDFの作成
  • 自社受注サイトの購入URLの反映
  • 安全な文書共有の仕組み

単なる入力フォームではなく、実際の業務フローに沿った「見積依頼管理アプリ」として設計する必要があると分かってきました。

3つの画面構成へ

開発を進める中で、画面は大きく3つに分けることにしました。

整備工場
見積依頼の入力画面。注文者情報・車両情報・部品情報・添付資料を入力。
サプライヤー
回答画面。車両・部品情報を確認し、仕入価格・納期・備考を入力。
事務局(社内)
管理画面。回答を比較・選定し、見積書を作成。

この3画面構成にしたことで、整備工場・サプライヤー・事務局それぞれの役割を明確に分けて考えられるようになりました。

苦労したのは「業務をそのままシステムにする」こと

開発で難しかったのは、コードを書くことだけではありません。むしろ大変だったのは、普段の業務をどう整理するかでした。

どの項目を必須入力にするのか。見積書はどのタイミングで作成するのか。決済は自社の受注サイトを利用するのか。書類の授受はどの段階でどのように行うのか——こうした点を一つずつ整理しながら、実際の業務フローに合わせて少しずつ形にしていきました。

また、最初に考えた仕様がそのまま最後まで使えるとは限りません。PDF作成、画面表示、ステータス管理、回答データの持ち方などは、実装しながら何度も見直しました。

この連載で残していきたいこと

このブログでは、GASのコードの詳細を紹介するのではなく、業務アプリを作る過程を残していきます。なぜその機能が必要だったのか。なぜその画面構成にしたのか。どこで詰まったのか。どのように設計を変更したのか。

Excel・メール・FAX・紙の帳票で回している業務は、まだ多くの会社に残っています。そのすべてを一気に大きなシステムへ置き換えるのは難しいかもしれません。しかし、業務フローを整理し、入力・通知・集計・帳票作成の一部から自動化していくだけでも、現場の負担はかなり減らせます。

今回の「部品一括見積システム」は、その一つの実例です。

次回:最初に整理した業務フローについて。整備工場・サプライヤー・事務局の3者がどのように関わるのかを整理しながら、システム全体像を紹介します。

コメント

タイトルとURLをコピーしました