システム開発工程とは？
システム開発は、アプリケーション開発とシステム構築と混在して認識される傾向にもあります。
工程を理解する上で、言葉の違いも含めて、正しく理解しておく必要があります。
開発工程とはなにか
そもそも「開発工程」とは、システム開発においてあらかじめ決まっている手順のことを指します。
（※フェーズと呼称することもあります）
一般的にシステムを作るための提案、要件定義から、運用・保守までの作業ステップを表す言葉として扱われます。
いわば「家づくり」における、建築のステップと同じような意味合いです。
システム開発を進める上では、工程ごとに期限や品質の基準などを設けていて、それぞれの工程がプロジェクト単位で厳格に管理されています。
このように工程を管理することで、一定の品質を保ちやすくなり、且つ期限までにシステム開発を完了・納品できることにつながります。
しかし、期限や品質はシステムの規模感によってばらつきがあります。
小規模なシステムであれば3ヵ月程度、大規模なシステム開発になると1年以上かかることもあり、各工程の期限を決めていくのが難しい場合もあります。
開発と構築との違いは？
システム開発、アプリケーション開発、インフラ構築と似たような言葉が登場します。
一般的には、システム開発＝アプリケーション開発＋システム構築のことを指します。
また、アプリケーション開発はアプリケーションを作るステップの事を指し、インフラ構築はアプリケーションが稼働する為のITインフラを作るステップの事を指します。
上記にある通り「開発」はプログラム等、ゼロからアプリケーションを作る作業を指すケースで使い、「構築」はインフラ等、既存のミドルウェア等を組み合わせて環境を作る作業を指すケースで使うことが一般的です。
また、システム構築といった言葉が出てくることもあります。
場合によって使い分けることもありますが、基本的にはほとんど同じ意味を持ちます。
（システム構築はシステム開発のテスト作業の工程後に、そのシステムが実際に運用できる環境を組み立てていく作業のことを意味する場合もあり）
そもそもの日本語としては、「開発」とは新しいものを作成し実用化することで、「構築」は既にあるものを組み立てて築き上げることを指します。
従って、システム開発は新しいシステムのみに限定されますが、システム構築はその限りではないともいえるかもしれません。
システム開発における、各工程別の具体的な作業内容
システム開発を適切に進めるためには、工程ごとに行う作業が異なります。
また、その工程を選任する役割や職種という考え方もあります。
（例として、プログラマ＝詳細設計・プログラミング 等を行う 等）
そうした点から、予め工程を正しく理解しておく必要があります。
システム開発の担当者であっても、担当工程以外のことはよく理解していなかったり、全体像を意識していないケースも少なくありません。
各工程の具体的な作業内容は以下の通りとなります。
要件定義
要件定義とは、新たに作り上げるシステムをどういった内容にしていくのか決めていく工程のことを指します。
ここで決めた内容をもとに、予算や人員、納期なども設定していきます。要件定義ではシステム開発の全体像を固めるため、単にプログラミングスキルだけでなく、工程ごとの計画を立てる能力やシステム開発の実績や経験なども求められます。
決定した内容を各工程の責任者に伝え、実行に移していきます。
そのため、事前にシステム開発の全体像を意識した上で、細部まで打ち合わせておかなければ、後々の認識のズレなどによって完成するシステム内容や納期などに大きな影響を及ぼす可能性が高まります。
様々なケーススタディなども考慮しながら開発するシステムの要件・内容を定義し、共有しておくことが重要です。
基本設計（外部設計）
基本設計（外部設計）とは、要件定義の工程で決めた内容を基に、それを実現する為の機能単位に細かく区分し、各機能がシステムとして何を実現するのかを決める工程（人間の作業をコンピュータによる作業に置き換えるイメージ）になります。
それ故に、主にインターフェース部分（ユーザーから見える部分）を設計する工程とも言えます。
故に、これから開発するシステムの基本設計をする形となり、成果物としては「基本設計書」が求められます。
「見た目の分かりやすさ」や「使い勝手」など、ユーザ側の目的が果たせる仕様になるか？が重要です。
例えば「見た目」に注力するあまり、使い勝手が悪ければ意味がありません。
企業向けのシステム開発であれば担当者の要望を考慮し、顧客向けのシステム開発であれば使い勝手の良さにも十分考慮する必要があります。
基本設計に不備があると、業務効率や満足度の低下につながる怖れもあります。
UI/UXを追求するとともにユーザー視点に立って内容を固めていくと効果的です。
詳細設計（内部設計）
基本設計が決まったのであれば、次に詳細設計（内部設計）を行います。
詳細設計とは、システム・アプリの「中身（機能・動作）」に関する設計のことを指し、成果物としては「詳細設計書」が求められます。
具体的には、機能の動作をプログラミングする為に必要な仕様固めとも言えます。
いくら基本設計がしっかりしていたとしても、プログラミング含めた内部をシステムとして正しく動作できていなければ意味がありません。
一方で、詳細設計も安定して使用可能なシステムであれば、ユーザビリティも向上し好評にもつながりやすくなります。
開発者側の視点でプログラムの設計を行い、コードの設計などは一人ではなく複数人でチェックしながら設計していくと効果的です。
プログラミング（製造）
詳細設計がある程度完成したら、プログラミングの工程を行います。
プログラミングは、設計を具現化する工程なので「製造工程」と呼んだりもします。
要件定義にて取り決めたしたシステムの仕様によって、それを実現する為に有用な開発環境や必要なプログラミング言語は異なります。
従って、仕様に応じて様々な言語を使い分けながら、実際にプログラミングを組んでいきます。
（家づくりに例えるならば、木造在来工法なのか、2×4なのか、鉄骨なのか といったイメージで、建てる家の用途に応じて作り方を変えるのと同じです）
一般的に使用言語として人気が高いJavaをはじめ、実行速度の速さに定評があるC言語などが多く活用されています。
単体テスト
プログラミングが完了したら、要件定義や基本設計で決めた仕様通りの動きをするかを確認するため、テスト工程に移ります。
このテストにもいくつか工程がありますが、まずは単体テストを行います。
単体テストでは、個々のプログラムが詳細設計で定めた仕様を満たしているか一つずつチェックします。
正常に反応しないプログラムが見つかれば、問題の内容を確認し、原因究明を行うとともに、修正につなげていきます。
結合テスト
単体テストの後には、結合テストを行います。
結合テストでは、複数のプログラムが正常に反応するか確認します。
いわば、基本設計で定めた機能の仕様を満たしているかの点検です。
プログラムは単体では動作したとしても、組み合わせると正常に動かないことがあります。
そのため、データの受け渡しなどでプログラム同士が正しく連携するかなど、複数のプログラムを結合させてチェックすることは非常に重要となります。
単体テストと同様、正常に反応しなかったプログラムが見つかれば、反応した内容を確認してどこに問題があったのか原因究明を行うとともに、修正につなげていきます。
システムテスト
単体テストと結合テストが問題無く終わった後には、システムテストを行います。
すべてのプログラムを合わせて正常に反応してくれるか確認するテストを行います。
システムテストの中では、すべてのプログラムを組み合わせて正常に反応するか、アクセスへの耐久性や処理速度などに注意し確認する必要があります。
最終テストであるからこそ、要件定義で定めた内容はもちろんのこと、実際に利用するユーザー目線でのチェックが重要です。
開発側の環境で問題なくシステムが運用できるか確認した上で、問題無ければ最後のテストに移っていきます。
運用テスト
運用テストは、システムを納品・リリースする前の最終工程のことを指します。
実際にシステムを利用する環境下において、正常に反応するか実用性を重視しながらチェックしていきます。
システム開発時に用いるテスト環境下で正常に作動したとしても、実際の納品先企業などでは作動しないケースは少なくありません。
そのため、より運用面を考慮し今まで以上に実用フェーズで確認していくことが重要です。
リリース
ここまで全てのテストが正常に完了したら、いよいよ開発したシステムをリリースしていきます。
一般的にシステムの移行には旧システムから新システムに一気に切り替える一斉移行と、段階的に徐々に切り替える順次移行の2パターンが存在します。
一斉移行は新システムへの移行を急いで行う場合に効果的な反面、現場で使う人がすぐに対応できず現場が混乱することもあります。
そのため、急いで新システムに移行させる必要がない場合は、基本的に順次移行で段階的にシステムを切り替えていく方法が効果的です。
運用保守
システム開発は作り上げたら終わりという訳ではありません。
リリース後は安定して運用したり、バグに対応したりできるように体制を築いて監視を続ける必要があります。
そうした、実利用環境におけるサポートや、フレキシブルな対応をする工程のことを運用保守と言います。
開発したものをリリースして間もない間は、予期せぬ障害やトラブルが発生する可能性も起こり得ます。
従って、通常「運用・保守」は開発したシステム会社が担うケースが多くなりますが、中にはヘルプデスクやユーザサポート等のコミュニケーション面を重視して、運用保守以降の工程は専門の会社が担うケースもあります。
このように、各工程が1日で終わるような仕事では無い為、まるで工程＝職種のようにも感じられるかもしれません。
プログラマやテスターといった職種は、まさにその工程を専門に行う役割＝職種とも言えそうです。
また、一般的には要件定義～基本設計を上流工程、詳細設計以降を下流工程と呼んだりします。
開発工程モデルについて解説！それぞれのプロセスや特徴
ここまでシステム開発の工程について一連の流れを紹介してきましたが、続いて代表的な２つの開発モデル（方式）についても触れていきます。
ウォーターフォールモデル
ウォーターフォールモデルとは、上述の一連のシステム開発工程を上流工程から下流工程に向け流れるように進めるモデルのことを指します。
上流から下流に向かって進んでいき、戻ることのない一方通行の開発プロセスであることから、滝をイメージしウォーターフォールモデルとよばれています。
現在のようにWeb系開発（開発した内容が即座に反映される環境）が主流になる前は、ほとんどがこのモデルで開発されていました。
それ故に、経験者も多く、緻密に要件や設計を固めて仕事を進める為、手堅い手法とも言えます。
1つのフェーズが完了してから次のフェーズに着手するため、進捗の把握が比較的簡単で計画的に工程を進めることが可能です。
一方で、ミスや不具合があった場合、それをリカバリーするのに時間やコストが掛かる点や、前の工程が終わらないと先に進めないことから、システムを完成させるのに時間がかかる傾向にある点がデメリットとして挙げられます。
アジャイルモデル
アジャイルモデルとは、機能ごとに開発工程を何度も繰り返しながら、状況に応じて随時変更や修正を行う開発工程モデルのことを指します。
柔軟性を重視しており、スピードが求められるプロジェクトと相性がいい開発工程モデルとなります。
ウォーターフォールモデルに比べ要件定義をそこまで固め過ぎず、システム開発までのスピードを速くすることが可能ですが、工程の進捗や状況を把握するのが難しい傾向にもあります。
また、複数社が絡むことが多いシステム開発工程においては、柔軟性によって担当者の責任範囲が不透明化しやすいアジャイルモデルでは、対応できる会社が少ないこともデメリットとして挙げられます。
