システム構築の基礎と構築計画－基本的な内容の理解と構築計画の流れ

AIをはじめとする最新技術やDXによるビジネス革新が秘めた可能性が取り沙汰され、昨今のIT分野への期待は増すばかりであると感じます。この機運に乗じて、新規システムの構築を考える企業も増えていることでしょう。

しかし、ITシステムの構築を検討する場合、幅広く深い知見や複雑な技術の理解が必要であり、そのようなノウハウや優秀な技術者を持たない企業には極めて高いハードルです。

特に、IT分野での就職を目指している方や新しく会社のIT部門に配属された方など、まだ経験が浅い方には、まず何から学び、何から手を付け始めればいいのか、出発点のところから分からないと思います。

本記事では、システム構築を基本的な内容から解説し、システム構築を検討するにあたって押さえておくべき前提知識、システム構築の流れ、構築を計画する際のポイントや注意点を説明します。

なるべく初学者にも分かり易い情報提供を努めますので、システム構築の基礎学習や構築を検討する際の参考となれば幸いです。

システム構築とは何か

はじめに、システム構築の定義や基本知識、構築の目的、そもそもどのようなことをするのか等を説明します。

システム構築の定義

システム構築とは、ハードウェアおよびソフトウェアを組み合わせたITシステムを設計し、作り上げて利用を開始するまでの一連の流れを指します。

システム構築と似たような言葉として「システム開発」が用いられますが、厳密には次のようなニュアンスの違いがあります。

システム構築：既に存在する部品を組み合わせてシステムを作り上げる

システム開発：新規にシステムの部品を製造する

要するに、システム開発は新規にハードウェアやソフトウェアなどの部品を製造します。ハードウェアを新たに作るには製造設備が必要なので、そのような機会はなかなか無いかもしれません。一方、１からプログラムやWebデザインを作るなどして、新規にソフトウェアを開発することは珍しくありません。

システム構築をする場合、ハードウェアは既存製品を利用し、組み合わせるアプリケーションは新たに開発するというケースもあり、この場合はシステム構築の１工程としてシステム開発が含まれるような関係性があるとみなすことができます。

このような関係性から、システム全体あるいはインフラ部分（サーバやネットワーク機器、ミドルウェアといった基盤部分）を作る場合は「構築」、その上で稼働するアプリケーションを作る場合は「開発」といった使い分けをする例もよく見られます。

システム構築の各工程

まずはじめに、システム構築の各工程について理解していきましょう。

一般的にシステム構築・システム開発の工程は、次の流れで行われます。

1. 要件定義
2. 基本設計（外部設計）
3. 詳細設計（内部設計）
4. 構築（開発）
5. 単体テスト
6. 結合テスト
7. 総合テスト（システムテスト）
8. 移行
9. 運用・保守

これら各工程の詳細は、こちらの記事で説明していますので、是非参照してください。

システムの目的

システムは、実に様々な目的で構築されます。例えば、次のような目的を挙げることができます。

• 業務の効率化
• 生産性の向上
• 人件費削減
• 新規ビジネスの遂行

構築するシステムの目的を明確にすることは、大変重要です。システム構築の失敗例としてありがちなのは、ITシステム化すること自体が目的となってしまうことです。

システム構築を検討する初めの段階で、「システムを導入することで何を実現したいのか」をきちんと明確にすることで、定めた目的を実現できるシステムを構築できます。

システムの構成要素

システムの構成要素を説明します。

ハードウェア

ハードウェアは、装置、設備、部品といった物理的な構成要素です。

例えば、次のようなものをハードウェアとして挙げることができます。

装置：コンピュータ、ストレージ、ネットワーク機器、UPS（無停電装置）

設備：サーバラック、LANケーブル、ディスプレイ

部品：CPU、メモリ、ハードディスク

ソフトウェア

物理的に実体を持たないプログラムをソフトウェアといいます。

プログラムは、データを処理するためのコンピュータへの命令の集合です。

