zマイスターとの新たな価値探求 rational

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、

最新化がもたらす価値

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、最新化がもたらす価値

Syかがemｚは IBM メインフレームの 45 年以上の歴史において、多くのお客様の基幹シ

ステムを支えるインフラとして採用され、現在も最新のビジネス・ニーズに対応すべく、ハー

ドウェア、ソフトウェア共に進化し続けているプラットフォームです。技術の進化、移り変

わりの激しいＩＴ業界の歴史においても、これだけ長く、継続してお客様に価値を認めて

いただいているプラットフォームは、他に例が無いでしょう。

そのことを裏付ける事実として、全世界の市場を見てみると2010 年から2012 年にかけ

て、Syかがem ｚのビジネスは飛躍的な伸びを示しています。一方で、日本の市場におい

ては、日本国産ベンダーのメインフレームのイメージを元に、メインフレームに対するネガ

ティブなイメージが散見されています。そのイメージを払拭するために、進化・発展してき

た IBM Syかがem ｚが提供する機能とそれによって得られるメリットをより分かり易い形に

整理し、お伝えできるように取り組みを進めています。

本コラムでは、最新のバージョンに移行して頂いた暁に、活用頂ける最新のソフトウェア

の機能と、最新化がもたらす価値について、主要なミドルウェアの切り口から、お届けい

たします。

先輩：

IT部門のシニアな社員。

豊富なメインフレーム経験を持つ。

自称“zマイスター”

後輩：

IT部門若手社員。

メインフレームが主担当だが

オープン系も一部担当する。

登場人物

161

第8章

Rational

いま企業は、オフショアに代表されるグローバルな開発体制、ビジネス・パートナーやお客様のア

プリケーションとの統合など、新しい製品やサービスへの要求に対応することが求められています。

しかし、ビジネスや社会が高度化するにつれ、ソフトウェアに対する要求は一層複雑化し、他社に

先駆けて高品質なソフトウェアを開発していくことは容易ではありません。また、昨今の厳しい経済

状況も後押しし、短納期、低コストの波も収まることはありません。

こうした状況の中、より価値のあるソフトウェアを社会に送り出し、新たな価値を創出していくため

には、どのような変革が必要なのでしょうか？

IBM Raがional は、「要求」「アーキテクチャーと設計」「開発」「テスト」などのソフトウェア開発の

各工程で求められている仕組みはもとより、Jaげげテクノロジーに代表される次世代コラボレーション・

ライフサイクル管理環境の提供、さらに、開発現場とビジネスを高度に連携させるソリューション

の提供など、ビジネス全体に他にはない優位性をもたらします。

メインフレーム開発も同様です。多くの IT 組織は、アーキテクチャーや長年築きあげてきた既存の

システムに縛られ、ビジネスに即応することが難しい状態にあります。

こうした中でビジネス・ニーズを満たすためには、既存資産の有効活用するサービス指向アーキテ

クチャー（SOA）の採用など、モダナイゼーション（最適化、最新化）を段階的に実施することが

必要です。また、こうしたモダナイゼーションが、組織に最新のアーキテクチャーやテクノロジーを

もたらし、チームのコラボレーションを環境の促進や生産性の向上につながります。IBM Raがional

は、エンタープライズ・モダナイゼーションに向けたソリューションを提供し、企業の IT システムを

段階的に最新のアーキテクチャーとテクノロジーに対応させる支援を行います。

本章では IBM Raがional のエンタープライズ・モダナイゼーションがもたらす価値についてご紹介し

ます。ぜひ後輩くんと一緒に最新のメインフレーム開発テスト環境（IBM Inがegおaがed Solきがion foお

Sけかがem げ Developmenが）について理解し、メインフレーム環境を最大限に活用することで、より

価値のあるソフトウェア開発にご活用ください。

162

図 1：Raがぁぇうal 製品ポートフォリオ

図 2：最新のメインフレーム開発テスト環境

163

① 開発者のデスクトップ環境の革新【第8章】 Rational

164

【第8章】 Rational ① 開発者のデスクトップ環境の革新

1 開発者のデスクトップ環境の革新

　ベテランも若手も使いやすい開発インターフェース

先輩：どうしたの？　こんなに遅くまで残っていて。

後輩：実は、今度メインフレームの COBOL 開発のプロジェクトに入ることになって。今までオー

プン系 Jaぎa の開発しかやっていなかったので、開発のやり方を勉強していました。えっと、

まず PCOMM ※ 1 でメインフレームとセッションを張り、グリーン・スクリーンが表示されて、

TSO とコマンドを打って ID とパスワードを入れて。

※ 1. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/うeがくぇおk/えcぇmmか/

先輩：苦労しているようだね、自分が入社した時にも同じ経験をしたよ。ちなみにエミュレータにど

んな印象を持った？

後輩：初めてエミュレータを立ち上げた瞬間、大混乱しました。真っ黒で何を入力していいかわか

らず。Eうがeおキーを押しても何も動かなくて、自分も画面と一緒にフリーズしてしまいました

（笑）。

先輩：ははは、Cがおl キーと間違えてしまったんだね。それで、もうグリーン・スクリーンの開発に

は慣れた？

後輩：開発の操作はやっと覚えました。ISPFに入り、編集するメンバーを選択して、行を探してソー

ス編集、次に JCL を探して編集、さらに JCL をサブミット。その後、SDSF に入りサブミッ

トしたジョブを選択し、エラー・メッセージを確認、エラーがあった場合はエラー内容と行

番号を記憶し、JCL やソースコードを見ながら問題判別する。ですよね？（図 3）

先輩：この短期間でよく覚えたね。Jaぎa の開発に比べて開発スピードはどうなった？正直な感想

を言ってみて。

