開発の基礎

開発とは何か

ソフトウェア開発とは、コンピュータに「何をしてほしいか」を指示するプログラムを作る作業のことです。

Webサイト、スマホアプリ、社内の業務システムなど、普段使っているデジタルなサービスはすべて、誰かが「開発」して作ったものです。

開発の大まかな流れ

1. 企画・設計 — 何を作るか決める
2. 実装（コーディング） — プログラムを書く
3. テスト — 正しく動くか確認する
4. デプロイ（公開） — 利用者が使える状態にする
5. 運用・改善 — 不具合を直し、機能を追加する

企画・設計フェーズの中身（特に大切）

開発の最初にある「企画・設計」は、後の工程すべての土台になります。ここで決めたことを後から大きく変えるのは、家を建ててから間取りを変えるくらい大変なので、時間をかける価値があります。

このフェーズでは、性質の違う3つの文書を順番に作っていきます。

1. 要件定義

「何のために」「誰のために」「何ができれば嬉しいか」を言語化する文書です。

• 機能の一覧
• 対象ユーザー（誰が使うのか）
• 使われる場面（どんな時に使うのか）
• 想定外の状況（エラー時はどうするか）
• 優先順位（必須機能と「あると嬉しい」機能の区別）

要件定義はもっとも重要な工程です。ここで決めたことが仕様、設計、実装、テスト、運用すべてを縛ります。逆に言えば、ここで全てが決まると言っても過言ではありません。要件定義が曖昧なまま実装に進むと、後から手戻りが大量に発生し、時間もコストも倍以上に膨らむことが珍しくありません。

2. 仕様書

要件定義を「具体的に何を作るか」に落とし込む文書です。

• 画面の構成（どんなボタンがあって、どんな入力欄があるか）
• 操作の流れ（ユーザーが何をすると、画面がどう変わるか）
• 入出力データの形（どんな情報を受け取り、何を返すか）
• エラー時の挙動（入力ミスがあった時にどう知らせるか）

「ボタンを押したら何が起きるか」「データはどこに保存されるか」のレベルまで具体化します。

3. 設計書

仕様書を「どう作るか」（技術的な実現方法）に落とし込む文書です。

• データベースの構造
• システム全体の構成
• 外部サービス（決済、地図、認証など）との連携方法
• セキュリティ・性能・コストの考慮事項

3つの文書の違い

文書	主な視点	答える質問
要件定義	ユーザー・業務	「何のために、何を実現したいか」
仕様書	プロダクト	「ユーザーから見て何ができるか」
設計書	技術	「内部でどう実現するか」

順番は 要件定義 → 仕様書 → 設計書。後ろの文書は前の文書に従い、前の文書なしには書けません。

よく聞く開発用語

フロントエンドとバックエンド

• フロントエンド: ユーザーが直接見て触れる画面の部分（ボタン、入力欄、デザインなど）
• バックエンド: 裏側でデータを処理・保存する部分（データベース、計算ロジックなど）

レストランで例えると、フロントエンドは「接客係」、バックエンドは「厨房」です。

データベース

データベースは、情報を整理して保存する仕組みです。会員情報、商品データ、注文履歴など、アプリが覚えておく必要があるデータはすべてデータベースに入っています。

API

APIは、ソフトウェア同士がデータをやりとりするための窓口です。天気予報アプリが気象データを取ってくるのも、APIを通じて行われています。

開発チームの役割

役割	やること
エンジニア	プログラムを書く
デザイナー	画面の見た目や使いやすさを設計する
PM（プロジェクトマネージャー）	スケジュールや方針を管理する
QA（品質管理）	テストして不具合を見つける

初心者へのアドバイス

開発に関わるすべての人がコードを書く必要はありません。大切なのは「何を作りたいか」「なぜ作るのか」を明確に伝えることです。技術的な言葉が分からなくても、目的が明確であれば開発チームは適切な方法を見つけてくれます。