LIN CHIACHENG
  1. Work
  2. NEXUS

01 / 07INDEPENDENT BUSINESS SYSTEM PROJECT

NEXUS

顧客・見積・案件・請求を、ひとつの業務管理の流れに。

NEXUS の経営者向け画面。予定、経営指標と進行案件をまとめたビュー。
概念設計 — 経営者の視点。

以前の仕事で感じた不便をきっかけに、自ら提案し、学んだ技術とAIを使って開発を続けているシステムです。

役割
プロダクト / 開発
技術スタック
React · Spring Boot · PostgreSQL · Docker
状態
IN DEVELOPMENT · 2026

GitHub（非公開）

01

慣れた仕事から、プロダクトづくりへ。

起点の流れ

以前の業務では、紙の資料、Excel、顧客情報が分散し、同じ内容を何度も照合する必要がありました。 日本で開発を学んだ後、以前の仕事の仲間に連絡し、顧客・見積・案件・請求の流れを一つのシステムに整理する構想を提案しました。何度か話し合うなかで NEXUS が始まり、現在も実装と検証を続けています。日々の確認作業を、より明確で継続して使える業務の流れへ整えることが目的です。

構想の中心

機能を増やすのではなく、仕事の流れそのものを、ひとつにつなぎ直す。

NEXUS / 01
  • 顧客
  • 見積
  • 案件
  • 請求・支払

NEXUSひとつの業務基盤

業務をつなぎ直す構想図

構想の四段階

  1. 01EXPERIENCE

    経験

  2. 02OBSERVE

    観察

  3. 03REFRAME

    再定義

  4. 04BUILD

    構築

整理の原則

  1. 01

    整理

    散らばった情報を見つける。

  2. 02

    接続

    分かれていた流れをつなぐ。

  3. 03

    簡素化

    不要な操作を減らす。

02

機能の前に、仕事の流れをつなぐ。

BEFORE

  • 顧客名簿Excel
  • 見積書Excel / Word
  • 案件管理表計算
  • 請求処理別システム
NEXUSひとつに、つなぐ。

OUTCOME

  1. 01

    主要な流れからつくる

    要求は変わり続けるため、まず主要な流れをつくり、残りは段階的に加える。

  2. 02

    操作を複雑にしない

    機能が多くても、操作は複雑にしない。

  3. 03

    最後は自分で判断する

    ひとりの視点に閉じないためにAIを使い、最後は自分で判断する。

同じ仕事なのに、なぜ情報をあちこち探す必要があるのか。顧客、見積、案件、請求のつながりを整理してから、画面を考えました。

顧客情報、見積、案件、請求が別々の場所にあると、必要な情報を探す時間が増え、判断は遅れる。

優先したのは、機能の多さではなく、迷わず使える流れだった。

章の結論

問題の本体は、機能の不足ではなく、業務の流れが分断していたことだった。

NEXUS / 02 · NOTE

03

実際に扱える業務のかたち。

構想と判断を、実際に扱える画面と流れへ落とし込む。

顧客情報から案件の進捗まで、日々確認する情報を一つの場所にまとめます。

NEXUS は、顧客からの問い合わせを起点に、見積・案件・請求までを一つの業務基盤で扱う。

ワークスペース — 今日の仕事の入口。
ワークスペース — 今日の仕事の入口。

主要モジュール

  1. 01

    CUSTOMER顧客管理

    顧客と関連する記録をひとつに。

  2. 02

    QUOTATION見積

    問い合わせから見積までを同じ流れで扱う。

  3. 03

    PROJECT案件管理

    見積のあとも案件の記録をつなぐ。

  4. 04

    OPERATIONS請求・支払・業務管理

    請求・支払・管理を同じ基盤で扱う。

動かせる画面

見積のテスト版から統合版へ進んだ時期の画面。書き直した新システムとは、開発段階を分けています。

案件管理 — 案件と状態を一覧する。
案件管理 — 案件と状態を一覧する。
見積項目 — AIで項目を作るための入力画面。
見積項目 — AIで項目を作るための入力画面。

公式サイトのリニューアル

ホーム、サービス、施工事例。業務システムとは別の Web 制作として並べています。

公式サイトのリニューアル — ホーム。
公式サイトのリニューアル — ホーム。
公式サイトのリニューアル — サービス。
公式サイトのリニューアル — サービス。
公式サイトのリニューアル — 施工事例の一覧。
公式サイトのリニューアル — 施工事例の一覧。

新システムの初期記録

この提供画面は連絡先の基礎を示します。記録時点では PR は未マージで、業務システム全体の納品を示す画面ではありません。

連絡先の基礎 — 提供された初期画面。
連絡先の基礎 — 提供された初期画面。

