1. IT課題の解決がなかなかすすまない
   1. 生産性が上がらず、品質も安定しない
   2. 運用管理に手間と費用
   3. 技術者育成がすすまず、リテンションも低い
2. 課題解決に向けた取り組み
   1. Java開発標準化が各社で行われた
      1. 2000年代初頭
         1. 多数の独自FW乱立
            1. J2EEの機能不足をサードパーティー製FWで補う
            2. フレームワークチーム
            3. メンテナンス
            4. 開発標準化のガバナンス
      2. ITコスト削減が要求される
         1. 独自FW路線の継続は難しい状況
            1. ユーザー企業のFW、ベンダーFWとのミスマッチ
            2. 開発コスト
            3. 運用コスト
            4. ロックイン
            5. フレームワーク担当チームのオペレーションコストが大きい
            6. バージョンアップ
            7. セキュリティ対応
            8. 人材配置の最適化
         2. オープンソース製品へのロックインリスクの露呈
            1. ベース技術の陳腐化
            2. プロジェクトのEOLやセキュリティ対応コスト
            3. バージョンアップ時の動作検証など追加コスト
3. Java EE セントリックなアプリケーション開発標準化
   1. OSSプロジェクトの静かを取込み,Java EE はフルスタックのフレームワーク機能を提供
   2. 課題解決
      1. ユーザー企業とベンダが同じJavaEE FWを利用する
      2. フレームワーク単体のメンテナンスは不要
      3. 必要な技術範囲が Java EE 標準技術に適正化
   3. 開発標準の整備には今が絶好のタイミング
      1. ユーザー企業
         1. 開発の内製化
            1. アウトソースしすぎた
            2. 自社技術者の育成
            3. 開発のコントロールを自ら行う
      2. バッチ処理標準化
         1. メインフレームのダウンサイジング
      3. 商用APサーバーが出そろう
4. 勘所
   1. メリット
      1. 最大のメリット
         1. 標準
         2. 後方互換性
      2. 特定の企業、団体に非依存
      3. ハードOS選ばず
      4. 標準API
      5. 後方互換を維持したバージョンアップ
      6. 仕様に基づいた製品を選択可能
   2. 均質化
      1. アプリケーションのアーキテクチャを均質化
         1. Java　EE マルチティアモデルに準拠
   3. 長寿命化
      1. 標準APIベースの開発
      2. サードパーティ製品は疎結合利用して、ロックイン回避
   4. 標準アーキテクチャ
      1. JSF+EJB+JPA
   5. 各コンポーネントの作りのばらつきを抑える
      1. コンポーネントの作りをパターン化して再利用
         1. 設計パターンの整備とカタログ化
         2. パターンの再利用による設計を推進
         3. パターン名によるコミュニケーション