システム開発とは？種類・工程・依頼方法の基礎知識

業務の手作業を減らしたい、新しい顧客向けサービスを提供したい、既存システムの情報をつなげたい。このような課題に対し、必ずしも最初から個別開発を選ぶ必要はありません。既製サービスの活用、設定や連携、カスタマイズ、個別開発を比べながら、自社に合う進め方を見極めることが重要です。

この記事では、システム開発の定義から方式、工程、相談準備、見積もり比較、リスク確認までを発注者の視点で整理します。方式候補を仮置きし、相談用メモ・社内役割・共通依頼条件を準備できるようになります。

システム開発は実装だけで完結せず、課題整理から方式選定、発注準備、導入後の運用改善までを一連の取り組みとして捉えます。

01Sectionシステム開発とは、課題を実現する仕組みを整え続けること

システム開発とは、業務や事業の目的を実現するために、仕組みを構想し、要件を整理して、設計・実装・テスト・導入・運用改善を行う取り組みです。「プログラムを作ること」だけではなく、導入後に使い続け、改善していくことまで含めて考えます。

対象には、社内の業務システム、顧客向けWebサービス、スマホアプリ、取引先との連携機能、データ連携・活用基盤などがあります。要件定義では、利用部門が業務・事業上の目的を踏まえて主体的に関与することが重要とされています。IPAの要件定義ガイドも、業務側と開発側の認識をそろえる重要性を示しています。

開発が必要かは、機能数ではなく課題で判断する

まずは「何を作るか」よりも、「誰のどの業務・事業課題を、どう改善したいか」を確認します。標準機能や業務手順の見直しで目的を達成できるなら、既製サービスの活用が有力です。一方、固有の業務処理や継続的なデータ連携が必要な場合は、設定・連携、カスタマイズ、個別開発も候補になります。開発要否の判断基準はシステム開発が本当に必要かを見極める考え方で詳しく整理しています。

Webサイト制作との違い

情報提供や集客が主目的であれば、Webサイト制作が中心になりやすいでしょう。一方で、ログイン後の権限管理、予約・決済、申請・承認、データ管理、外部サービスとの継続的な連携が中心なら、システム開発を併せて検討する必要があります。サイト制作とシステム開発が同じ案件に含まれることもあります。

02Section種類は「用途・利用者」「利用チャネル」「実現方式」の3軸で整理する

「誰が何のために使うか」「どの経路で使うか」「どう実現するか」を分けて考えると、方式候補を比較しやすくなります。

システムの種類を考えるときは、分類軸を分けると検討しやすくなります。「社内向け」は誰が何のために使うかという用途・利用者の軸であり、「Web／スマホ」は利用チャネルの軸です。既製サービスや個別開発は、実現方式の軸として扱います。

用途・利用者には、社内業務、経営・基幹業務、顧客向け、取引先連携、データ連携・分析などがあります。利用チャネルには、Webブラウザ、スマホアプリ、現場端末、API経由などがあります。これらを整理したうえで、実現方式を比較します。

実現方式は4つの候補で仮置きする

表は、方式を一つに決めるためではなく、有力な候補と追加確認が必要な条件を見つけるために使います。機能だけでなく、性能、可用性、運用・保守、移行性、セキュリティといった非機能要件も確認してください。IPAの非機能要求グレードは、こうした確認観点の参考になります。

方式ごとの比較を深めたい場合は、システム開発の種類も参照してください。

03Section発注者は工程ごとに判断・レビュー・受け入れを担う

外部へ委託する場合も、発注者は工程ごとに目的・優先順位・業務上の妥当性を確認し、受け入れや改善の判断を行います。

外部へ委託しても、目的、業務ルール、優先順位、レビュー、受け入れ判断、運用改善の優先順位まで委託先だけに任せることは難しいものです。発注者側で、誰が何を確認するかを早めに仮決めします。

工程ごとに確認・承認すること

ウォーターフォール型とアジャイル型の違い

アジャイル型は、無計画に変更する進め方ではありません。短い単位で成果を確認し、その結果を次の開発内容へ反映する方法です。デジタル庁サイト掲載の『アジャイル開発実践ガイドブック』（内閣官房IT総合戦略室、2021年）も、漸次的・反復的に進める考え方を解説しています。

