Entersight

System & Data — 業務システム構築・データサイエンス

その作業、
人がやらなくていい。

人がやっていた業務を仕組みに置き換えると、人件費とミスが同時に減ります。これまで自動化が難しかった判断や文章の仕事も、AI を組み込むことで対象に入ってきました。

Approach

ゼロからつくるか、サービスをつなぐか。

業務システムのつくり方は、大きく2つに分かれます。イニシャルの開発費用、開発期間、保守のしやすさ、実際の使い心地などで、どちらが貴社にとって適切なのか話し合いましょう。

ゼロからつくる

中〜大規模になりやすい

既製品を使わず、フルオーダーで画面も処理も要件に合わせてつくります。既存システムが残る場合は、そこへつなぐ部分も設計に含めます。

メリット

  • 業務にシステムを合わせられる
  • 仕様を自社で決められる
  • 月額が人数ぶん積み上がらない

デメリット

  • イニシャルの開発費用が高くなる可能性がある
  • 開発期間が長い
  • 不具合対応と機能追加に、保守のランニングコストがかかる

サービスをつなぐ

小〜中規模で収まりやすい

会計・販売管理・勤怠・決済・チャットなど、既にあるサービスや OSS を組み合わせて作成します。足りない部分だけを自前でつくり、API でつなぎます。

メリット

  • イニシャルの開発費用が安くなる可能性がある
  • 短期間で動かせる
  • 本体の保守と法改正対応は提供元が持つ

デメリット

  • 月額が人数ぶん積み上がる
  • 業務をサービス側の仕様に合わせる場面が出る
  • 提供元の値上げ・仕様変更・サービス終了が、こちらの都合に関係なく突然起こる

つくれるものの例

  • 予約システム
  • 受発注システム
  • 販売管理システム
  • レジ / オーダー受付システム
  • Eコマース
  • 見積作成システム
  • 会員サイト / 会員管理
  • 在庫管理システム
  • 棚卸システム
  • 配送 / 配車管理
  • 工程 / 生産管理
  • 多拠点管理
  • 会計システム
  • 請求 / 入金管理
  • 経費精算システム
  • 勤怠管理システム
  • シフト管理システム
  • 申請 / 承認ワークフロー
  • 日報 / 報告システム
  • 社内ポータル
  • 社内専用チャット
  • 文書 / 契約管理
  • 顧客管理システム
  • 問い合わせ管理システム
  • アンケート / 集計
  • 通知 / メール配信
  • 経営ダッシュボード
  • 定期レポートの自動作成
  • 需要予測
  • レコメンド / 分類
  • 社内ナレッジ専用の生成 AI
  • 社内検索
  • 書類の読み取り(OCR)
  • 議事録の自動要約
  • 業務自動化(転記 / 連携)
  • 社内専用サービス
  • マッチングサービス

Process

最小構成から、育てる。

システム開発は、進めるほど作りたいものが増えて、品質と納期が崩れます。 先に拡張できる形の最小構成をつくり、動かしながら足していくのが安全です。

Phase 1

  1. 01困りごとの洗い出し今の手順を追い、詰まっている場所と、作らずに済む場所を見つける。
  2. 02最小構成の設計・実装あとから足せる形を先に決め、そこまでをつくる。ここを飛ばすと作り直しになる。
  3. 03動かして確かめる現場で使ってもらい、想定とのズレを早い段階で拾う。
  4. 04本実装・移行既存データを移し、運用に乗せる。

Phase 2+

02 — 04を繰り返します。1周ごとに、使われ方を見て優先順位を引き直し、機能を足します(アジャイル開発)。

Technology

技術は、組み合わせで決まる。

React と Go を軸に、案件に合わせて最適なものを選びます。 インフラも Google Cloud / AWS / Cloudflare / VPS を組み合わせ、必要なときに伸ばせて、普段は安く済む形を探します。

01

Architecture

アーキテクチャ

