購買システムを試しに入れるとき——範囲・測る値・本番の決め方

試行で確かめるのは「製品」ではなく「入れ方」

購買部門から「受発注のシステムを入れたい」と相談されたとき、情報システムの担当者がまず考えるのは、いきなり全社に広げてよいかどうかである。試しに一部で使ってみるという判断は自然だが、何を確かめるための試行なのかを決めないまま始めると、期間が終わったときに「使えそうだった」「慣れなかった」という感想しか残らない。

試行には似た言葉がいくつかある。情報処理推進機構（IPA）の要件定義のガイドは、概念実証（PoC）を、新たな概念やアイデアの実現可能性を示すために、簡単かつ不完全な状態でもいいので作ってみることと説明し、作ってみるとアイデアが具体化されたり、効果がないことが見えてきたりするとしている^[1]。行政の情報システムについては、デジタル庁の標準ガイドラインが、目標に対する具体的な実現方法が定まっていない場合に、開発規模・期間を限定した試行版を提供し、効果検証を経て実運用に向けた計画を再度立案するといった段階的な進め方（実証実験）を検討するものとしている^[2]。これは政府の情報システムに向けた決まりで、民間の会社に義務があるわけではないが、「規模と期間を限る」「効果を検証してから計画を立て直す」という骨格は民間の試行にもそのまま使える。

ただし、クラウドで提供される購買システムを試す場合、作るものはない。機能はすでにあり、変えられる範囲も事業者が決めている。だから試行で確かめるのは製品が動くかどうかではなく、自社の承認の流れ、品目の持ち方、取引先とのやりとりが、その製品の上で回るかどうかである。機能の過不足を事前に洗い出す作業は購買部門の要望を選定に使える要件に書き直す手順で済ませておき、試行はその要件では判断できなかった部分を実地で見る場として使うと、試行の目的がぶれにくい。

範囲は「部署・品目・取引先」の 3 つで決める

IPA のガイドは、移行計画を考える段階で、利用者全体を対象にして一斉に全機能を切り替えるか、できるだけ機能や利用者を狭めてスモールスタートするかを確認するよう求め、スモールスタートの方が障害発生時の影響を局所化できるとしている^[1]。試行はこのスモールスタートを、本番を決める前に行うものと考えるとよい。狭める軸は、購買の場合は次の 3 つになる。

取引先の選び方は特に偏りやすい。担当者は頼みやすい相手から声をかけるので、試行の取引先はたいてい最も協力的な数社になる。その結果、試行は順調に終わり、本番で残りの取引先に広げた段階で「システムには対応できない」という返事が集まる。電子のやりとりに慣れていない先を最初から入れておけば、本番の前にその返事の中身が分かる。断られたときの線引きは取引先に「システムは使えない」と言われたらで整理しているので、試行の前に読んでおくと声のかけ方を誤らない。

利用者のアカウントも試行の範囲に合わせて絞る。IPA のクラウド利用の手引きは、運用するときの確認ポイントとして、サービスを必要とする人だけに利用者アカウントを作ること、誰にどのような権限を与えるかを決めることを挙げている^[3]。試行だからといって全員に管理者の権限を配ると、権限の設計そのものを試さないまま本番に入ることになる。どの役割に何を許すかは購買システムの権限の設計で扱っている。試行では、そこで決めた権限表を小さな範囲で実際に当ててみる。

期間は締めを 2 回またぐ

購買の業務は月の締めで一巡する。見積を取って発注し、納品を受けて検収し、請求書と突き合わせて支払う。この一巡の後半、つまり検収と請求の照合で問題が出ることが多いのに、試行を 2〜3 週間で区切ると発注までしか見られない。最低でも発注から支払の予定が立つところまでを 1 回は通し、2 回目の締めで 1 回目に直した運用が効いているかを確かめる。だから期間は「締めを 2 回またぐ長さ」を基準にする。

