システム開発を外注に丸投げしないために｜社内に残すべき3つの判断

社内にIT担当者やエンジニアがいない会社にとって、システム開発の外注は現実的な選択肢です。必要な技術者をすぐに採用できなくても、専門の会社へ依頼すれば開発を始められます。

ただし、開発作業を外へ任せることと、システムに関する判断をすべて任せることは同じではありません。

私は発注者の立場で、開発会社がこちらの意図を十分に理解しないまま開発を進めた結果、期待とはまったく異なる成果物が出てきた経験があります。仕様の曖昧な点を確認せず、開発会社側のPMやエンジニアが独自の解釈で進めてしまったことが原因でした。

私たち自身もシステム開発を行う会社だったため、その進め方と成果物に問題があると判断し、具体的に指摘できました。

しかし、発注側に技術的な判断ができる人がいなければ、何が問題なのかさえ分からないまま、出来上がったものを受け入れることになったかもしれません。

システム開発の外注で本当に危険なのは、実装を任せることではなく、判断まで手放してしまうことです。

この記事では、外注先へ開発を依頼するときにも社内に残すべき判断を、次の3つに分けて整理します。

何を作るか・何を作らないか
優先順位と予算をどう決めるか
成果物の品質を誰が判断するか

システム開発の外注を丸投げすると失敗する理由

システム開発を初めて外注するとき、発注側は「実現したいことを伝えれば、開発会社が適切なシステムにしてくれる」と考えがちです。

ところが、発注時に使われる言葉には多くの曖昧さがあります。

例えば「申請業務を効率化したい」という要望だけでは、誰が、いつ、何を申請し、どこで確認に時間がかかっているのかは分かりません。現在の業務フローをそのままシステム化したいのか、業務の進め方自体を変えてよいのかも不明です。

この状態で開発を始めると、開発会社は不足している情報を何らかの解釈で補うことになります。その解釈が発注側の想定と一致する保証はありません。

さらに、開発会社のPMやエンジニアにも能力差があります。業務上の目的まで掘り下げて提案できる人もいれば、伝えられた言葉をそのまま機能へ置き換える人もいます。

発注側に評価できる人がいないと、仕様の認識違いなのか、開発会社の能力不足なのか、そもそも依頼内容に問題があったのかを切り分けられません。

この「分からないので、相手が正しいと信じるしかない」という状態が、システム開発の丸投げです。

社内に残すべき3つの判断

1. 何を作るか・何を作らないか

最初に決めるべきなのは機能の一覧ではありません。どの業務上の問題を解決したいのかです。

私は、次の順番で問題を掘り下げることが重要だと考えています。

現在、誰がどの業務で困っているのか
その業務は、なぜ必要なのか
業務フロー自体を変えることで解決できないか
人の運用や既存ツールではなく、システム化することが適切か
システムを作るなら、最初に必要な範囲はどこまでか

この順番で考えると、最初に想像していたシステムとは異なる結論になることがあります。新しいシステムを作るのではなく、不要な承認を一つ減らすだけで解決するかもしれません。既存のSaaSを導入すれば十分な場合もあります。

開発会社は技術的な実現方法を提案できます。しかし、その業務が本当に必要か、会社として何を変えられるかを決められるのは発注側です。

作るものだけでなく、作らないものを決める責任も社内に残す必要があります。

2. 優先順位と予算をどう決めるか

システム開発では、欲しい機能をすべて同時に実現できるとは限りません。予算と時間には限りがあり、開発中に新しい要望が見つかることもあります。

そのたびに必要になるのが、次のような判断です。

売上や業務への影響が大きいのはどの機能か
最初のリリースに必要な範囲はどこまでか
何を後回しにするか
追加費用を受け入れるか、範囲を減らすか
期限と品質のどちらを優先するか

ここで「最適なものをお願いします」と開発会社へ任せても、会社にとっての最適解は決まりません。開発会社は工数や技術的なリスクを説明できますが、どの業務や顧客を優先するかは決められないからです。

優先順位と予算を決める人が不在だと、声の大きい人の要望から作られたり、判断が止まるたびに納期が延びたりします。

