Webシステム担当者のための入門ガイド～ITベンダーとのプロジェクト推進編～

更新日：2025年6月13日

こんにちは！
企業の情報システム部門に配属され、Webシステムの担当になったものの、「Webシステムを扱うプロジェクトでITベンダー（開発者）はどのように開発を進めているのだろう…」 「発注者として、ITベンダーとどのようにやり取りすれば良いのだろう…」という方も多いのではないでしょうか。 本記事では、プロジェクトにおけるITベンダーの業務内容や 、各工程でのITベンダーとのやり取りにおいて意識すべき基本的なポイントを解説します。

ITベンダーとのプロジェクトを進めていくうえでぜひお役立てください！

※Webシステムの概要について知りたい方は、以下の記事もあわせてご確認ください。
★コラム：「Webシステム担当者のための入門ガイド～Webシステムの基本編～」

1. Webシステムはどうやって作られていく？

Webシステムの担当者となりプロジェクトを進めていくには、開発者がどのような手法を用いてシステムを作るのか、また、どのような業務を行うかを理解しておくことが重要です。そこで、本コラムでは代表的な開発手法と、Webシステム開発における主な業務内容について紹介します。

1-1. 代表的な開発手法

1-1-1. ウォーターフォールモデル

ウォーターフォールモデルは、開発の各工程を順番に進めていく方法です。
ここでは、V字モデルの基本的な項目に絞って簡単に説明します。

■開発の流れとそれぞれ対応するフェーズを表したV字モデル

システムの開発

■要件定義

システムで解決したい問題や必要な機能を明確にします。要件には、業務要件とシステム要件があり、さらにシステム要件には、機能要件と非機能要件があります。

■設計

要件定義を元に、システムの具体的な設計を行います。設計には基本設計（システム全体の仕組みを決めるもの）、詳細設計（内部の詳細な仕組みを決めるもの）などがあります。

■プログラミング

設計に基づいて、実際にプログラムを作成します。プログラミング言語を使って、システムが動くようにコードを書きます。

■テスト

作成したプログラムが設計通りに動くか、問題がないかを確認します。テストは単体テスト、結合テスト、システムテスト、受入テストなどを順番に行います。

テストが完了したら、本番環境にシステムをリリース（移行）します。これでシステムの開発は完了です。

システムの運用・保守

システムの開発が完了したら、そのまま放っておいて良いわけではありません。リリース後には、そのシステムのサービスが終了するまで、安定した稼働を維持するために、「運用・保守」という作業が必要です。
そういったシステムの企画段階から開発・リリース、そして運用・保守に至るまでの一連の流れを、「システム開発ライフサイクル（SDLC）」と呼びます。
リリース後も、日々の管理やメンテナンスを行い、トラブルや不具合が起こった際には速やかに対応・復旧することが求められます。
以下では、運用と保守の具体的な役割について説明します。

■運用

システムの運用は、システムが安定して稼働し続けるように、日々監視や管理を行う業務です。定期的なデータバックアップは、システム障害やデータが損失した際、速やかにデータを復旧させるために重要です。また、システムのセキュリティ管理も欠かせません。例えばWebシステムでは、インターネットを介して多くの人がアクセスできることからDDoS^※をはじめとしたさまざまな攻撃が行われた際に、即座に対応できるように準備をしておく必要があります。また、定期的なセキュリティチェックやサーバ証明書の更新を行い、システムの安全性を確保します。
※分散型サービス拒否攻撃(Distributed Denial of Service)の略。多くの送信元から特定のサーバやネットワークに大量のトラフィックを送り、サービスを利用不能にする攻撃

■保守

システムの保守は、故障や不具合が発生した際の対応や、システムへの新規機能追加を行う保守開発業務が含まれます。障害が発生した際には、迅速に対応し、システムを正常な状態に戻すことが求められます。障害は予測できないため、日頃から障害対応の手順を整備しておき、障害発生時には速やかに復旧作業を行える体制を整えておくことが重要です。また、システムの機能追加や改善を行い、ユーザーのニーズを反映させてシステムを常に進化させることも求められます。加えて、利用しているソフトウェアのバージョンが保守サポート終了する際には、新しいバージョンへのアップデート対応も必要です。保守工程ではこのようなさまざまな活動により、システムの安定した稼働の維持と、さらに良いシステムとなるよう改善を進めます。

