DevOpsの最初のステップはツールではなく、企業文化の変革
アプリケーション開発とIT運用を組み合わせて自動化すること（一般にDevOpsとして知られる）は、それ自身が自動化するプロセスのようなものであり、イテレーションおよび改善を通じた継続的な変更のプロセスです。そのため、人生のほとんどのことと同様に（おそらく休暇は別にして）、それは旅の行程であって、旅の目的地ではありません。
DevOpsロードマップの「旅の行程」について考えるときは、gitやJenkinsのような、DevOpsツーリングの導入について考えているというのが一般的のようです。実際には、これはスタート地点ではありません。ほとんどの企業にとっては、DevOpsロードマップにおける最初のステップは、本当は企業文化の変革なのです。
ほとんどのIBM i のショップには、IBM i を稼働する陣営と、非IBM i の陣営（たいていは、Windowsおよび.Net、またはLinuxおよびJava/node.jsなどを稼働）の2つの陣営があります。よく見られるのは、非IBM i 陣営がこれらのDevOpsプロセスの一部をすでに導入しているということです。そうだとすると、IBM i 陣営にとって最も合理的と思われるのは、非IBM i 陣営が行っていることに目を向けて、すでに導入されているツールやワークフローを導入し始めることです。同じく目にすることが多いのは、2つの陣営が互いに交流し合っていないことです。そのため、両グループ間で対話が持たれるだけで、これらの問題の多くを解決し始めることができるはずです。
IBM i チームと非IBM i チームを見比べてみると、他にもいくつか重要なことが見つかります。2つのチームそれぞれに、実はまったく同じ処理を行うこともあるコード ベースがあることに気が付くことがよくあります。実際、異なる言語（たとえば、RPGとJavaなど）で同じ機能を書くということになり、DevOpsプロセス全体に悪影響が生じます。両チームを協働させて、プロセスの早い段階でこのような問題に気付くことができれば、二重メンテナンスなどに関連する多くの問題は間違いなく軽減でき、結果的に、DevOpsパイプラインではるかにより良く機能する、全体的により小規模で、よりクリーンなコードベースになるはずです。
また、IBM i 陣営の側にとって興味深いことに、IBM i プラットフォームは、そうした機能を実装するのに適切なプラットフォームとして非常に理に適っています（非IBM i プラットフォーム ではありません ）。IBM i プラットフォームは、ある一定のことを非常に上手く処理します。たとえば、パック10進数演算を非常に上手く処理しますし、大量のトランザクション処理はお手ものものです。一方、非IBM i プラットフォームやそれらの言語（Java、C#、node.jsなど）は、それほど上手く処理しません。
これについての私の考えとしては、DevOpsロードマップには3つの大きな事前ステップがあると思います。最初のいくつかのステップは、ツーリング なしで 行えること、つまり、これまで述べてきた、ドキュメンテーションや企業文化の変革のようなことです。次いで、ツーリングやワークフローの導入（ほとんどの人々が最初のステップだと考えることです）があり、それから、ハイブリッド クラウドまたはオール クラウドへの移行、またはアプリケーションのコンテナ化のような先進的なことです。
ほとんどのIBM i のショップの場合、クラウドへの最初のステップには、おそらくテストの実施が含まれます。実際に何らかの形でオンプレミスなハードウェアからオフプレミスな（クラウド）ハードウェアへとテストをオフロードすることは、非常に意義がある場合もあります。これは一般的に当てはまるわけではありませんが、多くの企業の場合、料金を支払う対象が、どこかに設置されているボックスに対してであって、そのボックスが行うのはテストのみであり、使用されるのはテストを行うときのみであったりします。また、 The Subscription Pricing For The IBM i Stack So Far（IBM i プラットフォームに導入されるサブスクリプション料金方式：これは非常に興味深いものですが）を利用するとしても、数時間、スピン アップされてから、次のテスト サイクルまでは再び使用されないボックスを利用するというのは、あまり理に適っているとは言えません。もっとも、クラウドはそのようなシナリオには最適です。つい最近までは、クラウドの導入はPowerハードウェアではほとんど不可能でした。しかし、今日では、IBM、Microsoft/Skytap、さらにはGoogleも、サブスクリプション ベースでPower 9およびPower10のクラウド スライスを提供しています。
また、企業では、DevOpsに対する多くの抵抗感も見られるようです。DevOpsは手が掛かり過ぎる、または煩雑過ぎるというのが言い分です。あと5年か10年働いたら引退しようと考えているIBM i 開発者も多いため、20年間または30年間、自分のやり方で仕事をしてきたところで、新しいやり方を学びたいとは思いません。
しかし、こういう面もあります。DevOpsロードマップは、でこぼこなフィールドを平らに（条件を公平に）します（競技場のフィールドであれ、戦場というフィールドであれ、比喩の解釈は自由です）。IT全般について言えば、企業の80%が自身を「エリート」DevOpsパフォーマー（1日に複数のイテレーションで、エラーの発生は非常に少ない）であるとみなしていることを示す調査があります。DORAおよび他のグループによる調査では、DevOpsが驚くほど効果的なROIをもたらすことが証明されています。DevOpsを導入しているほとんどすべての企業が、1年未満で十分なROIを実現しており、中にはわずか7か月という企業もあります。ARCAD Software社では「DevOps ROI Calculator（DevOps投資収益率計算機）」を作成していますが、時を経て分かったことは、DevOpsは、企業の開発者に対する支払いをほぼ半減させることになるため、1年に、25人の開発者に平均6万ドル（計150万ドル）を支払っているとすれば、DevOpsによって、その半分、1年当たり75万ドルの節減になるということです。企業も無視するわけにはいかない驚くべき数字です。
DevOpsへの移行は必ずしも難しいわけではありません。どの企業も今日から始めることができます。IBM i のショップが今すぐに行える、最も簡単かつ最も重要なことの1つは、フリーフォーマットRPGを使用し始めることです。IBM i チームがフリーフォームRPGでアプリケーションをゼロから完全に書き直すべきだというわけではありません（リグレッション テストの観点から見れば、費用も掛かり、ばかげているでしょう）が、新機能を実装したり、既存の機能をリファクタリングしたりする場合は、古典的な（固定フォーム）RPGで行うべきでありません。完全フリーRPGへ移行し始めるとすぐに、コード ベースはたちまち、よりモダンでより読みやすいものになり、これは、非IBM i 陣営とのコード共有にも、そうでなければ固定フォームRPGを学びたがらないかもしれない新規採用者にとっても好都合です。また、これは、RPGコードをモジュール化し始めるうってつけの方法でもあります。そうすることにより、IBM i アプリケーションからビジネス機能を抜き出すことも可能になり、それらの機能が非IBMプラットフォームで利用できるようにもなります。また、アプリケーションを完全フリーRPGに変換したい場合は、そうした多くの作業を自動化するのに役立つ変換ツールもあります。変換ツールを利用すれば、手作業で行った場合ほどには、面倒で危険を伴うタスクではありません。
コードをモジュール化し終えたら、ユーザー インターフェース コードからビジネス機能を分離する作業を始めることができます。すでにあなたが書いたものを「壁の向こう側」の人が書き直すのではなく、APIとしてエクスポーズすることができます（あるいはSQLユーザー定義関数またはストアード プロシージャーとして）。余談ですが、Db2 for iデータベースは、すべてのプラットフォームで私がこれまでに見た中で最も完成度の高いデータベースです。Db2 for iはSQLでプロシージャーを定義することができる強力な機能をすべて備えていますが、実際には高水準言語（RPGのような）を呼び出してその機能を実行します。そのような機能は、他のデータベース プラットフォームにはありません。そうした強力な統合性のおかげで、IBM i 開発者は、他のプラットフォームから簡単に呼び出すことができる「ブラック ボックス」のようなものとしてSQLを使用して、簡単にプログラムをエクスポーズすることができます。ということは、壁の両側でそれぞれのツーリングおよび言語を使用して、両陣営が協働していることになります。そして、IBM i 開発者の視点から見れば、彼らは企業のためにより良く稼働するコードを作成しているというだけではなく、彼らの貢献や専門知識が企業にとって極めて重要であることを確かめているのだということです。このことは、このプラットフォームそのものの存続を確かなものにするのにも役立つのです。
したがって、DevOpsの取り組みに乗り出すときには、オートメーションやツーリングは、巨大建築物を作るための1片の（ただし重要な）レンガと考えるようにしてください。成功に不可欠なのは、IBM i 陣営と非IBM i 陣営との間で文化交流を確実にすることです。
IBM i DevOpsで利用可能なオプションの詳細については、以下のウェビナーを参照してください。
[ウェビナー] 「BYOT - Bring Your Own Tool to the IBM i DevOps workflow（IBM i DevOpsへのBYOT（自分のツールの持ち込み）のワークフロー）」
