• 検索結果がありません。

PowerPoint Presentation

N/A
N/A
Protected

Academic year: 2021

シェア "PowerPoint Presentation"

Copied!
22
0
0

読み込み中.... (全文を見る)

全文

(1)

適材適所の言語選択と

効率化ソリューションのご紹介

日本アイ・ビー・エム株式会社

IBMシステムズ・ハードウエア事業本部

ハイエンド・システム事業部

山田 義昭

(2)

目次

1. 適材適所の言語選択

2. z/OS効率化ソリューションのご紹介

(3)

開発者の不足とは?

改良開発におけるコーディング

量は少ない

開発ツールの統合

分散系の開発手法の適用で効率化が可能

COMPUTE A = A + B IF A > 100 THEN MOVE C TO A ELSE MOVE D TO B ADD X TO A : 追加 END-IF

COBOLやPL/Iは習得が容易

1人の担当者が、

Javaで記述されたフロン

ト・エンドのアプリケー

ションとCOBOLで記述され

たバック・エンドのアプリ

ケーションの両方を担当す

ることは難しくありません。

開発者の不足は開発言語の問題でしょうか?

3

(4)

COBOL資産の状況

【グローバル】COBOLの統計情報(eWeekより)

□新規に開発されているCOBOLプログラムは年間50億行に達する

□全てのdaily business transactionsのうち80%以上はCOBOLアプリケーションによる ものである □世界中の業務データの70%以上はメインフレーム上に保存されている □ミッションクリティカルなアプリケーションの70%以上はCOBOLで書かれている □行数で見ると、現在使われている全SWの65%以上がCOBOLで書かれている □COBOLアプリのトランザクションはGoogle検索トランザクションの200倍に達する □業務上のCOBOL人口はおよそ200万人 【日本】 □金融業全般ではCOBOLが主流(分散系でも使用) □全業種メーカーに関係なくメインフレームに関してはCOBOLが多数 Page 4

4

出展:eWeek http://www.eweek.com/c/a/Application-Development/Modernizing-COBOL-Apps-10-Reasons-Why-Its-Important-736307/

(5)

基幹系アプリケーション開発と開発言語スキルの関係

• 基幹系アプリケーション開発に求められるスキルは、大部分が

「業務スキル」(例:商品やサービス、事務手続き)です。

• 開発言語に関するスキルは重要性としては相対的に低いものと

考えられます。

商品・サービス処理 80% 事務に係わ る処理 12% アプリ制御、外部システム接続など 8% アプリケーション分類 図: 金融系A社基幹システムにおけるアプリケーションの分類 0% 20% 40% 60% 80% 100% アプリ制御、外部システム接続など 事務に係わる処理 商品・サービス処理 60% 88% 90% ビジネス・ロジック比率 ビジネス・ロジック 左記以外

5

(6)

業務特性に応じた言語選択

6

記録を軸とした基幹システム

(Systems of Record: SoR)

人と関わりあうシステム

(Systems of Engagement: SoE)

長期安定、上位互換保証、業務スキル 継承が重要 仕様が安定し、学習が容易でビジネス・ ロジックを簡単、確実に実装可能な構造 化設計と手続き型言語が適している。 最新テクノロジーの採用を優先する。 分散コンピューティングやプレゼンテーショ ンが得意なオブジェクト指向設計/言語が適 している。 相互作用 何が必要かを定義して 一度に作る 少しずつ作って 仮説検証を繰り返す トランザクション トランザクション

API

常時変化、スクラップ&ビルドもあり、 早く安く構築/調達/改善

業務特性、システムのライフ・サイクルや時代の変化などを勘案して

開発言語を選択すべきと考えます。

(7)

業務特性に応じた適材適所の開発言語選択

