アプリは画面から作る。データベースから作らない

先に結論を置きます。

アプリを作る工程を12段に分けたとき、画面は3段目と4段目に来ます。データの保管庫を設計するのは6段目で、実際に作るのは8段目です。

順番が逆に見えると思います。データを決めてから画面を作るほうが自然に感じますよね。何を保存するか決まっていないのに、どうやって画面が描けるのか、と。

描けるんです。むしろ、そちらのほうが早い。

画面を先に作ると、必要なデータがひとりでに決まります。名前の欄があるなら名前を持つ。日付が並ぶなら日付を持つ。

逆にデータから始めると、画面に一度も出てこない項目が保管庫に残ります。作ったけれど誰も見ない列です。

この記事では、その12段の順番を1本ずつ説明します。どの段で何を決めて、何が揃ったら次へ進んでよいのかを書いていきます。

12段を、先に全部見せる

品書きを先に出します。新しくアプリを1本作るとき、通る順番はこうです。

1段目要件定義
2段目保管場所の初期化（作業の記録を残す土台を用意する）
3段目画面の土台づくり
4段目画面をページごとに作る
5段目外部サービスとの接続
6段目裏側の計画
7段目 AIの担当をつくる（AIが判断する部分がある場合だけ）
8段目裏側の実装
9段目画面と裏側をつなぐ
10段目人の操作をそのままなぞる試験
11段目手元での動作確認と、本番運用の診断
12段目本番に出す

この12段は直列です。前の段の出口条件を満たすまで、次の段には進みません。

7段目だけは条件つきで飛ばします。AIが何かを判断する部分があるアプリだけ通り、決まった手順どおりに動くだけのアプリは飛ばします。飛ばしても6段目の計画と8段目の実装は通常どおり通します。

既存のアプリに機能を足すときは、別の入り口から入ります。拡張の要件定義と拡張の実装を通したあと、10段目、11段目、12段目に合流します。試験と診断と本番に出す工程は、新規でも追加でも同じものを通します。

なぜ画面が先なのか

理由はひとつで、「どんな形のデータか」の決めごとが、画面側に置いてあるからです。

4段目で画面を作るとき、データはまだ本物ではありません。仮の値を埋め込んで画面を組みます。一覧に3行並べたいなら、3行ぶんの仮の値を直接書いてしまいます。

この段階で、その画面が何を必要としているかが確定します。一覧に出す列、詳細で開く項目、入力させる欄。それを1か所に書き出したものが、以降すべての工程の出発点になります。

6段目の裏側の計画は、この決めごとを起点に立てます。画面が要求している形に合わせて、窓口の一覧と保管庫の設計を組む。だから設計の段階で、使われない列が生まれにくいんです。

逆の順番だと何が起きるか。

保管庫を先に設計すると、そのときに思いついた項目が全部入ります。あとから画面を作ると、半分は画面に出てきません。出てこないけれど消せない。消してよいのか判断する材料が、もう手元にないからです。

もうひとつあります。画面が先にあると、動くものを早く見られます。仮の値でも、押せて、めくれて、切り替わる。

ここで「思っていたのと違う」が出るなら、まだ裏側を1行も書いていない段階で出たほうがいいですよね。

1段目で決めるのは、作らないもの

1段目の要件定義では、7つの項目を埋めます。

何を作るか、どこで動かすか、何で作るか、画面は何枚か、似たものと何が違うか、いくらかかる見込みか、安全のために何が要るか。この7つです。

埋めるだけなら難しくありません。難しいのは、そのあとに作るものを3つに切り分けるところです。

必ず要るもの。あったほうがよいもの。今回は作らないもの。この3つに分けます。

3つ目がいちばん大事で、いちばん書かれません。作らないものを決めずに進むと、作りたいものが全部「必ず要るもの」になります。全部が必須なら、優先順位は存在しないですよね。

だから1段目の判断では、全部入りになっていないかを見ます。7項目に空欄があるか、作らないものが空欄か。どちらかなら、そこで止めます。次の段には進みません。

安全のところでは2つだけ確かめます。誰がどうやって本人だと分かるようにするか。そして、複数の利用者が同じ仕組みを共有するのかどうか。

後者を後回しにすると高くつきます。共有する形だと、保管庫のすべての表に「これは誰のものか」を持たせる必要があります。あとから足すと、既に入っているデータの持ち主が分かりません。1段目で決めておく項目です。

4段目でできあがるのは、5つの状態がそろった画面

4段目でページを作るとき、1ページにつき5つの状態を用意します。

何も起きていない最初の状態
読み込み中の状態
失敗した状態
中身がゼロ件の状態
中身が入っている状態