後輩：正直な感想ですが・・・、開発スピードは下がりました。グリーン・スクリーンに慣れていな

いことが大きいとは思いますが、切り替える画面の回数が多くて、直観的に次に何をすれば

よいかわからりづらいです。また COBOL 言語が初めてなので文法を覚えるのに苦労して

いて、コードのアシスト機能がないのが辛いです。Jaぎa 開発では Raがぁぇうal Aええlぁcaがぁぇう

Deぎelぇえeお（RAD）※ 2 や Eclぁえかe を使っていて、アシスト機能は当たり前でした。また、

オンライン・マニュアルがインターネットで簡単に参照できることも便利でした。

※ 2. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/deかぁgう/おad/

先輩：言ってくれるね。10 年前の自分だったら、そんな文句を言っているなら早くTSO/ISPF の

操作を覚えて一人前になれ、と怒鳴っていたところだけど。

後輩：言い過ぎました。申し訳ありません。

先輩：いやいや、そういう若者の視点って重要だと思うよ。我々の業務で使うオフィス・ツールや

電子メールも GUI（グラフィカル・ユーザー・インタフェース）だし、心のどこかでは皆 GUI

を望んでいると思うよ。でも今まで確立した開発運用体制や新しいツールを入れる時の導入・

定着コストを考えるとなかなか踏み切れないというのが、多くの企業やプロジェクトで起こっ

ている現状なんだ。

後輩：今、GUI と言いましたが、メインフレーム開発を GUI で行うツールはあるのですか？

先輩：その言葉を聞き流さなかったか、さすが。その通り、実はある。さっき君が触れたキーワード

が非常に重要になってくる。そのキーワードは何かわかる？

図 3：従来の開発作業（ISPF）

165


166


後輩：えっと、アシスト機能ですか？　いやそれを実現した根本のテクノロジーというと、もしか

して『Eclぁえかe？』

先輩：ビンゴ！

後輩：そうか、Eclぁえかe は拡張機能を提供するための標準的な手段（プラグイン）を提供している

ので、COBOL の開発機能を付与すれば。

先輩：生き生きしてきたね。やはりオープン系の技術の話になるとやる気が出てくるようだね。

Raがぁぇうal Deぎelぇえeお fぇお Sけかがem げ（RDげ）という製品でそれを実現しているんだ。

後輩：えー、なんで教えてくれなかったんですか？　早く使ってみたいです。

先輩：そう言ってくると思った。開発基盤を Eclぁえかe というテクノロジーで共通化することで、

言語に依存しない共通のユーザー・インターフェイスで統一できることが画期的なんだ。

COBOL や PL/I 開発者が減少する中、君みたいな Jaぎa 開発者からの移行を容易にする

こともできる。いわば『人材の流動化』のためにも役立つ。

後輩：逆に COBOL や PL/I 開発者が Jaぎa 開発者になることもできるんですね。

先輩：保守開発になると人数が少なくなるので、企業によっては開発者が全ての言語を担当しなく

てはいけない状況にあると聞いているけど、操作性が同じだと敷居は低くなると思うよ。

　プロジェクトや開発者にとって便利な機能

後輩：では、RDげの機能を知りたいのですが、どのようなものがあるのでしょうか？

先輩：それぐらい自分で、インターネットで調べなさい。

後輩：はい、ごめんなさい。自分で調べてからわからない点を質問すべきでした。RDげの製品ペー

ジ※ 3 に行って、あっ、「グラフィカルなインターフェースである Wぁうdぇくかの Eclぁえかe の

共通基盤上で、新しい開発メンバーもスムーズに開発作業に取りかかることができます。」っ

て書いてあります。

※ 3. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/deかぁgう/おdげ/

先輩：で、機能は？

後輩：はい。「バッチ、CICS、IMS、および DB2 用の COBOL、PL/I、C++、アセンブラー、

および Jaぎa アプリケーションの開発を可能にし、サービス指向アーキテクチャー（SOA）

および Web サービスの作成をサポートします」という記述がありました。万能ツールなの

ですね、えっ、Web サービスの作成もできるのですか？　オープン系のテクノロジーかと思っ

ていました。

先輩：既存のメインフレーム資産を有効活用するには、SOAの考えがとても重要なんだ。ソフトウェ

ア開発費用の半分以上は保守に使われていると言われているけど、その中で新しい機能を

拡張しながら提供していくとすると、SOA の考え方は重要になる。その中心となる技術は

Web サービスだからね。

後輩：どのような Web サービス作成機能があるのですか？

先輩： CICS や IMS のアプリケーションを Web サービス化する機能（Eうがeおえおぁかe Seおぎぁce Tぇぇlか

fぇお Web かeおぎぁceか aうd SOA など）を提供しているよ。また、最新の IMS, CICS の機能

の開発を支援するツール（CICS SCA Tぇぇlかや Aええlぁcaがぁぇう Deえlぇけmeうが Maうageお）も

ある。モダナイゼーション（最適化、最新化）という言葉を聞くことが多いと思うけど、SOA

のようにアプリケーションのモダナイゼーションをするだけでなく、それを実現する開発ツー

ルやミドルウェアなどの基盤をモダナイゼーションすることも忘れないでいてほしい。

後輩：はい！

先輩：それでは RDげの機能の話に戻るけど、deぎelぇえeおWぇおkか Raがぁぇうal ※ 4 に「Raがぁぇうal

Deぎelぇえeお fぇお Sけかがem げのご紹介」※ 5 という資料が公開されている。これを見たこと

があるかな？

※ 4. hががえ://くくく.ぁbm.cぇm/deぎelぇえeおくぇおkか/あえ/おaがぁぇうal/

