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

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

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

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

私たちもシステム開発を行う会社だったため、進め方と成果物に問題があると判断し、具体的に指摘できました。もし発注側に技術を評価できる人がいなければ、何が問題なのか分からないまま、出来上がったものを受け入れていたかもしれません。

システム開発の外注で危険なのは、実装を任せることではありません。自社にとって何が正しいかという判断まで手放すことです。

外注するときにも社内へ残す判断は、次の3つです。

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

丸投げすると、開発会社の解釈でシステムが作られる

システム開発を初めて外注するとき、「実現したいことを伝えれば、専門家が適切なシステムにしてくれる」と考えるかもしれません。

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

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

その状態で開発を始めれば、不足している情報を開発会社が何らかの解釈で補います。その解釈が、発注側の考えていたものと一致する保証はありません。

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

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

「自分たちには分からないから、専門家である相手を信じるしかない」。この状態が、システム開発の丸投げです。

最初に決めるのは、機能ではなく解決したい業務

最初に機能一覧を作る必要はありません。先に明確にするのは、どの業務上の問題を解決したいかです。

私は次の順番で問題を掘り下げます。

1. 現在、誰がどの業務で困っているのか
2. その業務は、なぜ必要なのか
3. 業務フロー自体を変えれば解決できないか
4. 人の運用や既存ツールでは足りず、本当にシステム化が必要か
5. 作る場合、最初に必要な範囲はどこまでか

この順番で考えると、当初想像していたシステムとは違う結論になることがあります。

新しいシステムを作らず、不要な承認を一つ減らすだけで解決するかもしれません。すでにあるSaaSを導入すれば十分な場合もあります。

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

作るものと同時に、作らないものも社内で決めます。

優先順位と予算は、発注側が最終判断する

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

そのたびに、次のような判断が発生します。

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

ここで「最適なものをお願いします」と開発会社へ任せても、会社にとっての最適解は決まりません。

開発会社は、工数や技術上のリスクを説明できます。どの業務や顧客を優先するかは、発注側にしか決められません。

意思決定者がいないと、声の大きい人の要望から作られたり、判断が止まるたびに納期が延びたりします。開発会社と相談しながら決めても構いませんが、最後に決める人は発注側に必要です。

品質を開発会社だけに判断させない

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

実際の業務で使えるか。解決したかった問題が改善されるか。今後も変更と運用を続けられるか。発注時に合意した内容を満たしているか。

こうした観点から、成果物を受け入れてよいか判断します。

私が発注者として経験した案件では、開発会社が仕様の曖昧な点を十分に確認せず、独自の解釈で開発を進めていました。PMやエンジニアの能力不足も重なり、期待とはまったく違うものが出てきました。

発注側にも技術者がいたため、何が問題かを説明できました。そうでなければ、「システムの専門家が作ったのだから、これで正しいのだろう」と受け入れていた可能性があります。

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

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

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

仕様書を書く前に、発注側の考えを一枚にまとめる

外注前から、詳細な仕様書を完璧に作る必要はありません。

業務上の問題を整理しないまま画面や機能を細かく決めると、必要のないシステムを正確に作ってしまうことがあります。

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

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

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

良いシステムを作るには、最初の要望をそのまま形にするより、解決したい業務を掘り下げるほうが先です。業務フローから見直し、システム化が適切かを考えたうえで開発へ進みます。

IT担当者がいなくても、判断する役割は置ける

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

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

開発会社の窓口を決めるだけでなく、次の役割を明確にします。

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

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

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

シニアエンジニアや技術責任者を採用するのが難しい場合は、エンジニアを採用できない会社が、採用前に整理すべき3つのことで、外部人材と採用可能な層を組み合わせる方法を紹介しています。

技術顧問が担える範囲は、技術顧問とは？エンジニア採用に悩む会社で担う役割と依頼できることにまとめました。

外注を成功させるには、開発会社と一緒に判断する

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

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

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

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

実装は外注できます。しかし、自社にとって何が正しいかという責任までは外注できません。

発注側が3つの判断を引き受け、開発会社と一緒に問題を掘り下げる。その関係を作ることが、目的に合ったシステム開発の出発点になります。