【エンジニアによる徹底解説】システム開発の流れと工程とは
この記事を読むと分かる事
  • 開発工程を理解すべき理由と目的
  • システム開発の基本的な手法
  • ウォーターフォールモデルの工程詳細

これからITエンジニアを目指す方にとっては、システム開発はどのような工程で行われるのか気になっている方も多いのではないでしょうか。

一口にシステム開発といってもさまざまな開発手法があり、開発規模や人員によって工程もさまざまです。また、開発するシステムの内容や納期によっても最適な開発手法も異なるもの。

そこで今回の記事では、システム開発には具体的にどのような手法があって、どのような工程で行われるのか代表的な事例をピックアップしながら紹介していきます。システムエンジニアやプログラマーなどを目指している方は、ぜひ参考にしてみてください。

”条件別” 当サイトで人気のエージェント

1.ランスタッド
 年収800万以上や外資系への転職に強い

2.Type転職エージェント
 ハイクラスを狙える総合転職エージェント

3.コンサルタントジョブ
 フリーコンサル案件に特化したエージェント

システム開発の工程を理解すべき理由と目的

システム開発の工程を理解しておいたほうが良い理由と目的

「そもそもシステム開発の工程はエンジニアになってから学べば良いのでは?」と考えている方も多いことでしょう。

しかし、システム開発の大まかな工程だけでも理解しておけば、初めて現場に入ったときに先輩や上司が何について話しているのか、誰が何の作業を行っているのかなど、大まかなことが分かるようになります。

そのためにも、今回はシステム開発においての上流から下流までの作業工程を一通り紹介すると同時に、よく用いられる単語も併せて解説します。専門用語も多く最初のうちは大変かもしれませんが、慣れてくると自然に言葉も理解できるようになるはずです。

システム開発でよくある2つの手法

システム開発でよくある2つの手法

まずはシステム開発のもっとも基本的な手法を2つご紹介します。それは「ウォーターフォールモデル」「アジャイルモデル」とよばれるものです。仕組みを知ると難しいことはありませんので、まずは基本となるこの2つの内容について押さえておきましょう。

ウォーターフォールモデル

「ウォーターフォール」とは日本語に直訳すると「滝」を指す単語です。

滝は上から下に水が流れ落ちますが、まさにこの様子を開発工程に見立てたものがウォーターフォールモデルといい、システム開発の企画や要件定義を行う上流工程から、それを具体的な形にするための作業を行う下流工程まで一連の流れを示しています。

まさに流れ作業のように上流から下流へと作業が進んでいくため、システム開発が今どの段階にあるのか把握しやすく進捗管理が容易です。ウォーターフォールモデルは伝統的なシステム開発の手法であり、古くからのシステム開発といえばこの流れをイメージする人も多いのではないでしょうか。

ちなみに、実際にシステム開発を行うエンジニアを募集する際にも「上流工程経験者」のように条件のひとつとして加えられることも多く、それだけシステム開発の現場ではウォーターフォールモデルが定着していると考えることもできます。

アジャイルモデル

ウォーターフォールモデルの対局にある開発手法が「アジャイルモデル」とよばれるものです。

アジャイルとは「素早い・迅速」といった意味をもち、その名の通りスピード感が求められるシステム開発の現場において最適な手法です。

きちんと工程管理が行われるウォーターフォールモデルとは対照的に、アジャイル開発にはそのような明確なルールがありません。たとえば漠然としたテーマや課題を共有し、それを解決するシステムを随時コミュニケーションを取りながら形にしていくのも典型的なアジャイルモデルです。

まるでミュージシャン同士がセッションをしながら楽曲を作り上げていくように、その場で生まれたアイデアや考え方を取り入れ、ときには随時修正もしながら最適な形に組み上げていきます。

そのため、ウォーターフォールモデルよりも驚くほど速いスピードでシステムが構築でき、ベンチャー企業やスタートアップ企業などを中心にアジャイルモデルは積極的に採用されています。

ウォーターフォールモデルの開発工程

ウォーターフォールモデルの開発工程

ここからは、今回のメインテーマであるシステム開発の工程について詳しく紹介していきましょう。

アジャイルモデルで開発している企業は増えてきていますが、大規模なシステム開発や開発期間が厳密に定められている現場においてはまだまだウォーターフォールモデルが採用されているケースは多いものです。

まずはシステム開発の基本ともいえるウォーターフォールモデルの流れを押さえておきましょう。

要件定義

どのようなシステム開発においても、もっとも重要とされているのがこの要件定義です。要件定義とは一言で表すと、開発するシステムにどのような仕様や機能を盛り込むかといった定義書のようなもの。

この後に続く設計作業はこの要件定義を基準として行われるため、もしこの段階で実装する仕様や機能を定義し忘れてしまっていると開発工程に致命的な影響を与えてしまいます。

要件定義は依頼者がどのようなシステムを望んでいるのか正確にヒアリングしたうえで、必要な機能を盛り込んでいきます。そのため、要件定義は下流工程の知識とノウハウがあり、本当に開発できるのか否かを判断できる人でなければ対応することが難しいものです。

外部設計と内部設計