※ 5. hががえ://くくく.ぁbm.cぇm/deぎelぇえeおくぇおkか/あえ/おaがぁぇうal/lぁbおaおけ/em/cmか/おdげ/おdげ_ぇぎeおぎぁeく/

後輩：まだです。早速見てみます。RDげはわかりやすい GUI ですね、Eclぁえかe インターフェー

スに慣れている私としてはすんなり入れそうです。ソースを編集して、選択して構文チェッ

ク、コンパイル、さらにコンパイルエラーの場合はダブルクリックするとソースの該当箇所

に移動する。（図 4）

まさしくJaぎa 開発と同じ流れです。これなら開発スピードの維持、いや向上ができます。

167


168


図 4：RDげを用いた開発作業

先輩：そう言ってもらえるとうれしいな。実はメインフレームの初心者だけでなく、ベテランの人に

も効果があったと聞いているよ。やはりWぁうdぇくかのGUIのインターフェースに慣れてきて、

ツールを変えるという障壁が心理的にも下がってきたのかもしれない。

後輩：他には、もちろんアシスト機能と、構文チェック、デバッグ作業もビジュアルにできるんで

すね？　3270 画面のレイアウト（CICS BMS, IMS MFS）の画面デザインツールもある

ようです。ちなみにプログラムを実行するのはどのようになるのでしょう？

先輩：一般的にはローカル（PC）で編集して、ローカルのコンパイラで構文チェックをし、その後

はメインフレームにソースを転送し、コンパイル＆リンク、実行を行う。この操作も RDげ

からできるんだよ。テストやデバッグ用の JCL もテンプレートに従い自動生成してくれる。

後輩：わぉ、クールですね。転送の時の文字コードはどうなるのですか？　Wぁうdぇくかでは Shぁfが-

JIS や UTF-8 などで、メインフレームは EBCIDIC ですが。

先輩：それもRDげがやってくれる。設定でどのようなコード変換をするか指定可能になっているよ。

メインフレームのデータセットやメンバーはエクスプローラーで表示され、ドラッグ＆ドロップ

操作により転送やコピー処理が可能になる。（図 5）

後輩：聞いているだけでワクワクしてきました。

図 5：RDげを用いたファイル転送

先輩：他には運用に役立つ、プロパティーや構成の管理とクライアントへの配布をする「クライア

ントへのプッシュ機能」もある。この機能により一貫性のある集中化された開発環境を利

用できる。開発者の人数が多いプロジェクトには便利だと思うよ。他にもたくさん機能があ

るので、RDげのオンラインマニュアル（US）※ 6 や動画の Edきcaがぁぇう Aかかぁかがaうが（US）※ 7

も要チェックです。

※ 6. hががえ://くくく.ぁbm.cぇm/かきええぇおが/dぇcぎぁeく.くかか?きぁd=かくg27014903

※ 7. hががえ://えきblぁb.bぇきldeお.ぁbm.cぇm/ぁうfぇceうがeお/ぁedきaかかが/おがうぎ1お0/ぁうdeぐ.あかえ?がぇえぁc=/cぇm.ぁbm.

ぁea.おdげ/えlきgぁう_cぇぎeおえage.hがml

後輩：はい、オンライン・マニュアルを見ながら触ってみます。

先輩：開発者にとってもそうだけど、プロジェクト全体にとっても効果はあるんだ。例えばテストの

効率化やチーム開発・コミュニケーションの促進だね。これは別の機会に話すとするよ。

　日本語仕様書での開発のメリット

後輩：ところで、RDげの製品ページの中に、RDげ HLL/WB ※ 8 という製品が載っていました。

※ 8. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/かぇlきがぁぇうか/em/hllくb/

http://publib.boulder.ibm.com/infocenter/ieduasst/rtnv1r0/index.jsp?topic=/com.ibm.iea.rdz/plugin_coverpage.html

169


170


先輩： HLL/WB は非常に古い製品で、RDげより古い歴史があるんだ。1990 年に初出荷なので、

20 年以上の歴史がある。途中で Eclぁえかe インタフェースに移行し、今は RDげの上位版と

して提供されている。

後輩：えっ、自分が 5 歳の時に出荷された製品・・・。

先輩：つまり多くの日本のお客様に使われ続けているということだね。日本の開発部門で開発して

いるのも特徴だよ。

後輩：日本語仕様書による COBOL や PL/I アプリケーション開発作業を支援するとありますが、

日本語からCOBOL ソースを生成してくれるのでしょうか？

先輩：それももちろん機能の一つだよ。また、理解しやすい日本語仕様書を用いることで

COBOL 言語に精通していない開発要員でも、生産性や品質を維持しながら開発すること

が可能なんだ。これは以前プロジェクトでこのツールを使った実感だよ。（図 6）

後輩：日本語仕様書からソースを生成する仕組みはどうなっているのでしょうか？

先輩：それには用語辞書と略号表が非常に重要な役割を持っているんだ。これを利用することで

コードの生成はもちろんのこと、コードから日本語仕様書へのリバースも可能になる。

図 6：HLL/WB を用いた開発作業

後輩：リバースも可能になるんですか、たまに仕様書がないと困っているプロジェクトを聞きます

が、この機能は利用できそうですね。

先輩：その用途で採用されたこともある。現行調査や移行支援に利用し、その後 HLL/WB を使っ

て開発していくことになるね。他には、プロジェクト独自の標準化チェック機能を作ったり、

COBOL の場合は日本語マクロによる部品化をすることで再利用性を高めるケースもある。

詳しくは、「Raがぁぇうal Deぎelぇえeお fぇお Sけかがem げ HLL/WB のご紹介」※ 9 という資料を読

むとよいよ。

