外部設計ってどうやるの?授業では習ったけどイメージがつかめない人へ
はじめに:
-
「外部設計って何?」と戸惑っているあなたへ。宿題や授業でサクッと使える、やさしめの設計記事です!
-
難しい用語や理論の前に、まずは「こうやって考えるんだな〜」という感覚をつかむのが今回のゴールです✨
(本来は要件定義が先ですが、ここでは飛ばしてこれをする!という方向で進めます。)
外部設計を考えるためのモデル :
「バスケのチーム記録をつけるミニアプリを作る」
チーム名と学年とシュート数の入力を2チーム分受け取り、それぞれの得点を計算し勝敗を表示する。
得点計算 :
- 2Pシュート数(2点)
- 3Pシュート数(3点)
- フリースロー成功数(1点)
学年: - 1, 2, 3, とmix がある
- 得点計算に違いはない
チーム名 : - アルファベット、数字が入る
- ひらがな、漢字もNGではないが使用しているチームはない
その他 : - 1試合(2チーム分)の表示ごとに区切りを入れる
入力例 : - Flames / 2年 /2P×15, 3P×4, フリースロー成功×3
- Dream Team / 1年 /2P×11, 3P×3, フリースロー成功×1
- Wings / mix /2P×20, 3P×4, フリースロー成功×2
結果表示画面の例
Team: Wings mix score: 54 win
Team: Dream Team 1年 score: 32 loss
-----------------------------------
次の入力と分けたい
外部設計として組み立てる
外部設計のポイント
-
ユーザーの視点
- 誰が使うアプリケーションなのか?
- ユーザーはどんな操作をしたいのか?
- どんな情報を求めているのか?
- どのような出力結果を期待しているのか?
-
システムの全体像
- システムはどのような機能を提供するのか?
- 各機能はどのように連携するのか?
- データはどのように管理されるのか?
-
設計の明確化
- 機能名、入力条件、出力条件を明確に定義する。
- 入力データの形式
- 出力結果のイメージ
- データの制約条件
- 可能な限り、具体的な例を挙げる。
-
画面設計(必要な場合)
- 画面のレイアウト
- 画面遷移
-
エラー処理の基本方針
- どんな場合にエラーとするか
- エラー時の対応
- 例: 入力データに不正な値が含まれている場合は、エラーメッセージを表示し、再入力を促す旨を記載。
外部設計に書くもの
- プロジェクト名(ドキュメント名)
- 作成者
- 作成日
- 承認者
- 設計書バージョン
- バージョン管理
- 変更履歴
- 機能一覧
- 機能名
- 機能概要
- 入力値条件
- 出力値条件
💡実務的な例:
※今回は簡易アプリなので、実務で使う資料の一例として“軽く目を通す”くらいの気持ちでOKです!
| ドキュメント名 | 内容の概要 |
|---|---|
| 外部設計書_機能一覧・仕様編 | システム全体の機能一覧とその仕様(入力条件・出力条件・制約など) |
| 外部設計書_画面一覧編 | 画面の種類とそれぞれの役割・画面IDなどの概要 |
| 外部設計書_画面設計編 | 各画面のレイアウト、入力項目、遷移の流れなど |
| 外部設計書_帳票設計編 | 印刷や出力する帳票(レポート系)のフォーマットや出力項目など |
| 外部設計書_インタフェース設計編 | 他システムとどうやってデータをやりとりするか(ファイル形式やAPI連携など) |
| 外部設計書_業務フロー(参考) | 業務の流れとそれに関係するシステム操作(※実務では要件定義書の中で作成されることが多い) |
📝なお、ユーザーからは見えない部分ですが、
実際の外部設計では論理データ設計(ER図テーブル設計)も行われます。現場では「ER図をあえて描かず、頭の中でイメージしてテーブル設計を進める」スタイルも多く、
実務では省略されがちな分野とも言えます。だからこそ、設計の勉強をする上ではしっかり押さえておきたいポイント!
「なんとなくでDBを作らない」ためにも、ER図の考え方は一度きちんと学んでイメージ出来るようになりたいところです。
- 今回は構成がシンプルなので、この部分(ER図テーブル設計)は割愛しています。
実際に設計してみる
最初の案:Ver.1.0
プロジェクト名:バスケチーム試合登録アプリ
【外部設計書】
| Ver. | 日付 | 変更内容 | 作成者 |
|---|---|---|---|
| 1.0 | 2025/04/26 | 初版作成 | neko_yashiki |
【機能一覧】
💡チーム登録→得点計算→得点比較→結果表示の流れを意識する
| NO. | 機能名 | 機能概要 |
|---|---|---|
| 1 | チーム登録 | チーム名、学年、得点シュート数を登録 |
| 2 | 得点計算 | 2P、3P、フリースローから得点合計を計算 |
| 3 | 得点比較 | 2つのチームの得点を比較して勝敗・引分を決定 |
| 4 | 結果表示 | チーム名、得点合計、勝敗・引分 を表示する |
-
入力条件
- チーム名は文字列、空白も考慮
- チーム名、学年、 2P、3P、フリースローの順で受け取る
- 得点は int 型、得点無しは 0 を入力
- 入力が引数と合わなければエラー
- 得点の型が合わなければエラー
- 入力が不正な場合は、再入力を促す
-
出力条件
- チーム名、得点合計、勝敗 を表示する
- 1試合分出力後区切線を表示
- チーム名、得点合計、勝敗 を表示する
-
計算ロジック
【得点計算】
得点 = (2Pシュート数 × 2) + (3Pシュート数 × 3) + (フリースロー成功数 × 1)
【勝敗判定】
得点を比較し、得点が高い方を勝者とする
※ 表の位置関係などMarkdownで見やすいように作成しています。実際の仕様書は作成するツールに合わせて改変が必要になると思います。
🤔見直し&バージョン管理
今回は自分ひとりで記事を書いているのでセルフレビューですが、本来チーム開発ならここで他メンバーにレビューを依頼します。
GitHubでPull Requestを出して、指摘をもらいながら改善していくイメージです。
内容の見直し ①
【修正ポイント】 レビュー
- 「1試合(2チーム分)の表示ごとに区切りを入れる」
- つまり何試合かまとめて入力したい?
- 入力は一度に2チーム分
- 試合単位で入力
- 入力の継続とやめるときの操作は・・
- 標準入力の対応orファイル入力
- チーム名制約
- 長さ制限があれば出力を整えられる
- 得点判定
- 同点の場合も必要か?
- 勝敗が決まるまでやるものなのか?
【修正内容確定】 Ver.1.1
- 同点を記録
- チーム名入力はアルファベット20文字まで
- チーム登録と試合登録へ変更
- ファイルからの入力、ファイルへの出力はなし(今後あるかも)
※将来的にファイル入力に対応する場合は、事前にチームを登録しておくような仕組みに変更する可能性がある
※現状はコンソール出力からExcelなどに貼り付けで使用の予定
※将来的には、学校の活動方針の転換(例:2年後の変更)や地域連携の方針などに合わせて、設計を見直すことも検討している - 文字入力のエラー処理はしない
- 入力をやめるときの操作は「+end → Enter」
- ①endなどの文字列はチーム名に使用する率は低いと思われるが、制限を設けたくない
- ②チーム名に使える記号は「-」「 _ 」「・」「 ! 」でそれ以外はNGにしている
- ①、②の理由から誤操作につながりにくい「+」を使用
- 誤操作を防ぐために「+end 」の4文字で終了を確定
内容の見直し ②
【修正ポイント】 レビュー
- 使い方についての説明を最初に1度だけ表示したらどうか
- 終了操作の入力タイミングは?
- チーム名入力の時?入力タイミングの決まりは?
- エラー処理を分かりやすくする
- 学年入力
- 数値と文字列の受け取りのままにするか
- 全部数値で受け取れる仕様にした方が使いやすいのでは?
【修正内容確定】 Ver.1.2
- 機能一覧No.0に使い方ガイド表示機能を追記
- 全てのユーザー入力時に終了コマンドを受け取る
- 学年の入力を1 = 1年、 2 = 2年、 3 = 3年、 4 = mixと表示する
変更を記録する / バージョン管理
「誰が、いつ、どんな意図で設計を変えたか」をあとから辿れるようにすること
自分だけで試行錯誤しているとき
- バージョン管理しなくてもOK!
- メモ帳でぐちゃぐちゃ書いて、直して、試して、を繰り返してる段階
他の人と共有・レビュー・チーム開発
- バージョン管理する!
- 「この機能って前まであったっけ?」が起きやすくなる
- 数字だけ変わると「なぜ?」「いつ?」「誰が?」が分からない
- お客様が「変更していいよ」と言った証拠も残る
| 版数 | 日付 | 変更内容 | 変更者 |
|---|---|---|---|
| 1.0 | 2025/04/01 | 初版作成 | neko_yashik |
| 1.1 | 2025/04/10 | 得点ロジックを修正(同点対応) | neko_yashik |
| 1.2 | 2025/04/20 | チーム名の長さ制限を追加 | neko_yashik |
バージョン番号「どう上げるか」ルール
-
小さい変更(誤字修正、ちょっとした説明追加)なら
→ 1.0 → 1.1 → 1.2 → ...
→ 1.9 → まできたら→ 1.91 → ... (小さい変更でまとめる) -
大きい変更(仕様そのものが変わる、新機能追加)なら
→ 1.4の次は2.0にする!
💡2.0のとき、つぎの大きい修正は3.0!
| バージョン | 何があった? |
|---|---|
| 1.0 | 最初の完成版 |
| 1.1 | 条件の追記(小さい追加) |
| 1.2 | 入出力値の見直し(小さい変更) |
| 2.0 | そもそもの機能追加!設計の大きな変更 |
修正後の案:Ver1.2
プロジェクト:バスケチーム試合登録アプリ
| Ver. | 日付 | 変更内容 | 作成者 |
|---|---|---|---|
| 1.0 | 2025/04/25 | 初版作成 | neko_yashiki |
| 1.1 | 2025/04/26 | 機能の明確化、出力条件の整理、将来の拡張機能の可能性を追記 | neko_yashik |
| 1.2 | 2025/04/26 | 使い方ガイドの表示を追記、出力画面のイメージを記載、学年の入力値を統一、エラーを項目として追加 | neko_yashik |
【機能一覧】
| NO. | 機能名 | 機能概要 |
|---|---|---|
| 0 | 説明表示 | アプリ起動時に1回だけ使い方を説明する |
| 1 | データ入力 | チーム情報(チーム名、学年、シュート数)を標準入力から受け取る(将来ファイル入力にも対応予定) |
| 2 | 試合登録 | 2チームの試合情報を管理 |
| 3 | 得点計算 | 2P、3P、フリースローから得点合計を計算 |
| 4 | 得点比較 | 2つのチームの得点を比較して勝敗を決定 |
| 5 | 結果表示 | チーム名、得点合計、勝敗、引分 を表示する |
| 6 | ファイル対応 | ファイルから読み込む/ファイルに保存する(今は未実装、枠だけ用意) |
-
入力条件
- 標準入力で受け取る。
- 入力項目と順番:
- チーム名(最大20文字、空白含む文字列)
- 学年(1=1年, 2=2年, 3=3年, 4=mix)
- 2Pシュート数(0以上の整数)
- 3Pシュート数(0以上の整数)
- フリースロー成功数(0以上の整数)
-
特別操作:
- 「+end」を入力すると試合登録を終了する。
- どの入力フェーズでも「+end」を受け付ける。
-
出力条件
- アプリケーション開始時に1度だけ使い方の詳細を表示する。
- チーム名、得点合計、勝敗をそれぞれ表示し、1試合分が終わるごとに区切り線(---)を挿入sする。
- 結果出力は「+end」のあと、それまで登録された全試合をまとめて表示する。
-
計算ロジック
【得点計算】
得点 = (2Pシュート数 × 2) + (3Pシュート数 × 3) + (フリースロー成功数 × 1)
【勝敗判定】
得点の比較によって win/loss/draw を決定する。 -
エラー処理
- 入力が空欄だった場合は再入力を促す(全項目共通)。
- 得点入力が0か正の整数以外なら再入力を促す。
- 学年入力が「1〜4」以外なら再入力を促す。
- 入力途中で「+end」が入力された場合、その試合の入力は無効にする。
-
出力画面の例
【最初の説明表示の例】
============ バスケチーム試合登録アプリ =========================================
入力方法:
1.チーム名を入力
2.学年を1,2,3,4,のいずれかの数字で入力:
1 = 1年、 2 = 2年、 3 = 3年、 4 = mix
3.シュート数の入力:
2Pシュート数、3Pシュート数、フリースロー成功数の順に「数字のみ」で入力してください。
シュート数が0の場合は「0」を入力してください。
4.ここで1チーム分の入力が終了します。
続けて対戦相手チームの入力が始まります。
5.入力終了は「+end」を入力してください。
※入力の途中で「+end」とした場合、その試合データは保存されずキャンセルされます。
6.終了操作が入力されるまで1→2→3が繰り返されます。
===============================================================================
【入力操作の表示の例】
試合登録
チーム名:
学年(1=1年, 2=2年, 3=3年, 4=mix):
2Pシュート数:
3Pシュート数:
フリースロー成功数:
対戦相手の登録
チーム名:
学年(1=1年, 2=2年, 3=3年, 4=mix):
2Pシュート数:
3Pシュート数:
フリースロー成功数:
【結果の表示の例】
basketball score
----------------------------------------------
Team: Wings mix score: 54 win
Team: Dream Team 1年 score: 32 loss
----------------------------------------------
Team: Flames 2年 score: 86 win
Team: Dream Team 1年 score: 57 loss
----------------------------------------------
- 備考
- 本設計は現時点の仕様に基づくものであり、学校方針や運用ルール変更に応じて見直す可能性がある。
処理と機能の考え方次第:超簡単設計
💡ここでちょっと視点を変えてみよう!
バスケの試合登録アプリのように、
複数のデータを扱ったり将来的な拡張を考える場合は、
「処理をどう分けて機能として設計するか?」をしっかり考える必要があります。
設計を考える練習としてやってみましたが
🧸もっと簡単なプログラムでは?
「2つの数を入力して、足し算して結果を表示する」
そんなときは、設計だって超シンプルでOK!
✅ 機能一覧(練習プログラムVer)
| NO. | 機能名 | 機能概要 |
|---|---|---|
| 1 | 入力と計算 | 2つの整数を入力し、足し算して結果を出す |
| 2 | 結果の表示 | 計算した合計を表示する |
無理に「入力」「計算」「出力」に分けなくてもOK!
なぜなら、ユーザーにとっては “ひとまとまりの動き” だからです。
🤔💭「コードが少ないから?」
→ もちろん、練習プログラムだからそれもある!
実務のような画面遷移やデータ保存などがないなら、設計もシンプルでOK!
たとえば、Ver1.2の案を将来の拡張無しで考えた例として
将来の拡張を行わない実装例 (機能数: 4)
※機能No. を1からに直しました。
| NO. | 機能名 | 機能概要 |
|---|---|---|
| 1 | 説明表示 | アプリ起動時に1回だけ使い方を説明する |
| 2 | データ入力 | チーム名、学年、シュート数の入力を受け付け、得点を計算するために必要な情報を集める |
| 3 | 試合結果処理 | 2チーム分の得点を計算し、勝敗を決定 |
| 4 | 結果表示 | チーム名、得点合計、勝敗、引分を表示する |
このVer1.3では、「試合登録」「得点計算」「得点比較」の処理を
“試合結果処理”という1つのまとまりに集約しています。
ファイル対応などの未実装の枠もいったん除外し、
「今できること」に絞って、設計をスリムに整理したバージョンです。
設計は「何を作りたいか」「どこまで作るか」で変わるもの
設計について調べると「正解はない」ばっかり出てきて……
「そんな・・😇」ってなるけど、
ちゃんと考えたならそれが"あなたの設計"です!🎉
※ 先生やしかるべき人に確認をするならOK!
✨ここまで読んでいただき、ありがとうございます。
自分でもまだまだ勉強中のため、未熟な記事ではありますが、少しでも参考になる部分があれば嬉しいです。簡単な設計練習の段階で、いろいろと調べたり、IPAの合意形成ガイドを見たりしながら学んでいますが😇👻。
設計について調べると、外部設計書だけでも何十ページになるような世界で、自分のレベルにあった解説を見つけるのが難しい、やっぱり経験を積まないといけない部分が大きいと実感しています。現場ごとにアプローチが違ったりするので、調べるだけでは解決できないことも多いと感じました。これからも引き続き学んでいきたいと思います!
Discussion