システムが行う様々な処理はこれらプログラムによって行われるため、要件定義で定めるシステムの機能要件は、基本的にソフトウェアによって実現されるといえます。

システム上で稼働するソフトウェアには、初めからハードウェアに組み込まれたもの、インストールして使用するもの、実行ファイルを配置して起動できるものなど様々な種類があります。

ネットワーク

システム上で処理されるデータは、システム内外の様々なハードウェアおよびソフトウェアでやりとりされます。それらのやりとりは、ネットワークを介して行われます。

システムを構成するハードウェア、ソフトウェアにそれぞれネットワークに関する何かしらの設定があります。

システム構築の手法

続いて、システム構築の手法について説明します。

構築の手法はいくつかあるのですが、ここでは次の手法をピックアップして説明します。

1. ウォーターフォール・モデル
2. アジャイルソフトウェア開発
3. プロトタイプ・モデル
4. スパイラル・モデル

これらの構築手法については、詳細をこちらの記事で紹介していますので、是非参照してください。

システム構築を計画する

この章では、システムを構築する前段階の計画方法について説明します。

内製でシステムを構築する場合も、SIerなどのITベンダに構築を依頼する場合も、今回の内容は重要であると考えますので、是非参考にしてください。

なお、本章で説明する内容の詳細は、IPA（独立行政法人 情報処理推進機構）が公開している以下の資料に基づいています。実際にシステム構築を検討する際は、是非こちらも参照してください。

https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf

システム化の目的や課題の整理

まずは、システムを構築することで何をしたいのか、何を解決したいのかを整理しましょう。

これはシステム構築の全工程に渡って根幹となる部分ですので、ここがしっかり定まっていないと工程がスムーズに進まなかったり、期待に見合うものでないシステムが出来上がることにもなりかねません。

システムの現状を把握する

システムの目的を定め、課題を洗い出すためには、現行システムの状況を把握する必要があります。現状がまだシステム化されていない場合は、現状の業務プロセスを把握しましょう。

また、把握した内容はドキュメント等で可視化すべきです。

既に現行システムのドキュメントが存在する場合も、ドキュメントの内容とシステムの実態との間に乖離がないか確認した方が良いでしょう。

場合によっては、現行業務の再学習が必要になるかもしれません。

現状を理解・共有する

現状の業務やシステムには、作業の分担などによって一部属人的なプロセスが潜んでいる場合があります。分担されていた作業が組み合わさると新たな課題に気付く場合もあるため、業務プロセス全体を理解して共有する必要があります。

全体的な業務プロセスの理解を徹底してシステム化を行えば、システムおよびシステム上で行われる処理や運用の整合性も高まります。

ステークホルダーを漏らさない

業務プロセスには、様々なステークホルダー（利害関係者）が関わります。例えば、次のようなステークホルダーが想定され、それぞれで立場や問題意識が異なります。

　・経営層・事業部門長など

　・マネージャ・リーダーなど

　・実務スタッフなど

ここで注意すべきは、すべてのステークホルダーが抱える要望や課題を聞き入れる必要はないということです。システムに求められるのは、基本的に経営レベルでの貢献です。

各ステークホルダーの抱える要望や課題意識の洗い出しは必要ですが、それら洗い出した要望や課題を聞き入れることが最終的なゴール達成に必要か、判断して取捨選択しなければなりません。

目的・目標を決める

システム化をすることで、どのような目的や目標を達成したいかを明確にします。

システムの構築には多額の費用を必要とし、ビジネスにおける大きな投資となります。構築したシステムによって実現したい目的や目標を明確に定めることで、投資した分のリターンをより大きなものにすることができます。

システム化の目的や目標は、経営レベル、業務レベルでそれぞれ検討する必要があります。

達成したい目的や目標が複数挙がると思いますが、メインゴールやサブゴールなどの優先度付けもしておきましょう。

システム要件の明確化