※ 9. hががえ://くくく.ぁbm.cぇm/deぎelぇえeおくぇおkか/あえ/おaがぁぇうal/lぁbおaおけ/em/cmか/おdげ/hllくb_ぇぎeおぎぁeく/

後輩：ありがとうございます。HLL/WB が開発作業の生産性と品質を向上させることがわかりま

した。

先輩：生産性と品質というキーワードが出たけど、次回はテストの観点でみていこう。メインフレー

ム開発においてテストは課題も多く、効率化を求められている領域なので。

後輩：はい、よろしくお願いいたします。

171

【第8章】 Rational

172


2 メインフレーム・テスト環境の革新

　IAサーバー上で z/OSが稼働するって本当？

後輩：プロジェクトでコーディング（CD）/ 単体テスト（UT）フェーズが始まり、多くの開発者が参

画するようになりました。この影響でメインフレームの開発区画のパフォーマンスが急に遅く

なって。1 本の COBOL ソースのコンパイル＆リンク、実行を行うだけでも数分かかってし

まいます・・・。

先輩：それは大変だね、プロジェクトの運用で何か工夫をしてたりする？

後輩：各自コンパイルの頻度を少なくするように言われています。Jaぎa 開発では PC 上で

RAD ※ 10 を使っていましたが、ソースを保存するだけでコンパイルが走り、同梱されてい

る WAS ※ 11 テスト環境ですぐにテストできました。メインフレーム開発って一般的にこんな

感じで運用で制約をかけるのですか？

※ 10. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/deかぁgう/おad/

※ 11. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/くebかえheおe/aええがおaうかacがぁぇう/くaか/

先輩：企業やプロジェクトによって違うけど、本番区画、開発区画、テスト区画を1 台のメインフレー

ムで共用しているケースも多い。もちろん本番の安定稼働が最優先なので、開発やテスト

の優先度は低く設定される。そうすると割り当てられるリソース（CPU やメモリなど）が少

なくなり、開発やテストの生産性が低下してしまうこともある。

後輩：リソースを追加することはできないのでしょうか？

先輩：費用がかかるから単純にはいかないね。またリソースを追加するとなると、運用部門との調

整が必要で、結局使えることができたのは 2ヵ月後なんてこともよく聞くよ。

後輩：何かこの状態を解決する方法はないのでしょうか？

先輩：我慢しなさい。っていうのは冗談で、これを解決するピッタリの製品があるんだ。Raがぁぇうal

Deぎelぇえmeうが aうd Teかが Eうぎぁおぇうmeうが fぇお Sけかがem げ（RD&T）※ 12 をインターネットで

検索してみて。

※ 12. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/deぎがeかが/かけかがemげ/

後輩：はい。えっと、開発者のデスクトップ上または共有サーバー上で、げ/OS 開発と単体テスト

を実行できる個人用の環境を作成します、とありますが、どういうことでしょうか？

先輩：こう言ったらわかりやすいかな、「IA サーバーの Lぁうきぐ上でげ/OS が稼働する」、つまりメ

インフレーム外で用意できる Sけかがem げ開発テスト環境なんだ。（図 7）

図 7：RD&えT の概要

後輩：すごく画期的です。メインフレーム開発区画のリソースが足りていない現状に対する効果的

なソリューション、ずばりです。

先輩：開発部門専用に用意できるので、運用部門との作業の依存関係を減らせることもメリットだね。

後輩：げ/OS だけでなく、Eうがeおえおぁかe COBOL コンパイラ、Eうがeおえおぁかe PL/I コンパイラや

CICS, IMS, DB2 などの各種ミドルウェアが含まれているのですね。

先輩：開発用途で事前構成されたセットがパッケージ化されている。これにより最新バージョンの

ソフトウェアが利用可能となる。げ/OS のマイグレーションやコンパイラ（例 OS PL/I から

Eうがeおえおぁかe PL/I）のマイグレーションの検証環境として利用するケースもあると聞いたこ

とがあるよ。

後輩： RD&Tってすごいですが、制約もあるのでしょうか？

先輩： RD&T は Sけかがem げに代わるものではないので、本番ワークロード、負荷テスト等を目的

とした稼働は許可されていない。また RD&T サーバーの起動と稼働は USB キーを用いた

ライセンス認証で行うこともお忘れなく。

② メインフレーム・テスト環境の革新② メインフレーム・テスト環境の革新

173


174


後輩：我々、初心者の教育環境にも使えるかもしれませんね、自由に壊してもよいげ/OS 環境。

先輩：おいおい、柔軟に使える環境と言ってほしい。意図的に壊したらダメだよ！

　最先端の単体テストツール

後輩： COBOL の単体テストはどのようにするのでしょう。

先輩：テスト・コードを一から作成することが多いかな。単体テストなので、スタブやドライバ

のコードを用意して、テスト・データをセットして実行。スキルも要求されるので、開発者

のスキルレベルが低いと、品質が悪いコードとなってしまう。

後輩： Jaぎa ですとあUうぁがという単体テスト・フレームワークがあり、これを利用したことがあります。

先輩：そうそう、最新の RDげ 8.5 ※ 13 では、げUうぁがというぐUうぁがフレームワーク・ベースの単体

テストフレームワークが導入されたんだ。Eうがeおえおぁかe COBOL および PL/I のコードの単

体テストに使用することができる。詳しくは RDげのオンライン・マニュアル※ 14 を確認して

みてね。

※ 13. hががえ://くくく-01.ぁbm.cぇm/cぇmmぇう/かかぁ/ShぇくDぇc.くかか?dぇcURL=/cぇmmぇう/かかぁ/

おeえ_ca/4/760/RTL12034/ぁうdeぐ.hがml&laうg=あa&おeぉきeかが_lぇcale=あa

