基礎知識

システム構成の読み方。フロント・バック・DB・インフラを理解する

提案書や構成図を見ても、どこが何なのか分からない。この記事では、システムを4つの層に分けて説明します。この区別ができると、見積もりの内訳や、変更の難易度が読めるようになります。

システムは4つの層でできている

どんなシステムも、おおむね次の4層に分かれます。

• ①画面（フロントエンド）／利用者が見て触る部分。ブラウザやアプリの画面
• ②処理（バックエンド）／裏側で動く仕組み。計算、判定、他システムとの連携
• ③データ（データベース）／情報を保存しておく場所
• ④基盤（インフラ）／これらが動くためのサーバーやネットワーク

この4つを区別できると、話の対象が明確になります。「システムが遅い」という相談も、どの層が原因かで対処がまったく変わります。

商談で構成図を見せられたとき、まずどこが4層のどれにあたるかを把握すると、全体像が掴めます。

画面（フロントエンド）

利用者が直接触る部分です。ボタン、入力欄、一覧表示。顧客が最も具体的に要望を持つ領域でもあります。

使われる技術はJavaScriptとTypeScript、そしてReactなどの枠組みです。ブラウザ上で動く言語が事実上これしかないため、選択肢は限られます。

営業として知っておくべき点は、見た目の変更は比較的容易でも、動きの変更は容易とは限らないことです。色やレイアウトの調整は短時間で済みますが、画面遷移の流れを変える場合は裏側の処理にも影響します。

また、スマートフォン対応は追加作業です。パソコン向けに作ったものが、そのまま最適に表示されるわけではありません。

処理（バックエンド）

画面からは見えない部分で、実際の業務処理を行います。工数の大半はここで発生します。

使われる言語はJava、Python、PHP、C#、Go、Node.jsなど多様です。何を選ぶかは、既存システムとの関係や、開発体制で決まります。

営業として重要なのは、ここに例外処理が集中することです。正常に進む場合の処理は早く作れますが、入力に誤りがある場合、外部システムが応答しない場合、途中で失敗した場合の対応に時間がかかります。

「基本的な機能だけなら安くできますよね」という質問への答えが「そうとは限らない」のは、この構造によるものです。

データ（データベース）

情報を保存しておく部分です。顧客情報、取引記録、在庫。システムの中で最も長生きする部分でもあります。

操作にはSQLという言語を使います。TIOBEの指標では、データ活用の重要性を背景に順位が上昇しています。

営業として知っておくべき点は2つです。

ひとつは、設計の変更が高くつくこと。保存する項目の構造を後から変えると、画面も処理も影響を受けます。建物の基礎を変えるのに近い作業です。

もうひとつは、既存データの状態が案件の難易度を決めること。データが整理されていない、表記が揺れている、重複がある。こうした状態だと、移行や連携に想定外の工数がかかります。提案前にデータの状態を確認できると、見積もりの精度が上がります。

基盤（インフラ）

サーバー、ネットワーク、セキュリティ。普段は意識されませんが、止まると全部が止まる層です。

大きくクラウド（AWS、Azure、Google Cloudなど）とオンプレミス（自社で機器を持つ）に分かれます。

クラウドは初期費用が小さく、使った分だけ支払う形式です。規模の変更が容易な一方、利用量が増えれば月額費用も増えます。

オンプレミスは初期投資が大きく、その後の費用は安定します。規制や社内方針で外部にデータを置けない場合に選ばれます。

営業として確認すべきは、顧客側にどちらの方針があるかです。この前提が違うと、提案の構成が根本から変わります。

どこを変えると費用が大きいか

変更の難易度を、層ごとに整理します。

• 画面の見た目／比較的容易。短時間で対応できることが多い
• 画面の流れ／中程度。裏側の処理にも影響する
• 処理の内容／案件による。例外への対応が増えるほど大きくなる
• データの構造／大きい。全層に影響が波及する
• 基盤の変更／最大。移行作業と検証が必要になる

下に行くほど費用が大きくなります。この順序を理解していれば、顧客の要望を聞いた時点でおおよその規模感が掴めます。

「ちょっとした変更」に見えても、データ構造に触れるなら小さくありません。この判断ができるかどうかが、見積もりの精度に直結します。

商談で確認する項目

構成に関して、商談で聞いておくべきことを整理します。

既存システムは何か。何が動いていて、いつ作られたものか。古いほど連携の難易度が上がります。

データはどこにあるか。どのシステムに、どんな形式で。エクセルで管理されている場合もあります。

クラウドは使えるか。社内規程で外部にデータを置けない場合があります。

誰が保守しているか。社内に担当者がいるか、他社が保守しているか。後者の場合、調整が必要になります。

これらは技術知識なしで聞けて、かつ提案の前提を大きく左右します。

構成図の実際の読み方

提案書や設計書に出てくる図を、どう読むかを具体的に示します。

まず、四角と線を区別する。四角は構成要素（システム、機器、サービス）、線はその間のやり取りです。

次に、線の向きを見る。片方向か双方向か。データがどちらに流れるかで、実装の内容が変わります。

そして、外部との境界を探す。自社で作る範囲と、既存システムや外部サービスの境界がどこにあるか。ここが責任の分かれ目になります。

最後に、点線に注目する。多くの図で、点線は「将来対応」「今回は範囲外」を意味します。顧客がこれを含まれると誤解している場合があります。

商談で出てくる用語

構成の話で頻出する言葉を、営業向けに整理します。

• API／システム同士がやり取りするための窓口。「APIで連携」は、決められた形式でデータを受け渡すこと
• サーバー／処理やデータを担う機器。クラウド上の場合、物理的な機器は事業者が持つ
• オンプレミス／自社の設備内にシステムを置く方式
• SaaS／出来合いのサービスを利用する形式。作らずに使う
• 移行／既存システムから新しいものへ乗り換える作業。データの移し替えを伴う

これらは意味を知っていれば会話に困りません。仕組みまで理解する必要はなく、何を指しているかが分かれば十分です。

分からない言葉が出たら、その場で聞くのが最善です。分かったふりで進めると、認識のずれが積み上がります。