システム開発の外注で失敗する5つのパターン ── 発注側で防げるもの

「前に一度、外注して失敗しているんです」。初回のお打ち合わせで、そう切り出されることがあります。何があったのかを聞いていくと、開発会社の腕が悪かったという話は思ったより少ない。多いのは、発注した側の社内で決まっていなかったことが、開発の途中やリリースのあとで表に出てきた、という話です。

どの会社に頼むかは開発会社の選び方に、打ち合わせで聞く5つの質問として書きました。この記事はその前後の話です。相手がどの会社であっても起きて、発注側の判断で防げる失敗を5つに分けます。それぞれ、起きる場面と、いつ何を決めておけば防げるかをセットにしました。

1. 作るものを決めずに、見積もりを取る

「受発注をシステムにしたいので、見積もりをください」。この一文で3社に頼むと、3社はそれぞれ自分で前提を置いて見積もります。取引先にも画面を使ってもらうのか、請求まで含めるのか、過去の注文も移すのか。書いていないことは、相手が想像で埋めます。

困るのは、いちばん安い見積もりが、たいてい「いちばん狭く想像した会社」の金額だということです。その会社と契約して、最初の打ち合わせで自社の業務を説明すると、想像の外にあったものが次々に出てくる。そこで「それは見積もりに入っていません」となり、追加の見積もりが積み上がっていきます。開発会社が不誠実だったわけではありません。範囲を決めたのが発注側ではなかった、というだけです。

防ぎ方は、見積もりを頼む前にA4の紙1枚に3つだけ書くことです。困っている業務を1つ、使う人の役割、今回は作らないもの。仕様書は要りません。3つ目の「作らないもの」が書いてあるだけで、各社の想像の幅はかなり狭まります。

2. 最初から全部入れる

「稟議を何度も通すのは大変なので、一度で全部入れておきたい」。受注も在庫も請求も、ついでに取引先向けの画面も。気持ちはよく分かります。

ただ、範囲が広がると開発期間が延び、全部が揃うまで誰も使えません。半年かけてようやく出したときには、最初に決めた前提のいくつかがすでに変わっています。全部を同時に使い始めた現場は、どれにも慣れないまま元のやり方に戻りやすい。社内の説明を1回で済ませたかったはずが、作り直しの説明を何度もすることになります。

防ぎ方は、最初に入れる業務を1つに絞り、2つ目に着手する条件を先に決めておくことです。「受注が画面で回り、FAXの注文を手で打ち直す件数が月に数件まで減ったら、在庫に着手する」のように。条件が書いてあれば、稟議で「残りはいつやるのか」と聞かれても答えられます。私たちのライトプランを1業務フロー・10画面までにしているのも、この考え方からです。どの業務を先にするかの選び方は最初の8週間にどれを入れるかに書きました。

3. 窓口と、決める人が決まっていない

開発会社からの質問メールが、総務の担当者と営業部長と社長の3人に同時に届く。返事はばらばらに来て、内容が食い違う。これがひとつ目の場面です。

もうひとつは、もっと重いものです。窓口の担当者とは毎週の確認で合意を重ねてきたのに、6週目に初めて画面を見た社長が「これは違う」と言う。6週間分の合意が、その場でひっくり返ります。

防ぎ方は、窓口を1人と、最終的に決める人を1人、契約の前に名前で決めておくことです。同じ人でなくて構いません。大事なのは、決める人が途中からではなく、最初の画面構成のラフの段階で一度見ることです。社長が忙しいなら、ラフを見る30分だけ取ってもらう。そこで一度見ていれば、6週目の「これは違う」はほとんど起きません。窓口の方にどれくらいの時間がかかるかは発注したあと、自分たちは何をするのかに週ごとの目安を出しています。窓口を任された人が契約の前に何をしておくかは、社内システムの発注担当になったらに書きました。

4. 現場を入れずに決める

社長と管理部門で要件を決めて、現場の人が画面を初めて見るのはリリースの日。この順番で進むと、現場が実際にやっている例外の処理や、手元のメモで回していたことが画面にありません。入力の手間だけが増えて、半年後には紙とExcelに戻っている、ということが起きます。使われなくなる原因と、開発のどの週で防ぐかは作ったのに使われないシステムになる原因に5つに分けて書いたので、ここでは発注側が決めることだけを書きます。

決めるのは、現場から確認の場に出てもらう人を1人と、その人の時間です。週に1時間で足ります。「忙しくて出られない」が起きるのは、たいていその人の業務量がそのままになっているからです。誰かに仕事を少し寄せて、確認の1時間を業務として扱う。これは開発会社からはお願いしかできず、決められるのは発注側の上司だけです。

5. リリースのあとを決めていない

見積もりは「開発一式」で、リリース後の話は契約に書いていない。3ヶ月後に「この項目を一覧に出したい」と頼むと、別見積もりで2週間待ち。作った担当者はもう別の案件に移っている。社内でも、新しく入った人のアカウントを誰が作るのか決まっていない。小さな不便が直されないまま積もり、使われなくなっていきます。

防ぐには、発注の段階で2つ決めます。ひとつは開発会社側の扱いで、リリース後12ヶ月の費用、誰が対応するか、小さな変更をどう頼むか。これを見積もりの比較に最初から入れます。もうひとつは社内側で、アカウントの追加と停止をする人、使い方の質問を受ける人、改善の要望を集めて月に1回まとめて伝える人です。

私たちはリリース後12ヶ月の月額での改善と、月1回30分の定例をセットにしていますが、これはこの5つ目を契約の形で先に決めておくためです。リリース後に毎月何にお金がかかるかは運用・保守の中身を項目ごとにに分けて書きました。

5つを、いつ決めるか

5つを並べ直すと、共通点があります。表に出る時期と、防ぐために決める時期がずれていることです。

パターン	表に出る時期	決めておく時期	決める人
1. 作るものを決めずに見積もり	契約後の最初の打ち合わせ	見積もりを頼む前	発注の担当者
2. 最初から全部入れる	リリースが延びたとき	見積もりを頼む前	決裁者
3. 窓口と決める人が曖昧	開発の中盤	契約の前	決裁者
4. 現場を入れずに決める	リリース後1〜3ヶ月	契約の前	現場の上司
5. リリース後を決めていない	リリース後3ヶ月ごろ	見積もりを比べるとき	担当者と決裁者

失敗が見えるのは、どれも契約のあとです。そのときにはもうお金も時間も使い始めていて、直すには何かを捨てることになります。一方で、防ぐための判断はどれも契約の前にあって、そこでは紙1枚と30分の打ち合わせで済みます。

発注側では防げない失敗もある

公平のために書いておくと、発注側の段取りでは防げない失敗もあります。開発会社の技術が足りない、担当者が途中でいなくなる、会社そのものが続かなくなる。これは選ぶ段階で見る話なので、冒頭に挙げた選び方の記事に譲ります。

ただ、5つのうちどれかが空白のまま始まった案件は、どの会社に頼んでも同じところでつまずきやすい、というのが私たちの見方です。開発会社を替えても、決めていないことは発注側に残るからです。

初回のお打ち合わせ（60分・オンライン可）では、この5つのうち決まっていないものがあれば、その場で一緒に整理します。そのうえで3営業日以内に画面構成のラフとお見積りをお出しし、ここまで費用はいただきません。決める人や現場の担当がどうしても決まらないなら、開始をずらすことをおすすめします。そのほうが、8週間を無駄にしません。