システム化の目的や解決したい課題が整理できたら、それらをシステム要件として落とし込みます。システム構築をITベンダに依頼する場合は、この要件定義から依頼することができますが、その場合も実現したい要望を依頼先のITベンダに漏れなく正確に伝えた方が、構築するシステムはより期待に沿ったものになり、工程進捗もスムーズなものとなります。

したがって、システムを内製するか他社に依頼するかに関わらず、システム要件は予め明確にしておきましょう。

本記事「要件定義」の内容をおさらいしますが、システム要件は機能要件と非機能要件に大別されます。前章「システム化の目的や課題の整理」の内容は、機能要件に該当します。経営レベルの目標、業務レベルの目標を達成するために、システムにどのような機能を持たせるかということです。

非機能要件は、システムが提供するサービスの品質に関わる要件です。具体的にどのような要件を検討するべきかは、IPAが公開している非機能要件グレードを参考にしてください。

▼情報処理推進機構 システム構築の上流工程強化（非機能要求グレード）紹介ページ

https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html

非機能要求グレードは、上記ページにて、以下赤枠で囲ったリンクのどちらかをクリックすることで入手可能です。”2018”とありますが、現時点で最新版となります（2024年8月時点）。

構築・開発依頼先の選定

この章以降「３〜 ６」は、システム構築をSIer企業等のITベンダに依頼する場合の説明です。

システム要件を明確化できたら、依頼先メーカーの選定を行います。本当に課題解決や要件定義に協力してくれる価値あるベンダ企業であるか、見極めるための明確な基準を設定しておくと良いでしょう。

選定のポイントとして、次のような例を挙げることができます。

1. 構築・開発実績の豊富さ
2. 得意分野、強み
3. 担当者との相性
4. アフターフォローは充実しているか
5. 経営状況

構築・開発実績

ITベンダによって、構築・開発実績のあるシステムは異なります。その企業のWebサイトに掲載されている実績ページや、営業に話を聞くなどして、希望するシステムのイメージに近い構築・開発実績があるITベンダを選びましょう。

得意分野、強み

得意とする分野や技術も、ITベンダごとに特色があります。実績同様、希望するシステムのイメージに合わせて、特定の業界への強みや得意な技術があるかを確認しましょう。

担当者との相性

システム構築を他社に依頼する場合、システムの導入を終えた後も長い付き合いになる可能性があります。なぜなら、構築・開発を担当しているのでシステムの仕様を把握しており、システムの更改や新機能の追加などを依頼し易いためです。

そのため、ITベンダの営業やSEとの相性は、構築・開発の依頼先を決める上でとても大事なポイントとなります。

アフターフォローの充実さ

システム開発後は運用フェーズとなり、システムの管理が必要になります。システム構築・開発を外部に依頼する場合、システム導入後の運用・保守も含めて、構築・開発を引き受けたITベンダに依頼するケースも珍しくありません。

その場合は当然、運用・保守のサービス内容が充実しているITベンダの方が好ましいです。

経営状況

意外と見落としがちなのが、依頼先となるITベンダ企業の経営状況です。

システム構築の工程途中で依頼先企業の経営状況が悪化した場合、工程の中断、最悪はプロジェクトが頓挫することも考えられます。

また、通常ITシステムは導入後数年から十数年に渡って運用し続けます。

構築・開発工程途中やその後の運用・保守期間中に依頼先ITベンダ企業がサービス提供を継続できなくなった場合は、他の引き受け先企業を探すのに大きな労力を必要とすることが考えられるため、依頼先ITベンダの経営状況は注視するべきです。 

ＲＦＰの作成

RFPは Request for Proposal の略で、「提案依頼書」のことです。

依頼先候補となるITベンダを列挙した後は、各依頼先に構築・開発したいシステムの要件を伝えて工期や費用の見積を提示してもらう流れとなります。

その際に依頼先候補に伝えるシステム要件をRFPとしてまとめて提出します。

要するに、「システム要件の明確化」で明確化したシステム要件を基に、依頼先候補に見積を依頼するためのRFPを作成するわけです。

様々な企業や組織がRFPのサンプルをWeb上で公開しているので、それらの記載内容やフォーマットを参考にするといいでしょう。

