3大要件トレードオフ_DXエンジニア向け_20261008

FOR MID-LEVEL & DX ENGINEERS 3大要件とトレードオフの 意思決定フレームワーク SLA/SLO化・Square Route・MoSCoW・ブルックスの法則を実務に落とす うさうさ研修工房

01 | 非機能要件の定量化 ISO/IEC 25010の特性を SLA/SLOに変換する 品質特性 定量指標の例 計測方法 性能効率性 レスポンスタイム p95 ≤ 800ms APM 信頼性 可用性 99.9%／月、MTTR 死活監視・インシデント管理 セキュリティ 重大脆弱性の修正SLA 72時間、監査ログ5年保持 脆弱性スキャン・SIEM 保守性 変更リードタイム 1スプリント以内 DORA指標 使用性 タスク完了率、SUSスコア ユーザビリティテスト 形容詞（速い・安全）のままでは検収できない。数値化して「検収条件」にする。

02 | トレーサビリティ RTMでビジネス要件 →機能→非機能→テストをつなぐ BR FR 機能要件 対応NFR テスト BR-01 処理時間50%削減 FR-01 レシートOCR自動読取 NFR-01 読取3秒以内 TC-012 BR-01 FR-02 勘定科目の自動分類 NFR-02 分類精度95%以上 TC-018 BR-02 内部統制強化 FR-03 承認フロー電子化 NFR-03 操作ログ5年保持 TC-025 「この BRを削るとどの FR・NFR・テストが不要になるか」を即答でき、スコープ調整をデータで進められる。

03 | Iron Triangleの限界 Atkinson (1999)：Square Routeで成功を 4面から評価する ① Iron Triangle ② Information System コスト・時間・品質（従来の管理指標） 保守性・信頼性・使いやすさ（技術の質） ③ Organizational Benefits ④ Stakeholder Benefits 業務効率化・収益改善（組織便益） 利用者満足・社会的便益（関係者便益） 予算内・納期内でも「現場で使われない」のは①だけで評価しているため。評価会議に③④を組み込む。

04 | スコープ調整と意思決定 MoSCoW法＋重み付けスコアリング 評価軸（重み） MoSCoW（DSDM） A 増員 B スコープ 削減 C 期間延 長 BR達成度 40% 4 60%以内）3 Must：欠けると失敗（全体の 5 Should：重要だが代替あり 追加コスト 25% 2 Could：あれば望ましい 5 4 Won't：今回は対象外 納期遵守 20% 5 1 5 品質リスク 15% 2 4 Mustが60%超なら優先順位付け未完のサイン。 5 加重スコア 3.75 3.35 4.15

05 | 増員判断とガバナンス ブルックスの法則チェックリストと変更管理 増員前チェック（ 2つ以上✕なら増員より削減） 変更管理フロー □ 残期間は新メンバーの立ち上がりを吸収できるか 変更要求 □ 追加タスクは分割（並列化）可能か ↓ □ コミュニケーション経路の増加を体制で吸収できるか RTMで影響範囲を特定 □ スコープ削減・期間延長を先に検討したか ↓ 重み付けスコアリングで代替案を評価 遅延プロジェクトへの増員は逆効果になり得る（ Brooks, 1975）。 ↓ 承認 ↓ 意思決定ログに記録・ PJ計画書を更新 ↓ 経営層／現場／開発チームへ展開

07 | 査読研究からの実務示唆① 「非機能要件」は本当に別物か？ — Eckhardt et al. (ICSE 2016) 研究が示したこと（事実） 実務への落とし込み（編集） ・NFRは機能要件と別に書かれ、数値目標がなく記述も曖昧になりがち で、分析もテストも難しい □ NFRは「条件＋振る舞い＋数値」で書く ・実証分析の結果、多くの「非機能」要件は、システムの振る舞いを述べた ものだった □ RTMで機能要件IDに紐づけ、テストケースを必ず付ける ・よって多くの NFRは機能要件と同様に扱える、と著者らは論じている 例：月末ピーク時、申請登録は 3秒以内（p95） □ 形容詞だけの NFRは受け入れ前に差し戻す □ 別紙に隔離せず、機能要件と同じレビューに載せる

08 | 査読研究からの実務示唆② 納期短縮には下限がある — Boehm の Impossible Region 研究が示したこと（事実） 実務への落とし込み（編集） ・Boehm (1981) 以来、名目スケジュールの約 75%未満には、人や金を足し ても短縮できないとされる □ 要望納期 ÷ 名目納期 を算出する ・COCOMO IIの実証研究（ 161件の産業プロジェクト）では、開発者は短縮 可能な幅を楽観的に見積もる傾向が示された □ 短縮案は「追加コスト」と「品質リスク」を併記 ・短縮するほど工数は急増し、コストは漸近的に膨らむ □ 75%に近い／下回るなら増員でなくスコープ削減（ MoSCoW） □ 短縮の見積り自体が楽観的でないか、第三者レビューを入れる □ 意思決定ログに名目納期と短縮率を記録

