📖 テーマ設定
🔊 音声設定
1.2
1.0
1.0
▶️ 再生コントロール
🎵 BGM設定
0.3
🔔 効果音設定
0.3

(演習)非機能要件の定義

概要

  • 日程: Day 2 / セッション6
  • 時間: 13:20-14:00
  • 形式: 演習
  • ゴール: 開発テーマについて、性能・可用性・セキュリティ等の非機能要件を3件以上定義できる
  • 学習形式: AIブレスト

導入(5分)

🗣️ 要約

  • 要件には機能要件(何をするか)だけでなく、非機能要件(どう動くべきか)という側面もある
  • このセッションでは開発テーマの非機能要件を3件以上、根拠つきで定義する

前のセッションでは、開発モデルの種類(ウォーターフォールやアジャイルなど)と、開発の工程を学びました。工程の最初に出てくるのが「要件」でしたね。

ところで、「要件」と聞いたとき、皆さんはどんな内容を思い浮かべますか? おそらく「ログインできる」「検索できる」といった、システムが何をするかという内容が多いのではないでしょうか。

実は要件には、もう一つの顔があります。それが「非機能要件」です。このセッションが終わる頃には、皆さんの開発テーマについて、非機能要件を3つ以上、根拠を持って言えるようになっています。

本編(20-40分)

🗣️ 要約

  • 機能要件と非機能要件の違いを、料理のレシピと厨房設備のたとえで理解する
  • 非機能要件の代表的な観点(性能・可用性・セキュリティ・保守性・運用性)を扱う

1. 機能要件と非機能要件の違い

🗣️ 要約

  • 機能要件はシステムが「何をするか」、非機能要件は「どう動くべきか」
  • 「検索できる」は機能要件、「検索結果が2秒以内に表示される」は非機能要件
  • 非機能要件は後回しにされがちだが、実装前に言語化しておく必要がある

要件には大きく2種類あります。

  • 機能要件:システムが「何をするか」
  • 非機能要件:システムが「どう動くべきか」

たとえば、「ユーザーが商品を検索できる」は機能要件です。しかし「検索結果は2秒以内に表示される」「検索機能は深夜でも止まらない」というのは、機能そのものではなく、機能がどのレベルで動くべきかという条件です。これが非機能要件にあたります。

これは、いわば料理のレシピと厨房設備の関係のようなものです。「カレーを作る」という手順(レシピ)が機能要件だとすると、「1時間以内に仕上げる」「衛生基準を満たす厨房で作る」という条件が非機能要件にあたります。レシピだけあっても、厨房の性能や衛生管理が伴わなければ、お店として成立しませんよね。

ここで少し考えてみてください。皆さんの開発テーマ(家計簿アプリ、レシピ類推サービスなど)で、「検索できる」「登録できる」といった機能要件は該当しますが、「同時に100人がアクセスしても落ちない」は該当しません。なぜなら、後者は機能そのものではなく、機能を支える条件だからです。

flowchart TD Req["要件定義"] --> Func["機能要件 (何をするか)"] Req --> NonFunc["非機能要件 (どう動くべきか)"] Func --> FuncEx["例: #quot;商品を検索できる#quot;"] NonFunc --> NonFuncEx["例: #quot;検索結果を2秒以内に表示する#quot;"]

ここがポイント

特に注意してほしいのは、非機能要件は「後回しにされがち」だという点です。よくある間違いとして、機能要件だけを定義してすぐに実装に入ってしまうケースがありますが、正しくは、実装前に「どのくらいの品質・性能で動かすか」も言語化しておくことです。あとから性能問題やセキュリティ問題が見つかると、設計をやり直すコストが大きくなります。

コラム

非機能要件を軽視して痛い目にあった話は、実はIT業界にたくさんあります。有名な例が、あるチケット予約サイトが人気アーティストのチケット発売と同時にアクセスが殺到してダウンしてしまう、という現象です。「チケットを予約できる」という機能要件は完璧に満たしていたのに、「同時に大量アクセスされても落ちない」という非機能要件(可用性)が抜け落ちていたために起きた事故でした。機能だけを見ていると、こういう「動くけど使えない」システムができあがってしまうのです。

2. 非機能要件の代表的な観点

🗣️ 要約

  • 代表的な観点は性能・処理効率、可用性、セキュリティ、保守性・拡張性、運用・保守のしやすさの5つ

非機能要件と言われても、何を考えればいいのか分からない、という声もよく聞きます。代表的な観点には次のようなものがあります。

  • 性能・処理効率(応答時間、同時アクセス数)
  • 可用性(止まらないこと、障害時の復旧のしやすさ)
  • セキュリティ(不正アクセス対策、データの暗号化)
  • 保守性・拡張性(機能追加のしやすさ)
  • 運用・保守のしやすさ(監視のしやすさ、ログの残し方)

