オープン系がメインのRationalツールにメインフレーム用のツールなんてあるの？ と思う方が多いと思います。しかし、これがびっくり、恥ずかしながら僕も今回の仕事ではじめて触ったのですが、最近のRationalはメインフレーム用のツールも充実しているのですね。
Rationalではメインフレーム用のツールを「エンタープライズ・モダナイゼーション」というカテゴリーでくくっています。
実は今まで入社以来、ホスト系はまともに触ったことがありませんでした。オープン系のOSとはまったく違った概念のOSの元、黒い画面でCOBOLとかを昔ながらの方法でゴリゴリ書いているという印象で、近寄りがたい、否、できれば近寄りたくない世界でした。プログラミングを始めた早い段階でTurbo C++という統合環境に慣れてしまった僕は、UNIXのパイプとかは大好きですが、プログラムの開発にコマンド・ベースで云々は、しんどい世界です。
まあ、実際現場ではそのような昔ながらの開発方法が行われていることも多く、それゆえに重要だとは認識されながらも、若い方からは敬遠されるという傾向があると思います。
しかし、最新のメインフレーム用Rationalツールを使うと、言語が昔ながらなのは仕方のない（ほとんど使われることはありませんが、実は最新のCOBOLではオブジェクト指向や例外処理などバリバリに対応されています）ところですが、開発環境はほぼ最新のJavaと遜色のないレベルが実現できることが分かりました。独特のエディタでゴリゴリ、プログラムとJCLを書いては直し、書いては直すという流れを、Eclipse上でのオート・コンプリート、文法チェック、ローカルでの単体テスト、デバッグというような近代的な開発に変えることができるのです。
検証してみたのは以下のツールです。オープン系でも使えるツールも同時に検証していましたが、これらはよく知られているので、今回はご紹介しません。
●Rational Developer for System z（以下、RDz）
メインフレームのCOBOLやPL/Iの開発をEclipseベースでできるツールです。COBOLはプログラムの書き方が特にカラム位置がかなりシビアな言語で、現在のRubyやPerlのようにかなりフリー・フォーマットに書ける言語に慣れているとかなりストレスがたまったりするのですが、これがコードアシストや常時働く文法チェックでかなり軽減されます。
さらに使用するデータベースやミドルウェア（CICSなど）にもよりますが、単体テストぐらいまでならローカルのCOBOLコンパイラが内蔵されていてコンパイル、テストできるので、ホストの難しい概念を知らなくてもプログラムが作成できます。ホスト側と連携したJCLの実行やテスト、デバッグなどもできます。ただし、これにはホスト側にもRDzのモジュールをインストールする必要があります。
感覚的にはメモ帳でソースを書いて、javacでコンパイル、Javaで実行の世界から、EclipseやNetBeansの世界に変わったぐらいの劇的な変化があると思います。個人的にはかなり抵抗感があったCOBOLもEclipseの環境で自己完結できるようになると、だいぶその抵抗感が和らぎました。
でも、やっぱりRDzは高いですよね。それでもメインフレームのCOBOLの開発をしなければならない方もいらっしゃると思います。
そのような方には、RDzのCOBOL Editorの部分がオープンになったCOBOL IDEがeclipse.orgから公開されています。ベータ版ですが、最新のEclipse 3.4対応版があります。昔ながらのCOBOL開発がしんどいという方はぜひ触ってみるとよいと思います。RDzも体験版がありますので、日本語かつフルスペックを体験してみたい方は体験版を申し込んでみてください。
●Rational Host Access Transformation Services V7.5
こちらは、3270や5250の画面を実行時に動的に変換してWebアプリケーションにしてしまうというものです。一般にメインフレームの資産を活用する場合、すべてオープン系で作り直すのはコストや品質上厳しいことが多いため、ビジネス・ロジック以下をサービスとして再利用するSOAの形をとることが多いと思いますが、SOAもそれなりにコストと労力がかかります。
このツールはプレゼンテーション・ロジックも含めて再利用するので、最小限の労力で既存のホスト系アプリケーションをWebアプリケーションにできます。
……とは言っても、本当に最小限の労力だと単に元々のホスト系アプリケーションがWebブラウザ上で操作でき、画面がちょっときれいになったかなという程度なので、本格的に今のWebアプリケーション並みに使い勝手をよくしようとすると、このツールでもいろいろカスタマイズが必要になります。リッチ・クライアントを使って使い勝手を上げたいといった要望がある場合は、先ほどのSOAでサービス化したほうがレイヤー分割も含めて適切かもしれません。
とはいえ、今までの黒い画面が数ステップでWebアプリケーションに変身してしまう姿は圧巻です。後は、ブラウザとHTTPのポートさえ空けておけば、操作できるようになるので、リモートからの操作にも便利です。
今回は2種類のホスト系Rationalツールを検証してみましたが、最新の開発環境だとメインフレーム・アプリケーションの開発もオープン系に近い形でできることがわかりました。いわゆる業務システムでプログラマやSEをする限りいつかはホスト系に関わることはあると思いますので、そんな時、ホスト系の開発環境にも便利なものがたくさんあることを知っているとプロジェクトで重宝されるかもしれません。
ということで、ホスト系Rationalツールの巻でした。
]]>このニュースの注目すべき点は、以下の部分です。
現地での待遇で働ける人
同じスキルを持った従業員を世界中から調達できるなら、最低価格で調達するというのは経済的には理にかなったことだと思います。そして、グローバルの単位で一物一価の法則が成り立つのでしたら、他の国の従業員も同等の価格でなければなりません。しかし、物価の異なる先進国と発展途上国では、先進国側の同じスキルを持つ従業員はその給与では生活していけません。従って、行き着く先はそのスキルで適切な給与となる国で働くということになります。
先進国と発展途上国ではそもそも生活水準が異なるのだから、そんな比較をされても困るというのが僕を始めとする発展途上国の技術者とスキルが競合している技術者でしょう。日本では言語と文化の壁があるので、まだこれほどドラスティックな変化は起こっていませんが、今後中国やASEAN諸国が言語と文化の壁を乗り越えてきたときに同様の変化が起こる可能性は否定できません。
しかし、この人材の流出を進めていくと短期的には利益の拡大化を図れると思いますが、同業他社が同様の方法を進めていくにつれ、価格低下の圧力がかかり、結果として売り上げは下がります。
さらに、この論理を進めていくと、より上流やお客様に近い場所、経営層も発展途上国の人材でよいということにもつながっていきます。つまり、全従業員がBRICsやASEANであればもっとも安くサービスや製品を提供できるわけです。
まあ、現状はそこまでではできないだろうと安全圏にいる人たちがこの政策を進めているのでしょうが、この政策の行き着く先は彼らをも巻き込むことになるのかもしれません。そのときアメリカを始めとする先進国はどうなるのでしょうね。
最後に有名な「彼らが最初共産主義者を攻撃したとき」を引用しておきます。この政策の行き着く先かもしれません。
]]>ナチ党が共産主義を攻撃したとき、私は自分が多少不安だったが、共産主義者でなかったから何もしなかった。
ついでナチ党は社会主義者を攻撃した。私は前よりも不安だったが、社会主義者ではなかったから何もしなかった。
ついで学校が、新聞が、ユダヤ人等々が攻撃された。私はずっと不安だったが、まだ何もしなかった。
ナチ党はついに教会を攻撃した。私は牧師だったから行動した―しかし、それは遅すぎた。
僕自身も昨今の経済危機に巻き込まれ、オフショア推進部門に異動したり、その後パフォーマンスが微妙ですぐ現場に戻ったが、この経済状況から仕事がなく、長らく派遣村の人々のような暮らしをしたりとごたごたしておりました。
今回はちょっとRationalから離れて、僕が去年PCを買い換えた経緯とその理由をお話したいと思います。理由は若干Rationalがらみです。
学生時代には今はなきNECのPC-98シリーズを何台か購入し、ハードウェアの改造にも力を入れていたのですが、会社に入って逆に毎日PCを触るようになるとハードウェアに対する興味は失せてしまって、長らく会社貸与のThinkPadを使用しておりました。
この会社貸与のThinkPadがとんでもなく重量があるもので、そのままカバンに入れて持ち運ぶときには大リーグボール養成ギプスなみの筋力が必要とされるものでした。一昨年、プロジェクトの関係で中国の成都に出張したのですが、このときは何とかこのThinkPadを持っていきました。
しかし、去年の9月、ちょうどオフショア推進部門（弊社ではオフショアといわず、Global Deliveryと呼んでいますが）に異動した際、僕の専門のテスト分野でオフショア先としてブラジルを検討したい、というお客様へのご提案をサポートするために、ブラジルに出張することになりました。
さすがに27時間かけて地球の裏側行くのに、大リーグボール養成ギプスは装着できません。しかし、昨今の経済事情やセキュリティの事情もあり、新たな社内PCの配布は凍結されていました。個人所有のPCの業務利用はいろいろと制限はあるのですが、これはたまらんということで許可を取り、自腹でPCを買うことにしました。股引のまま入院した前回から相変わらず、彼女いない暦＝年齢なので、小金は貯まっているのです。
そこでもう入社してから8年くらいまったく興味を持っていなかったPCのサイト、特にLenovoのサイトを見てみましたら、最近のPCの進化はすごいことになっていました。IBMはPC事業をLenovoに売却したわけですが、その関係もありLenovoの製品は一般よりちょっとだけ安く（ものによってはかなり安く）購入できるため、第1候補メーカーはLenovoとしました。実家ではVAIOを使っているので、まあ個人用なら正直どのメーカーでもいいというのもあるのですが、やはり会社でも使うものなので、HPやNECとかだとちょっと微妙ですね。
20時間以上飛行機に乗ることから、一番恐れたのはHDDが壊れてしまうことでした。それを回避するためのソリューションとしてSSD（Solid State Drive）搭載のモデルがLenovoでも登場していました。SSDはUSBメモリのようなフラッシュメモリーの不揮発記憶装置なので衝撃にも強く、かつ最近はHDDをはるかに凌駕する高速性を持っていて携帯が必須となるノートPCにとっては最適のソリューションだと思います。PC-98ノートから本格的にプログラミングを始めた僕としては、懐かしのRAM Driveやシリコン・ディスクを思い出し、胸が熱くなりました。
で、スケジュールも押し迫っていたので、購入したのは2008年9月当時SSD搭載モデルとしてLenovoのサイトにあったThinkPad X300です（今は後継のX301が販売中です）。SSD搭載モデルということ以外にLenovoがプレミアムモデルとして開発したというだけあって結構高価だったのですが、軽量性、キーボードの質感、SSDの高速性・静粛性（当たり前ですが音がしません）、全体の仕上げなど、今まで使っていた社内配布のThinkPad R52をすべての面で凌駕していました。1つ前のT61やX61を使っていたブラジルの技術者たちもX300を見て驚いていました。
……というのは嘘で、1つ困ったことがありました。重量が大幅に軽くなったのはよかったのですが、ディスプレイが13.3インチで解像度が1440×900と、ThinkPad R52の15インチ、1024×768に比べると大幅にドットピッチが小さくなり、文字が見にくくなってしまったのです。
1日中PCに向かい合っていることが多いSEにとっては、眼精疲労とそれに伴う肩こり、腰痛は職業病ともいえるものです。僕は以前これが悪化して、椎間板狭窄症というヘルニアの1歩手前の病気で3年ぐらい苦しんでいましたので、これは何とかしたいところでした。携帯用のPCとして使うにはよいですが、常用するPCではないと思いました。
とはいえ、SSDに慣れ、高解像度にも慣れてしまったので、いまさらThinkPad R52に戻ることはできません。最近のPCは画面比が16：10や16：9になっています。以前、4：3のPCをメインに使っていたときにはこのメリットがよくわからなかったのですが、いざ使い始めてみると以下のメリットがあること分かりました。
ということで、ワイドかつ大画面かつドットピッチがある程度大きいということで、2台目としてThinkPad T500を購入してしまいました。なんと、10年間もPCを買っていなかったのに、1年で2台も買ってしまいました。
15.4インチだけあってさすがに画面が大きいです。当初、値段の関係上HDDモデルを購入したのですが、やはりSSDのThinkPad X300と比較すると、HDDの分だけCPUのパフォーマンスを出せていないようでしたので、2009年に入ったらIntelの高速SSD X25-E Extremeを購入してしまいました。IntelのSSDは各所でその高速性が紹介されていますが、期待を裏切ることのない安定性と高速性を誇っていました。ただ、すでにX300でSSDを味わっていた僕はそれほど劇速とは思わなかったのですが、HDD時代と比べると雲泥の差がありますね。
で、このThinkPad T500とSSDは今後の現場の開発で活躍するために買ったのですが、最近はマネジメントや提案活動をすることが多くなり、PowerPointとExcel以外はあまり使っておらず、パフォーマンスをいまいち発揮できていない状態です。
ThinkPad X300は下宿を基点として、各種のイベントや出張用のPCとしました。家だと1日中PCに向かっているわけではないので、画面が細かくても十分実用になります。また、軽いのでベッドで寝転がりながらネットサーフィンなどもできてしまうのがよいです。
このコラムのネタとしても、このようにして購入した2台のThinkPadでRational Toolsをバリバリに使った自動テストや開発の仕事をしたいところなのですが、まずはお客様に買っていただける提案をしなければということで、提案の日々なのでありました。
そうしている間にもRationalの面白いツールが続々出てきているので、2台のThinkPadに入れていろいろと触ってみる予定です。次回はそこら辺で何かネタを出せるとよいかなと思っています。
]]>XP（eXtreme Programming）やTDD（Test Driven Development）の流行や、Ruby on Railsのようなフル・スタックのWebフレームワークが自動テスト・フレームワークを備えるようになった影響で、最近の開発者の間では自動テストという概念が普通になってきました。
以前は自動テストといった場合、開発者の間ではJUnitのようなテスティング・フレームワークを使った単体テストの自動化が中心でした。しかし、最近では機能テストの世界でもSeleniumをはじめとするオープン・ソースのツールが登場してきたことによって、画面ベースの機能テストも積極的に自動化していく動きが進んでいます。
僕がテストの研究を大学でしていた10年前では逆にJUnitは誕生したばかりで、自動テストといえば、商用の画面キャプチャー・ベースの機能テスト・ツール（以下、キャプチャー＆リプレイ・ツール）が一般的でした。
ですので、ちょっと前までの開発の経験があるが、Java時代以降ではあまり実装に関わっていないような方、あるいはもっとそれ以前の方にとって、自動テストというと画面ベースのツールだったり、逆に純粋にバッチだったりすることが多いです。
このキャプチャー＆リプレイ・ツールによる自動テストというのは、テストについて初心者であればあるほどインパクトが大きく、魅力的に見えるものです。そのために、陥る罠もたくさんあります。
今回は僕自身のプロジェクトの実体験をもって、このキャプチャー＆リプレイ・ツールを使った場合に陥りがちな自動テストの罠についてお話したいと思います。
■小錦からの無茶な要求
2年前のことですが、弊社存亡の危機とまでいわれたとあるプロジェクトがありました。このプロジェクトをリカバリーするために凄腕PMをはじめ、老若男女部署会社国籍の区別なくあらゆるメンバーが隔てなく集められました。勇者たちは総勢550名。彼らの血と汗、そしてお客様の力強い忍耐力によって最終的には無事にサービス・インできました。
当時、社内の部門でちょっと暇そうに見えたのか、はたまた自動テスト・スペシャリストの腕を買われたのか（多分これは違うと思います）分かりませんが、このプロジェクトに僕も参加することになりました。
そして、ある凄腕PMが率いるテスト・チームにて、統合テストの自動化の任務に就くことになりました。この凄腕PMがすごく怖かったのですが、それもさることながら、さらに僕の上にはオーストラリアから来た自動テストの達人なる小錦のような巨漢の自動テスト・リーダーがいました。
まず、プロジェクトの現状を調査して、各テスト・フェーズでどのようなテストがされていて、どの部分が自動化されているかを調査したところ、
単体テストが自動化されていません
恐るべきことに、まったく単体テストの自動化などを考慮しないで作られていたアーキテクチャーだったため、単体テストを自動化するのが非常に難しく、単体テストの自動化がされていなかったのです。単体テストの自動化がされていないということは、単体テストのフル・リグレッションが非常に難しいことを意味し、デグレードが発生したり、統合テスト以降で単体レベルのバグが見つかったりします。
統合レベルの機能テストの自動化が本来効果を発揮するのは、単体テストが自動化されている場合です。単体テストが自動化されていないと、統合テストのテスト・スクリプトを作っている最中でそもそもテストが失敗してしまったり、自動テストの実行の際に、単体レベルのバグが原因で失敗してしまい、本来の統合レベルのデグレードが検出できなかったりと、統合テストの自動化の意義が薄れてしまいます。
しかし、そのテスト・チームのリーダーは言いました。
「単体テストが自動化されていないことは分かっている。システムの品質も悪いことは分かっている。しかし、自動化して欲しい」
■自動テスト、4つの罠
●罠1 単体テストの自動化をしていないプロジェクトほど、自動テストについてまったく分かっていないため、それ以降のテストを自動化して挽回しようとする。
さらに日本語が分からず、プロジェクトの状況もよく分かっていない（まあ、英語のレベルがしょぼくて伝えられていない僕も問題なのですが）小錦から、恐るべき発言が飛び出しました。
"In my experience, all test scenarios should be automated. And we can."
いや、その、無理だろう……。このお客様のシステムは日本に1つしかない業務で、業務自体も恐ろしく難しく、アプリケーションとツールとのマッチングも去ることながら、まず業務フローとテスト・ケース自体を理解することが非常に困難だったのです。このような状況ですべてのテスト・シナリオを自動化することなど、Kent Beckでも無理でしょう。しかも、恐るべきことに、この発言が出たときに自動テストを設計・実装するメンバーは僕ただ1人だったのです。総勢550人ものメンバーがいるというのに。
●罠2 対象システムの難しさを知っていない人間ほど、とんでも発言をする。たとえ、自動テストの経験が長く、ツールに造詣が深くても、とんでも発言をする場合がある。
とはいえ、このプロジェクトで仕事を断ったら首になるという雰囲気ですので、不可能でも可能にするしかありません。いつかのツールを検討し、まあ、実際選択肢はなかったのですが、使用することになったのが、Rational Functional Tester（以下RFT）というRationalのキャプチャー＆リプレイ・ツールです。RFTの名誉のために言っておくと、僕はRFTをはじめ複数のキャプチャー＆リプレイ・ツールを使ったことがありますが、ほかのツールと比べても遜色なく、スクリプト自体がJavaもしくはVisual Basic .NETで記述できるため、独自スクリプト言語が多いほかのテスト・ツールと比べてもスクリプトが作成しやすいです。
ただし、それでも本来、テスト・ツール（特にキャプチャー＆リプレイ・ツール）には得手不得手と対象アプリケーションに対するフィット＆ギャップがあり、機能テストのテスト自動化を実施する場合、最初からアプリケーション側も自動テスト・ツールを考慮してコーディング標準などを定める必要があります。特に最近のAjaxをはじめとするRIAについては、ツールによってサポート範囲が大きく異なるので注意する必要があります。
案の定、このアプリケーションもRFTを使うことなどまったく考慮されず作られておりましたので、アプリケーション上のボタンやリンクを正しく認識させるのに工夫が要りました。このようなアプリケーションと自動テスト・ツールのフィット＆ギャップの調査はツール両立性検証と呼び、本来パイロットの開始前に実施しておくべきものです。
パイロットの初期段階であるサブ・システムの中でも正常フローで最も簡単なシナリオをようやく自動化し、デモを見せてみたところ、以下のようにリーダーから返ってきました。
「何だ、できるじゃないか。じゃあ、バンバン作り始めてくれ」
しかし、ここでサブ・システムのベテラン・アーキテクトから別途注文が来ました。
「画面ベースの比較では不十分なので、実行結果のテーブルの突合せをして欲しい」
比較するテーブル数とカラム数はとんでもなく多く（本当に正規化されているのか不明ですが、なぜか列が256行を超えているテーブルがたくさんありました）、とてもRFTからデータベースのGUIツールを呼んで比較できる量ではありません。
●罠3 現場から使用する自動テスト・ツールとアンマッチングな要望があがってくる可能性が高い。
状況をよく分かっていない小錦が
"Use data pool. You can do with data pool."
とか言ってきます。データ・プールとはRFTの機能の1つで、データ駆動型のテストを実現するものですが、ここでのテーブルの比較の要件にはアンマッチングです。これを説明するのも大変だったのですが、ベテラン・アーキテクトとつめて、ツールを自作し、組み込むことにしました。
ベテラン・アーキテクトから自動化の範囲をお聞きし、業務チームの方々、そして小錦と方針を決め、テスト自動化の範囲とスケジュールが決定しました。
とても僕1人では無理でした。さすが凄腕PMだけあって、すぐさま開発メンバーを調達してきました。Javaの開発経験のある協力会社さんの若手3名でした。
その若手3名、さらには厳しいスケジュールの中、業務チームで自動テストに興味を持って協力してくださる勇者の方々3名と一緒に自動テストのプロジェクトが始まったのですが……。
プロジェクト自体の雰囲気が非常にピリピリしていたこと、凄腕PMと小錦からのプレッシャー、実質ほとんど分煙されていないといってもよかったプロジェクト・ルームの劣悪な空調環境、疲労困憊して下宿の部屋の掃除もほとんどしていなかったことなど、悪条件が重なり、それまで少しずつ症状は出ていたのですが、ある朝「それ」はマックスに達しました。喘息です。急性喘息の発作が起こり、プロジェクト・ルームへ行けなくなってしまったのです。午後、症状が治まったら病院に行く予定だったのですが、一向に症状は治まらず、立ち上がって動くことさえできません。夜にはついに呼吸困難に陥り、救急車を呼んで緊急入院という最悪の事態となりました。
「IT業界の恐るべき実態：彼女いない暦＝年齢（30歳） 喘息の発作で股引を履きながら壮絶なる孤独死！」などと、「SPA！」や「アエラ」で特集されてしまいそうな悲しいスペックです。こんなので死んだら間違いなく成仏できません。というか、こんな状態で死んだら笑いものです。……ですので、死にませんでした。
あと3分遅れていたらチアノーゼを起こして危なかったという状況だったのですが、1週間の入院と、その後の1週間の自宅療養の末にカムバックすると、「大丈夫でしたか？」の挨拶も早々に、テスト自動化に戻りました。
戻ってきて、若手3名と共にぶつかった最初の困難が、業務チームへの仕様確認です。自動テストがお客様に報告するWBSには見えない裏タスクだったことから、ただでさえ激務な業務チームの方々からはなかなか協力が得られず、テスト・スクリプトの前にテスト・ケースの理解と妥当性確認のために多くの時間がとられました。
●罠4 統合テスト以降の自動テストの成功にはトップとボトムの両方の協力が必要だが、プロジェクトの後半から始めるとその協力が得られない場合が多い。
僕はかなり人との交渉が苦手なたちだったので、これが手こずり、かといって若手3人に任せるわけにもいかずと、進捗は芳しくなくと、再び凄腕PMと小錦の逆鱗に触れてしまいました。しかし、そこはさすが凄腕PM。人のマネジメントが得意な協力会社さんリーダーを僕の補佐としてつけてくれました。やはり、その方は長年の経験もあって、コミュニケーションの経路の作り方が優れており、業務チームとの協力関係をスムーズにしてくれました。
協力会社さんリーダーの参加によってパイロットも回し終え、ようやく本開発において自動テスト・チームも流れに乗ってきました。うまい具合にスクリプトを作れるようになってきました。
しかし、それはなんとサービス・イン直前で、残念ながら成果が出るのがあまりに遅かったため、テスト自動化はそれ以上の拡大をせず、駄目開発者の烙印を押された僕はサービス・インとともにプロジェクトを離脱、テスト自動化は一部別のメンバーに引き継いで、細々と自動化したシナリオをリグレッションするにとどまりました。
ただしサービス・インの前日、非常に重要な業務でのリグレッションの際に、自動テストがデグレードを発見して大活躍したので、入院したまでの苦労は多少報われたのかなと思います。
■自動テスト成功の鍵は「人と組織」「プロセス」「業務知識」
長くなりましたが、これが僕の実体験に基づく自動テストの罠です。罠からは逆に教訓が得られます。
教訓は以下のとおりです。
以上、自動テストの成功はほとんどツール自体の能力とは関係なく、人と組織、プロセス、業務知識なのでした。あれ、RFTほとんど関係なかったですね。上記5つの教訓を抑えていれば、実はツール単体で見た場合、どのツールを使ってもほとんど変わりがなかったりします。
ツールの差異が出てくるのはRIAへの対応や他のツールとの統合だったりするわけですが、その部分では各社のツールには様々な差異がありますので、パイロットの前のツールの両立性検証のフェーズで検証することになります。他のRationalツールとの統合におけるRFTの優位点はまた別の機会にて。
]]>Javaの案件だと大抵コード・インスペクション・ツール（静的テスト・テスト・ツールとも）としてCheckstyleとFindBugsをセットで使用することを義務付けていることが多いと思います。
これらのコード・インスペクション・ツールはルールの選択が難しくて、うっかりデフォルトの設定で使った日にはあまりのルール違反の指摘の多さに「ウゼー」と感じて、「狼と少年」状態になっていつのまにかオフにされていたとかいうことになりかねません。というか、僕もまことに申し訳ないことに、そういうことをしていた時期がありました。
でも、仮にもテストの専門家としてプロジェクトに参加することが多い僕がそのようなことをしていると、ほかの開発メンバーにとって示しがつかないだけでなく、お客様への背信行為となってしまいます。ですので、今はまず、ルールの策定段階から自分も関わるようにしています。そして、そのルールの策定では開発効率は落とさないが、しかし、潜在的なバグは事前に可能な限り自動的に除去できるようなルール選びがポイントになります。
同時にもうちょっとマニアック……じゃなくて、定量的な品質測定を考慮したプロジェクトですと、JDependのようなメトリックス・ツールを併用していることもあるかと思います。
サイクロマチック数のようなよく知られているメトリックスであっても、プロジェクトで実用的に活用するのはなかなか難しいです。僕がこれまで参加したプロジェクトでも、あくまで参考程度に使用していることがほとんどで、効果的に活用できているという事例には遭遇したことがありません。
冒頭の「面白いRationalツール」とは、このコード・インスペクション・ツールとメトリックス・ツールがセットになったRational Software Analyzerという静的解析ツールです。
これのどこが面白いのかというと、僕もほかの方からお勧めされるまでは単なるコード・インスペクション・ツールなのだろう、フリーで十分ではないかと思っていたのですが、面白いのはコード・インスペクションの部分ではなく、メトリックスの部分なのです。
というかですね、提供されているメトリックスがマニアックすぎて、見方が分からなかったりします……。不勉強なのか、半分以上分からないメトリックスでその値が何を示しているのか分からないのです。これでも一応、情報工学専攻のソフトウェア工学研究室出身です。
そのようなものをお金出して買う価値があるのかということですが、ある意味ソフトウェア工学に対して不勉強なエンジニアに対する挑戦といえましょう。Rational Software Analyzerの出してくるメトリックスも分からないようでは、真のソフトウェア・エンジニアとはいえないのです！ ああ、でもマニュアルを見てもメトリックスの説明が書いてないのだけど……。もうちょっとマニュアル充実して……。せめて推奨値ぐらい書いてよ……。あ、これ自社製品だった……。
さらにもうひとつ、クラス間の関係からアーキテクチャの良し悪しを計ったり、使われているデザイン・パターンを抽出したりするJavaアーキテクチュアル・ディスカバリーなる機能もあります。これまた不勉強ながら知らないデザイン・パターンとアンチ・パターンがてんこ盛りです。勉強しろよって感じですが。
それはさておき、実際にどんなものかと使ってみました。さすが過去に参加したプロジェクトのソースコードなどを使うわけにはいかないので、ここはオープンソースの定番で、僕も3.8時代にコードを全部読んだことがあるJUnitの4.5を被験者としました。
・・・
・・・
・・・
例
ルール
Assert.java: 623 String.equals("")を呼び出して、文字列の長さを検査しない
コード
if (message != null && !message.equals(""))
推奨コード
if (message != null && message.length() != 0)
著名なオープンソースであるJUnit4のコミッターをしてこのようなコードを書いているのかとちょっと安心した（笑）。
あ、いや、修正前のコードは別に間違いではないではないのですが、パフォーマンスを厳密に考慮する場合、修正後のコードの方が良いよねということです。
こんな感じで、コード・インスペクションについては単体テストで見つかるバグというよりは、どちらかというと潜在的に問題になりそうなコードを指摘してくれるルールが多いです。CheckStyleとFindBugsでも同じですが、ルールを全オンにしたりするとあまりに指摘が多すぎて厳しいので、ルールはプロジェクトに応じて絞り込んだ方が良いです。運用についても、常時オンというよりはEclipse内だけでなく、ビルド時にも組み込めたりするので、1日1回とかコミット前とかそういうタイミングで潜在エラーの可能性を見るために使うというのがよいと思います。
メトリックスについては、かろうじて理解できたのは複雑度メトリックスである循環的複雑度（つまりサイクロマチック数）ですが、閾値の6を越えているのはわずか6クラスと非常にシンプルに作られていることが分かります。かつて某金融機関システムのコードで、6000行のメソッドで8重ループの、ある意味「神」なコードを見たことがありますが、そのような破壊力を持つコードはJUnit 4.5には存在しないのです。というか、そんなコードは仕事以外では絶対読みたくありません。仕事でも読むのはしんどいです。
ただし、JUnit 4になってからの各種の機能追加によるものか、アーキテクチュアル・ディスカバリーを見てみると微妙に構造レベルのアンチ・パターンが存在していたりします。さすがに恐れ多くもJUnitなので、コンポーネント間の循環参照（Component Cyclic Dependency）は起こしていませんが、単なる中継だけのクラスと化しているような微妙なクラスもちらほらあります。メトリックスはあくまで指標なのであえてパターンを破っていたり、あえてアンチ・パターンを実装していたりすることもありますが、そこら辺はバランス感覚でしょう。
そんなわけで、微妙に使いこなすのは難しかったりするRational Software Analyzerですが、メトリックス好きやオブジェクト指向のパターン、アーキテクチャとは何であるかとか日夜悩んでいる方には熱いツールだと思うので、ぜひ一度、体験版を入手して（あ、また最後に宣伝）、自分で書いたソフトウェアやらオープンソースのフレームワーク、はたまた許可が下りるなら現在参加されているプロジェクトのソースコードに対して実行してみてください。
完璧にメトリックスを使いこなせて、プロジェクトで指標として使えるようになれば百人力だと思います。奥義を極めるためには論文も含めたメトリックス本と格闘ということになる奥深いツールだと思います。
ボーナスで買ってやるぜという漢気あふれる方がいらっしゃいましたら、ぜひ個別にご連絡ください。割引……はできないと思いますが、冬休みにでも濃い勉強会をご一緒にしましょう。
]]>従来、RUP（Rational Unified Process）は反復型の開発プロセスでありながらも重量級といわれ、重いプロセスの代表とされていました。Rational自身は「RUPはアジャイルだ」と述べていたのですが、ほかのアジャイル型プロセスに比べると個人的にはやはり「重たい」と感じてしまうものでした。
しかし、最近のRationalはツールもプロセスも本当の意味でアジャイルを目指しており、整理し直し始めています。Rationalの目指すアジャイルとは、従来の少人数のアジャイル開発を発展させたエンタープライズ・アジャイルと呼ばれるものです。エンタープライズ・アジャイルでは100人以上の開発メンバーや遠隔地での開発もアジャイルの対象にして、そのような開発でもアジャイルが実現できるようプロセスとツールを整備していこうというものです。
RUP自体は他のアジャイル開発方法論に習い、プラクティスという側面から整理し直されて、開発形態に応じてカスタマイズをするのが容易になっています。
RUPの改良も面白いのですが、やはり開発ツール好きの人間として面白いのはJazzプラットフォームに基づいて開発が進んでいるツール群ですね。 チームのコミュニケーションを極限まで促進させるためのRational Team Concertや、要求収集に役立つRational Requirements Composer、単なるテスト管理を超えた品質管理を可能とするRational Quality Managerなど、従来のRationalツールのサポートが十分ではなくWordやExcelでかんばっていた部分を補完するツールがJazzプラットフォームに基づいて続々登場しています。
上記の部分は従来ではWordやExcelで管理していることが多く、転記の作業が多かったり、はたまた個人で管理しているためにバージョンの先祖返りが起きたりと、システム開発の本質でないところで悩まされたりして、ムダだなあと思うことが多々ありました。上記のツールを新たなRUPと組み合わせ、使いこなすことによって、本質的でない作業を最小化すると同時に、コミュニケーションを最大化してシステム開発で本当に必要な作業に専念できる環境が整ってくるのではないかと思っています。
残念ながら、最近の受託開発の現場では、後藤さんのコラム「下流から見たIT業界 SEとPG、どっちが頭がいい？（1）」でも述べられているように技術者、特にプログラマが軽んじられる傾向がありますが、社内プログラマの経験が長いわたしとしては、良い傾向ではないと思っています。
プログラミングを単純労働として考え、低コストのプログラマの数だけを増やして開発を進めようとする海外オフショアなど、その最たるものといえます（海外オフショア開発がすべてこのようなものというわけではありませんが、建前はともかく実態はそうなっていることが多いです）。
プログラミングは単純作業ではないので、数だけ増やして水平クラスターなど出来はしません。水平クラスターをするためには、その前の段階で膨大なコストがかかり、その部分がコスト高になってしまい水平クラスターの効果を相殺、下手をすればコスト高になってしまいます。そうではなく、海外も含めて真のプロフェッショナルのプログラマ達のコミュニケーションを促進し、少数精鋭で開発を進めるべきです。
Rationalの進めているエンタープライズ・アジャイルの中では、プログラマは独立した専門職であり、テスト担当者や構成管理担当者についても同じです。どの専門が上でどの専門が下とかはありません。そしてプロセスとツールは彼らのコミュニケーションを促進し、彼らの専門性と能力を極限まで上げるために存在しています。
プログラマを始めとする技術者の方はぜひ高度なプログラミング能力に磨きをかけるとともに、Rationalを始めとするプロセスとツール、そしてシステム開発での経験から得た業務知識を武器に、自他共に認められるプロフェッショナルを目指して欲しいなと思います。
ということで、また宣伝になってしまいますが、もうすぐで体験版が出てくると思いますので、ぜひ体験版を触ってみてください。私も社内のサイトで一部のツールをダウンロードして試していますが、本当に面白いです。製品単体のすごさだけでなく「ああ、こういう部分がほかのツールと連携できるとうれしかったんだよね」という部分が非常によく出来ていると思います。私自身も現場に積極的に導入していきたいと思いますので、皆様もぜひ使ってみてください。
次回は開発プロセスの意義について書いてみたいと思います。
]]>初めまして、本コラムを担当させていただきます日本IBMの太田健一郎と申します。
本コラムではIBM Rationalが提唱し、お客様に提供している開発プロセスやツールの有用性を実際の開発現場のSEが実体験に基づき建前ではなく、本音で語ってみたいと思います。
わたしたち開発者にとって、Rationalの開発プロセスやツールはIBMがお客様に販売しているほかの製品と大きく異なることが1つあります。それは、Rationalの製品がお客様のターゲットとして、主に（注1）開発者を対象にした開発者のための製品であり、自社の現場のSEたちも使用する製品であり、その意味SEとしてはもっともお客様に近い視点で接することのできる製品だということです。つまり、わたしたち自身がプロジェクトで活用し、その有用性を実証することができれば、営業やプリセールスSEのメンバーだけでなく、我々自身も自信を持ってお客様に製品をお勧めすることができるということです（注2）。
（注1） IBM Rational Portfolio Managerを始めとして、経営者や組織を横断したManagerを対象にした製品も存在します。
（注2） WebSphereブランドやLotusブランド、Tivoliブランドの製品開発には実際に各種のRational製品を利用しており、社内でも有用性が実証されている製品群です。
と、何か、いきなり宣伝っぽくなってしまいました。わたしはもちろんお客様にはRationalブランドの製品を買っていただき、ソフトフェア開発の効率化、高品質化を目指していただきたいと本気で願っている人間ですが、Rationalブランドの人間ではありませんし、決して営業トークでこのようなことを書いているわけではありません（注3）。
（注3） 別に営業の方がお客様のニーズを発掘していなかったり、実体験に基づいていなかったりなどと言うつもりは毛頭ありません。
わたしはRationalがIBMに買収される前からのRationalユーザーであり、Rationalの開発プロセスやツール群、特にRUP（Rational Unified Process）、正確にはその前身であるOOSE（Object-Oriented Software Engineering）によってこの世界に踏み込んだ人間といってもよいので、わたし自身の実体験からRational製品の有用性をお話したいのです。
前置きが長くなりましたが、今回はそのRationalとの出会いを書いてみたいと思います。長くなりますので、前編と後編に分けてお話したいと思います。
2. プログラムってどう書くの？
わたしが本格的にコンピュータに興味を持ったのは、高校時代でRPG（Role Playing Game）が好きだったのと、家に父親が持っていたPC-8801やPC-9801 noteがあったので不遜にもRPGを自分で作ってみたくなったというのが理由です。
といってもいきなりゲームを作ったりするのは無理だということがコンピュータを触り始めてすぐに分かりました。しばらくはN88-BASICのリファレンス・マニュアルをROM版のN88-BASIC（86）にひたすら打ち込んではちょっと変更ということをして遊んでいました。
BASICの入門本を買ってみると、アルゴリズムなるものが世の中にはあって、どうやら数学の解法のようなものらしい、問題に応じてこれを使い分けて、プログラムを作っていくのだということがなんとなくわかってきました。
そして、高校3年生の時に2年間アルバイトをして貯めたお金で、PC-9821XsというNECのPCを購入し、ようやくカラー環境（これまではお下がりのPC-9801NSとPC-8801mkIIを使い分けていました）で、今度は無謀にもBorland Turbo C++を購入し、C言語に挑戦して、これまたC言語の入門本とにらめっこしながら学んでいきました。
大学の学科も実に不純な動機でゲームを作りまくれる学科があるなど全く間違った思い込みの元、情報学科というものに入学しました。
まあ、待っていたのは思っていたのとは全く違った世界でしんどい情報数学の世界だったのですが、それはさておき、一応、学科でもプログラミングの演習はありました。自習と大学の演習の両方で、それなりにプログラムが書けるようになってきたと思ったので、冬至愛読していたマイコンBASICマガジンの投稿プログラムのソースコード（注4）を打ち込んでみようと決意しました。
（注4） 当時はソースコードが投稿プログラムとして掲載されていました。このころともう少し前の時代のパソコン雑誌では普通だったと思います
3. どうやったら要求から実装につなげられるの？
そこでつまずいてしまったのです。ソースコードが載っているページには同時にゲームの概要が載っていて、そのゲームがどの様なものなのかということが書かれているのですが、その概要とソースコードがどの様に結びついているのか、はたまた作者がどの様な思考過程を経てこのソースコードにたどり着いたのか全くわからなかったのです。どうも、投稿雑誌だったということもありますが、演習のようなものではない本格的なプログラムというのは一部の特殊な才能を持った人たちしか書けないのではないか、やっぱり自分が感動したようなRPGを作るゲーム・クリエーターになる（注5）のは無理のようだと挫折感にさいなまれました。
（注5） 無謀にもまだ思っていました
その時は、ソースコード自体は何とか打ち込むことができたのですが、ソースコードの意図がよく分からなかったので、間違えたときにデバッグするのが非常に大変でした。そのため、ソースコードを見て打ち込むと言うのは何度かやってみたもののしんどくなってきてしまってやめてしまいました。
そこで思ったのはどうも、ゲームの概要とソースコードの間には何か大きなギャップがあって、それが一人でゲームを作ろうと思ってもできない原因ではないか（注6）と思うようになりました。
（注6） 実は才能がないというのも大きかったのですが
演習やプログラミングの入門書に出てくるような簡単な例題だったらアルゴリズムさえ知っていれば思いつきで何とかできるのですが、どうも作ろうとするものがある程度の大きさになるとそのような思いつき駆動ではプログラムを書くことができないということが分かりました。
4. 古典的な方法を知る
そんなこんなでどうもゲーム作りには程遠いと言う状態だったある日、ソフトウェア工学なる授業があって、そこでフローチャートとPAD（注7）というものに出会いました。
なるほど、いきなり問題（注8）をプログラムにするのではなく、このようなダイアグラムを使って整理すればプログラムを書けるようになるのか、これがソフトウェア工学なのか！ゲームは天才だけが作れるものじゃなくて凡人でも作れる方法があったのか！ソフトウェア工学素晴らしいとか一部間違った認識を持ちながら、ダイアグラムとソフトウェア工学というものを知りました。
（注7） 日立の標準として使われていた構造化設計用のダイアグラム
（注8） そのころは要求や要件なる言葉も知りませんでした
それで、一時、goto文を許してしまうフローチャートはどうも好きになれなかったので、基本的にgoto文を許さないPADにはまってなんでもかんでもPADにしてプログラムを書くと言うことをしていました。
そのころのメインに使っていたプログラミング言語はCだったのですが、コンパイラはTurbo C++だったので、どうもC++というのはCよりすごいらしいとTurbo C++のマニュアルを見ながら思ったので、これまた無謀にもC++に挑戦してみました。
5. オブジェクト指向でプログラムが書けない
ところが、PADにはまりすぎたのでしょうか、BASICの期間が長すぎたのでしょうか、どうもオブジェクト指向なるものが理解できません。Turbo C++のマニュアルにはC++のライブラリの説明は載っていても、オブジェクト指向でのプログラムの作り方は載っていませんでした。これまたどうやって、問題をオブジェクト指向のクラスに落としていくのか、そして動くプログラムにしていくのかさっぱりわからず、結局関数とメインでできた構造化設計で問題を片付けていたのです。
6. OOSE（Object-oriented software engineering）と出会う
そのころは大学の情報数学の授業についていくのが厳しい状況で、予習と復習のために自習室にこもって勉強していました。自習室の隣には図書館があって自習がしんどくなってくると、そこでPC関係とプログラミング関係の雑誌を読んでいました。同時にプログラミングや設計の本も探しては借りて読むということをしていました。学生でしたのでそう何冊も高い専門書は買えなかったのです。
その中で、ようやくたどり着いたのが、オブジェクト指向方法論なるカテゴリでした。どうも、Booch法とOMT法なるものがすごいらしいということが分かり、無謀にもチャレンジしてみるのですが、どうも最初の問題（要求）からフローチャートでいうところの設計に落とすところにギャップがあって、わたしにはどうもこれらだけではやはりうまく現実の問題をプログラムまで落とすことができませんでした（注9）。
（注9） ただし、Booch法もOMT法もそれぞれRUPの前身であり、RUPに取り入れられた有用な部分はたくさんあります。当時のわたしが最も求めていた部分に対する解決策が弱かったというだけです。
そこで、最後にようやく見つけたのが、OOSE（Object-oriented software engineering）こと「オブジェクト指向ソフトウェア工学」です。OOSEでは現在のRUPやUMLでも採用しているユースケースとユースケース図によって機能要求を表します。ようやく、要求を表す方法が分かりました。そして、ユースケースごとにクラスをBoundary、Control、Entityのステレオタイプごとに抽出して、最後に各ユースケースを実現するクラスを合成していき、分析段階のクラスを完成させるという現在のRUPでも採用している要求と分析のプロセス（注10）が例題を交えて分かりやすく解説してありました。それまで読んだオブジェクト指向方法論では、自分の読解不足からでしょうか、どうも、クラスやデータモデルがインスピレーションをもって天から降ってくるような書き方がされていて、例によって、「天才でない自分にはやはり無理なのか」というマイナス思考にさいなまれていました。読んでも凹むばかりでした。しかし、OOSEは、これなら、自分でもできる。やってみよう。オブジェクト指向はやはり素晴らしい！ と自信を与える何かがありました。
注10) RUPでは作業分野と呼びます。
特に素晴らしかったのが、一見オブジェクト指向ではなさそうですが、実は取り掛かりとしては書きやすいユースケースと、クラスのステレオタイプですね。オブジェクト指向を勉強し始めて難しかったのが、どの様なクラスをどの様な基準で作ったらよいのかが、構造化技法の知識と経験からは全く分からなかったことです。
しかし、OOSEではユーザーとのインタフェースを受け持つのがBoundary、永続的な実体を表すのがEntity、そして、Entityを調停し、BoundaryとつなぐのがControlと非常に分かりやすい役割分担でしたので、これらとユースケースを合わせれば自分でも作成できそうだと自信がもてました。
同時に、構造化技法ではあまり言及されていなかった繰り返し開発と言うのも新鮮でした。ああ、なんだ、一度に完成させようとしなくていいのか、これなら何とかなりそうとこれまた自信がもてました。
これからこのコラムでも書いていきたいと思いますが、RationalとくにRUPにおいて最も重要だと個人的に思っていることは開発方法論とは天才のためのものではなく、お客様と開発者の両方を含めて、凡人がよりよくシステムを開発するためのものであるということです。ゲームの例でも分かるようにごく少人数の天才がソフトウェアやシステムを作るときには別に開発方法論のようなものはなくても何とかなってしまうと思います。天才には独自の本人だけの方法論があるので、一般化された方法論は不要なのです。
しかし、我々凡人は本人独自の方法論、もっとざっくりいえば本人やチーム独自のやり方などいきなり生み出すこともできません。そのような凡人が凡人のままでもなんとかよりよくシステムを開発するためには、まずは偉大なる先人が作り上げたやり方、方法論を学ぶ方が効率的なのです。自分独自の方法論を作り上げるのはその後でも遅くはありません。
ツールにしても同じで凡人こそ、自分たちを適切にサポートしてくれるツールが必要なのです。
と、方法論、そしてソフトウェア工学素晴らしい！ とOOSEの真似事をしながら、やはり実用性皆無（結局こうなってしまいました）のプログラムを作っている間に、オブジェクト指向の世界ではBooch法のBooch、OMT法のRumbaugh、OOSEのJacobsonの3人が集まり、表記法の統合（UML）と開発方法論の統合（RUP）の検討を始めていたのです。
後編に続く
]]>