要件定義によってどのような機能を盛り込むのかが決まったら、まず外部設計に移ります。外部設計とはシステムを外側から見たときに、どのような見た目、インターフェースになるのかを決める工程です。

たとえばスマホ用アプリを開発する場合を例に挙げると、スマホ用アプリを立ち上げたときのボタン配置や大きさ、どのボタンを押したらどの画面に遷移するのかなどを決めるのが外部設計にあたります。WEBサイトの構築であれば、掲載する情報の大まかな内容やレイアウト、デザインの雰囲気などが外部設計にあたります。

外部設計はシステムの操作性にも直結する部分であり、ユーザー側と開発側で齟齬が発生しやすい部分でもあるため、こまめにコミュニケーションをとりながら進める必要があります。

外部設計が固まったら、それを形にするためにどのような内部構成にするのかを決める内部設計に移ります。建物を建設する工程に例えると、外部設計は建物の外観や設備のデザインにあたります。内部設計はそのデザインを形にするための作業計画にあたる作業を指します。

プログラムのコーディング

内部設計によって作業内容が決まったら、実際に形にするために手を動かして作業を行います。これが「プログラミング」や「コーディング」とよばれる作業で、一度は耳にしたことがある人も多いのではないでしょうか。建物の建設においては作業員や職人による作業にあたる部分です。

かつては一からプログラミングのコードを書いていましたが、現在ではさまざまなモジュール単位で組み立てができるようになっているため、開発効率は大幅に向上しています。

単体テスト

プログラミングが完了した後は、特定の機能やモジュールごとに問題なく動作するか確認する単体テストが行われます。モジュールを組み立ててプログラミングは行われますが、個別の開発においては細かなカスタマイズ処理や調整が必要不可欠です。

要件定義で定めた内容と合致しているか、動作上問題ないかも含めてテストが行われます。

ウォーターフォールモデルの開発工程

結合テスト

単体テストでモジュール単位の機能に問題がないことが分かったら、実際に複数のモジュールを組み合わせたうえで動作するか結合テストが行われます。プログラムは単体のモジュールで動くものもあれば、複数のモジュールからデータを受け取ったうえで初めて動作するものもあります。

単体テストでは問題なく動作していたにもかかわらず、結合テストの段階で異常が見つかることもあるため、さまざまなパターンでテストは行われます。

システムテスト

結合テストは複数のプログラムを連携させて行われますが、システム全体を通して異常がないかも確認しなければなりません。これをシステムテストとよびます。この段階で要件定義で定めた機能がきちんと動作しているか、総合的に評価が行われます。

運用テスト

システムテストの後は実際に業務への活用を前提とした運用テストが行われます。運用テストの段階においては業務で使用するデータなども用いられ、本番と同様の環境のもとでテストを実施。

システムを利用する担当者が実際に操作して確認するなど、リリースに向けた最終リハーサルのような役割があります。

リリース

一連のテストが終了しシステムの動作に問題がないことを確認できたら、実際にシステムをリリースします。現在使用しているシステムから新システムの移行が行われ、開発担当者もそのサポートを行うケースが多いです。

運用保守

システム開発はリリースして終わりではありません。特に新しいシステムは思わぬ不具合やトラブルが起こり得るため、万が一に備えて運用保守の体制も整えておく必要があります。テスト段階では想定していなかった使い方やデータが入力され、予想外のトラブルに見舞われることもあります。

当然のことながらそのような事態に陥った際にはエンドユーザー側で対応することはできないため、開発側で責任をもって保守の対応をしなければなりません。

システム開発で用いられる略語

システム開発でよく用いられる略語

システム開発の現場では英語の頭文字を取った略語が頻繁に使用されています。それぞれの意味が分かっていないと話が通じないことも多いため、簡単な内容だけでも覚えておきましょう。

今回は代表的な略語をいくつかまとめてご紹介します。

・SA(Service Analysis):要求分析
・RD(Requirements Definition):要件定義
・BD(Basic Design):基本設計
・UI(User Interface):UI基本設計
・FD(Function Design):機能設計
・DD(Detail Design:詳細設計
・PD(Program Design):プログラム設計
・CD(Coding):コーディング
・PG(Programing):プログラミング
・UT(Unit Test):単体テスト
・IT(Integration Test):結合テスト
・ST(System Test):システムテスト

システム開発の手法は多様

システム開発の手法は多様

今回は代表的なシステム開発の事例をいくつか紹介してきましたが、これらはあくまでも基本的な項目であり、開発現場や会社によってもさまざまな手法が取り入れられています。

どの開発手法が良い、悪いと一概に比較できるものではなく、現場や各プロジェクトの特性によって最適な方法は異なるものです。まずは基本を押さえておくという意味でも、今回ご紹介した内容をまずはしっかりと押さえておいてください。

こちらの記事ではITエンジニアの将来性やIT業界に特化した転職エージェントについてもご紹介しています。ぜひ参考にしてみてください。

[email protected]で「表では話せない◯◯の話」配信中

line@-pt2

記事が役に立ったら
フォローをお願いします。

ハイキャリアに役立つ情報をお届けします。

Twitterも随時更新しています