受発注をFAXと手書きの台帳で回していて、社長から「そろそろシステムを入れろ」と言われた。ただ、システムを発注したことがないと、そもそも何が手に入るのかが分かりません。システム開発とは何かを調べると、工程や手法の解説が並びますが、頼む側が知りたいのはそこではないはずです。この記事では、発注側にとってシステム開発とは何を買う行為なのか、自分は何をすることになるのか、最初に決めるのは何かを整理します。エンジニアの仕事内容やプログラミング言語の話は出てきません。
この記事のポイント
- 手に入るのは動くシステムと権利と書類の3つ
- お金を払っても発注側に残る作業が必ずある
- 最初に決める分かれ目は買うか作るか内製か外注か小さく試すか
- 最初の一歩は困っていることを1行書くだけでいい
目次
システム開発とは発注側にとって何か
システム開発は、形のないものを買う行為です。車や機械なら現物を見て買えますが、システムは契約した時点では影も形もありません。だから何が手に入るのかを先に知っておく必要があります。
受け取るのは動くシステムだけではない
発注して最終的に手に入るものは、大きく3つあります。
- 動くシステムそのもの
- そのシステムに関する権利
- 書類一式（要件定義書、設計書、テスト結果、運用手順など）
多くの方は1つ目しか意識していません。ところが後で効いてくるのは、残りの2つです。
権利の話から説明します。作ってもらったシステムの著作権が自動的に自社のものになるとは限りません。契約で決めていなければ、作った側に残るのが原則です。権利が相手にあると、別の会社に引き継いで改造してもらうときに許可が要ります。開発会社を替えたくなったときに初めて気づくことが多いところです。
書類も同じです。設計書やテスト結果が揃っていないと、数年後に手を入れようとしたときに、中身を読み解くところから始まります。次の会社はその調査に工数を積むので、書類がないぶんだけ金額に跳ね返ります。契約の時点で「何を納品してもらうか」を一覧にしておくと、この差が出ません。
形のないものを買うという性質は、もうひとつ別の意味も持ちます。完成品を見てから買うかどうか決められない、ということです。家や車なら現物を確かめてから判断できますが、システムは作り始めてからでないと形が見えません。だから途中で確認する機会が要ります。設計の段階で図や画面イメージを見せてもらい、動くものができた段階で実際に触る。この2回の確認を計画に入れておかないと、最後に出てきたものを受け取るしかなくなります。
途中で見せてもらうのは、疑っているからではありません。言葉だけでは伝わらないことが必ずあるからです。「一覧で見たい」と伝えたとき、発注側は50件が1画面に並ぶ絵を想像し、開発会社は10件ずつのページ送りを想像している、といったずれは普通に起きます。早い段階で絵を見れば、その場で直せます。
誰が何をするか
もうひとつの誤解が、お金を払えば全部やってもらえる、というものです。実際には、発注側にしかできない作業が必ず残ります。
開発会社は技術の専門家ですが、自社の業務は知りません。何を作るかを決められるのは発注側だけです。現場の業務がどう回っているかを説明するのも、出てきたものが業務に合っているかを確かめるのも、発注側の役割になります。
| 作業 | 発注側 | 開発会社 |
|---|---|---|
| 何を作るか決める | 決める | 聞き出して形にする |
| 現在の業務の説明 | 説明する | 整理して確認する |
| 設計と開発 | 内容を確認する | 作る |
| 業務に合っているかの確認 | 受け入れテストで確かめる | 環境と手順を用意する |
| 現場に使ってもらう | 周知して定着させる | 操作説明を行う |
表の左側を見て「思ったより多い」と感じたら、それが正しい感覚です。私の経験では、うまくいかないプロジェクトの多くは、この左側を誰も担当していません。担当者を1人決めて、その人の時間を月に何日か空けておくところから始めてください。
時間の目安も書いておきます。要件を決めている期間は、週に半日から1日くらい取られると思っておくと外れません。受け入れテストの時期はもっと集中して、2週間ほど現場の人を巻き込むことになります。本業の合間でこなせる量ではないので、上長にはその前提で話を通しておく必要があります。
ここを軽く見積もると、自社の都合で開発が止まります。開発会社の質問に答えられない、確認の返事が返せない、テストに人が出せない。相手を待たせているあいだも費用と期間は進むので、結果として自社が損をします。
費用と期間の全体像
金額と期間は、作るものの大きさで大きく変わります。ひとつの業務に絞った小さな仕組みなら数百万円で数か月、基幹業務に近い範囲になると数千万円で1年前後、という幅で語られることが多い範囲です。
これはあくまで一般的な目安です。同じ規模でも会社や条件で変わるので、実際の判断は個別の見積もりで確認してください。
いま押さえておきたいのは、幅が広いという事実そのものです。だから「システム開発はいくらですか」という聞き方では答えが返ってきません。何を作るかが決まって初めて金額が出ます。規模や種類ごとの相場感を先に掴みたい場合はシステム開発の費用相場を規模別・種類別に見るが参考になります。
システム開発とは何から始めるものか
何が手に入るのかが分かったら、次は始め方です。いきなり開発会社を探す前に、決めておくと話が早くなることがあります。
最初に決める3つの分かれ目
順番に3つあります。
1つ目は、買うか作るか。既製のサービスで足りるなら、作る必要はありません。2つ目は、作るとして内製か外注か。社内に作れる人がいるかどうかだけでなく、作ったあと誰が面倒を見るかまで含めて考えます。3つ目は、一度に全部作るか、小さく試してから広げるか。
この3つに答えが出ていると、開発会社との最初の打ち合わせがまるで違います。逆にここが白紙のまま相談に行くと、相手も何を提案していいか分からず、一般論のやりとりで終わります。
3つ目の「一度に全部か、小さく試すか」は見落とされがちです。予算が付いたので全部作りたくなりますが、初めての発注では小さく始めるほうが失敗しにくいところがあります。ひとつの業務だけ、ひとつの拠点だけで動かしてみると、自社の判断が正しかったかが数か月で分かります。そこで見えた修正を入れてから広げれば、間違いを全社に配らずに済みます。
どこまでを1回目に入れるかは、頭の中だけで決めようとすると広がりがちです。作りすぎを防ぐMVP開発スコープ決定シートのように、入れるものと入れないものを書き出す枠があると、最初の範囲を絞り込みやすくなります。
2つ目の内製と外注は判断材料が多いので、外注化のメリットと内製か外注かの判断基準で詳しく扱っています。社内の体制から考えたい場合はそちらを見てください。
作らずに済むならそのほうが早い
3つの分かれ目のうち、実は1つ目がいちばん大事です。作らない判断ができるなら、そのほうが安く早く始められます。
線引きの目安は、その業務のやり方が自社の競争力になっているかどうかです。請求書の発行や勤怠の管理は、どの会社でもやり方が似ています。こういう業務は既製のサービスに自社を合わせたほうが合理的です。
逆に、独自の商習慣や、他社が真似できない段取りで回している業務なら、既製品に合わせると強みが消えます。そこは作る価値があります。「うちは特殊だから」と全部を特殊扱いせず、どの業務が本当に特殊なのかを分けてみてください。
分け方のコツは、その業務のやり方をお客さんが評価しているかどうかで見ることです。取引先が「御社は納期の連絡が早い」と言ってくれるなら、その段取りは強みです。一方、社内の誰も理由を説明できない手順は、たいてい昔の事情が残っているだけで、変えても困りません。既製品に寄せる候補はそちらです。
最初の一歩は困っていることを1行書く
ここまで読んで「まず要件定義をしなければ」と思った方がいるかもしれません。そこまで構える必要はありません。
最初にやるのは、困っていることを1行書くことです。「毎月20日に売上の集計で2日つぶれている」「受注のFAXを転記していて月に何件か間違える」。この程度で十分です。
この1行があると、開発会社との会話が始まります。無いまま相談に行くと「ご要望をお聞かせください」と言われて、そこで止まります。要望を言葉にするのが難しいから相談しているのに、要望を求められて詰まる。よくある行き止まりです。
1行を書くときは、解決策ではなく困りごとを書いてください。「在庫管理システムがほしい」は解決策です。これだと、その解決策が本当に最善かを誰も検証しないまま話が進みます。「在庫の数が合わず、月末に棚卸しで半日つぶれている」と書けば、開発会社は別のやり方も含めて提案できます。
1行が書けたら、次は発注の手順です。どういう順番で進み、どの時点で何を決めるのかはシステム開発の発注工程と流れにまとめてあるので、動き出す前に一度目を通しておくと迷いません。
よくある誤解
最後に、初めての発注で引っかかりやすいところを3つ挙げておきます。
ひとつ目は、作れば使われるという思い込みです。実際には、現場は今のやり方を変えたくありません。誰がいつ周知して、分からないときに誰に聞くのかまで決めておかないと、せっかく作ったものが使われずに終わります。
ふたつ目は、安いほうが得だという判断です。見積もりが安い場合、多くは範囲が狭いだけです。同じものを作るのに片方が半額ということは、実務ではほとんど起きません。金額を比べる前に、範囲がそろっているかを確かめてください。
みっつ目は、完成したら終わりという前提です。稼働してからも、法改正への対応や業務の変化に合わせた改修が続きます。年間の保守費と、誰が窓口になるかを最初に決めておくと、稼働後に慌てません。
付け加えると、稼働直後の1か月は想定外のことが起きる時期です。使い方の問い合わせが集中し、想定していなかった業務のパターンが出てきます。ここを乗り切る体制を決めておかないと、現場が「やっぱり前のほうがよかった」となって定着しません。稼働日を繁忙期にぶつけないことと、最初の1か月は開発会社にすぐ聞ける状態にしておくことの2つで、かなり違います。
- Q. システム開発を頼むと、何が納品されますか
- A. 動くシステム本体に加えて、要件定義書、設計書、テスト結果の記録、運用手順書などの書類が付きます。ただし何を渡すかは契約で決まるので、黙っていると本体だけということもあります。契約の前に納品物の一覧を示してもらい、編集できる形式で受け取れるかまで確認してください。ソースコードと権利の扱いも同じタイミングで決めます。
- Q. 自社にIT担当がいなくても発注できますか
- A. できます。ただしIT担当ではなく、業務を分かっている人を1人立ててください。開発会社が知りたいのは技術ではなく、今の業務がどう回っているかです。詳しい人が片手間で対応すると、確認待ちで止まります。月に何日か時間を空けられる人を決めるところから始めるのが現実的です。
- Q. まず何を用意すればいいですか
- A. 困っていることを1行書いたメモがあれば十分です。加えて、今使っている帳票やExcelの実物があると話が早くなります。きれいにまとめ直す必要はありません。むしろ現状のままのほうが、業務の実態が伝わります。予算の枠が決まっているなら、その金額も最初に伝えてください。
