次の見どころ: IBM iアプリケーション開発のマルチプラットフォーム ショー
マルチプラットフォーム開発というものは、現実というよりはビジョンです。アプリケーション開発は今でもサイロ化した環境です。これは、夢想家たちが思い描いているよりも、プログラミングは孤立的で非協働的な作業のままであるためです。そのため、1つの組織内での複数のプログラミング環境が存在することで、それらが一体となって機能するという目標が達成されることはまずありません。チームワークがもたらす潜在的なメリットの多くは、手の届かないままです。存在しているのは、共通の業務を担った単一のチームではなく、個別の業務を担った個別のチームなのです。
良いニュースがあるとすれば、以前に比べればましになっていることくらいでしょうか。それでも、マルチプラットフォームの統一ファブリックと、それが開発プロセスにもたらすとされる効率は、決して立派だとは言い難い実績からすると、疑念を抱かずにはいられません。
それらはすべて、どうしようもないことなのでしょうか。ほんの5年前と比べると、ヘテロジニアスな環境は快適になっています。実際、快適さは、セキュリティ上の脅威の高まりとは関連があるものの、ヘテロジニアスな環境とはさほど関連がないようです。なぜなら、エンタープライズ コンピューティングが変わりつつあるからであり、適応は絶滅よりもましな選択であるからです。
マルチプラットフォーム開発は、エンタープライズ コンピューティングが変わって行く、その1つの変わり方に過ぎません。意志決定者たちは、多種多様な選択肢を基に、正しい順序でボタンを押しながら、自らのIT計画を調節して生産性およびコスト削減の改善を図ってきました。
ある特定のアプリケーション開発チームが縮小することは、目新しいことではありません。そうした事態の主因は人員の自然減少であるように思われます。そして、それに伴うのはスキルのある人材が集まりにくくなったことを嘆く声です。しかし、それは別の話です。そのテーマについては、 『IT Jungle』 で何度も取り上げてきました。結果として、マルチプラットフォーム チームの統合と調整がより広範囲に行われるようになっているのを、我々は目にしているわけです。
プログラミングに求められるものがますます複雑になって行くのにつれて、組織はKPI（重要業績評価指標）に基づいてマルチプラットフォーム開発チームを結成するようになるでしょうし、従来のサイロ化したやり方で生まれた業務上の問題を解決する現在の経営モデルに生じるギャップに取り組むようになるでしょう。進化している世界においては組織構造やレガシー テクノロジーがターゲットになります。20年来の技術的およびビジネス上の制約の多くは、もはや当てはまらなくなっています。そして、特に、技術的能力は、ほんの数十年前に想像されていた範囲を越えて拡大してきました。企業を取り巻く環境は一変しており、老舗企業には、時代の流れについていき、競争力を保つよう求めるプレッシャーが掛けられています。
しかし、変化の裏には不変性があります。すなわち、今ここにあるものが「次に良いもの」より優れているという信念と、技術を売り込むときの約束は後で達成不能と分かるのが常だという警戒心があるからです。また、ソフトウェア販売サイクルが強調され過ぎたあまり、アップグレードの繰り返しに企業が不信感を抱くようになってしまったパターンもあります。極端なケースでは、組織がアップグレード サイクルをひどく押し進めた結果、深い塹壕にはまり込み、前に進むにも難しい高くつく選択肢しか残されていない状況にがんじがらめになってしまったケースもありました。
改革への抵抗と現状維持は、厄介な障壁です。多くの場合、それは変革にとって最初で最後の障壁です。しかし、経営効率が詳細に検討されるようになるのにつれて、従来の組織の境界は、より優れた規模の経済性や論理的なワークフロー プロセスを求めてゆくなかで消え去りつつあります。
変革が起こるときに見落とされがちなのが、従業員に対する投資です。新たなスキルの習得と、変革にまつわる情報の普及なしで変革は起こりません。個人としておよびチームとしてより効果的に作業を行う方法についての知識は、突然備わるものではありません。人々が進んで責任を共有し合い、肯定的な結果を生み出そうとするようになるには、トレーニングおよび教育のカルチャーが環境として整えられている必要があります。成功を妨げる障壁が現れたときに、そんなものは存在しない、あるいはそのうち消えてなくなるなどと、うそぶいているだけでは消えてくれないのです。
大企業は、いつもそうしているように、マルチプラットフォーム コードを展開し、中央で一元管理する方式を他に先駆けて実践しています。IBM i、z/OS、AIX、および他のUnix OS、またはすべてのオープンシステム上で稼働するように作成されたかどうかにかかわらず、すべてのコードを管理するために標準化されたツールおよび方法論を彼らは利用しています。
我々がこれまで見てきたのは、マルチプラットフォーム統合が、コアとなるIBM iコミュニティの外側で、はるかに大きな範囲で根を下したことです。一部のケースでは、これらはIBM iも混在している組織であり、IBM iが支配的な役割を担っているわけではありません。役割についてはともかくとして、IBM i環境はマルチプラットフォーム環境の一部になるわけです。このシナリオは、IBM iとオープンソース開発との出逢いのために描かれていたシナリオでもあります。得られた経験は、IBM iが支配的な役割を担っている組織において必ず活かされることになります。
RPGは、圧倒的大差で選ばれるIBM i開発のためのプログラミング言語です。しかし、Java、.NET、第四世代オプション、およびPHPによって主導される増え続けるオープンソース オプションといった他の言語は、IBM i環境におけるマルチプラットフォーム開発を、潜在的なコラボレーションのための検査場として利用しています。
ほとんどのIBM iプログラマーは、ビジネス アプリケーションを書くための最良の言語はRPGだと思っています。複数の言語を知っているプログラマーでさえ、たいていの場合、ビジネス アプリケーションにはRPGを選びます。RPG以外のバックグラウンドを持つ開発者は、独自のツールおよび手順を持っています。いくつかはこれまでになくRPGにより近づいており、おかげでクロスプラットフォーム開発はかつてよりも行いやすくなっています。IBMのRPGロードマップは、RPGと他の言語との間のギャップを縮める方向へ進んできており、この傾向は続くと見込まれます。IBM iでのオープンソース ソフトウェアのサポートには重点が置かれており、コミュニティは増大しつつあり、盛況を帯びています。
オートメーションは、数多くの開発環境における手動のプロセスを置き換えるため、強力な武器となります。コードの1行目から開発最終段階まで関わる方式の開発は、オートメーションへの置き換えや、効率性の高い手法へのアップグレードを行うべき時期が来ているようです。開発を行ってはトライアルアンドエラーのテストを行う方式の開発は、効率が悪く、無謀であり、そうした時代はまもなく消えて行くでしょう。古いエラーの発生しやすいやり方と、独立して動いている開発環境の数とを掛け合わせれば、運用上の弱点およびコスト リークを見つけるのは難しくありません。テストの改善と統合は、複数のプラットフォームに適用するインパクト解析とともに、開発が行われるやり方を変えることを促すメリットの例と言えるでしょう。
それでもやはり、各々が独立して動くことができ、統一のための統一が価値ある目標であると納得していない人たちから成るチームをまとめることは難題であり、完全に効率的でない限り、古いやり方を破滅する結果は残せません。 しかし、現状を維持することでは、業務の効率化へ向けたいかなる組織の取り組みに関しても、大きな進歩を示すことはありません。とすれば、エグゼクティブたちもこれ以上見て見ぬふりはできないでしょう。
