Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Ver.
IBM i World 2018
次世代技術者に求められること〜 IBM i 30周年の節目に 〜
ティアンドトラスト株式会社 小川 誠
1.0 2018/05/22
本日の内容
1
本日の内容
1. はじめに2. ある⾼齢技術者の反省3. ⾼齢化問題とその対策4. オープンなシステムとは5. 30周年を迎えた IBM i の現状6. 「異⽂化の衝突」再考7. ツールについて8. まとめ
2
はじめに
3
問題提起
4
�IBM i 技術者の⾼齢化と不⾜�システム管理�システム開発(RPGプログラマー)
�システムの⽼朽化�数⼗年に渡って使い続けているシステム�「塩漬け」になっているシステム
この問題にどう対応していけばよいのか︖
目標設定
5
�技術者不⾜、システムの⽼朽化を解消するために
1. 人材確保、人材育成の実現2. システムの刷新を図る
上記を実現するために何が必要か︖何に注意をしていけばよいか︖
ある⾼齢技術者の反省
6
ある弊害(1)
7
�IBM i の最も成功した哲学は「過去の資産の継承」�⼀度構築したシステムを使い続けることを保証�ハードや OS の進化に影響されない�「30年前に作ったプログラム」は最新の OS でも動く
�ただし以下の弊害を伴う�システムの「新陳代謝」が⾏われない
�刷新を⾏うきっかけがない(インセンティブがない)�技術者が固定化(属人化)される
�「あの人でないと修正できない」� 人材がどんどん少なくなる�「私がいないと始まらない・・・」
ある弊害(2)
8
�ユーザー企業
�ベンダー企業
� 保守費用がかからない� ずっと使える(安心)
・開発当時のインターフェースのまま・新機能を実装する機会を逃した・OS の機能を使いこなしていない
� RPGⅢを継続的に保守� 他の言語は知らなくてもよい� 主機能は IBM i で完結 ・テクニカルスキルが更新されない
・技術者の固定化が進む・古い言語を若⼿が敬遠する
「IBM i は古い」という印象が進む
システムの属人化と技術者不⾜が進む
�RPGⅢ 言語で書かれた資産は数多く存在する� AS/400 でもその資産はそのまま実⾏可能� RPG/400 と名称が変わってもコンパイラーはそのままサポート
� 最新の V7.3 でもサポートされている� RPGⅣ は1994年発表
System/38︓1978年発表 AS/400︓1988年発表 IBM i 7.3V5R1︓2001年発表
RPGⅢ 機能拡張ストップRPGⅢ プログラムの開発
RPGⅣ︓1994年発表RPGⅣ プログラムの開発
9
過去の資産の継承の実際(1)
IBM i 7.3V5R1︓2001年発表
RPGⅢ 機能拡張ストップRPGⅢ プログラムの開発
RPGⅣ︓1994年発表RPGⅣ プログラムの開発
�RPGⅢ から Ⅳ への移⾏
� 1994 年から 2001 年の間に IV に移⾏するのが通常だが・・・� AS/400(IBM i) のポリシーは「過去の資産の継承」� 機能拡張はしないが、コンパイラーはその後も提供される
� 既存の RPGⅢ プログラムを保守可能� 新規の RPGⅢ を作成することも可能
現在でも両バージョンが共存している
重要ポイント︕機能拡張ストップしてすでに17年経過
(2018年現在)
10
過去の資産の継承の実際(2)
「過去の資産の継承」の弊害
11
�古い技術がいつまでも「使える」�新しい技術を勉強しなければならない理由がない�技術も「過去の資産」である意味食べていける
�その結果、新技術の重要性を⾒逃していたのでは︖
�古い技術を使い続けた結果、不名誉な評価を受ける
年 バージョン 機能1994 V3R1 IFS、RPGIV、TCP/IP1997 V4R1 インターネット対応強化
HTTP、Domino1999 V4R4 Java2004 V5R3 仮想化技術2008 6.1 OSS
AS/400って古いよねぇ。
⾼齢化問題とその対策
12
大前提として
13
�プログラム⾔語は開発者が多いほうが良い�RPG言語(特にⅢ)はこの点が不利
�一方基幹システムの開発に流⾏りの⾔語で良いのか�例えば PHP 言語はバージョンアップの度に非推奨の機能
が出てくる�このために OS のバージョンアップができないなどもある
�上記を踏まえると・・・�基幹システムは息の⻑い言語を使う必要がある�基幹システム以外はそれ以外の言語を使う�これを実現できるシステムは︖
⾼齢技術者の役割と責務
14
︓Java
・・・PHP Node.js
Python
RPGⅢ
RPGIV
FFRPG
・・
�過去の資産(RPGⅢ)を次世代に引き継ぐ�RPGⅢを若⼿に勉強してもらうのではない�RPGIV および FFRPG 化を⾏うことが⾼齢技術者の責務
若い技術者をどう育てるか
15
�属人化しているクローズドな情報を⾒える化�若⼿と一緒に取り組んでいくことが急務
�様々なツールを積極的に使っていく�エディタ�プロジェクト管理ツール�・・・
そんなコストはかけられない・・・ その結果が属人化なのでは︖
⾯⽩がってもらう、古参の技術者も一緒に⾯⽩がる︕
他のプラットフォームの技術者をどのように迎えるか
16
�オープン系の⾔語を積極的に使いましょう︕� Java でも PHP でも Python でも� IBM i の開発でその技術は十分生かせるはず
�基幹システム寄りには FFRPG を学んでもらう�RPGⅢを習得してもらうことはやめましょう�積極的にGUIツールを使う
�RDi�Orion�Visual Studio など
オープン系の技術者にとってIBM i はとても魅⼒的で
ユニークな開発プラットフォーム
オープンなシステムとは
17
ずっと抱えてきた違和感
18
�「クローズド」なコミュニティと「オープン」技術� IBM i の情報は少ないと⾔われているが
�「山ほどある」(英語だけど・・・)�疑問点を共有するコミュニティがない
�誰かが作ってくれるのを待っていないか︖�オープン系の人は積極的に発信(例えば Qiita とか)している
�「特殊なシステム」なのに新機能は「オープン」�6.1 から特に顕著に�オープン技術の情報はネット上に「山ほどある」� IBM i のものとなると途端に別物と考えていませんか︖
そもそもオープンとは何なのか︖
19
設計や仕様などの全部または一部を、オープン(公開、開放)にし
たアーキテクチャのこと(Wikipedia)
クローズド(閉鎖的)プロプライエタリ(排他・専有的)
オープン(アーキテクチャ)
UNIX 系の総称でもある分散システムを指す場合もある(日本)
OS は独自仕様(Windows も UNIX も同じ)
AIX や Linux の実⾏ランタイム環境を持つ(PASE for i)
オープンな開発言語をサポート(Java, PHP, Python, Node.JS…)
ファイル・システムは Unix/Linux互換の IFS をサポート
IBM i は︖
オープンなシステムとは
20
�ユーザーにとって「しばりの少ない」システムのこと�流⾏りの技術を使っていることがオープンではない�「オープン」な⾔語を使っていても・・・
�それを開発するツールがオープンでなければ「クローズド」
� IBM i は以下の理由でオープンなシステムです︕
� 過去の資産も新しいテクノロジーも常に共存できるシステム� 技術者の新陳代謝がシームレスに⾏えるシステム
� 古いものも新しいものも� テクノロジーも技術者も常に共存できる
21
業務システムの安定稼働
流⾏り廃りや時代の「流れ」
メーカー都合の再構築の圧⼒
不正アクセス
堅実に
積極的に
企業の業務を支えるシステムが持つ宿命であり、必須の要件
OpenSource
Java
Security
XML
JSON
OLAP
PHP
iPhone
Linux
SQL
VM
Node.js
git
Redmine
堅牢
オープン
SoE(Systems of Engagement)
取捨選択
IBM i は「外圧」には強く、オープンである
30周年を迎えた IBM i の現状
22
最新ロードマップの紹介
23
IBM Systems Japan Blog より
2016年のロードマップ
最新のロードマップ
IBM i という OS の役割
24
データベース
SoR(Systems of Records)
基幹システム
SoE(Systems of Engagement)
記録のためのシステム
クラウド ビッグデータ
繋がり関わるシステム
閉鎖的寿命が⻑い資産継承が大事
オープン変化が速い
資産継承の必要性がない
企業内ユーザー ⼀般ユーザー / 各種デバイス
IBM i は両方をサポート
データベース
25
�新しい機能を積極的に使うべき�DDS から SQL へ
�オブジェクト定義の文書化として有効�システム期間テンポラル表の活用(タイムトラベル)�監査列の活用(監査情報の自動記録)
�GUI ツールの活用� IBM i Access Client Solutions のスキーマ
�Oracle SQL Developer のようなインターフェースを提供
�IBM i サービス� SQLインターフェースでシステム情報に簡単にアクセス
「異⽂化の衝突」再考
26
技術者間の摩擦 – ⾼齢技術者と若⼿技術者
27
�⾼齢技術者�基幹システムを作ってずっと保守してきたという自負
�若⼿技術者�新しい⾔語やツールを積極的に使いこなす
�相⼿の考え方が理解できない�⾼齢技術者は若⼿技術者を自分の⼦供のように思う�若⼿技術者は⾼齢技術者のこだわりが理解できない
技術者間の摩擦 – IBM i 技術者とオープン系技術者
28
�⾼齢技術者と若⼿技術者の関係がそのまま当てはまる�お互いリスペクトしあうことが重要
⾼齢技術者IBM i 技術者
若⼿技術者オープン系技術者
当たり前と思っていることが案外そうでないと若い人は教えてくれる
業務、システムの知識および経験が圧倒的に豊富な方々
IBM i の開発現場からみた「異⽂化」の具体例 – (1)
29
�コミュケーション・ツールの活用�例えば slack などで意思疎通の労⼒を圧倒的に削減�いつでもどこでも
�ドキュメントの考え方�想像以上に人間は分かり合えない�記憶や主張は身勝⼿に変わる�だからこそ「正確さ」をとことん追求する
�「朝会」や「チーム会」�今の時代、普通に⾏う�意思疎通、風通しを良くする、ポリシーの繰り返し確認
IBM i の開発現場からみた「異⽂化」の具体例 – (2)
30
�勉強会�技術レベルおよび知識レベルの向上�お互い切磋琢磨できる
�レビュー�コードレビュー、ドキュメント・レビューなど�自分が作ったものは必ず他の人のレビューを受ける
�「読む」�ソース・コードはふつう「読む」�仕様書も当然「読む」
IBM i の開発現場からみた「異⽂化」の具体例 – (3)
31
�将来性のある⾔語を使う� Java、Node.JS、Go、Python・・・�要件によって使い分けるべき(当たり前)
�オープンソースを多用する�いかに「楽をして」コードを書くかを追求する�フレームワークや外部ライブラリを多用する�こうすることが結果的に質の良いコードになる
最新のツールを使うだけではだめ
32
�ツールはあくまでもツール�組織やチームの文化が成熟していないとだめ�最新のツールを採用しても問題は解決しない�ツールは万能薬ではない
�隣の芝生は⻘い�芝⽣が⻘いのはきちんと管理されているから�管理の苦労をしらずただ羨ましがってもだめ
ツールについて
33
クライアント OS
34
�IBM i システム開発の観点から最適なクライアント�Windows
�デファクト・スタンダード�MacOS
�OS が Unix ベースでターミナルが使える
�IBM i Access Client Solutions�両クライアントのどちらでも利用できる
開発ツール(エディタ)
35
�ソース・ファイル(QxxxSRC)からの脱却�7.3 TR4 より、IFS 上の CL ソースからコンパイル可能に�主要言語はすべて IFS からコンパイル可能
�RPG、COBOL、C、C++、CL
�すべての⾔語はフリーフォームで記述可能�様々なエディタを自由に選択可�SEU/PDM の世界からの脱却で生産性が大幅にアップ�若⼿技術者やオープン系技術者はエディタを自由に選択
バージョン管理
36
�git� デファクト・スタンダード� 無償、クライアント側も各種ツールあり� Orion との連携で⼿軽に始められる� 外部の git ホスティング・サービスとの連携可� 分散リポジトリ
�Subversion� 無償、クライアント側も各種ツールあり� 中央リポジトリへのコミット
�両方とも様々なエディタと連携可能� IBM i のソース管理も当たり前の時代
RDi / バージョン管理のイメージ
37
各種連携プラグイン
C:¥ Dir…
ソース1
ソース2
ソース3
編集
クライアントのディスク
RDi
リポジトリ
ソースメンバー
︓
プッシュ
ソースファイル
i プロジェクトを使用してローカルにソースを保存使用するバージョン管理システム用のプラグインを RDi に導入- Subversion- gitPC上のソースとバージョン管理システムで直接更新/コミット
/ Dir…
ソース1
ソース2
ソース3IFS
プロジェクト・バグ管理
38
�Redmine や Backlog が有名� クラウド系サービスも増えてきた
No Ticket! No Commit!
チケット駆動開発
1. チケットありき2. チケットに関連コミット№を記録3. コミット時関連チケット№を記録4. チケットには作業履歴を記録
チケットを中心に全ての作業記録を辿ることができるようにしていく
まとめ
39
これからのシステム開発に求められること
40
�大事なこと「新しい技術をシステムにどう取り込むか」
ではなく「期待される機能を実現できる技術は何か」
IBM i を前提にしないで考えてみる(求められているものは何かを明確に)
それを実現するための最適な言語や技術は何かを検討する
おそらくそれは IBM i で可能なはず
我々技術者に求められること
41
オープンな技術の情報を幅広く集めること︕
その技術をシステム開発で積極的に試してみること︕
オープンなコミュニティに積極的に参加すること︕
IBM i に精通すること︕
そして何より
ユーザー企業目線での後継者育成
42
�流⾏りの技術より業務知識�会社の⼤切な人財に身につけて欲しいのは自社の業務知識�流⾏りの言語知識では決してない
�言語の知識は後からついてくる�言語の知識だけではシステムは決して完成しない
�業務知識を第一としたうえで�言語は最新のものを習得してもらう
�FFRPG や Java、Python など�若⼿に過去の資産を引き継いでもらうために
�RPGⅢ 資産の RPGⅣ(FFRPGまで)化をコストをかけて⾏う
ベンダー目線での技術者育成
43
�IBM i は真の「オープン」なシステムという自覚�特に古参の技術者がその意味をしっかり勉強すること�そのうえでそれを若⼿技術者に引き継ぐこと
�教育するのではなく「一緒に学ぶ」�お客様の要望を⼀緒に「学ぶ」�新しい技術、言語を⼀緒に「学ぶ」�さまざまなツールを積極⼿に導入して⼀緒に評価する�若⼿の技術者を中心に新しい文化・風⼟を作る
「優しさ」と「信頼」でお客様のビジネスに “Good Cycle” を。
受託開発 顧客研修 技術開発信頼性においては定評のある IBM i をメインとしたアプリケーション開発を⾏います。お客様とのコミュニケーションを第⼀に考え、最適なソリューションをご提案しています。
外部研修にて IBM iコースを担当する専任のインストラクターがいます。また、お客様のご要望に応じたオーダーメイドの研修コースの提供も⾏います。
IBM i の最新技術だけでなく、お客様にとって必要になるであろうコンピュータ技術を日々蓄積しています。
ティアンドトラスト株式会社〒111-0053東京都台東区浅草橋4-16-4 ウィングエイトビル6F
フリーダイヤル︓0120-913-474代表︓03-5821-3666
+ =α
T&T
http://www.tat.co.jp
http://www.tat.co.jp
自己紹介
44