Clojureを実際の開発で使いたい場合、まずはチームメイトや上司を説得できなければ使えません。『Clojure』というキーワードで検索してここに辿り着くくらいですから、読者の皆様はClojureを知りたい、使ってみたいと思っているかもしれませんが、他の人はそうとは限りません。
なので、まずは自分自身が経営的な視点でClojureにどのようなメリットがあるのかを理解し、説明できるようにしておく必要があると思います。この文章は、その考え方の一つです。
なぜClojure？
それでは、Clojure言語のプログラマ向けの説明を、経営的な視点から見たメリットとして明らかにしていきましょう。
Clojureの特徴1: 文法要素を追加・変更できる
ある言語を使っている時、自分の目的を達成するために他の言語の構文が欲しくなることがよくあります。プログラムの一部だけRなどの統計分析言語を使いたいとか、ゲームのAIや賢いレコメンド処理などを書くために一部だけPrologの推論システムの構文を使いたいとか。
Clojureのような『Lisp系』と呼ばれる言語ではそのようなことに悩む必要はありません。構文を追加するために言語の作者に言語仕様の追加をお願いする代わりに、自前のライブラリとして作ることが可能だからです。現に先ほど述べた、統計の用途にはIncanterというライブラリありますし、Prologライクな推論システムにはcore.logicというライブラリがあります。両方とも単なる『ライブラリ』であり、コード変換ツールの類ではありません。
これが出来るのは、テキストファイルとして書いたプログラムを実行する際、他の言語では「テキスト→実行形式」となるのに対して、Clojureでは「テキスト→データ→実行形式」というように、一旦プログラムをデータとして解釈するステップがあるからです。実行形式になる前のデータに対していろいろな操作を行うことで、もともと無かった構文を自分でプログラムの中で作ることができます。
巷には高価な「仕様記述からプログラムを生成するツール」のようなものが売られていたりしますが、Clojure使いには必要ありません。大抵の場合、それと同等のことを単なるライブラリとしてものすごく簡単に実現できるからです。
Clojureの特徴2: 既存のプラットフォームやライブラリを積極的に活用する
ClojureはJavaVMやCLR(.NETのVM)、JavaScript処理系などの既存のプラットフォームの上で動く言語です。他の言語は、言語独自のプラットフォームを持っているものが多いですが、Clojureは言語のみであり、プラットフォームはありません。
プラットフォームを独自に作らず、既存のものを活用することで、処理系の改善とライブラリをそのまま手に入れることができます。JavaVMなどの既存のプラットフォームは、莫大な費用をかけて改善されており、今では非常に高速にプログラムを実行できるようになっています。また、そのプラットフォーム上で作られたライブラリは世界中で数えきれない量が蓄積されており、今も多くの開発者が開発に携わっています。これらの成果を活用しない手はあるでしょうか。
Clojureの特徴3: プログラムが大きくなっても大丈夫
Clojureはプログラムが大きくなったときにプログラムがぐちゃぐちゃになってしまわないための特徴を備えています。当然、業務向けの他の言語が備えているような、アクセス制御付きの名前空間やユニットテストの機能はありますが、以下ではClojureが備える特徴を挙げていきます。
関数型プログラミングによる副作用の管理
プログラムが大きくなった時に困るのは、他人が読んだ時や後で読み返した時に、プログラム内の変数をどこで変更しているのか、いつI/Oが起きるのか（この2つをまとめて「副作用」と言います）を把握し直すことです。Javaのような手続き型のオブジェクト指向言語だと、あるインスタンス変数がどのタイミングで変更され得るのかをプログラムのロジックを追っていかなければ見えてきません。Eclipseの「呼び出し階層表示」ようなIDEのサポートでだいぶ手間は軽減されるものの、結構キツい作業です。
Clojureでは『関数型プログラミング』を行うことが言語・ライブラリ両面によって強く促されます。このことで、副作用を扱う手間をかなり軽減することができます。関数型プログラミングとは、なるべく純粋な関数（出力が入力のみに影響され、状態の参照や変更をしない処理）でプログラムを表現する手法で、副作用はなるべく呼び出し元に近い限定的な箇所で発生するよう設計することになります。これによって、プログラム内のどこで副作用を起こしているのかを素早く把握することが可能となり、結果的に大きなプログラムでの開発効率が向上します。
STMによる並行プログラミング
特に制御系のプログラムを作るときに困るのが、ロックの管理です。規模が大きくなると、どこでどんな順序でロックを掛けるのかがプログラム全体を通して明らかにしない限り、デッドロックの危険を回避することはできません。
Clojureでは、ロックの代わりにSTM(Software Transactional Memory)を使うことで、デッドロックの危険性を排除することが可能です。
ただ、ロックやJavaのsynchronizedに比べ、STMではトランザクションの作りによってリトライが頻発してスローダウンするというデメリットがあります。しかし、「プログラム全体でのロック順序の整合をとる作業」と、「ある1つのトランザクションに対して実行時間が長くなり過ぎないように気をつけること」を比べれば、規模が大きくなればなるほど後者が楽だと思います。
Leiningenによるビルド構成の管理
JavaやRubyなどの言語でも、ライブラリのバージョンやビルドの構成を管理する機構は備わっていますが、Clojureは特にLeiningenによってそれが非常に簡単になっています。これは文章で説明するよりも実際に使っていただいたほうが、どのように簡単かがわかると思います。
実は筆者がClojureのメリットの中で最も気に入っているのが、この辺りのエコシステムが非常にシンプルにできていることです。欲しいライブラリがあったら、10秒後に手に入る。全部入りのjarへの梱包もコマンド一発で出来る。ユニットテストもテストも同様にコマンド一発。これで日々の生活がかなり楽になりました。
Clojureの実態
メリットの説明は以上ですが、では実際のところClojureを開発で使うのはどうなのでしょうか？
学習のハードル
Clojureを学習する上では、JavaやRubyなどの手続き型のプログラミング言語に慣れたプログラマにとって、これまでの頭をかなり切り替える必要があります。
例えば、手続き型の言語では変数の値の変更が普通に出来ていましたが、Clojureでは変数がありません。代わりに、値に名前をつける「束縛」とそのスコープを制御することで実現します。この辺りは、プログラムを組む上での根本となる部分であり、今までの概念をかなり崩されることとなるでしょう。
もう一つはループのやり方です。今までfor文で回していたもののほとんどは、Clojureでは高階関数と遅延シーケンスを使って表します。この辺りも、手続き型の感覚を一旦忘れたほうが良い部分です。
「Clojureのやり方」を身につけるまでは、それなりの学習と訓練が必要です。ただ、このハードルを超えることで得られるものは非常に大きいので、その辺りを思い出しながら頑張ってもらうようチームメンバをサポートしましょう。
性能
ClojureはJavaで書いた時とほとんど遜色ない速度で動作します。Web上に実際に測定した人のレポートが有りますので、検索してみてください。
ただ、それはJavaVMを起動してClojureの本体を読み込んだ後の話であって、起動には0.5秒から数秒もかかってしまいます。Clojure自体がでっかいjarファイルなので、そうなります。なので、シェルから何度もプログラムを起動するという目的で使うときには注意が必要です。（回避策は探せばいろいろあります。）
CLR版(Clojure.NET)はあまりまじめに使ったことがないので、よくわかりません。
開発者の確保
日本のプログラマ市場は、CやJava、VB、C#などが中心で、これらの言語ならプログラマの数もかなりいます。RubyやPythonの技術者もかなり増えてきています。当たり前ですが、これらの言語に対して「Clojureのプログラマ」は今のところ極めて少ないです。
ただ、プログラマの技能は言語そのものに対することだけではありません。例えば、「Javaの知識・経験」といった場合、Java言語の知識だけでは当然プログラムが組めるとは言えず、プラットフォームやライブラリに関する知識・経験もたくさん必要です。私はむしろ、後者の言語以外の部分のノウハウのほうが大きいと思っています。プラットフォームに対するツールセットの構築能力や、性能問題などの解決能力を養うほうが、言語自体の習得よりも圧倒的に難しく時間がかかるからです。
このような観点でClojureを見ると、JavaVM上で動くClojureで開発したいならJavaの技術者を、Clojure.NETを使いたいのなら.NETの技術者を探せば良いということになります。
あとは、学習コストとClojureによる開発コストの削減効果を比較すれば、（見つかった技術者の能力にもよりますが）Clojureで作ったほうが良い場合が多くなるのではと思います。しかも、作りたいものが複雑で高度であればあるほど、メリットのほうが顕著に効いてくると考えられます。
Clojure作ったもののメンテナンス
開発者の確保にも通じることですが、Clojureですばらしい物を作れたとしても、実際に使う段になればそのメンテナンスをする事が必要になってきます。開発時にはClojureを知っている/すぐに覚えられるような人材が確保できたとしても、その人がずっとメンテナンスし続けられない場合だってあります。
大きな会社なら育成メニューの作成、そうでなければ定期的な勉強会を開いて、Clojureを使える人の輪を増やしていきましょう。使える人の母数がそれなりにいれば、Clojureを使った開発が認められやすくなると思います。
まあこの辺りは、Clojureに限らず、プログラミング言語に限らず、いろんな製品を採用する場合に言えることですが・・・。
どんなところでClojureが有効なのか
WebアプリならRuby on RailsやDjangoがいいです。（WebLogicでもJBossでもいいですよ。）最初から欲しいものは揃ってますので。要は、目的に特化された製品があって、それを達成できればいいだけなら、わざわざClojureを使う理由は無いということです。
ただ、いろんな技術要素を組み合わせて、他社に差をつけるような独自の製品を作りたいなら、Clojureが良いです。前述のとおり、Clojureは、技術要素を組み合わせる能力と、アルゴリズムを表現する能力が高いです。そして、複雑なものをびっくりするほどシンプルにかけるので、プログラマの力を効率よく引き出してくれます。
ですので、戦略商品の開発を行うときの道具立てとして、開発部門が習得しておくのが、一つの効果的なビジネスへの使い方だと思います。