開発環境の構築とソフトウェアエンジニア考 - torutkの日記の続編です。
前回書いたことと内容は重なりますが、まずソフトウェア開発環境に予算を付ける（投資をする）組織、予算を付けない組織の違いを考察してみます。そして、予算を付けない組織において、現実的に対処する方法としてのオープンソースツールを組み合わせたソフトウェア開発環境の構築を具体化します。
ソフトウェア開発チームの運用
組織的なソフトウェア開発をするのであれば、プロジェクト毎に集散離合するチームではなく、いったん形成されたチームを継続して使用することが品質／生産性／組織能力の維持向上に望ましいです。
しかし、数値化しにくいこれらの要素に対し、数値化しやすい人件費でしか評価できない組織は、仕事がないときは人件費ゼロ、仕事があるとその量に応じた人件費という集散離合するチームでの開発しか選択しないのでしょう、きっと・・・。
組織論の観点でこの違いがどこかで語られていると思いますので、ここではこれ以上踏み込みませんが、次の主題であるソフトウェア開発環境への投資に対する態度の違いはこの組織運用の違いにあると思っています。
ソフトウェア開発環境への投資が戦略的かそれとも必要悪か
まず、ソフトウェア開発環境構築に要する費用が、自身が属する組織においてどのように捉えられているかを判断（推測）します。
ソフトウェア開発環境構築への投資が、品質／生産性／組織能力の向上を支える戦略投資として理解されている組織であれば、品質／生産性／組織能力を向上するシナリオに沿って開発環境構築を提案して、人件費、購入費を獲得するよう働きかけます。
しかし、個別のシステム開発プロジェクトにおいてソフトウェア開発にどうしても必要だから（仕方なく、ないと作れないから、）人件費／購入費を出すという捉え方をしている組織であれば、たとえ品質／生産性／組織能力を向上するからと提案しても、それが今のプロジェクトでどうコスト削減になるのか具体的な数値で示さない限り、投資を受け入れてもらうことが困難です。プログラマーの生産性が1割向上する、みたいな定性的な話では通じないことが大半です。
直接プロジェクトのコストに影響する投資、たとえば、帳票ライブラリを購入すれば、帳票機能開発の○○人月が削減できます、といった直接機能を実現するソフトウェアの導入は了承されやすいのに対し、自動ビルドツール、構成管理ツールなどの間接支援ツールは、それを導入することによってプロジェクトのコストに直接影響が見えずらいため、了承されがたい点があります。自動ビルドツールも、「担当者がビルドすればいいだろう、ビルド開始してから終わるまで張り付いている必要ないんだから、そんなに工数がかかるわけがないだろう」といった反応を示すこともあります。
このようなプロジェクト本位制な組織では、開発環境の構築予算もプロジェクト毎に捻出するので、いくら効率がといってもプロジェクト採算上は支出（赤字要因）なので、極力抑えるという動きになってしまうのかもしれません。
開発環境への投資が必要悪とされる組織で開発環境を構築するとしたら
ともあれ、そうした言わばプロジェクト本位制のソフトウェア開発組織に身を置いている以上、文句をいってるだけではエンジニアとしての品性が低下してしまうので、その状況に合わせてエンジニアの価値を発揮するべく考えていきましょう。
前回述べたオープンソースツールを組み合わせた開発環境を構築するのが一つの現実的な解です。
ソフトウェア開発環境基盤の一構想
数人〜数十人の開発者が集まるプロジェクトにおいてソフトウェア開発環境基盤を構築することを考えて見ます。
構成管理視点での開発環境基盤
まず、構成管理視点でソフトウェア開発の業務を考えます。各開発者は自分の作業用PCで設計情報、ソースコードなどを作成します。この設計情報、ソースコードは開発者同士で共有するもので、また開発が進むにつれ追加・変更が発生します。変更については、いつだれが何を変更したかを追跡できることが必要です。そのため、ユーザー管理／アクセス管理がツール全体を通して必要になります。
ソースコードについては、バージョン管理ツールで管理するとして、設計情報の管理が一つの課題です。伝統的には文書ファイル（Officeドキュメント）をファイル共有するというものですが、この場合、構成管理の重要な要素である変更管理、ベースライン管理がツールでは実現できません。そこで、ソースコードと同じく文書をバージョン管理ツールで管理します。
Officeドキュメント等で作成する文書ファイルの欠点として、編集作業が基本1人に限られること、変更が完了するまでの期間は内容が見えないといったことがあります
迅速性が要求される文書、共同で作成する文書、ハイパーリンクを使用する文書、ソースコードを掲載する文書、ファイルを添付したい文書、には不向きです。このような用途にはWikiが向いています。ただし、Wikiの場合、ベースライン管理には不向きなので、使い分けが必要です。
ソフトウェア開発プロジェクトでのQ&Aの文書化も重要です。仕様・設計についてのQ&A、特に組織をまたいでのQ&Aは過程を記録に残しておかないと後日トラブルの種になります。Excel表でのQ&A管理を多く見かけますが、たいてい破綻しています。チケット管理ツールでチケットにするのも一案ですが、Q&Aは設計情報であり幾度も参照する点、1回のQ&Aで完了せず何回もQ&Aが繰り返されるものが少なからず存在するので、チケットではなく掲示板（フォーラム）が向いています。
ファイル共有については、管理が難しくすぐ破綻するので、成果物を置くのではなく、ファイルをマシン間で受け渡すための一時用途にとどめるのが無難です。共有ツールやデータなどの開発作業で配布するもの、ビルド成果物などの試験作業で使用するものなどは、ファイル共有ではなく、むしろWebを使う方がよいです。ファイル共有は簡単に削除したり置き換えられてしまう上、付加情報を持つのが難しいので、維持的な使用目的でファイル共有を用意しておいた方がよいです。
ここまであげた以下の機能を持つツールを揃えます。
品質管理視点での開発環境基盤
品質管理視点としては、レビュー、テスト、不具合管理の作業となります。品質管理では、作業の実施だけでなく、実施記録を残すことが求められます。
レビューの場合、指摘事項（レビュー後に対処する作業）が記録になり、指摘事項が反映されたことを確認して完了となります。これはチケット管理システムのチケットにするのが向いています。
ソースコードレビューでは、指摘事項に該当ソースコードがあるのとないのとでは雲泥の差なので、レビュー対象バージョンの該当コードへリンクが作れるツールを使うか、ソースコードレビュー機能を持つツールを使うのがよいです。でないと、レビュー実施記録を見て、「xyz.cppの45行目は変数を初期化すること」とあるけれど、その後の修正で行番号は意味を成さず、もはや指摘状況を再現できないということになってしまいます。
テストについては、自動化という観点とテスト管理（実施状況）の観点があります。自動化については、ビルド自動化の一環でテストまで実施するということ、その結果を共有することで、ビルド自動化ツール（ほぼJenkinsの一択）を使います。
テスト管理は、TestLinkというツールもありますが、定番というところには達していなく、これから発展が期待される分野です。ですので、開発環境基盤として特定のツールを推すという段階ではまだありません。
不具合管理については、BTSの出番です。バージョン管理ツールとの相互連携が取れる機能を持ったBTSを使うのが一番です。バージョン管理ツールとの連携については、自動で双方向リンクとなるのが一番です。例えば、ソースコードをコミットする際のメッセージにチケット番号を記載すれば、そのチケットにソースコードのコミット情報が自動で記載される、という動きです。
コンパイラ、各種テストツール
ビルドツール、静的検証ツール、メモリリーク検査ツール、自動テストツール、デプロイツールなどは開発するソフトウェアの言語、OSに依存するので、開発環境基盤としては特定しません。
連絡ツール（追記）
開発環境が外部と切り離されている場合、内部にメールを設ける必要があるでしょう。
ソフトウェア開発環境基盤の一構築例
先のソフトウェア開発環境基盤の一構想に基づいて実際に環境を構築としたら、という想定で具体的な環境を検討します。
基盤を動かす計算機
オープンソースといえども実行にあたっては計算機が必要となり、組織へ唯一開発環境への投資を訴える項目となります。
開発環境基盤は、サーバー機能を中心とするので、計算機は最低1台、できれば2台で冗長構成をとりたいところです。多種のサーバー機能を動かすので、本来は計算機も多数必要としたいのですが、管理の手間と昨今の計算機技術（特に仮想化）を活用すれば1台で複数サーバー機能を動かすことが容易になっています。そこで、CPU／メモリ／HDDを十分搭載した計算機を1組確保します。
オープンソースツールの大半は、Linux OS上での動作が一番実績あるので、LinuxをOSとします。Windows OS上での動作は構築に苦労する場合、機能に制約のある場合があり、またWindows Serverの開発者数分のCALを揃える分費用もかさみます。
ソフトウェア開発環境構成
- バージョン管理ツールにGitを使用
- Wiki、掲示板、ファイルダウンロード、チケット管理にRedmineを使用
- ファイル共有にはSambaを使用
- ユーザー認証にはSamba 4.0のActive Directory（ドメインコントローラ）を使用し、各ツールからLDAP/Kerberos認証として利用
- 自動ビルド他の自動実行にはJenkins
- 各サーバーはLinuxのKVMで仮想化環境上で実行
というのが現在想定している環境です。
Gitは、昨年日本語対応が進み、Windows/Linuxで日本語ファイル名が化けずに管理できるようになりました。また、書籍・Web等の情報も増えており、IDE等開発ツールからの利用も標準あるいは準標準で搭載されるようになってきました。
Redmineは、開発環境におけるWiki/掲示板/ファイルダウンロードといった情報の共有とチケット管理と機能が統合されていて、あれこれ組み合わせずに済む利便性や、Gitとの連携（ユーザー認証含む）、Active Directoryユーザー認証の利用という点が優れています。
最近リリースされたSamba 4.0でWindowsのドメインコントローラ機能が搭載され、Windows ServerがなくてもActive Directoryユーザー認証が実現できる点（少し調査が必要）で、Windows OS／Linux OSが混在する環境でOSのログインユーザーや各ツールでのユーザー認証をほぼ一元化できます。今までツールごとにばらばらにユーザーアカウント設定をしていたので、手間がかかっていましたが、ずいぶん手間を軽減できそうです。
このあたりをあらかじめ仮想化環境に用意することで、実行する計算機さえあれば、開発環境をプロジェクト毎に容易に展開することが可能になります。
これで、いざ、プロジェクトの召集がかかったら、開発環境基盤として計算機を1組（最悪1台、でも障害時に代替きかないが）用意することだけプロジェクトから取り付ければ、あとは仮想化ホストを立ててインスタンスをコピーするだけで即席開発環境基盤の出来上がりです。
認証回りの調査メモ
TODO（追記）
- データのバックアップ機構を設ける
- リソース監視機構を設ける
