開発環境（4）

1984年に社会人となってから、様々なソフトウェア開発に従事しましたが、振り返ってみると実際にソフトウェア開発をしながら、チームもしくはプロジェクトのビルド環境の担当も何度か経験しています。

最初に経験したのは、1988年暮れから米国El Segundo市（ロサンジェルス国際空港の南）で従事したSalientプロジェクト（Xerox StarワークステーションをSunワークステーションへ移植するプロジェクト）です。私はVP Document Editorグループに属していたのですが、その時は、グループが担当するソフトウェアのビルドも担当していました。（「Mesa言語」）

グループの中でUnixを良く知っていたのが私だけだったためビルドも担当したのだと記憶しています。ビルドを効率良く行うために、分散コンパイルのためのプロトコルを独自に作ったりもしていました（10台近くのワークステーションを投入して分散コンパイルしていました）。

次にビルドを担当したのは、DS20プロジェクト（Fuji Xerox DocuStation IM200）です。Solaris 2.3、C++、マルチスレッドで、白黒でしたがデジタル複合機（コピー、ファックスなど）を開発した時です。この時は、かなりの量のコードを私自身は開発すると同時に、ビルド環境の整備も行い、1994年当時で毎晩ビルドを自動実行していました。

2003年から従事したプロジェクトでは、私自身はビルドは担当していませんが、DS20プロジェクトに従事したエンジニアも多く含まれていましたので、ビルドを夜間に自動で行うのは当たり前という環境が構築されていきました。このプロジェクトでは、部分的ですが、継続的インテグレーションを試行したりもしていました。

以上の3つのプロジェクトでは、私自身もかなりのコード（C++だけで10万行以上）を書いており、同時にビルド環境を改善していって、開発効率を向上させる努力をしてきました。

今の会社で昨年の10月から、若手の外部技術者と二人でビルドを含む開発環境を整備しています。これで4度目ということになります。すべて手作業で行われていた作業の自動化です（「コンピュータは作業を、人はクリエイティブな活動を」）。ただし、以前の3回と比べて違うのは、私自身は何も製品開発していないということです。

実は、この違いは精神的に非常に大きいです。以前なら、自分自身が開発を行いながら、開発グループあるいは部門をリーディングして、現場を巻き込んだ開発環境改善を行っていました。今回は、開発の現場が全く関心を示さない、むしろ、リーダクラスのエンジニアが開発環境整備を否定したり全く関わったりしないということです。

開発環境の整備に加えて、本来なら日々コミットして退社するなどの細かな開発習慣に対しても開発者に指示して身につけさせないと開発効率は本来上がっていきません。しかし、リーダクラスのエンジニアが現場に指示することは当然ありません。

ということで、今回のビルド環境整備では、以前の3回では意識していなかった事柄を認識したことになります。つまり、改善の意識が低い開発組織に対して、その組織の指揮ラインの横から何かを言っても精神的に徒労終わる可能性が高いということです。

「開発環境」、「開発環境(2)」、「開発環境（３）」