目次
システム開発における工程の基礎知識
システム開発には、さまざまな工程と流れがあります。工程管理表やマイルストーン表に基づき、あらかじめ決められた開発方針に従って作業を進めることで、計画的かつ効率的にシステム開発を進行することができます。システム開発を業者に発注する場合であっても、工程や流れを理解していることでシステム開発会社とのコミュニケーションが円滑になり、細かな調整や依頼がスムーズになります。これは業務系システムの開発であってもWeb系のシステムやアプリ開発であっても共通して言えることでしょう。また、システム開発をおこなう側としても、自分が関わっている仕事の工程以外を理解でき、流れの見直しや開発の手順理解について知識を深める良いきっかけになるはずです。
はじめに、システム開発における工程の基礎知識を解説します。そもそもシステム開発における工程とはどのようなものなのか、発注の際に工程への理解があると良い理由、工程や工数の比率・割合、使用頻度の高い略語について、詳しくチェックしていきます。
そもそもシステム開発における工程とは？
ここでいう「工程」とは、システム開発をおこなううえであらかじめ決まっている、必要なプロセスを指します。つまり、要件定義や外部設計、内部設計、プログラミングなどの、システム開発をおこなうために必須となる一つひとつのプロセスを指します。
工程に沿ってシステムを開発していく目的は、計画通りスムーズに開発を進行させることです。開発プロセスを工程に分割し、一連の流れに沿って進めることで、品質や進捗状況を管理しやすくなります。
実際の開発では、一つひとつの工程に期限や品質の基準などを設定しておき、決められた基準を守るように管理していきます。工程を理解し、それぞれの工程で管理をおこなうことにより、仕事の期限を守りつつシステムの質を確保できるのです。
システム開発における工程には厳密なルールはないため、分割の仕方などは企業ごとに異なります。
発注の際に工程への理解があると良い理由
先述のとおり、自社ではシステム開発をおこなわずに開発会社へ発注する場合であっても、工程への理解があるほうがいいです。なにもわからないままではシステム開発にどのように関わればいいのかわからず、開発工程を完全に委ねてしまうことになりかねません。
この状態では必要なチェックができなかったり、開発会社にうまく意図が伝わらないなどのコミュニケーションの問題が発生したりといったトラブルにつながります。うまく関われなかった結果、完成に近づいた時点で大幅な修正が必要になってしまい、大幅に納期が遅れるなどの問題が出てきてしまいかねないのです。
このほかにも、「仕様変更」はシステム開発においてよく問題になっています。仕様変更とは、システム開発の工程がどんどん進んで言った段階で、伝えたいことに漏れがあるなどして途中で「やっぱりこれを変更したい」といわれることです。
システム開発では、はじめの工程で要件定義をおこない設定を進めていきます。後々の開発工程で仕様変更があると、計画どおりに進行できなくなって開発者を混乱させます。その結果、見直しや変更が必要になったことによる納期の遅延や追加費用の発生などにつながっていく可能性があるのです。
発注の際に工程への理解がないと、途中で変更のリクエストをしても「ほんの一部分を変更させるだけなら問題ないだろう」と認識してしまいます。しかし、工程への理解があれば、トラブルなくしっかりとシステム開発をおこなってもらうためには、はじめの要件定義の段階でしっかりと伝えておくことが重要だと理解できるでしょう。もしも仕様変更が必要になった場合には、リスクを把握したうえでそれでも必要かどうかを判断するのがおすすめです。
システム開発の工程の工数比率・割合
工程の理解を深めるために、システム開発工数全体に対してそれぞれの工程がどれほどの工数比率であるのかをチェックしていきましょう。日本情報システム・ユーザー協会（JUAS）が発表した「ソフトウェアメトリックス調査２０２０」によると、２０１８～２０２０年に集めたデータでの実績工数比率は、以下のとおりです。
・要件定義：２０％未満
・設計から統合テスト（外部設計、内部設計、プログラミング、単体テスト、結合テスト、システムテスト）：６０％以上９０％未満
・運用テスト：２０％未満
こちらのデータに対して、望ましいと感じている工数比率として集めたデータは、以下のとおりでした。
・要件定義：４０％未満
・設計から統合テスト：３０％以上８０％未満
・運用テスト：２０％以上３０％未満
システム開発する際に、今よりも設計から統合テストの割合をおさえて、要件定義や運用テストの時間をとったほうがいいと感じる人が多いようです。しかし、実際には設計から統合テストの段階で工数が多くなっているのが実態なのです。
システム開発で使用頻度の高い略語
要件定義では、クライアントと開発会社がそれぞれの話を理解して、しっかりとコミュニケーションをとることが重要です。依頼する側にとっては専門用語を理解しやすいように、受注する開発会社側にとってはクライアントに話を説明しやすいように、以下の使用頻度の高い略語の意味を確認しておきましょう。また本記事では代表的な用語を取り上げていますが、より詳細な情報を知りたい方はIPA（独立行政法人情報処理推進機構）が公表するガイドライン等を一読すると学びが多いはずです。
参考：IPAの詳細はこちら
＜システム開発における代表的な開発略語＞
- SP……企画
- SA……要求分析・システム方式設計要求分析
- RD-UI……要件定義（RDのみで要件定義を意図することもある）
- UI……基本設計
- BD……基本設計
- SS……構造設計
- FD……機能設計
- DD……詳細設計
- PD……詳細設計・プログラム設計
- PS……詳細設計
- M……製造
- UT……単体テスト
- CD……コーディング
- PG……プログラミング
- IT……結合テスト
- ST……システムテスト
- PT……総合テスト
- OTO……運用テスト
システム開発の主な工程・流れ
システム開発の主な工程や流れは以下のとおりです。
- 要件定義：打ち合わせと要件定義書の作成をおこなう
- 外部設計・基本設計：UIを設計する
- 内部設計・詳細設計：プログラムを設計する
- プログラミング：実際にシステムを開発する
- 単体テスト：正しい動作か確認する
- 結合テスト：プログラム同士を連携させてテストする
- システムテスト：全体の総合的なテストをおこなう
- 運用テスト：実環境に近い状況でテストをおこなう
- システム移行・リリース：システムを公開し、必要であれば移行作業をおこなう
- 運用・保守：安定稼働させるために対応していく
それぞれの工程ごとに、ポイントを詳しくチェックしていきましょう。
要件定義：打ち合わせと要件定義書の作成
クライアントと契約書を取り交わした後、要件定義工程に入ります。本工程ではクライアントと開発会社間で打ち合わせをおこない、双方のディスカッションの中で得られた情報を基に要件定義書と呼ばれるドキュメントを作成します。要件定義が明確でない場合、開発を進める際に盛り込むべき内容が曖昧になってしまいます。また言った言ってないの議論もプロジェクトの中では非常に発生しやすいです。開発会社側はクライアントの要望をしっかりと確認し、作り上げるシステムの概要を決めていく必要があります。
打ち合わせの際に現場の代表者や責任者が参加せず、現場を知らない管理職が無用の長物といえるようなリクエストをするケースがあります。このような状況はシステム開発の手間がかかるだけではなく、現場で使いづらいシステムを開発してしまう危険を孕んでいます。打ち合わせの際に伝える要望はできるだけ現場目線の声をベースにすべきでしょう。
システムに盛り込む内容が決定した後はそれをもとに予算や期間、人員などを設定します。要件定義工程についてより詳しい情報を知りたい方は以下のURLをご確認いただけたらと思います。要件定義工程で行うことや実際にどのような成果物を作成するのかが分かるはずです。
要件定義の成果物とはなにか？具体的な作業内容や進め方についてシステムエンジニアが解説
外部設計・基本設計：UIの設計
要件定義が完了した後、外部設計や基本設計、インタフェース設計などと呼ばれる工程に移ります。外部設計では、要件定義で決めた内容をもとに、ハードウェアの設計やシステムの操作画面のレイアウトなど、搭載すべきものやシステムの特徴をより具体的に決定していきます。
ここでユーザーインターフェース（UI）を設計するため、ユーザー側の視点に立って使い勝手のいいシステムになるよう検討することが重要です。見栄えの良さだけではなく、効率よく動き、操作性が高く、アクセスしやすいシステムになるように設計を進めます。
この工程では、基本設計書やシステム構成図、インタフェース設計書、外部設計書、方式設計書、テーブル定義書、ファイル定義書が成果物です。また、外部設計の工程では、開発期間や費用についてクライアント側と話し合います。
内部設計・詳細設計：プログラムの設計
内部設計や詳細設計と呼ばれるのが、システムの中身である機能や動作の設計をおこなう工程です。開発言語やAPIとの連携、サーバー・データベース、プログラミングのルールの策定など、主に技術的な要素を設計していきます。この工程で作成するのは、単体テスト仕様書や詳細設計書などです。
外部設計や内部設計というとおり、外部設計では人の目に見える部分を設計し、内部設計は人の目に触れないものを動かすために必要な部分を設計します。内部設計をおこなうことで、外部設計で設計した内容をシステムに正しく反映できるようになるのです。
プログラミング：実際にシステムを開発
プログラミングの工程では、実際にシステムを開発していきます。これは、コーディングや開発とも呼ばれる工程です。システム開発においては、これまでの「要件定義」や「基本設計」、「詳細設計」の工程を「上流工程」と呼び、プログラミング以降の工程を「下流工程」と呼びます。
内部設計の際にプログラミングの型をある程度開発しますが、この工程では実際に作り上げていくフェーズです。この工程ではプログラミング言語を用いますが、使用する言語の種類によって特徴が異なってきます。プログラミングの際はシステムごとに必要となるプログラミング言語が異なるため、さまざまな言語を使い分けながら進めていくことがあります。
単体テスト：正しい動作の確認
単体テストは、プログラムが正しく動作するかをチェックする工程です。詳細設計の際に作成しておいた単体テスト仕様書をもとに、動作確認をおこないます。
テストにはいくつか種類があり、はじめにおこなうテストは、個々のプログラムが要件定義で定めた内容どおりに動くかどうかのチェックです。もしも正常に反応しなかった場合には、どのように反応したのかを確認し、問題があった部分を修正します。
結合テスト：プログラム同士の連携のテスト
結合テストは、プログラム同士を連携させて、正常に反応するかどうかをテストする工程です。単体ではうまくいっても、複数のプログラムが組み合わさると干渉によって正常に作動しないケースがあります。たとえばデータの受け渡しをしてみるなどで、プログラム同士で連携がとれ、基本設計書で定めた機能が再現できているかどうかを検証するのです。
システムテスト：全体の総合的なテスト
システムテストでは、全体の総合的なテストをおこないます。この工程でのテストとは、すべてのプログラムを合わせた状態で正常に作動するのかどうかをチェックしているものです。
システムテストでおこなうのは、動作確認だけではありません。アクセスへの耐久性や処理速度など、実際にユーザーが利用する際に問題がないかを確認していきます。
運用テスト：実環境に近い状況でのテスト
運用テストの工程で実施するのは、実際にシステムを利用する環境に近いものを用意し、そのなかで正常に反応してくれるかどうかという、実用性を重視したテストです。システム移行やリリース前の最終テストとなるため、ありとあらゆる状況を検証していきます。
テストできる環境を早めに整備しておけるように、外部設計が終わったあたりの段階から準備を進めていくといいでしょう。
システム移行・リリース（上市）：新システムを公開
先述の各テストで徹底的に検証し、現場での運用に問題がない状態だと判断できれば、システム移行やリリースをおこないます。市場にリリース（公開）するときは、システムのすべての機能が一度に公開されるわけではなく、クライアント側のビジネス戦略に応じて順次リリースされていくという流れです。
開発したものが社内システムなどで、もしも既存のシステムを使っている場合には、旧システムから新システムへの移行作業をおこないます。この場合にも、一気に切り替えていく一斉移行の方法と、少しずつ切り替えていく順次移行の方法から選択可能です。
運用・保守：安定稼働させるための対応
システムを実際に使い始めたら、安定稼働させるために運用・保守の工程として対応していきます。その後もしもバグがあれば正常に動くようにしたり、アップデートを実施したりなどの対応をとっていくのです。これによって、システムを使い続けられるようにしていけます。
システム開発工程のモデルの種類
システム開発工程のモデルには複数の種類がありますが、今回は以下のモデルをチェックしていきましょう。
・ウォーターフォール開発
・アジャイル開発
・V字モデル
・XP（ペアプログラミング）
・スパイラル開発
・MVP開発・プロトタイピング開発
・DevOps（呼び方：デブ・オプス）
ウォーターフォール開発とアジャイル開発は、開発工程の基本となる２モデルです。V字モデルは、開発工程とテスト工程をリンクさせ、ウォーターフォール開発を進化させたモデルだといわれています。それぞれのシステム開発工程モデルの種類について、特徴を解説します。
ウォーターフォール開発
ウォーターフォールとは、上流から下流へ水が流れていくことを指す表現です。つまり、上流工程から下流工程に向かって、一定の流れで進めていく開発方法を表しています。決められた順に工程を進めていく方法で、1つの工程が完了しないうちには次の工程に入ることはありません。
進捗状況の把握が容易で、高い品質のシステムが作りやすいのがメリットです。ただし、素早いシステム開発は苦手で、仕様変更へ対応する難易度が高いというデメリットもあります。
アジャイル開発
アジャイル開発は後戻りすることを前提に進行していく開発方法です。ウォーターフォールとは違ってはじめに全体を綿密に設計せず、１つの工程をしっかりと完成させる前に進めていくため、各工程をスピーディに進行させられます。また、工程の後戻りができるため、途中での仕様変更に対応しやすい開発方法です。ただし、工程の進捗状況の管理が難しいこと、対応できる開発会社が少ないという点がデメリットです。
アジャイル開発の指針となる手法のひとつに、スクラム開発と呼ばれるものがあります。スクラム開発はチームで開発する手法で、メンバーそれぞれが違った役割を果たしつつ、しっかりとコミュニケーションを取って開発していく方法です。スクラム開発は、今後も更新が必要なシステムなどを開発する案件に適しているといわれています。
V字モデル
V字モデルでは、プログラミングの工程までウォーターフォールと同じく上流から下流へ流れるように進められます。プログラミングが終わってテストの段階になってからは、テスト工程と開発工程とでそれぞれの工程をリンクさせて、効率的に検証作業を実施する方法です。
単体テストでは内部設計のチェック、結合テストでは外部設計のチェック、システムテストで要件定義の内容の実装をチェックします。このように、折り返して一つひとつ上流にのぼりながら工程を確認していくため、V字モデルといわれています。
テストする内容を明確にできるため作業進捗がわかりやすく、テスト工程で手戻りのリスクを軽減できるという点がメリットです。
XP（ペアプログラミング）
XPとはエクストリームプログラミングの略称で、アジャイル開発の手法のひとつです。
アジャイル開発では、ひとつの機能ごとに要件定義から設計、開発、テストの開発工程を小さなサイクルにして何度もおこないます。これによりひとつずつの機能を独立させた状態にでき、顧客の要望を取り入れながら臨機応変に進めてもリスクの最小化が可能です。
XPも先述したスクラム開発も、アジャイルの思想を実現させるための手法として作られています。スクラム開発は開発スピードを高めて素早く作り上げていく手法で、XPは継続的な成長を要としている手法です。スクラム開発との大きな違いとして、XPではペアプログラミングを実施することが挙げられます。
ペアプログラミングは、２人のプログラマーが共同でプログラミングをおこなうことです。コードを記述する者とそれを確認・補佐する者とがペアになり、確認しながらプログラミングするため、その場ですぐに課題を解決できるというメリットがあります。
スパイラル開発
スパイラル開発は機能ごとに開発工程を繰り返す開発方法で、アジャイル開発と似ています。アジャイル開発との違いは、機能のリリース時期や重視するポイントです。
アジャイル開発は機能ごとに開発を完成させてその都度リリースするため、サービスを稼働させながら開発を進めていきます。スパイラル開発でも機能ごとに工程をおこなうものの、機能は動作確認のためのプロトタイプとして開発していきます。その後クライアントレビューを確認して改善しつつ、全ての機能の実装が完了してからリリースすることが大きな違いです。
アジャイル開発はスパイラル開発と比べて計画的に進められるという点がメリットです。一方、スパイラル開発はより品質を重視して開発できるというメリットがあります。
ただし、スパイラル開発は開発にコストがかかるため、アジャイル開発のほうが普及している傾向があります。
MVP開発・プロトタイプ開発
プロトタイピング開発手法とは、早い段階で簡易版であるプロトタイプ（試作品）を開発し、クライアントからのフィードバックを確認してから完成させていく開発手法です。
はじめの打ち合わせの段階でいろいろと確認を取っていても、クライアントがイメージできていなかったり、使ってみてから考えたかったりするケースはよくあります。こんな場合には簡易版を使って確認してみると実際の完成イメージがつかみやすくなるでしょう。
そのため、仕様が明確に決められていない場合や、クライアントが発注に慣れていないケース、操作性が重要なものの開発には、プロトタイピング開発手法がおすすめです。
プロトタイピング開発手法では早期にプロトタイプを試して完成イメージを確認するため、どのようなシステムを開発するのかという認識のズレが回避できます。また、技術的に実装が難しい機能などの問題点が早い段階で確認でき、不具合を回避しやすくなる点もメリットです。ただし、完成品だけではなくプロトタイプも作るため、コストがかかることや開発者の負担が大きくなりやすいというデメリットもあります。
DevOps
DevOpsとは、Development（開発チーム）とOperations（運用チーム）が連携しあう開発手法で、それぞれの単語を組み合わせて作られた言葉です。連携してシステム開発することによって、余分な工数を削減して素早く柔軟にかつ高い品質で対応できる仕組みを作れます。
情報共有の促進や、それぞれのチームが尊重しあえる組織文化を構築すること、テスト効率化のためのツール活用などが、DevOpsの重要なポイントです。
DevOpsは開発手法としてだけではなく、概念として使われることもある言葉です。最近はアジャイル開発が多くなったこともあって、開発チームは改善と修正を繰り返しています。しかし、運用チームはシステムを安定稼働させるために何度も変更したくないという思いがあり、重視するものが違う分反発しあってしまうことがあるものです。
先述したとおり、お互い協力しあったほうがいいシステムが開発できます。そのため、DevOpsが注目されるようになったのです。
システム開発の工程で注意すべきポイント
システム開発の工程で注意すべきポイントは、以下の３点です。
・仕様変更はできるだけ避けること
・発注者・受注者間がコミュニケーションをしっかりと取ること
・双方のプロジェクトマネージャーがプロジェクトにコミットすること
先述のとおり、システム開発に取り掛かって、工程の途中で「やっぱりこうしたい」と仕様変更することは、トラブルのもとになります。納期の延期や開発コストの増加につながるため、できる限りはじめの要件定義の段階で要望を伝えましょう。
また、コミュニケーション不足は開発の遅延や障害などを招く恐れがあります。あらゆる関係者が必要なコミュニケーションをしっかりととるように心がけましょう。
開発工程と流れを理解しスムーズにシステムを開発しよう
システム開発における工程とは、開発のために必要となるプロセスのことです。つまり、要件定義や外部設計、内部設計、プログラミングなどの、システム開発をおこなうために必須となる一つひとつのプロセスを指しています。
システム開発を業者に発注する場合であっても、工程を理解していると開発会社とのコミュニケーションが取りやすくなり、スムーズに依頼可能です。また、システム開発をおこなう側としても、自分が関わっている仕事の工程以外を理解でき、流れの見直しや開発についての理解を深めるきっかけになるでしょう。
それぞれの工程やシステム開発モデル、注意点などを理解したうえで、スムーズに開発していきましょう。
まとめ
本記事はこちらで以上となります。いかがだったでしょうか。
昨今のシステム開発手法は、かなり複雑になってきています。自社が開発するシステムの性質や特性を見極め、適切な開発手法を選択することが肝要です。またプロジェクトが開始した後も発注者・受注者がしっかりとコミュニケーションを取り、システム開発に最初から最後までコミットする必要があります。よくありがちなのは、「高いお金を払ったんだし、システム開発会社がよしなに良いものを作ってくれるだろう。」と考え、発注者側のプロジェクト責任者がプロジェクトに関与しなくなることです。発注者の社内事情を一番理解しているのは発注者側です。受注者側であるシステム開発会社側はヒアリングや質問紙調査を通じて、発注者の社内事情を理解できるように、可能な限り努力をしますが、それでも短期間で吸収できる量には限界があります。「失敗しない開発」には、双方の適切なコミュニケーション、リレーション作りが非常に重要になってきます。
システム開発の経験がない方や少ない方、社内決裁や稟議を通すことに自信がない方は、企画・構想の段階から開発会社に協力をお願いすると良いでしょう。
システム開発、アプリ開発、新規事業立ち上げ、DX化の推進でお困りではありませんか？
日本全国には開発会社が無数にありますが、保守性や堅牢性に優れた高品質のシステムやスケール（規模拡大）を目指すアプリサービスを実現させる開発会社は、全国で見ても多くはなく、弊社・GeNEEは数少ないその一つ。
お客様のご要望通りに開発することを良しとせず、お客様と共に伴走しながらビジネス全体にとっての最適な解を模索しながら、プロジェクト全体を推進する、ビジネス×テック（技術力）×デザインの三位一体型システム開発/アプリ開発会社です。DXやIT全般に関して、何かお困りのことがございましたら下記の「GeNEEへのお問合せ」フォームからお気軽にご連絡いただけたらと思います。
またエンジニアの稼働提供（SES）のご依頼・ご相談に関しては、弊社グループのGNSで御請けしております。「1名からエンジニアを派遣してほしい。」、「ScalaやGo言語といった母集団の少ないエンジニアの手を借りたい。」などご要望がございましたらこちらからお気軽にご相談いただけたらと思います。