09 | 実務チェックシート 要件・トレードオフ会議の前に確認する 5項目 確認項目 根拠 NGのサイン NFRに数値と測定方法があるか Eckhardt et al. 2016 / ISO 25010 「速い」「安全」だけで検収不能 全要件がBRに紐づくか（RTM） Sommerville / 本編RTM 紐づかない機能が残っている Iron Triangle以外の便益も評価するか Atkinson 1999 納期・予算の報告のみ 短縮率は名目比75%より十分上か Boehm 1981 納期短縮を増員だけで解決 増員前チェックを通したか Brooks 1975 遅延後に急な増員

10 | お客様向け説明① システムの「要望」は 3つに分けてお伺いします ① 目的（なぜ） ② 機能（何ができる） ③ 使い心地・安心（どのくらい） このシステムで、どんな成果を目指します か？ 日々の業務で、何ができると助かりますか？ どのくらい速く、止まりにくく、安全であってほ しいですか？ 例：レシートを撮影するだけで金額が入る 例：経費精算にかかる時間を半分にしたい 例：月末の混雑時でも 3秒以内に登録できる IPAは非機能要求の用語をやさしい言葉に置き換えた小冊子を公開しています（出典参照）。③は数字で一緒に決めることで、認識のズレを防げます。

11 | お客様向け説明② 費用・納期・体制は連動するため、優先順位をご相談します ご要望 ご提案の選択肢 お客様への影響 納期を早めたい 機能の一部を次の段階に回す／体制を増やす 機能が減る／費用が増え、立ち上げ期間も必要 費用を抑えたい 機能を絞る／期間を延ばす 開始できる機能が減る／稼働が遅れる 機能を増やしたい 期間を延ばす／費用を追加する 納期が延びる／費用が増える どれを優先するかを最初にご相談し、変更が出た場合も同じ表で比較して一緒に決めます。決定の理由は議事録に残します。 ※「人を増やせば早くなる」とは限りません（ブルックスの法則）。増員は立ち上げ期間を含めてご説明します。

12 | お客様向け説明③ 非機能要求グレード（ IPA）で「安心・快適」の水準を一緒に決める IPA公式資料の位置づけ（事実） お客様との進め方（編集） ・IPAが2009〜2018年度に実施した、システム構築の上流工程強化（非機 能要求グレード）の成果物 □ システムの性格に近い典型モデルを選ぶ ・グレード表は 3つの典型モデルごとに、主な非機能要求項目の要求レベ ルを示す □ 高い水準ほど費用・期間に影響する点を併せて説明 ・活用シートは、プロジェクトに応じてカスタマイズできる ・経営層向けの読本も公開されている □ 項目ごとに要求レベルを一緒に確認する □ 合意した水準を活用シートに残す □ 変更時は水準と費用の関係を見直す ※IPAの公開ページはアーカイブ掲載です。最新の内容は公式サイトでご 確認ください。

13 | 新人向け指導方法① フィードバックは 4階層で考える — Hattie & Timperley (2007) 階層 内容 要件定義での声かけ例 課題（Task） 成果物が正しいか 「この機能要件は、どのBRに紐づく？」 手順（Process） どう進めたか・方法 「NFRはどの品質特性から洗い出した？」 自己調整（Self-regulation） 自分で確認・修正する力 「提出前に、RTMで抜けを確認できる？」 自己（Self） 人への評価・称賛 「えらい」「センスがない」（学習効果は限定的） レビューでは、人ではなく課題と手順に具体的に触れ、次の行動（フィードフォワード）につなげます。 ※初学者には課題レベルの具体的な指摘が先、慣れてきたら手順・自己調整へ、という整理が教育研究の解説で紹介されています（BERA）。

14 | 新人向け指導方法② 要件定義を 5段階で育てる（編集：本資料の道具を練習に使う） 段階 新人の課題 指導者の関わり方 1 既存の機能一覧を、目的／機能／品質に仕分ける 正解例と見比べ、迷った理由を言葉にさせる 2 RTMを1案件ぶん一緒に作る 最初の数行は手本、残りは本人が記入 3 形容詞のNFRを数値＋測定方法に直す ISO/IEC 25010の特性を手がかりに渡す 4 トレードオフ会議に同席し、議事録を書く 事実と評価を分けているか、課題・手順の観点で指摘 5 選択肢表（A/B/C）を自分で作り、提案する 結論でなく、評価軸の選び方を問う 段階は理解度を見て進め、各段階の終わりに「何ができるようになったか」を本人の言葉で確認します。

