システム開発の丸投げが失敗する理由。発注者に残る3つの仕事

見積書に合意し、希望する機能を伝えた後は、完成の連絡を待てばよいと考えがちです。システム開発の丸投げを考える経営者は、開発会社へ専門作業を任せる感覚で発注します。

僕は、実装を外注する選択には賛成です。ただし、誰の業務を変えるか、どの機能を先にするか、何をもって完成と認めるかまで開発会社へ預けてはいけません。

非エンジニアの経営者がコードを書く必要はありません。経営者に残る仕事は、事業上の優先順位を選び、社内の回答を集め、実際の業務で完成を確かめることです。

システム開発の丸投げは、事業の選択者が消えると失敗します

開発会社は、業務を画面やデータへ翻訳し、動くシステムを作る専門家です。一方で、顧客との約束、部門ごとの困り事、使える予算の優先順位までは自動で分かりません。

説明用に、受発注システムを作る場面を考えます。営業部門は早い公開を求め、経理部門は例外的な請求処理を求め、管理部門は利用者ごとの閲覧範囲を狭めたいと伝えます。全要望を同じ日までに作れない場合、開発会社は案を出せても、守る業務を単独では選べません。

発注者が「最適な形でお願いします」と返すと、開発会社は技術上作りやすい案や、見積もりの範囲に収まる案を選びます。発注者が期待した顧客対応や社内運用と、完成した機能がずれる余地が生まれます。

丸投げが危険なのは、開発会社の能力が低いからとは限りません。追加費用を承認できる人が会議にいない、現行業務の資料を開ける人が決まっていない、質問の回答日がない、受入を行う部署が参加していない、といった進め方でも案件は止まります。

開発会社にも役目があります。曖昧な依頼を黙って実装せず、未決の項目を示し、複数案と費用・日程への影響を説明し、確認方法を提案する役目です。発注側の準備不足だけで片付ける開発会社も選ばないほうがよいです。

IPAの「ユーザのための要件定義ガイド 第2版」は、ITベンダーやシステム部門だけで進めず、業務部門の利用者が要件定義へ主体的に関わる必要性を説明しています。対象は要件定義であり、外注案件の失敗率を測った統計ではありません。発注者が参加する場面を確認する実務資料として参照できます。

開発会社へ広い作業範囲を任せることは可能です。事業上の選択者、社内情報を渡す窓口、完成を認める人まで消す進め方は成立しません。

システム開発を外注しても、発注者に三つの仕事が残ります

一つ目は、変える業務と見送る範囲を決める仕事です。「受発注を効率化したい」だけでは、開発会社は利用者も到達点も選べません。誰が、どの画面から作業を始め、どの状態まで進められれば投資する意味があるのかを発注側が示します。

経営者は、ボタンの位置やデータベースの設計まで決めなくて構いません。予算と公開日が衝突した時に、対象機能を狭めるか、日程を動かすかを選びます。経営者が進める要件定義のやり方では、作る機能より先に見送る範囲を決める方法を詳しく書きました。

二つ目は、開発中の質問へ期限内に答える仕事です。課題管理ツールで「発注者回答待ち」の項目を開き、回答者、回答日、選択肢、推奨案、費用と公開日への影響を同じページへ置きます。追加費用を承認できない担当者を窓口にする場合は、最終承認者へ上げる条件も決めます。

返答は「社内で確認します」で止めません。採用した案、見送った案、選んだ理由を日付と一緒に残します。後から参加した社員や別の開発会社も、過去の決定を同じ理由で議論し直さずに済みます。

三つ目は、実際の業務で完成を認める仕事です。開発会社が用意したデモだけでは、日常業務に含まれる入力間違い、担当者不在、重複データ、閲覧範囲の違いを見落とします。発注側が実際に近いデータを用意し、誰がどの環境で操作し、何が表示されたら合格かを決めます。