人と関わりあうシステム(SoE) 記録を軸とした基幹システム(SoR)  MVCモデルのVとCの部分(*)  変化しやすいプレゼンテーションやコン トロールであり、分散コンピューティン グとプレゼンテーション機能が得意な 「流行の」言語で良い  マスター・データを共有することは少な く、非機能要件は並列、分散して全体で 高めることができる  ライフ・サイクルが短いため、早く、安 く作って、場合によっては スクラップ・ アンド・ビルドで対応する  市場のスキルを早く安く調達する方針で 良い MVCモデルのMの部分(*) オブジェクト指向などのクラス抽象化や継承 機能などの効果は非常に少なく、構造化設計 で業務ロジックを確実に実装、検証できる手 続き型のシンプルな言語が適している マスター・データを共有するオンライン処理 とバッチ処理が混在のため、CPU効率とI/O 効率重視でメモリー・リークなどの心配のな い安定性のある実行環境が必要 ライフ・サイクルが数十年と長いため、言語 の安定性、上位互換性が必須で、システム構 造、データベース構造、設計思想、非機能要 件実装上の工夫などの伝承が重要 その点でも長期IT人材育成の投資も価値があ る 堅牢性や安定性が重視される「SoR」と柔軟性や拡張性が重視される「SoE」において、 それぞれのシステムのライフ・サイクルや時代の変化などを勘案して開発言語を選択すべき と考えます。 (*)MVCモデル:ソフトウェアの設計モデルの一つで、処理の中核を担う「Model」、表示・出力を司る「View」、入力を受け 取ってその内容に応じてViewとModelを制御する「Controller」の3要素の組み合わせでシステムを実装する方式。

7

(8)

【参考】 MVCモデルとは

(9)

リライトで開発生産性は向上するか?

• レガシー化は言語が原因ではありません。

- 他の言語にリライトするだけでは問題は解決しません。

• COBOLとJavaの生産性に大きな差はありません。

9

出典: 独立行政法人情報処理推進機構, ソフトウェア開発データ白書2014-2015, 2014.10.1発行

配布資料には含まれておりません

(10)

リライトのリスク例

• 例えば以下のようなリスクがあり、慎重に調査、検討が必要です

- 文字コードの違いによる文字化け、外字領域不足、ソートの結果相違

- パフォーマンス劣化

CPU時間

I/O処理時間

Java化により数倍から数十

倍単位でCPU時間が伸長

COBOLバッチの単体実行時

Javaバッチ化後の単体実行時

CPU時間

I/O処理時間

10進数演算 パック10進数変換

COBOL

265.8ミリ秒

146.6ミリ秒

Java

1985.8ミリ秒

2167.9ミリ秒

7.5倍

14.8倍

※ 同一演算を同一プラットフォーム(分散系)で実行して比較したもの COBOLとJavaの性能比較※

10

配布資料には含まれておりません

(11)

メインフレームおよび開発言語についてのIBMのコミットメント

 メインフレーム(z Systems)への投資 – z13では研究開発に13億ドル(120円換算で1560億円)を投資し,全世界の18の研究所 が24時間体制で開発しました。 – 開発には2,500人以上 のIBM社員が3年間で、のべ1,500万時間以上を費やしてきまし た。 – 40名以上のIBMフェローと技術理事(Distinguished Engineer)が研究開発プロジェクト をリードしています。  プログラミング言語の継続開発

– PL/I およびCOBOLに対する IBM のコミットメントを継続することを明確に示していま

す。

– IBM が 30 年以上にわたって培ってきたアプリケーション開発経験を今後も継続してご

活用いただけます。

IBMは、長期的なメインフレーム戦略を明確にする『IBMメインフレーム憲章

(IBM Mainframe Charter)』を2003年に発表し、継続的な投資をお約束して

います。メインフレーム憲章は、z Systemsのお客様に対して、将来的な投資計

画のためのフレームワークを提供し、一貫した価値 を提供していくことを目的と

する新しい戦略です。

(12)

IBMはメインフレーム基盤とともにPL/I言語製品に対しても継続的な投資を行い、 機能の拡張を行っています。現行のアプリケーションおよび開発環境を、将来に向けて 安心して使い続けることができます。

IBMのPL/I言語製品について

3.1 3.23.3 3.4 3.5 3.6 3.7 3.83.94.1 4.2 4.34.4 2000 2010 1990 1.1 2.2.0 2.2.1 2.12.22.3 •IMS および DB2 のミドルウェ ア・サポートの向上 •コンパイラー・パフォーマンスの 向上 •デバッグ機能を改善 •Web 相互運用性を改善 •SQL サポートの機能拡張 •生産性の改善 •デバッグ・ツールの機能拡張 •ユーザビリティ機能拡張 •保守容易性の改善 •XML のサポート向上 •UTF-8 および UTF-16 のサポート の強化 など 機能 使いやすさ パフォーマンス 4.5

