システム開発の丸投げが失敗する理由｜発注側が管理すべき6項目

「専門的なことは分からないので、プロにお任せします」

開発会社を信頼した、誠実な姿勢に見えます。実際、技術的な判断は任せるべきです。

ただし、任せてよいことと、任せてはいけないことがあります。

この線引きを間違えると、完成したシステムが業務に合わない、費用が膨らむ、稼働日に間に合わない、といった問題が起こります。

この記事では、発注側が握っておくべき6つの項目を解説します。関係者の認識合わせについては、経営者・現場・システム会社の認識がズレる理由｜DXの合意形成の進め方をご覧ください。

「丸投げ」とは、何を渡してしまうことか

丸投げという言葉は曖昧なので、具体的に分解します。

項目	任せてよい	自社で持つべき
技術の選定	○ 開発会社の判断でよい	—
画面の作り方	○ 提案を受けて判断する	—
開発の進め方	○ 手法は任せてよい	—
何のために作るか	×	● 自社でしか決められない
誰が決めるか	×	● 社内の決裁は自社の問題
いくらまで出すか	×	● 投資判断そのもの
いつまでに必要か	×	● 業務の都合は自社が知っている
何を作るか	△ 整理は支援を受けられる	● 最終判断は自社
何が起きたら困るか	×	● 業務への影響は自社しか分からない

上の3つを任せるのは、まったく問題ありません。むしろ専門家に任せるべき領域です。

問題になるのは、下の6つまで渡してしまうことです。これらは外部には決められません。

なぜ丸投げすると失敗するのか

開発会社は、あなたの業務を知らない

当たり前のことですが、見落とされがちです。

「この取引先だけ請求書の書式が違う」「繁忙期は件数が3倍になる」「この処理は月末しか使わない」。こうした前提は、聞かれなければ伝わりません。

そして開発会社は、存在を知らないことについては質問できません。

判断が止まると、そこで工程も止まる

開発中には、細かい判断が何十回も発生します。

「この項目は必須にしますか」「削除は誰でもできてよいですか」。こうした質問に答える人が社内にいないと、開発は止まるか、開発会社が推測で決めることになります。

推測で決められた仕様は、たいてい後から直すことになります。

完成してから「違う」と気づく

途中を見ていなければ、確認できるのは完成後です。

その時点での修正は、最も高くつきます。設計段階なら打ち合わせ1回で済んだ変更が、完成後には作り直しになります。

発注側が管理すべき6項目

1｜目的

何のために作るのかを、1文で言える状態にしておきます。

これは判断の基準になります。仕様で迷ったとき、「目的に照らしてどちらか」で決められるようになります。

目的が曖昧だと、判断のたびに「どちらでもいいです」と答えることになり、結果として誰の役にも立たないシステムになります。

2｜責任者

社内で決める人を、明確に1人決めます。

役割	担当	やること
意思決定者	経営者・部門長	予算と優先順位の最終判断
推進担当	実務担当者	日々の窓口、進行管理、社内調整
業務の代表	現場のキーパーソン	仕様の確認、テスト、現場への展開

ここで重要なのは、推進担当の工数を確保することです。

通常業務に上乗せするだけでは、必ず後回しになります。「週に半日はこの仕事に使う」と決め、経営者から周知してください。

3｜予算

開発費だけでなく、総額で把握します。

• 開発費・初期設定費
• 月額利用料・保守費（年額で見る）
• データ移行の費用
• 教育・マニュアル作成の費用
• 社内担当者の時間（人件費として換算する）
• 想定外の変更に備える予備費（1〜2割）

最後の予備費は、必ず取っておいてください。

予算を使い切った状態で追加要望が出ると、必要な変更まで諦めることになります。

4｜スケジュール

稼働日だけでなく、自社側の作業がいつ発生するかを把握します。

時期	自社側の作業	負荷の目安
要件整理	業務の説明、判断、資料提供	重い
設計確認	画面や帳票のレビュー	中
開発中	細かい質問への回答	軽い
テスト	実際の業務データで検証	非常に重い
移行準備	データ整理、マニュアル、教育	重い
稼働直後	問い合わせ対応、不具合報告	重い

見落とされやすいのがテストの負荷です。

ここは開発会社では代われません。実際の業務を知っている人が、実際のデータで試す必要があります。繁忙期と重なると、テストが形だけになり、稼働後に問題が噴出します。

5｜要件

何を作るかの最終判断は、自社が持ちます。

整理作業は支援を受けて構いませんが、「これで業務が回る」と言えるのは自社だけです。

特に管理すべきは、途中で増えた要望の扱いです。追加要望が出たら、その場で次の3つを決めてください。

