業務システムの選び方：機能表と実際の業務試行で比較する

たとえば、次のような仮想の選定を考える。業務システムの選定表に、申請、承認、通知、分析などの項目を並べる。営業資料ではどの候補も「対応」に丸が付く。最も点数の高い製品を導入したところ、例外申請だけは紙へ戻り、承認が終わっても会計側へ転記が必要だった。項目の有無は確かめたが、担当者が一件の仕事を完了できるかは試していなかった。点数の差は、実務の差ではなく表の作り方の差だった可能性がある。

百の「対応」のうち、使う機能はいくつか

選択は機能表を捨てるか、試用だけで選ぶかではない。必要な機能の欠落を見つけるには一覧が役立つ。しかし重要な業務結果は、現実に近い場面で試す。特に複数部門へ渡る案件、例外の多い処理、既存のデータとの接続では、画面上にボタンがあることと仕事が終わることを分ける。

公的調達指針は「小さく難しい課題」を勧める

英国政府の技術購入戦略の指針は、製品を買う場合、小規模のデモや試行を検討し、その際に小さいが難しい問題を一つ解く、既存製品との連携や利用体験、アクセシビリティなどを試すと述べる。英国政府の調達文脈での実務指針で、デモをすれば失敗率が何割下がるという比較研究ではない。また、すべての機能を試用で再現せよとも言っていない。

米国GAOの2026年COTS評価ガイド草案は、市販品の購入前に、運用上の必要と、それを確かめる試験要件を整理することを扱う。2026年9月公開の意見募集用草案で、確定版の標準として扱うべきではない。物理的な装置も含む米国連邦政府向けの指針だから、日本企業のSaaS選定へ規則として直接適用はできない。ただし、要求の文と検証方法を結び付ける考え方は、機能表の丸を実際の判断へ変える助けになる。

この二つから編集上は、必須機能の足切りをした後、代表的な一件を候補製品で通す。そこで得た観察を、価格、保守、移行などと合わせて決める。「難しい一件」を選ぶ際も、滅多に起きない異常だけを選ぶと日々の使いやすさが見えなくなる。頻度が高い通常処理と、事業を止める例外処理を分けて試す。

先に成功条件を書く

仮に、店舗からの返品申請システムを選ぶなら、「返品申請機能あり」は成功条件ではない。販売履歴を見つけ、対象外の理由を示し、責任者が例外を判断し、承認結果が会計へ届き、顧客への通知が残る。この一連を、必要な権限と時間内で終えられるかを考える。できない箇所があったら、設定で直るのか、別製品との連携が必要か、業務手順を変えるのかを記録する。

試験に使うデータも吟味する。営業担当が用意した整ったサンプルでは、古い取引番号、重複した顧客、代理申請などの問題が出ない。機密情報をそのまま持ち込まず、実データの形を模した匿名のサンプルと、例外を含む手順を購入側が用意する。候補ごとに異なる課題を与えたら公平な比較ができない。共通課題と採点方法は試行前に決め、後で印象に合わせて変えない。

どの状態なら受け付けるか、誰が例外を判断するかが未決なら、先に具体的な業務場面による要件の合意を確認する。製品側の標準設定を、発注側で決めるはずの方針の代わりにはしない。

公開仕様から、試す場面を選ぶ

「物品購入を申請し、承認済みのデータを経理へ渡す」という仮の業務で、kintoneとZoho Creatorを候補にした場合を考える。以下は2026年10月13日に確認した公開仕様の比較で、実際に設定や操作を試した結果ではない。承認とCSV出力の機能があることから、業務が最後まで成立するとは判断しない。

表は左右にスクロールできます。

比較条件はkintoneのスタンダードコースと、Zoho Creatorのスタンダードプランで一つのアプリを使う場合とする。ただし、無料試用で使える範囲を契約予定プランの範囲と同一視しない。kintoneの試用はスタンダード、Zoho Creatorの試用開始時はプロフェッショナルのため、kintoneのコースとZoho Creatorのプラン別機能を実行前に照合する。Zohoの日本語料金ページは米国データセンターの機能を基にした案内で、日本データセンターでは一部異なる可能性も示している。上の表は、契約予定プランと日本の利用環境での動作を保証するものではない。

