「システム開発の闇」という動画を見ました。
動画では、新たに就任した上場企業の社長から、長年にわたるシステム開発費について相談を受けたという事例が紹介されています。
巨額の費用を支払っているにもかかわらず、出来上がったシステムが費用に見合っているように見えない。同じ技術者の月額費用が途中から何倍にも変わっているのに、開発会社が理由を説明できない。最終的には裁判にまで発展した、という内容です。
この事例が第三者によって検証されたものかは分かりません。しかし、動画が提起している問題そのものは、システム開発を発注する企業にとって非常に重要です。
私は、外注そのものが悪いとは考えていません。
外注してはいけないのは、プログラムを書く作業ではなく、「自社にどのようなシステムが必要なのか」を判断する仕事です。
高いか安いかを判断できないことが、最初の問題である
システム開発の見積額だけを見て、高いか安いかを判断することはできません。
同じような画面に見えても、処理するデータ量、利用人数、権限の複雑さ、セキュリティ、障害対策、既存データの移行、外部サービスとの連携、保守範囲によって費用は大きく変わります。
問題は金額そのものではなく、発注企業が「なぜこの金額になるのか」を説明できない状態です。
技術者一人当たりの費用が変わるのであれば、担当範囲、役割、必要な能力、投入時間などの根拠が必要です。開発期間が延びるのであれば、当初の想定と何が変わったのか、どの変更にどれだけの作業が発生したのかを確認できなければなりません。
人月による見積もりが、直ちに悪いわけではありません。
しかし、支払った人月と、完成した機能、確認できる成果物、解決された課題が結びついていなければ、発注企業は人数と期間に対してお金を払い続けるだけになります。
発注者が「何を作るか」を決めなければ、丸投げになる
システム開発会社は、発注企業の業務を最初から知っているわけではありません。
どの情報が会社にとって重要なのか。誰が入力し、誰が確認し、誰が承認するのか。どの出来事によって請求や在庫や会計が変化するのか。間違えたときに、どこまで元へ戻せなければならないのか。
これらは、発注企業側が決めるべきことです。
専門家へ相談しながら決めることはできます。しかし、判断そのものまで開発会社へ預けてしまえば、開発会社が変わるたびに、会社の業務を最初から説明し直すことになります。
IPAも、システム開発の取引構造を透明化するため、各開発段階におけるユーザー企業とITベンダーの責務、仕様、プロジェクト管理方法、検収方法などについて共通理解を持つことを重視しています。情報システム・モデル取引・契約書
システム開発は、発注書を渡して完成を待つ買い物ではありません。
自社の業務を分解し、開発会社と共同で、機械が処理できる形へ変換していく仕事です。
発注企業が最低限保持すべきもの
開発作業を外部へ委託する場合でも、次のものは発注企業側で把握し、継続して利用できる状態にしておく必要があります。
- システムの目的と対象業務
- 用語の定義とデータ構造
- 権限、承認、変更履歴の設計
- 現在の仕様と未完了事項
- ソースコードとリポジトリへのアクセス
- 本番環境、ドメイン、データベース、外部サービスの管理権限
- 成果物の検収条件
- 著作権、利用許諾、改変、再利用に関する契約
- 他社へ保守や開発を引き継ぐための手順
重要なのは、「資料を納品してもらった」という事実ではありません。
担当する開発会社が明日変わっても、自社の判断で運用と開発を継続できるかどうかです。
この状態を作らないまま特定企業へ依存すると、改修のたびに提示された金額を受け入れるしかなくなります。これは技術的な問題というより、経営上の統治の問題です。
お金を払えば、著作権も自動的に移るわけではない
動画では、外注して作られたプログラムの著作権は、基本的に開発会社側へ帰属するという問題も取り上げられています。
ここは、少し丁寧に整理する必要があります。
著作物の制作を外部へ依頼した場合、制作費を支払ったという理由だけで、著作権が自動的に発注者へ移転するわけではありません。文化庁の資料でも、他社へ制作を委託した場合、実際に創作した受注者側が著作者になることが原則として説明されています。文化庁「著作権制度の概要」
ただし、「外注したプログラムは必ず開発会社のものになる」と断定するのも正確ではありません。
著作権をどちらへ帰属させるのか、発注企業がどの範囲で利用・改変・再委託できるのかは、契約で定められます。既存の共通部品、今回新たに作る部分、オープンソースソフトウェア、第三者製品について、権利関係を分けて確認する必要があります。
経済産業省のモデル契約でも、知的財産権の帰属について、契約締結前の提案・見積段階から条件を説明することが重視されています。経済産業省「情報システム・モデル取引・契約書」
契約書に「成果物一式」と書くだけでは不十分です。
ソースコードを受け取れるのか。自社で修正できるのか。別会社へ保守を依頼できるのか。開発会社が事業を停止した場合にどうするのか。これらを契約前に決める必要があります。
内製化とは、社員だけで全コードを書くことではない
動画では、給与計算ソフトのように市販品を使えばよいものと、自社サービスの根幹として自ら作るべきものが区別されています。
この区別は非常に重要です。
メール、給与計算、一般的な会計処理など、企業間で大きな違いがない部分は、実績のある製品を利用した方が合理的です。
一方で、顧客へ提供するサービス、独自の業務手順、価格決定、承認、会社資産を変化させる処理などは、会社の競争力や責任に直接関係します。この部分の設計を外部へ丸投げしてはいけません。
ただし、内製化とは、すべてのコードを社員だけで書くことではありません。
外部の技術者、税理士、社会保険労務士、中小企業診断士などの知見を取り入れながら開発してもよいのです。大切なのは、会社自身がシステムの目的、構造、判断基準を保持し、外部の専門家を選び直せる状態にすることです。
外部へ任せるのは「手」であり、「脳」ではありません。
動くものを早く見せてもらい、重要な処理は改めて設計する
進捗を「現在70％です」という言葉だけで確認してはいけません。
実際に動く画面、登録されたデータ、実行できる処理、テスト結果を小さな単位で確認する必要があります。試作品を早く作り、利用者から意見を集めれば、発注者側も本当に必要な仕様を発見できます。
受付や業務報告の試作であれば、CMSや表計算サービスから始めても構いません。
しかし、会計、請求、在庫、給与、権限、会社資産を変化させる処理は、試作品の延長で本番化してはいけません。要件を整理し、データモデル、承認、取引の一貫性、変更履歴を改めて設計したうえで、人間が把握できるコードとして実装する必要があります。
試作では、動くものを見ながら仕様を発見する。
本番では、会社が責任を持てる構造へ作り直す。
この境界を管理することも、発注企業側の仕事です。
外注してはいけないのは、経営判断である
システムは、単なる業務効率化の道具ではありません。
誰が、いつ、何を行い、その結果として会社の情報や資産がどう変化するのかを決める仕組みです。言い換えれば、会社の脳や神経に近い存在です。
プログラムを書く作業は外注できます。デザインも、テストも、保守も、専門家へ依頼できます。
しかし、なぜその仕組みが必要なのか、何を正しい状態とするのか、どこまでを自社の責任として管理するのかという判断は外注できません。
システム開発の闇を避ける方法は、すべてを社員だけで作ることではありません。
自社のシステムを、自社の言葉で説明できる状態を保つことです。
会社の手は外部から借りてもよい。
会社の脳まで外部へ渡してはいけないのです。