業務要件とシステム要件： 「観光プラン（やりたいこと）」と「移動手段（実現方法）」の違い
「最新のツールを導入したのに、現場の作業がちっとも楽にならない……」
「システムに詳しい人だけで話が進み、肝心の使い勝手が置いてけぼりだ……」
要件定義を進める中で、このような「手段の目的化」に悩まされていませんか？
前回は、[要件定義シリーズ第3回：ヒアリングの極意]で、バラバラな「わがまま」から真のニーズを抽出する技術を学びました。材料が揃った次にやるべきは、それを「業務要件」と「システム要件」に切り分ける作業です。
この2つの違いを正しく理解していないと、どれほど高機能なシステムを作っても「宝の持ち腐れ」になってしまいます。今回は、家族旅行の「観光プラン」と「移動手段」を例に、その決定的な違いを解説します。
業務要件とシステム要件の定義
まずは、それぞれの定義を整理しましょう。
業務要件（観光プラン）：ユーザーがやりたいこと
システムを使って、「誰が」「いつ」「どんな流れで」仕事をするのかを定義したものです。ITの専門知識は不要で、あくまで「人の動き」にフォーカスします。
- 旅行なら： 「どこを巡り、何を食べ、どんな体験をするか」という観光プランそのものです。
- ビジネスの例： 「営業担当者が外出先から、その日の売上報告を5分以内に完了させ、即座にマネージャーに共有される状態にする」
システム要件（移動手段）：ITで実現する方法
業務要件を支えるために、システムが備えるべき具体的な機能を定義したものです。業務要件という「目的地」へたどり着くための「道具」を決めます。
- 旅行なら： 観光プランを実現するための移動手段（車、電車、飛行機）や、「QRコードやクレカが使える決済機能」などです。
- ビジネスの例： 上記の業務を実現するために必要な「スマホ対応の入力画面」「データ同期機能」「自動プッシュ通知機能」などを指します。
このように、業務要件が「何をするか（What）」であり、システム要件が「どう実現するか（How）」という密接な親子関係にあります。
なぜ「業務要件」が先なのか？（観光プランなき移動は迷走する）
要件定義の現場でよくある失敗は、「どんなシステム（道具）にするか」を、「どんな業務（過ごし方）にするか」より先に決めてしまうことです。
【旅行での失敗例】
「せっかくの旅行だから、最新のキャンピングカーをレンタルしよう！」と、先に移動手段を決めたとします。 しかし、後から「歴史ある温泉街の細い路地にある老舗旅館に行きたい」という観光プラン（業務要件）が決まったらどうなるでしょうか？ 大きなキャンピングカーでは路地に入り込めず、結局、宿にたどり着くことができません。
【システム開発での失敗例】
「最新のAIチャットボットを導入しよう！」と先に決めたものの、現場の業務フローを確認したところ「顧客との電話応対中に、手書きの台帳をめくりながら回答する」のが最も効率的だった…。結果、AIは全く使われず、高額な導入コストが無駄になるというケースです。
「どう動くか（業務）」が決まっていないのに「何を使うか（システム）」を決めるのは、行き先を決めずに切符を買うのと同じです。
業務要件を整理する「業務フロー」：点をつないで線にする
「なぜ個別の要望だけでなく、フロー（流れ）が必要なの？」と思うかもしれません。しかし、業務要件を定義する上で「一日の流れ」を可視化することは不可欠です。
なぜなら、「点（個別の要望）」だけでは、実際の業務や旅行は成立しないからです。
- 旅行の例： 「美味しいランチが食べたい」「有名な滝を見たい」という「点」があっても、前後の移動時間が抜けていればランチの予約に間に合いません。
- ビジネスの例： 「承認ボタンが欲しい」「集計グラフが見たい」という「点」だけを実装しても、誰がどのタイミングでデータを入力し、いつ誰が承認するのかという「情報のバトン」がつながっていなければ、システムは動きません。
「現状（As-Is）」から「理想（To-Be）」へ
業務フローを描く際は、いきなり理想を目指すのではなく、まず「現状（As-Is）」を可視化することから始めます。
- 現状（As-Is）を知る： 「今は誰が, 何に時間がかかって、どこで苦労しているか」を浮き彫りにします。旅行なら「いつも渋滞にハマって、子供が飽きてしまう」という課題を見つける作業です。
- 理想（To-Be）を描く： 現状の課題を解決し、「こうなったら最高だ」という新しい流れを描きます。
この「As-Is」と「To-Be」のギャップこそが、システムが解決すべき本当の課題となります。
旅行の例：理想の過ごし方（To-Beフロー）
- 午前： 渋滞を避けるため早朝に出発。車内で軽く朝食。
- 昼： 予約困難な地元の名店でランチ（11:30入店）。
- 午後： 子供が走り回れる広い公園で2時間遊ぶ。
- 夕方： 疲れが出る前にチェックインし、夕食前に温泉。
ビジネスの例：理想の受注プロセス（To-Beフロー）
- 受注： Webフォームから注文が入ると、自動で在庫を引き当てる。
- 承認： 10万円以下の注文は上長の承認をスキップする。
- 出荷： 倉庫に自動でピッキング指示が飛ぶ。
- 通知： 発送完了メールが顧客にリアルタイムで届く。
この「流れ」に納得感があって初めて、「じゃあ、この自動在庫引き当てにはどんな機能が必要か？」というシステム要件の議論ができるようになります。なお、具体的な図解の方法については[業務フローの基本的な書き方 業務フローは要件定義の重要なツール！]で詳しく解説していますので、あわせて参考にしてください。
リーダーに必要な「翻訳」の事例：手段と目的を分ける
ユーザーはしばしば、システム要件（手段）を業務要件（目的）のように語ります。リーダーはこれを正しく切り分け、翻訳しなければなりません。
| ユーザーの要望（混同） | 業務要件（本来の目的） | システム要件（実現手段） |
|---|---|---|
| 「スマホで承認ボタンが欲しい」 | 外出先でも承認作業を停滞させたくない | モバイル端末対応、プッシュ通知機能 |
| 「Excelみたいな一覧表がいい」 | 大量のデータを一目で比較・修正したい | グリッド表示、一括更新機能 |
| 「AIで売上予測を出したい」 | 勘に頼らず適正な在庫数を維持したい | AIエンジン連携、在庫シミュレーション機能 |
要望の中に「ツール名」や「具体的な機能名」が出てきたら、「それを使って、誰が、どんな作業を楽にしたいのですか？」と問い直しましょう。それが業務要件を引き出す鍵です。
まとめ：良い「観光プラン」が良い「乗り物」を選ぶ
業務要件（観光プラン）は、システム開発における主役です。システム要件（移動手段）は、その主役を輝かせるための脇役に過ぎません。
- 業務要件： ユーザーが何を達成したいか。IT抜きで語れる。
- システム要件： 業務をどうITで助けるか。エンジニアが作るもの。
「このボタン（機能）は何のためにあるのか？」という問いに、「現場のこの業務課題を解決し、理想のフローを実現するために必要だからだ」と全員が即答できる状態。それが、手戻りのない健全な要件定義の姿です。
次のステップ：見落としがちな「非機能」の壁
観光プラン（業務）と乗り物（システム）が決まったら、次は「安全・安心」の検討です。 「快適に走れる高級車だけど、燃費が悪すぎて1時間おきに給油が必要」「セキュリティが完璧すぎて、鍵を開けるのに10分かかる」……。そんな極端な乗り物では困りますよね。
次回は、機能と同じくらい重要な「非機能要件の落とし穴：楽しい旅行を支える『燃費』や『保険』の決め方」について解説します。
地味だけど絶対に外せない、システムの「品質」の守り方を学びましょう！
次の記事を読む：非機能要件の落とし穴：楽しい旅行を支える「インフラ」や「品質」の決め方
