はじめに
エンジニアとして働いていると、どうしても「目の前の作業」に集中しがちです。
しかし、自分の仕事が開発全体のどこに位置しているのかを理解しておくことはとても重要です。
全体像を知ることで、自分が今どの段階にいて、次にどのような役割を担っていくのかが見えてきます。
システム開発は、大きくいくつかの工程に分かれています。
シンプルに見えますが、実際にはそれぞれの段階で考えることが多く、慣れていないと境界が曖昧に感じるかもしれません。
1. 要件定義
要件定義とは、ユーザーやビジネスが「何を実現したいか」を言葉に落とし込む工程です。
ここでは抽象的な願望を 具体的な利用シーンや機能の形 に変えていきます。
- 例：「メモを保存できるアプリがほしい」
- さらに深堀りすると：「検索やタグ付けもできるようにしたい」
- 最終的には「誰が」「何を」「どのように使うか」を明確にすることがゴールです。
重要なのは、ユーザーの言葉をそのまま実現することが目的ではないという点です。
ユーザーが「検索機能がほしい」と言っていても、真の課題は「必要な情報にすぐアクセスできること」かもしれません。
つまり、表面的な願望を鵜呑みにせず、背後にある課題や目的を見極め、本当に解決すべき要件に言い換えることが求められます。
この工程を誤ると、ユーザーの真のニーズから外れた機能を作ってしまい、システム全体が無駄に複雑になったり、使われない機能ばかりが増えてしまいます。
2. 設計
要件で定めたことを、システムとしてどう形にするかを決めるのが設計です。
ここで最も重要なのは 責任分担の明確化 です。つまり、どの層・どのモジュール・どのテーブルがどの役割を担うのかを整理し、境界をはっきりさせることです。
- UI：ユーザー入力を受け取り、結果を画面に表示するだけに専念する
- ドメイン：ビジネスロジックや業務ルールを扱い、アプリの本質的な処理を担う
- DB：データの永続化に徹し、アプリ固有の判断は持ち込まない
責任分担が曖昧だと、UIにロジックが入り込み、DBに業務ルールが散らばり、コード全体が複雑に絡み合っていきます。結果として、修正や機能追加のたびに影響範囲が広がり、開発スピードも品質も落ちてしまいます。
逆に、役割を明確に区切っておけば「どこにコードを書くべきか」が自然に見えてきます。これにより実装がスムーズになり、テストも行いやすくなり、将来の拡張やリファクタリングにも強いシステムになります。
3. 実装
設計で定めた責任分担に沿って、実際にコードを書いて機能を作り上げる工程です。
小さな単位で動作確認を繰り返しながら少しずつ組み立てていきます。
ここではスピードよりも「設計通りに役割を守れているか」が大切で、同時にテストを意識することで、後の検証や保守が格段にしやすくなります。
4. テスト
実装したものが要件どおりに動作しているかを検証します。
- 単体テスト：関数やクラス単位で動作を確認
- 結合テスト：モジュール間の連携を確認
- E2Eテスト：ユーザー視点でアプリ全体を確認
テストが甘いと後で修正コストが跳ね上がるため、現場ではとても重視されます。
5. 運用・保守
リリース後、システムを実際にユーザーに使ってもらう段階です。
このフェーズでは日々の安定稼働を支えるだけでなく、改善が発生します。
主な作業例は以下のとおりです。
- バグ修正
- 軽微な改善やリファクタリング
- ログ監視やセキュリティ対応
- パフォーマンスチューニング
システム開発の5つのパターン
家に例えると…
- 新築＝ゼロから作る
- 増築＝大きな機能追加
- 改修＝小〜中規模の改善
- 整備＝内部構造の整理
- 廃止＝不要部分の削除
システム開発はすべて「新築」ではありません。
むしろ多くの場合は既存のシステムをどう増やすか、直すか、整えるか、あるいは不要な部分を取り除くか、という作業になります。
家にたとえるとイメージがつきやすいでしょう。
🏠 新築：ゼロから新しいシステムを作る
まっさらな土地に新しい家を建てるように、システムをゼロから構築すること。
（要件定義 → 設計 → 実装 → テスト → 運用）を一通り体験できるが、現場では頻度は少なめ。
- 要件定義：どんな家が欲しいかを決める（マンション？一戸建て？部屋数？）
- 設計：間取りや構造を決める（リビングの広さ、キッチンの位置）
- 実装：大工さんが家を建てる
- テスト：雨漏りしないか、ドアが閉まるかチェック
- 運用・保守：実際に住んで、故障や修繕に対応
🧩 増築：既存システムに大きな機能を追加する
家に新しい部屋を増やすように、既存システムに大きな機能を追加すること。
基盤を壊さずにどうつなげるかが重要。
- 要件定義：なぜ増やすのかを決める（子ども部屋？書斎？）
- 設計：既存の構造にどうつなげるか考える（配管や柱の位置）
- 実装：新しい部屋を追加工事
- テスト：既存の部屋が使いづらくなっていないか確認
- 運用・保守：増築部分と既存部分を合わせて使い続ける
🔧 改修：小〜中規模の改善やバグ修正
壁紙を替えたり、蛇口を修理するように、部分的な改善やバグ修正を行うこと。
最も頻度が高く、日常的に発生する。
- 要件定義：何が不便かを確認（ドアが開きづらい、キッチンが暗い）
- 設計：修繕の方法を決める（ドアを調整？照明を追加？）
- 実装：実際に直す、改善する
- テスト：修理後に正常に動くか確認
- 運用・保守：使いやすさを維持
🧹 整備：内部構造を整理して住み心地を良くする
配線や断熱材を入れ直すように、内部の見えない部分を整えること。
コードの可読性や保守性を上げ、長く快適に使えるようにする。
- 要件定義：住んでいて気づいた不便を洗い出す（冬寒い、光熱費が高い）
- 設計：改善プランを立てる（断熱強化、電気系統整理）
- 実装：見えない部分を手直し
- テスト：快適さや安全性を確認
- 運用・保守：維持コストを抑え、長く住めるようにする
🗑️ 廃止：不要になった機能を取り壊す
使わなくなった物置を壊すように、不要な機能を取り除くこと。
維持コストを減らし、システムをシンプルに保つ。
- 要件定義：なぜ不要なのかを明確にする（誰も使わない、維持費がかかる）
- 設計：壊す範囲と影響を確認（配管や電気に影響がないか）
- 実装：実際に取り壊す
- テスト：壊した後も生活に支障がないか確認
- 運用・保守：空いたスペースを新たに活用
コメント