複数の企業がプロジェクトに参画し、分業しながら進めていくことが多いシステム開発。すでにエンジニアとして活躍している人でも、「自分が担当する工程以外はあまり知らない」「システム開発の全体像が分からない」という人は少なくないのでは？

この記事では、基本的なシステム開発の工程や、代表的な開発手法であるウォーターフォールモデルやアジャイルモデルなどについて紹介します。その他、システム開発の現場で頻出する略語についても合わせて解説。

プロジェクト開発についての理解を深め、これからのキャリアについて考えるきっかけにしてみましょう。

システム開発工程とは？

まずはシステム開発における各工程でどのようなことが行われているのかを詳しく解説します。一般的には、要件定義に近いほど上流工程と呼ばれ、保守や運用に近いほど下流工程と呼ばれます。

ただし、一口に「システム開発の工程」といっても、プロジェクトの規模や開発手法などによっては明確に分かれていなかったり、省略されたりすることもあります。現在自分が担当している工程はどのあたりなのか、将来的にどのような工程に携わりたいのかなどを考えながら読んでみてくださいね。

要件定義（要求定義）

要件定義の工程ではクライアントと共に、これからどのようなシステムをどんな開発手法で作るのか、導入や運用方法、予算、開発期間など、システム開発に必要な要件を決めていきます。この話し合いの場にはベンダーが参加するのが一般的ですが、プロジェクトの規模によっては開発会社のPMやPL、SEなども参加することがあります。

システム開発は、要件定義で決めた内容に基づいて進んでいくため、最終的にトラブルが発生しないように、クライアント側と開発側の双方が認識を合わせておくことが必要です。要件定義は開発工程における設計図を作る“最上流工程”であり、もっとも重要なフェーズといえます。

基本設計（外部設計）

基本設計は、要件定義の工程で決めた内容を基に、主にインターフェース（ユーザーから見える部分）を決定する工程です。プロジェクトの規模にもよりますが、基本設計書は一般的にシステムの機能ごとに作成されます。

各システムを担当するシステム会社のエンジニアが基本設計書を作成し、それぞれの基本設計書を相互にフィードバック・改善しながら完成させていきます。完成した基本設計書はクライアントが確認する資料なので、専門用語や複雑なデータが記載されることは少ないです。

詳細設計（内部設計）

基本設計書の内容が決定したら、その内容を基に詳細設計書を作成します。基本設計書がクライアント向けの資料だったのに対し、詳細設計は各開発会社のエンジニア向けの資料です。搭載予定の機能をモジュールごとに分割し、具体的な実装を想定した「機能仕様書」「データフロー図」「データベース物理設計書」など、より専門的な資料を作成しながら、プログラミング工程に進むための設計書を確定していきます。

プログラミング

詳細設計が終わったらいよいよ製造工程です。各開発会社のSEやプログラマーが詳細設計書の内容に基づき、プログラミングを行っていきます。

製造・単体テスト

プログラミング工程が終わったら、作成したプログラムが要件定義で決めた通りの動きをするかを確認するため、テスト工程に移ります。

まずはモジュール単位でテストを行い、不具合が見つかったら修正したり、テスト結果のフィードバックを行ったりしながらプログラムを完成させていきます。企業によってはテスターというポジションがテスト工程を担当することもあります。

結合テスト

単体テストで各モジュールに不具合がないことを確認したら、次は複数のモジュールを組み合わせたサブシステムに不具合が起きないか、各サブシステムのインターフェースにズレがないか、各サブシステムの連携がうまくいっているかなどの確認をしていきます。

規模の大きいプロジェクトの場合は結合テストを２段階に分け、サブシステム内の連携をチェックする内部結合テストとサブシステム外の連携をチェックする外部結合テストを行うこともあります。

システムテスト（総合テスト）

結合テストで各サブシステムの不具合がないことを確認したら、いよいよシステム全体に不具合がないかの確認をするシステムテストです。すべてのプログラムが要件定義で決めた通りの動きをするかを確認するのはもちろん、アクセス過多時の耐久性や処理速度の速さなどあらゆる角度からテストを行います。

運用テスト