受入で見つかった差は、不具合なのか、未決だった要件なのか、後から加わった要望なのかを分けます。見積書、要件一覧、変更履歴、受入手順を横に並べると、費用を開発会社が負担すべきだと決めつける前に、どの合意が抜けたかを確認できます。開発会社を変更する前に契約と成果物を棚卸しする手順も、案件を立て直す際に使えます。

経営者が毎日の開発会議へ出る必要はありません。現場の業務を知り、決められた金額や範囲なら承認できる事業責任者を置きます。経営者へ上げる論点は、顧客への影響、追加費用、公開日の変更を伴う項目へ絞れば、参加時間を減らせます。

システム開発の丸投げを止める役は、開発会社と別に置けます

社内に技術案を評価できる人がいない場合、事業責任者だけでは開発会社の提案を選べない場面があります。認証方式、データ移行、障害時の復旧、運用費の違いを説明されても、顧客や社内業務への影響へ置き換えられないからです。

CTO代行へ任せられるのは、提案書、見積書、設計資料、課題一覧、テスト結果を読み、経営者が選べる案へ整える仕事です。推奨案だけでなく、採用しない案、想定される危険、費用と公開日への影響まで一枚へまとめてもらいます。

CTO代行は、経営者の代わりに顧客との約束を決める役ではありません。技術面から選択肢を評価し、事業上の選択に必要な材料を作ります。経営者は、許容できる売上への影響、動かせる公開日、優先する顧客を最終的に選びます。

進行管理を外注するだけで足りる案件もあります。設計を評価する社員がいて、回答の遅れだけが問題なら、外部PMに課題と期限を追ってもらえます。技術案の評価者が空席なら、技術顧問とCTO代行の役割分担も確認し、助言する人、進行役、技術判断の実行責任を持つ人を分けてください。

外部の技術責任者には、必要な資料を会社管理の場所で開けるようにします。ソースコード、クラウド設定、設計資料、課題管理ツールへ役割に合うアクセスを用意し、個人アカウントや開発会社だけが管理する場所へ判断記録を残しません。

依頼内容も「技術支援」だけでは足りません。重要な設計案へコメントする、追加見積もりの前提を確認する、受入手順を現場担当者と読む、経営会議へ選択肢を提出する、と成果物まで書きます。会議回数ではなく、未決項目に選択肢と回答日が付き、受入条件を同じ操作で再現できるかを見ます。

次の定例では、未回答の一件を決め切ります

次の定例会議では、案件全体を反省する資料を作らなくて構いません。提案書と見積書、課題管理ツール、最新のデモ環境を開きます。公開に必要で、発注側の返答を最も長く待っている一件を選びます。

提案書と見積書では、対象の利用者、変える業務、対象外、公開日の前提を読みます。課題管理ツールでは、開発会社が出した選択肢、推奨案、追加費用、公開日への影響を確認します。情報がなければ、開発会社へ同じページへの追記を求めます。

発注側は、最終承認者と回答日を決めます。現場担当者だけでは選べない場合、経営者へ上げる日時まで入れます。技術上の危険を比較できる人がいなければ、実装を先へ進める前に外部の技術責任者へ資料を読んでもらいます。

デモ環境では、実際に近いデータを一件だけ入れます。通常の操作に加え、入力を間違えた場合と担当者に権限がない場合も試します。期待する表示、実際の表示、合否を決める人を受入手順へ残します。

発注側が期限内に答えているのに、開発会社が選択肢や危険を示さない場合は、開発会社の進め方を見直す材料になります。開発会社が選択肢を出しているのに承認者が空欄なら、会社を替える前に発注側の担当を決めます。成果物が開発会社の管理場所にしかない場合は、追加開発より先に会社管理の保管先へ移します。

丸投げをやめるために、経営者が設計者になる必要はありません。明日、未回答の一件へ承認者と回答日を付け、最新のデモを実際に近いデータで操作してください。一件を決め切れる体制が作れたら、実装を現在の開発会社へ任せ続けるか、技術責任者を補うか、開発会社を見直すかを選べます。