ソフトウェア開発環境が含む範囲
本記事は、製品としてソフトウェアを作る場合で、複数の開発者が共同して作業する、企業でのビジネスを想定しています。プログラミング言語は、コンパイラ型でオブジェクト指向プログラミング機能を想定しています。
逆に、サービスの提供が目的でソフトウェア自体が製品ではない場合、開発規模が小さい（ごく少人数の開発で阿吽の呼吸が通じる）場合、既にある製品やサービスを活用し、ちょっとしたアドオンやカスタマイズで実現する場合、などは本記事の想定外となります。
開発環境と一言でいうとどこまでを含むのか
ソフトウェアの開発環境を整備しようとしたら、何を含めるのかについて同じ職場でもコンセンサスがなかなか得られていません。そんなときは両極端な思考をしてみて検討の幅を持たせて適切なところを探ります。
最小限の開発環境
まず、片方の極端な思考として、もっとも少ない開発環境を考えます。ミニマムではソースコードを実行体にコンパイル（ビルド）するのに必要なコンパイラがあればいいでしょう。作業効率も問わなけらば、ソースコードの記述は何でもよくて（メモ帳でもWordPadでも）、ソースファイルは日時のフォルダに整理して保存し、ソースファイルをコンパイルして実行体を生成します。
最大限の開発環境
続いて、もう片方の極端な思考として、もっとも多い開発環境を考えます。
プログラミング作業が用意になるよう統合開発環境（IDE：Integrated Develop Environment）を用意します。開発者がそれぞれバラバラなソースコードを記述しないようコーディング規約を策定し、IDEに可能な限り規約に合わせた設定を行い、それを全員に配布し適用します。プロジェクトで定めたファイル先頭コメント（ライセンス記述やプロジェクト記述等）やコメントの雛形等をファイル新規作成時に自動で展開できるようにIDEに設定しておきます。設定を展開するのに必要であればIDEのプラグインを作って全員に配布します。
ソースコードは構成管理ツールの下に集約し、ソースコードの作成、修正、履歴管理、リリース管理の方法を構成管理規約を策定し全員に配布します。要件（仕様）からのトレーサビリティを確保するため、要件から展開したタスクをタスク管理システムに登録し、タスク番号をブランチ名としてソースコードをコミットし管理するなども構成管理規約に含めます。
ソースコードの品質を評価する作業も開発の一部として開発環境に組み込みます。品質の代表的な評価手段としてレビュー（インスペクション）とテストがあります。レビューはプロセスやライブラリの外部インタフェース（プロセス間通信、ファイル等のリソースアクセス、APIなど）、プログラムの構造（パッケージ／クラス構造、ライブラリ構成）、ドキュメントコメントから生成する設計情報、各段階のテスト仕様、ソースコードを対象とするので、レビューの実施体制、レビュー基準、レビュー記録などの手順、計画、管理方法などを策定します。
ソースコードに対して静的解析ツールを適用して、予め定義した検査ルールに逸脱する箇所を検出します。検査ルールは、命名規約からネストの深さ、パッケージやクラスの構成（クラス数、メソッド数、ファンイン／ファンアウト数、他）、循環複雑度、凝集性、APIの呼び出し方法、バグパターンなどを定義しておきます。組み込み方も、ある程度開発が進んでから一括して検証するだけでなく、開発者がコードを書いている最中に検証をしておくのが望ましいので、IDEへ組み込めるようにします。
ユニットテストツールを適用して、小さいモジュール単位（クラス／メソッド等）で機能の確認をします。その際、カバレッジツールや動的解析ツールを併用してテストの検証範囲や計算機リソース（CPU、メモリ、ディスク、ネットワーク等）の使用状況を評価します。ユニットテストで不可欠なモックの作成をツールを使って効率化するならモックツールも適用します。
開発されたソースコードをまとめてビルドしテスト環境や納品用のリリース媒体を作るビルド・リリース環境も用意します。ビルドしたソースコードのレビジョンとリリースバージョンの対応付け、バグ管理ツールとの対応（そのリリースで修正されたバグ、既知のバグなど）などを行って、リリースノートへの記載などができるようにします。このビルド環境にも静的解析ツールを組み込んでの評価、ドキュメントコメントからのドキュメント生成などができるようにしておきます。
テストや運用中に発生したバグを管理し、バグの修正コードを記述するために、バグ管理ツールを導入し、バグ管理規約を作成します。バグ管理ツールは構成管理ツールとの紐づけが最低限必要です。
- IDEとその設定（プラグイン含む）
- コーディング規約
- 構成管理ツール
- 構成管理規約
- 要件管理ツール（またはタスク管理ツール）
- レビュー管理ツール
- レビュー規約
- 静的解析ツール
- ユニットテストツール
- カバレッジツール
- 動的解析ツール
- テスト規約（ユニットテスト）
- ビルドツール（自動ビルド）
- リリースツール（必要ならインストール媒体作成を含む）
- ドキュメント生成ツール
- バグ管理ツール
- バグ管理規約
ソフトウェア開発環境が対象とするもの
ソフトウェア開発環境が対象とするものをソースコードとするのか、製品の媒体（バイナリ、インストーラー等）とするのかもブレがありそうです。
ソースコードまでを範囲とする場合、各開発者が自分の環境でソースコードの作成をすることが主作業で、作業の必要上コンパイルする、ユニットレベルのテストをする、デバッグをする、といった範囲が開発環境となります。ソースコードをテスト環境や運用環境に展開する、あるいはインストール用媒体を生成する、などはおざなりに付く程度です。
実行体までを範囲とする場合は、テスト環境や運用環境に展開する、あるいはインストール用媒体を生成するまでが開発環境となります。
品質活動をどこまで開発環境に取り込むかによって、対象が増減します。
規約とツール
IDEにEclipseを使います。ソースコード管理にGitLabを使います。テストはJUnitを使います。ビルドにはJenkinsを使います。バグ管理にはJIRAを使います。とツールだけを決めても開発現場は混乱します。ファイルの改行コード、エンコーディングがバラバラ、ビルドツールはIDE固有の人、Ant使う人、maven使う人などでビルド困難、命名規約がバラバラ、パッケージ単位もバラバラ（やたら細かい人、数十クラスを1つのパッケージにする人）、コメント記述バラバラ、ユニットテストの書き方、メンテナンスがバラバラ、などなど。
しまらないまとめ
ソフトウェア開発環境はピンキリですが、品質保証活動を取り入れた製品の開発を行う場合は、言わば開発対象のビジネス業務を丸ごと一つ業務設計するような決め事が必要になります。これを、ソフトウェアをエンジニアリングすることと言いたいのですが、伝わらないですねぇ。
でも、それをしなないとカオスの渦に飲み込まれてしまいます。
