私はシステム部の福田課長に独自案を提案した。ユーザー・レプリケーション方式の処理時間を見積もり，初期の全データ移行方式，必要ディスク容量，当方式のメリット/デメリット，制約事項，新規プログラムの開発規模などを盛り込んだものである。
「新国際システムのDBMSはバージョンが古く，当初のレプリケーション方式は採用できないことが分かりました。そこで，私独自の方式を考えてみました」。
決して美しい方式ではない。ある程度の非難は覚悟していた。ところが，福田課長の反応は意外にもよかった。
「いろいろな制約がある中で，短期間でよく考えてくれた。この方式をより詳細化して，販売企画部門に提案しよう」。
既にお気付きの方もいると思うが，ユーザー・レプリケーション方式には以下のような欠点があった。
- レプリケーションの開始から完了までに時間を要する（データの鮮度を重要視する場合は適用不可）
- 中間ファイルやCPUなどシステム資源を使用する
- 規模は大きくないものの，新規開発が必要
期待に対して100％応えられたとは思っていない。だが福田課長も100％ではないものの，満足してくれたようだ。どうやら様々な制約を乗り越えて方式を提案したその過程が，評価されたようである。
いざ販売企画部門に提案
検討を進めた後，福田課長らは販売企画部門に説明するための資料を作成してくれた。それを見せてもらうと，そこにはこんな記述があった。
- バックアップ・データを入力とするので，本体システムへの影響はない
- 全更新データを反映する通常のレプリケーションとは異なり，前日との差分のみを反映する。そのため反映処理が平易かつ短時間となる（同一レコードに1日に複数回更新があった場合でも最後の更新のみを反映すればよい）
- DBMSの種類やバージョンに依存しないので，他のシステムにも同データの提供が可能。相互のバージョンを意識する必要もない
- 障害などで1日分のデータが欠落しても，2日分の差分データを容易に作成できる
- レプリケーション・ソフト特有の「ログ量の増加」や「各種環境定義追加」が不要
その提案資料は「ユーザー・レプリケーション方式が最善である！」というトーンで作成されていた。「うまく表現してくれたものだ」と感心し，私も嬉しくなってきた。
「あきらめない」ことの重要性
本記事で私が伝えたかったのは，「ユーザー・レプリケーション方式」の仕組みではない。方式そのものは最新技術を使った事例でもなく，参考にしていただく必要もない。
それよりも「制約が多く，実現できそうもない案件」に対して，解決策を導き出すアーキテクトとしての活動，そしてこのようなアーキテクトの行動が，お客様の評価を勝ち取ったことをお伝えしたかったのである。私はこの案件を通じて，以下のようなことを学んだ。
- 当初予定したソリューションが適用できない場合，アーキテクトは観点を大きく変えた解決策を模索することも必要である
- 制約が多い要件でも，「できません」と言う前に，その制約を乗り越えて何とか解決策を導き出すのも，アーキテクトの醍醐味である
- お客様がアーキテクトに期待しているのは，単なる技術力ではない。課題に対する解決能力である
皆さんも，同じような考えを持っていただいたと期待しつつ，この特集を締めくくろう。
| 宮治 徹（みやじ とおる） 日本IBM アプリケーション・サービス シニアITアーキテクト |
| 1988年に日本IBM入社。主として通信メディア系の大規模SIプロジェクトのSEを歴任。現在はインフォメーション・マネージメント部に所属し，データベース関連を中心としたアーキテクト活動を手掛けている。 |