作っていると、5つ目だけを作りたくなります。データが並んでいる画面がいちばん見栄えがするからです。

でも本番で人が最初に見るのは、たいてい4つ目なんです。登録した直後は何も無い。1件も無い画面に「ここに出ます」と書いてあるかどうかで、次の操作に進めるかが決まります。

3つ目も同じで、後回しにすると本番で白い画面が出ます。何が起きたのか分からないまま止まってしまう。

5つを4段目で作っておくと、あとの工程でこれが試験の下敷きになります。10段目で人の操作をなぞる試験を書くとき、確かめる対象は「5つの状態が正しく出るか」になります。作った覚えのない状態は、試験にも書けません。

この段階のデータはまだ仮の値です。仮のまま5つを作ります。本物を繋ぐのは9段目で、そのとき仮の値を差し替えるだけで済みます。

人が止まるのは、7か所だけ

12段のあいだ、人が手を止めて判断する場所は7か所に決めてあります。それ以外は止まりません。

止まる場所と、そこで見るものはこうです。

1か所目 … 1段目の終わり。要件7項目と、作らないものの線引き
2か所目 … 4段目の最初のページを作る前。色と配置の案4つから選ぶ
3か所目 … 5段目に入る前。どの外部サービスと繋ぐか
4か所目 … 6段目の終わり。窓口の一覧と保管庫の設計
5か所目 … 11段目。5つの観点での採点
6か所目 … 12段目の直前。本番の設定と、元に戻す手順
7か所目 … 12段目の直後。本番で全部動いたかの確認

数を7に絞っているのには理由があります。

止まる場所が多いと、判断そのものが薄くなります。毎回何かを聞かれる状態だと、人は中身を見ずに通すようになる。逆に止まる場所がゼロだと、間違った方向のまま最後まで進んでしまう。

7か所は、どれも「後戻りが高くつく分かれ道」に置いてあります。要件、見た目、外部サービス、データの形、本番に出してよいかの判定。ここを間違えると、あとの工程が全部やり直しになります。

そして止まる場所以外では、人は判断しません。3段目で画面の土台を組むとき、8段目で裏側を書くとき、10段目で試験を回すとき、いちいち確認を挟まない。挟むべきところは既に通っているからです。

止まらない場所では、機械と別の担当が見ている

人が止まるのは7か所だけと書きました。では残りは誰も見ていないのかというと、そうではありません。

機械が見る部分があります。書き方の検査、決めごとの型が合っているかの検査、組み上がるかの検査。この3つは各段の終わりに自動で走り、1つでも赤なら次に進みません。人の判断は要らない。合否が機械的に決まるからです。

もうひとつ、検品する担当を実装する担当から切り離してあります。

これには理由があります。実装した本人に「できましたか」と聞くと、できたと答えます。悪意ではなくて、自分が通ると思って書いたものを自分で疑うのが、構造的に難しいからです。

だから検品側は、実装側の報告を読まない前提で動きます。自分でコマンドを叩き、自分で画面を開いて確かめる。書き換える権限は持たせていません。直す権限を持つと、直せる範囲で判定を甘くする力が働くからです。

試験も分けてあります。4つの層があります。

部品ごとの試験。外部は全部偽物でよい
保管庫と繋いだ試験。ここは本物の保管庫を使う。軽い代用品では通さない
外部サービスと繋いだ試験。ここは本物の窓口を叩く。決済だけは試験用の鍵でよい
人の操作をそのままなぞる試験

割合の目安は、部品ごとが7割、繋いだ試験が2割、操作をなぞる試験が1割です。

そして、全部を偽物で通して終わりにすることを禁じています。偽物どうしを繋いだ試験は、想定が正しいことしか確かめられません。想定が間違っていると、全部緑のまま本番で落ちます。

だから2つ目と3つ目は、最低1つの機能について本物で通します。本物の保管庫に書き込み、本物の窓口を叩く。

お金が動き出すのは、5段目

12段のうち、支払いが始まるのは5段目です。

5段目で外部のサービスに繋ぎます。決済、メール配信、エラーの見張り、画像の置き場。ここで本番の契約を結ぶと、そこから課金が始まります。

だから、その手前に止まる場所を置いてあります。3か所目の判断がそれで、繋ぐ先の一覧と、それぞれ何に使うのかを並べて確認します。

ここで見るのは「必要か」の一点です。あとから足せるものは、いま繋がない。1段目で書いた想定コストと突き合わせて、増えているなら理由を確かめます。

