IBM i World 2017 Ver /04/21 ー IBM i の視点からみる開発トレンドの動向ー ティアンドトラスト株式会社小川誠

Ver.

IBM i World 2017

ー IBM i の視点からみる 開発トレンドの動向 ー

ティアンドトラスト株式会社 小川 誠

本日の内容

1. IBM i の開発ツールの紹介

2. IBM i システム開発の現状

3. アプリケーション・ライフサイクル管理

- SoR、SoE - ウォーターフォール、アジャイル - DevOps

4. IBM i での開発手法

5. 「異⽂化の衝突」

6. Orion / git デモ

IBM i (AS/400) 従来の開発環境︓ 5250

ベーシックな開発環境

ソースコードはソース・ファイルに保管

エディターは SEU

メンバーの処理は PDM

ソースのバージョン管理は...

ソ ー ス メ ン バ ー ︓ SEU プ ロ グ ラ ム ( * P G M ) CRTRPGPGM (RPGⅢ） CRTBNDRPG (RPGⅣ） ソースファイル 5250エミュレーター IBM i • SEU は V6R1 以降 機能拡張なし • ソースコードのバー ジョン管理は⾏われ ていない

IBM i (AS/400) 従来の開発環境︓ RDi

Rational Developer for i

高機能

ソースコードはPCのディスクに保管

コンパイル時に IBM i へ push

バージョン管理システムとの連携が可能

git、Subversion ソ ー ス メ ン バ ー ︓ プログラム (*PGM) CRTRPGPGM (RPGⅢ） CRTBNDRPG (RPGⅣ） C: Dir ソース１ ソース２ ソース３ RDi プッシュ & コンパイル git や Subverion コミット ソースファイル PCのディスク

新しい オープンソースの開発環境︓ Orion

ブラウザベースの開発環境

ブラウザさえあれば良い（PCへ専⽤ソフトのインストール不要）

オープンソース

Eclipse Foundation（Eclipse プロジェクトを運営する非営利団体）

IBM i 無償ライセンス

ライセンスキー不要 他のサーバーは不要

2016年6月より提供開始

SoR と SoE

データベース SoR (Systems of Records) 基幹システム SoE (Systems of Engagement) 記録のためのシステム クラウド ビッグデータ 繋がり関わるシステム 閉鎖的 寿命が⻑い 資産継承が大事 オープン 変化が速い 資産継承の必要性がない 企業内ユーザー 一般ユーザー / 各種デバイス IBM i

IBM i システム開発の現状（言語）

SoR 開発に用いられている言語

RPG / COBOL RPGⅢ、Ⅳ 今後は FFRPG も利⽤拡⼤ Java

SoE 開発に用いられている言語

Java PHP Perl 今後は Python や Node.js も

IBM i システム開発の現状（問題点）

RPG 技術者の不⾜ / 高齢化

RPG は IBM i プラットフォームのみの言語 「古い言語」というイメージ 将来性はあるのか（不安） RPGⅣ（FFRPG）に移⾏すべきなのか 新しい言語の必要性はわかるが・・・ 要求はされるが RPGⅢ から他言語への習得はハードルが高い RPGⅢ RPGⅣ FFRPG PHP Java その他の言語 複数言語を習得するのは難しい

IBM i システム開発の現状（問題点）

複数の言語経験者によるシステム構築

言語による開発環境の違いがある RPG技術者は SEU/PDM に慣れている 他言語技術者は統合開発環境があたり前 バックグラウンド（あるいは文化）の違い ソースコードのバージョン管理 開発⽅法論 情報共有に対する考え⽅ RPG Java 複数の言語経験者でシステム構築 PHP

IBM i システム開発の現状（RDBMS）

DB2 for i (RDBMS) 新機能 テンポラル表 監査列・・・ DDS SQL

安定（枯れた）機能

DDS 物理・論理ファイル SQL テーブル、ビュー、インデックス 新機能は SQL でのみ可能 既存のデータベースは DDS で作成したものが圧倒的に多いが、 これからは SQL インターフェースが主流となる RPG 技術者

SoR と SoE

データベース SoR (Systems of Records) 基幹システム SoE (Systems of Engagement) 記録のためのシステム クラウド ビッグデータ 繋がり関わるシステム 閉鎖的 寿命が⻑い 資産継承が大事 オープン 変化が速い 資産継承の必要性がない 企業内ユーザー 一般ユーザー / 各種デバイス IBM i

アプリケーション・ライフサイクル管理とは︖

Application Lifecycle Management : ALM

アプリケーション・ソフトウェアの「⼀⽣」を管理 品質や⽣産性の向上 様々な外部要因による変化への対応⼒の向上

様々なツールの使用が前提

要件管理、設計、実装、検証、バグトラッキング、リリース管理など 各ツールが連携することも必要条件

ALM︓ 特徴

プラットフォームに依存しない考え方

IBM i 、Linux 、Windows など、どの開発にも共通 使⽤するツールも共通のものが利⽤可能（のはず）

IBM i Linux

Windows ・・・

ALM で管理すべき項目

システムが利用されなくなるまで管理すべき項目

要望、フィードバックは漏らさず管理されているか きちんと計画されているか（各スケジュール、担当者など） それぞれの状態が把握（⾒える化）されているか ソースの変更管理は⾏われているか 稼働前のテストは⼗分⾏われているか プログラムが正しく配置（デプロイ）されているか

開発手法

システム開発の２大手法

ウォーターフォール開発 アジャイル開発 ウォーターフォール アジャイル 特徴 ⻑期間 局面が厳密に定義されている 後戻りは困難 上記フローは一回限り 短期間 変更が前提 上記フローを何回も繰り返す 重視しているもの ドキュメント コミュニケーションや対話 適しているもの 会社の基幹業務のシステム化 （SoR） 変化の要求が多いシステム（SoE） 要件定義 設計 開発 テスト 注）優劣をつける表ではない

開発手法

少し乱暴な言い方だが・・・

開発者目線のアプローチ︓ウォーターフォール、アジャイル 開発者チームと運⽤チームの共同作業︓DevOps 開発者 ユーザー 開発者チーム 運用チーム

アジャイル・マニフェスト

左記 右記 プロセスやツール 個人と対話 包括的なドキュメント 動くソフトウエア 契約交渉 顧客との強調 計画に従うこと 変化への対応 私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、 よりよい開発⽅法を⾒つけだそうとしている。この活動を通して、私たちは以下 の価値に至った。 すなわち、左記のことがらに価値があることを認めながらも、私たちは 右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/manifesto.html

アジャイル・マニフェストの背後にある12の原則

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味⽅につけることによって、お客様の競争⼒を引き上げます。 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 4. ビジネス側の人と開発者は、プロジェクトを通して日々⼀緒に働かなければなりません。 5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 6. 情報を伝えるもっとも効率的で効果的な⽅法はフェイス・トゥ・フェイスで話をすることです。 7. 動くソフトウェアこそが進捗の最も重要な尺度です。 8. アジャイル･プロセスは持続可能な開発を促進します。⼀定のペースを継続的に維持できるようにしなければなりません。 9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 10. シンプルさ（ムダなく作れる量を最⼤限にすること）が本質です。 11. 最良のアーキテクチャ・要求・設計は、⾃⼰組織的なチームから⽣み出されます。 12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて⾃分たちのやり⽅を最適に調整します。 http://agilemanifesto.org/iso/ja/principles.html

アジャイル︓スクラム開発

チームのコミュニケーションを重視

「スプリント（ソフトウェア開発の工程）」を短い間隔で繰り返す 1. バックログの作成 2. バックログの優先順位、担当者、⾒積（期間、⾦額）などを実施 3. 毎日ミーティングを⾏い進捗等を把握する（デイリースクラム︓朝会） 4. スプリントの最後に実際に動くソフトを使ってレビュー 5. レトロスペクティブ（振り返り）ミーティングを実施（次のスプリントに活かす） １．バックログ作成 ２ ．プ ラ ン ニ ン グ ３ ．朝 会 ３ ．朝 会 ・・・ ３ ．朝 会 ４_．レ ビ ュ ー ５ ．振 り 返 り 実際の開発作業

DevOps

開発（Dev）と運用（Ops）が協⼒

ALM全般に渡って両者が協⼒し、最終的にビジネスの成功を目指す Dev と Ops は利害が対⽴するものではない Dev︓システムへの機能追加を目的とする Ops︓システムの安定稼働を最も⼤切なものとする ビジネスのニーズ︓必要な機能を素早く実装し稼働させる 1. ユーザーが要求を出す 2. 要求を動くプログラムとして開発 3. テスト、配置、運用監視 ツールの使用が必須

ライフサイクル管理でよく使われるツール / 手法

項目 代表的なツール / 手法

ソフトウエア開発手法 スクラム開発

バージョン管理システム git, Subversion

バグトラッキング・システム Redmine, Mantis, Trac

構成管理ツール Chef

継続的インテグレーション（CI） Rational Team Concert, Jenkins

チャット chatwork

仮想化 VMWare, Docker, VirtualBox

これらのツール / 手法を使うことを目的化しない あくまでもツールを使うことで

時間短縮、正確な情報の記録および共有を実現し、 変化に柔軟に対応できるシステム構築および保守を目指す

時間がかかるフェーズについて

要件定義 概要設計 詳細設計 開発 テスト

自動化できれば全体の「高速化」が実現

設計フェーズ︓ドキュメント作成、および管理 開発フェーズ︓プログラマーによる⼿作業 テスト・フェーズ︓要件定義の項目が網羅されているかの確認 時間短縮、属人性の排除を実現可能な様々なツールを駆使する ・プログラム自動生成 ・ドキュメント自動生成 ・テスト自動化 プラットフォームに依存する場合が多い

IBM i での開発手法

ウォーターフォール開発

IBM i で基幹業務システムを開発するケースで利⽤ ただし、新規で開発する案件はかなり少ない

稼働中のシステム保守案件に対して

小規模、短納期、低価格の要求が多い 新規案件も Web 系システム開発などが多い 要件 定義 設計 開発 テス ト IBM i システム開発で アジャイル（スクラム開発） / DevOps

ツールを使いましょう

項目 代表的なツール / 手法 Pattern1 Pattern2

ソフトウエア開発手法 スクラム開発 ○ ○

エディタ RDi, Orion Orion RDi

バージョン管理システム git, Subversion git どちらか

バグトラッキング・システム Redmine, Mantis, Trac Redmine, Mantis

構成管理ツール Chef -継続的インテグレーション（CI） RTC, Jenkins - (RTC) チャット chatwork chatwork 仮想化 VMWare, Docker, VirtualBox -Pattern1︓まずは始めてみよう（ソースのバージョン管理は全ての基本） Pattern2︓SoR システムも早期に管理対象とすること

Pattern1︓Orion, git

エディタ︓Orion

無償、クライアント側はブラウザのみ FFRPG のみだが⼿軽に始められる

バージョン管理︓git

無償、クライアント側はブラウザのみ Orion との連携で⼿軽に始められる 外部の git ホスティング・サービスとの連携可

Orion の利用イメージ

1.

ブラウザから IBM i の Orion サーバーへアクセス

2.

ブラウザで プログラムソースを編集

ソースは IBM i の IFS に保管される

3.

5250 でコンパイル

IBM i Access for Web でも可

プログラム (*PGM) CRTBNDRPG / Dir… ソース１ ソース２ ソース３ 編集 CRTRPGMOD + CRTPGM IBM i の IFS Orion SRCSTMFパラメータ TGTCCSIDパラメータ（5035等に変換） ブラウザ CCSID(1208) TGTCCSID については以下を参照のこと https://ibm.biz/Bdr6K8

git の利用イメージ

Merge / commit

Merge / commit

O r i o n

個人リポジトリ

git ホスティング・サービス Push / Fetch

1.

ネイティブ環境で利用可能な VCS ツール

Orion と連携することによりソースのバージョン管理が可能に

2.

外部の git ホスティング・サービスとの連携が可能

gitHub

Pattern2︓RDi, git / Subversion, Redmine

エディタ(統合開発環境)︓RDi

RPGⅢ、Ⅳ および FFRPG の編集が可能 編集だけでなく、コンパイル（ビルド）およびデバッグなども可能

バージョン管理︓git, Subversion

該当の Eclipse プラグインを導入することで VCS と連携可能

BTS︓Redmine

バックログ管理、バグ管理、情報共有（⾒える化）

RDi / バージョン管理の利用イメージ

各種連携プラグイン C:¥ Dir… ソース１ ソース２ ソース３ 編集 クライアントのディスク RDi リ ポ ジ ト リ ソースメンバー ︓ プッシュ ソースファイル i プロジェクトを使用してローカルにソースを保存 使用するバージョン管理システム用のプラグインを RDi に導入 - Subversion - git PC上のソースとバージョン管理システムで直接更新/コミット / Dir… ソース１ ソース２ ソース３ IFS

Redmine の利用イメージ

VCS / BTS / RDi / IBM i の関連イメージ

No Ticket! No Commit! チケット駆動開発 1. チケットありき 2. チケットに関連コミット№を記録 3. コミット時関連チケット№を記録 4. チケットには作業履歴を記録 チケットを中心に全ての作業記録を 辿ることができるようにしていく

IBM i / RPG の技術者

言語

FFRPG（フリーフォームRPG） 定位置記入形式に慣れていると読み慣れない（別言語のように⾒える） SEU が利⽤できないのでなかなか試せない PHP、Java RPG とあまりにも異なる「外国語」である Web系（通信系）の知識も必要 SoR（基幹業務開発）には正直必要ないと思っている

ツール

SEU / PDM で作業するほうが効率がよい GUI 系のツールは不慣れ バージョン管理、BTS など必要であることはわかるが・・・

若い技術者 / 他言語経験者

言語

定位置記入形式の言語（RPGⅢ、Ⅳ） コードが読めない（標識などの⽤語が独特） RPG サイクルのプログラムは保守不可能 SEU は古臭く思える DB2 for i SQL に慣れていると SoR 的なデータベース・アプローチが複雑に⾒える 物理ファイル、論理ファイルなどの⽤語が独特 DDS でのデータベース作成はハードルが高い（DDL の⽅が簡単）

ツール

統合開発環境に慣れているので SEU / PDMは使いづらい バージョン管理、BTS や Wiki などでの情報共有はあたり前

IBM i は

SoR も SoE も開発可能なプラットフォーム

今後は異文化の開発者が⼀緒にシステム開発を⾏うのは当たり前 IBM i の技術者は・・・ オープン系の開発基準に積極的に関わっていく Orion / RDi などの開発環境 git / Subversion などの VCS FFRPG でフリーフォーム・関数に慣れる SQL インターフェースに慣れる 若手社員 / 他言語技術者は・・・_{IBM i の堅牢な機能を積極的に学習する} FFRPG で SoR の開発に親しむ OS の基本機能をしっかり学ぶ 実⾏管理 回復設計 機密保護 お互いの⽂化を尊重し良いところを積極的に 取り入れていく（真の意味でのオープン）

Orion, git, Bitbucket

IBM i の将来性（ライフサイクル）

2017年04月時点の最新 OS は IBM i 7.3

2018年04月30日で、IBM i 7.1 はサポート終了（EOS）

最新 OS から 2 世代先の IBM i Next + 1 までスケジュールされている

10年以上先までロードマップが策定されており、システムを安心して使い続けることができる

「優しさ」と「信頼」で

お客様のビジネスに “Good Cycle” を。

受託開発 顧客研修 技術開発 信頼性においては定評 のある IBM i をメイン としたアプリケーショ ン開発を⾏います。お 客様とのコミュニケー ションを第一に考え、 最適なソリューション をご提案しています。 外部研修にて IBM i コースを担当する専任 のインストラクターが います。また、お客様 のご要望に応じたオー ダーメイドの研修コー スの提供も⾏います。 IBM i の最新技術だ けでなく、お客様に とって必要になるで あろうコンピュータ 技術を日々蓄積して います。

ティアンドトラスト株式会社

〒111-0053 東京都台東区浅草橋4-16-4 ウィングエイトビル６F フリーダイヤル︓0120-913-474 代表︓03-5821-3666

+

α

＝

T&T

http://tat.co.jp http://tat.co.jp

自己紹介