12

1.5.1

(13)

IBMはメインフレーム基盤とともにCOBOL言語製品に対しても継続的な投資を行い、 機能の拡張を行っています。現行のアプリケーションおよび開発環境を、将来に向けて 安心してお使い続けることができます。

IBMのCOBOL言語製品について

3.1 3.2 3.33.4 4.1 4.2 5.1 5.2 2000 2010 1990 1.1 2.1 2.2 1.2 1.3 1.4 •IMS および DB2 のミドルウェ ア・サポートの向上 •コンパイラー・パフォーマンスの 向上 •デバッグ機能を改善 •Web 相互運用性を改善 •SQL サポートの機能拡張 •生産性の改善 •デバッグ・ツールの機能拡張 •ユーザビリティ機能拡張 •保守容易性の改善 •XML のサポート向上 •UTF-8 および UTF-16 のサポー トの強化 など 機能 使いやすさ パフォーマンス

13

1.2.4 1.2 6.1(New)

(14)

第一章のまとめ

• それぞれのシステムのライフ・サイクルや時代の変化などを勘案し

て開発言語を選択すべきと考えます。

• 開発者に求められるスキルは、業務スキルが重要で、開発言語のス

キルは相対的には低いと考えられます。

• リライト(開発言語の移行)するだけでは、レガシー化を改善すること

はできません。

• IBMはz SystemsやCOBOL、PL/Iといった開発言語をお客様に長

く、安心してお使いいただけるようこれからも開発に多大な投資を

行います。

14

(15)

目次

1. 適材適所の言語選択

2. z/OS効率化ソリューションのご紹介

(16)

リノベーションの3ステップ

リノベーションは段階的に実施することを推奨いたします。まずは「見える化」によりアプリ ケーション資産の総量や性質を把握し、改善ポイントを洗い出します。次に「効率化」により 開発生産性やスピード、品質を向上します。これらを実施することにより「先進化」への迅 速・柔軟な対応が可能となります。

見える化

効率化

先進化

INPUT A, B, C. IF A > B THEN IF A > C THEN MOVE A TO R ELSE MOVE C TO R; ELSE IF B > C THEN MOVE B TO R ELSE MOVE C TO R; END-IF PIC(9) C PIC(9) R PIC(9) B PIC(9) A #1 Type 1 0 2 0 PIC(9) C 0 1 #1 0 1 #2 1 0 #3 PIC(9) R 1 PIC(9) B 0 PIC(9) A #4 Type 1 0 2 0 PIC(9) C 1 0 1 #1 2 0 1 #2 1 1 0 #3 1 PIC(9) R 1 PIC(9) B 0 PIC(9) A #4 Type Test result INPUT A, B, C. IF A > B THEN IF A > C THEN MOVE A TO R ELSE MOVE C TO R; ELSE IF B > C THEN MOVE B TO R ELSE MOVE C TO R; END-IF PIC(9) C PIC(9) R PIC(9) B PIC(9) A #1 Type 1 0 2 0 PIC(9) C 0 1 #1 0 1 #2 1 0 #3 PIC(9) R 1 PIC(9) B 0 PIC(9) A #4 Type 1 0 2 0 PIC(9) C 1 0 1 #1 2 0 1 #2 1 1 0 #3 1 PIC(9) R 1 PIC(9) B 0 PIC(9) A #4 Type 1 0 2 0 PIC(9) C 1 0 1 #1 2 0 1 #2 1 1 0 #3 1 PIC(9) R 1 PIC(9) B 0 PIC(9) A #4 Type Test result Linux on z z/OS WAS/z WAS Worklight Server IMS DB2 DB2 CICS

支援サービスやツール

利用による見える化

支援サービスやツ-ル

利用による効率化

CAMSS対応※

柔軟なビジネス・ルール

への対応

開発の効率化

DevOpsのプラクティス

対象領域/課題の

明確化

