共通チーム（システムアーキテクト）の仕事

ここでは、システム構築プロジェクトで、「共通チーム」として考慮すべき点を列挙します。
システムのアーキテクチャは、EJBを使ったWebシステムを前提とします。

プレゼンテーション層

プレゼンテーション層の役割は、画面からのリクエストを受付け、ビジネスロジックを呼び出し、処理結果に従って画面の再描画を行うことです。
堅牢なシステム構築のためには、プレゼンテーション層では他にも多数の考慮点が必要です。

• 認証(ログイン・ログアウト)
• 認可(権限・ログイン制御)
• 業務規制
• ページガード
• サニタイジング(SQLインジェクション対策・クロスサイト・スクリプティング対策)
• HTTPセッション管理
• ページ送り
• エンコード・デコード(文字化け)
• 国際化
• 多言語化

ビジネスロジック層

ビジネスロジック層は、業務設計に依存する割合が大きく、処理方式を統一することが難しい箇所です。
しかし、最低限のルールを決めておかないと、プログラムの保守性に大きく関わってきます。

トランザクション管理

• ユーザコンテキストの設計、管理
• 例外の扱い
• セッションファサード、DTOなどの定番パターン

データアクセス層

データアクセス層は、データベースアクセスをカプセル化します。一般的には、データベースベンダー独自の機能を使わず、可搬性を保つことを目指す傾向があります。
しかし、ほとんどの場合、複数種類のデータベースに対応させる要件はありません。

• O-Rマッピング
• JDBCテンプレートフレームワーク
• バックアップ計画

基本処理方式の検討

• ログ出力→運用管理と連携
• 例外の扱い、エラーハンドリング

その他業務処理方式の検討

• 帳票処理方式
• メール配信処理方式
• 他システム連携
• Javaバッチ処理方式(オンラインとは異なるフレームワークで行なうべき)

開発プロセスの標準化

ドキュメント

スムーズにプロジェクトを進行させる為に、ドキュメントを欠かすことはできません。
プロジェクトに新規参入したメンバーを含め、お客様にも納得頂くことが重要です。

• アプリケーション・デザインガイド(画面・処理・帳票・特殊機能)
• 仕様書作成ガイド(フェーズごとの仕様書の定義と記載基準)
• コーディング・ネーミング規約
• 本番/開発環境構築ガイド

テスティング(単体・結合・システム・運用テストを除く)

• パフォーマンステスト
• セキュリティテスト
• モンキーテスト
• 回帰テスト
• 受入検証(オフショア)

レビュー

人間は必ず間違いを起こすものです。チェックをしないことが信用だと考えている人が多いと感じます。「任せる」ことは、「丸投げ」とは全く異なる点に注意が必要です。

• 仕様書成果物レビュー
• ソースレビュー

管理関係

• 障害管理
• 変更管理
• 成果物管理
• メトリクス分析
• その他の要因

クライアントの選定

オンライン処理を行う、クライアントは、ウェブブラウザが主流です。
しかし、より表現力豊かなユーザインタフェースを提供するために、リッチクライアント技術が台頭し始めています。

データベース

RDBMSが主に用いられる。Oracle、DB2、SQLServerがシェアを分け合っており、オープンソースの製品として、PostgleSQLやMySQLがこれに割って入る構図となっている。