経済とIT

ソフトウェア品質の12の属性

凪瀬 — Tue, 03 Feb 2009 08:36:00 GMT

システム開発において「品質の向上」という標語がしばしば掲げられますが、「品質の属性」については無頓着なケースが多いのではないでしょうか。

ひとくちに品質といっても多様な属性があります。顧客と品質の話で揉めたことはありませんか？品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。

Karl E. Wiegers氏が著書「ソフトウェア要求」で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。

可用性	availability	動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。
効率性	efficiency	同じ処理性能を出すのにどのぐらいのハードウェアのスペックが必要か。
柔軟性	flexibility	機能拡張への柔軟性。順次拡張していくアジャイル開発を可能にするためにはある程度の柔軟性を備えた設計にする必要がある。
完全性	integrity	データが正確で完全であること。改ざんなどされておらず、正しく動作すること。情報セキュリティの目標事項のひとつとして挙げられる。
相互接続性	interoperability	他システムとのデータ連携の容易さ。
保守性	maintainability	バグの修正や仕様変更の容易性。
移植性	portability	ある稼働環境から、別の稼働環境へ移行させるために要する工数など。 JavaなどにみられるVM方式など高レイヤでの稼働システムは移植性が高いとも言える。
信頼性	reliability	特定の期間、故障なしでソフトウェアを実行できる可能性。
再利用性	reusability	プログラムコードの再利用性。オブジェクト指向などによるモジュール化によって高めることができる。もっとも、日本だとソースコードが納品先の所有になる契約となることが多くライセンスの問題で再利用性が低い。
堅牢性	robustness	耐障害性。異常データなどの入力に対する耐性。
試験性	testability	テストのしやすさ。
使用性	usability	ユーザビリティ。使いやすさ。

これらは多くのプロジェクトに共通する属性ですが、もちろんこれで全てと言うわけではなく特定ジャンルではさらに追加の品質属性を考慮する必要が出てきます。同じ本から引用すると「組み込みシステムに重要な品質属性としてはさらに安全性、導入容易性、サービス能力があります。スケータビリティは、インターネットアプリケーションに重要なもう一つの属性です。」ということになるでしょう。

これらの品質属性は、すべてを同時に上げることができません。トレードオフが発生するのです。

品質属性のトレードオフ

これら品質の属性は、相互に作用し合っています。ある属性を高めれば他の属性も高まる、あるいは低くなるということがおきます。以下の表は左側の属性を上げた場合に上側のどの属性が高く、あるいは低くなるかを表しています。（追記：引用元「ソフトウェア要求」228ページ）

	可用性	効率性	柔軟性	完全性	相互接続性	保守性	移植性	信頼性	再利用性	堅牢性	試験性	使用性
可用性								＋		＋
効率性			－		－	－	－	－		－	－	－
柔軟性		－		－		＋	＋	＋			＋
完全性		－			－				－		－	－
相互接続性		－	＋	－			＋
保守性	＋	－	＋					＋			＋
移植性		－	＋		＋	－			＋		＋	－
信頼性	＋	－	＋			＋				＋	＋	＋
再利用性		－	＋	－	＋	＋	＋	－			＋
堅牢性	＋	－						＋				＋
試験性	＋	－	＋			＋		＋				＋
使用性		－								＋	－

まずは品質には属性があることを顧客に伝えましょう。そして属性にトレードオフが発生することを理解してもらいましょう。

ソフトウェア工学と品質属性

ソフトウェア工学の数々の成果はこれらの品質属性にどう影響を与えたのでしょうか？

構造化プログラミング

試験性 - 適切なモジュール分割は試験性を高めます。より高めるにはステートレスな機能を意識的に分割することです。ステートレスな関数は引数と戻り値によって容易にテストでき、自動テストなどによる自動化も行いやすくなります。
再利用性 - 構造化によりある程度、再利用性が高まりました。

契約に基づくプログラミング

完全性・堅牢性 - モジュール間での「契約に基づくプログラミング」のほつれに対して適切にエラー処理を施すことで完全性・堅牢性を高めることができます。

オブジェクト指向

柔軟性・保守性 - オブジェクト指向によって動的なフローチャートになるプログラムを容易に制御できるようになりました（ポリモフィズム）。これを活用することで、既存箇所に手を入れることなく追加のクラスを作成するだけでの拡張が可能になります。
再利用性 - 構造化プログラミングよりさらに再利用性を高めることができます。ポリモフィズムを活用したプログラミングは再利用性の点でも優れています。

VM技術、仮想化技術

移植性 - Javaの標榜する"Write once, run anywhere"は究極の移植性と言えます。現在のJava開発は主にWindows機上で行われており、そのままUnix系のOSで稼働する本番機で動作させるようなことが行われています。携帯電話におけるJavaMEの採用もこの点を活用してのことです。

O/Rマッピング

移植性 - O/RマッピングもDBを特定製品に縛らないという意味で移植性を高める効果があります。

DIコンテナ

柔軟性・保守性 - DIコンテナによる設計は柔軟性・保守性を高めます。
試験性 - DIコンテナによる疎結合は試験性をより高めます。DBなどを伴うシステムですら、スタブによって自動テスト化することが容易になりました。

ここでは目立つ特徴をピックアップしましたが、もちろん品質属性への影響はここに挙げただけにはとどまりません。各種パラダイムを眺める際に、品質属性への影響と言う点でみつめるとまた違ったものが見えてくるかもしれません。

アーキテクチャ選定を考える

凪瀬 — Sun, 28 Sep 2008 14:15:00 GMT

アーキテクチャ選定ではメリットとデメリットを考えるではフレームワークやアーキテクチャの選定は合目的でなくてはならない、ということを言いましたが、「システムの贅肉」という曖昧な概念を説明できていませんでした。

なんとなくイメージはできるんだけど、論理的な定義をうまくあたえれていない…。

骨格＝要件の大きさ

まず、確認しておくことは、システムの規模そのものの大きさです。要件定義・要件開発において、スマートになるように要件を決めよう、という話題ですね。

お客さんに「ちょっとここはこうなるようにしてほしい」とか言われたときに気にするのがこの点。今の設計に無理なく乗るなら軽く「いいですよ」と返せるところですが、その一見小さく見える事象に対応するために骨格がいびつになるような場合は悩んでしまいますね。

さて、そんな要件開発ですが、絶対値というか、要求される事象の大きさの下限は決まっていて、目的を達成するために必要な最低限の骨格を作るだけでも、とても大きな骨格になってしまうものもあります。

ネズミかゾウかではなくて、肥満か筋肉質かだろうが言っているのはこの骨格の大きさと、プログラミングのまずさからくる贅肉を混同するな、ということですね。

体の大きさ＝実装の大きさ

要件を実装するにあたって、実装手段によってソースコード、つまるところ実装の大きさが異なります。大雑把にいえばステップ数ですね。 (ステップ数という単位は誤差が酷いのであまり使いたくないですが、プログラムの大きさと正の相関を持つのは事実)

成長の早さ＝リリースまでの期間

システムを完成させるまでの期間、というのはゾウなりネズミなりが成人するまでの期間に相当するでしょう。

ゆっくり時間をかけて成長（プログラミング）が進み、完成までに数年の歳月を費やすシステムもあれば、非常に高速で成長しわずかに数か月で稼働にこぎつけるシステムもあることでしょう。

一般には、小さなシステムの方が、リリースまでの期間は早く、大きなシステムほどリリース時期は遅い。

養育費用＝開発コスト

