【分かりやすく解説】システム開発工程ver1

皆さんは、システムエンジニアとしてどの工程を担当していますか？
上流工程を担当していますか？それとも下流工程を担当していますか？
 
フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。
 
そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けできたらと思います。
 
まずは、ver1として、システム開発工程の概要をお届けします。
 
ぜひ、工程について再確認したい方は、ぜひご覧ください。

まず、システム開発工程の全体像です。

こちらの図をご覧ください。

これは、ウォーターフォールモデルと呼ばれるシステム開発の流れです。
みなさんも慣れ親しんだ図ではないでしょうか？
 
ウォーターフォールモデルとは、システム開発に要する工程を順番に進めていく方法です。
あらかじめ定めた工程計画を順番にこなすイメージです。
 
高いところから水が流れ落ちる滝のように、前工程に戻らない点が特徴であり、最もポピュラーな開発モデルです。
 
ウォーターフォールモデルの最大のメリットは、工程の後戻りがないので、スケジュール策定や進捗管理を比較的行いやすい点です。
また、最もメジャーな開発モデルであるため、経験者であればシステム開発しやすいメリットもあります。
 
そして、デメリットとしては原則前工程に戻ることができないため、後工程になって欠陥や変更があった場合に、大幅にシステム開発が遅れる可能性がある点です。
大幅な納期遅れが生じる結果、市場の変化に対応しにくくなるデメリットも生じます。

では、もう一つ最近注目されている開発の流れにも目を向けてみましょう。

アジャイルモデルとは、素早くシステムを開発する方法の総称です。
最近、このモデルを使用するプロジェクトもあるので、聞いたことはあるのではないでしょうか？
 
アジャイル開発の工程では、顧客と開発会社同士の連携や協調、変化への対応を重視します。
 
最大のメリットとしては、開発の期間を短縮化できる点です。
重要な機能からいち早くリリースできるので、素早い事業展開が可能になります。
 
またシステムを機能単位で開発するので、不具合や仕様変更にも柔軟かつ迅速に対応できる点もメリットとなります。
 
顧客と開発者側が密にコミュニケーションを取りながらシステムを開発するので、理想的なシステムを作り上げることが出来るでしょう。
 
ただ、デメリットとして、厳密な計画を立てないので、スケジュール管理が難しいです。システム開発全体の管理が難しいので、管理次第では納期が遅れる危険があります。
 
この2つが、システム開発の流れでよく目にする形になります。このシリーズでは、ウォーターフォールモデルの流れを元に各工程のお話をしていきます。

システム開発は、要件定義という工程から始まります。
システム開発を依頼する側と開発する側が打ち合わせを行い、システムの性能・機能や運用方法などの「要件」を決定します。
システム開発を依頼する際、希望の機能や性能があるかと思います。その要求と開発会社側の認識にズレがある場合、結果的に希望とは異なるシステムになる恐れがありますので、認識のすり合わせが非常に重要です。

外部設計の工程では、システム使用者(ユーザー)の視点からシステムに必要な機能を洗い出し、それを基に大枠となるシステム設計を行います。
その際システムの仕様などが記された基本設計書を、ユーザー側が確認するケースもあります。

次に外部設計で決定した事項を基に、コンピュータでの実装を想定した上で、より詳細にシステムを設計します。
外部設計がユーザー視点からの設計である一方で、内部設計の工程ではコードやプログラムの設計など、開発者側からの視点でシステムを設計します。

内部設計での決定事項を基に、実際にプログラミング言語を用いて、システムを構築する工程になります。
家の建築で例えると、先ほどまでの工程が設計図の作成であった一方で、この工程以降は家を実際に建てる流れになります。

プログラミング工程が完了したら、実際に構築したプログラミングが作動するかをテストします。
システム開発では、小さい単位から大きい単位という流れでテストを行います。単体テストでは、プログラミングの対象単位(モジュール)ごとにテストします。

モジュール単位で問題が無ければ、各モジュール同士を結合してテストを行います。
例えば、データの受け渡しや画面の切り替わりなど、プログラム同士が正常に連携するかをテストします。

プログラム同士の連携が問題なければ、ユーザーが要求する機能や性能を満たしているかをテストする工程に入ります。
この工程では具体的に、処理速度や大量アクセスへの耐久などをテストします。

システムテストの工程に問題が無ければ、最後に運用テストを実施します。
運用テストでは、実際にシステムを運用する環境下で、開発したシステムに不具合がないかを確認します。

全てのテストをクリアしたら、完成したシステムをリリースする工程となります。

システムが完了したからといって、全ての工程が完了した訳ではありません。
なぜならシステムを使用し続ける過程で、何かしらの不具合が生じる場合があるからです。システムを効果的に活用し続ける為には、常にシステムを監視し、不具合が生じた際には即座に修正する必要があります。
 
この流れが、システム開発の流れになります。
1~3 の部分が、上流工程と言われることが多く、4~が下流工程といわれます。
ただ、下流工程に行くからと言って、上流工程が全く関わらないわけではなく、6~8の工程では、上流工程が密接に絡んできます。
その辺りは、次の記事からお話できればなと思います。

いかがでしたでしょうか？
私は、システム開発の全行程を担当したことあります。どの工程に、こういう事を大切にしたいといけないということを、少しだけ感じられてると思いますので、次の記事から私の経験談も交えながら、お伝えしていこうと思います。
皆さんの今後の活躍のためになれば、幸いです。