DevOpsへの漸進的アプローチ
IBM System/360メインフレームのチーフ アーキテクト、ジーン・アムダール（Gene Amdahl）氏が正確に観測し、その後、体系化された アムダールの法則によれば、どのようなプロセスを実装したどのようなシステムでも、システム全体の処理速度は、その中の一番遅いコンポーネントの処理速度を超えない、ということです。人的プロセスにおけるボトルネックについて当てはまることは、システム設計においても、また、DevOpsとして知られるそうした重複領域（アプリケーション開発とシステム運用の合流地点）においても同様に当てはまります。
全体のパフォーマンスが、一番処理速度の遅いボトルネックを超えないのだとしたら、逆に言えば、その一番遅いコンポーネントのパフォーマンスを向上させることによって、ワークフローまたはシステム全体のスループットを高速化できることになります。DevOpsでは、アプリケーション開発およびデプロイメントのワークフローの、最大のボトルネックとなっている部分を突き止めて、それらの修正に取り組むことを、「バリュー ストリーム管理」と呼んでいます。これは、非常に古くからある考え方に新しい呼び名が付いたものですが、新たなプロセスとシステムのセットにも当てはまります。
それはまた、今日でもまだよく見られる、ウォーターフォール開発手法やモノリシックなアプリケーション コーディング プラクティスから、DevOpsへの転換を成功させる鍵でもあります。DevOpsの取り組みに乗り出す際に頭に入れておくと良い最も重要な考え方は、コーディング プラクティスや運用プラクティスを進化させることを目指す場合には、漸進的なアプローチを取ることができるということです。これこそがDevOpsだというような、テクノロジーおよび企業文化の全面的変化を受け入れる必要はないのです。VS CodeやJenkinsやJiraへ移行する必要もありませんし、自動化された継続的パイプラインへ一気に移行する必要もないのです。
DevOpsの目的（それは私たちが漸進的アプローチを推奨する理由でもあります）は、開発および運用プロセスにおける（さらには、これらのチームがサポートすることになるビジネスにとっての）、混乱を少なく抑えることにあります。DevOpsへ移行することが、とてつもない混乱となるのであれば、それは、目的に反することになります。だからこそ、IBM i 顧客に対しては、常に漸進的アプローチの話をしているのです。
DevOpsは、開発と運用との間でのコラボレーションであり、そうしたコラボレーションの一部には、現在、人力で処理している手作業ステップのいくつかを自動化することが含まれます。ワークフローのプロセスのすべてを自動的にJenkinsパイプラインに移行する必要があるわけではありません。ワークフローのある一部分（最大のペイン ポイント（悩みの種、弱点）と思われるもの）を取り上げて、ワークフローのその部分に対応する現行プロセス部分を自動化することができます。ARCAD社がIBM i プラットフォームで提供しているDevOpsツールの利点は、それらのツールがオープンであり、現行のプロセスに接続できるAPIがあることです。自動化には2つのメリットがあります。1つには、すぐに費用対効果（ROI）を高めることができる点です。自動化したそのプロセスには手作業が介在する必要はなくなるからです。2つ目のメリットは、手作業（開発者は、たとえば、リストのオプションや、何かのリリース番号のキーや、その他のキー値を選ぶ必要があります）が介在するときは必ず、エラーを招き入れる機会になることです。そうしたエラーは、開発の取り組みのROIを大幅に損ねることにもなりかねません。こうした面倒で何度も繰り返す手作業のタスクの1つで犯した小さなミスのせいで、大掛かりな修正作業への労力投入を強いられることもあります（そして、私たちは皆、少なくとも一度は、そうしたミスのせいで本番システムがダウンするのを目の当たりにしたことがあります）。
ソース管理のためにGitを実装することは、大人気でもあり、さらには多少クールな感じさえするため、そこから始めたいと思う人は多いようです。しかし、ソース管理がすぐに価値を生み出すことにはならないこともよくあります。開発者は、ソース コードの管理を行っていることで満足しきっています。そして、ソース管理が最後に残ったボトルネックに対する 解決策になる のは、企業が開発プロセスの 残りの部分 を自動化および効率化し始めるときなのです。ということは、普通は、こうなります。リリースに向けて手作業ですべてのソース コードをまとめている間、1週間も開発が中断するようなことがないように、彼らが構築した自動化プロセスにコードを入れる必要があるということです。
教訓にすべき大事なことは、DevOpsの実装 そのもの に対するこうした漸進的アプローチが、継続的最適化のための実際の機会を提供するということです。これは、ARCAD Software社での経験から得られた知見です。DevOpsの1つの重要な側面は、フィードバック ループです。すでに導入済みのプロセスを1つ取り上げて、何らかの方法で自動化したとします。そして、こう尋ねてみることです。それは、組織全体の健全性にとって本当に有益だったのか。あるいは、自動化できるからというだけで、プロセスを自動化したのではないのか。したがって、たとえば、そうするべきだと思うからという理由で、あるいは、粗悪な変更管理プロセスが修正されると思うからなどという理由で、顧客にソース管理を導入してもらいたくはありません。残念ながら分かったことは、粗悪な変更管理プロセスがあるのだとしたら、ソース管理へ移行しても、自動的には、あるいは魔法のようには修正されないということです。ご自身の変更管理プロセスやアプリケーション開発フロー全体を見直して、こう自問自答してみることです。どうすればこれを改善できるのか。本当のペイン ポイントはどこなのか。どこで摩擦が生じているのか。
ソース管理へ移行すれば、自動的に何の問題もなく並行開発を行うことができると考えている人も多いようです。ソース管理が、プロセスを効率化し、並行開発で生じる摩擦を減らしてくれるのは確かです。しかし、それで並行開発の問題がすべて解決するわけではありません。もちろん、コードの上書きは防止してくれます。そして、コードを決して上書きしない大きな助けになり、代わりにコードをマージしてくれます。しかし、そうしたマージが、必ずしも意味のある結果をもたらすとは限らないのです。Gitは、RPGまたはCOBOL言語を認識しないこと忘れてはなりません。そして、マージの際には、ただ単純に、そうしたコードを機械的にマージするだけです。そのため、理論的には、いったん、そうしたマージが行われた時点で、それはソース変更とみなされることになります。プロセスはそれを認識し、そこからビルドが始まります。しかし、それがコンパイルされ、そのコードが、行うはずのことを行っているか、行わないはずのことを行っていないか確かめるためにテストを行う必要もあります。したがって、確かに、ソース管理を導入すれば、開発者はより安心感を持って並行開発を行うことができるということになります。そして、自由度も高まります。そのことは、今なお多くの人々が大規模プログラムを処理しているIBM i の世界では特に重要です。こうした並行開発の問題が生じる原因はどういうところにあるのでしょうか。たとえば、顧客ファイルの更新（読み取り、書き込み、削除）のすべてを処理するプログラムがあるとします。私が読み取りプロセスを変更しようと思っても、削除プロセスを変更している担当者の作業が完了して、ようやく本番移行するまで待たないと、私の読み取りプロセスは変更できません。それが単一の大きなプログラムであるからです。そこが、大きなボトルネックです。したがって、ソース管理があれば、さらに大きな安心感を持って重複する開発を行うことができます。
けれども、それは魔法ではありません。そして、こうしたSCM（ソフトウェア構成管理）がうまく機能するには、他のツールに対してオープンであることに加えて、漸進的に変更を行って直ちに新たなコードをビルドし、それをテストし、その変更の結果を確認し、生産的な何かを実現しているかどうかを評価できることが必要です。ペイン ポイントを出発点に、そのプロセスを最適化するとしましょう。そして、その作業が完了したとしたら、そのことが意味するのは、 他の何か がワークフローのボトルネックになるということです。そして、最終的には、開発者がボトルネックになるかもしれません。彼らがコードをこの最適化プロセスに供給しないからです。そして、そうした時こそ、ソース管理が間違いなく解決策となるのです。
しかし、もう一度言います。それは魔法ではありません。
DevOpsの取り組みに乗り出す際には、従来のIBM i のショップが直面する最もよくあるペイン ポイントは、テストであることを考慮しておく必要もあります。2番目に大きなペイン ポイントはと言えば、間違いなくデプロイメントです。
興味深いことに、開発者は、最適化プロセスに十分な速さでコードを供給することができなくなるまでは、普通は、問題にはなりません。一般的に、開発者であれば、残りのプロセスを圧倒するのに十分な速さで変更を加えることができます。そうしたプロセスが効率化され、可能な限り自動化されたら、それは非常に魅力的にものになります。より迅速に変更を加えられるからです。多くのIBM i のショップにとっての副産物は、大きなプログラムの開発に掛かる時間が短くなることです。したがって、プロセスを最適化したからには、並行開発はさらに重要になります。
私たちが直面する最後の問題は、マルチスピード開発です。実のところ、これはIBM i プラットフォームに特有の問題です。小さな変更がたくさんあります。機能強化の提供や問題修正のために、1つのプログラムまたは少数のプログラムを変更しているからです。その一方で、私はフィールドを拡張するか、ファイルにフィールドを追加するかしなければなりません。これらの作業それぞれに対する開発の労力は同じくらいかもしれませんが、必要なテストの量は大きく異なります。フィールド変更の影響は、はるかに広範に及ぶからです。やはり、ここでも、テストが足手まといということになります。しかし、テストを最適化し、フィールド変更にオートメーションを適用したときでも、影響を受けるすべてのプログラムの連鎖反応があります。そうなると、テスト要件が増えます。そういうわけで、オープンソースの世界から取り込んだ機能の1つが、大規模プロジェクト向けにテスト環境を動的に構築しているのです。実際、顧客の間でも大人気です。私たちがソース管理に目を向けるようになる前から、この機能はありました。本稼働中のIBM i 上にテスト環境を構築することができるため、大規模プロジェクトをそこに入れて、隔離することもできます。
しかし、もう一方の変更が進行している間に、その大規模プロジェクトをテスト環境に戻す術が必要です。危険なのは、様々なプロジェクトをテストするための様々なテスト環境がある場合です。それらのプロジェクトの統合性を本番でテストしたくはないものです。もっとも、そうする羽目になる人もいるのです。大規模なプロジェクト テスト環境があり、PTFテスト環境があり、両方ともそこから本番に移行します。しかし、実際には、彼らは本当に 本番環境でテストしているのです。これはどう見ても、無謀なことです。本番に移行する前に、コードとPTFが 統合されて動作する ことを確かめておく必要があるのです。
IBM i DevOpsへの漸進的アプローチについての詳細は、以下のウェビナーを参照してください。
[ウェビナー] Power of Automation: Integration brings Transparency（オートメーションのパワー: 統合がもたらす透明性）
