購買部門の要望を選定に使える要件に書き直す——必須の線と評価表

「使いやすいシステムを」は、要件ではない

購買部門から受発注のシステムを入れたいと相談を受けると、最初に届く要望はたいてい次のような言葉である。「今の表計算より楽にしたい」「取引先とのやりとりを一元管理したい」「承認をちゃんと回したい」「履歴が追えるようにしたい」。どれも本音で、間違ってはいない。ただ、この言葉のまま事業者に渡しても、どの事業者も「できます」と答える。比べる物差しにならないのである。

IPA（情報処理推進機構）のユーザのための要件定義ガイドは、要求と要件を分けて使っている。要求は JIS X 0166 の要求事項と同じ意味で使い、要件はその要求を文書化・仕様化して関係者と合意したもので、次の工程の入力になるため、業務部門から IT 部門へ、IT 部門から開発を担う事業者へと第三者に伝達可能な形に形式化されている必要がある、としている^[1]。購買部門の言葉は要求で、情報システム部門の仕事はそれを要件に書き直すことである。

同じガイドは、要件定義の文書があいまいだと結果が正しく伝わらず、開発されたシステムに仕様の漏れや誤りが入り込み、利用部門が参加したテストで指摘が多発したり、稼働後に実装漏れの指摘が続いたりすると書いている^[1]。既製のクラウドサービスを選ぶ場合は開発こそしないが、同じことが「入れてから足りないことに気づく」という形で起きる。

要望を業務の流れに戻す

書き直しの最初の作業は、要望が業務のどこで出てきたものかを特定することである。購買の業務は、品目と取引先の登録、見積依頼、比較と決定、発注、納期の回答と追いかけ、入荷と検収、請求の照合と支払、という流れでつながっている。要望を一つずつ、この流れのどこで、誰が、何に困って出てきたものかに置き直す。

置き直すと、同じ言葉が別の意味だったことに気づく。たとえば「一元管理したい」は、見積依頼の段階では取引先からの回答が担当者のメールに散らばっている問題で、納期の段階では回答された納期を誰も一覧で見られない問題で、支払の段階では検収の結果と請求書が別々の場所にある問題である。ガイドが要件文書の注意点の最初に挙げているのが、抽象的な単語は定義を明確にして使うこと、特に「〇〇管理」は何をすることかを明確に定義すること、である^[1]。「管理」という言葉が出てきたら、その場で「何を、いつ、誰が、どうできれば管理できたことになるか」を聞き返す。

品目や取引先の登録まわりの要望は、マスタに何を持つかの話になる。その中身は品目仕様をどこまでマスタに持つかと取引先マスタに何を持つかで、発注してから後に要る機能は発注管理システムに要る機能で整理している。この記事は、そうした中身を「選定に使える文」にする手順を扱う。

手段の形で出てきた要望は、目的に戻す

「表計算に出力できること」「画面を今の表計算と同じ並びにしてほしい」のように、要望は手段の形で出てくることが多い。手段のまま要件にすると、それを満たす製品しか残らない。出力したいのは経理に渡すためなのか、上司に報告するためなのか、取引先別の集計を見るためなのか。経理に渡すためなら、本当の要件は会計システムとの受け渡しであり、それは会計・生産管理・在庫のシステムと購買システムをどうつなぐかの論点になる。

ガイドは、記述された要件が要求を抜け漏れなく満たしているかを確かめる「検証」と、定義された要求そのものが目的の実現に妥当な手段かを確かめる「妥当性確認」を分けている^[1]。要件の一覧を購買部門に見せて「これで全部ですか」と聞くのが検証、「これを満たせば、困っていたことは本当に解消しますか」と聞くのが妥当性確認である。手段の形の要望は、妥当性確認で目的に戻すと別の要件に変わることが多い。

誰が読んでも同じ判定になる文に書く

