「しっかり作る」側からの反論

「しっかり作る」側からの反論

最初に触れたように、素早く作るスタイルの究極の姿は、先々のことを考えないで、その場限りの限定したシステムを作ることです。でも、企業全体のシステムを見る立場に立つと、リスクがあると感じられます。

企業全体のシステムを統括する立場からすれば、使い捨てとはいえ、統制が取れていない小さなシステムが社内で利用されてしまうと、システムのカバー範囲が不明確になり、変更に対する影響も計れなくなってしまいます。

また、実際には業務に不可欠なものが、こういった対症療法で解決されてしまうことがあると、結局、使い捨てにはならず、現行システムを補完する重要なアプリケーションとして業務プロセスに定着してしまいます。

例えば、現状の業務プロセスを理解しようと業務担当者にヒアリングすると、いろいろなアプリケーションを渡り歩いて1つの業務を行っていることが明らかになることがあります。「この業務の引き継ぎ、大変なんですよ」なんて言われてみて、初めて分かる。これは避けたいですよね。

もう1つ懸念されるのは、標準化という視点です。企業のシステムは、有機的につながっています。これらは、ある程度一貫した設計に基づいて作られていないと、将来の拡張において大きな足かせとなってしまいます。また、そこで扱われるデータも、複数のサブシステム間の連携を考えたときに、共通化されていなければなりません。

たとえ素早く作るシステムであったとしても、こうした点に気をつけて影響範囲を把握していないと、実際に取り込んだデータに不整合があったり、処理の一貫性が損なわれたりしてしまうことがあります。

問題点を知る、ツールからのアプローチ例

残念ながら、こうした懸念をもってしても、“現実の需要に応える”という至上命題にはかないません。「とにかく今すぐ」という要求に対し、標準化の旗はあっけなく降ろされてしまいます。

とある企業の標準化部隊の方は、「いつの間にか小さなシステムが増殖してしまうんですよね」と嘆いていました。ちょうど来日していたエンバカデロ本社（米Embarcadero Technologies）の技術者も、こう返していました。「それは世界中同じですよ。特に、最近オープンソースでコンパクトにアプリケーションを開発できるようになって、ますますその傾向が高まっています」。

このときに、この企業の標準化部隊の方に紹介したのが、ツールによるアプローチです。

まず、現実に存在するシステムの問題点を知ることが重要です。ここで有効なツールが、「ER/Studio」です。

ER/Studioを使うと、データ構造の比較を行うことができます。これによって、正しくはこうあるべきという設計に対し、現実のシステムがどのようになっているかを知ることができます。差異を理解したら、容易に対策を立てることができます。

このとき、物理設計ではなく、論理設計で比較ができることも重要です。実際のシステムは、メインがOracleで、ちょっとしたテンポラリ・システムにはMySQLなんてことがよくあります。こういったケースでも、論理上どのような設計になっているのかを把握できれば、比較も容易になります。

もう1つ重要なのは、命名規則やフィールド定義などを標準化することですが、これには、データ・ディクショナリという機能があります。社内で標準となるフィールド定義を規定し、これに合わせるように強制させることもできます。