15 | 新人向け指導方法③ レビュー時の声かけ NG → OK 場面 ❌ 避けたい言い方 ✅ 伝え方の例 NFRが曖昧 「また曖昧だね。センスないな」 「“速い”を数字にしたい。 p95で何秒なら業務に支障がない？」 RTMに抜け 「確認不足」 「FR-05はBRに紐づいていないね。どの BRに貢献する想定だった？」 議事録に主観 「書き方が悪い」 「“非現実的”は評価なので、事実（見積 4週間／要望 2週間）に置き換えてみよう」 うまくできた 「さすが、えらい」 「NFRに測定方法まで書いたので、テストに直結するね」 称賛も、人でなく「何がよかったか」に具体的に触れると、次に再現しやすくなります。

16 | トラブルを防ぐヒアリングシート① 目的・成果・決定者を最初に確認する 確認項目 聞き方の例 確認 目的（なぜ） このシステムで、何をどう変えたいですか？ □ 成功の指標 できた／できないを、何で判断しますか？（数字で） □ 現状の課題 いま最も困っている業務と、その頻度・時間は？ □ 「現行どおり」 現行のどの動きを、そのまま残しますか？具体的に教えてください □ 決定者・確認者 最終判断は誰ですか？仕様確認はどなたにお願いできますか？ □ IPAの要件定義ガイドは、「現行どおり」という要求提示は要件定義ではない、としています。現行の何を残すのかを具体的に聞き取ります。

17 | トラブルを防ぐヒアリングシート② 機能と「安心・快適」の水準は数字で聞く 確認項目 聞き方の例 確認 利用者と業務の流れ 誰が・いつ・何のために使いますか？現在の手順を教えてください □ 量とピーク 利用者数・件数は？最も混む時期や時間帯は？ □ 稼働時間と停止 止まって困る時間帯は？何時間までなら止まっても業務が回りますか？ □ 情報の取り扱い 個人情報や機密情報は含みますか？監査や保管期間の決まりは？ □ 既存システム連携 つながる相手のシステムと、受け渡す情報・タイミングは？ □ 「速く」「安全に」といった言葉が出たら、「どのくらいなら十分ですか？」と数字に置き換えて確認します（ IPA 非機能要求グレードも参照）。

18 | トラブルを防ぐヒアリングシート③ 費用・納期・体制・優先順位を先に合意する 確認項目 聞き方の例 確認 予算 上限の目安はありますか？追加が出た場合の判断者は？ □ 納期 いつまでに必要ですか？動かせない理由（法令・行事など）は？ □ 優先順位 費用・納期・機能のうち、最も動かせないのはどれですか？ □ 必須と任意 なくては困る機能と、あれば嬉しい機能を分けてください（MoSCoW） □ お客様側の体制 確認・テストに参加できる方と、時間の目安は？ □ 変更の進め方 要望が増えた場合は、費用・納期への影響を一緒に確認して決めてよいですか？ □ 記入後は内容を復唱し、合意事項・保留事項を議事録に残して双方で確認します（議事録フレーズ集を参照）。

19 | PJ仕様選定① 選び方 候補案を評価軸で比べ、「検証のしやすさ」も軸に入れる 評価軸（重み） 案A 既製 OCR利用 案B 自社開発 案C 手入力補助のみ BR達成度 30% 4 5 2 コスト 25% 3 2 5 納期 20% 5 2 5 品質リスク 15% 3 3 4 テスト容易性 10% 4 3 5 加重スコア（例） 3.80 3.15 3.95 ※数値は例示（仮）。 BR達成度に最低ラインを設け、 Must要件を満たさない案は点数にかかわらず除外します。選定理由と採点は意思決定ログに残します。

20 | PJ仕様選定② 書き方 テストに使える仕様の条件 — ISO/IEC/IEEE 29148 特性 意味 仕様書での確認 テストへの効果 検証可能（Verifiable） 達成を証明・測定できる 数値と測定方法があるか 合格基準がそのまま決まる 曖昧でない（Unambiguous） 解釈が1つだけ 形容詞・「など」がないか 期待結果がぶれない 単一（Singular） 1つの要求は1つのこと 1文に複数の条件がないか 1要件＝1テストに対応させやすい 追跡可能（Traceable） 上位の必要性と下位の成果物に辿 れる BR→FR/NFR→テストIDが辿れるか 影響範囲と漏れを確認できる 同規格は、要求は測定可能であるほど検証しやすくなる、としています（二次資料経由。規格本文は有料のため要確認）。