1. 今回やるか、次回に回すか
2. やる場合、費用と期間はどれだけ増えるか
3. その分、何を削るか

3つ目を決めないと、範囲だけが増えて期日と予算が守れなくなります。

6｜リスク

何が起きたら困るのかは、業務を知っている側にしか分かりません。

リスク	起きたときの影響	備え方
稼働が遅れる	旧システムの契約期限に間に合わない	延長の可否を先に確認しておく
データ移行の失敗	過去の取引履歴が参照できない	移行のテストを事前に行う
現場が使えない	旧方式に戻り、二重運用になる	教育期間とサポート体制を確保する
担当者の退職・異動	経緯を知る人がいなくなる	決定事項を文書に残す
想定より件数が多い	動作が遅くなり業務が滞る	想定件数を明示して設計してもらう

すべてに備える必要はありません。起きる可能性が高いもの、起きたときの影響が大きいものから順に手を打ちます。

進捗はどう確認すればいいか

「順調です」という報告を、どう受け止めるか。ここが難しいところです。

技術的な内容が分からなくても、次の質問はできます。

• 「今どこまで動きますか。見せてもらえますか」（実物が最も正確な進捗）
• 「今、心配なことはありますか」（懸念を早く出してもらう）
• 「こちらで決めていない項目はありますか」（判断待ちを見つける）
• 「予定と比べてどうですか」（遅れの有無を確認する）

特に1つ目が有効です。「進捗70%」という数字より、動いている画面を見るほうが確実です。

月に1回でも実物を見ていれば、大きな認識のズレは防げます。

よくある失敗

推進担当を兼務のまま放置する

最も多い失敗です。

通常業務が忙しくなると、確認や判断が後回しになります。すると開発が止まり、期日が延び、そのぶん費用も増えます。

担当者の時間を確保することは、経営者の仕事です。

安さだけで発注先を決める

見積金額が安い理由は、たいてい説明できます。

範囲が狭い、テストが薄い、保守が含まれない、要件整理の支援がない。安い理由を必ず確認してください。

見積書の見方については、システム開発の見積書、どこを見ればいい？で詳しく解説しています。

議事録を開発会社任せにする

記録を相手だけが持っている状態は、避けたほうが安全です。

認識が食い違ったとき、確認する材料が相手側にしかないことになります。決定事項は自社でも控えておいてください。

稼働後の体制を決めていない

稼働してからが本番なのに、そこから先の話をしていないケースが多くあります。

問い合わせ窓口はどこか、対応時間は何時までか、障害時は誰に連絡するか、追加改修の費用はどう決まるか。契約前に確認すべき項目です。

明日からできる3つのこと

1. 推進担当と、その人が使える時間を決める
   「週に半日」と明示し、経営者から社内へ周知します。
2. 予算に1〜2割の予備費を足す
   想定外の変更に対応できる余地を残します。
3. テストの時期を業務カレンダーと照合する
   繁忙期と重なっていたら、今のうちにずらします。

よくある質問

IT知識がなくても管理できますか？

できます。ここで挙げた6項目は、どれも技術的な知識を必要としません。

目的、責任者、予算、期限、範囲、リスク。これらは他の事業投資と同じ管理項目です。

技術的な判断まで踏み込む必要はありません。

どのくらいの頻度で打ち合わせすべきですか？

開発中は隔週30分から1時間が目安です。

要件を決める時期とテスト期間は、もっと頻度を上げてください。判断待ちで止まる時間が最も無駄になります。

開発会社と揉めたときはどうすればいいですか？

まず、何が合意事項だったのかを記録で確認してください。

多くの場合、どちらかが悪いというより、合意した内容の解釈が食い違っています。記録があれば、事実に基づいて話ができます。

記録がない場合は、そこから先は感情論になりやすく、解決に時間がかかります。

まとめ｜技術は任せ、判断は持つ

• 技術・設計・進め方は任せてよい。目的・体制・予算・期限・範囲・リスクは自社で持つ
• 開発会社は、存在を知らないことについては質問できない
• 推進担当の工数を確保するのは、経営者の仕事
• テストの負荷は代われない。繁忙期と重ねない
• 進捗は数字より、動いている画面で確認する

無事に稼働しても、そこで終わりではありません。

むしろ、良いシステムを作ったのに現場で使われないという問題が、ここから始まります。次回は定着の進め方を扱います。

みんなシステムズでは、プロジェクトの進め方や体制づくりの段階からご相談を承っています。「社内に経験者がいない」という状況でも、進行の支援を含めてお手伝いできますので、お気軽にお問い合わせください。