成人までの間にどれだけの費用を投入したのかという数値ですね。

成人後の成長＝アジャイル性

アジャイルなシステムというのは成人が早い。割と未熟なうちにリリースしてしまう。リリース後の成長も大きく、成人してからも代謝が高いのですね。

対してウォーターフォール式のシステム開発などは、成人後にほとんど成長は止まってしまう。下手をすると成長などまるでなくて、「老後の介護」にばかり手間がかかるということもありえるのです。

代謝を高めるための設計手法と言うのもあります。こうした後の変更がある場合にそれは活きてくる。でも、いざそのときが来ない限りはそうした設計の良さというのは日の目を見ない。ソフトウェアの保守性はアップサイドリスクであるで言ったのはそういう事情のことなのですね。

寿命＝システムの寿命

システムは改修をしつつ、使われるわけですが、やがて寿命を迎えます。死因はさまざまですが、

土台となるOSやミドルウェアが死んだ
要求の変更に対応できなくなった

というのが大きいかなと思います。

システムというのは設計時に、いろんな前提条件を加味します。こういう部分は変更が容易なように、この辺は変えなくてもよい、とかいろいろ。「全部対応できるように」だといくらカネがあっても足りません。

それらの前提が覆ってしまったとき、それがシステムが死ぬべき時だと私は考えます。

贅肉・筋肉＝？？？

さて、問題となるのがここですね。「実装の質」と言いたいところですが、ひとことに「質」と言っても質にも種類があるので混乱しやすい。

例えば、高い処理効率（パフォーマンス）をたたき出すようなカリカリにチューニングされたソースコードというのは、変更に対してとても弱い。柔軟性に欠けるわけですね。

逆に抽象化を施し、仕様変更などにも柔軟に対応できるようなコードというのはパフォーマンスで劣る。柔軟だけど速度は遅い。

なので、これらのメリット・デメリットを考えた上で適度なところでバランスする必要があります。赤筋（反応が遅いが持続力がある）と白筋（反応が速いが持続力がない）みたいなもんですね。ハンマー投げの室伏広治氏は白筋が多く、マラソンは苦手だというエピソードもあります。状況を見て合致する「質」を選ばなくてはいけない。

ただ、一見して贅肉と分かるものも中にはあって、

コードクローン。要するにコピー＆ペーストによって冗長なコードになっている状態
構造化がうまくされていない
データ構造が非効率

といったところはかなり目立つ贅肉ですね。データ構造が悪いと、それを処理するプログラムも煩雑になって贅肉が贅肉を呼ぶ状態。

こうした、明らかな贅肉はそぎ落とすことでコードが数分の一になることがありますが、経験則からして1/10を超えない。どんだけ贅肉で太らせようとても骨格が支えられないほどには大きくなる前にシステムが破たんするのではないかと思います。人間の体重も世界記録では700kgぐらいらしく、限界までいっても10倍そこそこのようですね。

体脂肪を落とす効率

システムの贅肉を落とし、体脂肪率を10%にするためのコストと、体脂肪率10%から1%に落とすコスト、1%から0.1%に落とすコストが概ね等しいと思います。(無責任な社会、限定責任な社会から着想)

まぁこれは概念的な話なので数字が正確かというと怪しいのだけども、指数関数的だよね、というのは理解いただきたい。過度なダイエットは費用ばかりが嵩むので、ほどほどの贅肉は許容せざるをえないというわけです。

とはいえ、このほどほどの贅肉はコードが数分の一に縮むほどの贅肉じゃない。人間だって体脂肪率が0%になることはないでしょう？多少の脂肪に病的に神経質になっても仕方がない。

合目的なアーキテクチャ選定

フレームワークやアーキテクチャの選定は合目的でなくてはならない。そこで取り上げられる評価軸は「小規模 - 大規模」なんて単純な1軸ではないわけです。

システムの骨格の大きさ：要求事項の絶対値
システムの実装の大きさ：ソースコードの量
リリースまでの期間：開発速度
リリースまでのコスト：開発生産性
リリース後のコスト：可変性
システムの寿命

「時間、品質、料金」のうちから、2つを選択できる、なんてジョークがあるのですが、示唆深いと思いませんか？

これらのうち、何を活かして何に目をつぶるのか、その比率はどの程度にするのかというのが、アーキテクチャ選定で悩む部分です。小さなシステムは、使い捨てにすることもできる。リリースまでの期間が短くコストも小さいなら、定期的に使い捨てにするという方法論もアリでしょう。過去のリソースを使いたいからCOBOLで開発というのもコスト・リスクが見合うならあるいはアリでしょう。

コンセプトは前提条件の上に繰り広げられるものです。コンセプトだけ聞くと「ないわー」と思うようなことでも、特定のシチュエーション下では「そうせざるを得ないね」という合理的なものであったりするのです。

目的があってその実現手段としてアーキテクチャを選ぶのですから、アーキテクチャ単体だけを取り上げて安易に良しあしと言ってはいけない。

出来ることなら、技能あるチームで今風のアーキテクチャで今風の設計をするようなシステム開発をやりたいものですね。

サニタイズとハンガリアンとヒューマンエラーとアスペクト指向

凪瀬 — Sun, 06 Jul 2008 18:34:00 GMT

このあたりの話題は、個々のプログラマに対して「気をつけろ」と注意喚起してもなくならない話題なのですが、その背景的な部分をば少し。

サニタイズは消毒足り得ない

sanitize = 「無害にする」、という英単語ですが、≒ sanitate 「消毒する」と紹介されることが多いですね。でも、この消毒という比喩は文学的ではあるけども、技術的には問題のある比喩に思います。 XSS(Cross Site Scripting、クロスサイトスクリプティング)への対処として言われることが多いですね。

現実の消毒というのは、過剰に繰り返しても問題はなく、消毒済みのものをそのままもう一度消毒しても構わない。なので、食品衛生的な現場では過剰なぐらいに「とりあえず消毒」というスタンスでやるわけです。

これに対しプログラム上やりたいことというのは「その場の文脈でメタ文字となる文字をエスケープすること」 ( 続・「サニタイズ言うなキャンペーン」とはより)なわけで、例えば対HTMLでのエスケープ処理として"&"といった記号を"&"と置き換えたりするような処理です。これは何度でも行える「消毒」ではなく、 正しい場所で一度きりしか実行してはいけない「変換処理」なんですよね。

しかし、プログラムにおけるエスケープは消毒とは違ってあくまで「変換処理」ですから、 正しい場所で一度だけ、しかも漏れなく行う必要がある。そして、その場所というのが、「HTMLを出力する場所全て」というどうやって網羅するんだよ、と言いたくなる広範な個所なのですね。

ハンガリアン記法

話は変わってハンガリアン記法。 Jittaさんの言う「型によるハンガリアン（システムハンガリアン）使うな」の話です。

Wikipediaでも見てもらうと掴めると思うのですが、"iWindowHeight"みたいに、変数名の頭に型を表現する情報を付加すると言う記法です。

この記法、Javaなどの強い型付けの言語の場合、プログラム上の「型」と変数名での「型」と冗長になるんですね。そしてプログラムでの「型」はコンパイル動作で機械的にチェックされるので型の相違などは検出・修正できるわけでバグとなっていつまでも残るようなことはないわけです。そして、この冗長を常に保つことの難しさというのが欠点として挙げられていて、メリットがないということが言われている。

ハンガリアン記法を保つためには、「全ての変数を宣言する箇所で」網羅的に命名を確認する必要があります。そしてソースコードを修正する際に「型を変更する全てのケース」で網羅的に変数の命名も直さなくてはならない。

