Webシステムを作りたいという相談を受けたとき、最初に困るのがどこから説明するかです。
言葉の定義から入ると眠くなる。かといって作り方から入ると、なぜそう作るのかが分からない。なので私は、いつも「1回の画面表示で何が起きているか」から話しています。順に追うと、部品の役割が勝手に見えてくるからです。
ボタンを押してから画面が変わるまで
たとえば経費申請の画面で、申請ボタンを押したとします。
ブラウザが押されたことを検知して、入力された内容をまとめて送ります。ChromeやSafariのことです。ここは利用者の手元で動いています。
送り先がサーバーです。どこかのデータセンターで動いているコンピューターで、送られてきた内容を受け取って、正しいかどうかを判断します。金額が空欄なら弾く、上限を超えていたら承認者を変える。判断の中身がいわゆる業務ロジックです。
判断が通ったら、データベースに書き込みます。データを保管して、あとから探せる形で持っておく専用の仕組みです。表計算ソフトの表が、同時に何百人から読み書きされても壊れないように作られたもの、と考えると近いです。
書き込みが終わったら、サーバーがブラウザに結果を返して、画面が切り替わります。
この3つが、Webシステムのほぼすべての土台です。手元で見せる係、判断する係、覚えておく係。 役割で覚えると、あとから出てくる用語がどこに属するか分かるようになります。
なぜサーバー側で判断するのか
ここは実務で効いてくるので分けて書きます。
さきほど「金額が空欄なら弾く」という判断をサーバー側に置きました。ブラウザ側でも同じ判断はできます。実際、入力した瞬間に赤く表示するのはブラウザ側の仕事です。
それでもサーバー側にも同じ判断を置きます。理由は、ブラウザ側は利用者が書き換えられるからです。手元で動いているものは手元で変えられる。それどころか、画面を通さずにサーバーへ直接データを送る道具は誰でも無料で手に入るので、画面側のチェックはそもそも通らずにすり抜けられます。
だから「ブラウザ側の判断は親切のため、サーバー側の判断は守るため」と役割が分かれます。私はこれを、業務システムに詳しい人ほど最初に驚くポイントだと感じています。手元のExcelマクロの感覚だと、判断を二重に書く理由が見えないからです。
作り方の選択肢は大きく3つ
ここから作る側の話に入ります。同じWebシステムでも、作り方が何通りかあります。
サービスで組む。 kintoneのように、画面とデータの置き場が最初から用意されていて、設定で組み上げる形です。作る速度は一番速く、コードを書かないので非エンジニアでも進められます。代わりに月額の利用料がかかり、そのサービスができる範囲を超えられません。
土台を組み合わせる。 画面を作るための土台になるソフト(Next.jsなど)と、データベースをネット越しに貸してくれるサービス(Supabaseなど)を組み合わせ、その上に自分の業務ロジックを書く形です。自由度が高く、作ったものが自分の資産として残ります。代わりにコードを書く工程が必要になります。
どちらも画面やデータだけの道具ではなく、判断の置き場所も持っています。 Next.jsはサーバー側で動く処理を書けますし、Supabaseにもログインの管理や処理を動かす仕組みがあります。つまり業務ロジックはどちらにも書けるので、どちらに書くかを最初に決めておく必要があります。決めずに進めると、同じ判断が両方に散らばります。
全部自前で組む。 サーバーの用意から自分でやる形です。制約が一番少ない代わりに、動かし続ける手間が全部こちらに来ます。いま新規で選ぶ理由は、よほど特殊な要件がある場合に限られます。
3つを並べると、こうなります。
サービスで組む 速い / 月額がかかる / 非エンジニアでも進められる
土台を組み合わせる 自由 / 使った分の費用 / コードを書く工程が要る
全部自前で組む 制約なし / 動かし続ける手間が全部自分 / 新規で選ぶ理由は少ない
私が自分用のツールを作るときは、土台を組み合わせる形を選ぶことが多いです。小さいものなら無料の枠に収まることが多く、月額が積み上がらないのが理由です。
選び方は「はみ出すかどうか」で決まる
3つのうちどれを選ぶかは、機能の多さでは決まりません。サービスの枠から、はみ出す要件があるかどうかで決まります。
私は一度これを読み違えました。社内の集計ツールをサービスで組み始めて、8割まで順調に進んだところで、外部のデータを毎晩自動で取り込む部分が作れないと分かった。結局、土台を組み合わせる形で作り直しています。8割まで進んでいたので、判断が遅れた分だけ痛かった。
いま最初に確認するのは、要件の中でいちばん変わった1つです。よくある機能は、どの作り方でも作れます。変わった1つが作れるかどうかで決まる。ここを最初に試すようにしました。
要件の詰め方は別記事にまとめています。
AIに書かせるなら、どこを書かせるか
いま実装をAIに任せる形が現実的になっています。私はClaude Codeを使っています。
やってみて分かったのが、3つの部品で任せやすさが違うことです。
ブラウザ側の画面は任せやすい。見た目の話なので、出てきたものを見れば正しいか判断できます。おかしければその場で分かる。
データベースの設計は、任せると速いのですがあとで効いてきます。 最初にデータの分け方を業務の形と合わない置き方にしてしまうと、機能を足すたびに苦しくなる。私はここは自分で決めて、書くところだけ任せています。
サーバー側の判断は、書かせたあとに必ず読んでいます。とくに権限まわり。誰が何を見られるかは、動いているだけでは間違いに気づけないからです。データを守る部分だけは、自分の目を通すと決めました。
何から手を付けるか
これから作る人に私が勧めているのは、いちばん小さく動くものを1本通すことです。
画面を1つ、判断を1つ、保存を1つ。この3つを端から端まで動かす。全部の画面を設計してから作り始めると、動くものを見るまでが長くなります。1本通してから広げるほうが、間違いに早く気づけます。
工程全体の並びについてはこちらにまとめました。
私が最初に作ったWebシステムは、画面1つとボタン1つだけのものでした。それでも、押したら保存されて次に開いたときに残っている、という当たり前のことが動いたときは嬉しかったのを覚えています。ここが通れば、あとは同じことの繰り返しです。
