共通基盤チーム

「共通基盤チーム」と呼ばれるチームの役割に関する私見と、その共通基盤チームの方のための文献紹介。

共通基盤チーム

共通基盤、他には「インフラ」や「フレームワーク」「アーキ」など文化によって色々な呼び方をされていると思いますが、要するにアプリケーションのアーキテクチャ策定から業務横断的な共通機能の提供を行うことで、各アプリケーション開発者の方々を支援するチームのことを指しています。すっかり一般化した「ITアーキテクト」という言葉で指される人たちが集ったチームと考えていただければ良いでしょう。開発者が10人位までのプロジェクトであれば、特にチームとして作られることはないと思われますが、40から50人規模のプロジェクトでは大概明確に設定されていると思います。


共通基盤チームの役割を要約するならば、「業務開発者の責任範囲を限定すること」になるのではないかと考えています。つまり、各業務開発者は担当する業務ロジックの実現にのみ専念すればよく、それを取り巻く"技術的な"問題は共通基盤チームで解決するべきということです。これを実現するための共通基盤チームの責任範囲は必然的に広くなるのですが、それでもポイントは以下の3点に要約できるのではないでしょうか。

  1. 適切にレイヤ化されたアーキテクチャの策定
  2. スムーズな開発をサポートするためのプロセス整備
  3. "技術的な"品質を担保するためのコーディング規約制定

このうち、1.に関してはそのアーキテクチャを実現するためのフレームワーク開発(ないし既存フレームワークの拡張)がタスクとして含まれてくることになります。

学ぶべきこと

「業務チーム」と「共通基盤チーム」との区別は、往々にして「技術のある人を共通基盤チームに」と単純化されてしまうことが多いように感じています。しかし、実際には業務と共通基盤では求められる技術範囲がかなり異なるため、「仕事がデキる」「コーディングが速い」といったことを理由に共通基盤チームにアサインされて、苦労している方もたくさんいらっしゃるのではないでしょうか。


共通基盤チームの役割は上記のようにきわめて多岐にわたるため、勉強しようにもどこから手をつけたら良いのか分からないところがあります。最終的には、例えば以下の雑誌に特集されている「ITアーキテクトの必読書50冊」のようなブックリストを参考にコツコツ積み上げる必要があると思います。

ITアーキテクト Vol.3 (IDGムックシリーズ)

ITアーキテクト Vol.3 (IDGムックシリーズ)

それでも、さしあたり1週間位で立ち上がらなければいけない時には、サーバーサイド・デザインパターンの基礎と実装時の考慮事項などをコンパクトにまとめた参考文献が必要になります。


そんな時に役に立つであろう文献がこちら(英語)。
Designing and Coding Applications for Performance and Scalability in WebSphere Application Server | IBM Redbooks

Designing and Coding Applications for Performance and Scalability in WebSphere Application Server

全700頁弱ですが、エッセンスだけを読み取るならば2章と3章だけで十分です(80頁程度)。2章がデザイン、3章がコーディングに関する説明にあてられています。この本が優れていると思われる理由は、基礎を押さえつつ、応用部分に関しても、それを支える重要な考え方とあわせてきちんと説明してくれている点にあります。


2章では、3層アーキテクチャMVCモデル、SOAに関する基礎的な知識が紹介されていますが、それに引き続きSession FacadeやBusiness Delegateなどの重要なデザインパターンも紹介されます。
Business Delegateに関する説明の一部を引用します。

The Business Delegate can be designed such that it has the ability to retry operations in the business layer on failure. The client is unaware of any attempts for successful execution, only after the number of retry attempts have failed. The Business Delegate translates business service remote exceptions into application exceptions. This also helps shield the client from EJB and network-related implementation details.


Business Delegateはビジネス層において処理が失敗した場合にリトライが可能なように設計することもできます。リトライを何度も試みた上で処理が成功した場合でもクライアントはそれを意識することがありません。Business Delegateはビジネスサービスのリモート例外をアプリケーションの例外へと変換します。この場合にもクライアントからEJBやネットワークに関連した実装の詳細を隠蔽することに一役買います。
Chapter 2. Application planning and design (p.41)


また、3章ではコーディングの考慮事項の他、ガーベジコレクションやファイナライジング、同期化などについてJVMのふるまいを含めて丁寧に解説されていると同時に、Java5の言語仕様についてもサンプルコードを交えて簡単に紹介してあります。
スタティッククラスとシングルトンとの使い分けについての説明から一部を引用します。

Use static classes if the details do not change over time --- a utility class for parsing strings is a good example. They are not impacted by a change in context, and additionally, they gain very little from polymorphism. If the code contains business logic that is likely to change over time, the singleton provides the flexibility.


今後詳細が変わらないようであれば、スタティッククラスを使用して下さい。ストリングをパースするユーティリティクラスなどが良い例です。こういったクラスはコンテクストの変更によってインパクトを受けることはありませんし、ポリモルフィズムによって得るものもほとんどありません。逆に、もしコードが今後変更されそうなビジネスロジックを含むようであれば、シングルトンを使うことで柔軟にできます。
Chapter 3. General coding considerations (p.71)


初心者の方に留まらず、ある程度の経験をつまれた方にとっても、「パフォーマンスやスケーラビリティ」という観点(タイトルの通りですが)から「MVCモデルアプリケーション」について再確認するための良いきっかけを与えてくれる良書ではないでしょうか。