ヒューマンエラー

例えば、小学生低学年向けの、算数のドリルをやるとしましょう。算数の足し算を延々とやるわけです。算数の足し算ぐらいは誰でもできますね。では、1万問のドリルで全問正解してください、と言われたら「そんなの簡単だよ」と言えるでしょうか？

これは単純で簡単な作業であっても、人間はなんらかの間違いを犯すと言うことです。「うっかりして」の「うっかり」なのです。

あなたがチームリーダーだとしましょう。10人のメンバー全員に1万問のドリルで全問正解させるにはどうしたらいいでしょうか？この「うっかり」に対して「気合いを入れて」とか「集中して」とか精神論を掲げても、確実性が上がるわけではありません。

俗にサニタイズと呼ばれる処理も、ハンガリアン記法も、原理を理解して対処することは難しくはない。 (いや、サニタイズ言うなキャンペーンはその原理の理解がされていないことを憂いてのキャンペーンだったか…) 算数ドリルのような話題です。ただし、その数がべらぼうで、「うっかり」間違えることもあるというものです。

10人分の計算ドリルをあなたが検算することで全問正解を目指すとしましょう。あなたは検算を間違えないでやりとおせるでしょうか？「うっかり」検算を間違えたりしないでしょうか？ XSSの話題というのはこの個々は簡単な作業なのだけども、漏れなく実施しそれを保証するのが難しいというところが本題です。そして一か所でも漏れがあるとそれでセキュリティホールになる可能性があるって言うんだから嫌になる。

ハンガリアンでもやはりきっちりと網羅して行うことの難しさというのがあって運用に堪えない。

こうした部分にはヒューマンエラーがするりと入り込んでくるので頭が痛い問題です。

アスペクト指向というパラダイム

拙稿アスペクト指向の概念でおおむね解説しているわけですが、アスペクト指向では「全てのXXに全部YYをする」という事象を扱います。これをアスペクト、「横断的関心事」と呼ぶわけです。上記、挙げてきた件を解決しようという試みなわけですね。

このアスペクト指向というのはOOP(オブジェクト指向プログラミング)の概念とぶつかるものではなく、相補的なものと言えます。

AOP(アスペクト指向プログラミング)に対応した言語では、関数のようなものを作って、この処理を「全てのXX」に差し挟む、ということが記述できます。この「全てのXX」という部分にOOPでのオブジェクトなどが用いられたりするわけです。

また、AOP対応言語でなくとも、設計のパラダイムとしてのアスペクト指向というのはあって、 OOPでのデザインパターンでProxyパターンというものがありますが、これは、 Proxyするオブジェクトで前後に処理を一律に差し挟むことを可能とする。アスペクト指向的な概念に対してOOPの枠内でできる対処法のひとつなんですね。

XSSに代表されるように、横断的関心事というのは人間の手作業ではヒューマンエラーとも密接に関わって非常に対処しにくい。 AOPはプログラミングのパラダイムとしてだけではなく、開発体制をいかに構築するか (私はこれをシステムを構築するプログラミングの仕事と類似する事項と思っています) という部分にも応用することができる。

日常の開発の中で、こうしたアスペクトを捉えて、それを一網打尽にするジョインポイントはどこか、そう考えると見えてくるものがいろいろあるのです。

人件費の1%の投資で効率を20%UPする方法

凪瀬 — Thu, 03 Jul 2008 00:51:00 GMT

もし、あなたがこれから10年間、土砂を運搬する仕事をするとしたならば、次のどの道具に投資しますか？

手押し車 (10,000円～)
軽トラック (500,000円～。最大積載量は350kg以下)
中型トラック (ダンプで1,500,000円～。最大積載量は6.5トン未満)
大型トラック (10tダンプで10,000,000円～。)

多くの人は4を選ぶのではないでしょうか。あるいは大型免許を保持していない人は3を検討するかもしれません。

道具というのは仕事の効率に直結します。土木建設業などでは機械による効率化が目に見えてわかるため、機械への投資とそのリターンが想像しやすいですね。

開発マシンを変えたなら

以前のプロジェクトで契約先会社から支給されたマシンで開発していたのですが、 Tomcat(JavaEEの実行環境であるWebサーバ)の起動に300秒以上かかっていました。プログラムを修正し、コンパイルしてテストを再開するたびに5分待たされるわけです。 10箇所修正するとそれだけで50分、1日の業務の10%がこの待ち時間で費やされていたわけです。

そこで、DELLでCore2Duo搭載でメモリが2Gのマシンを12万程度で購入し、持ち込むことにしました。これによって、Tomcatの起動時間は20秒程度にまで短縮されました。

システム開発において、Webサーバの疑似環境の起動や、DBの起動、コンパイルといった処理にはかなりのマシンパワーが求められます。

また、Eclipseといった最近の高度なIDEはそれ自体が相当にマシンパワーを要求します。もっとも、クラス名・メソッド名などの自動補完や、構文解析を伴う高度なシンタックスハイライト、コード記述中の動的コンパイルやバグパターンの検出機能、リファクタリング機能や命名規約のチェックなど、生産性向上のための多様な高度な機能が盛り込まれているため、「テキストエディタで開発すれば？」というわけにはいきません。生産性が違いすぎます。

さて、先に挙げたように土砂運搬の例だと投資額が1000万円とかになるわけですね。耐用年数が10年だとしても年間100万円、これに重量税や車検といった費用がかかります。人件費側を保険等の諸経費も込みでひとりあたり50万円/月と仮定した場合、年間600万円でその20%ぐらいの比率で機械への投資が必要だと言うことになります。しかし、それで4tから10tに切り替えたら一度に運べる量は+150%になるわけで、仕事のためにこの金額を投資しようと考えるのが一般的です。

開発に使うマシンの場合はどうでしょうか。先に挙げたとおり、私が今開発で使っているマシンは12万円です。この12万円にはWindowsVistaとMSOfficeのライセンス料も含まれています。 耐用年数を2年としても、年間6万円です。わずかに人件費の1%です。そして、こまごまとしたマシンフリーズや起動待ちから解放されて+20%程度の作業効率アップができるわけです。

開発マシンに投資しよう

マシンが古いと正に「仕事にならない」という事態が発生します。しかし、その仕事上での困り具合というのがどうにも見えにくいというのもIT業界の特徴です。

Webでもそうですが、通信を行うシステムではマシンが物理的に複数台あるほうが効率が良いこともあります。 1台のマシンに仮想環境を作って疑似的に2台にするとかいうこともできますが、その手間とかマシンパワーの負担による待ち時間の発生とか考えたらマシンへの投資をケチってトータルで得をするでしょうか？ IT業界は人件費の比率が突出して高い業界です。人を活かすためのマシンへの1%程度の投資額なんざ、あっというまに回収できるわけです。

しかし、積載量が倍になれば運搬効率二倍だね、なんてイメージのしやすさに比べ、 IT業界での仕事効率は見えにくい。ですから、経営者や、経理の人には 「マシンを2年じゃなくて4年使えば経費を50%カット♪」 ぐらいに思われている可能性があります。その代償としてどれだけの人件費が無駄になっているか、どれだけ技術者のモチベーションを下げているかをちゃんと伝えなければなりません。

【ニュース】アルファギークと学生の討論会が開催される見込み

凪瀬 — Mon, 23 Jun 2008 16:32:00 GMT

