MENU
cases
事例紹介
dot
業務システム

内職(在宅作業者)管理システム

誰に、何を、いくつ頼んで、いくつ戻ってきたか。紙で回していた内職管理を仕組みに

紙と担当者の記憶で回していた内職管理をシステム化。作業依頼のテンプレート化と、商品・作業・資材のマスタ連携で日々の入力を軽くする設計です。

システム概要

業種
製造業(箸・生活雑貨)
システム規模
約20画面(内職者・作業内容・資材・商品・作業依頼・テンプレート・実績照会・配達員向け・利用者管理 等)
開発期間
7ヶ月
費用レンジ
400万円〜450万円
使用技術
Laravel + Next.js(フルスクラッチ開発)
プラットフォーム
Linux(Webアプリ)

背景・課題PROBLEM

内職さんの管理は、担当者の頭の中にある

自社の商品を仕上げる工程の一部を、地域の内職(在宅作業者)の方々に依頼されているお客様でした。

課題課題
  • 内職の方の連絡先や振込先、誰にどの作業をお願いできるかが体系的に管理されていない内職の方の連絡先や振込先、誰にどの作業をお願いできるかが体系的に管理されていない
  • 作業依頼の内容や単価、必要な資材の紐づけがその都度の判断になっている作業依頼の内容や単価、必要な資材の紐づけがその都度の判断になっている
  • いつ・何個回収予定なのかが一覧で見えず、進捗が把握しづらいいつ・何個回収予定なのかが一覧で見えず、進捗が把握しづらい
  • 回収後の実績数量や不良品数の記録が残らない回収後の実績数量や不良品数の記録が残らない

提案SUGGESTION

  1. パッケージではなくフルスクラッチを選ぶ理由を示す
  2. 開発範囲を段階で区切る
  3. 依頼を「テンプレート」と「複製」で軽くする
  4. 商品と作業をデータでつなぐ
  5. 実績と不良品を記録する

パッケージではなくフルスクラッチを選ぶ理由を示す

パッケージとフルスクラッチを、初期コスト/導入スピード/カスタマイズ/運用適合性/拡張性/保守性の6観点で比較した表をお示ししました。内職管理という業務の性質上、業務をシステムに合わせるのではなく、業務にシステムを完全に合わせるほうが適していると判断し、フルスクラッチをご提案しています。

開発範囲を段階で区切る

今回の開発範囲を「内職さん管理」「作業内容マスタ管理」「依頼管理」「システム利用者管理」に絞り、資材在庫管理と資材マスタ管理は将来的な開発範囲として図で明示。最初から全部作らず、まず回る形をつくる進め方をご提案しました。

依頼を「テンプレート」と「複製」で軽くする

よく使う作業依頼の組み合わせをテンプレートとして登録し、依頼登録時に明細として呼び出せるようにします。過去の作業依頼を複製して登録することも可能とし、日々の依頼入力の手間を減らします。

商品と作業をデータでつなぐ

・商品にはセット商品の概念を取り入れ、既存の商品を組み合わせて別の商品として登録可能(夫婦箸など)
・商品には、それを作るために必要な作業内容を紐づけて登録
・作業内容には名称・単価に加え、必要な資材を紐づけ

実績と不良品を記録する

回収後に実績の数量と不良品数を登録でき、実績・出来高照会画面で確認できるようにしました。配達員向けの機能も用意しています。

成果RESULT

  • 内職の方の情報(氏名・住所・連絡先・銀行口座)を一元管理する構成を提示内職の方の情報(氏名・住所・連絡先・銀行口座)を一元管理する構成を提示
  • 作業依頼のテンプレート化・複製により、日々の依頼入力を効率化する設計作業依頼のテンプレート化・複製により、日々の依頼入力を効率化する設計
  • 商品・作業内容・資材のマスタ連携により、必要な資材が自動的に導かれる構造商品・作業内容・資材のマスタ連携により、必要な資材が自動的に導かれる構造

※2026年8月時点で提案段階。

commentコメント

「まずどこから作るか」を提案の中で明示するようにしています。今回は資材の在庫管理まで一気に作ることもできましたが、まずは内職さんの管理と依頼管理から始め、運用が回り始めてから在庫管理へ広げる形をご提案しました。フルスクラッチかパッケージかも、比較表でメリット・デメリットを両方お示ししたうえでご判断いただいています。

dot
dot
PAGETOP