外部にシステムを発注する際には様々なトラブルが生じます。
自分が直近１年以内に経験した外注先とのトラブルで代表的なものを挙げてみました。
はじめに
自分は以前は受託制作会社で働いており、現在はどちらかと言えば発注側にいます。
そのため発注側、受注側お互いの気持ちがある程度理解できるので受注側・発注側どちらか片方を責めるものではありません。
ビジネスゴールの違い
前提として、受注側と発注側ではwebサイトを制作する際のビジネスゴールが違います。
受注側は、発注側が運営しているサイトに対して興味があるとは限らないし、請け負ったサイトが納品後に収益を上げているかどうかなんて興味はないでしょう。
・受注側(制作会社)のビジネスゴール
制作依頼を請けて対価として制作料を受け取る。
・発注側(事業会社)のビジネスゴール
PDCAを回してサイトの収益性を上げる。
見積もり工数の違い
ビジネスゴールの違いは、見積もりにも現れてきます。外注の見積もり工数は社内エンジニアのそれよりも高くなる傾向にあるようです。
また、外注にその施策を行う意図が知らされていない事も原因だと思います。なぜその実装をするのか分からないまま見積もる為、余計な工数で見積もりが膨れ上がる可能性もあります。外注に発注するときは「なぜそれを作りたいのか？」という背景まで伝えたほうが良いかもしれません。
過去にあった外注とのトラブル事例
(1)とんでもない低品質で結局いちから作り直し
納品物のソースを確認したら以下のようにほとんど画像だった事があります。
更新頻度が高いテキスト部分も全部画像でした…。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>納品物</title>
</head>
<body>
<img src="image.png">
</body>
</html>
上記問題の原因
・発注した外注先のスキル不足、及び制作における意識の低さ。
・短納期・低予算だった可能性。
上記問題の改善案
・受注側と発注側で認識を合わせる。仕様をはっきりさせてから発注する。
・受注側は仕様が不明瞭なところは積極的に確認しにいく。
・そもそも作り直すほど低品質な物が納品されるのであれば、はじめから自社内で対応する。
(2)「出来ます」と言われて発注したら納期直前(当日)に「間に合わない」と言われる
上記問題の原因
・受注側の納期に対する認識の甘さ。
・発注側が正確な仕様を伝えてなくて着手が遅れる。また受注側も仕様を確認しに行かない。
・そもそもできない仕事を引き受けてしまう。
上記問題の改善案
・外注の「出来ます」を100%信用しないようにする。
・発注側も外注の進捗を常に把握しておく。(例 gitのログをみてリモートリポジトリへ全くpushされていない場合は進捗はどうか確認する。)
・納期の○日前までにgitにpushの形跡がなければ自社で巻き取るというようなルールを作る。
・そもそもはじめから自社内で対応する。
(3)運用ルール・コーディングルールを無視した実装
上記問題の原因
外部に制作を発注する場合、サイト全体の制作というよりLPや既存ページの一部改修という依頼が多いかと思います、その際外注がサイト全体の構成やコーディングルールを確認しないままそのページ「だけ」改修すると、他のページが崩れていたり、今後の運用に影響が出るような低品質な納品物を受け取る羽目になります。
上記問題の改善案
・外注側の基本的な意識が低いことが第一の原因ではありますが、発注側の雑な指示が原因の場合もあります。依頼する際に最低限守ってほしいガイドラインを共有すると良いでしょう。
・もし、ルールを共有しても守ってもらえないなら自社で対応した方が良いでしょう。
外部に発注するメリットって？
外部に仕事を発注するメリットは大きく分けると２つあると思います。
１つは、社内にないノウハウを社外の人間に助けてもらうこと。そしてもう１つは社内の人間がやるべきでない作業を外注化することで社内の人間が本来の業務に集中できるようになる事です。
では本来の業務をすべて外注化してしまった場合、どのような弊害が起きるでしょうか？
本来の業務を外注化してしまった場合の弊害
・社内にノウハウが蓄積されなくなる。
・本来やらなくても良い外注の巻取りという仕事に時間を費やすことになる。
・サイト全体がブラックボックス化されていきいざという時に自社内で対応できる人間が少なくなる。
結果として
→ ノウハウが外注先に溜まっていき自社内のエンジニアにスキルが蓄積されなくなる
→ 自社内のエンジニアがコーディングする機会が少なくなりスキルアップしにくくなる
といった弊害が起きます。
外注との理想的な関係とは？
結局どうすれば外注と良好な関係が築けるでしょうか？
そもそも受注側と発注側で理想が異なるので、どこで折り合いをつけるかが重要になると思います。
受注側の理想
・なるべく高単価で、納期に余裕をもって依頼して欲しい。
・仕様はしっかりまとめてから依頼をして欲しい。
受注側の義務
→受注側は、依頼された施策に対して出来るだけ高品質な納品をするのが仕事なので、情報が揃ってなければ発注側に取りに行くことが必須となります。
発注側の理想
・なるべく低単価で、短納期でも対応してくれたら嬉しい。
・仕様が100%まとまってから依頼するのはスケジュール的に難しいので、不明点はヒアリングして欲しい。
できれば提案もして欲しい。
発注側の義務
→発注側は、高品質な納品を期待するのなら、出来るだけ実装に必要な情報なるべく早く外注に提供することが必須になります。
上記の通り、受注側双方が自分の義務を果たしていてば、信頼関係が徐々に構築されていくと思います。
受注側、発注側、片方の努力だけでは外部発注は成功しません。
まとめ
受注側は「仕様を完全に揃えてから依頼してほしい」って思ってるだろうし、発注側ももちろんそうあるべきだと分かっています。だけど諸々の事情があってそれが難しいとしたら、密にやり取りをしていくしかないと思います。
発注側がなんでもかんでも外注へ仕事を振りすぎるのも問題です。
中には外注が見積もり書を作成している間に社内エンジニアだったらリリースまで完了できる案件もあるはずですが、そういう施策も外注化してしまったら却って手間になってしまします。
外注化がどんどん進んでいくと、社内のエンジニアにとってはブラックボックスが増えていき、実装ノウハウがどんどん外に流れていき緊急時の対応も難しくなります。
社内エンジニアがさばききれない実装を外注に手伝ってもらう、または社内にノウハウがない実装を外注にお願いするというのが、外注先との健全な付き合い方かと思います。
（なんだかんだ外注さんには助けられてます…。）