開発会社へ相談しながら決めることはできますが、最終的な意思決定者は発注側に必要です。

3. 成果物の品質を誰が判断するか

画面が表示され、ボタンを押せるだけでは、目的に合ったシステムが完成したとはいえません。

実際の業務で使えるか。解決したかった問題が改善されるか。今後の変更や運用を続けられるか。発注時に合意した内容を満たしているか。こうした観点から受け入れてよい成果物かを判断する必要があります。

私が発注者として経験したケースでは、開発会社が仕様の曖昧な点を十分に確認せず、独自の解釈で開発を進めていました。PMやエンジニアの能力不足も重なり、期待とはまったく異なる成果物が出てきました。発注側にも技術者がいたため問題を指摘できましたが、そうでなければ「システムの専門家が作ったのだから、これで正しいのだろう」と受け入れてしまう可能性があります。

開発を担当した会社だけに品質判断を任せると、作った側と評価する側が同じになります。少なくとも発注側には、業務上の目的を満たしているかを確認する責任者が必要です。

社内に技術を評価できる人がいない場合は、開発会社とは別に、外部の技術責任者や技術顧問へ設計や成果物の確認を依頼する方法もあります。

分からないこと自体が問題なのではありません。分からないまま受け入れる体制にすることが問題です。

発注前に、仕様書より先に整理したいこと

外注前から詳細な仕様書を完璧に作る必要はありません。むしろ、業務上の問題を十分に整理しないまま画面や機能を細かく決めると、必要のないシステムを正確に作ってしまうことがあります。

最初は、次の内容を一枚程度にまとめるところから始めれば十分です。

解決したい業務上の問題
現在の業務フローと、困っている人
システム導入後にどう変わってほしいか
必ず守りたい期限や条件
想定している予算の範囲
社内で判断する責任者
技術や品質を評価できる人の有無

この情報をもとに開発会社と話し、相手が機能の話へすぐ進むのか、それとも業務の背景や「そもそも作る必要があるのか」まで質問するのかを確認します。

良いシステムを作るためには、最初の要望をそのまま形にすることより、解決したい業務を掘り下げ、業務フローから見直し、システム化が適切かを考えることが重要です。

IT担当者がいない会社では、誰が判断するのか

社内にエンジニアがいなくても、すべての判断を経営者一人が行う必要はありません。

業務については、その仕事を理解し、変更する権限を持つ人が責任者になります。技術については、外部の技術責任者や技術顧問に補ってもらうことができます。

重要なのは、開発会社の窓口になる人を置くだけでなく、次の役割を明確にすることです。

業務上の目的と、作らないものを決める人
優先順位と予算を決める人
技術的な提案と成果物を評価する人

一人が複数の役割を担っても構いません。しかし、誰も担っていない役割を、暗黙のうちに開発会社へ押しつけてはいけません。

経済産業省のデジタル経済レポートでも、請負・準委任型契約に基づく開発の丸投げから脱却し、事業要件とシステム開発要件をつなぐプロジェクトマネジメント人材を確保する必要性が示されています。

シニアエンジニアや技術責任者を採用するのが難しい場合の考え方は、エンジニアを採用できない会社が、採用の前に整理すべき3つのことでも詳しく書いています。

システム開発の外注は、共同作業である

外注先に専門性を求めることは当然です。発注側が自分で設計やプログラミングをできる必要もありません。

それでも、会社の業務や顧客について最も詳しいのは発注側です。何を変えたいのか、どの問題から解決するのか、完成したものが目的に合っているのかという判断は、外注できません。

システム開発を外注に丸投げしないために、社内に残すべき判断は次の3つです。

何を作るか・何を作らないか
優先順位と予算をどう決めるか
成果物の品質を誰が判断するか

実装は外注できても、自社にとって何が正しいかという判断まで外注することはできません。

この3つの責任を明確にし、開発会社と一緒に問題を掘り下げることが、目的に合ったシステムを作るための出発点になります。

AI-assisted drafting; reviewed and approved by 松崎達朗 (Tatsuro Matsuzaki)