第35話「頼む前に決めること」
ストラテジ系 ／ システム戦略 ── テーマ：要件定義・機能／非機能要件・RFIとRFP・DFD
▶ マンガで読む（無料・登録なし）この話で覚える用語（7語）
- 要件定義ようけんていぎ
- システムや業務に求めることを明らかにし、関係者で合意する工程。まず業務要件を定め、それを実現するための機能要件・非機能要件を決める。
- 機能要件きのうようけん
- システムが「何をするか」についての要件。例：領収書を登録できる、上司が承認できる、など。
- 非機能要件ひきのうようけん
- 機能以外の要件。「どれくらいうまく動くか」にあたる。性能（応答時間）、信頼性（止まりにくさ）、セキュリティ、使いやすさ、運用・保守のしやすさなど。
- RFIあーるえふあい
- 情報提供依頼（Request For Information）。調達のはじめに、候補の会社へ技術や製品、実績などの情報の提供を求めること。RFPを作る準備になる。
- RFPあーるえふぴー
- 提案依頼書（Request For Proposal）。システムの要件や条件を示し、候補の会社に提案書や見積書の提出を求める文書。
- DFDでぃーえふでぃー
- Data Flow Diagram。データの流れと処理を、プロセス（処理）・データフロー・データストア（保存先）・外部実体の記号で表した図。業務の分析に使う。
- BPMNびーぴーえむえぬ
- Business Process Model and Notation。業務の流れを表すための標準の書き方。担当ごとのレーンに、作業・分岐・イベントなどを並べて描く。
試験に出るポイント
- 機能要件＝「何をする？」→ カレーを出す
- 非機能要件＝「どれくらい？」→ 3分で出る・お腹をこわさない
- カレーが出ても3時間後なら客は帰る。だから非機能も大事
- 非機能＝性能・信頼性・セキュリティ・使いやすさ・運用など
- 「〜できる」は機能、「〜秒以内」「止まらない」は非機能
- RFI の I＝Information。「I（あい）さつ代わりに、情報ちょうだい」
- RFP の P＝Proposal（提案）。部長いわく「プロポーズ」
- 恋と同じで、まず相手を知って（I）からプロポーズ（P）
- 選定は、先に決めた評価基準で公平に比べる（顔で選ばない）
- システム化計画＝目的・予算・スケジュール・体制などを決める（要件定義より前）
- 「何をするか」＝機能要件／性能・信頼性・セキュリティ＝非機能要件
- RFI＝情報の提供を依頼／RFP＝要件を示して提案を依頼
- 調達の順番：RFI → RFP → 提案書・見積書 → 選定 → 契約
- データの流れと処理＝DFD／業務の流れの標準記法＝BPMN／実体と関連＝E-R図
確認クイズ（ITパスポート試験の形式）
- 利用者が領収書の画像を登録できること
- 上司が申請を承認または差し戻しできること
- 申請画面を3秒以内に表示すること
- 承認された申請のデータを会計システムに送ること
答えと解説を見る
正解：ウ 申請画面を3秒以内に表示すること
「どれくらいうまく動くか」が非機能要件。応答時間は性能なので非機能要件です。登録・承認・データの送信は「何をするか」なので機能要件です。
- 調達先の候補に、技術や製品についての情報の提供を求める文書
- 調達先の候補に、システムの要件を示して提案書の提出を求める文書
- 調達先の候補が、作り方と費用をまとめて発注側に出す文書
- 発注側と受注側が、納期や金額などを取り決める文書
答えと解説を見る
正解：イ 調達先の候補に、システムの要件を示して提案書の提出を求める文書
RFPは提案依頼書。情報の提供を求めるのはRFI、作り方と費用をまとめて出すのは提案書・見積書、納期や金額を取り決めるのは契約書です。
- RFI → RFP → 提案書の受領 → 選定 → 契約
- RFP → RFI → 提案書の受領 → 選定 → 契約
- RFI → 提案書の受領 → RFP → 契約 → 選定
- RFP → 提案書の受領 → 契約 → RFI → 選定
答えと解説を見る
正解：ア RFI → RFP → 提案書の受領 → 選定 → 契約
まず情報を集め（RFI）、要件を示して提案を頼み（RFP）、届いた提案書を比べて選び、最後に契約します。RFIとRFPの順番を逆にするのがよくある勘違いです。
マンガのセリフ（文字版）
部長「経費精算をシステム化するぞ！ミライくん、担当だ」
ミライ「はい！さっそく協力会社さんに作ってもらいます！」
ツカサ先輩「待て！何を作るかも決めずに頼む気か！？」
ツカサ先輩「まずシステム化計画で目的・予算・日程・体制を決める。次に要件定義だ」
ツカサ先輩「最初は業務要件。仕事をどう変えたいかを整理する」
ミライ「家を建てる前に、暮らし方を決める感じ…」
ツカサ先輩「システムが何をするかが機能要件。「領収書を撮って申請できる」などだ」
ミライ「できることのリスト、ですね」
ツカサ先輩「もうひとつ、機能以外の要件、非機能要件もある」
ミライ「機能じゃない…つまり「何もしない」のが要件！？」
ツカサ先輩「サボる要件があるか！どれくらいうまく動くかだ」
ツカサ先輩「速さ・止まりにくさ・安全さなど。品質の約束だな」
ミライ「性能や品質のことか…！」
- 機能要件＝「何をする？」→ カレーを出す
- 非機能要件＝「どれくらい？」→ 3分で出る・お腹をこわさない
- カレーが出ても3時間後なら客は帰る。だから非機能も大事
- 非機能＝性能・信頼性・セキュリティ・使いやすさ・運用など
- 「〜できる」は機能、「〜秒以内」「止まらない」は非機能
要件がかたまった。次は作る会社選び
ツカサ先輩「まず候補の会社にRFI（情報提供依頼）。どんな技術や製品があるか教えてもらう」
ミライ「いきなり見積もりじゃないんですね」
ツカサ先輩「次に出すのがRFP。Pはプロポーザルの略だ」
部長「プロポーズ！？ミライくん、だれに求婚する気だ！」
ツカサ先輩「求婚しません！RFP＝提案依頼書。要件を書いて提案を頼む文書です」
ミライ「RFIは聞く、RFPは頼む…！」
数日後
ヤマダさん「RFPを拝見しました。こちらが提案書と見積書です」
ミライ「ありがとうございます！他社さんのとも比べて選びますね」
- RFI の I＝Information。「I（あい）さつ代わりに、情報ちょうだい」
- RFP の P＝Proposal（提案）。部長いわく「プロポーズ」
- 恋と同じで、まず相手を知って（I）からプロポーズ（P）
- 選定は、先に決めた評価基準で公平に比べる（顔で選ばない）
ヤマダさん「要件の確認のため、今の業務を図にしてもよろしいですか」
ツカサ先輩「データの流れならDFD、仕事の手順ならBPMNだな」
ミライ「データの設計にはE-R図、でしたっけ」
- システム化計画＝目的・予算・スケジュール・体制などを決める（要件定義より前）
- 「何をするか」＝機能要件／性能・信頼性・セキュリティ＝非機能要件
- RFI＝情報の提供を依頼／RFP＝要件を示して提案を依頼
- 調達の順番：RFI → RFP → 提案書・見積書 → 選定 → 契約
- データの流れと処理＝DFD／業務の流れの標準記法＝BPMN／実体と関連＝E-R図
後日
部長「わしの誕生日会も、RFPを出して業者を選ぼう！」
ミライ「了解です！非機能要件に「部長のあいさつは3分以内」と書きますね」