「機能」と「処理」の違いを明確に！外部設計で迷わないための見分け方と分類ルール

はじめに：

• 設計を始めると必ず出会う「機能」「処理」の分け方…
  実は最初はすごく迷いやすいポイントです。
• 本記事では「どこからが機能？あれは処理？」と悩まないための見分け方を、具体的な例とともにまとめました。

📘 外部設計のポイント

～「機能」と「処理」の違いを見極める～

✅ 基本の考え方

• 機能（Feature）：
  　利用者にとっての「やりたいこと」「まとまった動き」。
  　UIに現れる単位。メニューやボタンになることが多い。

• 処理（Process）：
  　その機能を支える、プログラム内部の具体的な作業。
  　ユーザーには見えないことも多い。

---

✍ 線引き例

内容	機能 or 処理	理由
「BMIを計算できる」	機能	アプリの目的そのもの（ユーザーの目的）
「身長を受け取る」	処理	計算に必要な一要素で、単体では意味を持たない
「計算結果を表示する」	処理（または小さな機能）	ユーザーに直接見せるが、補助的な役割
「アカウントを作成する」	機能	明確なユーザー操作で、一連の流れになっている
「パスワードの文字数チェック」	処理	入力バリデーションという裏方
「エラーメッセージを出す」	処理	処理失敗時のサポート的表示
「使い方を表示する」	機能 or 処理	アプリの性格次第。目立つボタンなら機能扱いもアリ
「データベースに保存する」	処理	完全な内部処理（ユーザー操作ではない）
「ランキングを見る」	機能	明確な目的を持ってユーザーが選ぶ動作

▷ バリデーションの解説は最後にあるよ

---

🧮【電卓アプリ】の例で整理すると…

区分	内容
機能	「2つの数字を受け取って計算する」
処理	数字1を入力する／数字2を入力する／計算する／結果を表示する

---

💡 判断ポイント

• 🎯 ゴールが1つで明確 → 「1つの機能」としてまとめてOK
• 🔄 途中で選択や分岐がある／目的が変わる → 「機能」を分けて整理する

---

🔍じつは“見えづらい複数のゴール”

アプリの目的（ゴール）が１つに見えても、裏では複数の動作が組み合わさってゴールにたどり着いている。
そこで「共通機能」という考え方が役に立ちます。

例：日記アプリ

「日記を書くことができる」これが重要だけど・・

ユーザーが意図してやること	実は…
日記を書く	◎ メインのゴール
書いた日記を保存する	✔ 共通機能（保存）
ログインする	✔ 共通機能（認証）
過去の日記を読み返す	◎ 別のゴールとも取れる（記録の活用）

➡ 実際には 複数のゴール に近い動きがある。

🔄 共通機能の分類

共通機能の例：

機能名	概要
ログイン	利用者の識別、セキュリティ確保
保存	入力情報の永続化（DB・ファイルなど）
認証・認可	アクセス制御（管理者／一般ユーザーなど）
ヘルプ表示	操作方法のサポート

共通機能は、アプリの目的に関係なく「全体を支える機能」

• アプリの“柱”ではないけど、全体に関わる「横断的な機能」。「機能一覧」に入れるか、「共通機能」として別扱いにするかは、目的と設計フェーズによって異なる。

💡「入力」「出力」は“共通処理”

区分	理由
🔄 入力・出力	どの機能にも共通して必要な処理だが、 ユーザーが「入力したい」「出力したい」と直接目的にすることは少ないから。
🔑 共通機能（例：ログイン・保存・設定）	それ単体で機能として認識されるもの。 ユーザーが「ログインする」「データを保存する」という明確な操作対象になる。

✅ 分けるときの考え方

種別	例	説明
処理	入力・出力・バリデーションなど	あらゆる機能の裏で動くけど、ユーザーにとっては目立たない
機能	ログイン・保存・印刷・設定	単体で意味を持ち、ユーザーが意識的に操作する

---

「バリデーション」って言葉に慣れない・・

みんな普通に使ってて、ニュアンスも分かるけど…使いこなせるほど分かっていない…

バリデーション（validation）：入力データの検証や確認に関する用語
簡単に言うと、「このデータ、このまま使っていいやつ？」と確認するステップ！

✅ よくあるバリデーションの例

種類	内容	例
必須チェック	入力が空じゃないか	名前、メールアドレス、得点など
形式チェック	特定のルールに沿っているか	メール形式（@があるか）、数字だけか
範囲チェック	値が一定の範囲内か	0以上100以下、文字数が20文字以内など
型チェック	データの種類が正しいか	数値・文字列・日付など
制限文字チェック	禁止されてる文字がないか	絵文字、記号、SQL文字など
一致チェック	確認用入力との一致	パスワードと確認パスワードが同じか
選択肢チェック	選べる値に含まれているか	学年は「1年」「2年」「3年」「mix」だけ、など
相関チェック	他の項目との整合性	開始日より終了日の方が後である、など

補足：バリデーション ≠ エラー処理

• バリデーションは「正しいかどうかのチェック」
• エラー処理は「ダメだったときにどう対応するか」

たとえば：
「空欄はNGです」と表示する → バリデーションの結果に基づくエラー処理

バリデーションの使い方

「バリデーションってざっくり言うとき」と「細かく書き出すとき」には、目的の違い がある。

✅ ざっくり「バリデーション」と言うとき

→ 全体の流れや構造をざっと設計したいとき

たとえば外部設計や画面仕様を決める段階では…

• ✓ 入力欄あり（バリデーションあり）
• ✓ 学年の選択（バリデーションで範囲を制限）

💡 「何にバリデーションが必要か」だけを洗い出すことが目的

✅ 細かく書き出すとき

→ 実装やテストに入る準備、またはチームでの認識共有が必要なとき

例）「チーム名」のバリデーション仕様をコードに落とすなら…

• 必須入力
• 半角英数字とスペースのみ許可
• 20文字以内

など、「どんなチェックを行うか」 を明確にしないと、

• 実装で迷う
• テストで見逃す
• 人によって認識がバラバラ

というトラブルのもとになる！

大体の分け方：

状況	バリデーションを…
設計初期（外部設計など）	「あり」とだけ書くでOK
実装準備（内部設計など）	細かく書き出す（ルールごと）
プログラムコード／テスト項目	1つずつ分けて明示

外部設計の時から細かく聞かれるよ？🤔
▷ ここはいろいろだよね！

• 認識ズレの防止
• 後々機能追加や画面実装に関わるので「最初に決めておく」ほうが安心
• 理解度や設計の視点をチェック（先生視点）

「バリデーション」って実は“常識チェック”の集まりみたいなものだから、言葉は難しくても、内容は案外簡単！

でもまだ「ここはバリデーションありで～」っていう自分を想像できない😇
使っていれば、自然に使いこなしてるようになれるかな…

最後に：ここまで読んでいただき、ありがとうございます。

外部設計で「あれ、これは機能？処理？」と悩んだら、ぜひこの記事の表やチェックポイントを思い出してみてください。
自分も学んでいる最中なので、難しいポイントに出会ったら追記していきます！