System integration システム開発の依頼の進め方

Development process システム開発の依頼の流れとは

システム開発の依頼の流れは、社内での整理、相談、要件の整理、見積もりの比較、契約、設計・開発、テスト・受け入れ、リリース・保守の 8 つの段階です。外注する場合でも、目的を決め、要件を確かめ、完成したものを受け入れるのは発注する側の役割です。開発会社は作る作業と提案を担いますが、何を作るかを最後に決めるのは発注側です。このページでは、発注の流れに沿って、段階ごとに発注側と開発会社がすることを説明します。あわせて、依頼前の整理シート、期間を左右する要因、よくあるつまずきを取り上げます。

8 steps システム開発を依頼する流れ・8 つの段階

段階発注側がすること開発会社がすること
1. 社内での整理目的、困りごと、期限、決定者を整理し、依頼前の整理シートにまとめる目的や課題の整理の段階から、相談に応じる
2. 相談決まっていることと、決められていないことを分けて伝える業務と課題を聞き、進め方の選択肢を示す
3. 要件の整理業務フローと利用者を説明し、機能を「必須」と「あれば良い」に分けるヒアリングをもとに、必要な機能と見積もりの前提を整理する
4. 見積もりと提案の比較金額だけでなく、何が含まれているか、前提条件、進め方、体制を比べる範囲と前提を示して、見積もりと提案を出す
5. 契約範囲、成果物、受け入れの方法、変更の扱い、保守の範囲を確かめる契約の範囲と進め方、開発スケジュールを示す
6. 設計・開発画面や動作の確認と、仕様の判断に参加する。確認の期限を守る機能要件と技術仕様を固め、設計と開発を進める
7. テスト・受け入れ実際の業務の流れで動作を確かめ、受け入れるかを判断する単体テスト・結合テスト・総合テストをおこない、不具合を修正する
8. リリース・保守利用者への周知と、社内の運用担当を決める。保守をどこまで依頼するかを決めるリリース後の動作確認と不具合対応をおこない、契約に応じて保守・運用に移る

フロンティアエージェンシー（FAC）の企画開発は、要件定義・設計、プロトタイプ開発・検証、
本格開発・テスト、リリース・運用サポートの順で進めます。
上の表では、3 と 6〜8 の段階がおおむねこの 4 つのステップにあたります。
FAC では、早期に動くプロトタイプで画面や動作を確認いただきながら、仕様を固めます。

Request sheet 依頼前の整理シート（簡易 RFP）

RFP（提案依頼書）は、開発会社に提案と見積もりを頼むときに、目的や条件をまとめて渡す資料です。
正式な RFP がなくても、次の 10 項目を 1 枚にまとめておくと、相談と見積もりの前提がそろいます。
書けない項目は「未定」のままで構いません。例は記入のサンプルです。

項目書くこと例
目的システムで何を達成したいか受注から請求までの手作業を減らしたい
今の困りごと今の業務で起きていること複数の台帳で情報が食い違い、集計に時間がかかる
対象業務と利用者どの業務を、誰が、どの場面で使うか営業部が外出先で受注を入力し、経理部が月末に請求をまとめる
必要な機能必要な画面と機能。「必須」と「あれば良い」に分ける必須は受注の登録と請求書の出力。あれば良いのは月ごとの売上の集計
連携するシステムつなぎたい他のシステムや外部サービス会計システム、顧客管理
データ移したい既存データの種類、量、形式顧客の一覧と過去の受注の記録（Excel のファイル）
期限とその理由使い始めたい時期と、その時期にしたい理由決算期の前に使い始めたい。繁忙期の切り替えは避けたい
予算の考え方予算が決まっているか、検討中か。何を優先して費用をかけるか最初は必須の機能に絞り、拡張は次の段階で検討したい
社内体制と決定者社内の担当者と決定者、その不在時の代理窓口は業務部の担当者、仕様の決定は部長
リリース後の運用リリース後に誰が運用し、保守をどこまで依頼するか操作の問い合わせは社内で受け、障害対応とバグ修正を依頼したい

見積もりの内訳と、費用が変わる要因は、システム開発の費用の決まり方で説明しています。

Schedule システム開発の期間は何で決まるか

システム開発の期間の目安は、作るものの量と、発注側の確認と判断にかかる時間の組み合わせで決まります。同じ規模でも、次の要因で長くも短くもなります。

要因期間が長くなる場合
機能と画面の数機能が多い。例外的な業務パターンまで作り込む
他システムとの連携連携先が多い。連携先の仕様が分からない
データ移行既存データの量が多く、形式がそろっていない
要件の決まり具合要件が後から追加され、手戻りが増える
確認と判断の速さ決定者が決まっていない。確認の期限がない

期間を短くしたい場合は、使い始めたい時期から逆算し、必須の機能から段階的にリリースする計画を立てます。個別の期間は、範囲を決めたうえで開発スケジュールとして定めます。

Pitfalls よくあるつまずき

つまずき起こりやすいこと防ぐために
外注を丸投げにする目的や業務の説明が足りず、業務に合わないものができる目的と業務の流れは発注側が説明し、画面や動作の確認に参加する
決定者がいない確認のたびに意見が分かれ、判断が止まる決定者を 1 人決め、確認の期限を決める
要件を後から出す開発の途中で機能や例外の業務が見つかり、手戻りが増える依頼前に業務と機能を書き出す。動くプロトタイプで早めに確かめる
受け入れテストをしない使い始めてから、業務に合わない点が見つかる業務の担当者が実際の業務の流れで確かめる時間を、計画に入れる

FAQ よくある質問

要件が決まっていなくても依頼できますか？

はい。ビジネス課題や業務フローをヒアリングし、システムの目的と要件を明確にするところから始めます。整理シートは、書ける項目だけで構いません。

発注者の役割は何ですか？

目的と業務の説明、仕様の判断、画面や動作の確認、受け入れの判断です。いずれも発注側にしかできない作業です。

開発の期間の目安はどのくらいですか？

作るものの量と、確認と判断にかかる時間で変わります。範囲を決めたうえで、機能要件、技術仕様とあわせて開発スケジュールを定めます。

RFP を作らないと依頼できませんか？

いいえ、RFP がなくても依頼できます。整理シートの項目が分かれば、相談と見積もりの前提をそろえられます。複数の会社を比べる場合は、同じ資料を渡すと比べやすくなります。

整理シートが書けていない段階でも、状況に合わせてご相談ください。発注が決まっていなくてもご相談いただけます。お問い合わせフォームの「お問い合わせ内容」に「相談希望」とご記入ください。

まず相談する

関連：企画開発／システム開発の費用の決まり方／システム保守の範囲と決め方

Related あわせて読む

費用システム開発の費用の決まり方見積もりの内訳と、費用が変わる 7 つの要因サービス企画開発業務基盤システム、Web・モバイルアプリのスクラッチ開発解説システム保守の範囲と決め方保守・運用・改修の違いと、契約前に整理する 6 項目