読み込み中...
読み込み中...
読み込み中...
読み込み中...
読み込み中...
ソフトウェア開発は、プログラムを書くだけでは完結しません。コードの編集、バージョン管理、テスト、ビルド、デプロイ（本番環境への配置）など、多くの作業を効率よく進めるための ツール と 環境 が必要です。
たとえば、チームで1つのアプリを開発する場面を想像してください。メンバーが同時にコードを変更したら、誰の変更が最新なのか分からなくなります。テストを毎回手作業で行うと時間がかかり、ミスも起きます。こうした問題を解決するのが、このセクションで学ぶ各種ツールです。
ここでは IDE 、 バージョン管理 、 CI/CD 、 構成管理 、 テスト自動化 、 コンテナ技術 の6つのテーマを順に学びます。
IDE（Integrated Development Environment）は、ソフトウェア開発に必要な複数のツールを 1つの画面に統合 したソフトウェアです。
| 機能 | 説明 |
|---|---|
| コードエディタ | シンタックスハイライト（色分け表示）やコード補完で効率よくコードを書ける |
| コンパイラ/インタプリタ | コードを実行可能な形式に変換する |
| デバッガ | ブレークポイント（一時停止点）を設定してプログラムの動作を1行ずつ確認できる |
| ビルドツール | ソースコードからアプリケーションを自動で組み立てる |
代表的な IDE には Visual Studio 、 Eclipse 、 IntelliJ IDEA 、 Xcode などがあります。
IDE を使わずにテキストエディタとコマンドラインだけで開発することも可能ですが、IDE を使えば コード補完 や リアルタイムのエラー表示 によって生産性が大幅に向上します。
| 機能 | 説明 |
|---|---|
| ブレークポイント | プログラムの実行を指定した行で一時停止させる |
| ステップ実行 | プログラムを1行ずつ実行して変数の値を確認する |
| ウォッチ | 特定の変数の値を継続的に監視する |
| コールスタック表示 | 現在の関数がどこから呼ばれたかの呼び出し履歴を表示する |
バージョン管理システム（VCS: Version Control System）は、ファイルの変更履歴を記録し、過去の状態に戻したり、複数人の変更を統合したりするためのツールです。
| 方式 | 特徴 | 代表例 |
|---|---|---|
| 集中型 | 1台のサーバに全履歴を集中管理。サーバに接続しないと作業できない | Subversion（SVN） |
| 分散型 | 各開発者がローカルに完全な履歴のコピー（リポジトリ）を持つ。オフラインでも作業可能 | Git |
現在のソフトウェア開発では Git が事実上の標準です。
| 用語 | 意味 |
|---|---|
| リポジトリ | ファイルの変更履歴をすべて保管する場所 |
| コミット | 変更内容を履歴として記録する操作 |
| ブランチ | 開発の流れを分岐させる機能。機能ごとにブランチを作って開発し、完成したら統合する |
| マージ | 別のブランチの変更を取り込む操作 |
| プルリクエスト | 変更内容をレビューしてからマージするための仕組み（GitHub の機能） |
| コンフリクト（競合） | 同じ箇所を複数人が変更したときに自動マージできない状態。手動で解決する |
この図のように、 main ブランチから feature-A ブランチを分岐させて機能を開発し、完成したら main にマージするのが一般的なワークフローです。
CI/CD はソフトウェアの品質を保ちながら リリースまでのスピードを上げる ための手法です。
開発者がコードを変更するたびに、自動で ビルド と テスト を実行する仕組みです。問題を早期に発見できるため、バグの修正コストが下がります。
CI を通過したコードを、自動で ステージング環境 （テスト用の本番相当環境）や 本番環境 にデプロイする仕組みです。
代表的な CI/CD ツールには Jenkins 、 GitHub Actions 、 GitLab CI/CD 、 CircleCI などがあります。
構成管理（Configuration Management）は、ソフトウェアを構成する すべての要素 （ソースコード、設計書、テストデータ、環境設定など）の変更を追跡・制御することです。
| 対象 | 具体例 |
|---|---|
| ソースコード | プログラムファイル |
| ドキュメント | 設計書、仕様書、テスト仕様書 |
| ビルド成果物 | 実行ファイル、ライブラリ |
| 環境設定 | サーバ設定、データベース設定 |
| 依存ライブラリ | 外部パッケージとそのバージョン |
バージョン管理システムは構成管理の 一部 です。構成管理はコードだけでなく、設計書やインフラ設定なども含む、より広い概念です。
テスト自動化とは、人手で行っていたテスト作業をツールによって 自動的に実行 することです。手動テストに比べて 繰り返し実行が容易 で、 実行速度が速く 、 結果のばらつきがない という利点があります。
| 種類 | 目的 | 代表的なツール |
|---|---|---|
| 単体テスト（ユニットテスト） | 関数やメソッド単位の動作を検証 | JUnit, pytest |
| 結合テスト | モジュール間の連携を検証 | Postman, REST Assured |
| E2E テスト（エンドツーエンド） | ユーザー操作をシミュレートして全体の動作を検証 | Selenium, Playwright |
| 回帰テスト（リグレッション） | 変更によって既存機能が壊れていないか確認 | CI/CD と連携して自動実行 |
コンテナは、アプリケーションとその実行に必要なライブラリ・設定ファイルを 1つのパッケージ にまとめる技術です。「自分の環境では動くのに、別の環境では動かない」という問題を解決します。
| 比較項目 | コンテナ | 仮想マシン（VM） |
|---|---|---|
| OS | ホスト OS のカーネルを共有 | 各 VM が独自の OS を持つ |
| 起動時間 | 秒単位 | 分単位 |
| リソース消費 | 少ない | 多い（OS 分のオーバーヘッド） |
| 分離レベル | プロセスレベル | ハードウェアレベル |
| 代表ツール | Docker, Podman | VMware, VirtualBox |
| 用語 | 意味 |
|---|---|
| イメージ | コンテナの設計図。アプリ＋ライブラリ＋設定をまとめたテンプレート |
| コンテナ | イメージから作成された実行中のインスタンス |
| Dockerfile | イメージの作り方を記述したファイル |
| レジストリ | イメージを保管・共有する場所（Docker Hub など） |
多数のコンテナを管理・運用するための仕組みです。代表的なツールが Kubernetes （クバネティス、略称 K8s）です。
ポイント
IDE はエディタ・コンパイラ・デバッガを統合した開発環境。バージョン管理は 集中型 （SVN）と 分散型 （Git）があり、Git が現在の標準。 CI はコード変更のたびに自動でビルド・テストを実行する仕組み、 CD はさらに自動デプロイまで行う仕組み。 構成管理 はソースコードだけでなく設計書・環境設定も含む広い概念で、ベースラインと変更管理が重要。テスト自動化は テストピラミッド （単体テスト多・E2E 少）のバランスが理想的。 コンテナ （Docker）は VM より軽量で起動が速く、 Kubernetes で多数のコンテナを自動管理できる。
用語
ソフトウェアを開発・公開する際には、技術的なスキルだけでなく 法律の知識 も必要です。自分が作ったソフトウェアを守る権利、他者のソフトウェアを使う際のルールを知らなければ、意図せず法律に違反してしまう可能性があります。
また、開発チームや組織の プロセスそのものを改善 する取り組みも重要です。良い開発プロセスがあれば、品質の高いソフトウェアを安定して生産できます。
さらに、プロジェクトの開始前に どれくらいの工数やコストがかかるか を見積もる技法も FE 試験で出題されます。
このセクションでは、 知的財産権 （著作権・特許・商標）、 開発プロセス改善 （CMMI・ITIL）、 見積もり技法 （FP 法・COCOMO・類推法）の3つのテーマを学びます。
知的財産権は、人間の知的な創作活動から生まれた成果を保護する権利です。大きく 産業財産権 と 著作権 に分かれます。
| 権利 | 保護対象 | 保護期間 | 登録 |
|---|---|---|---|
| 著作権 | 思想・感情の創作的表現 | 著作者の死後70年 | 不要 （創作と同時に発生） |
| 特許権 | 発明（自然法則を利用した技術的思想の創作のうち高度なもの） | 出願から20年 | 必要 （特許庁に出願） |
| 実用新案権 | 物品の形状・構造・組合せに関する考案 | 出願から10年 | 必要 |
| 意匠権 | 物品のデザイン（形状・模様・色彩） | 出願から25年 | 必要 |
| 商標権 | 商品やサービスを識別するマーク（ロゴ・名称） | 登録から10年（更新可能） | 必要 |
プログラムは著作物 として著作権法で保護されます。ただし、 プログラム言語 、 規約 （プロトコル）、 アルゴリズム そのものは著作権の保護対象外です。
| ポイント | 内容 |
|---|---|
| 職務著作 | 会社の業務として作成したプログラムの著作権は、原則として 会社 に帰属する |
| 委託開発 | 開発を外注した場合、契約で定めがなければ著作権は 開発会社 （受託者）に帰属する |
| 著作者人格権 | 著作者本人に専属する権利で、譲渡・相続ができない。公表権・氏名表示権・同一性保持権がある |
| 著作財産権 | 複製権・翻案権・公衆送信権など。こちらは 譲渡可能 |
| 種類 | 特徴 |
|---|---|
| プロプライエタリ | ソースコード非公開。複製・改変に制限あり（商用ソフトに多い） |
| OSS（オープンソースソフトウェア） | ソースコード公開。複製・改変・再配布が可能（ライセンス条件に従う） |
| コピーレフト型 OSS | 改変した派生物も同じライセンスで公開する義務がある（GPL） |
| 非コピーレフト型 OSS | 派生物のライセンスを自由に選べる（MIT, Apache, BSD） |
| パブリックドメイン | 著作権を放棄。誰でも自由に使える |
ソフトウェアに関する発明 も特許として登録できます（ビジネスモデル特許を含む）。特許を取得するには以下の要件を満たす必要があります。
| 比較項目 | 著作権 | 特許権 |
|---|---|---|
| 保護対象 | プログラムの 表現 （コードそのもの） | プログラムの アイデア・技術 |
| 発生条件 | 創作と同時に自動発生 | 特許庁への出願・審査・登録が必要 |
| 保護期間 | 著作者の死後70年 | 出願から20年 |
| 独自に同じものを作った場合 | 侵害にならない（独立創作の抗弁） | 侵害になる （先に出願した者に権利） |
商品やサービスを他者のものと区別するための 名称 、 ロゴ 、 マーク を保護する権利です。ソフトウェアの 製品名 や サービス名 も商標登録できます。
CMMI（Capability Maturity Model Integration）は、組織の 開発プロセスの成熟度 を5段階で評価するモデルです。もともと米国のカーネギーメロン大学のソフトウェア工学研究所（SEI）が開発しました。
「チームの開発の進め方がどれくらい成熟しているか」を客観的に評価するための物差しと考えてください。
| レベル | 名称 | 特徴 |
|---|---|---|
| レベル1 | 初期 | 場当たり的。成功は個人の能力に依存 |
| レベル2 | 管理された | プロジェクト単位で計画・管理が行われる |
| レベル3 | 定義された | 組織全体で標準プロセスが定義・共有されている |
| レベル4 | 定量的に管理された | プロセスの実績を 定量データ で測定・管理 |
| レベル5 | 最適化している | データに基づいてプロセスを 継続的に改善 |
たとえば、料理に例えると: レベル1は「レシピなしで勘で作る」、レベル3は「レシピが標準化されて誰でも同じ味が出せる」、レベル5は「お客様の反応データを分析してレシピを継続的に改良する」というイメージです。
ITIL（Information Technology Infrastructure Library）は、IT サービスの運用・管理に関する ベストプラクティス （成功事例）をまとめたフレームワークです。開発したソフトウェアを安定して運用するためのガイドラインと考えてください。
| プロセス | 目的 |
|---|---|
| インシデント管理 | サービスの中断や品質低下（インシデント）を できるだけ早く復旧 させる |
| 問題管理 | インシデントの 根本原因 を調査・解決し、再発を防止する |
| 変更管理 | システムへの変更を計画・承認・実施して、変更によるリスクを最小化する |
| リリース管理 | テスト済みのソフトウェアを本番環境に 安全に配置 する |
| サービスレベル管理 | サービスの品質目標を SLA （Service Level Agreement）として定め、達成度を管理する |
インシデント管理と問題管理の違い はよく試験で問われます。インシデント管理は「今起きている障害を素早く直す」 応急処置 、問題管理は「なぜ障害が起きたのか原因を突き止めて再発を防ぐ」 根本治療 です。
| 比較項目 | CMMI | ITIL |
|---|---|---|
| 対象 | ソフトウェア 開発 プロセス | IT サービスの 運用 プロセス |
| 目的 | 開発プロセスの成熟度向上 | IT サービスの品質・安定性向上 |
| 評価方法 | 5段階のレベル評価 | ベストプラクティスの適用度で判断 |
ソフトウェア開発プロジェクトを始める前に、 どれくらいの工数（人月）やコストがかかるか を見積もる必要があります。見積もりの精度がプロジェクトの成否を左右します。
| 技法 | アプローチ | 特徴 |
|---|---|---|
| FP 法（ファンクションポイント法） | ソフトウェアの 機能の量 から見積もる | 言語に依存しない。ユーザー視点の見積もり |
| COCOMO | プログラムの 行数（LOC） から見積もる | 過去のデータに基づく数式で算出 |
| 類推法 | 過去の 類似プロジェクト の実績から見積もる | 経験ベース。類似度が低いと精度が下がる |
| 三点見積もり法 | 楽観値・最可能値・悲観値の 3つの値 から算出 | 期待値 = (楽観値 + 4 × 最可能値 + 悲観値) / 6 |
| デルファイ法 | 複数の専門家 の意見を匿名で収集し合意形成 | 偏りが少ない。複数回繰り返して収束させる |
FP 法は、ソフトウェアが持つ 機能の数と複雑度 から規模を算出する手法です。プログラミング言語に依存しないため、異なる言語で開発するプロジェクト同士を比較できます。
| 分類 | 説明 | 具体例 |
|---|---|---|
| 外部入力（EI） | 外部からデータを受け取って内部に保存 | ユーザー登録フォーム |
| 外部出力（EO） | 内部データを加工して外部に出力 | 帳票出力、集計レポート |
| 外部照会（EQ） | 内部データをそのまま外部に表示（加工なし） | 商品一覧表示 |
| 内部論理ファイル（ILF） | システムが管理するデータの論理的な集まり | 顧客マスタ、商品マスタ |
| 外部インターフェースファイル（EIF） | 他システムから参照するデータ | 外部の郵便番号データ |
あるシステムの機能を分析した結果が以下のとおりだったとします。
| 機能分類 | 低 | 中 | 高 | 重み（低/中/高） |
|---|---|---|---|---|
| 外部入力（EI） | 3 | 2 | 0 | 3 / 4 / 6 |
| 外部出力（EO） | 1 | 1 | 0 | 4 / 5 / 7 |
| 外部照会（EQ） | 2 | 0 | 1 | 3 / 4 / 6 |
| 内部論理ファイル（ILF） | 1 | 1 | 0 | 7 / 10 / 15 |
| 外部インターフェースファイル（EIF） | 1 | 0 | 0 | 5 / 7 / 10 |
未調整 FP の計算:
未調整 FP = 17 + 9 + 12 + 17 + 5 = 60
調整係数を 1.05 とすると:
調整済み FP = 60 × 1.05 = 63
1 FP あたりの開発工数が 0.5 人月とすると:
必要工数 = 63 × 0.5 = 31.5 人月
COCOMO は、プログラムの ソースコード行数（LOC: Lines of Code） からコストと工数を算出するモデルです。
| モード | 対象 | 特徴 |
|---|---|---|
| オーガニック（有機的） | 小規模・経験豊富なチーム | 最も単純な計算式 |
| セミデタッチト（中間的） | 中規模・混成チーム | 中程度の複雑さ |
| エンベデッド（組込み型） | 大規模・制約が厳しい | 最も複雑な計算式 |
FP 法との違い: COCOMO はコード行数という 開発者視点 の指標を使うため、プログラミング言語によってコード行数が大きく異なるという欠点があります。一方、FP 法は機能という ユーザー視点 の指標を使うため、言語に依存しません。
過去に実施した 類似プロジェクトの実績データ をもとに、新しいプロジェクトの工数やコストを見積もる方法です。
1つの作業に対して3つの値を見積もり、期待値を算出します。
期待値 = (O + 4M + P) / 6
例: 楽観値 10日、最可能値 15日、悲観値 30日の場合:
期待値 = (10 + 4 × 15 + 30) / 6 = (10 + 60 + 30) / 6 = 100 / 6 ≒ 16.7日
ポイント
知的財産権は 産業財産権 （特許・実用新案・意匠・商標、出願が必要）と 著作権 （創作と同時に発生）に大別される。プログラムは著作権で保護されるが、アルゴリズム自体は保護対象外。職務著作は会社に帰属、委託開発は契約がなければ受託者に帰属。 CMMI は開発プロセスの成熟度を5段階で評価するモデル。 ITIL は IT サービス運用のベストプラクティスで、インシデント管理（応急処置）と問題管理（根本治療）の違いが重要。見積もり技法は FP 法 （機能の数と複雑度から算出、言語非依存）、 COCOMO （コード行数から算出）、 類推法 （過去の類似プロジェクトから推定）を区別する。FP 法は5つの機能分類（EI・EO・EQ・ILF・EIF）に重みを掛けて未調整 FP を求め、調整係数を掛けて調整済み FP を算出する。
用語