ひがやすを氏がアルファギークと学生の討論会をセッティングしてしまったらしい。「9月上旬の土日(たぶん9/6以外)」だそうです。私も極力調整して参加するつもり。

ことの発端はITメディアが「10年は泥のように働け」「無理です」――今年も学生と経営者が討論と報じた記事。これはIT Pro側の「IT技術者はやりがいがある仕事か」---学生とIT産業のトップが公開対談と読み比べるとわかりますが、 ITメディア側は偏向報道が強い。「10年は泥のように働け」という言葉が独り歩きして炎えあがりました。

その際、ひがやすを氏は IT業界の重鎮に期待せず、アルファギークと学生の討論会はいかがというエントリを立てて

とはいえ、重鎮たちと学生を討論させても、学生がIT(SI)業界に夢を持ってくれるとは思えないので、ここで1つ提案をしたい。
小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。
もちろん、司会は、ダンコーガイ。いいよね、弾さん。

と書かれているのですが、今回、この試みが具体化したということのよう。

この行動力、言い出しっぺの法則をやすやすとこなす点には敬服いたします。こんな楽しい企画ですから私も協力は惜しみません。とりあえず微力ながら広報まで。

Webシステムの次は

凪瀬 — Wed, 21 May 2008 01:07:00 GMT

プログラミングのジャンルと難易度(および Web プログラミング批判)というエントリが人気のようですね。ざっくりした概要は「Web プログラミングの世界ってのは、全体的に程度が低いからだ。」の一文で表現されてしまいます。

JavaのServlet技術を用いた業務システムをさんざんやってきた私ですが、この感覚というのはよくわかる。 Webシステムのサーバサイドの仕事の8割は経験3ヵ月の新人でやれてしまう。

ただ、Webシステムは技術がまるでいらないかというと、そういうわけではなくて、物凄く幅広い知識が必要とされる側面があります。しかし、そうした技能を持ったアーキテクトがチームにひとりいれば、大抵の問題は解決できるぐらいに、大半は専門的な技術を必要としない。

こうしたWebシステムの側面は、経済的な面で非常に有利であり、あんなにも使いにくいUIになるにも関わらず、多くのLAN内部で使われる社内の業務システムがWebサービスとして作られることになりました。 (アプリケーションの配布の手間がないという側面も大きく評価されたのだと思いますけども)

HTMLによるGUI作成

Webの、というよりHTMLによるGUIの作成は、VisualBasicよりもある意味では易しい。というのは、画面サイズ固定であればVBによる画面作成は煩雑ではないものの、HTMLのような自動レイアウトが容易ではないからです。ウィンドウサイズを可変にして、サイズの変更に際してスペースを割り付けするとか考えたらやってられなくなる。固定レイアウトであればVBが楽、可変のレイアウトであればHTMLが楽だと思います。

そしてこのレイアウト、および出力データが一体となって、HTMLという文字列で扱うことができます。古典的にperlのCGIを作る場合はこの出力HTMLを動的に書きだす文字列操作に終始しますし、 JavaだとJSPなどのテンプレートエンジンの類、つまるところ、HTMLの可変データ部分だけ虫食い状態にしたものを用意して、そこにデータを埋め込むという方式を用いることになります。（実際には表を出力したりする場合の繰り返し処理などもある）

これらの処理は、複雑な論理演算を伴わないので、アルゴリズムを考えるという技能があまりなくとも一応形になるものを作れる。この敷居の低さは確かで、経験3ヵ月の新人でもできるというのは本当です。

Webシステムはことさら初級者に仕事をさせてシステムを作ると言うことがされているように思います。静的オブジェクト指向は設計者が苦労を背負込むシステムで挙げた「Javaの静的オブジェクト指向というのは将軍の力でもって、初心者の大隊を常勝させるための技術」というのは特にこうしたWebシステムの開発現場では身に染みて思うところです。まともなGUIプログラミングとかだと初級者にやらせられる仕事なんて本当に少ない。

熟練するには幅広い知識が必要とされる

大規模なWebシステムというのは、とりあえず仕事をさせるとした場合のボーダーとなる技能は低いのですが、熟練するためには非常に幅広い知識が要求されます。

HTMLの構造
CSSの知識
UIデザイン論
JSPなどのテンプレートエンジンの動作原理
タグライブラリ・EL式の知識
JavaScriptの技能
AJAXの動作原理
HTTPのプロトコルについての知識
Cookieを用いたセッション管理の仕組み
SSLによる暗号化通信の仕組み
Strutsなどのフレームワークを用いる場合はその動作原理
O/Rマッピング
DIコンテナ
RDBMSの知識
バックアップなど運用についての考慮
ロードバランサなどの理解
システムの多重化についての知識
セキュリティに対する知識(XSSやSQLインジェクションなどのアタックへの対処など)

うーん。きりがない。

このように個々の専門知識は相応に深く、しかもフロントエンドからバックエンドまで非常に幅広い技術が要求されるので全体統括をするためには知識の深さと広さを兼ね備える必要がある。

とりあえず作業をすると言う時の敷居の低さに対して、熟練するためのギャップが凄まじいんですね。このあたり、慢性的な人材不足の構造的な理由かもしれません。

ポストWebシステム

Webシステムの開発をしていれば、こんなやり方はいつまでも使えるもんじゃないというのは感じていることでしょう。ブラウザ戦争の頃の不発弾のようなデファクトスタンダードなHTMLの仕様といい、文字コードなんぞ考慮されていないHTTPの古めかしい仕様といい、 Webシステムに精通すればするほど、不安定な土台に乗せられた危ういシステムということが見えてくる。

世紀が変わった頃にはリッチクライアントと言うことが盛んに言われ始めて、 Webシステムのプアなユーザビリティはどうにかしないといけないという問題意識が高まっていきました。

しかし、そもそもがブラウザというものはPCへの標準搭載がほぼ100%という土壌があります。新しいプラットホームを作るにあたって、この壁は大きな壁となります。

SunがJavaFXロードマップ発表というニュースが出ていましたが、ここにきてリッチクライアントのプラットホームはAIR、Silverlight、JavaFXという3者に絞られてきた感があります。

AdobeのAIRはFlushなどの技術がベースにあります。Flushの普及率は高く、当blogのGoogle Analyticsでの解析を見ると97%ほどになります。

Silverlightのサポート環境は調べる手立てが思いつかないのですが、当blogのGoogle Analyticsでの解析では

OS	ブラウザ	%	Silverlight
Windows	Internet Explorer	50.34%	○
Windows	Firefox	33.94%	○
Windows	Opera	4.06%	×
Macintosh	Firefox	3.54%	○
Macintosh	Safari	3.45%	○
Linux	Firefox	1.87%	×

となっていますから、サポートされる環境の91.27%より少ない程度がSilverlightが動作する可能性があります。

…。というか、この数字えらく偏っていませんか？いくら技術系のblogだからってFirefoxのシェアが40%あるってどうなんだ。 OSもWindowsが89.41%でMacintoshが7.19%もあるし…。なんかあまり信用できる数字ではないですね…。母集団が凄く偏っているような気がする。

JavaFXは当然Javaベースの技術です。当blogのGoogle Analyticsでの解析ではJavaのサポートが95.41%となっています。これからいくらか割り引いた程度が動作環境と考えられますね。

ポストWebシステムに求められるもの

前述のようにデータは怪しいものの、3者はかなりの割合で動作することが見込まれます。移行の為の下地は整いつつあると言えるでしょう。

