arclamp.jp アークランプ

　先日、稚北東京サテライトで客員教授会があったのですが、テーマの1つが「システム開発を学ぶ」というものでした。

　すぐに気づくのは言語や実装方法を教えるだけでは足りないということです。Java開発を覚えるのであれば、Java言語を覚えるとかJavaEE（JSP、Servlet）とか、あるいはStrutsやSpringといったフレームワークというのは大きな一歩ではありますが、それだけでは足りません。

RUPにおける作業分野定義
　RUPのdiscipline（作業分野）では、次の9つが定義されています（WikipediaのIBM Rational Unified Processより）。

Engineering Disciplines:
* Business modeling discipline
* Requirements discipline
* Analysis and design discipline
* Implementation discipline
* Test discipline
* Deployment discipline

Supporting Disciplines:
* Configuration and change management discipline
* Project management discipline
* Environment discipline

　ものすごくばっくり言えば次の5つに分類されるでしょうか。

- 上流：Business modeling、Requirements、Analysis and design
- 下流：Implementation 、Test
- 管理：Configuration and change management、Project management
- 運用：Deployment
- 開発環境：Environment

　上流、下流、管理というのは比較的注目されているようですが、エンジニアとしてはEnvironment の重要性を忘れてはいけないところです。

Environment disciplineの重要性
　特にEnvironment についてはきちんとした教育プランというのが組まれていないように感じています。Wikipediaを引けば、Environment disciplineの目的は

The purpose of the environment activities is to provide the software development organization with the software development environment-both processes and tools-that will support the development team.

（environmentの目的は、ソフトウェア開発におけるチーム開発を支援するためのプロセスやツールなど、ソフトウェア開発構成を提供することである）

　とあります。これは単純にIDEというだけではなくて、ソースコード・バージョン管理、構成管理、イシュー管理、情報共有などが含まれます。こうした項目は地味ですが重視されるべき点で、ここで多くのリスクを排除することが可能になります。

　しかしながらノウハウは整理した形で配布されていません。頭数論に書いたとおり

OSSは安価な選択ですが、それによってツールベンダーが崩壊しました。おかげで、これまでは手厚かった教育がなくなっています。初心者用の本が売れているのはツールの品質が下がったからに他なりません。OSSはデベロッパーの能力を上げたのでしょうか？格差が広がっただけなのかもしれません。

　というのは無視できない理由でしょう。OSSスタックをパッケージング化して提供するサービスもありますが、なかなかビジネスにするのは難しいようです。しかし、こうしたサービスへのニーズは強いはずですから、正当な評価をしてビジネス化されなくてはいけません。あ、話がそれました（ｗ。

なぜ管理すべきかを学ぶべき
　では、こうした開発環境となるツールの使い方を学べばよいのでしょうか？たとえばMaven2では、かなり複雑なアプリケーション構成管理が行えるよっています。特にライブラリ間の依存関係解決に力点が置かれています（これもOSSのせいですが）。しかし、そもそもMavenはプラガブルな構造になっており基本的にできないことはありません。僕の周りにいるMaven職人も「そこまでするか（ｗ」という使い倒し方をしたりします。

　ですから、大事なことは「なぜ管理しなければならないか」を学ぶことだと思っています。わかりやすい理由は作業を自動化しミスの軽減することです。ですが、そこから1つレベルをあげて「継続して協業可能な分業を行う」という意識が重要と考えます。

　開発では一人一人の作業がシンプルであっても、それらがさまざまな１．タイミング　２．品質　３．人（生産力）で行われるていることにより常に複雑化しています。それらをなるべく同時化することにより問題の発見を促し、適応のタイミングを作り出します。テスト・ファーストが変化を恐れないために重要であるように、環境整備も変化に適応するためには重要な土台となります。ここだけでも長い話になりますね。

DSE（Domain Specific Environment）
　また、そのプロジェクトにいかに適合するのかというのも重要な視点です。DSL（Domain Specific Language）になぞらえてDSE（Domain Specific Environment）とでも呼べばよいでしょうか。単純に社内でプロジェクトをまたいで標準化するといった試みは難しいはずです。そもそも標準化は生産性向上のために行うものです。標準化によって生産性が落ちてしまうなら本末転倒です。

　ですから、基本的には標準的なるツール郡を用意しておきながらプラグインでプロジェクトの独自性をカバーするというアプローチが現実的になります。ま、これもバランスですが。

　僕の場合はMavenやEclipseのプラグインを開発してプロジェクトに対応することがあります。これもDSEの重要なコンポーネントといえるでしょう。

僕の環境
　さて、皆さん、どんな構成で作業されているのでしょうか？僕はかなり普通だと思いますが、

　JIRAは商用製品ですが使い勝手が良いので気に入っています。情報共有はWikiを使っていますが迷いがあってTrac、Pukiwiki、SnipSnapあたりでしょうか。なんかしっくり来るものがないです。
　あと静的コードメトリクス（Checkstyle、FindBugs）を組み合わせることも多いです。サーバはTomcatをワークスペースごとに用意してTomcat Launcher pluginと舞姫で制御。

　にしても、めんどくさいのが事実。なんか、ぽちぽちっとやったら、えいっとできて、ごにょごにょっとすると完成みたいなのが欲しい。

　稚北東京サテライトでは浅海先生が授業で構成管理ツールを導入してトライ＆エラーを行っています。今後はクラス化して「ネットワーク管理」とか「UNIX管理」を学ぶように「開発環境管理」を学ぶようなことも検討しています。