21 | PJ仕様選定③ テストへの接続 選定した仕様を「受け入れ基準」にして、 RTMでテストにつなぐ 要件ID 選定した仕様（受け入れ基準） テスト種別 合格基準 結果 FR-01 レシート撮影で金額・日付が自動入力される 機能テスト テスト用レシート20枚で、金額一致が19枚以上 □ NFR-01 月末ピーク時、撮影から入力表示まで3秒以内（p95） 性能テスト 同時50人の負荷でp95が3秒以内 □ FR-03 申請は上長が承認するまで経理に連携されない 機能テスト 未承認データが連携されない（異常系含む） □ NFR-03 操作ログを5年間保持し、検索できる 運用・監査確認 保管設定の確認と、期間指定検索の成功 □ ※数値は例示（仮）。合格基準は仕様選定の時点で顧客と合意し、受け入れテストでそのまま使います。

22 | PJ仕様選定④ テスト観点 ISO/IEC 25010の品質特性からテスト観点を選ぶ 品質特性 主なテスト観点（例） 仕様選定で決めておくこと 機能適合性 機能テスト・受け入れテスト 正常系／異常系の期待結果 性能効率性 負荷・応答時間テスト 同時利用数・ p95の目標値 信頼性 障害・復旧テスト 許容停止時間・復旧目標 セキュリティ 脆弱性診断・権限テスト 守る情報と対象範囲 使用性 ユーザビリティテスト 対象利用者・完了率の目標 保守性 変更容易性の確認・レビュー 変更の例と許容工数 観点の対応づけは本資料の編集です。全特性を網羅できない場合は、 MoSCoWで優先度の高い特性から選びます。

23 | まとめ・出典 実務の要点と参考文献 1. NFRは数値＋振る舞いで書き、機能要件と同じレビューに載せる 2. Square Routeで組織・関係者便益も評価する 3. 納期短縮は名目の 75%が目安の下限。超えるならスコープ削減 4. 意思決定はスコアリング＋ログで可視化 5. 増員はチェックリストを通してから 6. 新人指導は課題・手順への具体的なフィードバックから 7. 初回ヒアリングで目的・数値・制約・優先順位を確認する 8. 仕様は選定時に検証方法まで決め、受け入れテストに使える形にする 要件の品質特性（ ISO/IEC/IEEE 29148の解説・二次資料） https://arxiv.org/pdf/2408.10886 要件の検証可能性・追跡可能性（同規格の解説・二次資料） IPA ユーザのための要件定義ガイド https://arxiv.org/pdf/2502.18617 第2版（アーカイブ） https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html Hattie & Timperley (2007) The Power of Feedback, Review of Educational Research 77(1) https://www.uky.edu/~gmswan3/575/Hattie_Timperly_2007.pdf BERA: Hattie & Timperleyのフィードバック階層の解説 IPA 非機能要求グレード（紹介ページ・アーカイブ） https://www.bera.ac.uk/?p=46755 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html IPA 非機能要求グレード 2018 利用ガイド [活用編 ]・経営層向け読本 改訂 https://www.ipa.go.jp/ikc/reports/20190328.html ISO/IEC 25010:2011 https://www.iso.org/standard/35733.html Atkinson (1999) IJPM 17(6) https://www.sciencedirect.com/science/article/abs/pii/S0263786398000696 Eckhardt et al. (ICSE 2016) 非機能要件 https://arxiv.org/pdf/1611.08868 Yang, Chen, Valerdi, Boehm: Effect of Schedule Compression on Project Effort https://dspace.mit.edu/handle/1721.1/84158 Meyer: Shortest Possible Schedule（Boehm 1981の解説） https://cacm.acm.org/blogcacm/the-shortest-possible-schedule-theorem-yes-you-can-throw-money-at-software-deadlines Square Route解説（ DTU） http://wiki.doing-projects.org/index.php/The_iron_triangle_as_an_analytical_tool MoSCoW method https://en.wikipedia.org/wiki/MoSCoW_method Brooks's law（原典： Brooks 1975） https://en.wikipedia.org/wiki/Brooks%27s_law

• https://arxiv.org/pdf/2408.10886
• https://arxiv.org/pdf/2502.18617
• https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html
• https://www.uky.edu/~gmswan3/575/Hattie_Timperly_2007.pdf
• https://www.bera.ac.uk/?p=46755
• https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• https://www.ipa.go.jp/ikc/reports/20190328.html
• https://www.iso.org/standard/35733.html
• https://www.sciencedirect.com/science/article/abs/pii/S0263786398000696
• https://arxiv.org/pdf/1611.08868
• https://dspace.mit.edu/handle/1721.1/84158
• https://cacm.acm.org/blogcacm/the-shortest-possible-schedule-theorem-yes-you-can-throw-money-at-software-deadlines
• http://wiki.doing-projects.org/index.php/The_iron_triangle_as_an_analytical_tool
• https://en.wikipedia.org/wiki/MoSCoW_method
• https://en.wikipedia.org/wiki/Brooks's_law