機能的には古典的なHTMLによるWebシステムと違い、非同期通信がサポートされますし、アニメーションを伴うかなり高度なUIを用いることができることがウリです。かなりのユーザビリティ向上が望めます。

そして、これらのより高機能で複雑になったシステムを、より簡単に開発できる必要性があります。開発費が高沸してシステム開発の敷居が上がるなんてことでは、普及は難しいでしょう。

私は最近Flex/AIRのシステムを作っていたりするのですが、高度なUIが容易に作成できるようにとの工夫が随所に見られます。このあたりの感触からも、そろそろリッチクライアント時代が来るな、という手ごたえを感じます。

静的オブジェクト指向は設計者が苦労を背負込むシステム

凪瀬 — Sat, 10 May 2008 13:02:00 GMT

みねこあさんのところで挙がっていた、静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。

Javaは経済的事情をうまく捉えて普及した

プログラミングの効率と経済で書いているとおり、大量生産フェーズにおいては 「一部のプロフェッショナルと多数の凡庸なプログラマという取り合わせ」で開発することでその費用を抑えるということが行われます。

こうすることで、一定の品質のものを低価格で提供できるわけですが、現行のJavaEEでのWebシステムというものは正にこのような体制で製造されているということも、多くの人が認めるところでしょう。これはバベッジ的な分業効果 *1 というもので、とりたてて目新しい話題ではないですが、 JavaによるWebシステムが流行ったのは、こうした経済的側面からして都合がよかったという点が大きいと思います。

要するにJavaというのは登場した1996年当時の肥大化しつつあるシステムをいかに経済的に製造するかという点で答えを与えた言語であり、こうした経済的視点がJavaの普及の原動力のひとつであったと言えましょう。事実、MicroSoftはJavaの改造版を作りWindows開発に利用しようとしましたし(J++ 1997年)、ライセンス上のトラブルがなければC#(2002年)を作る必要はなく、J++がその役割を担っていたことでしょう *2。

Java以前からオブジェクト指向が存在したことは周知の通りだし *3、 Javaによってオブジェクト指向が広く使われることになったのもまた周知の通りです。しかし、なぜ、Javaがオブジェクト指向を普及できたのか。私が思うに、javaのオブジェクト指向がクラスの設計者と利用者の間のスキルの差をバベッジ的分業効果で肯定したからではないでしょうか。

というのは、Javaの静的オブジェクト指向というのは、クラスを設計する側の立場に立つと非常に苦労するものなのですが、クラスを使う側には非常に楽なものなのです。 Java界隈で仕事をする会社の新人教育は、この「クラスを使うことができる」レベルまで到達出ていればよいとされていると言って過言ではないでしょう。

この、苦労をクラスの設計者に一身に背負わせたという点で、Javaの静的オブジェクト指向は多数の凡庸な技術者を用いて開発を仕切らなければならないアーキテクト（先に言った設計者）の支持を得、スペシャリストが作り上げたクラス群を使うだけという凡庸なプログラマ（先に言った利用者）にもまた支持されたのです。

JavaやC#といった静的型付けのオブジェクト指向言語はまさにこのような環境下で多く活用されていますね。

初級者と中級者の間の壁

しかし、これはスペシャリストである設計者と凡庸な実装者の間に厚い厚い壁を作ることとなりました。 Javaはコーディングができるという初級者と、プログラミングができるという中級者の間に大きな壁があります *4。たどたどしいながらも、条件分岐とループを操り業務ロジックを実装するというレベルへは容易に到達できるがそこから思った通りにプログラムを作れるまでの間が遠く、人がどんどん供給されてなお「人材」は不足していると言われ続けるのは、この壁を越えて中級者となれる技術者の少なさを物語っているとも言えましょう。

多分、その初心者と中級者とのあいだの落差が、LLと呼ばれる言語、つまるところ動的オブジェクト指向言語ではなだらかな斜面となっているのではないでしょうか。それが、動的オブジェクト指向の「軽さ」のひとつではないでしょうか。教育的な意味で、なだらかなステップアップが望めるのがLLではないでしょうか。

さて、Javaで言ったクラスを利用できる初級者とクラスを作れる中級者・上級者との間の壁ですが、これは、クラスの使い手が楽をできる分の揺り戻しというか、反作用と言うか、そうした類のものです *5。より使い手に優しいクラス設計にしようとすればするほど、クラスを作る段で苦労が増えるのです。この初級者の苦労を中級者以上が代わりに背負うというシステムが、初級者と中級者の隔たりを大きくしている。

しかし、クラスというのは作るよりも使う方が回数が多いのが通常ですから、作る側に労力を持ってくるというのは非常に合理的で、うまく設計されたクラスと言うのはその使用に際して間違えることができない *6。ヒューマンエラーを機械的に排除した作りにすることができるのです。これが、静的オブジェクト指向言語の何よりもの魅力なのです。

逆に動的オブジェクト指向言語によるプログラミングは、初級者の苦労分まで中級者以上が背負うという責務が軽い。これが、動的オブジェクト指向のもうひとつの「軽さ」ではないでしょうか。他人の荷物を背負って山に登る必要がない。持つのは自分の手荷物だけでいいのです。

反面、動的オブジェクト指向言語のクラスライブラリの利用は静的オブジェクト指向言語でのそれに比べ重いように私は感じるのです *7。自分で作ったクラスを自分で使う分には、両方とも自分ですからその重さはあまり気にならないかもしれない。しかし、初級者を多数率いて行うような規模感の開発ではその重さが強く出てくるように思います。

それぞれの適所とは

つまり、LLというのは上級者であるスペシャリストが、多数の初心者を率いて巨大なシステムを作るということを行うには向かないが、中級者以上が集まったチームでは非常に手軽にサービスインまでこぎつけることができるのではないでしょうか。ネットで話題に上がるような面白いサービスというのは正にこうしたチームによって作られていると思います。手早くプロトタイピングし、その使い心地を評価するのに非常に向いている。

逆にJavaのような静的オブジェクト指向といのは初心者の軍を率いて戦うには向いていると思います。業務用システムのような、大量の仕様を人海戦術で捌かなければならない状況によくマッチする。ただし、これは軍を率いる将軍の采配が非常に重要であることをも意味しています。上が荷物を持ってくれるからこそ一兵卒は軽い荷物で行軍できる。上が荷物の持ち方を知らないなら、兵は生きて帰れぬ戦線で戦わされることになる。

この責任の重さがJavaのオブジェクト設計の重さです。しかし逆に、そこでさえうまくやれば、全軍を勝利に導けるという意味でもある。 Javaの静的オブジェクト指向というのは将軍の力でもって、初心者の大隊を常勝させるための技術なのだと思うのです。私が隊長となって、動的オブジェクト指向言語で中級者による小隊を率いるならば、まだ戦果をあげることもできるかもしれませんが、初心者の大隊を率いて戦えと言われたら、常勝する自信がない。

だからこそ、一般には動的なオブジェクト指向言語での開発は小規模で生産性が高く、静的なオブジェクト指向言語は大規模で生産性が高いのだと評価されるのでしょう。この結論は個々の開発者が置かれた環境によって生産性が高くも低くもなることを意味していて、どちらも一長一短あって、静動どちらかが絶対的に生産性が高いというわけではない。

制約の多さは管理する側には大きなメリット

静的言語の制約の多さは、制約される側の立場、つまるところ淡々と実装作業をする側としてはわずらわしいものであると思うかもしれません。それらを統括して管理しなければならない側に回ると、これほど統治に便利なものはない。 Java開発者では設計の自由を手にできている開発者は少ないと思います。日々、降りてくる仕様書を淡々とコードにし、テストするような人員が大量動員されている。彼らには多くの能力は求められません。つまり、簡単な重労働なのです *8。

