いまどきのエンタープライズ開発 †
要約 †
本論に入る前の背景説明。
導入 †
ソフトウェア業界で「エンタープライズ」というと、大規模で複雑なプロジェクトや事業を表すときもあれば、一般的な企業そのものを指すこともある。
「エンタープライズ」は、大企業であるがゆえに新しいテクノロジーに適応できないという文脈で使われることが多い。
大企業で複雑かつ安定したアプリケーションをつくるときの標準的なプラットフォームになった技術が、Java Enterprise Edition (Java EE)だ。このテクノロジースタックは1998年生まれのベテランで、最先端の技術や開発パラダイムに適応したりすることを意図したものではない。
しかし、大企業や大規模プロジェクトを動かす原動力はイノベーションや継続的改善だ。
イノベーションがなければ、時代遅れで高くつくインフラコンポーネント（ほら、大昔のホスト環境とか…）になり、それが本来想定していた期間よりはるかに長期間にわたって行き続けることになってしまう。現状に即しているかどうかを検証しつづけなければ、いつの間にかベンダーにロックインされてしまうだろう。延長サポートを受けつつ大昔のミドルウェアを使い続けていると、いつの間にかその環境での開発ノウハウを持つ業者がほとんどいなくなってしまう。
だいたい5年から10年おきに、ソフトウェア業界全体（特にエンタープライズインテグレーションやエンタープライズアプリケーション領域）で新しい方法論やアーキテクチャスタイルが登場する。それらは「今までの10倍の生産性！アジャイルでフレキシブルでレスポンシブ！」みたいに訴えかけてくる。エンタープライズアプリケーションインテグレーション、ウェブサービス、SOA、コンポーネントベースアーキテクチャ、ESBなどなど、いろんなものが生まれてきたよね。
企業のゴールと目的 †
テクノロジーの進化に伴い、企業のIT部門は新しい機能やプロセスを組織に導入していった。技術的な標準化と社内業務のコスト削減を実現しているにもかかわらず、IT部門はビジネスのニーズをわかっていないと非難される。
事業部門や購買部門の意思決定は今でも、即効性のある投資と長期的なコスト削減を重視している。そのため、新規ビジネス要件や市場開発などの必要性を見落としてしまう。
変更に耐えて、経済面でも効率的 †
Java EEアプリケーションサーバーを全社標準として導入することで節約できる額と、個々のプロジェクトでソースコードを精査する手間やメンテナンスコストを比較すれば、その投資対効果は一目瞭然だ。長期サポートやライセンス契約についても同じで、インフラやそれにまつわるあれこれを年に何度も変更するのなら、これまでのサポートレベルの低下を覚悟する必要がある。
…というわけで、最新のすばらしいテクノロジーと企業の開発者が使える技術の間のギャップが年々大きくなる。
置き去りになる開発者 †
ざっと上っ面を眺めただけではあるが、開発者たちが感じている疎外感の理由がこれではっきりした。
毎日毎日同じ技術スタックで戦うのは、ありがちな落とし穴や欠点に関する知識を蓄えるという意味ではいいことだろう。でも、もっとエレガントに素早く問題解決できる方法があるかもしれないのに、そこから目を背けてしまうことにもなる。
技術重視かビジネス重視か †
旧来型企業の多くはビジネス主導で、IT部門や運用部門はコストセンター扱いだった。
均質なITサービスを提供するために、標準プラットフォームを作ろうとして、
ITアーキテクチャやテクノロジーを選択するプロセスに注力しすぎていた。
その結果できあがるのは、「ビジネスドメインとそれに関連するプロセスの標準化と最適化で、単なるオペレーションの最適化よりもはるかに高い投資回収を約束する」という一見よさげなものではあるが、それはビジネスソフトウェアの真の価値から目をそらしたものだ。
幸い、多くの組織がこれに気づきはじめて、より簡単で効率的なアーキテクチャ管理に向けて動き始めている。しかし、変化は必ずしもトップダウンである必要はない。開発者やアーキテクトひとりひとりにも、変化する責任がある。
本書の狙いと扱う範囲 †
このレポートで注目するするのは、以下の二点。
- 企業がどのように動いていくのか
- 最新テクノロジーをいつどのように導入するかを理解することで、状況をどのように改善できるのか
重点を置くのは、Java EEのデザインパターンを理解すること。さらに、それをmicroservicesやDevOps?といった新しい開発パラダイムと組み合わせる方法を理解することだ。
担当者のつぶやき †
みんなの突っ込み †