発注側は同じ架空の購入申請を使い、通常承認、承認者不在、取戻し後の再申請を試す。画面で誰がいつ処理したかを確認し、承認済みデータのCSVを受け側が必要とする項目・コード・文字形式で取り込めるかまで確かめる。画面の履歴とCSV出力は別の確認で、変更履歴・ステータス履歴・承認履歴・監査証跡も同じものとは扱わない。代理承認の可否、会計ソフトとの直接連携、使いやすさ、試用の成否は、ここでは未検証である。

仮想選定で順位が逆になる

A製品は機能表の項目を多く満たし、B製品は分析画面など一部の項目を持たないとする。返品の一件を試すと、Aは代理申請後の承認記録を会計へ渡せず、手作業が必須になる。Bは一連の処理を標準設定で終え、足りない分析は既存のレポートで補える。返品業務が今回の導入目的なら、機能表の順位を覆してBを選ぶ理由がある。丸の数ではなく、必須の結果を支えるかで判断した例だ。

条件を変えて、会計連携は数か月後に廃止される既存システムとの暫定接続であり、Aは将来の標準基盤へ容易に移行できる。一方Bの構成では長期に個別改修が必要だと確かめられたなら、Aを選ぶ可能性が高まる。ここでは移行計画と総費用を証拠として足す必要がある。「今の一件を早く終える」が唯一の目的ではない。試行は意思決定を豊かにするが、契約や運用を見なくてよい免罪符にはならない。

試行に費用がかかるという反論も正しい。安価で標準化された、取り替えやすい道具なら、すべての候補で詳細な実証をする必要はない。条件に合う候補の絞り込みに機能表を使い、負荷が大きい部分だけを試す。一方、導入後の移行が難しく、複数部門に影響する製品は、買う前の小さな試行に相応の価値がある。試行の費用も選定費用として計上し、無限に検証を続けない。

導入後の評価を選定時から決める

試行で確認した業務の完了率、例外が紙へ戻る回数、後工程の転記、担当者が迷う場面を、導入後にも同じ定義で見る。デモの日だけ訓練された担当者が操作していたら、現場全体で再現するとは限らない。運用担当と現場担当が試行に参加し、なぜ通らなかったかの記録を残す。候補を落とす根拠にも、採用後の改善課題にもなる。

デモで見えない費用を別表にする

試行で確認できなかった移行・教育・障害支援・退出の費用は、初期・運用・変更・終了の時点に分けて比較する。販売側の支援が本番でも必要なら継続費へ含め、「設定でできる」は設定後の結果と費用、「開発すればできる」は未実装として扱う。

必須・加点・失格条件は試験前に決める。頻度が低くても契約上必須の例外は加点へ落とさず、便利なだけの画面を必須にして競争を狭めない。製品を落とす際も、次節の同条件での確認を行う。

製品を落とす理由も検証する

一件の試用で失敗したとき、それが製品の制約か、試行環境の準備不足かを分ける。必要なデータ形式を事前に伝えていない、評価者の権限が足りない、といった問題で候補を排除すれば、選定自体が偏る。同じ条件で再試行できる範囲を設け、結果と理由を残す。一方、毎回特別な開発者の支援が必要な状況を「使える」に数えない。日常の運用でも必要になる支援として費用に入れる。

さらに、試行で良かった候補が必ずしも最安とは限らない。紙への戻りや転記が残る費用、教育に要する時間、解約時のデータ移行費も比較する。ただし効果を恣意的な金額に換算して順位を確定させず、数値化できる費用と判断を要する制約を並べて説明する。

その判断過程も選定記録として残す。

試行で残った差を、手作業で補うか、拡張するか、業務を標準へ合わせるかは、次の判断になる。標準機能と個別対応の比較では、必要な業務結果を保てる案について、使う期間と未計上費用をそろえて考える。

選定の結論

結論として、標準的で交換しやすい製品は、機能表と条件確認で絞れる。業務上の例外や連携が成否を左右する製品は、機能表だけで決めず、小さく難しい代表業務を通す。試行で勝った候補でも維持と移行の費用が大きければ順位は変わる。選ぶべきは「丸が多い製品」ではなく、必要な仕事を持続的に終えられる製品だ。

参照資料

• 英国政府, Define your purchasing strategy
• 米国GAO, Testing and Evaluation Guide: Best Practices for Commercial Off-the-Shelf Systems（意見募集用草案）