Javaでの開発を生業として、設計の自由を手に入れて楽しい開発をしたいのであれば、どうにかして初級者の荷物を持つ力を手にしないといけない *9。

静的オブジェクト指向言語の軽さ

静的オブジェクト指向での設計に慣れた者は、たとえ一人でプログラミングするとしても、クラスを使う側というのは初心者であろうと失敗することができないという設計にしてしまう。これは、神経質すぎるように思うかもしれません。しかし、この神経質とも思えるクラス設計が、クラスを使う側に自身が回った時に幸せへと変わるのです。つまり、自分自身さえも、クラスを使う側に回ったならば初心者のレベルまで脳みそを手抜きすることができるというわけです。これが静的オブジェクト指向でのプログラミングの軽さなのです *10。

静的オブジェクト指向の理想は、コンパイルが通った時点でバグがなくなっていることです *11。その強い型付けを最大限に生かし、間違えることができない型設計をすることが、後の生産性を高めます。だから、クラスの設計が終わってしまえば、そのクラスについて忘れることが許される。強い型システムがクラスの使い方を導出してくれます。導かれるままに使うだけでいい。私がJavaで大量にロジックを書くことができる理由は、効率よく忘れることが許されているからに他なりません。俯瞰視点で設計するときは細部を見ることはないし、細部を作るときには全体を見ることはない。

一度に大量にプログラミングすると自分でプログラムしたことさえ忘れてしまうことがあるぐらいに *12、型を境目とする「契約に基づくプログラミング」は思考を分断することができるのです。型が契約を分かりやすくし、保証をしてくれる。契約は確かに面倒臭い。ダックタイピングは慣行に基づき契約書なしでの契約締結で楽なのですが、逆にそれゆえに契約そのものが曖昧であやふやな感じが私は嫌なのです。

注釈

*1 チャールズ・バベッジ(Charles Babbage、1791 - 1871)

*2 J++で作られたMFCのアプリケーションはMS製のJavaVMでしか動作しない。これはJavaの世界を二つに分断することになるとJavaのコミュニティは考え反発しました。 Javaのライセンスを持つSunとの訴訟となったが、別にSunだけが反発したわけではありません。

*3 JavaはSmalltalkやC++のオブジェクト指向の機構を参考にしています。

*4 目的を適える為の方法論を考えられる/られないという区切りでプログラミング/コーディングと用語を使い分けています。自分のやりたいことを自分で考えてコードにできるようになって初めてプログラミングと言えると思います。

*5 誰かの楽のためには誰かが苦労をすることになる…

*6 ただし、中級者の頃には、そのクラスの使用頻度・重要性に比べて凝りすぎたオーバースペックな設計にしてしまいがち。でも、そうやって工夫を自分の手でやってみて設計を覚えていくのだから教育的な視点では暖かく見守りつつ、バランス感覚を身につけるように諭さなければなりません。

*7 デバッグが困難なバグのひとつに、異常データがどこからともなく紛れ込むというのがあります。ソースの流れを追うのに比べ、データの流れを追うのは難しい。 ( Objectよ、汝の出自を示せを参照) 動的オブジェクト指向言語で私が一番不安になるのは、オブジェクトの動的さゆえに、この手のバグに遭遇するのではないかという不安です。

*8 ニコニコ動画で知られる、ドワンゴが2ちゃんねるで求人をした際のフレーズ。 ITmediaの記事を参照のこと

*9 設計をする自由を手に入れるとIT業界は俄然楽しくなります。技術職の本懐でしょう。

*10 情けは人の為ならず。使いやすいクラス設計を呼吸をするように無意識に出来るところまでプログラミング能力を鍛えると静的オブジェクト指向の方が楽になると私は思います。

*11 実際、業務ロジックなどの単純なものであれば1000行程度なら、2～3時間ぐらいでがーっと書いてコンパイルを通した後に2割ぐらいは1発動作します。動作させて若干の修正というのがほとんどで、1、2回の確認でプログラミングが完了。ただし複雑なロジックは流石にそうもいかず、JUnitのテストなどを使いつつ動かしながら完成させます。

*12 小人さんとの出会い方を参照

追記

トラックバックできないとの問い合わせがありましたので、その点について追記しておきます。

わんくまblog全体に言えることですが、トラックバックが分かりにくくなっているかと思います。（自分も昔、わんくまblogにトラックバックを送ろうとして失敗したことがあります。）

わんくまでは.Textというblogツールを使っているようで、挙動は.Textの使用に準じます。また、スパムが多いらしく、厳しめにスパムキーワードを設定しているようで、リンクを書けないなど不便をおかけしています。管理人に代わりお詫び申し上げます。

2ch 求人就職者の実状

「ITゼネコンをぶっつぶせ」レポート

凪瀬 — Fri, 02 May 2008 14:17:00 GMT

日本Javaユーザグループ主催で、クロスコミュニティカンファレンス(CCC)が、4/30日に行なわれました。この稿ではそのうち「ITゼネコンをぶっつぶせ」というBOFについてレポートおよび考察となります。講演者はSeasarの開発者として著名なひがやすを氏。会場は立ち見が出るほどの盛況ぶりでした(100人以上はいたと思われる)。

ITゼネコンをぶっつぶせ - ひがやすをblog
ITゼネコンを倒す方法をみんなで考えよう - ひがやすをblog
プログラミングファースト開発 - ひがやすをblog

セッション資料はそのうち公開されるのではないかと思います。

本セッションはITゼネコンの問題点をまず挙げ、ひがやすを氏の考える打開案であるところの「プログラミングファースト開発」についてのプレゼンといった流れ。

残念なのはひがやすを氏が契約の部分に対して解をもっていなかったという点ですね。セッション最後に「最大の弱点が契約」とおっしゃっていました。まさにその点を克服しないことにはITゼネコンが変わることが出来ない。このあたりについては手前味噌ではありますが以下の考察も参考にして貰えると幸いです。

SIerをカモに金を稼ぐ方法　- プログラマーの脳みそ
 技術を持たない人で金を稼ぐシステム　- プログラマーの脳みそ

ITゼネコンよ、仕事しろ

序盤、ITゼネコンの問題については、「上流指向型」と「全丸投げ型」が例示されました。全丸投げ型は論外として、上流指向というのも結局のところ、相応の仕事ができていないじゃないか、という点が不満のポイントですよね。開発ができないのに設計するなんて無謀な話。

相応の仕事をした上で、相応の金を取るなら別に文句を言われる筋合いはない。そうした点で、共通して言えることは「ITゼネコンよ、仕事しろ」ということでしょう。

「ひがやすを BOF ITゼネコンをぶっつぶせ」に期待 - 凪瀬blog のコメント欄にてメインフレームの話がでています。メインフレームのような大手でしか扱えないものを扱って金を取るというのは相応の仕事でしょうし、そういった仕事をやることに対して批判するものではありません。

しかし、オープン系の開発では「資本力を持つ」以上の仕事が出来ていないITゼネコンもある。そうした仕事はしないのに高利であがりを攫っていくというやり口は批判されるべきだし、「ITゼネコンをぶっつぶせ」の対象そのものなわけですね。

また、システム開発が資本力で効率化できない理由 - 凪瀬blog では、IT業界の大手はその資本をうまく活用できていないと指摘しました。

大規模システムの設計 - 凪瀬blog で取り上げた事項ですが