4段目までは、外部に何も繋いでいません。画面は仮の値で動いています。つまり4段目までは、いくら作っても支払いは発生しません。

この構造には意味があります。作ってみないと分からないことを、支払いが始まる前に済ませられるんです。見た目が違う、画面の流れが違う、そもそも要らない画面がある。こうした発見は、繋ぐ前に出たほうが安く済みます。

なお、この記事では金額の実測は出しません。繋ぐ先も規模も案件ごとに違うので、いくらかかるかは書けないからです。書けるのは、どの段で支払いが始まるかという順番のほうです。

この記事で読めること

無料の部分はここまでです。12段の並びと、なぜその並びなのかと、人が止まる7か所までを出しました。

有料の部分に入るのは次の4つです。

12段を1段ずつ

各段について、何を受け取り、何をして、何が揃ったら次へ進んでよいのかを書きます。段ごとに出口条件を明記します。

7つの判断ポイントの合格基準

止まる場所ごとに、何が揃っていれば通してよく、何があれば通してはいけないのかを、そのまま出します。採点で90点という基準や、直したい箇所を何回まで直すかという上限も含みます。

順番を崩すと何が起きるか

飛ばしたくなる段と、飛ばしたときに後でどう返ってくるかを書きます。とくに、試験と診断を後回しにしたときの返り方を書きます。

機能を足すときの順番

既存のアプリに追加するときは12段を全部は通りません。どこから入って、どこで合流するのかを書きます。

向く人と向かない人

向かない人から書きます。

すでに自分の作り方が固まっていて、それで完成まで行けている方には要りません。順番の話は、途中で止まる人のためのものです。

作らずに読みたい方にも向きません。この記事は工程の説明であって、技術の解説ではないんです。プログラムの書き方は出てきません。

すぐに動くものが欲しい方にも向きません。12段のうち、動くものが見えるのは4段目です。それまでに3段あります。

大人数で分担して作る方にも、そのままでは向きません。この12段は、少人数で最初から最後まで通すことを前提に並んでいます。

向くのはこういう場合です。

作り始めると毎回どこかで止まる。何から手を付けるかで迷って、迷っているうちに別のことを始めてしまう。

最後まで行くのだけれど、後半で必ず大きな作り直しが出る。データの持ち方が違った、画面の前提が違った、というやり直しです。

AIに作らせているけれど、どこまで任せてどこで自分が見るのかが決まっていない。

よくある質問

12段は多すぎませんか。

段の数は作業量ではありません。1段が数分で終わることもあります。段を分けているのは、出口条件をそこで確かめるためで、手間を増やすためではないんです。

画面から作ると、あとで作り直しになりませんか。

なります。ただし作り直すのは画面の見た目であって、データの構造ではありません。見た目の作り直しは安く、データの構造の作り直しは高い。安いほうを先に済ませる並びにしてあります。

小さいアプリでも12段通しますか。

通す前提で書いています。ただし7段目は条件つきで飛ばします。段が軽くなるだけで、順番そのものは変わりません。

AIに全部やらせられますか。

7か所は人が判断します。それ以外は任せられます。この記事の後半は、その7か所で何を見るかに紙幅を使っています。

7段目を飛ばす判断は、どうやってしますか。

そのアプリの中で、AIが何かを判断するかどうかで切ります。入力に応じて答えを組み立てる部分があるなら通す。決まった手順どおりに計算して返すだけなら飛ばす。迷ったら、その部分の答えが毎回同じかを見てください。毎回同じなら飛ばして構いません。

途中で仕様が変わったら、前の段に戻りますか。

戻ります。ただし戻る先は、変わった決めごとを持っている段です。データの形が変わったなら6段目まで、画面の流れが変わったなら4段目まで。全部やり直すのではなく、その決めごとを持つ段から下だけを通し直します。段を分けてあるのは、戻る範囲を狭くするためでもあるんです。

途中で止めた場合、どこから再開しますか。

各段の出口条件が記録に残るので、最後に条件を満たした段の次から入ります。再開の手順も後半に書いています。

免責

この記事に書いてある工程と基準は、実際に運用している開発の決まりから取り出したものです。2026年8月22日時点の内容です。

工程の番号は2026年7月28日に組み替えています。それ以前の記録とは番号が1つずれる箇所があります。この記事は組み替え後の番号で統一しています。

書いてある方法を実行した結果について、成果を保証するものではありません。開発の判断はご自身の責任で行ってください。

外部サービスの仕様と料金は変わります。この記事の内容は執筆時点のものです。

各段の中で使う指示文そのものは、この記事には掲載していません。掲載しているのは工程の順番と、判断の基準です。

ここから先は有料です。