エンジニア全般
システム開発には要件定義から設計、コーディング、テストと複数のフェーズがあります。この一連の流れや工程をシステム開発工程と呼びます。
この記事ではシステム開発工程の基本の流れや開発を効率的に進めるコツだけでなく、開発でよく使われる略語の意味も一覧でわかりやすくまとめました。
システム開発を検討している方は、ぜひ参考にしてください。
小中規模プロジェクトを中心にSEやコンサルとして活動。クラウド導入やスタートアップ、新規事業開拓の支援も経験しました。
システム開発工程1：要件定義
要件定義は、システムで実現したい機能を洗い出し、仕様を文書化する段階です。
リスト化
例えば、「商品を注文する」「会員登録ができる」など、システムでなすべきことをできるだけ細かくリスト化します。これにより、開発の方向性が明確になります。
そしてユーザーから聞き取りを行い、システムで実現すべき機能や条件を洗い出します。ユーザーには、システムの主な利用者を選定し、インタビューやアンケート、ワークショップなどを通じて意見を集めることが多いです。
機能要件と非機能要件に分ける
収集した要件は、機能要件と非機能要件に分類されます。機能要件は「何ができるか」、非機能要件は「どのように動作するか」を表します。
例えば、「注文履歴を表示する」は機能要件、「注文処理時間は1秒以内」は非機能要件です。
補足資料を作成する
要件定義書には要件一覧に加え、画面遷移図やワイヤーフレームなどの補足資料を含めるのが一般的です。
要件定義書が完成したら関係者全員で内容をレビューし、要件が正しく文書化されていることを確認します。ポイントは、ユーザー目線で必要な機能を洗い出すこと、要件の粒度を適切に定めること、変更容易な柔軟な文書形式を使うことです。
品質の高い要件定義書ができれば、開発工数が削減でき、同時にシステムの品質も高まります。
システム開発工程2：基本設計
基本設計は、要件定義で洗い出した機能を、どのようなデータ構造や処理フローで実現するかを設計する段階です。
例えば、顧客データはどのテーブルに格納するのか、注文処理はどのようにデータを受け渡すのか、を検討します。
基本設計の進め方
基本設計ではまずシステムの全体構造を設計します。前提となるハードウェアやネットワーク環境や外部システムとの連携を検討し、システム構成図を作成します。
次に機能ごとの処理フローを設計します。要件定義書に基づき、データフローや画面遷移を表すフローチャートを作成します。主要な処理単位ごとにモジュールを定義し、モジュール間の関係を明確化します。
さらにデータ構造の設計を行います。どのようなデータをどこに格納するか、データベースのテーブル定義を設計します。
基本設計のポイントは、要件を満たすシンプルな設計、将来の変更に強い柔軟性の高い設計を目指すことです。
基本設計書の記載内容
基本設計書は要件をもとにシステムの技術的な内容を詳細に定義するドキュメントです。
各項目の詳細度合いは案件により異なりますが、概要や要件定義からデータ、アプリケーション、セキュリティの設計など、次工程の詳細設計や開発に必要な情報が漏れなく記載されている必要があります。
設計書が完成したらレビューを実施し、問題点を洗い出して仕様を固めます。
システム開発工程3：詳細設計
詳細設計は、基本設計で考えた処理フローやデータ構造をより詳細に設計する段階です。コードに近い形で、関数やクラスの仕様を文書化します。これに基づきコーディングを進めます。
詳細設計では基本設計の機能モジュールをさらに細分化し、プログラム単位での詳細な仕様を定義します。各モジュール内の関数やクラスの処理手順、インターフェース仕様を決定します。
詳細設計で決めること
詳細設計でのすべきことは以下の通りです。
- 処理手順の詳細化
- データ構造の詳細化
- インターフェース仕様
- データベーステーブルの詳細定義
- プログラム間の接続関係の定義
詳細設計書には、これらの詳細仕様に加え、コーディング時の決まりごとを文書化した設計基準書を含めます。
コーディング作業が仕様に沿って行われるよう、細部までデザインを固めておくことが重要です。詳細設計のポイントは、拡張性や保守性を考慮した設計、コード品質の確保に役立つ設計をすることです。
詳細設計書のポイント
プログラムの詳細な仕様を記述する文書が詳細設計書です。
主に処理ロジックの詳細フロー、画面や帳票の入出力情報を定義します。設計書通りに開発できるよう、できる限り具体的に記載することがポイントです。
漏れやあいまいな部分がないか、レビューを行うことも重要です。
システム開発工程4：コーディング
コーディングは、詳細設計の文書を基に実際にプログラムコードを記述する作業です。設計書通りの処理が実装されるよう、細心の注意を払います。
コーディングでは、詳細設計書に定められた仕様に則り、ソースコードを記述します。
コーディング作業とは
主な作業は以下の通りです。
- モジュールのコーディング
- 動作確認
- テストデータ作成
- ドキュメント作成
- コードレビュー
コーディングのポイント
コーディング時のポイントとして、詳細設計書からの逸脱を最小限に抑えること、コーディング規約を守ることが挙げられます。コード品質が低下すると、テストや保守が困難になるため、設計意図を損なわないコーディングを心がける必要があります。
また、適切なコメントを記述し、他者が理解しやすいようなソースコードを心がけることも大切です。コードレビューにより品質向上を図り、規模の大きなシステム開発ではコーディング時の品質基準を文書化するのが一般的です。
システム開発工程5：単体テスト
単体テストは、個々のプログラムが仕様通りに動作するかを確認するテストです。
例えば作成したクラスや関数ごとに、想定した入力値と出力結果が得られるかを検証します。
単体テスト工程の目的
単体テストは、モジュール・クラスなど、プログラムの最小単位ごとに動作確認を行う工程です。
開発者がコーディングしたプログラムに、意図した通りの機能が組み込まれているかをチェックすることが目的です。
個別の機能が正しく動作することを検証し、後工程で発生するバグを未然に防ぐことができます。
単体テストの手法・内容
単体テストにはモジュールテストやユニットテストなどの様々な手法がありますが、通常、開発者自身が作成したモジュールに対して実施します。テスト内容は以下のようなものがあります。
- 機能テスト
- 境界値テスト
- 異常系テスト
- パフォーマンステスト
主にコーディング時に作成したテストケースに基づき、外部に依存することを排除した上で想定した入力データを用いて動作確認を行います。自動化ツールを使って効率的にテストケースを実行するのが一般的です。
正常系と異常系それぞれの振る舞いをチェックし、すべての条件分岐を網羅することが重要です。
テスト結果は記録して、不具合が見つかった場合は修正を行います。全てのテストケースをパスすることを確認してから、単体テスト完了となります。単体テストによりプログラム品質が向上し、後続のテスト工数も削減することが可能です。
システム開発工程6：結合テスト
結合テストは、個々のプログラム同士が正しく連携動作するかを確認するテストです。呼び出し関係のある複数のモジュールを組み合わせてテストし、データの受け渡しなどで問題がないかを検証します。
結合テスト工程の目的
単体テストで確認したモジュールを組み合わせ、インターフェースでの連携を確認する工程が結合テストです。
個別に確認した機能が、組み合わせた際にも意図した通りに動作することをチェックします。複数のモジュールの組み合わせによる不具合をあらかじめ検証できます。
画面モジュールと業務ロジック、業務ロジックとデータアクセス、GUIとデータベース、といった組み合わせなどでテストを実行します。
結合テストのテスト手法・内容
スタブ（モジュールの代役）を使ったトップダウン、ボトムアップなどの手法があります。
単体テストで使った入力データに加え、モジュール間の受け渡しデータや各種ケースを準備し、システムが正しく動作することを確認します。単体では確認できない、モジュール間の連携の不備をチェックできます。
テスト結果は記録し、不具合が見つかれば修正して再テストを実施します。相互接続されたコンポーネントが正しく動作することが確認できれば、結合テスト完了となります。
結合テストによって、コンポーネント間のインタフェースやデータの受け渡しが仕様通りであるかを確認できます。システムレベルのテストに進む上で、結合テストの品質が重要となります。
システム開発工程7：システムテスト
システムテストは、システム全体の動作を通して要件が満たされているかを確認するテストです。実際の運用を想定して様々なケースをテストし、システム全体としての品質を検証します。
システムテストの作業内容
システムテストでは以下のようなテストを実施します。
- 機能テスト
- インターフェーステスト
- 性能テスト
- 回帰テスト
- セキュリティテスト
- ユーザビリティテスト
システムテスト工程のポイント
統合されたシステム全体での動作確認がシステムテストの目的です。設計書やユーザー要件に沿って、システムが問題なく動作するかを確認します。
そのため、システムテストでは実際の利用環境に近い形で検証します。性能やセキュリティ、障害対応など非機能要件についてもチェックする重要な工程です。
テスト結果は綿密にチェックし、要件未達成やバグがあれば修正作業を行います。全テストケースをクリアし、システム全体の品質が確保された状態になればテスト完了となります。
システム開発工程8：システム移行
開発が完了したシステムを本番環境に移行する工程がシステム移行です。データの移行、環境設定、運用手順書の作成など、実運用に必要な作業を行います。
システム移行の作業内容
システム移行では以下のような作業が含まれます。
- 移行環境の構築
- データ移行
- 移行テスト
- 障害対応訓練
- バックアップ手順の確立
- 運用手順書作成
移行後は、システム監視やテスト運用を行い、安定稼働を確認します。障害があれば原因を究明して対応し、移行作業が完了した段階で本番運用に移行できます。
システム移行工程のポイント
システム移行のポイントは迅速かつ障害のない移行、運用担当者への知識伝達、プロジェクト管理による作業の確実な実施です。
円滑に移行されたシステムこそが、運用フェーズで最大限の機能を発揮することができます。
事前に十分なリハーサルを行い、本番移行時の影響を最小限に抑えることが求められます。
システム開発工程9：保守・運用フェーズ
保守・運用フェーズは、リリース後のシステムを継続的に運用・管理する段階です。バグ修正や機能追加、バージョンアップ、モニタリング、ユーザーへのサポートなどを行います。
保守・運用の作業内容
保守運用では以下のような作業が行われます。
- バグ修正
- 機能追加
- バージョンアップ
- 監視
- 運用
- ヘルプデスク
保守・運用における重要ポイント
保守・運用における重要ポイントは、安定稼働の確保、変化への迅速な対応、生産性の向上を目指しながらも、保守コストとシステムの価値を両立させることです。
保守運用フェーズが長期化するとシステムの老朽化や複雑化が進行するため、定期的な見直しやシステムの入れ替えを検討する必要があります。そうすることで、余計なコストをかけずにシステムの安定運用と価値の維持を図ることができます。
運用に入った後も継続的な保守・改善を行うことで、長期的な価値の提供とコストの最適化を両立させることができるでしょう。
代表的な開発モデル工程
システム開発にはウォーターフォール型とアジャイル型の2つの主な開発手法があります。
ウォーターフォール型は段階を順を追って進める伝統的な手法で、アジャイル型は軽快に要件変更に対応する手法です。それぞれの特徴と適した開発案件が異なるため、メリット・デメリットを理解して使い分けることが重要です。
ウォーターフォール開発
ウォーターフォール開発モデルは、要件定義、設計、実装、テストといった開発プロセスを段階的に進める手法です。各工程が完了してから次の工程に移行するため、計画性が高く文書化しやすいというメリットがあります。一方で、要件変更への対応が難しく、完成までに時間がかかるデメリットもあります。
ウォーターフォール開発では、まず要件を固定化した上で綿密な設計を経て実装に入ります。要件が確定しているため、設計通りの品質の高いソフトウェアを効率よく開発できます。しかし、要件変更が生じた場合、工程全体を見直す必要があり、迅速な対応が難しくなってしまいます。
このようなウォーターフォール開発のメリットを持ちつつ、要件変更にも対応できるようにしたのがSDEM（Systems Development Life Cycle）です。SDEMはウォーターフォール開発をベースとしながらも、各フェーズにフィードバックループを設けることで、柔軟な開発が可能になっています。
つまり、SDEMは「要件を詰めながらの開発」ができるプロセスモデルであり、要件の変更が予測される案件に適したアプローチと言えます。一方で、ウォーターフォール開発は要件が明確な案件により適しています。
アジャイル開発
アジャイルは柔軟性がある方法です。小さなステップで進み、開発者と顧客が継続的にコミュニケーションを取り、要件や目標を簡単に調整できます。変更への対応が得意で、ソフトウェアの一部を優先的に開発します。
例えば、SNSアプリを考えてみましょう。ウォーターフォールでは、最初に全ての機能（プロフィール、投稿、友達機能など）を設計し、実装、テストしなければなりません。
しかし、アジャイルでは最初に基本的な投稿機能から始め、その後プロフィールや友達機能を順次追加できます。ユーザーのフィードバックに基づいて迅速に変更することもできます。
まとめると、ウォーターフォールは段階的で変更が難しく、アジャイルは柔軟で顧客のフィードバックに応じた進化が得意な開発方法です。
システム開発工程における略語集
システム開発では要件定義から設計、コーディング、テストと工程が進むにつれて、多くの専門用語や略語が登場します。ここでは、開発フェーズごとによく使われる略語と簡単な意味をまとめました。システム開発の用語がわからないという方は、ぜひ参考にしてください。
要件定義から設計までの略語
要件定義や基本/詳細設計では、FR、NFR、UI、DFDなどの略語がよく出てきます。
| 開発フェーズ | 略語 | 正式名称 | 意味 |
| 要件定義 | FR | Functional Requisite | 何ができるか |
| NFR | Non Functional Requirement | どのように動作するか | |
| 基本/詳細設計 | UI | User Interface | 画面 |
| DFD | Data Flow Diagram | データの流れ |
開発からテストまでの略語
コーディングやテストフェーズでは、SO、PG、UT、STなどの略語が使われます。FVTは全体のシステムテストのことを指します。
他にも、コーディングではPR、CR、CIなどが利用されます。PRはコードの変更を提案すること、CRは他のエンジニアによるコードチェック、CIは頻繁に自動ビルドとテストを行う手法です。
またテストでは、IV&V、UATなどが重要な略語です。IV&Vは第三者検証、STRは負荷試験、UATはユーザーによるテスト許可を示しています。
| 開発フェーズ | 略語 | 正式名称 | 意味 |
| コーディング＆テスト | SO | Service Order | システム担当者 |
| PG | Programmer | プログラマ | |
| UT | Unit Test | 単体テスト | |
| ST | System Test | システムテスト | |
| コーディング | PR | Pull Request | プルリクエスト |
| CR | Code Review | コードレビュー | |
| CI | Continuous Integration | 継続的インテグレーション | |
| テスト | IV&V | Independent Verification and Validation | 独立検証・検証 |
| UAT | User Acceptance Test | ユーザー受入テスト | |
| STR | Stress Test | 負荷試験 |
その他の一般的な略語
全般的には、SLA、SQA、PMOなどが良く出てきます。SLAはサービス水準、SQAは品質管理、PMOはプロジェクト管理組織の略称です。
その他にも、リスクやコスト関連では、RA、CRAが使われます。RAはリスク評価、CRAはコストとリスクのトレードオフ分析を意味しています。保守・運用フェーズに関しては、SOP、BCP、DR等の略語があります。
| 開発フェーズ | 略語 | 正式名称 | 意味 |
| 全体 | SLA | Service Level Agreement | サービス品質保証 |
| SQA | Software Quality Assuranc | ソフトウェア品質保証 | |
| PMO | Project Management Office | プロジェクト管理オフィス | |
| リスク・コスト管理 | RA | Risk Assessment | リスクアセスメント |
| CRA | Clinical Research Associate | コスト・リスク分析 | |
| 保守・運用 | SOP | Standard Operating Procedures | 標準操作手順書 |
| BCP | Business Continuity Plan | 事業継続計画 | |
| DR | Disaster Recovery | 災害復旧 |
システム開発工程の効率的な進め方
システム開発を効果的に進めるには、いくつかの重要なポイントがあります。そこで、システム開発を効果的に進めるための方法やポイントについて以下に詳しく解説します。
開発モデルの選定
適切な開発モデルを選ぶことは、プロジェクトの成功に大きく影響します。
ウォーターフォール開発は、計画が重要なプロジェクトに適しています。要件がほぼ確定し、変更が少ない場合に有効です。大規模なシステム開発プロジェクト、特に規模の大きい組織では、段階的な進行と明確な文書化がプロジェクトの管理を助けます。
例えば、銀行系システムや法律に基づく規制が厳しいプロジェクトでは、ウォーターフォール開発が適しています。
アジャイル開発は変更が頻繁で、顧客のフィードバックを継続的に取り入れる必要があるプロジェクトに最適です。小規模プロジェクトや中規模プロジェクト、特に新しいアプリケーションの開発に向いています。アジャイル開発は柔軟性を重視し、チームの協力と継続的な改善を通じて製品の品質を向上させます。
プロジェクトの性質や目標に合わせて、ウォーターフォール開発かアジャイル開発かを選定し、成功に向けてスムーズに進めましょう。開発モデルの選択はプロジェクトの成果に大きな影響を与えます。
コミュニケーションの重要性
開発プロジェクトにおいて、コミュニケーションはとても重要です。以下はその重要性と効果的な方法についての解説です。
進捗の共有
プロジェクトメンバー間で進捗を共有し、問題を迅速に把握することが重要です。進捗の共有を怠ると、問題が積み重なりプロジェクトの遅延や品質の低下につながる可能性があります。
課題の議論
チーム内でのオープンかつ率直な課題の議論は、改善の第一歩です。課題を共有しその解決策を協力して見つけることで、プロジェクトの品質と進行に対するリスクを軽減できます。
定期的なミーティング
定期的なミーティングはチームメンバーの意見交換と課題の確認に役立ちます。ミーティングを通じて進捗や優先事項、お互いの役割を明確にしましょう。
コミュニケーションはチームの協力と問題解決に不可欠であり、プロジェクトの成果に大きな影響を与えます。オープンで効果的なコミュニケーションを促進し、プロジェクトの成功に向けてコミュニケーションを積極的に取り入れていきましょう。
仕様変更への対応
プロジェクト中の仕様変更には以下のアプローチが役立ちます。
要件の明確化
仕様変更の際に、新たな要求や変更点を明確に文書化しましょう。どの部分が変更されるのか、その内容は何かを詳細に記録します。これにより変更する領域が明確になります。
影響評価
仕様変更がプロジェクトに及ぼす影響を評価しましょう。変更によってスケジュールや予算、リソースにどのような変化が生じるかを把握します。
優先順位設定
仕様変更が多数ある場合、その重要度に応じて優先順位を設定しましょう。最も重要な変更から順に対応することで、プロジェクトの進行において最も価値のある仕様を最初に実装できます。
スケジュールと予算の調整
仕様変更に伴い、プロジェクトのスケジュールや予算を適切に調整します。変更による遅延を最小限に抑え、プロジェクトの成果を保護しましょう。
仕様変更は避けられないものですが、適切に管理することでプロジェクトの品質を維持し、成功に導くことができるでしょう。
開発コストの抑制方法
開発コストを効果的に抑える方法について、以下のポイントを考慮しましょう。
無駄な作業の削減
プロジェクト内で重複した作業や無駄なタスクを削減しましょう。作業の最適化やプロセスの改善を通じて、リソースと時間を節約できます。
再利用可能なコンポーネント
開発中に作成したコンポーネントやコードを再利用することで、開発時間とコストを削減できます。ライブラリやフレームワークの活用、コードのモジュール化は重要です。
リスクの早期識別と対処
プロジェクト内のリスクを早期に識別し、対処策を検討しましょう。リスクの早期対処は将来のコスト増加を防ぎ、プロジェクトの進行を安定させます。
外部リソースの効果的な利用
必要に応じて外部の専門家やコンサルタントを活用しましょう。外部リソースの導入により、特定の課題に焦点を当て内部のリソースを最適に利用できます。
プロジェクトの計画と監視
開発プロジェクトの計画と進捗監視はコスト管理に不可欠です。予算とスケジュールを定期的に確認し、必要に応じて調整しましょう。
開発コストの抑制はプロジェクトの成功に直結し、企業の収益性に影響を与えます。効率的なリソース利用とリスク管理を組み合わせて開発プロジェクトをコスト効果的に進めましょう。
まとめ：システム開発工程は仕組み作り
システム開発をする上で、プロジェクトの成功に向けた綿密な計画と実行が不可欠です。適切な開発モデルを選択し、コミュニケーションを重視することで、問題の早期解決や要件の明確化が可能です。仕様変更が生じた際には変更の要件を詳細に把握し、スケジュールと予算を調整します。
開発コストの抑制には、無駄な作業の削減やコンポーネントの再利用が役立ちます。外部リソースの効果的な利用とリスク管理も重要です。プロジェクトの計画と監視を通じて、予算とスケジュールを管理し、プロジェクトの成功を確保します。
株式会社Jiteraはシステム開発に関する専門家であり、プロジェクトのニーズに合わせたサポートを提供しています。プロジェクトに関する質問や相談がある場合はお気軽にJiteraへご連絡ください。
