システム会社にソフトウェア開発を委託したり、Webサイト制作会社にECサイト制作を委託する場合、システム開発の工程とそのポイントについて知っておくと「クライアント側としてやるべきこと」が明確にわかります。
経営課題を解決したり、新しいビジネスを創出するためのシステム開発ではクライアントの協力がとても重要です。今回はシステム開発の工程とそのポイントについてご紹介するので、この機会に知見を深めていただきたいと思います。
アジャイル開発、ウォーターフォール開発、DevOps
最初に一般的な開発手法についてご紹介します。
アジャイル開発とは従来の開発手法に比べて素早く機能をリリースしていき、短いサイクルの積み重ねで一つのソフトウェア開発を進めていく手法です。イテレーションと呼ばれる1週間～4週間程度の開発期間をいくつか設けて、その中で優先度の高い要件から開発を進めていきます。開発途中で不具合や要件変更が起きても手戻りが少なく、素早く改修できるのがメリットです。
ウォーターフォール開発は一つのソフトウェア開発を一連の流れで開発していく手法です。そのためアジャイル開発のようにイテレーションは無く、一つの工程が完了したら次工程に移行するというのが一般的な方法です。ウォーターフォール開発ではプロジェクト全体を最初に計画するため進捗管理がしやすいという反面、不具合や要件変更が発生すると手戻りが多くなるというデメリットがあります。
ソフトウェア開発現場では長らくウォーターフォール開発が主流でしたが、2000年代に入ってから徐々にアジャイル開発を採用する企業が増えています。また、DevOpsとは開発チームと運用チームが協力体制を取り、スピーディかつ信頼性の高いシステム開発を目指すための手法です。
システム開発の工程とそのポイント
それでは具体的な開発工程とそれぞれのポイントについてご紹介します。
- 工程①要件定義
- 工程②基本設計
- 工程③詳細設計
- 工程④コーディング
- 工程⑤単体テスト
- 工程⑥結合テスト
- 工程⑦システムテスト
- 工程⑧運用テスト
- 工程⑨システムリリース
- 工程⑩システム運用
工程①要件定義
要件定義とはソフトウェアに必要な機能や仕様を「要件として盛り込む」作業です。システムエンジニアは顧客からヒアリングした現状課題やシステム化の経緯、ソフトウェアに期待する効果などをもとに要件を固めていきます。
大切なことは要件を定義するだけではなく、その要件を顧客と擦り合わせて正確な要件としてまとめることです。ウォーターフォール開発の場合工程の後戻りは難しいため、システムエンジニアと顧客で協議した上で要件を定義する必要があります。
工程②基本設計
基本設計はユーザー視点で考えるソフトウェアの設計です。どんな機能を実装するか？出力する帳票の種類は？やり取りするデータは？画面レイアウトは？データベースは？などなど、ユーザーや運用管理者の視線に立って設計を行っていきます。開発工程における費用の発生や細かいスケジュールに関してもこの時点で顧客と擦り合わせます。
工程③詳細設計
基本設計で決定した内容をもとに実際のソフトウェア開発に落とし込んでいくのが詳細設計です。ソフトウェア内部の動作やデータの処理方法などを細かく設計していき、プログラム単位で様々な要素を決定していきます。
次工程に必要な設計なので顧客と擦り合わせることはありませんが、様々なドキュメントを作成して正確な設計を行うことが重要です。
工程④コーディング
コーディングとはプログラミングと同義であり、詳細設計をもとにプログラムを一つ一つ
作っていくのが主な業務です。重要なことは開発チームでコーディングに関するルールを定めることです。コーディングは自由度が高い作業なので、同じ機能を実装する場合でも様々なコーディング方法があります。
予めルールが定まっていないと開発者ごとに異なる方法でコーディングをしてしまい、後々不具合が発生したりソフトウェアの保守性が低下するというトラブルが生じます。
工程⑤単体テスト
単体テストはプログラム単位で正常に作動するかを確認する工程です。一般的にはコーディングと並行して進めていきます。可能な限り後工程で不具合を発生させないために、単体テストでより多くの不具合やバグを発見して修正することが大切です。
工程⑥結合テスト
単体テストが完了したプログラム同士を結合して一つの機能としてテストします。実際の利用場面を想定して詳細設計通りに実装できているかを確認しましょう。
工程⑦総合テスト
システム開発側最後のテストです。結合テストがすべて完了したらソフトウェア全体の動作を確認します。本番環境に合わせてテストすることが大切で、万が一不具合が発生しても恐れずに改修することが大切です。多少のプロジェクト遅延よりも、顧客の経営課題を解決できないシステムを納品してしまう方が事業に与えるダメージは大きくなります。
工程⑧運用テスト
運用テストは主に顧客立ち会いのもと行うテストです。完成したソフトウェアに触れてもらい、要件定義に沿った開発ができているか、操作感は納得のいくものかどうかを確認します。
工程⑨システムリリース
すべてのテストが完了したらソフトウェアを本番環境に移行してリリースします。
工程⑩システム運用
システムリリース後も制作会社は保守運用にあたるのが一般的です。不具合が発生した場合の修正や新しい機能の開発及び追加も行います。
成果物管理と標準化が成功のカギ
ソフトウェア開発の成否を握っているのが「成果物管理」と「標準化」です。
成果物管理
成果物管理とは、顧客ニーズを満たすソフトウェアを開発するために最終的な成果物の姿を管理するためのプロセスです。ソフトウェア開発の現場では、納品後「想定していたものと違う」といった最悪の事態に遭遇するケースが少なからずあります。これは、成果物管理が徹底されていないためです。
前述した各開発工程には常に明確な成果物が無くてはなりません。工程が一定水準に達していないまま次工程に移ってしまうと、確実に想定していたものとは違うソフトウェアが完成します。
各開発工程の成果物を管理することで、それを集約したものが最終的な成果物となり顧客ニーズを満たすソフトウェアが完成します。
標準化
「標準化されている状態」とは、誰もが同じように物事を理解して作業を進められる状態を指します。ソフトウェア開発の現場ではこの標準化されている状態がとても大切です。ソフトウェア開発は基本的に集団作業です。システムエンジニアやプログラマーなどそれぞれ異なる役割を持つ開発者がチームを組んで一つのプロジェクトを完成させます。
もしもこの時、各々が思うがままに開発を進めてしまうとどうなるか？答えは「属人化した状態」になり、特定の人してそのプログラムや機能について理解できない状態になってしまいます。こうなるとソフトウェアの保守性は劇的に低下します。
ソフトウェアに不具合が発見されたり改修依頼があったとしても、そのプログラムを開発した人しか改修が加えられないという状態になってしまうでしょう。
だからこそコーディングルールを明確にしたり、適宜ツールを使用して可能な限り標準化を目指すことが大切です。
いかがでしょうか？これからIT業界に携わるかもしれないという方は、最低限システム開発の工程とそのポイントを頭に入れて置き、日々の業務に取り組んでいただければと思います。