※ 14. hががえ://えぁc.dhe.ぁbm.cぇm/ぁうfぇceうがeお/おaがdeぎげ/ぎ8お5/がぇえぁc/cぇm.ぁbm.eがぇぇlか.おdげ.げきうぁが.dぇc/

がぇえぁcか/c_げきうぁが_ぇぎeおぎぁeく.hがml

後輩：テスト・ランナー、テスト・ケース、アサーション・・・、Jaぎa 開発であUうぁがを使ってい

た私にはなじみ深い用語です。テストのセットアップ宣言して、プログラムの入出力のコー

ドを記述すればいいのですね。これなら使いこなせそうです。継続的インテグレーション

（CI：Cぇうがぁうきぇきか Iうがegおaがぁぇう）を実現する機能になりそうですね。メインフレームで

CI を実現する CIげ（IBM Cぇうがぁうきぇきか Iうがegおaがぁぇう Sぇlきがぁぇう fぇお Sけかがem げ）という

コンセプトがホームページに載っていました。

先輩：さすが Jaぎa 開発者だった君は理解が早い。実は何十年もCOBOL や PL/I の開発をして

いた自分にはげUうぁがや CIげの必要性はわかっているのだが、少し敷居が高くて。

後輩：先輩にも苦手なことがあるんですね。

先輩：歳を経ったもんだ・・・。ところで、日本 IBM の IP アセット※ 15 で単体テスト・ツールとい

うものがある。COBOL 用と PL/I 用の 2 つが、RDげを拡張するプラグインとして提供さ

れている。プログラムの単体テストを支援する以下のような機能がある。（図 8）

● ソースコードから、テスト・ケース（テスト仕様書）テンプレートを自動生成

● ソースコードから、単体テスト用ドライバ､スタブ･モジュールを自動作成

● げ/OS（RD&T）上でのテスト自動実行（リグレッション･テストの自動化）

● テスト結果と期待値との比較､カバレッジ取得

※ 15. IBM がサービスで使用できる権利を持つ知的財産（Iうがellecがきal Pおぇえeおがけ）アセット

図 8：単体テストツールの概要

後輩：これは便利ですね。テスト仕様書はどのようなものなのでしょうか？

先輩：ソースコードを解析し Eぐcel のテスト・ケース・テンプレートが自動生成される。慣れた

Eぐcel でテストデータを入力できるので、開発者のテストデータ準備の手間を軽減できるん

だ。それを基に単体テスト実行に必要なドライバやスタブが自動生成されるので、すぐに単

体テストを開始できることになる。

後輩：すごい！　初心者でもベテランでもこれなら容易に使いこなすことができますね。

先輩：プロジェクトの標準化促進という意味でも効果的なツールとなるね。最近増えているオフショ

ア開発でも採用されるケースがあると聞いているよ。また単体テストのリグレッション・テス

トを自動化できるので、プログラム修正時のテスト･コストの削減やデグレードを防止が期

待できる。つまり単体テストツールもCI を実現する機能となりえるんだ。

後輩：なるほど。ちなみにカバレッジの取得ができるとありますが、どのような仕組みになっている

のでしょうか？

② メインフレーム・テスト環境の革新 ② メインフレーム・テスト環境の革新

http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/4/760/RTL12034/index.html&lang=ja&request_locale=ja

http://pic.dhe.ibm.com/infocenter/ratdevz/v8r5/topic/com.ibm.etools.rdz.zunit.doc/topics/c_zunit_overview.html

175


176


先輩：げ/OS 上の Debきg Tぇぇl ※ 16 と連携して実現しているんだ。RD&T には Debきg Tぇぇl が

同梱されていることからも、単体テスト環境として利用する価値がある。単体テストにおい

てコードカバレッジ 100%、テストケースの 100%合格という完了基準があった場合、エ

ビデンスを取得するのは煩雑で手間がかかることだけど、この単体テストツールを使うとこ

の手間が軽減されて、開発者が本来行うべきコーディングや単体テストに集中できるね。

※ 16. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/えおぇdきcがか/あえ/あa/debきgがぇぇl/

後輩：今のプロジェクトで、COBOL 単体テストツールが適用できるか、開発リーダーに相談して

みます。

　統合テストで利用できるテストツール

後輩：単体テストに引き続き、統合テスト（IT）についても相談させてください。このプロジェクト

のフロントエンドは、ユーザーが Web ブラウザでアクセスする WAS 上の Web アプリケー

ションです。WAS からメインフレームは WebSえheおe MQ ※ 17 もしくは Web サービスで

接続します。

※ 17. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/くebかえheおe/ぁうがegおaがぁぇう/くmぉ/

先輩：典型的なシステム連携パターンだね。どのような統合テストが必要になるだろうか。

後輩：まず Web のリグレッションテストが必要になります。前の Jaぎa プロジェクトでは、テスト・

ケースの再利用性を高め効率化するために、Raがぁぇうal Fきうcがぁぇうal Teかがeお（RFT）※ 18

を使ったことがあります。手動での打鍵作業を毎回実施すると大変ですし。

※ 18. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/がeかが/おfが/

先輩：今回もRFT は使えそうだね。補足しておくと、グリーン・スクリーンの 3270 や 5250 端

末のリグレッションテストもできる。他には .うeがや Vぁかきal Baかぁc のテストもできる。バック

はメインフレームでも、フロントエンドは様々なテクノロジーを使うことがあるから。

後輩： RFT は Web だけじゃないのですね、勉強になりました。次に、WebSえheおe MQ や

Web サービスのテストを検討しなくてはいけませんが、前のプロジェクトでは手作りでテス

トプログラムを作っていました。

先輩：多くのプロジェクトでは手作りで作っていると思うよ。ツールを適用するのであれば、