このように、ウォーターフォールモデルは、各工程を順序立てて進めるため、進捗管理がしやすく、大規模な開発プロジェクトに適しています。
しかし、一度工程が完了すると成果物が確定するため、前の工程に戻らないことが前提であり、途中での仕様変更が難しいというデメリットがあります。
そのため、ウォーターフォールモデルでシステム開発を進める場合は、事前に要件をしっかり固めたうえで取り組むことが重要です。

1-1-2. アジャイルモデル

近年、アジャイルモデルで開発することも多くなっています。
アジャイルモデルでの開発では、開発を小さな単位で繰り返し、改善しながら進めていきます。これにより、仕様変更があった場合でも柔軟に対応でき、素早く開発を進めることができます。ビジネスのスタートを早めたい場合に特に適しています。

アジャイルモデルについて詳しく知りたい方は、以下の記事をご覧ください。
出典：Fintan「アジャイル・スクラム」

1-2. 「アプリケーション開発」と「インフラ構築」とは

システムを開発する際、多くのプロジェクトでは「アプリケーション開発」と「インフラ構築」の2つのレイヤーに分けて進めることが一般的です。アプリケーションとはユーザーが直接操作するソフトウェアのことです。アプリケーション開発はそのソフトウェアを設計・実装する作業を指します。一方、インフラ（インフラストラクチャの略）とはアプリケーションが動作するための基盤となる環境のことです。インフラ構築は、その環境を整備・構築する作業を指します。

アプリケーション開発

■クライアントサイド（フロントエンド）

クライアントサイド開発は、ユーザーが実際に触れる部分を担当します。Webページに表示される内容を作成するため、使いやすく、見た目もわかりやすい画面を提供することが求められます。ユーザーが快適に使えるようなデザインを意識して開発します。

■サーバサイド（バックエンド）

サーバサイド開発は、システムの設計やデータ処理を担当します。ユーザーが直接目にしない部分ですが、サーバサイドはシステムがどう動くかを決める重要な役割を持っています。具体的には、データベースの設計やAPIの設計、サーバサイドのプログラムを作成します。また、セキュリティ対策やパフォーマンスを考慮し、システムを最適化することも重要です。

インフラ構築

インフラ構築は、システムが動作するための基盤となる部分を担当します。具体的には、サーバやネットワークの設計・構築などを行います。更に基盤環境で担保すべきセキュリティ対策も多くあり、セキュリティ面の考慮が欠かせません。最近ではクラウドサービスを使ったインフラ構築が一般的になっており、インフラエンジニアにはクラウドサービスを活用するスキルも求められます。

クラウドについて詳しく知りたい方は、以下の記事をご覧ください。
★コラム：「Webシステム担当者のための入門ガイド～クラウドの基本編～」

これまで、Webシステムがどのように作られていくか、そしてどう維持されるのかを説明してきました。外部のITベンダーに開発を委託する場合は、上記の工程・業務をITベンダーが担います。自社で開発する場合は、これらの業務を自社内で担当することになります。
いずれの場合であっても、「どのようにシステムが作られていくのか」を把握しておくことは、スムーズな進行や適切な判断につながるため、非常に重要です。

2. 各開発工程で担当者として押さえておくべきポイントは？

ここからは、Webシステムの開発を外部のITベンダーに委託するケースを想定して説明していきます。

■委託開発のイメージ図

Webシステムを委託開発することになったものの、「各工程では具体的に何をすれば良いのだろう？」と戸惑う方も多いのではないでしょうか。

そこで、これまで我々TISがWebシステム開発の委託を受け、実際にクライアントとお仕事する中で、「こういう観点を持っていただけるとシステムエンジニアは嬉しい」と感じるポイントを、要件定義から運用・保守までの各段階に沿って紹介します。
大まかな流れとポイントは、以下の図の通りです。

■各フェーズでのポイントを示した図

なお、以降は、Webシステムの構築において活用されるケースが増えているクラウド環境での開発を例として説明していきます。

クラウドについて詳しく知りたい方は、以下の記事をご覧ください。
★コラム：「Webシステム担当者のための入門ガイド～クラウドの基本編～」

それでは、各フェーズでのポイントを詳しく見ていきましょう。

2-1. 要件定義