業務システムの寿命は、どの言語を使うかより「どこに何を置くか」で決まります。構成図のとおり、画面・処理と権限・データを分けて組むのが基本の形です。分けておくと、どれか1つを作り替えても他が巻き添えにならず、5年後に一部だけを入れ替えられます。

境界は API に置きます。業務のルールと「誰が何をしてよいか」の判断を API 側に集めてしまえば、画面が増えても判断が分かれません。あとからスマートフォンのアプリや、他社システムからの呼び出しを足すときも、同じ約束のまま使えます。

特定のクラウドにしか無い機能へ深く寄りかからないことも、設計のうちです。アプリケーションを Docker で包み、どこでも同じように動く状態にしておけば、料金改定や障害を理由にクラウドを移すときも作り直しになりません。1社に全部を預けると、その会社の都合がそのまま事業のリスクになります。

そして、一度に全部を置き換えないこと。既存のシステムは動かしたまま、業務の一部ずつを新しい仕組みへ移していきます。並走できる形にしておくと、途中で止まっても業務は止まりません。

層の分離画面・処理・データを分ける。1つ替えても他が壊れないAPI を境界に業務のルールと権限を1か所に集める疎結合つなぎ目を細くして、片方の都合が伝染しないようにするクラウド非依存固有機能に深く寄りかからない。移せる状態を保つ段階的な移行既存を動かしたまま、業務の一部ずつ移す監査ログ誰がいつ何を触ったかを残す。引き継ぎと監査に耐える冪等な処理二重に走っても結果が壊れないようにする
02

UI / UX Design

UI/UX デザイン

スキューモーフィズムが流行した時代から、現代のマテリアルデザイン、フラットデザイン、ニューモーフィズム、Fluent Design まで、時代とプラットフォームに最適化された手法を柔軟に取り入れています。

単なる見た目の美しさだけでなく、ユーザー行動の分析、情報アーキテクチャの設計、プロトタイピングとユーザーテストを通じて、使いやすさと美しさを両立させたインターフェースを構築します。

業務システムでは、使う人が毎日何百回も同じ画面を触ります。1クリック減らす、入力欄の並びを業務の順番に合わせる、といった地味な設計が、そのまま作業時間とミスの数に出ます。見た目を決める前に、誰が何の順番で操作するかを先に決めます。

Figma画面の案を先に見せて、作る前に合意を取る情報アーキテクチャ画面の数より、どこに何があるかの方が効くプロトタイピング触れるものにしないと、使いにくさは見つからないユーザーテストデザインシステム画面が増えても見た目と操作が揃うアクセシビリティキーボードだけでも通る。読み上げにも乗るレスポンシブ設計
03

Frontend

フロントエンドReact

フロントエンド開発の言語として世界で最も人気のあるライブラリである React を採用しています。React は 2013 年に Facebook(現 Meta)が開発した JavaScript ライブラリで、フロントエンド開発においてデファクトスタンダードとなっています。

Microsoft が開発した JavaScript のスーパーセットである TypeScript と親和性が高く、静的型付けによって型安全性を確保でき、バグの少ない堅牢なコードを記述することが可能です。また、豊富なエコシステムも大きな魅力で、Next.js や Astro などの高機能フレームワーク、多数の UI ライブラリやツールが充実しており、開発効率を大幅に向上させます。

さらに、React は大規模なコミュニティに支えられており、最新の情報やベストプラクティスが常に共有されています。これにより、問題解決が迅速で、長期的なメンテナンス性も高く保つことができます。世界中の主要企業が採用している実績も、技術選定の信頼性を裏付けています。

このような理由から、当方では React をフロントエンド開発のファーストチョイスとして採用し、高品質で保守性の高いシステムをお客様に提供しています。

React画面の状態を1か所で持てる。人手が増えても壊れにくいTypeScript型で間違いを実行前に落とすNext.jsサーバ側で描けるので、初回表示が速いViteCSS Modules画面ごとに見た目が閉じる。他の画面を壊さないTanStack Queryサーバから取った値の鮮度を1か所で管理するReact Native
04