Raがぁぇうal Teかが Wぇおkbeうc h （RTW）※ 19 という製品がある。これはテスト自動化

パッケージで、先ほどの RFT, Web 負荷テストの Raがぁぇうal Peおfぇおmaうce Teかがeお

（RPT）※ 20, そして MQ や Web サービスなど様々なプロトコルに対応する Raがぁぇうal

Iうがegおaがぁぇう Teかがeお（RIT）が含まれている。この RITを使う手はあると思うよ。インター

フェース定義からテスト・スクリプトを自動生成する機能や、逆にアプリケーションの振る

舞いをシミュレーションするスタブをインターフェース定義から自動生成する機能がある。

※ 19. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/おがく/

※ 20. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/がeかが/おえが/

後輩：連携するサブシステムや外部システムが多くなると役に立ちそうです。

先輩：ところで、プロジェクトではテスト仕様書や結果はどのように管理するの？

後輩： Eぐcel です。RFT などのテストツールを使うとテストの実施は自動なのですが、実施状況

や結果の記入は Eぐcel に入れるので、他の人とマージするのに手間がかかっています。

先輩：管理者の視点からはどうだろう？

後輩：この前の飲み会でプロジェクト・マネージャーの横に座ったのですが、プロジェクトの状況を

リアルタイムに把握できることが望ましいけど、Eぐcel によるテスト管理だと必要とする情

報を正確に収集するまでに 1 週間程度の期間が必要となるので、日々の状況をどう把握す

るかが課題と言っていました。報告の頻度を短くすると、先ほどのマージ作業に時間がかかっ

て、肝心のテスト作業に時間が避けなくなるので、ジレンマになっているそうです。

先輩：個人からチームの最適化という視点に話題が広がったね。

後輩：もっとチーム全体で『コラボレーション』できればいいのですが。

先輩：品質の視点で考えると、コラボレーションは、人とノウハウの両方を表していると最近は感

じているよ。それらをうまく蓄積し、結びつけられるといいね。またうまくツールを活用する

ことで管理の簡略化を行い、正しく統制（最適化）することで品質を向上させることができ

るのではないかな。

後輩：今、ツールという言葉が出ましたが、どのようなツールが適用できるのでしょうか？

② メインフレーム・テスト環境の革新 ② メインフレーム・テスト環境の革新

177


178


先輩： Raがぁぇうal Qきalぁがけ Maうageお（RQM）※ 21 は、ソフトウェアのライフサイクル全体にわたる

品質管理･テスト管理をシームレスに実現することができる。（図 9）

deぎelぇえeおWぇおkかの技術文書※ 22 が良くまとまっているので、詳しくはこちらを見てほしい。

※ 21. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/がeかが/おぉm/

※ 22. hががえ://くくく.ぁbm.cぇm/deぎelぇえeおくぇおkか/あえ/おaがぁぇうal/lぁbおaおけ/ぉm/#おぉm

図 9：RQM を中心とする品質管理ソリューション

後輩：テスト担当者にとってみると RQM で RFT や RPT のテスト・スクリプトを自動実行できるの

もよいですね、結果が自動的に収集されるので報告作業が効率化されます。

先輩：管理者にとっても RQM のレポートを見ていればリアルタイムで正確な情報を確認すること

ができるので、意思決定サイクルが短くできるね。組織メンバー同士の上下左右の距離が

短くなり、結果として生産性と品質の向上につながることが期待されるよ。

後輩：これってメインフレームの開発だけでなく、オープン系の開発でも適用できますね。

先輩：その通り。システムはますます複雑になっているから、全体最適の仕組み（インフラ）と

して、ツールを適用するのは当然の考え方だ。ツールをうまく活用することで、それぞれ

の立場で各自の専門性に集中することができ、スキルや組織の力の底上げに役立てること

ができるといいね。

3 チーム・コラボレーション環境の革新

　コラボレーションはうまくできていますか？

後輩：前回、先輩から人とノウハウの両方をうまく蓄積して結びつけられるとコラボレーションがう

まくできるという話がありました。この点をもう少し詳しく聞かせてください。

先輩：何か具体的にプロジェクトで困っている事があるの？

後輩：管理する手段がたくさんあるというか、開発メンバーにとってみると窮屈というか、長年の

開発プロセスは実績があるのでそのまま受け入れればいいのですが、これを改善できない

かと考えています。先輩の話を聞いていると改善するキーワードは「コラボレーション」の

気がして。

先輩：すごいな、この短期間でリーダーの視点になっている。この視点は大事だよ。我々ベテラ

ンは過去の実績や成功体験があるため、新しいことを導入することに躊躇してしまうことも

多い。そういう点で君の意見は貴重だよ。どんな点が改善できそうか、今感じている課題

を聞かせてほしい。

後輩：まずは管理票が多いことですかね。案件管理票、変更 / 障害管理票、Q&A 票、テスト進

捗、リソース管理票など表計算ソフトウェア（Eぐcel）で管理しています。記入するのはい

いのですが他の人が更新中かもしれないので、今見ている内容が最新か疑問に思うことが

あります。もちろん Eぐcel の排他制御の仕組みを使えばいいのですが、そうすると効率性

が悪くなりますし。

先輩：ちなみに案件の並行開発ってある？

後輩：もちろんです。複数案件が並行して走り、同じソースコードを数人で触ることもあります。

今回のプロジェクトではライブラリ管理者がマスターリポジトリーから案件対応でソースの変

更が必要な開発者にソースを貸し出すという仕組みになっています。紙の貸出票に記載して

ソースを借りるのですが、複数案件が起票されて同じソースを複数の開発者に貸し出す際

の手間があり時間がかかっています。メインフレーム開発ではこの仕組みは当たり前なので

しょうか？