まずは要件定義工程があります。押さえておきたいポイントは以下です。

要件の明確化

基本的に、クライアントの要件に合わせてITベンダーがシステムの構成を検討します。そのため、機能・非機能要件を社内で事前に整理した上でITベンダーに伝えると、理想のシステムに近づけることができます。

検討しておくべき基本的な機能要件、非機能要件については、以下の記事を参照してください。
★コラム：「Webシステム担当者のための入門ガイド～クラウドの基本編～」

また、要件の考え方や伝え方において、特に以下のように伝えていただけるとエンジニア側も誤解することなく要件を理解しやすくなります。

①重要度の高い要件、およびその理由を明確に伝えること

各要件については、重要度や優先度、その機能が必要な背景を具体的に考えましょう。その際、コストとスケジュールのバランスを考慮し、「絶対に必要な要件」と「あれば良いが必須ではない要件」というように分類しておくことが重要です。各要件の重要度を分類するにあたっては、以下の観点で検討すると良いです。

• コスト面での優先度：予算が限られる中で、コストをかけてでも絶対に実装したい機能なのか
• 時期的な必要性：システム稼働当初から必要な機能なのか、それとも将来的に必要だが初期リリースには含めなくても良い機能なのか
• 要件未達時の影響度：その機能を要件通りに実現できなかった場合、どの程度システムに影響があるか、またその影響をどこまで許容できるか

このような情報を明確にしないと、ITベンダーが開発している途中で認識のズレが生じ、設計や開発の手戻りが発生して、追加コストや納期遅延のリスクが高まります。

②「現行踏襲とは何か？」を考えること

プロジェクトによっては、自社で管理している既存Webシステムをクラウドへ移行するケースもあるでしょう。その際、「今使っているシステムと同じ機能のままクラウドに移行したい」という気持ちはよく理解できます。しかし、「今のシステムと同じ（現行踏襲）になるように」という伝え方をすると、発注側とITベンダー側で「何をもって『同じ』になるのか」の捉え方に差異が生じ、結果として「思っていたものと違う…」「現行と同じ操作ができない…」というシステムが完成してしまうかもしれません。

そのため、「『今のシステムと同じ』というのが、具体的に何の機能がどのように動くことなのか？」を明確にしていくことでITベンダーとの認識のズレを防ぎ、完成後のシステムが期待通りのものになる可能性が高まります。

クラウド移行の概要について知りたい方は、以下の記事をご覧ください。
★コラム：「システムのクラウド移行とは？メリットやリスク、失敗しないポイントを解説」

自社規定の確認および共有

要件定義の段階では、自社の規定やルールに関する情報をぜひ共有しておきましょう。多くの企業には、システム開発において遵守すべき社内規定が存在しており、これらをITベンダーに伝えておくことがスムーズな設計・開発のために重要です。

特に、セキュリティに関して多くの企業ではシステム開発におけるセキュリティ対策の基準があり、これに準拠できていないシステムは最悪の場合、完成してもリリースできないという事態になってしまう恐れもあります。こうした規定を要件定義段階で共有できていないと、開発完了後に「社内セキュリティ監査に通らない」という事態が発生し、リリースが大幅に遅延してしまう事態を招くこともあります。

このように、要件定義の初期段階で自社の規定を明確にしてITベンダーに共有しておくことは、後々の手戻りを防ぎ、プロジェクトを無駄なく進めていくために必要不可欠です。我々エンジニアとしても最初からこれらの条件を踏まえた設計ができると、より質の高いシステムを提供することができるのです。

要件変更・追加に伴う留意事項の把握

当初の要件から追加・変更が発生するたびに費用は膨らみます。クラウドは使った分だけ料金が発生し、選んだサービスや使用時間によってコストが変わります。また、追加・変更したシステム機能を実現するための開発作業にも人的コストがかかります。要件を事前にしっかりとご検討いただけていないと後から新しい要件が頻繁に出てくる場合があり、それらを実現するための追加費用が発生し、予算オーバーの原因となることがあります。

また、途中でシステムに関する依頼事項が発生した場合は、早めにITベンダーに相談するとよいでしょう。クライアントとITベンダーでは作業の対応インパクトの考え方に大きな差があることがあります。例えばクライアントにとっては「簡単な機能だから数日でできるはず」と思われる内容が、実際には設計・開発・テストを含めると2週間以上かかるケースも珍しくありません。追加したい機能や要件が出てきた段階で早めに相談することで、適切なコスト/スケジュール調整が可能になり、エンジニアとしても最適な対応ができると考えられます。