どちらが常に適しているとはいえません。要件の確度、変更頻度、発注者がレビューできる体制で選びます。全体方針や移行計画を先に整理し、一部の機能を反復的に開発する組み合わせも考えられます。工程や手法の詳細は、システム開発の流れで確認できます。

04Section外部相談の前に、目的・制約・判断体制を1枚にまとめる

初回相談の時点で、完成した仕様書は必須ではありません。要求と主要な要件を共有し、方式や優先順位を相談しながら具体化します。

要求は達成したい業務・事業上の目的、要件は目的を実現するための条件、仕様は画面項目や処理手順など実装内容の具体化です。初回相談では、要求、主要要件、制約、判断体制を整理できていれば検討を始められます。

予算が未確定でも、上限の有無、投資判断の時期、優先順位を共有すれば概算相談は可能です。未確定事項は、理由と決定予定を伝えることで認識違いを減らせます。

05Section費用と期間は、見積もりの前提と総コストで確認する

費用とリリース時期は、対象業務・機能範囲、既存システムとの連携、データ移行、利用規模、性能、セキュリティ、テスト、教育、保守、発注者側の確認体制によって変わります。費用の内訳や相場の考え方はシステム開発の費用に委ねますので、あわせて参照してください。開発側の作業期間だけでなく、データ準備、レビュー、受け入れテスト、教育、移行判定に必要な発注者側の期間も確認しましょう。

初期費用では、要件整理、設計、実装、テスト、移行、導入支援などの対象内外を確認します。継続費用では、クラウド・外部サービスの利用、保守・監視、障害対応、セキュリティ対応、追加改修、教育、契約更新を分けて確認します。経済産業省の情報システム・モデル取引・契約書でも、構築・設定、移行、教育、保守・運用支援などが取引対象になり得ることが示されています。

概算相談から詳細見積もりまでの進め方

見積もりは総額だけでなく、対象内外、発注者側の作業、追加費用の条件、継続費用を同じ前提で確認します。

見積書を比較するときは、次の4点を独立して確認します。

• 含むもの：要件定義、設計、実装、テスト、移行、教育、導入支援など
• 含まないもの：インフラ、外部サービス、保守、データ整備など
• 発注者が担う作業：資料提供、データ準備、レビュー、受け入れテスト、教育など
• 追加費用となる条件：要件変更、連携追加、移行量増加、テスト追加、期限変更など

対象内外・発注者作業・追加費用条件・継続費用が異なる提案を、総額だけで比較しないことが重要です。前提が異なる場合は、共通条件での再提示または差分の説明を求めましょう。

06Section失敗を防ぐには、要件・変更・受け入れ・委託条件を早めに確認する

手戻りや運用開始後の混乱は、技術だけで起こるわけではありません。要件が曖昧なまま進む、判断者が不在になる、変更の影響を確認しない、受け入れ条件が不足する、といった発注側の準備不足も影響します。

外部委託では、委託範囲、責任分界、求めるセキュリティ対策、契約条件を明確にすることも重要です。

07Section検討段階に応じて、次の行動を選ぶ

すべてを一度に決める必要はありません。不足している情報に応じて、次の行動を選びます。

課題がまだ曖昧な場合

現場へヒアリングし、「誰が、どの業務で、何に困り、何が改善すればよいか」を整理します。システム開発で解決できる課題で課題起点の選択肢を確認しましょう。

方式候補を絞れない場合

用途・利用者、利用チャネル、実現方式の3軸で整理し、実現方式の比較表を確認します。連携、運用、セキュリティの未確認事項を洗い出し、システム開発の種類で比較を深めます。

発注後の進行に不安がある場合

社内の確認・受け入れ担当と、レビュー時期、変更判断の方法を仮決めします。システム開発の流れで工程の詳細を把握しましょう。

相談に進める場合

相談用1枚メモと共通依頼条件をそろえ、未確定事項には決定予定を添えて相談します。

Webアプリ・SaaS開発の相談先を比較する

課題、優先機能、連携要件、希望時期などを整理したうえで、開発支援会社の対応領域を比較できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の相談先を見る