運用テストとは、システムを納品・リリースする前の最終工程です。クライアントの要望を満たした上で、その機能が正常に稼働するかはもちろん、誤操作しにくい仕様になっているか、もっと操作性が上がらないかなど、実際にユーザーが使う時に起こりうるトラブルや不具合などを想像しながら細かくチェックしていきます。

クライアント側のテスト担当者が実際の業務を想定しながら運用テストを実施することもあります。先ほども述べた通り、運用テストはリリース前の最終テストとなるため、システムのクオリティーに直結する重要な工程といえます。

システム移行（リリース）

一般的に、開発したシステムをリリースする時は、旧システムから新システムに移行する工程が必要となります。

このシステム移行の工程は、エンジニアにとって最も緊張感を味わう工程と言っても過言ではありません。その理由は、旧システムの仕様によってあらゆるトラブルが予想されるからです。また、サービスを停止できる時間には限りがあるため、時間制限がある中でシステム移行を行わなければなりません。

新システムにデータを移行しても想定通りの動作をするよう、さまざまな懸念点を考慮しながら移行手順書を作成し、システム移行がスムーズに進むようにしておくことが求められます。

システム移行をする方法としては、旧システムから新システムに一気に切り替える一斉移行という方法と、機能ごとに徐々に切り替えていく順次移行があります。

保守、運用

リリースしたシステムを問題なく稼働し続けるには保守・運用業務が必要になります。

保守はシステムが滞りなく稼働するようにデータを入力したり、サーバダウンなどのトラブルが発生したときに対応手順書に沿って処理をしたりすることを指します。それに対し運用とは、システムの改修やアップデートなど、システムに変更を加えることを指します。

保守・運用工程はどちらもシステムの安定稼働がミッションとなるので、それぞれの担当者が連携することが大切です。また保守、運用の工程は、社内の情報システム部門が担当することもあれば、外部のシステム会社が担当することもあります。

なぜ工程を分けて分業するのか？

ここまでシステム開発はいくつかの工程に分けて行うことを説明してきましたが、そもそもなぜ分業してシステム開発をするのかというと「効率よく、品質の高いシステムを作るため」です。

プロジェクトの規模にもよりますが、システム開発には半年～数年を要するような長期プロジェクトが多くあります。そのため、開発工程をフェーズごとに細分化し、細かくゴールを設定することでメンバー全員がシステム開発の完成図をイメージしやすいという利点があるのです。フェーズごとに管理者を設定すればタスク管理もしやすくなります。

また、フェーズごとに細かくテストしていくことで、システム完成後に「気付いたら不具合だらけだった」というトラブルを防ぐことにもつながります。

さらにフェーズごとに必要な技術や作業量も異なるため、そのフェーズに特化したメンバーを投入したり、状況に応じて人員を追加・変更したりすることも可能になります。工程を分けることで、複雑化しやすいシステム開発がより簡潔になり、その結果システム開発の効率化・クオリティー向上につながっているのです。

開発工程モデルとは？

開発工程モデルとは、開発プロセスのことを指します。開発工程モデルは、先ほどご紹介した開発フェーズをどのように進めていくかによって分類されます。

今回は代表的な開発工程モデルであるウォーターフォールモデルとアジャイルモデルの二つを詳しく説明します。

ウォーターフォールモデルとは？

「ウォーターフォール」は、日本語で「滝」という意味です。つまりウォーターフォールモデルとは、滝のように上流から下流に向かって進んでいき、戻ることのない一方通行の開発プロセスのことを表しています。

ウォーターフォールモデルの最大のメリットは、一つのフェーズが完了してから次のフェーズに着手するため、進捗の把握が比較的簡単な点です。進捗の把握が管理しやすい分、品質がある程度担保しやすいのもメリットの一つといえます。

一方、ウォーターフォールモデルのデメリットは、ミスや不具合があった場合、それをリカバリーするのに時間やコストが掛かること。特に要件定義や基本設計などの上流工程にミスがあった場合は、多大なコストが掛かります。

ミスや不具合を改善し、前のフェーズが完了するまで次のフェーズには進めないため、スピードが求められるプロジェクトにはあまりふさわしくないと言われています。

アジャイルモデルとは？

「アジャイル」は日本語で「俊敏な」という意味で、その名の通りスピードが求められるプロジェクトと相性がいい開発工程モデルです。ウォーターフォールモデルとは逆に、後戻り前提で工程を進めていくため、設計段階ではあえて詳細まで決めず、全体を作りながら随時修正を行っていきます。

