システム開発は大きなプロジェクトになるとさまざまな企業や関係者が関わり、エンジニア自身も自分の担当範囲しかわからないということもよくあります。
また、他社へシステム開発を委託する場合、工程をしっかりと把握しておくことで、打ち合わせや開発をスムーズに進めることができ、不具合の発生や手もどりを防ぐことに繋がります。
今回は、システム開発工程と、代表的なシステム開発手法であるウォーターフォールとアジャイルについて解説します。
システム開発工程とは
システム開発工程とは、システム開発を行うにあたって進めていく手順のことを指します。
システム全体の仕様や予算・スケジュールのすり合わせ等を行う要件定義から始まり、設計→コーディング→テストといった段階に進んでいく流れがシステム開発工程となります。
工程を川の流れになぞらえて、前半部分を上流工程、後半部分を下流工程と呼ぶ場合もあります。ひとえにシステム開発工程と言っても、企業やプロジェクトの規模によって細かい所には違いがありますが、主要な流れは掴んでおきましょう。
システム開発の基本的な工程
システム開発の基本的な工程について紹介していきます。
要件定義
要件定義では、クライアントが必要としているシステムの要件をヒアリングして、まとめていきます。
開発手法、予算、開発スケジュール、リリース後の運用方法など、システム開発に必要な要件についてもここで決めていきます。
要件定義でどれだけ内容を詰められるか次第で、その後のシステム開発が順調に進んでいくかどうかが決まると言ってよいでしょう。
トラブルが起こらないように、クライアントとの認識をここでしっかりと合わせておく必要もあるため、要件定義は極めて重要な工程です。
基本設計
基本設計では、要件定義で決めたシステムの概要をもとに、基本的な仕様を機能ごとにまとめていきます。
システムを実現するためにはどういう画面を作ればよいのか、入出力やデータはどういう形式なのかなど、実装すべき機能について決めていきます。
データベースの情報をまとめたテーブル設計書やER図、画面一覧表や画面遷移図なども主にこの工程で作成されます。
基本設計についてはクライアントにも一緒に確認してもらうことが多いため、見られることを想定して設計書を作ります。
詳細設計
詳細設計では、基本設計でまとめた内容を、実際にコーディングが出来る段階まで落とし込んでいきます。
機能を満たすためにはどういったプログラムを書けばよいか、関数や戻り値、取り扱うデータなど、開発担当者が設計書を見ながらプログラム開発に取り掛かれるように作成します。詳細設計で決まった内容がそのままプログラムに反映されることになるため、重要な工程です。
コーディング
詳細設計後は、コーディングを行います。
詳細設計に書かれている機能をプログラムに反映させていきます。
設計書が分かりやすいものであることは前提ですが、開発担当者には設計書の内容を読み解く理解力と、それを実現するコーディングスキルが必要です。
単体テスト
単体テストは、コーディング後にプログラムの動作をテストする工程です。
通常、関数やメソッドごとの細かい単位でテストすることを単体テストと言います。
例えば、テキストボックスにおける値の入力チェックや、特定のボタンを押下した際に正しくメッセージが表示されるかなどの動作確認を行います。
それぞれの機能が正しく動作していなければ以降の結合テストへは進めませんので、ここで機能単位の動作確認はしっかり終わらせておく必要があります。
バグが見つかった機能は、デバッグを行ってバグを取り除きます。
デバッグについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
結合テスト
単体テスト終了後は、結合テストの工程へ進みます。
結合テストでは、単体テストで確認した機能を複数組み合わせて動かした場合に、正しく動作するかを確認します。
例えば、テキストボックスに値を入力して、登録ボタンを押下した場合にその値がデータとして正しく保存されるか等、一連の流れで動作を検証していきます。
結合テストについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
統合テスト
統合テストでは、システムを実業務と同様の流れで動作させてテストします。
テストに利用するデータも、本番を想定したものとなるため、本番時のデータ受け渡しの際に不具合が発生しないかもここで確認することができます。
また、統合テストは実際にクライアントにシステムを触ってもらうケースが多いため、開発側で想定していなかった操作等、イレギュラーなケースを発見出来ることもあります。
リリース・本番移行
統合テスト終了後は、いよいよリリース・本番移行です。
システムを実際の業務で利用できる様に、本番の環境で公開する作業です。
本番環境で利用するデータベースやデータ等をあらかじめ用意しておき、開発したプログラムとともに本番環境へアップロードします。
リリース後は運用・保守
リリース後は、稼働中のシステムに不具合が発生しないかの運用・保守作業を継続して行います。エラー発生時は担当者へメールで通知が届いたり、システム利用者からの問い合わせに対応したりと、運用・保守作業が多く発生する場合もあります。
特にリリース直後は、綿密なテストを行っていても何かしらの不具合が発生することが高く、問い合わせも多くなる傾向にあります。
主なシステム開発手法
システム開発時に取り入れられている、主な開発手法について紹介します。
ウォーターフォール開発
ウォーターフォール開発とは、要件定義、基本設計、詳細設計、コーディング、テストをシステム全体規模で上流工程から順に行っていく開発手法です。
つまり、何を作るかを明確にした状態で開発に臨む手法です。
メリット・デメリット
ウォーターフォール開発のメリットは、上流工程から順に進めていくため、スケジュールを組みやすいところにあります。
どの工程でどれぐらい作業時間が掛かるのかが、進捗管理を明確にできるため、個人のタスクの負担を軽くすることも出来ます。
一方、手戻りが発生した場合には大きくスケジュールが崩れてしまうデメリットがあります。
他にも、設計の段階で見えていなかった不満点が途中で見つかってもそのまま続行してしまい、ユーザビリティに欠けるシステムになってしまう危険性もあります。
アジャイル開発
アジャイル開発とは、上流工程から下流工程へ順番に作業を完了してからテストするのではなく、より小さな単位で実装とテストを繰り返して開発を進めていく手法を指します。
メリット・デメリット
アジャイル開発はその特性上、仕様変更にも柔軟に対応出来るため、ユーザビリティの高いシステムを開発することが出来るメリットがあります。
一方、設計の段階でシステム全体的に厳密な仕様を決めきれていないため、開発の方向性がブレてしまうというデメリットもあります。
システム開発における注意点
システム開発を工程通りスムーズに行うためにも、気をつけなければならない注意点をいくつかご紹介します。
なるべく仕様変更は発生させない
仕様変更が発生すると、その度に手戻りが発生することになります。
設計段階ならまだしも、コーディング終了後のテストまで進んだ段階で仕様変更が発生してしまうと、設計・コーディング・テストを全てやり直さなければなりません。
実装する機能に漏れがないか、仕様について互いの認識が合っているか、要件定義の段階でクライアントと入念に打ち合わせましょう。
本番移行作業は慎重に行う
本番移行作業は本番環境を触ることになるため、慎重に行う必要があります。
本番用に用意したデータに漏れがないか、本番反映用のプログラムは統合テストのデバッグまで終えた最終バージョンで間違いがないか等、本番環境に誤ったデータ・ファイルをアップロードしないようにしましょう。
既存システムのアップデートを行う場合も同様です。
例えば、アップデートに伴ってデータベースの値を追加・変更する場合、本番環境のデータベースに対して直接データに手を加えるのか、それともテスト環境で対象のデータをCSVファイルで作成してから本番環境へインポートさせるのかではリスクが大きく変わってきます。
本番移行作業はリスクの大きな作業になるため、システムの規模問わず可能であれば複数人で何重にもチェックしながら行うことを推奨します。
エラー発生時の対応フローは明確にする
システムでエラーが発生した場合、解決までをスムーズに進めるための対応フローは明確にしておきましょう。
例えば、頻発するエラーがある場合、もちろん不具合を修正することが第一ですが、エラー発生後すぐに対応出来るフローを用意しておき、それに沿って迅速に対応し、なるべくユーザーに支障が出ないような運用を心掛けましょう。
発生したエラーに対していかに早く対応出来るかが、運用・保守の信頼性に繋がります。
まとめ
システム開発工程は、正しい手順と手法で進めていくかどうかで、完成するシステムの品質に大きく影響してきます。各工程で行うべきことを明確にして、どの開発手法を取るべきか、リリース後の体制をどう取るべきかを考えましょう。