システム開発のコストに一番大きく影響するのはステップ数です。
（中略）
次にコストに影響するのは開発に関わる人員の質だ、とジェラルド・ワインバーグ氏が論文で述べています。
このあたり、詳しくはソフトウェアエンジニアリング論文集80'sで読むことが出来ます。

と、30年前の論文ですでに開発のコストを下げたければ人の質を高めろと指摘されているのです。

そして、開発者の賃金は、能力による生産性の向上に対してゆるやかな上昇しかしない、逆にいえば能力に見合った賃金が払われていないため、常に一番能力のある人を高い賃金で雇うことが最善だということも書かれています。

人を育てて金額相応の仕事をしろ。これに尽きるかと思います。

プログラミングファースト開発

プログラミングファースト開発がいかなるものか、ということについてはひがやすを氏がblogで解説しているのでそちらを見て頂くのが一番でしょう。

既存の標準とどう向かい合っていくのか

質問で上がった気になるキーワードに「共通フレーム」というものがありました。これは社団法人日本電気計測器工業会（JEMIMA）の規定する共通フレームのことのようですね。

こういったやり方を基準としている場合、どうやってその壁を破るかというのは大きな課題と言えましょう。会場での質問と似たような指摘が他にもあり ITゼネコンは永遠に不滅、か？ - andalusiaの日記では経済産業省の「システム管理基準」( PDF文書)を取り上げて、

ＩＴ全般統制という黒船が到来しようとしている今、おおっぴらに「プログラム設計書を書かない！」なんてことは、多分上場企業の役員さんは言えないでしょう。なにしろ、向こうには経済産業省謹製の「錦の御旗」があるのですから。残念ながら、滝派(*1)管理脳が官軍で、アジャイラーは賊軍(*2)なのです。

という考察をしています。最もこのシステム管理基準についてはその文章の中で

システム管理基準は、本管理基準と姉妹編をなすシステム監査基準に従って監査を行う場合、原則として、監査人が監査上の判断の尺度として用いるべき基準となる。ただし、組織体が属する業界又は事業活動の特性等を考慮して、必要ある場合には、本管理基準の主旨及び体系に則って、該当する関係機関などにおいて、独自の管理基準を策定し活用することが望ましい。また、時々の関連技術動向、関連法令、及び社会規範などを考慮し、それらを反映した詳細なサブコントロール項目を策定することが望ましい。

と、そのまま使うのではなく必要に応じて独自に策定しろと推奨しているわけで、この基準に則らないと駄目だ！という代物ではないのですが、そのまま採用している会社であればやはりプログラミングファースト開発などの工夫にとっては障害となるのではないでしょうか。

オフショアなんてやめてしまえ！

ひがやすを氏曰く「オフショアなんてやめてしまえ！」ということなのですが（実際の語感は大分違います。念のため）その根拠として「品質向上には垂直統合が効果的」という話をしていたのがとても興味深い。

垂直統合については製造業まわりではよく議論された話題だと思いますが、現状の低品質なソフト開発体制で水平分散などというのは時期尚早と言えるのかもしれません。

会場で、オフショアを経験した人に成功した例を聞きましたが、現地の教育も含めた質がその鍵のようにうかがえました。ただ外に出せばいいというものではない。また、スケールメリットというのも大きく、50名ぐらいの規模を下回ると採算がとれないのではないかという話も。

ちなみに、会場でのオフショア事例を経験されている方は7割ほど、そのうちオフショアの成功事例を経験されている方は2名ほどでした。いかにオフショア開発を成功させるのが難しいか物語っているように思えます。

教育にはペアプログラミングを活用しよう

XP(エクストリームプログラミング)が注目された2000年前後にその概念が広まったペアプログラミングですが、教育的効果が高いということはよく知られているのではないでしょうか。私も実践経験から、教育手法としては非常に優秀だと捉えています。

ベテラン - 新人というペアの他に、カテゴリ違いの人材をペアにするというアイデアを紹介していました。これは面白いアイデアだと思いました。

ゲーム業界での事例

こうした方法論の実践事例はゲーム業界にあるとのことです。この手法をSI業界に持ち込む。それがITゼネコンの体質改善のひとつの方策となるかもしれません。

またこの実践事例より、問題点として以下のことが挙げられていました。

コードがメンテナンスし辛い
テストが不十分

このうち、コードのメンテナンス性についてはペアプログラミングで対処できるのではないかと提案していました。テストに関しては極力ユニットテストを書かずに品質を確保する方法 - ひがやすをblog の手法を考察されているようでした。テストに関しては多く議論が交わされていましたね。

Javaに恋するスクリプト

凪瀬 — Mon, 28 Apr 2008 14:01:00 GMT

元ネタは「怠慢はプログラマの美徳」というけれどというエントリ。

スクリプト言語はJavaに恋している

スクリプト言語はJavaに恋をしているのです。寝ても覚めてもJava、Javaと騒ぎ立てます。 PHPもPythonもRubyも、いつもJavaとの比較を行います。 XXのシステムはPHPだとか執拗にJavaを意識します。君たちはそんなにJavaが好きなのかい？

JavaはXXでよくないからスクリプト言語であるXXを使いなさい、というプロパガンダ記事をよく見かけます。対して、こういう理由でJavaを使うべきだ、というプロパガンダ記事は随分と少なくなりました。

つうかね、Java がほんとに使いやすくなったら、スクリプト言語なんてイチコロなんだよ。今、スクリプト言語に人気があるのとは対照的に Java に元気がないのは、Java 自身の失態がいちばんの原因だよ、ほんと。

まるで好きな女の子に相手にされなくて強がって陰口を叩いているかのようです。 Javaはたしかに融通がきかないところもある。変数を扱うたびに型、型、型。きっちりとしたその性格はキャリアウーマンのごとく。

対してスクリプト言語は少年のごとく。型なんて面倒なものいらねぇよ。とにかく作ってみようぜ！

でも、そんなスクリプト言語の憧れの的はやはりJavaなのです。 Javaに対して「俺たちの魅力」をアピールしている。 Javaはすでに確たる地位を手にしているので、わざわざプロパガンダしてまで交際を申し込む必要はないのです。黙っていても富豪令嬢のようなJavaには言いよる相手ばかりなのですから。

Javaはもう、シェアを奪いに行く立場ではなくなってしまった。シェアを取ろうと躍起になる「元気さ」は確かにないかもしれません。

怠慢はプログラマの美徳

Java 屋とスクリプト言語屋の間には、「めんどくさい」と感じるセンスについて超えられない壁が存在している。

本質的でない事柄に関する記述があったときに、スクリプト言語屋は「めんどくさい」と感じ、Java 屋はそれを感じないか、または「これは必要な冗長性だ」と本気で思い込んでいる。

ここで重要なのは「本質的でない事柄に関する記述」とは何かという点です。 Java屋が言う「必要な冗長性」がスクリプト言語屋の前提の下では無意味で面倒くさいものである、というのが実態でしょう。

スクリプト言語というのはフットワークの軽さが売りで、ちょっとしたアイデアをすぐに形にするには都合がよい。反面、刹那的な代物で、保守性に乏しく、巨大で複雑なシステムを構築する言語としては適さない代物です。世の中もそれが分っていて、スクリプトに都合のよい仕事はスクリプトで行うし、重厚長大なシステムはJavaなどの巨大建築向けに設計された静的言語を用いるのが通例です。

これらの適用箇所の違いは、さまざまな前提の違いを生み出します。小規模なソースコードではデメリットにならないことが、大規模になると無視できなくなったりするわけです。

