「基本設計経験あり」と書いていいのは誰か——在庫3点に4点注文されたら、で分かる設計の本質
スキルシートに「基本設計」と書く人は珍しくない。
だが中身を聞くと、決まった内容を書き写す作業だったことが多い。
基本設計の本質は、使う人の体験（UX）を画面と動きのルールに落とすことだ。
架空のECサイトの「在庫3点に4点注文」という1つの場面を、工程ごとに追いかけて整理する。
この記事は 基本設計経験とは何か？AI時代に求められる設計力とスキルシートの書き方 のダイジェスト版です。
二人の注文が重なる場合の考え方や、AIで設計を練習する際の注意点は、上記の完全版をどうぞ。
同じ「在庫不足」でも、工程ごとに考えることが違う
題材は、Tシャツを販売する架空のECサイトだ。
商品をカートに入れ、数量を確認して注文する。
ここでは数量と在庫だけに絞る。
| 工程 | ひと言でいうと | 在庫不足でいうと |
|---|---|---|
| 要件定義 | 何をできるようにするか決める | 店に来なくても注文できるようにする |
| 基本設計 | 使い方と動きのルールを決める | 在庫不足なら注文を止め、数量の修正を案内する |
| 詳細設計 | 裏側の処理を具体化する | どこで在庫を調べ、どの処理を止めるか決める |
| 実装 | 決めた処理をコードにする | 数量チェックと注文保存の処理を書く |
| テスト | 決めたとおりに動くか確かめる | 在庫3点に4点注文して、受け付けないか確認する |
同じ注文機能でも、考えていることの細かさが違う。
基本設計は「どう動けばよいか」、詳細設計は「どう作るか」だ。
ただし工程名で仕事をきっちり分ける必要はない。
実際の基本設計には、システムの方式なども含まれる。
自分の現場で、どの設計書に何を書き、誰が確認するのかが分かれば十分だ。
在庫3点に4点注文されたら、どうするか
ここが基本設計の本質に触れる場面になる。
選択肢は少なくとも3つある。
- 3点だけ受け付ける
- 不足分を予約扱いにする
- 注文を止め、数量を選び直してもらう
どの案を選んでも、システムとしては動く。
しかし買う人の体験はまったく違う。
黙って3点に減らせば、届いてから「頼んだ数と違う」と気づく人が出る。
問い合わせや返品が増え、店の負担にもなる。
「動けば良い」という視点では、この差が見えない。
多くのエンジニアは、機能が動けば設計は済んだと考える。
一方、POやビジネスサイドが見ているのは、使う人がどう感じるかだ。
基本設計は、このUXを画面と動きのルールに落とす仕事である。
だから、実装担当者が作りやすさだけで決めてはいけない。
この例では店側へ確認し、こう決まったとする。
- 在庫の範囲だけ注文できる
- 不足時に数量を勝手に減らさず、買う人へ修正を求める
- カートに入れただけでは在庫を取り置かない
決まったルールを、数量欄と案内文にする
方針が決まったら、画面の動きに落とす。
| 状況 | 画面の動き |
|---|---|
| 在庫が足りない | 注文を確定せず「在庫が不足しています。数量を変更してください」と案内 |
| 在庫が0点 | 売り切れを案内 |
| 0点・小数の数量 | 受け付けない（1点以上の整数のみ） |
設計書でいう「入力チェック」や「エラー時の動き」だ。
平たくいえば「何を入力してよいか」「買えないときに何を伝えるか」になる。
案内文ひとつでも、買う人が次に何をすればよいか分かるかで体験が変わる。
不明点を見つけたら、リーダー経由で確認すればよい。
自分で決める権限がなくても、決める必要があることには気づける。
その気づきを設計書へつなげることも、設計に関わる仕事だ。
詳細設計とテストは、ルールを守る仕組みになる
基本設計で決めた動きを、裏側の処理へ落とすのが詳細設計だ。
ここで押さえたいのが、画面の制限だけでは足りないという点だ。
画面で1〜3点しか選べなくしても、画面を通らずにデータが送られる場合がある。
OWASPの入力検証ガイドでも、画面側の確認はUXのため、サーバー側の確認は安全のためと役割を分けている。
さらに、カートに入れてから注文するまでに、別の人が買うこともある。
取り置きをしない店なので、注文を受け付ける時点の在庫を確認する。
① 数量が1以上の整数でなければ、注文を受け付けず修正を求める
② 在庫が足りなければ、注文を確定せず案内を返す
③ 条件を満たす場合は、在庫の確保と注文の記録を行う
④ 正常に記録できたことを確かめ、注文完了を伝える
この4行で詳細設計が完成するわけではない。
在庫だけ減って注文が残らない、といった失敗への備えも要る。
最初は先輩のレビューを受けながら、確認する範囲を広げていけばよい。
設計の内容は、そのままテストの観点につながる。
在庫3点の状態から、それぞれ試す。
| 試すこと | 確認したい結果 |
|---|---|
| 2点を注文 | 注文でき、在庫は1点になる |
| 3点を注文 | 注文でき、在庫は0点になる |
| 4点を注文 | 注文できず修正が案内される。在庫は3点のまま |
| 0点・小数・空欄を送る | 注文できず入力の修正が案内される |
在庫不足時の案内が未定なら、テスト担当者がその場で決めるのではない。
基本設計の担当者へ戻り、どう動くべきかを確認する。
▶ 二人の注文が重なる場合の考え方や、AIで設計を練習する際の注意点はこちら → 基本設計経験とは何か？
AIが作ったカートは「動く」。だが体験までは決めない
AIに「商品を注文できる機能を作って」と依頼したとする。
在庫不足なら、数量を黙って在庫数まで減らす作りになっていた。
動作としては正しい。
テストを書かせても、そのとおりに通ってしまう。
しかし、店が決めた「買う人に修正を求める」体験とは違う。
AIは指示された範囲で合理的に作るが、誰の体験を優先するかまでは決めない。
ここでUXの視点が判断の物差しになる。
AIを使ううえで難しいのは、出てきたものの良し悪しを判断することだ。
物差しを持たないままAIを使うと、動くものを量産するだけで終わる。
基本設計を理解していれば、「使う人にとって何が困るか」を確認できる。
詳細設計を理解していれば、そのルールが裏側の処理にもあるかを追える。
AIに実装を任せる現場ほど、この判断が人に残る。
「文言を直した」と「仕様の抜けを確認した」は別の経験だ
ここで最初の問いに戻る。
数量欄の説明を、指示された文言へ変更した。
これは、決まった内容を正確に反映した経験だ。
在庫を超える注文の扱いが未定だと気づき、確認した。
これは、仕様の抜けを見つけて設計へ反映した経験でもある。
買う人が戸惑う場面を先回りして見つけた、UXの経験ともいえる。
どちらも書いてよい。ただし「基本設計書を修正」の一行では、この違いが伝わらない。
| 記述 | |
|---|---|
| Before | ECサイトの基本設計・詳細設計・製造・テストを担当。 |
| After | ECサイトの注文数量チェックを担当。 在庫不足時に数量を自動で減らさない方針を、リーダー経由で確認。 購入者が数量を直せる条件と案内を、基本設計書へ反映。 詳細設計では、注文受付時に数量と在庫を確認する処理案を作成。 先輩のレビュー後に実装し、在庫以内・在庫超過の注文をテスト。 |
対象・確認内容・担当範囲を分けると、経験の中身が見える。
Afterには、使う人の体験をどう守ったかも入っている。
レビューを受けたことを隠す必要はない。
基本設計に関わったことと、一人で基本設計を進められることは別だ。
「顧客との調整を主導した」など、実際には担っていない役割は足さない。
次の改修で、確認する範囲を一つだけ広げる
「自分は修正しかしていない」と感じても、今の経験を消す必要はない。
担当するボタンや入力欄について、次の三つを確認してみる。
- 使う人は、何ができれば困らなくなるのか
- 入力を間違えたり、在庫が不足したりしたら、どう動くのか
- そのルールを、コードのどこで確かめているのか
最初から答えを持っている必要はない。
数量欄なら、こう聞ける。
「在庫不足のときは数量を自動で減らさず、入力し直してもらう方針でしょうか？」
答えを教わったら、なぜその方針なのかも聞く。
設計書のどこへ書き、実装のどこへ反映するかまで追う。
質問をしただけで終わらせず、次の作業につなげることが大事だ。
AIに確認漏れを挙げてもらうのもいい。
ただし客先のコードや設計書、個人情報を無断で入力してはならない。
練習には架空のECサイトを使う。
こうして確認した範囲は、担当範囲の変化として残しておきたい。
Skillsheet-Port なら、案件ごとの担当工程をフォームに入れておけば、差分を足して再出力できる。
「何を確認し、どこまで担当したか」を、後から説明できる形で積める。
まとめ
- 基本設計は「どう動けばよいか」、詳細設計は「どう作るか」。考える細かさが違う
- 基本設計の本質は、使う人の体験（UX）を画面と動きのルールに落とすこと
- 在庫3点に4点注文、の扱いはどの案でも動く。差が出るのは買う人の体験
- 詳細設計ではサーバー側でも確認する。画面の制限だけでは足りない
- テストで未定の動きが見つかったら、その場で決めず基本設計へ戻す
- AIは動くものを作るが、誰の体験を優先するかは決めない。その判断が人に残る
- スキルシートは対象・確認内容・担当範囲を分けて書く。担っていない役割は足さない
いきなり難しい設計を背負う必要はない。
目の前の数量欄やボタンを一つ選んで、「使う人にとって、なぜこの動きなのか」を確認してみてほしい。
その一つが、次に任せてもらえる範囲を広げる。
▶ 完全版ガイドはこちら → 基本設計経験とは何か？AI時代に求められる設計力とスキルシートの書き方
▶ 無料でスキルシートを作ってみる → https://skillsheet-port.com/