システム開発

小さく作って、業務に合わせて育てるシステム開発

Excel・紙・メールで分散した業務、既存システムの改修、新規サービスの初期開発まで、最初から大きく作り込まず、必要な範囲を公開して改善しながら育てます。

anytoolsができるシステム開発

  • 業務システム開発
  • Webシステム開発
  • 既存システム改修
  • API・外部連携
システム開発について問い合わせる

課題

こんな課題を解決します

業務改善も新規事業も、運用課題や検証したい価値から一緒に整理します。

Excelや紙の運用課題を整理する手描きイラスト

課題

Excel・紙・メール運用に限界が来ている

受発注、在庫、予約、顧客管理がExcelや紙、メールに分散し、確認と転記に時間がかかっている。

課題

同じ情報を何度も入力している

問い合わせ、見積、請求、在庫などを複数のシステムに二重入力していて、ミスや確認漏れが起きやすい。

課題

古い業務システムを改修しづらい

基幹システムや社内システムが老朽化し、少し直すだけでも時間や費用が読みにくくなっている。

課題

SaaSが自社業務に合わない

パッケージや既存SaaSでは業務の流れに合わず、結局手作業や例外対応が残っている。

課題

特定担当者しか運用できない

判断基準や作業手順が担当者の経験に依存し、引き継ぎや休職時の対応が不安定になっている。

課題

データが活用できない

売上、在庫、案件、顧客情報が別々に管理され、状況把握や改善判断に使える形になっていない。

課題

新しい事業の価値を検証したい

最初から大きく作り込むのではなく、うまくいくか分からないサービスやアプリを小さく公開し、反応を見ながら改善したい。

課題

AIで作った業務システムの運用が不安

AIで一度形にしたものの、権限管理、データ保護、保守性、障害時の対応など、実運用で問題が起こらないか確認したい。

提供サービス

用途別に相談できます

システム開発一式ではなく、業務、Web、改修、連携、インフラ、運用のどこからでも相談できます。

用途別の開発メニューを選ぶ手描きイラスト

対応領域

業務システム開発

日々の業務を整理し、現場が使い続けられる仕組みにします。

  • 顧客管理
  • 案件管理
  • 在庫管理
  • 受発注管理
  • 予約管理

対応領域

Webシステム開発

顧客や会員、社内担当者がブラウザから使えるサービスを作ります。

  • 会員サイト
  • ポータル
  • 管理画面
  • マッチング
  • 業務アプリ

対応領域

既存システム改修

今あるシステムを活かしながら、使いにくさや古さを段階的に直します。

  • レガシー改修
  • 機能追加
  • UI改善
  • クラウド移行

対応領域

API・外部連携

分断されたツールやデータをつなぎ、二重入力や確認作業を減らします。

  • 会計
  • CRM
  • EC
  • 決済
  • LINE
  • Google Workspace
  • 基幹連携

対応領域

クラウド・インフラ

VercelやCloudflareなど、運用負荷を抑えやすい基盤で公開します。

  • Vercel
  • Cloudflare
  • Supabase
  • Google Cloud
  • 監視
  • バックアップ

対応領域

保守・運用

作って終わりではなく、障害対応や改善開発まで継続して支えます。

  • 障害対応
  • 改善開発
  • セキュリティ更新
  • 定期レビュー

選ばれる理由

不安が残りやすい論点を、先に整理します

柔軟さや品質ではなく、発注前後で不安になりやすい業務理解、作り方、運用安全性を具体的に扱います。

不安な論点をチェックして整理する手描きイラスト

業務理解

開発前に業務フローと改善余地を整理します

現場ヒアリングから今の流れ、例外対応、二重入力、属人化している判断を可視化し、作る前に改善できる部分を分けます。

技術選定

SaaS活用、ローコード、スクラッチを比較します

最初から全てを作り込まず、要件と運用に合わせて既存サービス活用や部分開発も検討し、過剰開発を避けます。

運用安全性

リリース後の改善と安全性まで見ます

障害対応、改善開発、セキュリティ更新、権限設計、ログ、バックアップ、定期レビューまで運用前提で整理します。

開発プロセス

発注後に何が起きるかを、先に見える化します

初回相談からリリース後の改善まで、進め方と判断ポイントを分けて共有します。

開発プロセスが順番に進む手描きイラスト

step 1

初回相談

課題、現状、予算感、納期、既存システムを確認します。

step 2

業務・要件整理

業務フロー、利用者、必要機能、優先順位を整理します。

step 3

概算見積り・提案

開発範囲、体制、スケジュール、費用、リスクを提示します。

step 4

契約・着手

開発範囲、検収条件、支払い条件、保守範囲、権利関係を確認し、契約後に着手します。

step 5

設計

画面、データ、権限、外部連携、VercelやCloudflare前提の公開構成を設計します。