要件は、事業者に渡したときに「できる」「できない」の答えが一つに決まる文でなければならない。ガイドは要件文書の注意点を 11 項目にまとめており、そのなかで、形容詞や副詞を使った場合は補足説明が必要だとし、例として「高速で動作する」を「入力後 1 秒以内に応答がある」に置き換えている^[1]。一文には一つのことだけを書くこと、表にできるものは表にすること、「以上・以下」のような表現は等号・不等号で書くことも挙げている^[1]。

購買部門のよくある要望を、この考え方で書き直すと次のようになる。右端の列は、選定のときに何で確かめるかである。

表の数字（3 社、1,000 件、3 秒）は書き方の例で、自社の実情に合わせて決める値である。大事なのは、値が入っていることで判定が一つに決まる点にある。「快適に」「十分な」と書いた要件は、全事業者が満たすと答え、比較の役に立たない。

一番上の行は、法令の要件とも重なる。取適法の対象取引について 7 条の記録を電磁的記録で持つ場合、取引先の名称等や範囲指定した発注日で検索できること、画面に表示し書面に出力できることが求められる^[6]。電子帳簿保存法の電子取引データは「日付・金額・取引先」で検索できる必要がある^[5]。法令上外せない要件の全体は受発注システムの選び方——電子帳簿保存法と取適法で外せない要件にまとめてあるので、要件の一覧を作ったらそこと突き合わせて漏れを確かめる。変更の記録に何を持たせるかは操作の記録（ログ）を何のために、何を、どれだけ残すかで扱う。

非機能の要件は「作らせる」のではなく「選ぶ」形で書く

機能の要件と同じくらい漏れやすいのが、止まってよい時間、障害のときにどこまで戻せるか、データをどう移すか、どれだけの人数で使うか、といった非機能の要件である。IPA の非機能要求グレードは、非機能の要求を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの 6 つの大項目に整理している^[2]。購買部門の要望にはまず出てこない項目なので、情報システム部門が自分から埋める必要がある。

非機能要求グレードには、システムの社会的な影響の大きさに応じた 3 つのモデルシステムが示されている。そのうち主な項目を抜き出すと、次のようになる^[2]。

非機能要求グレードは中央の列を、企業活動の基盤で、機能が低下又は利用不可能になると企業活動に多大な影響を及ぼし取引先や顧客等の外部利用者にも影響を及ぼすもの、と説明している^[2]。左の列は企業の特定部門が限られた範囲で使うシステムである。自社の購買システムが止まったとき、発注が出せない影響がどこまで及ぶかを購買部門と話し、どの列に近いかを決める。年間の停止が数日で困るのか、1 時間で困るのかで、選べる事業者の範囲が変わる。

ここで注意したいのは、非機能要求グレードが、利用者と開発事業者の間で非機能の要求を合意し、システムの基盤を作ることを想定した道具だという点である^[2]。クラウドの購買システムでは、稼働率もバックアップも事業者がすでに決めている。利用者が書くべき要件は「99.99% で作ること」ではなく、「事業者が開示する稼働率の目標値と実績値が、自社が許容できる水準以上であること」になる。

開示を求める項目には、総務省の ASP・SaaS の安全・信頼性に係る情報開示指針が使える。指針は事業者が開示する項目を必須と選択に分けて示しており、たとえばサービス稼働率の目標値・実績値とサービス停止の事故歴、利用者データのバックアップの実施間隔と何世代前まで持つか、SLA（サービスレベルの合意）が契約書に添付されるか否か、サービスの提供時間帯、アプリケーションのカスタマイズの範囲は、いずれも必須の項目に入っている^[3]。要件の一覧に「指針の該当項目について開示を受けること」と書いておけば、事業者ごとに同じ物差しで答えをそろえられる。

IPA の中小企業のためのクラウドサービス安全利用の手引きも、選ぶときに確かめる 6 項目の一つとして、サービスの稼働率、障害発生頻度、障害時の回復目標時間などのサービス品質保証が示されているかを挙げている^[4]。セキュリティの非機能要件をどう確かめるか、事業者の回答をどう読むかは受発注・購買のクラウドサービスの安全性を、選ぶ前にどう確かめるかで詳しく扱う。

