会計、原価管理、販売管理。長く使ってきたシステムの上に業務が積み重なると、刷新の話が出てきます。二重入力が減らない、データが表計算ファイルに分かれていてAIに渡せない、保守できる人が限られている。理由ははっきりしていても、何から決めればよいかで手が止まることがあります。
ベンダーの比較や提案依頼書(RFP)の作成に進む前に、発注者側で決めておくことがあります。IPA(情報処理推進機構)の「情報処理システム高信頼化教訓集(ITサービス編)」2.2節・教訓G2(p.20〜22)は、「発注者は要件定義に責任を持ってシステム構築にかかわるべし」を教訓に挙げています。同じ箇所の事例では、開発と運用を外部へ委託し、任せる業務が広がるうちに、要件定義や受入れテストでの発注者の役割を果たしきれず、本稼働後に基本的な仕様の漏れが見つかりました(p.20)。
この記事では、刷新を検討し始めた段階で発注者側が揃えておく5つを整理します。
| 決めること | 記入例(架空) | 決まっていないと起きやすいこと |
|---|---|---|
| 対象業務と完了条件 | 月次の締めで、部門別の原価を5営業日目までに確定する | 提案を比べる物差しがなく、受入れの判断ができない |
| 残すデータ | 取引先は販売管理の登録を正とし、旧システムの未使用項目は移さない | 移行の範囲が後から広がり、費用と期間が読めない |
| 人とシステムの分担 | 仕訳の候補はシステムが作り、例外の承認は経理責任者が行う | 稼働後に「誰が確認するのか」が決まらず、手作業が残る |
| 決裁と予算 | 管理本部長が決裁し、来期のIT投資枠から出す | 提案が揃った段階で検討が止まる |
| 本番後の運用担当 | 設定変更は情報システム担当、問い合わせの一次対応は経理担当 | 稼働後の変更をすべて外部に頼ることになる |
表の記入例は説明のために作成した架空のものです。以下、順に見ていきます。
1. 対象業務と、刷新後の完了条件
最初に、刷新で変えたい業務を一つずつ書き出します。「会計システムの刷新」ではなく、「月次の締めで、部門別の原価を確定させるまで」のように、始まりと終わりが分かる単位にします。
業務ごとに、刷新後に何ができれば完了とするかを決めます。締めにかかる日数、手作業で直している項目、確認する人。現状を数字で書けない項目は、刷新の前に一度測ります。完了条件がないままでは、提案を比べる物差しがなく、受入れのときにも判断できません。
2. 残すデータ、移すデータ、捨てるデータ
長く使ったシステムには、今は使っていない項目や、表計算ファイルで補っている情報があります。新しいシステムへ移すもの、参照用に残すもの、移さないものを分けます。
このとき、データの「正」がどこにあるかを決めます。同じ取引先や品目が複数の場所にあるなら、どれを基準にするかを業務の担当者と合意しておきます。後からAIで検索や集計をする場合も、どこが正しい記録かが決まっていることが前提になります。
3. 人とシステムの分担
刷新後に、システムが自動で行う処理と、人が判断する処理を分けます。たとえば「仕訳の候補はシステムが作り、例外の承認は経理責任者が行う」のように、判断する人と、その判断に必要な情報を書いておきます。
AIを使う場合も、どの業務の、どの判断の前に使うかは、この分担が決まってから検討します。製品やモデルを先に選ぶと、業務の側を製品に合わせることになりがちです。AIを業務システムや社内の知識につなぐ考え方は、AIがソフトを使う時代、企業の競争力はどこで決まるのかとCompany Brainとはで解説しています。
4. 決裁者と予算の出所
誰が最終的に決めるのか、予算はどの部門のどの枠から出るのかを、提案を依頼する前に確かめます。決裁者と予算の出所が曖昧なまま進めると、提案が揃った段階で検討が止まることがあります。
あわせて、何を比べて選ぶかも決めます。費用だけでなく、1で決めた完了条件をどう満たすか、2のデータをどう移すか、本番後に誰が支えるか。比べる項目を先に決めておくと、提案ごとに説明の仕方が違っても判断がぶれません。
5. 本番後に運用する担当
稼働した後に、設定の変更、問い合わせへの対応、データの修正を誰が担うかを決めます。ベンダーに任せる範囲と社内に残す範囲を分け、社内の担当者には刷新の検討段階から参加してもらいます。
IPAの「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」(2019年12月発行)は、ユーザ企業で要件定義に従事する人を主な読者として、要件定義の各局面で起きる問題と、その解決の勘どころを対にして説明しています。最初から通読する必要はありませんが、自社で決めていない点を見つける手がかりになります。
次の一手:5つのうち、決まっていないものから
5つのうち、すでに決まっているもの、決まっていないもの、誰に聞けば決まるものに分けてみてください。決まっていないものが多い場合は、全体の刷新計画を作る前に、1つの業務で1〜3を試しに書き出すのが近道です。
Facet BridgeのAIソリューションでは、「“動く試作”で確かめる要件定義・発注支援」として、関係者へのヒアリングと対象業務・必要な機能の整理、要件・発注資料・見積比較の基準・受入基準の作成、開発先選定と発注後の進行・検収支援を行います。基幹システムの刷新が必要な場合は、移行・切替・保守を担う専門体制と対象範囲を具体化します。相談では、5つのうち決まっていないものをお聞かせください。刷新の前に決めることを相談する
出典(2026年11月11日確認)
- IPA(情報処理推進機構)「情報処理システム高信頼化教訓集(ITサービス編)」2.2 発注者の要件定義責任に関する教訓(G2)「発注者は要件定義に責任を持ってシステム構築にかかわるべし」p.20〜22(PDFの1〜3ページ)。事例の問題と原因はp.20 https://www.ipa.go.jp/archive/files/000049529.pdf
- IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」(2019年12月20日発行、IPAのアーカイブに掲載) https://www.ipa.go.jp/archive/publish/tn20191220.html 。想定読者は第2版2刷のp.12(PDFの23ページ) https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf
記事の内容について確かめたいことがあれば、この記事について筆者に質問する