Backend

バックエンドGo

API 開発の言語として、Go(Golang)を採用しています。Go は 2009 年に Google が開発したプログラミング言語で、シンプルさと効率性を追求し、特に並行処理(Goroutine)を容易に扱えるよう設計されています。

C 言語並みの高速な実行速度を誇りながら、ガベージコレクション機能により安全なメモリ管理が可能で、型安全でバグの少ない堅牢なコードを記述できます。コンパイル時に単一の実行ファイルが生成されるため、デプロイが非常にシンプルで、依存関係の問題も最小限に抑えられます。

Go の大きな特長として、充実した標準ライブラリがあります。HTTP 通信、JSON 処理、データベース接続など、API 開発に必要な機能の多くが標準で提供されており、外部のエコシステムに過度に依存することなく実装を完結できます。これにより、依存パッケージの管理コストを削減し、セキュリティリスクも低減できます。

また、Docker や Kubernetes、Prometheus など、クラウドネイティブ領域の主要プロジェクトの多くが Go で開発されています。大規模なトラフィックを処理する必要があるシステムでも安心して使える高い拡張性とパフォーマンスを備えており、マイクロサービスアーキテクチャとの相性も抜群です。

このような理由から、当方では Go を API 開発の中核技術として採用し、高速で安定性の高いバックエンドシステムをお客様に提供しています。

Go並行処理に強く、単一バイナリで動く。落ちにくく移しやすいNode.jsフロントと同じ言語で書ける。小さく始めるとき速いFastAPIPython の分析処理をそのまま API にできるDjangoLaravel既存の PHP 資産を引き継ぐときREST APIGraphQL画面ごとに必要な分だけ取りたいときWebSocket在庫や予約など、ずれると困るものをリアルタイムに認証・権限設計誰が何をしてよいかを1か所に集めるバッチ / cron
05

Data & AI

データと AIPython

データサイエンス・AI 領域の開発用言語として、Python を採用しています。Python はシンプルで読みやすい構文が特徴で、エンジニアに限らず数学者や研究者など幅広い職種の方々に受け入れられています。

このため、膨大な数のライブラリとフレームワークが開発されており、機械学習の TensorFlow や PyTorch、データ分析の pandas や NumPy など、最先端の技術を素早く導入できます。特に AI・機械学習分野ではデファクトスタンダードの地位を確立しており、学術論文で発表された最新のアルゴリズムも、多くの場合 Python での実装が最初に公開されます。これにより、最新技術をいち早くビジネスに活用することが可能です。

また、活発なコミュニティと豊富な知見も大きな強みです。問題解決のための情報が充実しており、開発効率を高めることができます。

当方では、Python を用いて AI 機能や分析エンジンを開発する際、FastAPI などの軽量フレームワークを活用し、必要最小限の機能を持った API エンドポイントを作成します。これを Go で開発したメイン API から呼び出す構成により、各言語の強みを活かしたマイクロサービスアーキテクチャを構築し、高い保守性とスケーラビリティを実現しています。

Python分析と機械学習の資産がそろっているSQLデータの正しさは最後ここで担保するPostgreSQL業務データの既定。制約で不整合を防げるMySQLMongoDB形が定まらないログや下書きを受けるときRedis取り合いになる在庫・座席の整理にBigQuery量が増えても集計時間が伸びないpandasNumPyscikit-learn需要予測や分類を、重い基盤なしで試せるJupyterETL / データ基盤Looker Studio見る人が自分で触れる。更新を頼まれ続けないClaude API長い文脈を読ませる仕事に強いOpenAI APIGemini APIRAG社内の資料だけを根拠に答えさせる仕組みベクトル検索言い回しが違っても同じ意味の文書を拾うプロンプト設計評価・監視出力がずれていないかを後から検証できる状態に
06

Infrastructure

インフラストラクチャーGCP / AWS / Cloudflare