「必須」と「あれば良い」を分ける

要件は書き出すほど数が膨らむ。全部を必須にすると満たす製品がなくなるか、満たすと答えた製品の言い分を確かめきれなくなる。ガイドは、要求の優先順位をつける判断基準として、有効性（目的にどれだけ貢献するか）、必要性（法制度対応、内部統制、社会的責任、将来性などの観点で必要か）、緊急性、費用、実現性、新たな問題（実現したときに新しく生じる問題はないか）の 6 つを挙げ、取捨選択の全体評価には、必須（Must）、推奨（Should）、できれば（Could）、不要（Won’t）の 4 つに分ける MoSCoW 分析が参考になるとしている^[1]。

購買システムの選定で必須に入れてよいのは、おおむね次の三つに限られる。一つ目は法令上欠かせないもので、ガイドの判断基準でいえば必要性に当たる。二つ目は、それがないと業務が止まるもの。三つ目は、後から変えられないもの、たとえばデータの保管場所や、取引先に利用者登録を求めるかどうかのように、製品の作りで決まってしまうものである。「あると便利」「今の運用ではこうしている」は推奨以下に置く。

既製のサービスを選ぶときは、必須を増やすほど「業務をシステムに合わせる」余地がなくなる。ガイドは業務パッケージの導入について、失敗の原因はカスタマイズの量が多くなることで、カスタマイズが 20％以上あると新規開発と変わらないと言われているとし、業務をパッケージに合わせるという意識を強く持つよう書いている^[1]。クラウドの購買システムでは多くの場合カスタマイズそのものの範囲が限られており、先の情報開示指針でもカスタマイズの範囲は開示の必須項目である^[3]。今の帳票の並びや、今の承認の段数をそのまま必須に書くと、合わせられる製品が残らない。承認の段数を何段にするかは承認の段数はいくつ要るかで考え方を整理しているので、今の段数を前提にせず見直す機会にしてよい。

評価表への落とし方

要件を分けたら、事業者の回答を並べる評価表にする。1 行に 1 つの要件を置き、列は次のように取る。

1. 要件の番号と文
上で書き直した文をそのまま使う。番号を振っておくと、事業者への質問状と回答を突き合わせやすい。

2. 区分
必須・推奨・できれば。不要と決めたものも、検討した記録として行を残しておく。

3. 確かめ方
開示資料で確かめるのか、書面で回答をもらうのか、自社のデータで実演してもらうのか。必須の要件ほど、書面の「対応しています」で済ませず、実演か試行で確かめる。

4. 根拠
どの資料の何ページ、どの回答書の何番、何月何日のデモで確認したか。半年後に「なぜこの製品にしたのか」を聞かれたときに答えられる形にする。

5. 結果
必須は満たすか満たさないかの二択で書く。推奨以下は点数をつける。

この表で一番大事なのは、必須の合否と、推奨以下の点数を混ぜないことである。必須を一つでも満たさない製品は、点数がいくら高くても候補から外す。点数の合計で選ぶと、必須を欠いた製品が「便利な機能」の点数で上に来ることがある。点数のつけ方は、ガイドが言うように、判断基準をもとに総合得点を機械的に計算するか、関係者が集まって評価するかを先に決めておく^[1]。

費用は評価表とは別の表にする。機能の点数と費用を同じ表で足し引きすると、安いが必須を欠く製品の扱いがぶれる。費用と効果を稟議でどう説明するかは購買システム導入の稟議で、費用と効果をどう説明するかで、書面では判定しきれない要件を試しに使って確かめる手順は購買システムを試しに入れるとき、どの範囲で何を測るかで扱う。

要件づくりで起きやすい不備

今の表計算の機能を全部「必須」にしてしまう

表計算での運用は、担当者が何年もかけて自分の仕事に合わせて作り込んだものである。その機能を一つずつ要件にすると、必須が膨らみ、既製のサービスはどれも当てはまらなくなる。表計算でやっていることは、目的に戻してから要件にする。「この列は何のためにあるのか」を聞くと、半分ほどは誰も使っていないことが分かることもある。