その点を隠してスクリプト言語はいいよ！というのはプロパガンダか、無知かのいずれかでしょう。

怠惰のセンス

さて、前置きが長くなりましたが、スクリプト屋とJava屋の怠惰のセンスの違いについて見てきましょう。あらかじめ断わっておきますが、壁ではなく方向性の違いなのです。どちらかが優れているというものではありません。

スクリプト言語は手軽さを売りにしています。手軽であることが正義という世界ですから、怠惰の方向性もまた、記述の手軽さといった方向に向かいます。

そのため型推論を好みます。プロトタイプベースのオブジェクト指向を好みます。勢いで作って、さくさく動かすことを掲げ、その障壁となるものを排除するように怠惰であろうとします。

IDEなど使いません。高機能な統合IDEは起動に時間がかかります。ちょっとしたソースを書くのにそんなものを使ってられない。ちょっとしたテキストエディタにシンタックスハイライトの機能があれば十分。デバッグは動かしながらやればいいのです。まずは動かすまでが楽であること。それがスクリプト屋の怠惰のセンスです。

Java屋は堅牢さを重視します。何千というクラスを取りまとめ、何十万行というソースを統括し、基幹システムとして鎮座する機能を作り上げる使命を背負っているからです。

Java屋の怠惰のセンスは重厚長大なシステムを設計・製造・運用・保守していくための怠惰です。静的な強い型付けを好みます。変数を扱うたびに型、型、型。しかし、そうすることでコンパイルの段階で、システムを動かすまでもなくバグを取り除けるのです。 Java屋の望む怠惰はそういう怠惰です。そしてそのための面倒は大事の前の小事にすぎないと考えます。

「Write once, run anywhere」という合言葉はJava屋の怠惰の一端を表しています。

高機能なIDEを日常的に使います。テキストエディタでプログラムなんて書く気も起きません。 EmacsでJavaを書いてはいけないとEmacsの開発をしたジェームス・ゴスリン氏が語っているぐらい（彼はJavaの生みの親でもある）。起動時間が長い？朝にIDEを起動して一日中使うのだからなんら気になりません。

Java6でスクリプト呼び出しができるようになった理由

Javaのような静的言語とスクリプト言語は、そもそもターゲットが違っているのです。 Javaに恋してJavaの領分をスクリプト言語で行おうとする人もいることでしょう。でも、うまくいっていますか？もはやJavaは空気のように当たり前に基幹システム使われています。スクリプト言語がそれを置き換える日はこないことでしょう。

逆にJavaがスクリプト言語の代わりになるのであれば、そもそもスクリプト言語が生まれ来ることもない。「つうかね、Java がほんとに使いやすくなったら、スクリプト言語なんてイチコロなんだよ。」というのは、スクリプト言語の領分をJavaで代替えできるならという話。そう、Javaはスクリプト言語の代わりにならない。逆にスクリプト言語もJavaの代わりにならない。

そこで適材適所たるこれらを連携する機能性を、ということでJava6.0から追加になったのが javax.scriptパッケージなわけです。

Javaに恋するスクリプト言語には、JRubyやJythonといったようにJavaVM上で動くように Javaのバイトコードを書き出すようなアプローチを試みたものもあります。

それとはまた違った方法で、Javaとスクリプト言語はうまくその長所を生かせる土台ができてきたということなのです。

果たしてスクリプト言語のアプローチはJavaに届いたかのように見えます。この先、その仲がうまくいくのかどうかは注目していきたいところですね。

システム開発が資本力で効率化できない理由

凪瀬 — Sun, 20 Apr 2008 21:19:00 GMT

「ひがやすを BOF ITゼネコンをぶっつぶせ」に期待にて

技術力のあるところがプロジェクトを統括すれば、安く、早く、良いものを作ることができる。これは、技術を売り物に独立起業している人間であれば多くが「うちにやらせてくれるなら出来る」と言うことでしょう。この点はさしたる問題ではない。

などと言ったわけなのですが…。この点、IT業界特有のものでしょう。

IT業界には設備がいらない

IT業界特有、というのはシステム開発において「設備」というものが重視されない点です。

自動車整備工の人が、自宅の方が設備がよいので自宅で作業したいと言うでしょうか？

医師の人が、自宅の方が設備が良いので自宅で手術した方がいいのにと言うでしょうか？

しかしプログラマは「家のマシンの方が性能いいし、モニタもでかいし、本もあるし、ネットも速いし、家でプログラム書く方がいいよね」と言う人が多い。

マシンが必要といっても、たかだか数十万で済む話なのです。個人の事業者では手が出ないような設備は必要としない。だからこそ自宅の方が環境が良いなんてことがおこるし、個人で独立することが容易な業界でもある。

大資本が生き残るために選んだことは

車の製造のようなことでは、個人で太刀打ちすることはできません。資本がなければ設計することも試作することもテストすることもままならない。

しかし、IT業界は設備がいくらよかろうとも、優れた技術者を確保できなければデスマーチになりますし、設備が貧弱だろうが優れた技術者であればものを作ってしまうこともある。いや、環境が貧弱でもいいって言うわけではないのですけどね。

工場のような、資本を投じることで生産性、収益性を得るという戦略が効かない業界なのですね。それぐらいに技術者への属人性の高い業界とも言えましょう。

そうなると、大資本ならではの高収益体制をどうやって作るか。

システム開発は金額のかかるものです。100億とか1000億とかいうプロジェクトもあるわけです。そして、その金額の取引をするには資本的な信用がいる。

この信用に対して金を取る、これこそが大資本がその資本を活かして高収益を得るための唯一無二の方法なのです。

メインフレームとかスーパーコンピュータとかハードの絡むことは単純に資本がないと取り扱えないですから資本を使った仕事をすればいいわけですが、純粋にソフトウェアだけの開発では資本ならではのやり方というのがないのですよね…。

対応はあまりに簡単

大資本ならではの稼ぎ方というのはIT業界では資本の信用の部分ぐらいしかありません。高性能な機械を導入すれば工場が高収益になるような業界ではない。

別に資本ならではという稼ぎ方をしようというのでなければ、 ITゼネコンを倒す方法をみんなで考えようで言うところの

「ISIDだってITゼネコンじゃん」と思う方もいらっしゃるでしょう。昔は、そんなこともありましたが、最近は違います。「丸投げ禁止」「技術力という足腰を鍛える」「チームにアーキテクトをきちんと入れて全体のアーキテクチャをきちんと見させる」というのは、会社の偉い人からのメッセージです。

という当たり前のことをやればいいわけです。もっとも、こんなことはどこのSIerも言っているぐらいには誰にでもわかるようなことなのですが、そんな素朴なことを本当に実践できている会社はなかなかない。

その「当たり前のこと」というのは、投資してから価値を生むまでの期間が長く、かつ回収できるかも不安定なことです。投資するなら即効性があって還元率の高いところから資本を突っ込みたいというものです。地味に技術力を磨くなんて、面倒で不確実なことに投資をするなんてやりたくないというのが人情というもの。

地味に教育に力を入れていきましょう

そんな面倒で誰もやりたがらない「勉強」をしてきた人が技術者としては重宝されているわけですね。

「即戦力」とばかり言ってないで「教育」に力を入れた方がいいのではないでしょうか。面倒で金もかかりますが、長い目で見ればそれだけのリターンがあります。というか、業界を挙げて人を育てないと業界自体の未来が危ぶまれるのですよね…。