概念設計

管理者と工務担当者の視点を検討した概念画面。実装済み機能や実際の経営数値とは区別しています。

概念設計 — 管理者のダッシュボード。
概念設計 — 管理者のダッシュボード。
概念設計 — 工務担当者のワークスペース。
概念設計 — 工務担当者のワークスペース。

業務ライフサイクル

  1. 01

    INQUIRY

    問い合わせ・受付

  2. 02

    QUOTE

    見積

  3. 03

    CONTRACT

    契約・顧客

  4. 04

    DELIVERY

    納品・案件

  5. 05

    BILLING

    請求・支払

章の結論

構想と判断は、実際に扱える画面と流れになって初めて検証できる。

NEXUS / 03 · NOTE

04

学びながら、AIと一緒につくる。

開発経験を積んでいる途中だからこそ、作業を小さく分け、AIに整理や実装、別の視点での確認を手伝ってもらいます。分からないことはコード、テスト、実際の画面に戻って確かめ、次へ進みます。

AIを使う。

判断は任せない。

AI 開発工程

  1. 01

    要件を整理

    要件と問題を、まず言葉にする。

  2. 02

    AIと検討

    整理・比較・リスク・選択肢。

  3. 03

    自分で判断

    判断・取捨・検証は自分が担う。

  4. 04

    小さく実装

    小さく実装し、動く単位で積み上げる。

  5. 05

    動作を確かめる

    テストとレビューで確かめる。

作業に合わせて、道具を使い分ける。

01

考えを整理する

要件を整理し、問題を分け、選択肢を比較して次の方向を考える。

作業環境
ChatGPT
使用モデル
GPT-5.6 · GPT-6
02

小さくつくり、直す

作業に応じて環境とモデルを使い分け、画面実装、デバッグ、改修を進める。

作業環境
Codex · Cursor · OpenCode · OMO
使用モデル
Composer 2.5 · GPT-5.6 · GPT-6 · DeepSeek V4.1 · Muse 1.3
03

実際の画面を見比べる

スクリーンショットを見比べ、実装と意図のずれを複数の視点で確認する。

使用モデル
Gemini 3.8 Flash · Grok 4.7 · GPT-6 Astra

採用するかは、自分で確かめて決める。

AI の提案や各モデルの結果を比較し、採用・却下を判断する。コードと実際の操作を確かめ、確認できた内容をもとに修正する。必要なら別のモデルにも再レビューを依頼する。

  • Build / Typecheck
  • Tests
  • Browser / E2E / Smoke
  • Screenshot / Visual QA

実際に使った道具の概要です。詳しい分担と開発方法は、別の AI Workflow ページへ。

07 / AI DEVELOPMENT WORKFLOW →

05

画面・処理・データの役割を分ける。

学んだReact、Spring Boot、PostgreSQLを使って、画面操作、業務処理、データの保存をつなげています。役割を分けることで、一つずつ理解し、確かめられるようにしています。

中核の層

概念上の責務
横断する考慮AUTH / ROLE認証・権限
  1. 01

    画面操作

    利用者が触れる画面操作を受け持つ。

    フロントエンド · React / TypeScript

  2. 02

    業務処理

    業務の流れに沿った処理を受け持つ。

    バックエンド API · Spring Boot

  3. 03

    データの保存

    扱うデータを保存する役割を受け持つ。

    データベース · PostgreSQL

横断する考慮DOCKER / VM開発・配備環境

検証済みの支援技術

  • Docker

    実行環境をコンテナで揃え、同じ前提で動かせるようにする。

  • Git

    ソースと変更履歴を、ひとつの履歴として管理する。

  • Authentication

    利用者を識別する。

  • Authorization

    役割ごとに操作範囲を分ける。

  • Validation

    扱う値が正しいかを確かめる。

  • Audit Log

    操作の記録を残す。

章の結論

層ごとに確かめ、全体で整合を取る。構造はその順序を決めるものだ。

NEXUS / 05 · NOTE

06

形になってきた。改善は、まだ続く。

現在も開発中です。使う人と確認しながら、機能や操作を調整しています。これからも主要な流れを確かめ、役立つものと、見直すべきものを見極めていきます。

  1. IDEA
  2. PROTOTYPE
  3. CORE SYSTEM
  4. NOW
  5. NEXT

  1. 01

    WHAT EXISTS NOW

    顧客・見積・案件を横断する基本フロー

  2. 02

    WHAT I LEARNED

    機能を増やすより、判断と情報の流れを設計すること

  3. 03

    WHAT COMES NEXT

    実運用を想定した検証・改善・自動化

現在の言葉

考えたものを、使えるものへ。

NEXUS / 06
NEXUS — LIN CHIACHENG