品目の調達期間が長い場合はさらに延ばす。発注から納品まで 2 か月かかる品目を試行に入れたのに、期間が 1 か月しかなければ、その品目は納品と検収を一度も通らない。試行に入れる品目を決めたら、その品目の通常の調達期間を並べ、最も長いものに締め 1 回分を足した長さを期間の下限にする。

期間を決めたら、終わる日に何をするかも決めておく。IPA のガイドは、移行作業の途中に検証ポイントを明確にし、障害対応や切り戻しの手順を検討しておくよう求めている^[1]。試行では、終わる日がこの検証ポイントにあたる。終わる日の時点で本番に進む・延ばす・やめるのどれかを決める会議を先に入れておかないと、試行は惰性で続き、本番でも試行でもない状態が何か月も残る。

同じ取引が 2 か所に残るとき、どちらを残すかを決める

試行の期間中は、同じ取引先とのやりとりが新しいシステムと従来のメールに分かれることがある。取引先が新しい画面に慣れず、念のためメールでも見積書を送ってくる、というのはよく起きる。このとき、どちらを保存すればよいのかを決めておく必要がある。

国税庁の電子帳簿保存法の一問一答は、クラウドサービスで受け取った請求書と同じものが確認のために電子メールでも届いた場合について、同一のものであればいずれか一つの電子取引に係る請求書を保存しておけばよいとしている^[4]。同時に、合理的な理由がないまま規則性なく保存先を散らし、検索のための措置もとらず、整然とした形式で速やかに出力できないような保存方法は認められないとしている^[4]。試行の期間は保存先が 2 つになりやすいので、「試行の範囲の取引はシステムに残ったものを保存し、メールで届いた同じ内容のものは控えとする」のように、どちらを残すかを試行の手順書に書いておく。紙と電子データの両方を受け取った場合については、書面を正本として扱うと取り決めていても電子データに書面を補う情報が含まれていれば両方の保存が要るとされている^[4]。紙と電子が混ざる場面の扱いはFAX・電話の見積依頼と電子帳簿保存法でも触れているので、同じ判断を試行の手順書にも写しておく。

発注の記録も同じである。中小受託取引適正化法（取適法）は、委託事業者に取引の記録の作成と 2 年間の保存を求め、記録すべき事項を別々の書類や電磁的記録に分けて持つ場合はその相互の関係を明らかにするよう求めている^[5]。試行の範囲だけ新しいシステムで発注し、それ以外は従来の帳票で発注していると、記録は 2 か所に分かれる。分かれること自体は禁じられていないが、発注番号のような共通の鍵で突き合わせられる状態にしておく必要がある。記録の持ち方の詳細は発注の記録を 2 年どう残すかにまとめてある。

測る項目を先に決め、導入前の値を数えておく

試行の結果を判断に使えるかどうかは、始める前に決まる。IPA のガイドは、目標を「今はこのくらい（現状値）だが、いつまでに（達成時期）、どのくらいの効果（目標値）を目指すのか」という具体的な時期と指標を持つものとして整理している^[1]。そのうえで、現状値や目標値を測る物差しを「測定尺度」と呼び、間接的でもよいので、定量的に自ら測定可能なものを設定することが重要だとしている^[1]。

購買の試行で「自ら測定可能」というのは、担当者の手元の記録やメールの送受信の時刻から数えられる、という意味になる。アンケートで「便利になったか」を聞くのは補助にとどめ、主には次のような項目を数える。

この表で最も手間がかかるのは導入前の値である。試行が始まってから「前はどうだったか」を思い出そうとしても、記憶は試行の印象に引きずられる。直近 3 か月のメールから拾える項目は、試行を始める前に拾い切っておく。電話の件数のように記録が残っていない項目は、試行の前に 2 週間だけ数える期間を設ける。数え方は導入前と試行中で必ず同じにする。導入前は担当者が数え、試行中はシステムが数える、という組み合わせにすると、数え漏れの差がそのまま改善に見えてしまう。