▼特定非営利活動法人 ITコーディネータ協会 RFP・SLAドキュメント見本ページ

https://www.itc.or.jp/foritc/useful/rfpsla

提案書や見積の評価

システム構築の各依頼先候補より、システム要件やRFPを基に提案書や見積を提示してもらった後は、それらを評価します。

提案書や見積を評価にあたり、その評価基準を予め設定し、内々で共有しておく必要があるでしょう。

提案書の評価

評価基準は、構築するITシステムの要件や前提条件、制約などによって変わってくると思いますが、例えば次のような評価項目を挙げることができます。

• 依頼時に指定したフォーマットで回答しているか
• 依頼事項に漏れなく回答しているか
• プロジェクトリーダーの経験は充分か
• 導入体制や運用体制は充分か
• 導入計画は適切か
• 将来を見据えた提案がされているか

例えば、これらの評価項目ごとにスコアを設定し、なるべく定量的に評価を行えるような仕組みを用意すると、より客観的な評価や比較を行うことができます。

IPAによる提案書の評価項目一覧表も公開されていますので、そちらも是非参考にしてください。

https://www.ipa.go.jp/choutatsu/nyusatsu/2023/t6hhco00000068hd-att/nyusatu20230714ex.xlsx

見積の評価

見積の評価について考える前に、システム構築を依頼する前に精度の高い見積を作成することは不可能であるという前提を理解する必要があります。

はじめから完璧なシステム構築計画を立てることができれば理想的ですが、それはやはり理想であり、細かい仕様については後々詰めていくといった箇所も必ず出てきます。

したがって、構築依頼前の見積には不確定な要素があると合意形成し、確定するまで不確定要素の変化を監視して、決まった時点で再見積をしていくという考え方が重要です。

この前提を踏まえた上で、見積の評価について考えていきます。

提案書と同様に、評価は基準を定めた上で定量的に判断するとより客観的な視点で評価することができ、検討メンバー間の意志疎通もスムーズとなります。

構築するシステムによって重視することに違いがありますが、例えば次のような評価項目を設定することができると考えます。

• 見積の対象が明確であるか
• 見積の根拠となる作業規模に妥当性はあるか
• 必要な人員の規模に妥当性はあるか
• 構築の主要工程だけでなく、調査や検証といった付随作業も含まれているか
• システムのライフサイクルを通じて必要となる作業が明確にされているか
• ITベンダとユーザの責任範囲が明確にされているか
• 購入物やレンタル品の金額が含まれているか
• 費用総額が予算に収まっているか
• 検収方法・検収条件は明確になっているか

依頼先ITベンダの決定

各依頼候補先より提出された提案書や見積の評価より、最終的に依頼先とするITベンダを決定します。予め設定した明確な評価基準を以て、総合的に依頼したいITベンダにシステム構築を依頼しましょう。

依頼後に重要となるのは、システム構築は依頼先であるITベンダと依頼元であるユーザのそれぞれに担うべき責任があり、互いに協力して進めていくべきであるということです。

依頼先ITベンダにすべての責任や検討事項を丸投げしてしまうと、最終的に期待に沿わないシステムが出来上がってしまいます。

まとめ

さて、今回はITシステムの構築に関して、基本的な事項から始め、構築を始める前段階の計画について説明してきましたが、いかがでしたでしょうか。

ITシステムの構築は莫大な費用と時間を必要とするため、企業にとっては大きな投資となります。期待通りのシステムを構築できれば大きなリターンを得ることができますが、期待通りの成果を得られなかったり、工程がスムーズに進まず費用の膨大化や計画の頓挫など失敗に終わった例もあります。

システム構築を成功に導くには、システム構築の基礎を理解したうえで、入念な準備に基づいて計画を進めていく必要があります。

ITシステムへの需要や期待は今後も高まっていくことが予想され、企業経営においてITへの投資は避けて通れない時代です。この記事が、戦略的なITシステムへの投資を進めるうえで参考になれば幸いです。