普段はあまり意識されませんが、「システム構築」と「システム開発」とは別物だというのをご存じでしたか？
IT分野で使用される用語であり、似ているように思われるかもしれませんが、それぞれ異なる側面を指しています。
「システム構築」はシステム構築は、既存のコンポーネントやシステムを組み合わせて、一つの動作するシステムを構築するプロセスです。
「システム開発」はシステム全体を構築するために、ソフトウェアやハードウェアなどのコンポーネントを設計、開発、実装するプロセスです。
簡単に言うと「既存の組み合わせで新しい要件を満たす」のか「新規に開発するのか」の違いですね。
本記事ではより具体的にその違いを解説し「システム構築」について深堀して解説します。
1.「システム構築」と「システム開発」は何が違うのか？
簡単に言えば、システム開発はシステムの構成要素を作成するプロセスであり、システム構築はそれらの要素を統合して機能する一体のシステムを構築するプロセスです。両者はしばしば連携して行われ、システム開発が完了した後にシステム構築の段階に進むことが一般的です。
1.1.システム構築とは
システム構築は、既存のコンポーネントやシステムを組み合わせて、一つの動作するシステムを構築するプロセスです。これは、異なる部分を統合して、全体としての機能や性能を達成することを目指します。例えば、既存のソフトウェアやハードウェアコンポーネントを連携させて、より大きなシステムを構築する際に行われます。システム構築は、システム全体の設計、テスト、デプロイメント、および運用の段階で行われる作業を包括しています。
1.2.システム開発とは
システム開発は、システム全体を構築するために、ソフトウェアやハードウェアなどのコンポーネントを設計、開発、実装するプロセスです。システム開発には、要件収集、設計、プログラミング、テスト、デバッグ、およびデプロイメントなどの工程が含まれます。システム開発の目的は、利用者やビジネスニーズに応じた機能を持つシステムを構築することです。
2.システム構築の工程
2.1.要求定義・RFPの作成
【要求定義 (Requirements Definition)】
要求定義は、プロジェクトやシステムに関する明確で詳細な要件を定義するプロセスです。これは、プロジェクトの成功を達成するために必要な機能、性能、制約、条件などを明確にするために行われます。要求定義の過程には、利用者やステークホルダーとのコミュニケーション、要件の優先順位付け、矛盾の解決などが含まれます。要求定義はプロジェクト全体の基盤となり、開発や提案の際の指針となります。
【RFP (Request for Proposal)】
RFPは、プロジェクトや契約に関連する提案を外部のベンダーや提供業者に求めるドキュメントです。RFPには、プロジェクトの背景、目的、要求事項、提案の提出方法、評価基準などが含まれます。RFPを発行することで、異なるベンダーや提供業者から提案を受け取り、最適な提案を選定するための競争を促すことができます。RFPには、提案者がどのように要求事項を満たすか、提案内容の詳細な説明や見積もりが求められます。
要求定義は、プロジェクトやシステムの要件を明確に定義するプロセスであり、これがプロジェクトの基盤です。一方、RFPは、外部のベンダーや提供業者に向けて提案を求めるための文書であり、要求定義に基づいてどのようにプロジェクトを進めるかを提供業者に指示するものです。要求定義がプロジェクトの要件を定義し、RFPがこれをベンダーに提案する形式となります。RFPの応募提案は、要求定義を満たすためにどのように計画し、実行するかを提供業者が示すことになります。
2.2.依頼先の選定・契約
システムベンダーの選定は、プロジェクトやビジネスの成功に大きく影響を及ぼす重要なプロセスです。適切なシステムベンダーを選ぶためには、以下のステップや要因を考慮することが重要です。
■要求定義の明確化
■RFPの作成
■ベンダーの候補者リストの作成
■RFPの配布と提案受付
■提案の評価
■ベンダー選定の決定
■契約交渉
■契約締結とプロジェクト開始
システムベンダーの選定はプロジェクトの成功に大きく影響するため、慎重なプロセスが必要です。適切なベンダーを選ぶために、要求定義から始まり、提案の評価、契約交渉までの各段階を適切に進めていくことが重要です。
2.3.要件定義
要件定義は、プロジェクトやシステムに関連する要求事項やニーズを明確に定義し、プロジェクトの成功を達成するために必要な機能、性能、制約、条件などを文書化するプロセスです。要件定義は、プロジェクトのスコープや目標を確立し、開発や設計の方針を決定するための基盤となります。
以下は要件定義の主要な側面とステップです。
■要件収集
■要件分析
■機能要件
■非機能要件
■制約条件
■要件文書化
■要件の承認
■変更管理
要件定義はプロジェクトの成果物の基盤となり、プロジェクトの成功を確保するために不可欠です。要求事項やニーズを正確に理解し、関連するステークホルダーとの協力とコミュニケーションを通じて適切な要件定義を達成することが重要です。
2.4.基本設計
基本設計（High-Level Design）は、システム開発プロセスの中で、要件定義を基にシステムの構造やアーキテクチャを詳細に設計するプロセスです。基本設計は、要件を技術的に具現化する段階であり、開発チームが具体的な実装に向けて準備を進める重要なステップです。
以下は基本設計の主要な側面とステップです。
■アーキテクチャ設計
■データモデルの設計
■インタフェース設計
■データフロー設計
■アルゴリズムの設計
■セキュリティ設計
■パフォーマンス設計
■エラー処理と例外設計
基本設計は、要件定義で定義された要求を具体的な設計に落とし込む段階です。適切なアーキテクチャ、データモデル、インタフェース、セキュリティ対策などを考慮しながら、システムが要求を満たすように詳細な設計を行います。
2.5.詳細設計
詳細設計（Detailed Design）は、基本設計の結果を基に、システムの具体的な実装やコンポーネントの内部設計を行うプロセスです。基本設計で定義されたアーキテクチャや要素をより詳細に具現化し、開発者が実際のプログラミングや実装作業を進めるための指針となる設計です。
以下は詳細設計の主要な側面とステップです。
■モジュール設計
■データモデルの具体化
■コーディングガイドラインの設定
■インタフェース実装
■データベース実装
■アルゴリズム実装
■ユーザーインターフェース実装
■テストケースの設計
■ドキュメンテーション
詳細設計はプログラミングや実装作業の前に行われる段階であり、実際のコーディングやテストの指針を提供する役割を果たします。詳細設計が適切に行われることで、実装の効率性や品質が向上し、プロジェクトの成功に寄与します。
2.6.プログラミング・実装
プログラミングや実装は、要件定義や設計の結果を基に、実際にソフトウェアコードやシステムの機能を開発するプロセスです。プログラミングは、設計された仕様を元に具体的なコードを記述する作業を指し、実装はそのコードをシステムに組み込む一連の手順を指します。
以下はプログラミング・実装の主要な側面です。
■プログラミング言語の選定
■コーディング
■テスト
■エラー処理
■デバッグ
■最適化
■バージョン管理
プログラミングや実装は、設計段階で考えられた機能や要求を実際のソフトウェアに昇華させる重要なフェーズです。品質保証やテストを適切に実施しながら、要求を満たす正確で効率的なコードを開発することが求められます。
2.7.単体テスト・結合テスト・総合テスト
システム構築において、テストはシステムの品質と正確性を確保するために欠かせないプロセスです。テストの段階では、単体テストがシステムの機能や相互作用を評価する役割を果たします。
【単体テスト（Unit Testing）】
単体テストは、ソフトウェアの最小単位である「ユニット」（関数、メソッド、クラスなど）が正しく動作するかどうかを検証するテストです。開発者が独自に実施し、コードの品質を保証するためのテストです。単体テストはユニットごとに行われ、テストケースを用いて予想される入力と出力を比較します。
【結合テスト（Integration Testing）】
結合テストは、複数のユニットが組み合わさって連携する際の相互作用やデータフローをテストするプロセスです。ユニット同士のインタフェースやデータのやり取りが正しく行われるかを確認します。ユニットテストを通過したユニットを結合させてテストを行います。
【総合テスト（System Testing）】
総合テストは、システム全体の機能や要求事項をテストする段階です。システムが要件を満たすかどうかを確認し、利用者がシステムを期待通りに使用できるかを検証します。総合テストでは、ユーザーシナリオやユースケースに基づいてテストケースを作成し、実際の使用状況に近い条件でテストを行います。
これらのテストは、段階的に進行し、システムの正確性と品質を確保します。単体テストは個別のユニットの正しさを確認し、結合テストはユニット間の連携を、総合テストは全体のシステムの機能と要件をテストします。テストの段階を通じて、早期に問題を発見し、修正することで、プロジェクトの品質向上を図ることができます。
2.8.納品・構築・受入テスト・検収
システム構築プロジェクトにおいて、最終的にクライアントや顧客にシステムを納品し、クライアントがシステムを受け入れるための一連のプロセスがあります。以下にそれぞれのステップについて説明します。
【納品（Delivery）】
システムの開発が完了したら、クライアントに対してシステムを正式に納品します。この段階では、システムの動作が要求仕様に適合し、テストが適切に実施されていることが確認されます。納品時には、システムの実行ファイル、ドキュメンテーション、トレーニング資料などが含まれることがあります。
【構築（Deployment）】
システムの納品後、実際の運用環境にシステムを導入し、運用を開始する作業が行われます。この段階では、ハードウェアやソフトウェア環境の設定、データの移行、セキュリティ設定などが行われます。システムが正しく動作することを確認しながら、本番環境への移行が進められます。
【受入テスト（User Acceptance Testing, UAT）】
受入テストは、クライアントや最終ユーザーがシステムの機能や性能を評価するためのテストです。クライアントが実際にシステムを操作し、要求仕様を満たしているかどうかを確認します。受入テストは、クライアントがシステムを受け入れる前に行われ、クライアントの満足度を確保する重要なステップです。
【検収（Acceptance）】
受入テストが成功し、クライアントがシステムを受け入れる意思を示す場合、正式な検収が行われます。検収には契約上の合意事項や要件の適合などが含まれます。システムの受け入れに関する条件や文書が確定し、プロジェクトの完了が宣言されます。
これらのステップを通じて、システム構築プロジェクトはクライアントに納品され、システムが運用環境で正常に動作することが確認されます。プロジェクトの成功は、クライアントの満足度とシステムの要求を満たすことによって確保されます。
2.9.システム構築後の運用・保守
システム構築が完了し、システムが本番環境で稼働し始めた後も、運用と保守作業が重要な役割を果たします。システムが効果的に動作し、クライアントやユーザーのニーズを満たし続けるために、以下の活動が行われます。
■運用管理
■障害対応とメンテナンス
■セキュリティ管理
■バージョン管理とアップデート
■ユーザーサポート
■監査と報告
運用と保守は、システムが継続して価値を提供し続けるために欠かせない活動です。定期的な運用とメンテナンス、セキュリティの確保、ユーザーサポートなどが適切に行われることで、システムの品質と信頼性を維持することが可能です。
3.システム構築の手法
3-1.ウォーターフォール
ウォーターフォールモデルは、システム構築プロセスの古典的な手法の一つで、一連の段階的なフェーズを順序通りに進行することによってシステムを構築する手法です。各フェーズは前のフェーズが完了してから始まり、次のフェーズに進む前に前のフェーズが完了することを特徴としています。
ウォーターフォールモデルの利点は、段階的な進行によって各フェーズが明確に分かれており、進行状況や成果物が容易に管理できる点です。
しかし、要求の変更に対応するのが難しく、途中での変更がコストと時間に大きな影響を及ぼす可能性があるというデメリットもあります。
このため、ウォーターフォールモデルは変更が少なく、プロジェクトの全体像が早期に把握できる場合に適していますが、変化の多いプロジェクトには適さないこともあります。
3-2.アジャイル
アジャイル開発は、ウォーターフォールモデルとは異なるアプローチを持つシステム構築の手法です。アジャイルは、変化に対応する柔軟性を重視し、継続的な顧客のフィードバックを取り入れながら進行する特徴があります。以下はアジャイル開発の主要な手法とその特徴です。
【スクラム（Scrum）】
スクラムは、開発プロセスを短期間の「スプリント」と呼ばれる周期に区切り、各スプリントごとに機能を追加していく手法です。スプリントの期間は通常2〜4週間程度で、各スプリントの開始前にバックログ（要求事項のリスト）から優先順位の高い項目を選び、スプリント中にそれを実装し、スプリントの終了時に成果物を提供します。スクラムでは、デイリースクラムミーティングなどのコミュニケーションが重要です。
【カンバン（Kanban）】
カンバンは、タスクの流れをビジュアルボード上に可視化し、各タスクの進捗状況や作業量を管理する手法です。作業が進行するにつれてボード上で移動させることで、プロジェクトの進行状況をリアルタイムで確認しやすくなります。カンバンは特定のスプリントや周期に縛られず、柔軟に進捗を管理するための手法です。
【エクストリーム・プログラミング（Extreme Programming, XP）】
エクストリーム・プログラミングは、プログラムの品質を重視するアジャイル手法で、テスト駆動開発（TDD）、ペアプログラミング、継続的インテグレーションなどのプラクティスを活用して開発を行います。XPはコードの品質を保つことに重点を置きつつ、顧客のフィードバックを取り入れるアジャイルの一形態です。
【リーン開発（Lean Development）】
リーン開発は、トヨタ生産方式をシステム構築に応用した手法で、無駄を排除し、価値を最大化することに焦点を当てます。進行中のプロジェクトに対して適切な透明性を提供し、適切なアクションを実行するためのメトリクスや手法を活用します。
アジャイル開発の共通した特徴は、顧客やユーザーとの密接な連携、継続的な改善、柔軟性の確保などです。アジャイル手法は変化に対応する能力を高め、プロジェクトの成功を確保するために採用されています。
3-3.プロトタイプ
プロトタイプ開発は、ソフトウェアやシステムの概念やアイデアを実際に動作するプロトタイプ（試作品）として素早く作成し、利用者やクライアントとのコミュニケーションを強化するための手法です。プロトタイプを使用することで、要求や仕様の理解を深め、適切な方向性を見つけることができます。以下はプロトタイプ開発の特徴とステップです。
特徴
■早期フィードバック
プロトタイプを利用者やクライアントに提供することで、早期にフィードバックを受け取り、要求事項を明確化しやすくします。
■柔軟性
プロトタイプは素早く作成できるため、変更や修正が比較的容易に行えます。
■バグや問題の早期発見
プロトタイプを使用して実際の操作を行うことで、バグや問題が早期に発見できます。
■顧客の要求に合致
プロトタイプの動作を通じて、顧客の要求が適切に満たされているかどうかを確認できます。
ステップ
■要求収集と分析
プロトタイプの目的と要求を収集し、システムの基本的な仕様を理解します。
■プロトタイプの設計
システムの機能やインターフェースの基本的な設計を行います。これは後に構築される本番システムの要素として考えます。
■プロトタイプの作成
設計に基づいて、プロトタイプを作成します。これは実際に動作するプロトタイプであり、一部の機能や画面が実装されます。
■プロトタイプの評価
ユーザーにプロトタイプを提供し、実際の操作を行ってもらいます。ユーザーからのフィードバックを収集し、要求事項やデザインの改善点を特定します。
■プロトタイプの修正と拡張
フィードバックをもとに、プロトタイプを修正し、新たな機能や要求事項を追加して拡張します。これは繰り返し行われることがあります。
プロトタイプ開発は、要求の明確化や顧客のニーズの理解を早期に行うために有用な手法ですが、注意が必要です。プロトタイプが実際のシステムの一部として誤解されることがあるため、プロトタイプ開発と本番システムの間に明確な区別を設け、本番システムの開発に移行する際には適切な設計とテストを行うことが重要です。
3-4.スパイラル
スパイラルモデルは、ウォーターフォールモデルのような直線的な進行ではなく、反復的で進化的なアプローチを採用するシステム構築手法です。スパイラルモデルは、リスク管理や変更管理を重視し、プロジェクトが進むにつれて詳細な計画を洗練させることを目的としています。以下はスパイラルモデルの特徴とステップです。
■反復と進化
プロジェクトは複数の反復サイクル（スパイラル）を通じて進行し、各スパイラルで新しい情報や要求を取り入れつつ進化していきます。
■リスク管理
各スパイラルでは、リスク評価が行われ、リスクの特定と軽減策の導入が重要な要素とされます。
■顧客のフィードバック
各スパイラルの終了時に顧客やユーザーとのコミュニケーションが行われ、フィードバックを取り入れながら進行します。
■目標の設定
プロジェクトの目標と要求を特定し、基本的な計画を策定します。
■リスク評価
プロジェクトのリスクを評価し、リスクの特定、分析、軽減策の検討を行います。
■開発と検証
要求仕様に基づいて、システムの設計・開発・テストを実施します。各スパイラルで新たな機能や要求を追加することができます。
■顧客との対話
開発された成果物を顧客やユーザーに提供し、フィードバックを収集します。顧客の要求が満たされるか、プロジェクトの方向性が適切かを確認します。
■次のスパイラルの計画
取得したフィードバックや新たな情報を元に、次のスパイラルの計画を策定します。新しい目標やリスクの評価を行います。
スパイラルモデルは、プロジェクトの変更に対応する柔軟性を持ちながらも、リスクをコントロールし、プロジェクトを進化させるための手法です。スパイラルモデルは、複雑なプロジェクトや高いリスクを伴うプロジェクトに適しており、各反復サイクルで詳細な計画を策定することで、プロジェクトの成功確率を高めることができます。
4.まとめ
いかがでしたでしょうか？今回はシステム構築の工程や手法についてご紹介しました。システム構築手法は実際には企業やシステム開発部門内で共通のルールが細かく決まっているケースが多いです。
また、プロジェクト管理ツールとの相性などもあるので「この手法が一番良い」というものはありません。皆さんの職場において、どんな手法が良いのか話し合って、皆が納得できるシステム構築手法を選択しアレンジしましょう。
最後にH&Kが取り組んでいるシステム構築の事例を2つ紹介します。
〇CUC様
医療系CRMデータベースの整備と、オペレーションDXの実現
詳細はこちら
〇ニューズピックス様
【キャンペーン施策支援】カスタマージャーニーの一貫したデータ運用で、マーケティングのボトルネックを可視化