② メインフレーム・テスト環境の革新 ③ チーム・コラボレーション環境の革新

179


180


先輩：ライブラリ管理モデルはメインフレーム開発で通常使われているものだよ。以前はプログラ

ム単位で開発メンバーに案件を割り振ることが多かったのでこの仕組みで十分だったけど、

複数案件を担当する並行開発が最近は増えているので、ここは改善するポイントかもね。

後輩：最後は変更履歴をソースコードに直接記入していることでしょうか。変更 / 障害管理は

Eぐcel で実施していますが、各項番の変更内容と変更者をソースコードの中にコメントとし

て記述しています。ソースコードの行数が長くなって可読性も悪くなり、また Eぐcel とソー

スコードの 2 つを見比べながら確認しなくてはいけないので面倒です。

先輩：今の話をまとめてみると、一つ一つの仕組みや成果物はうまくできているけど、それがうま

く結ばれていないように聞こえるね。ある意味属人化してしまっているのかもしれない。例

えばベテランのライブラリ管理者がある日突然いなくなってしまったらどうなるだろう。

後輩：ライブラリ管理マニュアルにはベテランのライブラリ管理者のノウハウがすべて記入されて

いるわけではないので大混乱すると思います。これをシステム化してツールを導入すること

を考えなくてはいけないと思います。

先輩：まさにその通り。それではツールをうまく活用することで属人化を防いだり、成果物を有機

的につないでコラボレーションを促進する全体最適の仕組み（インフラ）を構築することを

今回の改善テーマにしてみようか。

　コラボレーティブ・ライフサイクル・マネージメント

先輩：コラボレーティブ・ライフサイクル・マネージメント（CLM）※ 23 って聞いたことある？　アプ

リケーション・ライフサイクル・マネージメント（ALM）は各開発工程（要求ど設計ど実装ど

テストどリリース / 保守運用）の壁を取り除き、アプリケーションのライフサイクルにわたっ

て継続的にプロセス管理をする考え方だけど、それに加えてコラボレーションを重視した考

え方が CLM なんだ。

※ 23. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/clm/がeぐが.hがml

後輩： CLM はどんな壁を取り除くのでしょうか？

先輩：さっき管理マニュアルの話が出たけど、マニュアルが整っていれば開発生産性は上がると

思う？

後輩：いえ、そこでは表現できないことが開発現場にはたくさんあります。例えば、開発の指示

や依頼をするに至った経緯や背景など開発の意図を正しく伝えることは難しいです。電話の

やりとりで済ませてしまうと後で言った言わないの騒ぎになりますし、メールで履歴を残した

としても後で検索するのが大変です。

先輩：いわゆる「行間」ってやつかな。これが蓄積されるとノウハウになり、今はまさに属人化し

ている情報だ。メインフレーム開発に従事するベテランが定年で退職していく中、このノウ

ハウをどのように若い世代に技術伝承していくかは IT 業界全体の課題になっている。

後輩：この課題を解決するのが CLM でしょうか。

先輩：一つの手段として CLM に期待しているよ。例えば、CLM を構成する一つの Raがぁぇうal

Team Cぇうceおが（RTC）※ 24 は、作業管理、変更 / 障害管理、ソース（構成）管理、ビルド

管理などが統合管理できるツールとなっている。これにより、作業の進捗状況、障害と

成果物の関係やプロジェクトに関する情報を一元管理し、共有することができる。（図10）

※ 24. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/かcm/おがc/

図 10：RTC の概要

後輩： Eぐcel で作っている管理票をそのままこちらに移すことができそうですね。情報が一元管理

されるので、ある案件で修正したソースは何で、その案件がどのリリースに入ったなんてこ

とも紐づけることができるとしたら、今のプロジェクトの課題がかなり改善されると思います。

③ チーム・コラボレーション環境の革新 ③ チーム・コラボレーション環境の革新

181


182


先輩：もちろんすべて RTC に移せるかは Fぁが & Gaえしてみないとわからないけど、改善できる

可能性はある。

後輩：ところで構成管理の観点はどうなのでしょうか？　並行開発に対応できそうですか？

先輩：構成管理機能ではバージョンの管理だけでなく、並行開発やコラボレーションを支援する機

能が数多くある。並行開発で開発スピード向上を目的としているので貸し借りを重視するラ

イブラリ管理モデルではなく、ソースは開発者が自由に取得でき、登録（提出）する際にチェッ

クを行う仕組みになっている。自分の作業と競合する可能性のあるチームメンバーのソース

コードを提出前に通知したり、競合してしまった場合のマージの仕組みが充実しているんだ。

（図11）

図 11：分散並行開発を支える RTC の仕組み

後輩：排他制御もかけることはできるのでしょうか？　明示的にソースを提出できる人を決めて他

の人は提出できなくすることとか。

先輩：ロック機能を使えば実現できる。ロックを明示的に宣言すれば、その一覧を表示できるよ。

後輩： Jaぎa 開発をずっと行ってきた私には慣れ親しんでる仕組みなので違和感がないです。自分

の作業と競合する可能性のあるチームメンバーのソースコードを提出前に知ることができる

のは便利ですね、他の製品にはない機能でチーム開発に役立ちます。でも、メインフレー

ム開発を長年実施してきたベテランの方々でも受け入れることができるのでしょうか？

先輩：うーん、正直なところ反発を受ける可能性はあるね。過去の実績や成功体験があるので。

もちろん製品をカスタマイズすれば現行のライブラリ管理モデルのような仕組みを作ることは

できると思うけど、カスタマイズに多くの費用を費やしてはツール適用の効果は減ってしまう

ので、ツールに合わせた運用を新規に作っていく勇気も必要だと思うよ。もしくは既存の仕

