【これでOK】Webアプリケーション開発プロセスの基礎―要件定義・設計・実装・テスト・運用
はじめに
この章では、Webアプリ開発を実装だけの作業ではなく、一連のプロセスとして捉えます。
MDN は学習導線の中で、ワークフロー、テスト、デプロイ、ツールをそれぞれ独立したテーマとして扱っており、開発はコードを書く段階だけで完結しないことを示しています。
また、OWASP は安全な開発を、Requirements、Design、Implementation、Verification、Operation などのフェーズを通じて考えるべきだとしています。
つまり、何を作るかを決める段階から、公開後に安定運用する段階までを含めて、開発だと考える必要があります。
この章では、特定のフレームワークやクラウド名には依存せず、どの環境でも通用する形で、要件定義、設計、実装、テスト、公開、運用、改善の流れを整理します。
この章で学ぶこと
- 開発プロセス全体の流れ
- 要件定義、設計、実装、テスト、公開、運用の役割
- 各工程で何を決めるのか
- 手戻りが起きる理由と減らし方
- ツールが変わっても共通する本質
1. なぜ開発プロセスを全体で理解する必要があるのか
Webアプリ開発で最も起こりやすい誤解の一つは、実装が開発の中心であり、他は補助だと考えてしまうことです。しかし、実装は全体の中の一工程です。目的が曖昧なまま書いたコードは、後から設計変更や手戻りを生みやすくなります。MDN のワークフロー記事でも、テストやツールを含む全体の作業手順を意識することが重要だとされており、新しいコード追加で既存機能を壊さないためのテストも含めて考えるべきだと説明されています。
さらに、公開後の運用を考えない開発は、実際のサービスとしては不十分です。MDN のデプロイ記事は、ホスティング環境の選択、プロジェクト設定の調整、本番環境への配置を扱っており、ローカルで動くことと、利用者が使えることは別だと示しています。
flowchart LR
A[要件定義] --> B[設計]
B --> C[実装]
C --> D[テスト]
D --> E[公開]
E --> F[運用]
F --> G[改善]
G --> A
1-1. いきなり実装から入ると何が起こるか
いきなり実装から入ると、次のような問題が起きやすくなります。
- 目的が曖昧なまま機能を増やす
- 必要な画面やデータ構造が後から崩れる
- セキュリティや運用が後付けになる
- 公開直前に大きな修正が必要になる
1-2. 開発プロセスとは何か
開発プロセスとは、単なる作業順ではなく、問題を定義し、解決策を形にし、使われ続ける状態まで持っていく流れです。OWASP の Developer Guide でも、Requirements、Design、Implementation、Verification に加えて、Operation を含めた流れで考える重要性が示されています。
1-3. なぜツールより先に流れを理解するべきか
ツールやフレームワークは変わりますが、要件定義、設計、実装、テスト、公開、運用という流れは大きく変わりません。手段が変わっても、工程の本質は残るからです。MDN の client-side tooling overview も、ツールはライフサイクルの中で使い分けるものとして説明しています。
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| ツール名だけ覚える | 本質が見えない | 工程で理解する |
| 実装だけに注目する | 全体像を見失う | 開発の流れ全体で捉える |
| 環境が変わると理解が崩れる | 応用が利かない | 共通構造で学ぶ |
2. 要件定義
要件定義は、誰の、どんな課題を、どの範囲まで解決するかを定める工程です。ここで曖昧さが残ると、後続工程がすべて不安定になります。OWASP の requirements in practice でも、要件はセキュリティ要件を含めて開発の出発点になると説明されています。
2-1. 要件定義とは何か
要件定義は、「何を作るか」を決める工程です。ただし、単に機能一覧を並べるだけでは不十分です。利用者、利用場面、制約、成功条件まで含めて整理する必要があります。
2-2. 何を整理するのか
代表的な整理対象は次の通りです。
- 利用者は誰か
- どんな課題を持っているか
- どんな場面で使うか
- 最低限必要な機能は何か
- 制約条件は何か
- 成功をどう判断するか
2-3. 要件と希望の違い
「あると便利」と「なければ成立しない」は違います。要件定義では、希望を全部入れるのではなく、本当に必要なものを選び、優先順位をつける必要があります。
2-4. なぜ要件定義が重要なのか
要件定義があると、設計や実装の判断軸ができます。逆に、ここが曖昧だと、後から「そもそも何のために作ったのか」が揺らぎます。
この節の課題と解決
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| 課題を定義せずに作り始める | 目的がぶれる | 要件を先に言語化する |
| 希望を全部入れようとする | 複雑化する | 優先順位をつける |
| 成功条件がない | 良し悪しを判断できない | 評価基準を先に決める |
3. 設計
設計は、要件を実装できる形へ変換する工程です。ここでは、画面、データ、処理、権限、外部連携、運用条件などを整理します。OWASP Secure by Design Framework も、セキュリティをコードの後付けではなく、設計段階から組み込むべきだとしています。
3-1. 設計とは何か
設計では、「何を、どこで、どう扱うか」を決めます。要件をそのままコードへ落とすのではなく、構造へ変換する段階です。
3-2. 設計で分けて考える対象
- 画面
- データ
- 処理
- 権限
- 外部連携
- 運用条件
3-3. 設計で決めること
- 何を入力するか
- 何を保存するか
- どこで判断するか
- どこまで自動化するか
- どこに責任を置くか
3-4. なぜ設計が必要なのか
設計があると、実装時の迷いが減り、構造を共有しやすくなります。また、後から変更しやすい形を作れます。
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| 要件をそのままコードにする | 構造が崩れる | 設計に変換する |
| 画面、処理、保存を整理しない | 連携が破綻する | 設計対象ごとに分ける |
| 権限や運用を後回しにする | 公開後に問題が出る | 設計段階で扱う |
4. 実装
実装は、設計を実際に動く形へ落とし込む工程です。ここでは、画面、入力処理、データ保存、通信処理、認証、設定などを具体化します。MDN も、テストやデプロイの記事の前提として、実装済みのプロジェクトを扱っています。
4-1. 実装とは何か
実装は、設計図をもとにコードや設定を書いて、動く状態にする工程です。ただし、ただ動けばよいわけではありません。
4-2. 実装で扱う代表的な対象
- 画面
- 入力処理
- データ保存
- 通信処理
- 認証
- 設定
4-3. 実装で大切な視点
- 責務分離
- 再利用性
- 可読性
- 変更しやすさ
4-4. なぜ実装を役割で見るべきか
役割で実装を捉えると、どの技術を使っても本質が変わりません。環境が変わっても、画面、処理、保存という見方は残ります。
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| その場しのぎで作る | 後で直しにくい | 責務分離を意識する |
| 設計を無視する | 一貫性が崩れる | 設計を基準に実装する |
| ツール依存で覚える | 環境が変わると通用しない | 役割ベースで理解する |
5. テストと検証
テストは、正しく動くか、壊れていないかを確かめる工程です。MDN の workflows and processes では、JavaScript プロジェクトには新しいコード追加で既存機能を壊さないためのテストを含めるべきだと説明されています。MDN の testing モジュールも、一般的なテストや互換性確認へ拡張中です。
5-1. テストとは何か
テストは、実装した内容が仕様通りかを確認する工程です。さらに、変更で既存機能が壊れていないかを見る役割もあります。
5-2. 何を確認するのか
- 仕様通りに動くか
- 異常時に破綻しないか
- 入力に耐えられるか
- 権限が守られているか
- 表示や操作に問題がないか
5-3. なぜテストが必要なのか
実装しただけでは品質は保証されません。公開前に確かめることで、公開後の障害を減らせます。
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| 確認せずに公開する | 不具合に気づけない | テスト工程を設ける |
| 正常系しか見ない | 異常時に壊れる | 異常系も確認する |
| 動けばよいと考える | 品質が不安定になる | 期待動作を検証する |
6. 公開と運用
公開とは、利用者が使える状態にすることです。運用とは、その状態を維持し、問題に対応し続けることです。MDN のデプロイ記事は、ホスティング環境の選択、プロジェクト設定の調整、本番向け配置を扱っています。これは、ローカルで動くことと、実際に使われることが別であることを示しています。
6-1. 公開とは何か
公開は、開発中のアプリを利用可能な環境へ配置することです。デプロイとも言います。
6-2. 運用とは何か
運用は、公開後も安定して使える状態を保つことです。
6-3. 運用で行うこと
- 監視
- 障害対応
- ログ確認
- 更新対応
- バックアップ
- 権限管理
6-4. なぜ公開後も開発が続くのか
使われて初めて問題が見つかることが多いからです。また、依存関係や外部環境は変化し続けます。
この節の課題と解決
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| リリースで終わりだと思う | 継続利用に耐えない | 運用まで含めて考える |
| 問題発見の仕組みがない | 障害対応が遅れる | 監視とログ確認を行う |
| 更新を止める | セキュリティや互換性が崩れる | 保守を継続する |
7. 改善サイクル
改善とは、使われ方を見て、より良くすることです。最初の設計だけで全ては決まりません。
利用状況、フィードバック、エラー、運用上の負担をもとに、問題発見、原因分析、優先順位付け、修正、再評価を繰り返します。Google の SRE Workbook も、運用の中で信頼性と改善を継続的に扱う考え方を示しています。
7-1. 改善とは何か
改善は、公開後に見えてきた課題を解決し、価値を高める活動です。
7-2. 改善の材料
- 利用状況
- エラー
- 問い合わせ
- フィードバック
- 運用上の負担
7-3. 改善の進め方
- 問題発見
- 原因分析
- 優先順位付け
- 修正
- 再評価
7-4. なぜ改善が必要なのか
実際の利用でしか見えない問題があるからです。作って終わりでは、価値は伸びません。
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| 作って終わりにする | 価値が伸びない | 改善を前提にする |
| 感覚で直す | 本質的な問題が残る | 利用情報を使う |
| 優先順位をつけない | 効果の薄い修正が増える | 改善観点を整理する |
8. セキュリティを各工程へどう組み込むか
OWASP は、セキュリティを後付けではなく、Requirements、Design、Implementation、Verification、Operation の各工程へ組み込むべきだとしています。Secure by Design Framework も、設計段階から安全性を埋め込む考え方を示しています。
8-1. なぜ後付けでは遅いのか
セキュリティを最後に考えると、手戻りが大きくなります。設計そのものを変えないと対応できない問題もあるからです。
8-2. 要件段階で考えること
- 守るべき情報
- 想定する脅威
- コンプライアンス
8-3. 設計段階で考えること
- 認証
- 認可
- データ保護
- 信頼境界
8-4. 実装・検証・運用段階で考えること
- 入力検証
- 依存関係更新
- セキュリティテスト
- 監視と対応
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| セキュリティを最後に考える | 手戻りが大きい | 各工程へ組み込む |
| 守る対象を定義しない | 防御が曖昧になる | 要件段階で明確化する |
| 運用後の監視をしない | 問題発見が遅れる | 運用に含める |
9. 到達目標
この章を終えた時点で、次の内容を説明できるようになることを目指します。
-
要件定義から運用までの流れ
-
各工程の役割
-
実装前に何を決めるべきか
-
公開後に何を続けるべきか また、次の区別ができることも重要です。
-
要件定義と設計
-
実装とテスト
-
デプロイと運用
-
保守と改善
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| ゴールが曖昧 | 何を理解したらよいかわからない | 到達目標を明示する |
| 各工程を混同する | 学習が曖昧になる | 区別の観点を示す |
| 次章との関係が見えない | 知識が分断される | 接続先を示す |
10. 考えてみよう
- なぜ実装だけでは開発を理解したことにならないのでしょうか。
- なぜ要件定義を先に行う必要があるのでしょうか。
- なぜテストと運用を開発の外に置いてはいけないのでしょうか。
- なぜ改善まで含めてプロセスとして捉える必要があるのでしょうか。
- なぜセキュリティを各工程で考えるべきなのでしょうか。
11. まとめ
- 開発プロセスは、要件定義、設計、実装、テスト、公開、運用、改善を含む一連の流れとして捉えるべきです。
- ツールやフレームワークは変わっても、この流れ自体は大きく変わりません。
- 実装だけに注目すると、目的、品質、公開後の継続改善が見えにくくなります。
- テストは、新しいコード追加で既存機能を壊していないかを確認する重要な工程です。
- デプロイは、ホスティング環境の選定や本番向け設定を含む、開発の一部として扱うべき工程です。
- 運用と改善は、リリース後に価値を維持・向上させるために不可欠であり、開発プロセスの外側ではありません。
- セキュリティは、要件、設計、実装、検証、運用の各工程へ組み込むほうが効果的です。
12. 参考文献
- Learn web development - MDN
- Workflows and processes - MDN
- Client-side tooling overview - MDN
- Deploying our app - MDN
- Testing - MDN
- Strategies for carrying out testing - MDN
- Introduction to automated testing - MDN
- Secure development and integration - OWASP Developer Guide
- Requirements in practice - OWASP Developer Guide
- OWASP Secure by Design Framework
- OWASP Developer Guide
- Google SRE Workbook Index