実践ノート2026年10月9日

システムを直すたびに高くなる。機能追加の前に、事業全体の設計を見直す

部分ごとの画面ができても、受注から入金までの情報が途切れれば手間は残ります。他社で進まなかった案件の経験から、改善し続けられる設計と保守の考え方をまとめます。

実践ノート｜第7回／全7回

システムはある。でも、少し変えたいだけで時間と費用が大きくなる。結局、担当者が表計算や手作業で埋め合わせている。私たちには、他社でプロジェクトがうまく進まなかったり、対応を断られたりした後の相談が来ることがあります。

そこで先に見るのは、追加する画面の数ではありません。商品、集客、商談、受注、在庫、配送、入金の中で、どの情報が途切れ、誰が何を補っているかです。部分だけが便利になっても、全体の流れがつながらなければ、現場の忙しさは残ります。

仕様が足りないより、仕事のつながりが見えていない

「見積もり画面をつくる」と決めても、仕様変更後の金額を誰が確認し、どの内容で注文が確定し、在庫や請求にどう引き継ぐかが決まっていなければ、別の場所で確認が必要になります。個々の機能は正しくても、業務としてはかゆいところに手が届かない状態です。

私たちは、お客さまと仕様をすり合わせながら、汎用システムでは合わない部分を開発してきました。例えば、預かり在庫と別注品の受注管理、カスタムオーダーの商談から決済まで、専門サービスの利用支援などです。共通するのは、その事業の売り方と運用に合わせて、つながりを設計することです。

先に全体を描き、つくる範囲は絞る

全体を見ることは、最初から全部を開発することとは違います。既存のEC、決済、倉庫システム、メール運用を生かせるところは生かします。そのうえで、どの情報を共通に持ち、どこで確定し、どの部分だけ個別につくるかを決めます。

まず現在の流れを整理し、目指す状態と差を比べる。次に、お客さまも担当者も実際に使う一連の手順から、最初の開発範囲を決める。途中の一画面だけが完成するより、一件の仕事が最後まで進むことを確かめる方が、改善の効果を判断しやすくなります。

変更が多い条件を後から直しやすくすること、例外を無理に通常の流れへ押し込まないこと、誰が何を確認したか分かることも、設計の論点です。情報が重複する場所や、担当者の記憶だけで動く仕事を先に見つけると、必要な開発を絞り込めます。

AIで速くつくれる時代ほど、何をつくるかが大事になる

AIの活用で、私たちも開発の進め方や請け負える範囲に余裕ができました。ただ、速くコードを書けることだけが、お客さまの価値になるとは考えていません。間違った流れを速くシステム化しても、運用では手戻りが増えます。

少数精鋭で無駄を減らし、改善の速度とコストを両立させる。そのためには、最初の設計と実際の業務の確認を省かないことが必要です。安さの理由を、品質や確認を削ることに置きたくありません。実際に使い続けられるかを、開発と保守の両方で確かめます。

完成した後も、月に一度、使い方と事業の変化を確認する

継続している案件では、月一回の定例ミーティングでシステムの改善を行い、信頼を重ねています。稼働して初めて分かる手間や、取引が増えて変わる条件を、次の更新へつなげるためです。開発を納めて終わる形より、実際の仕事に合わせて育てていく形を大切にしています。

費用の設計も、初期開発だけで判断しません。保守、追加改善、既存サービスの利用料、運用の手間まで合わせて考えます。初期開発費と保守を組み合わせた分割支払いで引き継いだ案件もありますが、条件は事業の見通しと資金計画を含め、案件ごとに検討するものです。私たちも長く関わるからこそ、お互いに改善を続けられる関係かを重視します。