アジャイルモデルのメリットは先ほども述べたように、開発スピードが速いこと。新規事業などで工程や成果物のイメージがつきにくい場合でも、とりあえず開発をスタートできる柔軟さもあります。

一方で、アジャイルモデルは工程の進捗や状況を把握するのが難しいため、管理しづらい点がデメリットです。また、アジャイルモデルは比較的新しい開発工程モデルなので、対応できる開発会社が少ない点もデメリットの一つ。アジャイルモデルでの開発実績が少ない分、開発会社はクライアントにメリットを理解してもらうのが難しいというデメリットもあります。

「開発工程モデル」他にどんなものがある？

「プロトタイプ」とは日本語で「試作品」という意味です。まず開発初期に試作品を作成し、クライアントや関係者に確認してもらった上で開発を進められるため、認識のずれを最小限に防げる点が最大のメリットです。

一方で大規模なシステム開発の場合、プロトタイプを作るだけで膨大な時間やコストが必要になってしまうため、プロトタイプモデルは小規模なシステム開発に向いているといわれています。また、開発からプロトタイプ確認のプロセスを何度も繰り返すことになるため、開発会社側の負担が大きい点もプロトタイプモデルのデメリットの一つです。

プロトタイプを作成し、クライアントと認識のすり合わせが終わった後は、ウォーターフォールモデルと同じ流れとなります。

スパイラルモデルは、サブシステムごとに開発を進め、プロトタイプをクライアントに確認してもらいながら進めていくモデルです。

一つ一つのサブシステムはウォーターフォールモデルで開発を進めていきます。スパイラルモデルは要件定義で詳細を細かく決めず、サブシステムごとに計画を立てていくため、途中で計画変更があっても柔軟に対応しやすい点が大きなメリットです。

またプロトタイプモデルと同様に、試作品をクライアントにチェックしてもらいながら進められるため、クライアントと完成図を共有しながら開発を進められる点もメリットの一つです。

スパイラルモデルは柔軟さがある一方で、プロトタイプに不具合や修正が多いほど何度も開発の工程を踏まなければならないため、プロジェクトの進捗を把握しづらい点がデメリットの一つ。またサブシステムが多いほど開発コストも増えていきます。

スパイラルモデルのように各フェーズを一つの作業計画とし、プロトタイプを作成しながら進めていく開発工程モデルの総称を「反復型開発プロセス」と呼びます。反復型開発プロセスに分類される開発工程モデルは、スパイラルモデルのほかにインクリメンタルモデル、インテレーティブモデルなどが有名です。

システム開発工程で覚えておきたい略語

システム開発の現場では略語や英語が使用されることが多くあり、「なんとなく使っているけど、何の略？」「あれってどういう意味？」と感じることも少なくないのではないでしょうか。そこで今回は、システム開発の現場でよく使われる略語を紹介します。

システムに関わる言葉を知っておくと、打ち合わせなどの場でも便利ですよ。

・SP（System Planning）：企画
・SA（System Architectural design、Service Analysis、System Analyze）：要求分析
・RD（Requirements Definition）：要件定義
・UI（User Interface）：基本設計
・BD（Basic Design）：基本設計
・SS（System Structure Design）：構造設計
・FD（Function Design）：機能設計
・DD（Detail Design）：詳細設計
・PS（Program Structure Design）：詳細設計
・M（Manufacture）：製造
・UT（Unit Test）：単体テスト
・CD（Cording）：コーディング
・PG（Programing）：プログラミング
・IT（Integration Test）：結合テスト
・ST（System Test）：システムテスト
・OT（Operation Test）：運用テスト

まとめ

基本的なシステム開発の工程や、代表的な開発手法、システム開発の現場で使用される略語についてご紹介しました。今自身が担当している工程や、これからチャレンジしてみたい工程を理解することで、今後のキャリアについて考えるきっかけにしてみてくださいね。

また上流工程になればなるほど、開発手法について考えたり略語を使用する機会が増えたりすることもあると思います。「今後上流工程を目指したい！」と思っている人は、ぜひ参考にしてみてくださいね。

文／赤池沙希