システムを載せる土台として、Google Cloud・AWS・Cloudflare を組み合わせて構築します。どれか1つに揃えるのではなく、要件ごとに得意な部分を使い分ける方針です。1社に寄せると、その会社の価格改定や障害がそのまま事業のリスクになります。

AWS は提供されるサービスの数が最も多く、要件がまだ読みきれない段階での既定にしています。あとから必要になったものが、だいたい揃っています。Google Cloud は BigQuery を中心としたデータ基盤が強く、集計や分析を伴うシステムではこちらを選びます。

Cloudflare は転送量に対する課金の考え方が他社と異なり、アクセス数が読めない部分を定額に寄せられます。配信や画像の最適化、迷惑アクセスの遮断をここに任せることで、計算資源そのものの費用を抑えられます。規模が小さいうちは VPS を使い、固定費を月数千円に収めることもあります。

いずれの構成でも、Docker でアプリケーションを包み、どこでも同じように動く状態にしておきます。GitHub Actions で検査と公開を自動化し、監視とログで異常に人より先に気づけるようにします。これにより、将来クラウドを移す必要が出たときも、作り直さずに移動できます。

AWS必要なものが全部ある。要件が読めないときの既定Google CloudBigQuery まわりを使うなら素直Cloudflare転送量が読めない所を定額に寄せられるVPS規模が小さいうちは一番安い。固定費を抑えるDocker手元と本番の差をなくすLinuxGitHub Actions検査と公開を自動で回すNginx監視 / ログ落ちたことに人より先に気づくIaC(Terraform)構成をコードで残す。同じものを作り直せる
07

DevOps

開発・運用GitHub Actions

つくって納めて終わり、にはしません。業務システムは納品後のほうが長く、直す回数も多くなります。そこで、直して出すまでの手順を最初に自動化しておきます。

環境は開発・検証・本番の3つに分けます。試すのは検証まで、本番に触れるのは通った変更だけ、という順序を仕組みで固定します。これがないと「手元では動いていた」が本番の障害になります。

GitHub Actions で、変更のたびに型検査・テスト・ビルドを自動で走らせ、通ったものだけを公開します。人が手順書を見ながら作業する工程を残さないことで、作業ミスによる障害を減らせます。構成そのものも Terraform でコードに残すので、同じ環境をいつでも作り直せます。

動かしたあとは、監視とログで異常に人より先に気づける状態にします。問題が出たときは前の版へ戻せるようにしてあるので、原因を調べる時間と、業務が止まる時間を切り離せます。

GitHub Actions検査と公開を自動で回す環境分離開発 / 検証 / 本番。通った変更だけが本番へ行く自動テスト直したつもりが別の場所を壊していないか毎回見るDocker手元と本番の差をなくすTerraform構成をコードで残す。同じものを作り直せる監視 / アラート落ちたことに人より先に気づくロールバック問題が出たら前の版へ戻す。原因調査と復旧を分けるドキュメント / 引き継ぎ担当が替わっても運用が続く状態にする

※ 代表例です。記載外の技術・既存環境への追随もご相談ください。

※ 規模が大きい案件は、フリーランスの開発者と組んでチームを編成します。設計と技術選定、全体の進行は当方が持ちます。

Works

実績

FAQ

よくある質問

要件がまだ固まっていません。相談できますか?
その状態からで問題ありません。「今どう回しているか」を伺うところから始めます。作らずに済む部分があれば、それも含めてお伝えします。
大きな案件もお願いできますか?
規模に応じてフリーランスの開発者と組み、チームを編成して進めます。設計と技術選定、全体の進行は当方が持ちます。
既存システムの改修・引継だけでも依頼できますか?
できます。他社が作ったものの改修・移行・保守引継のご相談も歓迎します。まず現状のコードと構成を確認させてください。
費用感を知りたいのですが。
業務システムは規模と範囲で大きく変わるため、定価は置いていません。ヒアリングのうえ、優先順位をつけた見積りを無料で出します。

まずは、業務の話から。

要件が固まっていなくて構いません。今の手順を伺うところから始めます。2営業日以内にご返信します。

無料相談する