 |
ITアーキテクトとして，システムの全体構成や使用する製品の選定，アプリケーション・アーキテクチャ設計までを手掛ける「方式設計」を担当することは，重圧を感じつつも非常にやりがいを得られるものである。ところが，苦労して美しいアーキテクチャにしたはずなのに，開発がスタートすると次第にアプリケーション開発者によって「見覚えのない方式」があちこちに導入され始めたり，全く意図しない実装になったり，リリース間際にはツギハギだらけの構造に仕上がっていて悲しい思いをしたりすることがある。
悲しい思いをするだけならともかく，意図から離れた実装をするようになると，保守性が悪くなったり，性能に悪影響を及ぼしたりする。ITアーキテクトは，アプリケーション開発者が方式設計通りに開発してくれると思ってはいけない。方式設計通りに開発してくれるように導かなければいけないのである。
筆者が実際に経験したものから例を挙げると，次のようなものがある。
「方式設計書にない処理方式が使われている」
開発機がメモリー不足になっているという問い合わせを受けて，原因究明のため話を詳しく聞いていると，何やら設計した覚えのない非同期処理の仕組みが使われており，プロセスが大量に発生している。
「知らないサーバーとデータ連携している」
開発機と○○サーバーを接続できるように設定してほしいと頼まれ，しかもプロトコルを聞くとSOAPだという。そんなことは想定していなかったはずなのに，いつのまにか外部（○○サーバー）のWebサービスを使用する話になっている。
「性能が全く出ない」
たいした処理をしているわけでもないのに，画面レスポンスが非常に遅いと言われた。アプリケーションの仕様書を読んでみると，ミドルウエアの呼び出し方が間違っており，不要な初期化処理が散見された。
「知らない製品がいつのまにかインストールされている」
ある日突然「この部品の使い方がよく分からないのですが」という質問がアプリケーション開発者から寄せられた。んん？そんなの誰がインストールしたの？と思って尋ねると「ログを出力するプログラムを作るのが面倒なので，フリーの部品を使うことにしました」という答えが返ってきた。
このような事態が発生する原因には，主に次のようなものがある。
- コーディングの自由度が高く，アプリケーション開発者が好き勝手な方式を編み出している
- アプリケーション開発者が方式を正しく理解していないため，誤った実装を行っている
ITアーキテクトの仕事は「設計したら終わり」ではない
ではどうすればよいのか？アプリケーション開発者に方式設計どおりに開発してもらうための方法について考えてみよう。下記のような対策が考えられる。
「フレームワークで共通機能を提供しつつ，開発自由度を奪う」
フレームワークを採用する目的は，一般的には生産性向上や品質安定化であるが「アプリケーション開発者を方式設計で意図した処理パターンに誘導する」という目的もある。例えば，Webシステムで画面遷移の実装をパターン化するためにStrutsやJSFを使ったり，DBアクセスのロジックをパターン化するためにDAOとO/Rマッパーを使ったりといった具合だ。主に開発言語がJavaの場合に有効な手段となる。
「開発方式設計をしっかりやる」
意外と忘れられがちなのが，開発にかかわる方式設計である。例として次のようなものがある。
- ビルド方式
- ライブラリ管理方式
- リリース方式
「開発標準化の策定に首を突っ込む」
標準化は方式設計をインプットとして，方式パターンの細分化や具体的なコーディングのルール，サンプル・コードの提供を行うフェーズである。ここでもITアーキテクトの知識や経験が存分に発揮される。網羅的に作られたルール集と，豊富なサンプル・コードさえあれば，開発者は迷うことなく正しい方式を使用してくれる。標準化を進めるうえでポイントとなるのが，必ずアプリケーション開発者と一緒に標準化を実施するということだ。ITアーキテクトが各方式に込めた狙いや目的を説明しつつ，どうすれば現実的な実装にできるかについて開発者の声にも耳を傾けよう。
「性能評価を早めに実施する」
方式設計の重要なポイントの一つが「処理性能」である。高速な処理を実現する方式を設計できるかどうかは，ITアーキテクトの腕の見せ所ともいえる。ところが，アプリケーション開発者は画面や業務処理などの機能を優先して開発したがる傾向があるために，方式設計通りに開発されないという事態がよく発生する。
そこで，連結テストの進み具合を見つつ，性能評価できそうなモジュールがあればピックアップして簡単なテスト・コードを書いてレスポンスを測定してみよう。やたらと遅かったり，メモリーを消費しすぎたりしている場合，たいていはコーディング・ルール違反や想定外のミドルウエアの使われ方をしているはずだ。発見が遅ければ遅いほどスケジュール的に改修しづらくなるので，早期発見・早期治療に努めよう。
どうだろうか？設計の段階で工夫できる点もあるのだが，開発スタート後のフェーズでもできることはある。ITアーキテクトの仕事は「設計したら終わり」ではない。その後の開発フェーズにおいてもリーダーシップを発揮し，開発チームを正しい方向に導いてリリースを見届けるところまで責任を持ってこそ，プロのITアーキテクトなのだ。これは決して楽なことではないのだが，意外と開発フェーズ中に次の方式設計のヒントやアイデアに出くわすことも多い。ぜひ，前向きに取り組んでほしい。
|