※Cloud/Analytics/Mobile/Social/Security

16

(17)

Page 17

スタート地点

機能追加

機能追加

機能追加

• 保守等によるシステム使 用不可時間を削減すること による開発生産性の向上 •コーディング補助、サービ ス生成、リファクタリング 支援機能による迅速な z Systemsアプリケーショ ンのモダナイズ •コード検査、単体テスト自 動化、コードカバレッジに よる品質向上 •更に迅速、柔軟なテスト の実施 •z System環境から単体テ スト環境をオフロードす ることによるCPU資源の 削減 •変更による影響が早い段 階で理解できるため実機 反映の時間が短縮可能 •新規参加メンバーが習得 する時間が短縮 •ツール、チーム、プラット ホームに縛られない統合さ れた変更管理、処理、ソー ス管理 •自動化された手続きの施行 によるリスクの軽減と、監 査においてはコンプライア ンスの委任が可能 •z Systemsのソース管理コ ストを削減 RDz z Systems用のコンポーネ ントを実装した最新の統合 開発環境(IDE) RD&T 分散環境におけるz/OSア プリケーション開発と単体 テスト環境 RAA 迅速なアプリケーション影 響分析 RTC 様々なチーム、プラット ホーム、プログラミング言 語間のコラボレーションと ガバナンスを提供

17

参考) z Systemsにおける継続的インテグレーション(CIz)

柔軟に追加機能を適用可能な点が、

z Systems開発環境におけるIBM統合ソリューションのメリットです

(18)

今回ご紹介の効率化ソリューション

18

*2015年の当セミナーではRDz/RD&T/RTCを連携させた開発/テストプロセスの

効率化をご紹介しました

https://www.youtube.com/watch?v=V_bLMhdZwlA

(19)

19

リリース&デプロイメントの自動化 (IBM UrbanCode)

 コスト削減

- 手作業、待ち時間、手戻り作業の

削減

 Time to market

- リリース頻度の増加

 リスクの低減

- コンプライアンスに対応しつつ、

品質の高いアプリケーションをリ

リース

UrbanCode v6.1からz/OS向けのリリース&デプロイメント自動化が可能に

品質高く、少ないリスクでモバイル、クラウド、ビックデータ、トラディショナル

なアプリケーションのデリバリーを迅速化

(20)

デモの概要

20

ソース修正

ビルド/

単体テスト

<今回のデモ>

デプロイ作業

・準備

・申請

・承認

・実施

こちらはYouTubeで ご覧ください(前述)

RDz

RDz/RD&T

RTC→Urban Code Deploy

(21)

第2章のまとめ

DevOpsの核となる自動化、コラボレーションの

ソリューションをz/OS環境においてもオープン系と

同じプロセスで実施、管理することができます

☆プラットホームや言語に依存しないプロセス

☆IDEやWebインターフェイスによるオペレーション

☆SoE/SoRアプリの開発、リリース期間の短縮

21

(22)

参照

関連したドキュメント

年限 授業時数又は総単位数 講義 演習 実習 実験 実技 1年 昼 930 単位時間. 1,330

Jabra Talk 15 SE の操作は簡単です。ボタンを押す時間の長さ により、ヘッドセットの [ 応答 / 終了 ] ボタンはさまざまな機

[r]

22年度 23年度 24年度 25年度 配置時間数(小) 2,559 日間 2,652 日間 2,657 日間 2,648.5 日間 配置時間数(中) 3,411 時間 3,672 時間

19年度 20年度 21年度 22年度 配置時間数(小) 1,672 日間 1,672 日間 2,629 日間 2,559 日間 配置時間数(中) 3,576 時間 2,786 時間

1.3で示した想定シナリオにおいて,格納容器ベントの実施は事象発生から 38 時間後 であるため,上記フェーズⅠ~フェーズⅣは以下の時間帯となる。 フェーズⅠ 事象発生後

「Long Interval Time」には、ロングインターバル時間(0~355)(単位: ms)を指定し、GUI 上で算出したロング インターバルベース時間(Measurement Mode

 STEP ①の JP 計装ラックライン各ラインの封入確認実施期間および STEP ②の封入量乗 せ替え操作実施後 24 時間は 1 時間に