2-2. 設計

設計を担当するのはITベンダーですが、ただ設計書が出来上がるのを待つだけではなく、クライアントも以下のことに関わっていくと、より良い設計内容での合意形成が図ることができます。

設計内容の確認

ITベンダーから受け取った設計書は、自社の要件がきちんと反映されているか確認しましょう。特にセキュリティに関する設計は非常に重要です。セキュリティ対策が不十分だと大きなリスクにつながる可能性があります。そのため、不明点があれば社内の基準を確認したり、ITベンダーに質問したりして不安を解消することが推奨されます。

コストの確認

設計段階で、開発にかかる具体的な費用が見えてきます。特にクラウドの場合は使うサービスや使い方によって料金が変わるので、見積もりが予算を超えてしまいそうな場合は、ITベンダーと設計の見直しを相談するか、社内で追加予算の検討をしましょう。

2-3. 構築

設計を担当するのはITベンダーですが、ただ設計書が出来上がるのを待つだけではなく、クライアントも以下のことに関わっていくと、より良い設計内容での合意形成が図ることができます。

ユーザーテストの準備

テスト工程では、クライアント側でもシステムの動作確認を行う必要があります。よりスムーズに進められるよう、以下の点について事前に整理しておきましょう。

• 新システムの基本的な操作方法（画面の使い方、アクセス方法など）
• 実施するテストの内容・合格条件・結果のまとめ方法や手段
• テストで問題を発見した際のITベンダーとのやり取りの方法
• テストを始める時期と進め方

2-4. テスト

Webシステムを本番環境で稼働する前の最終テスト段階です。この段階でクライアント自身のテストによって、業務上必要なことが新しいシステムで実現できるのかを確認することになります。また、ITベンダー側でもシステム状況の最終確認がされ、その結果が共有されます。これらのテスト結果を確認し、リリースしても問題がないか判断しましょう。

また、ITベンダー側で実施するシステムテストで問題が見つかった場合、原因の調査から設計のやり直し、大幅な設定見直し等などが必要になるケースもあり、そうなるとITベンダーが単独で解決するのは大変です。そのため、システムテストで問題が発生した時に調整する手立てをあらかじめ用意しておくとともに、実際に問題が発生した際はITベンダーと緊密に連携し、今後の対応策を一緒に検討することが重要です。

2-5. 運用・保守

Webシステムの保守・運用作業もITベンダーに任せる場合は、定期的に運用実績を報告してもらい、システムの状態（監視状況や問題の発生状況など）を確認しましょう。その際、以下のポイントに気を付けると良いでしょう。

ITベンダーが行う保守・運用の範囲（契約内容）

ITベンダーとの保守・運用契約では、作業範囲や費用の計算方法（月額固定やポイント制など）が決められています。契約範囲を超える作業は追加費用が必要なため、以下の点を意識しましょう。

• 契約で定められたITベンダー側で実施する作業範囲を確認する
• ポイント制の場合は、残りのポイント数を定期的に確認する
• 契約範囲やポイントを超えそうな場合は、早めの予算確保を検討する

また、必要に応じてITベンダーと定期的に運用状況を確認し、計画的に作業を依頼することもおすすめします。

定期的なアップデートの検討

クラウドサービスは定期的に機能更新があるため、システムへの影響を考慮する必要があります。更新情報を日々チェックし、アップデートが必要な場合はITベンダーにも相談してください。

障害発生時の対応

システムに障害が発生した場合は、ITベンダーへの連絡と並行して、社内の関係者の皆さんへの報知等も必要になります。迅速な対応ができるよう、ITベンダー側の緊急連絡先や社内の報告ルート、ユーザーへの連絡方法を事前に確認しておきましょう。また、これらの情報は社内の関係者へ共有し、いつでも確認できるように管理しておきましょう。

3. プロジェクトを成功させるための秘訣

情報システム部に配属されたばかりの方は、初めは何をすべきか分からず、戸惑うことも多いかもしれません。

