torutkのブログ

ソフトウェア・エンジニアのブログ

開発環境の構築とソフトウェアエンジニア考

プロジェクト案件毎に、人、ものを集めてシステム開発をする現場では、あらかじめ整った開発環境がないことがほとんどです。人を集めて、開発言語やソフトウェア構成が決まって、それから開発環境が準備されます。もっとシステマティックに作っている組織もあるとは思いますが、ここは自分の経験で語るので、割と泥臭い現場のお話となります。

いくつかのプロジェクトをくぐりぬけ経験を積むと、おおよそ次もどうなるかの予想が立ちます*1。そこで、次は苦労しないようにと早い段階において、開発したプログラムを集積するリポジトリ、開発ツールセットの選定、規約の整備、マスタービルド環境、情報共有環境、不具合管理環境などのソフトウェア開発環境一式を構築しようとします。

本当は開発環境の構築には専任担当者がほしいところですが、現場とは視点が乖離してしまっているプロジェクト管理者には必要性がなかなか理解されず、たいていは必要を感じている開発担当者が仕方なく構築するという現実があります*2

開発が本格化すると、環境構築に手が回らなくなるので、そうなる前に環境が整うようにします。また、集められた開発者が作業を開始する時点である程度運用できるようにしておかないと、開発者が好き勝手に作業しはじめて、悲惨なことになってしまいます。

快適に使える開発環境にはそれなりの計算機を揃える必要があるので、これも早い段階で調達に動きます。プロジェクトで予算を取ってくれていれば理想ですが、たいてい開発環境なんて見えない人達が取り仕切っているので、相当声を大きく働きかけてやっとPC1台なんていうことがざらです。そこで、あらかじめ融通のきくPCをいくつか確保しておくのもソフトウェアエンジニアの心得となります。手持ちが無い場合、人づてでかき集めることになります。このときは、日ごろの人脈がものを言うので、人脈を作っておくのもソフトウェアエンジニアの心得となります。ただ黙って待っていると、数十人の開発環境の基盤がしょぼいノートPC1台なんていうこともありますので、こうした動きは重要となります。

開発ツール(ソフトウェア)を買う予算が付くことは、開発環境のハードウェアを買う予算が付くこと以上に厳しいです。ソフトウェアの予算は正面装備(開発対象システムに組み込むミドルウェア等)が優先で、開発環境に回す予算は付きにくかったりします。また、開発環境のうち、コンパイラ(を含む統合ツール)のようにそれがないと仕事が成立しないものは購入しますが、テストツール、構成管理ツール、不具合管理ツール、情報共有ツールなどには回らないことがよくあります。

そんなときにソフトウェアエンジニアの強い味方となるのがオープンソースです。計算機(箱)さえ確保すれば、Linux OSを入れればサーバーが用意できますし、そこにバージョン管理ツール、チケット管理ツール、ビルドツール、情報共有ツール(Wiki、メール、ファイル共有、Web、・・・)などを予算の制限を受けずに構築することができます。いったん構築したら、ノウハウとともに別プロジェクトにどんどん展開することができます。

商用ツールの場合、仮にあるプロジェクトで購入できたとしても、別のプロジェクトで購入が認められるとは限りません。ライセンスがないのでノウハウあっても使えないという事態があります。

また、商用ツールには汎用性が無い(特定言語・環境)ものもあり、異なる環境では適用が困難ということもあります。例えば、MicrosoftVisual Studio Team Foundation Serverを使って開発環境を整えたとして、次のプロジェクトがLinuxでの開発であったとすると、Visual Studioベースの開発環境は適用が困難です。

「ソフトウェアエンジニア」という用語

ソフトウェアエンジニアという言葉を意識して使っています。開発するソフトウェアのライフサイクル全体(仕様から納入後の保守まで)を考えて効率のよい開発の仕組みを作るのはエンジニアの仕事です。

日本のソフトウェア産業でよく目にする「システムエンジニア」というのは、本来は、金融/証券/企業業務/工場設備/プラント/・・・といったシステムを対象としたエンジニアですから、極論すればソフトウェアをまったく使わずにシステムを作れるならソフトウェアには関わらない(ソフトウェアの専門家でない)人達です。

一方、ソフトウェアエンジニアは、極論すればソフトウェアを使わないで実現するシステムには不要なエンジニアです。ただ、実際にはシステムの機能のうちソフトウェアで実現する比率が増えているので、ソフトウェアエンジニアの必要性が増えています。

システムエンジニアとソフトウェアエンジニアというわけ方をすればすっきりすると思います。

*1:残念ながら、プロジェクト管理者層やペーパーワークしかしない人達には見えないらしいです。

*2:個人の使う開発ツールと違って、プロジェクト全体を見すえる「エンジニアリング」視点が必要となります。手空きの人なら誰でも任せられるものではないのが課題を高くしています。