DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

タイトルのこの言葉は、アーキテクチャ主導でシステムを構築するのに最も適した標語だと私は思っている（IBMやAPPLEの受け売りではなく）。ちなみに「小さく産んで大きく育てる」とは、計画性の観点でニュアンスが異なる。さて今回のブログは実際のシステム化構想の局面で、この標語にピッタリの事例をご紹介する。かなり地味目な話であるが、何かの役に立てれば幸いである。

今から約９年前に社内メールのアカウントを登録する小規模システムの老朽化対応が持ち上がった。当時全盛のExchangeのアカウント情報をMS製品の外側から登録する仕組みだ。この要件を受けて描いた概念モデルは、図１のようなモデルだ。ADアカウント登録⇒個人ITリソース管理⇒ITリソース管理へと汎化するにつれ、システム・スコープは大幅に拡大していった。まず“ネットワークユーザ”というクラス定義で、その中の“社員“の異動情報が人事システムと自動連動する事が期待された。また同時にMS以外のネットワーク連携が可能な構造になった。さらに“個人ＩＴリソース”というクラス定義では、ＰＣのハード／ソフトの台帳管理の省力化が期待できた。そして行き着くところ、対岸にある“共通ＩＴリソース管理”への発展までイメージが膨らんだ。

その後、実装をどうするかという段階で、構築予算が“ADアカウント登録システム”の分しかないことが判明。また、ADアカウントの連動はセキュリティ対策として早急に実行したいと。このような背景からプロジェクトは第１ステップで人事連携～メールアドレス管理、第２ステップでＰＣ管理を実施し、１年足らずで全稼働した。

このように汎化がもたらすスコープの拡大は、汎化に要する投資と比べるとはるかに大きな効果をもたらす。ソフトウエアの付加価値は、まさにこの抽象化デザインの恩恵による。前回のブログで「ヒアリングのままシステムを作らない」と言ったことを思い出していただきたい。この汎化の連鎖にどれほどの時間を費やしたか？おそらく半日程度だったと記憶する。もしも要件通りの“ADアカウント管理システム”をスタンドアロン構築していたらどうだったろう？微小なＲＯＩに終わっていたこと間違いなしだ。
皆さん、システムのスコーピングの際は、今一度、汎化ができないかを考えてみよう！