ここまでで、機能要件と非機能要件の違い、そして非機能要件にどんな観点があるか、イメージできましたか? もし曖昧なところがあれば、次の演習で実際に手を動かしながら固めていきましょう。

💬 AIに聞いてみよう

🗣️ 要約

  • 開発テーマでありがちな非機能要件の例や、性能要件と可用性要件の違いなどをAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば:

  • 「(開発テーマ)でありがちな非機能要件の例を5つ挙げて」
  • 「性能要件と可用性要件の違いをもっと簡単な言葉で説明して」
  • 「非機能要件を後回しにすると実務でどんな問題が起きるの?」

実習・演習

🗣️ 要約

  • 開発テーマについて非機能要件を3件以上、理由つきで定義する演習

課題

🗣️ 要約

  • 性能・可用性・セキュリティ・保守性の観点でブレインストーミングし、「〜すること」という具体的な文にし、ペルソナ視点で理由を添える

チームの開発テーマについて、非機能要件を3件以上定義してください。

  1. 「性能・可用性・セキュリティ・保守性」の観点から、当てはまりそうなものをブレインストーミングする
  2. 出てきた要件を「〜すること」という具体的な文にする(例:「登録処理は1秒以内に完了すること」)
  3. なぜその非機能要件が必要なのか、ペルソナの視点で理由を添える

成果物

🗣️ 要約

  • 非機能要件一覧書(非機能要件を3件以上、理由付きでまとめたもの)

非機能要件一覧書(非機能要件を3件以上、理由付きでまとめたもの)

ヒント

🗣️ 要約

  • 「サービスが急に人気になったら何が困るか」を想像すると可用性・性能要件のヒントになる
  • AIに性能・可用性・セキュリティ観点での提案を依頼するのも有効

うまく要件が出てこない場合は、「もし自分たちのサービスが急に人気になったら、何が困るだろう?」と想像してみてください。それが可用性や性能の要件のヒントになります。AIに「(開発テーマ)で想定される非機能要件を、性能・可用性・セキュリティの観点でそれぞれ2つずつ提案して」と聞くのも有効です。

まとめ(5分)

🗣️ 要約

  • 要件には機能要件と非機能要件があり、非機能要件は動作の品質を決める条件
  • 次回はユーザインタフェースを学び、今回定義した非機能要件(特に性能・保守性)はUI設計にも直結する

今回学んだことを一言でまとめると、「要件には機能要件と非機能要件があり、非機能要件は動作の品質を決める条件である」ということです。

次回は「ユーザインタフェース」を学びます。今回定義した非機能要件(特に性能や保守性)は、UIの設計にも直結してくるので、頭の片隅に置いておいてください。

🔄 振り返りチェック

🗣️ 要約

  • 機能要件と非機能要件の違いを自分の言葉で説明できるか
  • 「検索結果を2秒以内に表示する」がどちらに当たるか、理由も含めて言えるか

以下の問いに答えられるか確認してみましょう:

  • 機能要件と非機能要件の違いを、自分の言葉で説明できますか?
  • 「検索結果を2秒以内に表示する」は機能要件と非機能要件のどちらに当てはまりますか?その理由も言えますか?

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

補足資料

🗣️ 要約

  • 参考資料はIPAの非機能要求グレード
  • 発展課題は、定義した非機能要件に優先度(必須/推奨/任意)を付けること
  • 参考リンク: IPA(情報処理推進機構)が公開している非機能要求グレードの資料
  • 発展課題: 定義した非機能要件に、優先度(必須/推奨/任意)を付けてみる

学習ガイド

🗣️ 要約

  • 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

想定される質問と回答例

🗣️ 要約

  • 非機能要件の粒度は開発テーマの規模による。学生演習では「数値目標+理由」で十分
  • 機能要件か非機能要件か迷うときは「サービス成立に必須か(機能)」「品質・条件の話か(非機能)」で切り分ける
質問 ヒント
非機能要件はどこまで細かく決めればいいの? 開発テーマの規模による。学生演習レベルでは「数値目標+理由」が言えれば十分。実務ではSLA(サービス品質保証)まで踏み込むこともあると伝える
機能要件か非機能要件か迷う要件がある 「これがないとサービスとして成立しないか(機能)」「これは品質・条件の話か(非機能)」で切り分けるとよい

つまずきやすいポイント

🗣️ 要約

  • 非機能要件が「セキュリティに気をつける」のような曖昧な表現になりやすい
  • 機能要件を非機能要件として書いてしまいやすい(例:「ログイン機能をつける」)
つまずきポイント ヒント
非機能要件が「セキュリティに気をつける」のような曖昧な表現になる 「〜すること」「〜以内に」など、判定可能な形に言い換えるよう促す
機能要件を非機能要件として書いてしまう(例:「ログイン機能をつける」) それは「何をするか」なので機能要件。非機能要件は「そのログインがどう動くべきか(例:3回失敗したらロックする)」を問い直す
読み上げを開始します...

AIに質問する