システムがビジネスの競争力に大きな影響を与える現代において情報システム部の皆様の役割は、企業の中核を担う重要な仕事であると我々は考えています。この記事ではITベンダーとのやり取りに注目していますが、システムに関するプロジェクトを成功させるためには、社内の関係部門の方含め多くのステークホルダーがプロジェクトに関わることが必要不可欠です。情報システム部の皆さんは社内の各部門とITベンダーの橋渡し役として全体の調整役を担うことが多くあります。このようなことを意識しながら、プロジェクトを成功に導き、ビジネスを成功させましょう。

その他にも、仕事をするうえで、配属されたばかりの担当者がつまずきやすいポイントとその対策方法についてのヒントをお話しします。

3-1. Webシステムの内容に関して

ハイブリッドクラウドは複数の異なる環境を統合して管理する必要があるため、構成が複雑化しやすく、管理や運用の難易度が高いことがデメリットです。
単一のクラウド環境を利用する場合と異なり、パブリッククラウドやプライベートクラウド、オンプレミスなど複数の環境間でのシステム連携が必要になります。
そのため、ハイブリッドクラウドでは処理の効率性が求められるなど高い技術力が必要とされ、セキュリティ管理などにおいても複数の異なる環境をカバーできる高度な運用体制とスキルが求められます。

技術用語や概念の意味を覚えるために

最初の大きな壁として、ITやWebシステムに関する専門用語や概念が分からないことが挙げられます。日常的に聞き慣れない言葉がたくさん出てきて、困惑するかもしれません。これらの言葉を意味がわからずにいると、プロジェクトの会話についていけなくなることが多々あります。

システム全体の構造を理解するために

Webシステムは多くの要素から成り立っています。フロントエンド、バックエンド、データベース、APIなどがどのように連携して動作するかを理解するのは、最初は難しく感じるかもしれません。特に、どこに何の処理が行われるのか、どこでデータが保存され、どう処理されるのかを知ることが重要です。

3-2. 効率的なシステム開発に向けて

ここまでITベンダーに委託して一からシステムを構築する場合を例に説明してきましたが、それだけがWebシステム開発の選択肢ではありません。毎回すべてを初めから構築すると時間もコストもかかり、大変になる場合も多いです。

4. まとめ

いかがでしたか？
このように、Webシステムの開発にはさまざまな工程があり、ITベンダーに開発を委託する際にクライアント側で把握・注意すべきポイントが数多く存在します。

しかし、WebシステムをITベンダーに委託する場合でも、一からすべて開発してもらうとなると、とても大変に感じることがあります。

ちなみに…
TISには「デジタル基盤オファリングサービス」というものがあります。これはAWSとTISの自社データセンターを使ってお客様に最適な基盤環境を提供するサービスです。TISが強みとする決済領域の自社ブランド”PAYCIERGE（ペイシェルジュ）”で培った安心・安全なインフラ基盤を活用して、更にお客様のDX推進をサポートする各種サービス群と先進テクノロジーを習熟したサービスアーキテクチャコンサルティングチームの支援によりお客様のビジネス成功をトータルサポートします。
このサービスを使うことで皆さんは作りたいWebサービスの機能開発に集中し、アイデアを実現することができます。

ぜひ、この機会に利用してみてください。
★TISデジタル基盤オファリングサービスの詳細はこちら

Webシステムの開発プロジェクトを担当することになった際は、基本的な構成や仕組みを理解しておくことが大切です。
Webシステムの開発プロジェクトを担当するにあたり、不安を感じることもあるかもしれませんが、学んだ知識を業務で活かしながら、少しずつ理解を深めていきましょう。
なお、本シリーズでは、今後も企業の情報システム部門に配属されたばかりの方を対象に、ITに関連する基本的な知識から、実際の現場で活かせる情報を幅広くお届けしていく予定です。
ぜひお楽しみに！

関連サービス

本コラムの執筆者

渡邉　千春

2023年度新卒でTIS入社。PAYCIERGEのクラウド領域を担当。マルチクラウドや生成AI活用など日々新たな挑戦を重ね成長し、先進の知見を持ってお客様の"DX実現"というチャレンジの成功に貢献することを目指す。

浦上　寧々

2024年度新卒でTIS入社。PAYCIERGEのクラウド領域を担当。学生時代に社会課題解決の研究・取り組みを行った経験を活かし、システムのプロとして地方創生等TISが手掛ける社会課題解決の実現を目指す。