step 6

開発・テスト

スプリント開発、レビュー、結合テスト、受入テストを進めます。

step 7

リリース

本番反映、操作説明、移行、初期サポートを行います。

step 8

保守・改善

障害対応、追加改修、定期改善、セキュリティ更新を続けます。

成果物

開発中も、リリース後も、判断に必要なものを残します

画面だけでなく、何を確認し、何を後回しにし、次に何を判断するかを残すことで、成長させる開発にします。

仕様書や運用手順を残す手描きイラスト

確認環境

共有URLで見られる初期プロジェクトと開発中の画面です。

  • URLで共有
  • 骨組みから確認
  • 早期フィードバック

MVP計画

最初に作るもの、後回しにするもの、判断条件を整理します。

  • 最小実装
  • 後回しリスト
  • 次へ進む条件

リリースメモ

何が使えるようになり、何を確認してほしいかを残します。

  • 今回の変更
  • 確認観点
  • 既知の未対応

運用・改善メモ

次に直すこと、利用状況、ランニングコストを見返せるようにします。

  • 利用状況
  • 改善候補
  • コスト見直し

向き不向き

小さく始めて育てたい事業や業務改善に向いています

すべての開発に向くわけではありません。短期リリースと改善判断を前提にできる場合に効果が出やすい進め方です。

向いているケースと向いていないケースを確認する手描きイラスト

向いているケース

  • 新規事業の初期プロダクト
  • 既存業務を少しずつシステム化したい
  • 社内向け管理画面や予約・申請・顧客管理を作りたい
  • まず利用者の反応を見たい
  • ランニングコストを抑えて始めたい

向いていないケース

  • 要件が完全固定で、短期の一括納品だけを求める
  • リリース後の改善や運用判断を一切行わない
  • 初回から大規模な冗長構成や24時間専任運用を必須とする
  • 法規制や認証要件が重く、初期から専門監査が必要

費用感・見積り方針

相談前に、どのレンジから検討できるかを見える化します

システム開発は内容によって費用が変わります。完全に隠すのではなく、入口の費用感と、見積りが変わる理由を先に共有します。

費用感と見積り方針を確認する手描きイラスト

相談・調査フェーズ

無料〜 / 有償診断 10万円〜

要件整理、業務フロー整理、概算見積り、既存システム調査

作る前に課題、優先順位、概算費用を整理します。

小規模改善

30万円〜

既存システム改修、フォーム改善、管理画面追加、通知追加

対象画面や機能が限られている改修を想定します。

中規模開発

120万円〜

業務システム、会員サイト、予約管理、顧客管理

複数画面、権限、データ管理を含む新規開発を想定します。

大規模開発

300万円〜 / 個別見積り

基幹連携、複数部門利用、外部API連携、データ移行

影響範囲、連携先、移行要件を確認して見積ります。

保守・改善

月額5万円〜 / チケット制

障害対応、軽微改修、定期レビュー、セキュリティ更新

リリース後の改善頻度と対応範囲で決めます。

見積りで確認すること

金額は画面数だけで決まりません。業務の複雑さ、連携、権限、移行、運用体制まで確認し、機能単位・工程単位・保守費用を分けて提示します。

費用が変わる主な要素

  • 必要な画面数と利用者の種類
  • 権限、承認、ログ、監査の要件
  • 外部API、既存システム、SaaSとの連携数
  • データ移行、既存データの整理量
  • セキュリティ、バックアップ、監視の水準
  • リリース後の保守・改善体制

料金に関する補足

表示価格は税別の目安です。正式な費用は、画面数、利用者数、権限設計、外部連携、データ移行、セキュリティ要件、保守範囲によって変わります。サーバー費用、外部API利用料、SaaS利用料、決済手数料、監査・専門家対応が必要な場合の費用は内容により別途となります。

支払い条件

基本的には、着手時・中間確認時・リリース時など、フェーズごとの請求で進めます。小規模改修や調査のみの場合は、一括請求になる場合があります。

仕様変更時の扱い

開発途中で仕様変更が必要になった場合は、影響範囲、追加費用、納期への影響、優先順位を確認し、合意してから反映します。

技術スタック

アプリ開発に集中できる、軽く保てる構成を選びます

技術名よりも、運用しやすさと将来の改善しやすさを重視して選定します。Next.jsとAstroを軸に、インフラはVercelやCloudflareのフルマネージド基盤へ寄せます。スマホアプリはReact Native、データベースはPostgreSQLを基本に、運用しやすい形でまとめます。

技術スタックを確認する手描きイラスト

Webアプリ / サイト制作

  • Next.js
  • Astro
  • TypeScript

選ぶ理由

フロントエンドとバックエンドは基本的に分けず、バックエンドが必要な場合はNext.js、サイト制作のみの場合はAstroを使います。

運用への影響