組みを利用しつつ、RTC を新規に適用し共存させていいとこ取りをすることもできるかもね。

後輩：丁寧に解説ありがとうございます。このプロジェクトのフロントエンドは、WAS 上の Web

アプリケーションで Jaぎa や HTML の開発をしています。メインフレームの COBOL や

JCL だけでなく、Jaぎa や HTML の管理もRTC を使えばできそうですね。

先輩：その通り。複数のプラットフォームで稼働するシステムに対するプロジェクトの場合、開発

環境がバラバラで管理する環境も別々というのでは、チーム間のコミュニケーションや協業

という観点で問題があるので、チームのコラボレーションを支援し、チーム毎の進捗や抱

えている障害などを見える化し、プロジェクト全体の効率化を促進していくという意味でも

RTC は検討する価値があると思うよ。

後輩： CLM は RTC の他に Raがぁぇうal Reぉきぁおemeうがか Cぇmえぇかeお（RRC）※ 25 と Raがぁぇうal Qきalぁがけ

Maうageお（RQM）※ 26 から構成されるとありました。（図12）

※ 25. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/おおc/

※ 26. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/えおぇdきcがか/がeかが/おぉm/eぐえ_かがaうdaおd/

図 12：コラボレーティブ・ライフサイクル・マネージメント（CLM）

③ チーム・コラボレーション環境の革新③ チーム・コラボレーション環境の革新

183


184


先輩： RQM は品質管理･テスト管理ツールとして前回話したよね。市場の変化に合わせて要求

も予想以上のペースで変化しているので、要求を捕捉し管理していくことが重要になってい

ることは実感していると思うけど、その要求定義・要求管理を支援するツールが RRC だよ。

後輩：これらを組み合わせると、「要求がテストされたか？」、「その障害はどのテストで起こっ

たか？　どの要求か？」、「障害の修正にどのファイルを変更したか？」なんて質問に回答

することもできますね。

先輩：情報を紐づけることでトレーサビリティー（追跡可能性）を確保できることができる。IT 監査

にはトレーサビリティーも指摘されるので、CLM のような仕組みを開発のインフラとして用

意していくことは重要だ。（図 13）もちろんメンバーが情報や関係を入力しなければいけな

いので、それを開発プロセスに標準として組み込まなくてはいけない。最初は負荷がかか

るかもしれないけど、将来を考えると役立つので是非考えてみてほしい。

図 13：トレーサビリティー強化による対監査性の向上

後輩：はい、プロジェクトメンバーと真剣に考えてみます。

　おわりに

先輩：ちなみに CLM は Jaげげというプラットフォーム上で作られていて、OSLC（Oえeう Seおぎぁceか

fぇお Lぁfecけcle Cぇllabぇおaがぁぇう）※27 に準拠し、開発ツール間のデータ連携の基盤として利

用できる。例えば、CLM の作業情報に記録される予実工数を原価管理の財務システムと

連携させるなどの可能性があると思うよ。

※ 27. hががえ://ぇえeう-かeおぎぁceか.うeが/

後輩：まさに、開発ツールのモダナイゼーションですね。既存の仕組みと新しい仕組みを有機的

に組み合わせることができ、「ツール / インフラの壁」を取り除くことに役立ちます。

先輩：ここまで Raがぁぇうal のエンタープライズ・モダナイゼーションがもたらす価値を見てきたけ

ど、影響分析の Raがぁぇうal Aかかeが Aうalけげeお（RAA）※ 28 を補足しておくね。げ/OS のア

プリケーション資産（Eうがeおえおぁかe COBOL, Eうがeおえおぁかe PL/I, JCL など）の情報を解

析し、分析データベースに格納することで、アプリケーションの棚卸しや影響分析に利用

することが可能で、ユーザーは Web ブラウザからプログラム資産の棚卸し情報や資産関

係の可視化をしたり、データの流れを追いかける波及分析を行うことができる。特に保守

段階では変更の影響分析をしてから開発が始まるので、ここに課題を感じていたら考えて

みてほしいソリューションだよ。

※ 28. hががえ://くくく.ぁbm.cぇm/かぇfがくaおe/あえ/おaがぁぇうal/かぇlきがぁぇうか/em/かけかがemか/げ/おaa/

後輩：メインフレームをレガシーという人がいますが、まったくレガシーでないですね。エンタープ

ライズ・モダナイゼーションによりメインフレーム開発テスト環境を革新し最大限に活用する

ことで、より価値のあるソフトウェア開発ができることを実感しました。どうもありがとうご

ざいました。引き続き、よろしくお願いいたします。

③ チーム・コラボレーション環境の革新 ③ チーム・コラボレーション環境の革新

185

IBM、IBM ロゴ、ぁbm.cぇm、AIX、CICS、CICSPleぐ、DB2、IMS、IうfぇSえheおe、NeがVeぁく、えきおeScale、RAA、

RACF、Raがぁぇうal、Raがぁぇうal Team Cぇうceおが、SPSS、Sけかがem げ、Tぁぎぇlぁ、WebSえheおe、げ/OS およびｚSecきおe は、

世界の多くの国で登録された Iうがeおうaがぁぇうal Bきかぁうeかか Machぁうeか Cぇおえぇおaがぁぇうの商標です。他の製品名および

サービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、

くくく.ぁbm.cぇm/legal/cぇえけがおade.かhがml をご覧ください。

● 掲載された情報は 2013 年 3 月現在のものです。事前の予告なく変更する場合があります。

● 製品、サービスなどの詳細については、弊社もしくは IBM ビジネスパートナーの営業担当員にご相談ください。

● 本事例中に記載の肩書や数値、固有名詞は掲載当時のものであり、変更されている可能性があることをご了承ください。

zマイスターとの新たな価値探求 rational

Software