IPA のクラウド利用の手引きも、選択するときの確認ポイントとして、業務に適したサービスを選定してどのようなメリットがあるかを確認したかを挙げ、確認の観点に業務品質・業務コスト・業務時間短縮を並べている^[3]。上の表はこのうち時間と手戻り（品質）を数えるものである。費用の側は試行では測りにくいので、利用料と社内の作業時間の見積もりを別に用意しておく。測った値を稟議でどう使うかは購買システム導入の稟議で費用と効果をどう説明するかで扱う。試行の値は件数が少ないので、そのまま全社の効果として掛け算せず、「この範囲ではこうだった」という形で添えるのが安全である。

取引先の反応は「使ったか」より「どこで止まったか」を拾う

取引先の反応を試行後のアンケートだけで拾うと、回答してくれるのは協力的な先に偏る。それより、試行の期間中に起きたことを記録しておくほうが確かである。拾うのは次の 4 つでよい。

1. 開いたかどうか。依頼の通知を受け取った取引先が、案内されたページを開いたか。開いていないなら、通知が迷惑メールに入っている、宛先が担当者ではなく代表の窓口になっている、といった入口の問題である。

2. システムで返したか、メールで返したか。開いたのにメールで返してきた先は、画面のどこかで止まっている。止まった箇所を電話で聞けば、たいてい 1〜2 分で答えが返ってくる。

3. 断った理由。見積を辞退した先が理由を書いていれば、それを残す。システムの都合で辞退したのか、案件として受けられないのかを分けて数える。

4. 取引先から来た質問。操作の質問、締めや支払の扱いの質問、紙で欲しいという要望を、内容ごとに分けて残す。

紙で欲しいという要望には、法律上の扱いがある。取適法では、発注の内容を電磁的方法で示した場合でも、相手から書面の交付を求められたときは遅滞なく交付しなければならず、例外は相手が電磁的方法での提供を希望する旨を書面または電磁的方法で申し出た場合などに限られる^[5]。さらにその例外にも、相手の責めに帰すべき理由がないのに画面で閲覧できなくなった場合は除くという但し書きがある^[5]。試行の期間中に紙を求められたら、断らずに出し、そのことを記録に残す。電子で届けるときの考え方は発注はメールで出してよいにまとめてある。

本番に進むか・延ばすか・やめるかは、始める前に書いておく

判断の基準を試行の後に決めると、どんな結果でも「進む」に寄る。費用をかけて準備した試行をやめるのは心理的に難しく、関わった人が多いほど難しくなる。だから基準は試行の前に、測る項目と一緒に書いておく。書き方の例を挙げる。

表の数字は例であり、会社ごとに決めてよい。大事なのは、何がどうなったら進むのかを、試行の結果を見る前に文字にしておくことである。数値で書けない項目、たとえば「承認者が画面に慣れたか」のようなものは、基準ではなく所見として扱う。試行の中で見つかった障害や遅さは、要件として扱うものと運用で吸収するものに分け、前者は選定の要件に戻す。安全面で確かめきれなかった点があれば、クラウドサービスの安全性を選ぶ前にどう確かめるかの項目に戻って確認してから進む。

やめるときに残すもの

試行をやめると決めたとき、システムの中には試行の期間に出した発注、受け取った見積、取引先とのやりとりが残っている。これは試験用のデータではなく、実際の取引の記録である。

まず、データを手元に取り出す。IPA のクラウド利用の手引きは、利用をやめるときに確かめる条件として、データを丸ごと返してもらえるか手元に落とせるか、他で使える形式か、事業者側に残ったデータが消されるかを挙げている^[3]。試行用のアカウントは期間が終わると閉じられる契約になっていることがあるので、終わる日より前に取り出し、取り出した中身で発注番号から取引を辿れるかを確かめておく。解約や乗り換えのときに確かめる点はクラウドの購買システムをやめる・乗り換えるときに困らないためにで詳しく扱う。