取引先の側の要件が抜ける

購買システムは、社内だけでなく取引先にも使ってもらう道具である。それなのに、取引先の担当者に話を聞かずに要件を作ると、取引先がどの手段で回答できるか、何を負担するかが要件に入らない。取引先側の確認項目（利用者登録の要否・費用負担・システムを使えない取引先の扱い）は、受発注システムの選び方で挙げたものをそのまま要件の一覧に入れておけばよい。

数字が入っていない

「大量のデータ」「多数の利用者」「速やかに」と書いた要件は、事業者ごとに解釈が変わる。今の発注件数、取引先の数、利用する人数、同時に使う人数のおおよその値を数えて書いておく。数字は将来の増加も含めて書くとよいが、根拠を一行添えておくと、後で見直しがしやすい。

運用の要件を誰も書かない

止まったときに誰が気づき、誰が事業者に連絡し、その間の発注をどうするか。利用者が入社・異動・退職したとき、誰がアカウントを作り、消すか。こうした運用の要件は、購買部門からも事業者からも出てこない。アカウントの発行と削除の回し方は購買システムのアカウントをどう回すかで扱う。

よくある質問

要件定義書を作るほどの規模ではありません。それでも必要ですか

立派な文書である必要はない。この記事の評価表、つまり要件の文と区分と確かめ方と結果を 1 行ずつ並べた表が一枚あれば足りる。必要なのは、事業者の答えを同じ物差しで比べられることと、後で選んだ理由を説明できることである。

事業者の提案資料にある機能一覧を、そのまま要件にしてはいけませんか

その事業者の製品に合わせた要件になり、他の製品と比べられなくなる。先に自社の要件を作り、事業者の機能一覧はそれに当てはめる材料として使う。機能一覧にないが自社には必須の要件が見つかれば、それが一番大事な比較の軸になる。

非機能の要件まで、情報システム部門だけで決めてよいですか

項目の洗い出しは情報システム部門が行い、水準は購買部門と一緒に決める。年間に何時間止まったら困るか、何日前の状態に戻ることを受け入れられるかは、業務を知っている側にしか判断できない。非機能要求グレードの 3 つのモデルシステムの表を見せて、どの列に近いかを聞くと話が早い^[2]。

まとめ

購買部門の要望は、そのままでは選定に使えない。業務の流れに戻して、どこで誰が何に困っているかを特定し、手段の形の要望は目的に戻し、誰が読んでも判定が一つに決まる文に書き直す。非機能の要件は、クラウドの購買システムでは事業者が開示している水準から選ぶ形で書き、開示を求める項目は公的な指針にそろえる。要件は必須と推奨以下に分け、必須は法令、業務の停止、後から変えられないものに絞る。評価表では、必須は合否、推奨以下は点数で付け、両者を混ぜない。こうして作った表が、選んだ理由をあとで説明するための記録になる。

出典・参考資料

1. ユーザのための要件定義ガイド 第 2 版 要件定義を成功に導く 128 の勘どころ（独立行政法人情報処理推進機構 社会基盤センター／2019 年 12 月 第 2 版第 1 刷・2021 年 11 月 第 2 刷）
2. 非機能要求グレード 2018 利用ガイド［解説編］（独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター／2018 年 4 月）
3. ASP・SaaS の安全・信頼性に係る情報開示指針（ASP・SaaS 編）第 3 版（総務省／令和 4 年 10 月）
4. 中小企業のためのクラウドサービス安全利用の手引き（独立行政法人情報処理推進機構／中小企業の情報セキュリティ対策ガイドライン 第 4.0 版 付録 7・2026 年 6 月 Version 2.3）
5. 電子帳簿保存法 電子取引データの保存方法をご確認ください【令和 6 年 1 月以降用】（国税庁／令和 5 年 7 月）
6. 中小受託取引適正化法テキスト「下請法」から「取適法」へ（公正取引委員会・中小企業庁／令和 7 年 11 月）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで