システム開発は、大きく「要件定義」「設計」「開発(プログラミング)」「テスト」「リリース」「運用・保守」の順に進みます。ITエンジニアの仕事は、この流れのどこかを担当するか、全体を見ながら進めることです。
この記事では、システム開発の流れを工程ごとに、未経験の方にもイメージしやすいよう、公務員の仕事(制度づくりや事業の進め方)にたとえながら解説します。ITエンジニアの仕事の全体像をつかむ参考にしてください。
この記事の結論
- システム開発は「要件定義→設計→開発→テスト→リリース→運用・保守」の順に進むのが基本
- 前半の要件定義・設計は「何を作るかを決める」工程、後半の開発・テストは「決めたとおりに作り、確かめる」工程
- 進め方には、順番に一つずつ進める「ウォーターフォール」と、短い期間で作って見直す「アジャイル」がある
- 要望の聞き取り、関係者との調整、文書の作成、正確な確認など、公務員の仕事と共通する部分は多い
システム開発の全体の流れ
| 工程 | やること | 公務員の仕事にたとえると |
|---|---|---|
| 要件定義 | 利用者の要望を聞き、システムで何を実現するかを決める | 事業の目的と、住民に提供するサービスの内容を決める |
| 設計 | 画面や処理、データの持ち方などを具体的に決める | 要綱や様式、事務の手順を具体的に作る |
| 開発 | 設計どおりにプログラムを書く | 決めた手順どおりに準備を進める |
| テスト | 正しく動くか、さまざまな場合で確かめる | 試行や読み合わせで、抜け漏れがないか確かめる |
| リリース | 利用者が使える状態にする | 制度や事業を開始する |
| 運用・保守 | 問い合わせ対応、不具合の修正、改善を行う | 開始後の問い合わせ対応や、要綱の改正 |
ここからは、各工程を順番に見ていきます。
1. 要件定義:何を作るかを決める
要件定義は、システムを使う人(発注者や利用者)の要望を聞き取り、「このシステムで何ができるようにするか」を決める工程です。たとえば「申請を紙ではなくオンラインで受け付けたい」という要望があれば、誰が、どんな情報を入力し、誰が確認して、結果をどう知らせるのかまで整理します。
この工程で決めた内容は「要件定義書」という文書にまとめ、発注者と合意します。後の工程はすべてこの文書をもとに進むため、聞き漏れや思い違いがあると、後から大きな手戻りが発生します。
相手の話を丁寧に聞き、あいまいな点を確認し、関係者の合意を取りながら文書にまとめる力が求められます。
2. 設計:どう作るかを具体的に決める
設計は、要件定義で決めた内容を、実際に作れるレベルまで具体的にする工程です。一般的に、利用者から見える部分を決める「基本設計」と、プログラムの中の処理を決める「詳細設計」に分かれます。
| 設計の種類 | 決める内容の例 |
|---|---|
| 基本設計 | 画面の項目と配置、帳票の様式、ほかのシステムとのつながり |
| 詳細設計 | 入力された値のチェック方法、計算の手順、データベースへの保存の仕方 |
設計書は、開発を担当するエンジニアが読んで、迷わずに作れることが大切です。
3. 開発(プログラミング):設計どおりに作る
開発は、設計書をもとにプログラムを書く工程です。一般に「ITエンジニアの仕事」としてイメージされやすいのがこの工程です。
開発では、ほかのメンバーが書いたプログラムと組み合わせて動くように作る必要があります。そのため、決められたルールに沿って書くこと、ほかの人が読んでもわかるように書くこと、作った内容を記録に残すことも大切です。
4. テスト:正しく動くかを確かめる
テストは、作ったシステムが設計どおりに動くか、想定外の操作をしても問題が起きないかを確かめる工程です。小さな単位から順番に確かめていきます。
| テストの種類 | 確かめる内容 |
|---|---|
| 単体テスト | 一つひとつの機能が正しく動くか |
| 結合テスト | 機能どうしを組み合わせたときに正しく動くか |
| 総合テスト | システム全体が、実際の使い方で問題なく動くか |
| 受け入れテスト | 発注者が、要件どおりにできているかを確認する |
たとえば税額や給付額を計算するシステムなら、通常の場合だけでなく、上限・下限ぎりぎりの値や、例外的な条件でも正しく計算されるかを確かめます。決められた手順どおりに、抜け漏れなく確認していく正確さが求められます。
5. リリース:使える状態にする
テストで問題がないことを確認したら、システムを本番の環境に移して、利用者が使える状態にします。古いシステムからの切り替えがある場合は、データの移行や、利用者への説明、切り替え当日の手順の確認なども行います。
6. 運用・保守:使われ続けるように支える
システムは、使い始めてからが本番です。運用・保守では、利用者からの問い合わせ対応、不具合の調査と修正、利用状況の監視、法改正や業務の変更に合わせた改修などを行います。
行政のシステムでは、制度が変わるたびに改修が必要になります。制度の内容を理解して、影響する部分を正しく直していくことが求められます。
開発の進め方:ウォーターフォールとアジャイル
システム開発の進め方には、大きく2つの考え方があります。
| 進め方 | 特徴 | 向いている開発 |
|---|---|---|
| ウォーターフォール | 要件定義から運用まで、工程を順番に一つずつ進める。前の工程に戻ることは原則として想定しない | 作るものが最初からはっきり決まっている開発。大規模なシステムや、行政の基幹システムなど |
| アジャイル | 小さな単位で「作る→確かめる→見直す」を短い期間で繰り返す | 使いながら改善していきたいサービス。Webサービスやアプリなど |
どちらが優れているということではなく、作るものや発注者との関係によって使い分けられています。
未経験からITエンジニアになったら、どこから担当する?
未経験で入社した場合、最初はテストや運用・保守、先輩の指示に沿った開発など、決められた範囲の作業から担当することが一般的です。経験を積むにつれて、設計や要件定義といった上流の工程も任されるようになります。
どの工程が自分に合うかは、実際に経験してみないとわからないことが多いものです。最初から特定の工程や職種にこだわらず、任された仕事を通して全体の流れを理解していくと、自分の強みが見つけやすくなります。
公務員として、要望の聞き取りや関係者との調整、文書の作成、正確な事務処理をしてきた経験は、どの工程でも役に立ちます。
よくある質問
Q. システム開発にはどれくらいの期間がかかりますか?
規模によって大きく異なります。小さな機能の追加なら数週間、大きなシステムを新しく作る場合は1年以上かかることもあります。
Q. 要件定義や設計は、プログラミングができないと担当できませんか?
担当すること自体はできますが、プログラミングやシステムの仕組みを理解していると、実際に作れる内容かどうかを判断しやすくなります。多くの場合、開発やテストを経験してから上流の工程を担当していきます。
Q. 行政のシステムと民間企業のシステムで、開発の流れは違いますか?
工程の流れそのものは同じです。行政のシステムでは、法令や制度が仕様になることや、入札などの調達手続きがあることが特徴です。詳しくは公共系SEとは?官公庁・自治体システムの仕事内容で解説しています。
まとめ
システム開発は、要件定義、設計、開発、テスト、リリース、運用・保守の順に進みます。前半は「何を作るかを決める」、後半は「決めたとおりに作って確かめる」工程で、どの工程でも、要望の聞き取りや調整、正確な文書作成と確認が欠かせません。公務員として積み上げてきた仕事の進め方は、システム開発の現場でも活きる場面が多くあります。
ITエンジニアへの転職の進め方は公務員からITエンジニアに転職する方法で解説しています。TechVillageでは、公務員からITエンジニアへの転職を考えている方の無料カウンセリングを行っています。

