社内システムを作りたいという話にはなったものの、いくらかかるのか分からないので社内で予算を通せない。 かといって、何を作るかが決まっていないので見積もりも出てこない。 この行き止まりに入ったとき、「まず要件定義だけを頼めないか」という相談が出てきます。全部を一度に決められないのだから、決める作業そのものを先に発注してしまおう、という考え方です。
結論から言えば、この形は成り立ちます。設計や要件定義の段階だけを切り出して受ける会社は珍しくありません。 ただし、分けたことで新しく決めなければならないことが出てきます。 その段階で何が手元に残るのか、残ったものを別の会社に持ち込めるのか、実装を頼むときに前提として使えるのか。 ここを決めずに分けると、お金を払ったのに次に進めない資料が残ることがあります。 この記事では、受託開発を手がけるCoconutWorksが、分けて発注できる段階と、分けるときに決めておくことを整理します。 費用の数字は扱いません。要件定義に持ち込む材料のほうは要件定義の前に発注側が準備することで扱っているので、ここでは発注の切り方という一点に絞ります。
結論: 分けて発注できる段階と、そこで手に入るもの
| 分けて出せる段階 | その段階で手に入るもの | そこで決まること | 分けるときの注意 |
|---|---|---|---|
| 現状の調査・整理 | 今の業務の流れとデータの実情をまとめた資料 | 何を対象にするか、手を付ける順番 | 調べて終わりにならないよう、次に何を決めるための調査かを先に書く |
| 要件定義 | 作るものの一覧と優先順位、画面や帳票の概要 | 実装の見積もりが乗る前提 | 実装する会社が読める粒度まで書いてもらうかを指定する |
| 設計 | 画面の流れ、データの持ち方、外部とのつなぎ方 | 技術の選択と、実装にかかる手数 | 実装側の進め方を縛るため、実装と同じ会社に任せるほうが素直なことも多い |
| 実装・テスト以降 | 動くもの、引き渡しの一式 | 運用に入ってからの体制 | 引き渡しと運用の取り決めを、この段階の見積もりに入れておく |
表で見ていただきたいのは、どの段階も「次の段階で何を決めるため」に存在しているという並びです。 分割がうまくいかないときは、たいてい段階そのものが目的になっています。 要件定義を頼んだのに、出てきた資料で実装の見積もりが取れない。調査を頼んだのに、何を作るかが決まらない。 分けて発注するときは、その段階の成果物が次の段階の入口として使えるかという一点で考えると判断を誤りにくくなります。以下、順に掘り下げます。
なぜ「決める段階だけ」を先に頼みたくなるのか
この相談が出てくる背景には、発注側と受託側で必要な順番が噛み合っていないという事情があります。 発注側は社内で予算を通すために金額が必要で、受託側は金額を出すために作るものの中身が必要です。 どちらも無理を言っているわけではなく、相手が先に出してほしいものを、自分も相手から待っている状態です。 決める作業を一つの発注として切り出すのは、この行き止まりを抜けるための現実的な手です。
もう一つの事情として、金額が読めない相談ほど社内で止まりやすいという点があります。 たとえば、受注から請求までを表で管理していて限界が来ている、という状態を考えてみてください。 困っていることは明確でも、どこまでをシステムにするかは関わる部署によって意見が違います。 この状態で各社に相談すると、範囲の想定が会社ごとに違うため金額が大きく開き、 社内では「まだ検討段階だ」という結論になりがちです。 見積もりがそろわない理由は見積金額が会社ごとにバラつくときの揃え方で詳しく扱っていますが、範囲が定まらないうちは依頼書の書き方だけでは埋まらない部分が残ります。
ですから、分割を考えるかどうかの入口は作るものがどのくらい固まっているかです。 おおよその形が見えていて社内でも合意があるなら、分けずにまとめて相談したほうが手数は少なく済みます。 反対に、何を作るかが人によって違うまま話が進んでいるなら、先に決める段階を切り出す意味があります。 発注の準備度を確かめるにはシステム開発を外注する前のチェックリストが使えます。
調査と要件定義は別のもの — 混ざると結果が噛み合わない
先に発注する段階として相談が多いのは要件定義ですが、その前段に調査・現状整理という段階があります。 この2つは目的が違い、混ざると出てくる資料が期待とずれます。 調査は今どうなっているかを明らかにする段階で、 要件定義はこれから何を作るかを決める段階です。
どちらが必要かは、社内で業務の流れを説明できるかで分かれます。 担当者が手順を順番どおりに話せて、使っているファイルや他のシステムとのつながりも挙げられるなら、調査は軽く済みます。 逆に、長く使っている仕組みがあって中で何が起きているか誰も説明できない、 あるいは部署ごとに運用が分かれていて全体像を誰も持っていない場合は、調査を切り出す価値があります。 既存の仕組みの中身が分からない場合の進め方は仕様書のない既存システムをどう引き継ぐかで扱っています。
つまずきやすいのは、調査を頼んだつもりが現状をまとめた資料だけで終わり、 結局何を作るかは自社で決めなければならなかった、という場合です。 これは受託側の手抜きではなく、発注の時点でどちらを頼んだのかが曖昧だったために起きます。 依頼するときに「この資料を使って次に何を決めたいのか」を一行添えておくと、 相手も成果物の形を合わせやすくなります。
成果物を次に持ち込めるかは、書き方と権利で決まる
分割発注で最も見落とされやすいのが、手に入った資料を次の段階で使えるかという点です。 使えるかどうかは2つに分かれます。一つは書き方、 もう一つは権利の取り決めです。
書き方の問題は、同じ会社が続けて実装する前提で書かれた資料は、他社が読んでも足りないことがある、という形で現れます。 社内で共有している前提や過去のやりとりを前提に書かれていると、 読み手が変わった途端に抜けが出ます。これは手抜きではなく、 誰に向けて書くかで必要な分量が変わるという当たり前のことです。 だからこそ、実装を比較してから決めたいのであれば、依頼の時点でそう伝える必要があります。
権利のほうは、成果物がどちらに帰属するか、第三者に見せてよいか、手を入れてよいかの3点です。 費用を払ったのだから自由に使えると考えてしまいがちですが、取り決め次第で変わります。 相見積もりの材料にしたい場合、第三者への開示が認められていないと目的を果たせません。 とはいえ、これは契約の交渉というより確認の話で、先に聞けば書面に入れてもらえることが多い部分です。
発注書や依頼のメールで曖昧になりやすい書き方を並べます。どれも悪意から生まれるものではなく、 双方が自然に読める言葉が入っていることで起きるものです。
| よくある書き方 | あとで困ること | 書き足すこと |
|---|---|---|
| 要件定義一式 | 何が納品されるのか分からず、実装の相談に持ち込めるかも読めません | 成果物の名前と、何が書かれているかを箇条書きで指定する |
| 成果物は双方協議のうえ定める | 協議が終わらないまま実装の相談時期が来ます | 形式と分量の目安、提出の時期を書く |
| 権利の帰属は別途定める | 他社に見せてよいかが決まらず、相見積もりが取れません | 帰属先と、第三者への開示・改変の可否を書く |
| 実装は本件に含まない | 含まないことは分かっても、実装側が読める形で書かれる保証がありません | 他社が実装する前提で書いてもらうかどうかを明記する |
右の列はいずれも、成果物の形・提出の時期・使ってよい範囲を加えているだけです。 難しい条文を書く必要はなく、打ち合わせの議事録に同じ粒度で書いて相手に確認してもらう形でも効きます。
分けることで失うもの — 責任の切れ目と手数の増加
分割には弱点もあります。はっきり出るのは責任の切れ目です。 要件定義を書いた会社と実装した会社が違う場合、 動かしてみて想定と違ったときに、決め方が足りなかったのか、作り方が合っていなかったのかという論点が生まれます。どちらにも落ち度がないこともあり、その場合でも直す費用は発注側に戻ってきます。
もう一つは、段階の境目で手数が増えることです。 新しく入る会社は資料を読み込む時間が必要で、質問も出てきます。 同じ会社が通しで担当すれば要らなかった時間なので、分けた分だけ全体の手数は増えます。 あわせて、発注側の作業も増えます。段階ごとに相談先を探し、依頼の形を整え、社内の承認を取る。 これらは見積書には出てこない部分です。
緩和の仕方としては、実装を頼む段階で資料を読んでもらった上で前提を確認してもらう場を 一度設けることをおすすめします。読めば分かるはずという前提で渡すと、 食い違いが見つかるのが作業の後半になります。 また、設計の段階については実装と同じ会社に任せるほうが素直なことが多いところです。 設計は実装の進め方を縛る部分で、切り離すと実装側が自社のやり方と合わない形を引き受けることになり、 かえって手数が増える場合があります。
分けないほうがよい場合の見分け方
分割が常に有利というわけではありません。 作るものの形がすでに見えていて、社内でも何を作るかの合意があるなら、通しで頼んだほうが早く安く済みます。 同じ業務を扱うパッケージやサービスを候補として検討していて、 それで足りるかどうかを確かめたい段階なら、要件定義を切り出すより先に候補を触ってみるほうが判断が早いこともあります。
もう一つ、分割が合わないのは、作りながら決めたい性質の仕組みです。 使う人の反応を見ながら中身を変えていく前提のものは、 先に全部決めてから作る形と相性がよくありません。 この場合は段階で切るのではなく、期間で区切って続ける形のほうが収まります。 月額で開発を続ける形の考え方は納品のない受託開発（ラボ型開発）とはで扱っています。
迷ったときのチェックポイントと、進めていく順序
分けて発注するかを決める前に、次の5点に答えられるか確かめてみてください。 詰まった項目は、分けたあとに「これでは次に進めない」として出てくる場所です。
- ①その段階の成果物で、次に何を決めたいか言えるか — 実装の見積もりか、社内の予算承認か、やるかやらないかの判断か。
- ②成果物の名前と中身を指定できているか — 「一式」で止まっていないか。
- ③実装を他社に相談する可能性を伝えてあるか — 伝えないまま進めると、書き方がその会社向けになります。
- ④権利の帰属と開示の可否を確認したか — 相見積もりに使えるかはここで決まります。
- ⑤分けたことで増える自社の作業を見込んでいるか — 相談先探し、資料の読み合わせ、承認の取り直し。
進める順序としては、①今の困りごとを事象として書き出す → ②社内で業務の流れを説明できるか確かめ、できなければ調査を先に置く → ③その段階の成果物で何を決めたいかを一行で書く → ④成果物の形・時期・権利の扱いを添えて複数社に相談する → ⑤出てきた資料で実装の相談ができるか、別の会社に当ててみて確かめる → ⑥実装の依頼時に前提を確認する場を設けるという流れが無理がありません。 ⑤を入れているのは、資料が次に進める形になっているかを確かめられるのが、その時点だけだからです。 見積書の読み方はシステム開発の見積書、どこを比較すればいいかで扱っています。
よくある誤解と、起きやすい失敗
「要件定義を頼めば、作るものが決まって出てくる」 — 決めるのを手伝う段階であって、 代わりに決めてもらう段階ではありません。業務のどこを優先するか、どの部署の運用に合わせるかは社内の判断です。 受託側ができるのは、選べる形に整理して判断材料をそろえるところまでです。 決める人を社内で立てていないと、資料は出てきても結論が出ないという形で止まります。
「実装は別の会社にすれば安く上がる」 — 安くなる場合もありますが、 読み込みの時間と、想定が合わなかったときの直しが戻ってきます。 分けることの目的は金額を下げることではなく、決める段階と作る段階で判断を一度区切ることにあります。 結果として同じ会社に続けて頼むことになっても、比較した上で選んだのであれば分割の意味は果たしています。
「分けたのだから、実装の見積もりはすぐ出る」 — 前提が書かれていれば速く出ますが、 資料を読んで自社の作り方に当てる時間は必要です。 また、要件定義の中身によっては、受けた側から「ここは決め直したい」という話が出ることもあります。 これは後戻りではなく、作る側の目で見て初めて分かる部分です。 その余地を見込んでおくほうが、日程が崩れにくくなります。
「要件定義の段階なら、相談相手は1社でよい」 — 複数社に当てておくほうが、 出てくる資料の形を比べられます。同じ相談をしても、現状の整理に重きを置く会社と、 作るものの一覧を細かく出す会社があり、次に進めやすい形は後者とは限りません。 社内の事情によってどちらが使えるかは変わるので、何社かの進め方を聞いてから決めるほうが確実です。
よくある質問
まとめ
要件定義だけを先に発注する形は成り立ちますが、分けたことで決めるべきことが増えます。 押さえたいのは、その段階の成果物が次の段階の入口として使えるかという一点です。 調査と要件定義は目的が違うので、社内で業務の流れを説明できるかで必要な段階が変わります。 成果物を次に持ち込めるかは書き方と権利の取り決めで決まるため、 実装を比較してから決めたいのであれば依頼の時点で伝えておく必要があります。 分けると責任の切れ目と手数が増えるので、作るものが固まっているなら通しで頼んだほうが素直です。 段階の切り方や依頼の形のご相談はシステム開発サービスのページから承っています。相談・お見積もりは無料です。