画面、API、公開構成を分断しすぎず、サーバー構成と保守の見通しをシンプルにします。

フルマネージドインフラ

  • Vercel
  • Cloudflare

選ぶ理由

サーバー運用体制を自前で大きく抱え込まず、運用基盤は各プロバイダーに任せます。

運用への影響

インフラ運用よりも、アプリ開発、改善、ユーザー体験づくりに時間を使いやすくします。

スマホアプリ

  • React Native
  • Android / iOS

選ぶ理由

AndroidとiOSを共有し、Webやサーバー側と近い実装感で作れる構成を選びます。

運用への影響

別々のアプリを保守する負担を抑え、機能追加や改善の速度を揃えやすくします。

データベース

  • PostgreSQL
  • Supabase
  • Google Cloud

選ぶ理由

基本はPostgreSQLを使い、要件や運用に応じてSupabaseまたはGoogle CloudのマネージドDBを選びます。

運用への影響

アプリの成長に合わせて、データの検索、集計、権限管理、バックアップを扱いやすくします。

外部連携

  • REST API
  • GraphQL
  • Webhook
  • SAML

選ぶ理由

既存システムやSaaSとのつなぎ方、リアルタイム性、認証要件に合わせます。

運用への影響

二重入力や手作業の確認を減らし、既存資産を活かします。

業務ツール

  • kintone
  • Salesforce
  • Google Workspace
  • freee
  • LINE

選ぶ理由

すべてを作るのではなく、既に使っている道具を活かせるかを先に検討します。

運用への影響

過剰開発を避け、導入後の運用コストを抑えます。

品質

  • GitHub Actions
  • CI/CD
  • E2Eテスト
  • 監視

選ぶ理由

リリース後に壊れたまま気づけない状態を避けるため、確認と検知の仕組みを入れます。

運用への影響

継続改善、障害対応、セキュリティ更新を進めやすくします。

セキュリティ・契約・保守

納期、情報漏洩、作りっぱなし、権利関係の不安を先に整理します

開発そのものだけでなく、秘密保持、成果物の権利、個人情報、保守範囲、途中変更の合意フローまで、発注前に確認できる状態にします。

セキュリティと契約条件を確認する手描きイラスト

NDA

初回相談前の秘密保持契約に対応します

未公開事業、社内業務、顧客情報、既存システムの構成など、相談前に守るべき情報がある場合はNDA締結後に進められます。

IP・著作権

ソースコード、設計資料、成果物の権利方針を確認します

納品物、利用ライブラリ、再利用部品、設計資料の扱いを契約時に整理し、後から権利関係が曖昧にならないようにします。

セキュリティ

権限管理、ログ、バックアップ、脆弱性対応を設計に含めます

誰が何を見られるか、重要操作を追跡できるか、障害時に復旧できるかを、機能要件と同じように確認します。

個人情報

個人情報・機密情報の取り扱い範囲を明確にします

顧客情報、従業員情報、問い合わせ内容など、扱うデータの種類に応じて保存場所、閲覧権限、削除方針を整理します。

保守

障害対応、対応範囲、月額費用、改善提案を分けて提示します

作って終わりにせず、障害時の連絡方法、対応時間、軽微改修、定期レビュー、改善開発の範囲を事前に決めます。

ドキュメント

仕様書、設計書、運用手順、引き継ぎ資料を残します

担当者が変わっても運用できるように、画面、データ、権限、外部連携、日常運用の要点を残します。

途中変更

仕様変更時の見積り・合意フローを決めます

開発途中の変更は起こり得ます。影響範囲、費用、納期、優先順位を確認し、合意してから反映します。

契約前に確認する項目を曖昧にしません

納期、対応範囲、検収条件、保守費用、権利の扱い、秘密情報の範囲は、開発開始後に揉めやすい論点です。見積り時点で確認し、必要に応じて契約書や発注書に反映します。

よくあるご質問

問い合わせ前に迷いやすい壁を、先に潰します

要件、費用、納期、保守、権利、セキュリティなど、相談前に気になりやすい論点を実務ベースで整理しています。

問い合わせ前の質問に回答する手描きイラスト

可能です。最初から仕様書を完成させる必要はありません。現状業務、困っていること、利用者、優先順位を整理し、作るべき範囲と後回しにする範囲を一緒に決めます。

相談・依頼範囲

要件が曖昧な段階や、小さな改修だけの相談可否を整理します。

費用・納期

問い合わせ前に知りたい費用感、変動要因、納期目安を整理します。

契約・保守・セキュリティ

納品後の運用、権利、セキュリティに関する不安を整理します。

まだ仕様が固まっていない段階でも相談できます

最初から完璧な仕様書がなくても問題ありません。事業の理想像、最初に検証したい価値、運用費の上限を一緒に整理し、最初のリリース単位を決めます。