エンジニア転職したいならシステム開発の基本的な流れを理解しよう！

すずき

プログラミング初心者のかたは、プログラミングスキルを習得すればシステム開発できると思っている人もなかにはいるかもしれません。ですが実態はそんなことなくて、システム開発においてプログラミングは全体の10～20％程度しか占めません。「それじゃ、システム開発は何をしているの？」と疑問に思う方がいるかもしれませんので、そういう方に向けて説明していきます。

基本的な開発プロセスを理解しよう！

一般的に、システムを開発するプロセスは、要件定義・基本設計・詳細設計・プログラミング（製造／単体テスト）・結合テスト・システムテスト・移行の区分に分かれます。

エンジニアになるならV字モデルを知っておこう！

先の章でシステム開発プロセスにはいくつかの区分があることを紹介しました。

その中でも開発工程（要件定義～製造）とテスト工程（単体テスト～システムテスト）に大別できます。

開発モデルの１つであるV字モデルは、開発工程とテスト工程の対応関係を表したモデルのことを指します。

開発工程で作り込んだシステムに対して、各テスト工程で、対応する開発工程の観点でテストをすることで、品質を確保する目的があります。

このV字モデルは、ウォーターフォール開発という開発手法で主に用いられるモデルになります。

ウォーターフォール開発とは、開発の一連の流れが、滝が上流から下流へ流れる様に似ているため名付けられたものです。

そうした所以から、原則として、前工程が完了しないと次工程に進めないようになっています。（基本設計でシステム化する全機能の仕様を決めないと詳細設計に進めない）

ただ、昨今は、ビジネス変化のスピードに迅速に対応できるように、アジャイル開発という開発手法が徐々に増えてきました。

アジャイル開発は、ウォーターフォール開発のように工程をきっちり分けて進行させていくのではなく、機能ごとに短いスパンで「設計→製造→テスト」を繰り返してお客様の求めるシステムを作っていこうというもの。

ですので、アジャイル開発では、１つの機能はまだ要件定義しているけど、他の機能は要件定義完了してるから先に設計・製造している、なんて状況も起こりえます。

どちらの開発手法にしても、ウォーターフォールであれば長いスパンで、アジャイル開発であれば短いスパンでV字モデルを活用しているといえます。

それぞれの開発プロセスを見ていこう！

この章では、各工程でどういったことをしていくのかを見ていきます。

要件定義

お客様の要求を収集して、インフラ、運用も含めた業務システムの全体像を固める工程にあたります。

ざっくり言うと、どういうシステムを作るかをお客様と合意します。

そのためには、お客様の業務に対する知識だけでなく、お客様によっては無理なお願いをしてくる人もいるため、交渉スキルが必要だったりします。

この工程は、主にシステムエンジニアの人が担当しますね。

※プログラマーは基本的に実施しません。

ですが、私のチームでは、プログラマの人にも要件定義成果物を作成してもらっています。

純粋に人が足りていないというのもありますが、メンバ全員がシステムを利用する側（お客様）の視点に立ち考えることで、よりユーザ満足度の高いシステムを提案できるようになろうという裏テーマもあります。

基本設計

システムの画面やボタンを押したときの挙動など、ユーザから見える部分のデザインや動きを設計します。

それだけでなく、他のシステムとの連携機能（インターフェース）などがある場合には、その設計も実施します。

また、V字モデルで対となる結合テストの計画書や仕様書を作成していきます。

この工程もシステムエンジニアが主に担当しますね。

詳細設計

基本設計を実現するための、システム内部の構造を設計します。

つまり、プログラム内部処理の内容や手順などをここで設計していきます。

複数プログラムがあって、一部の処理が共通化できる等あれば、切り出して部品化するなどを考えたりもします。

それぞれのプログラムの設計をきちんとすることがとても大事です。

この工程は主に、システムエンジニアまたはプログラマーが担当します。

プログラミング

内部設計で設計されたプログラムの製造・テストをしていくフェーズ。

主にプログラマーが担当します。（単体テストはテスターと呼ばれる人がテストする場合もあります。）

結合テスト

プログラミング工程で作成・テストしたそれぞれのプログラムを組み合わせて（＝結合させて）テストする工程。

個々のプログラムの仕様を確認しながら、順次範囲を広げてテストをしていきます。

例えば、商品購入機能があるとします。商品購入するには、商品検索機能、カート機能が必要ですし、購入履歴確認機能なども必要になります。

それぞれ単体の機能として、プログラミング工程の単体テストで検証している前提で、結合テストではそれらの機能ごとを繋げて利用することで何か問題が発生しないかを確認するテストです。

システムテスト

業務システム全体をお客様の視点など業務の観点でテストする工程です。

ここでは、お客様が満足できるものになっているか、実際に使う人の立場に立って確認します。

先ほどの商品購入を例にとってみると、商品検索→カート追加→商品購入→購入履歴確認（→場合によっては、購入取消など）といったユーザが実際に行うであろう一連の操作（シナリオ）をしてみて、何か問題が発生しないかを確認するテストです。

可能であればお客様に実際に使ってもらうのがベストですが、移行のフェーズで顧客受け入れテストを実施してもらうことが多いかもしれないですね。

移行

システムテストまで実施した業務システムを、お客様が実際に使用する本番環境にリリースしたり、これまでの成果物を納品する工程。

お客様が実際に受け入れテストを実施してOKが出たら本番稼働となります。

これ以降は運用保守となるため、開発部隊の役割が終わり、運用部隊に引継ぎをします。そのための資料などもアウトプットとして必要になってきます。