システム開発にはさまざまな工程があり、携わっていれば専門用語や略語を使用する機会は多くあります。ここではシステム開発とは何か、どのような業種が携わるのか、どのように運用するのか、などについて解説します。
システム開発の基本的な流れを押さえておくと、実際にプロジェクトに配属された際にスムーズに対応できます。
そもそもシステム開発の作業手順とは?
システム開発には、いくつかの作業手順があり、決められた工程に沿って進められます。一般的には、要件定義に近いと「上流作業手順」、運用・保守に近い作業手順は「下流作業手順」と呼ばれます。
システム開発の作業手順は、「要件定義・設計・開発・テスト」と進んでいきます。上流作業手順の方が役職上の地位が高く、下流作業手順の方が低いという考え方もあるでしょう。ただ、担当エンジニアの平均単価や、プロジェクトでの立ち位置としてそのように理解されているに過ぎず、実際には下流作業手順にスキルが高い従業員が配置されるケースもあります。「上流作業の担当者よりも、下流作業担当者のほうが、単価が高い」というケースも少なくありません。つまり、あくまでも作業手順の上下を指して「上流作業手順・下流作業手順」と呼ぶと考えておきましょう。
覚えておきたいシステム開発作業手順の略語
システム開発作業手順の略語は複数あるのですが、ここでは特に、覚えておきたい基本となるような略語を紹介します。
- 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):運用テスト
すべての略語を一気に覚える必要はありませんが、このようにシステム開発現場ではいろいろな略語が用いられることを把握しておきましょう。用語は基本となるように英語圏から流れてくるので、略語も英語の頭文字を取ったものが多いです。
システム開発の代表的な種類
システム開発の代表的な種類として、ウォーターフォール型とアジャイル型の2つがあります。それぞれについて解説していきます。
ウォーターフォール型
ウォーターフォール型とは、滝のように上流から下流に向かって進めていく開発プロセスのことです。1つの作業手順を順番に行っていくので、進捗状況の把握が容易で品質も担保しやすいというメリットがあります。
ウォーターフォール型は、手戻りがないことが特徴です。例えば「要件定義の後に設計をして、その後再度要件定義に戻る」ということが基本的にありません。例外的にどうしても戻らなければならない場合もありますが、基本は手戻りがない前提でプロセスを進めていきます。
アジャイル型
アジャイル型とは、とにかくスピード重視でプロジェクトを進めていく開発プロセスのことです。文字通り開発スピードが速く、全体を作りながら随時修正を行っていく方法になります。アジャイル型では作業手順を戻る前提でプロセスを進めていけるので、見切り発車しやすいというメリットがあります。
従来はウォーターフォール型が主流だったのですが、近年はウォーターフォール型の問題点が明確になってきています。例えばウォーターフォール型の場合、作業手順を戻れないので、各作業手順を徹底する分、時間がかかるでしょう。さらに、いくら各手順に完璧を求めても、作業手順を進めてみなければどうしてもわからないこともあります。
一方でアジャイル型なら不都合があった場合には1つ前の手順に戻ればよいだけなので、完璧を求める必要がありません。実際、作業手順を進めてみた方が早く問題に気づくといったことも少なくありません。
近年は特にシステム開発にスピード感が求められるので、アジャイル型の割合が増えています。ただしウォーターフォール型が不適切というわけではなく、あくまでも「今の時代には、アジャイル型の方がフィットすることが多い」ということです。
システム開発の作業手順と一連の流れ
システム開発の作業手順は以下のようになっています。
- 要件定義
- 基本設計
- 詳細設計
- プログラミング
- 単体テスト
- 結合テスト
- 総合テスト
- 運用テスト
- リリース
- 運用・保守
- 改修・メンテナンス
まず要件定義は、システムの概要を話し合って決定していく作業手順です。プロジェクト内のエンジニア同士で話し合うことはもちろん、システム開発を依頼した企業の担当者も交えて話し合いを行います。
次に基本設計は、システムの大枠の設計を記載した書類の作成です。具体的な処理を記載するというよりは、必要な要件をある程度細分化して記載していく内容になります。
さらに詳細設計で、基本設計よりも具体的な処理を決めて記載します。処理の内容を日本語で記載し、可能であれば使用するソースコードを直接文書に記載することも多いでしょう。そしてプログラミングの作業手順では、詳細設計で決めた内容に基づいてソースコードを記載していきます。
詳細設計でより具体的に記載しておけば、プログラミングの作業手順は難易度が下がります。逆に詳細設計の作業手順であまり具体的なことを記載していないと、プログラミングの作業手順で具体的な処理を考えながら記載することになります。
システム開発ではプログラミングの作業手順が注目されます。事実、システムの動きに直結するのは、プログラミングの作業手順です。しかしプログラミングはプログラミングの作業手順だけで決まるのではないため、特にその上位に該当する設計を適切に完了しておくことも大切です。
プログラミングが完了したら、次にテストの作業手順に移ります。テストの作業手順では、処理ごとに細かく区分した単体テストから実施します。
単体テストで問題ないことを確認したら、次に結合テストに進みます。
結合テストでは単体テストで確認した複数の処理を結合して、連携に問題がないかということを確認します。結合テストで問題がないことを確認したら、総合テストの作業手順に進みます。
総合テストでは、システム全体を動かしてテストを行います。総合テストで問題ないことを確認したら、実際の運用環境でシステムを稼働する運用テストです。運用テスト通過後に、ようやくリリースとなります。
もちろんリリース後も、保守・運用の作業が発生します。保守・運用後に改修やメンテナンスが必要になった場合、随時対処しなくてはならなりません。もし大幅な改修が必要な場合は、再度プロジェクトを発足して要件定義から実施することになるでしょう。
以上の流れが大枠なのですが、詳細はプロジェクトによって異なります。設計書が基本設計と詳細設計で分かれていなかったり、単体テストをプログラミングしながら大枠でしか行わなかったりといったケースもあるでしょう。
どのようなケースでも、システムを一般にリリースするなら、テストは非常に大切な手順で、時間もかける必要があります。ただプログラミングしている段階で、単体テストについては問題ないと判断できることも少なくありません。例えばこうしたときは、単体テストの一部を省略して、早い段階で結合テストに移っていくことになります。
このように上記の基本プロセスは、現場によって臨機応変に変動していくことが一般的です。テストも含め、手順の省略化や厳密化を適宜考慮しましょう。
まとめ
システム開発とはシステムを開発する作業で、プログラミングだけを指すわけではありません。要件定義、設計、テストなどの作業手順も大切で、これらすべてを包括したものがシステム開発と呼ばれています。
プロジェクトによっては基本から大きく異なってはいますが、基本となるような流れを押さえておくとよいでしょう。また、アジャイル型の開発手法についてより専門的な知識を得たいという場合は、Microsoftが提供する企業向けの開発者育成プログラム「Cloud Native Dojo」がおすすめです。