次に、取引先の側に残るものを考える。前述のとおり、取適法の上では、発注の内容を電磁的方法で示した相手が、自分の責めではない理由で画面を閲覧できなくなった場合には、書面の交付を求められたら応じる必要がある^[5]。取適法のテキストは、利用していたメッセージ機能のサービスが終了して内容を確認できなくなった例を挙げ、その場合は書面の交付に応じる必要があるとしている^[5]。試行をやめて取引先がそれまでの注文を見られなくなるなら、試行の範囲で出した注文の内容を、取引先が手元に残せる形で渡しておくのが確実である。

最後に、試行の範囲の記録を、従来の記録と突き合わせられる形で保存する。取適法の記録の 2 年や、税務の保存期間は、試行をやめても止まらない。取り出したデータを保存する場所を決め、従来の帳票の側から「この期間のこの取引先の分は試行のデータにある」と辿れるようにしておく。

よくある質問

無料の試用期間で試行を済ませてよいですか

済ませてよいが、試用期間の長さで試行の期間を決めないこと。締めを 2 回またぐ長さが無料の期間に収まらないなら、収まらない分は費用をかけて続けるか、範囲をさらに狭めて品目の調達期間が短いものに絞る。もう一つ、試用期間に入れたデータが期間の終了時にどう扱われるかを、始める前に利用規約で確かめておく。

試行の範囲だけ発注の手順が変わることを、社内規程に書く必要はありますか

発注の方法や承認の手順を規程で定めている会社なら、試行の範囲に限った特例として、対象の部署・期間・手順の違いを書いた文書を残しておく。内部監査や税務の調査で試行の期間の取引を見られたとき、なぜこの部署だけ手順が違うのかを説明できるようにしておくためである。

試行の結果が良くなかった場合、製品を変えればよいのですか

結果が悪かった原因が製品なのか、範囲の選び方や準備なのかを分けてから決める。品目の登録が不十分で検索に時間がかかった、承認の経路を旧のまま持ち込んだ、といった原因なら、製品を変えても同じことが起きる。止まった箇所の記録を一つずつ見て、「別の製品なら起きなかったか」を問い直す。

取引先に試行への協力を頼むとき、何を伝えればよいですか

試行であること、期間、取引先の側でしてほしい操作、困ったときの連絡先、そして従来のやり方（メールや紙）で返してもよいことを伝える。最後の一つを伝えないと、取引先は新しい方式に合わせることを取引の条件と受け取りかねない。相手に負担を求めるときの線引きは前述の記事にある。

まとめ

購買システムの試行で確かめるのは、製品の機能ではなく、自社の業務と取引先がその上で回るかどうかである。範囲は部署・品目・取引先の 3 つで絞り、取引先には協力的でない先も入れる。期間は締めを 2 回またぎ、最も長い調達期間に締め 1 回分を足した長さを下限にする。同じ取引が 2 か所に残る期間は、どちらを保存するかを手順書に書く。測る項目と導入前の値は始める前に揃え、数え方を前後で同じにする。取引先の反応は使ったかどうかではなく、どこで止まったかを拾う。進む・延ばす・やめるの基準は結果を見る前に書き、やめる場合は記録を取り出し、取引先が注文を見られなくなる事態に備えてから止める。

出典・参考資料

1. ユーザのための要件定義ガイド 第 2 版 要件定義を成功に導く 128 の勘どころ（独立行政法人情報処理推進機構（IPA）社会基盤センター／2019 年 12 月）
2. DS-100 デジタル・ガバメント推進標準ガイドライン（デジタル社会推進会議幹事会決定／2026 年 6 月 12 日）
3. 中小企業のための クラウドサービス安全利用の手引き（情報処理推進機構 セキュリティセンター／2026 年 6 月）
4. 電子帳簿保存法一問一答【電子取引関係】（国税庁／令和 7 年 6 月）
5. 中小受託取引適正化法テキスト「下請法」から「取適法」へ（公正取引委員会・中小企業庁／令和 7 年 11 月）

WHITE PAPER

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

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

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