さて、ソリューションやサービスを提供するためには、システム基盤が整備されていなくてはいけません。最初の業務アプリケーションレイヤーでは、業務アプリケーションそのものとそれが動くプラットフォームがあります。

業務アプリケーションはその昔は手組みが基本でしたが、その頃にはパッケージも出てきましたし、アプリケーション間の連携もできるようになりました。ですから、そのアプリケーションをどうやって調達するのかどうかの方針を決めておく必要があります。「作る、買う、つなぐ」の考え方で、今ではそこに「借りる」が追加されるようになりました。

プラットフォームに関しては、コンポーネントという考え方とハブという考え方を採用しました。コンポーネントというのは、業務的には伝票一枚から給与計算システムのようなものまで、システム的には、データからプログラムモジュールまでを言います。

実は重要なのは概念的な規定で、そのときは、“変わらないもの”をさして、その単位がコンポーネントであるとしました。ですから“変わるものは、変わらないものの組み合わせ”であると考えたわけです。

また、ハブということで言うと、連携や協調がこれからは必要ということで、そのためには、ハブ＆スポーク型の構造が必須と考えました。

その必要性をもう少し具体的に言うと、バケツリレーの排除、インターフェースプログラムの削減、変換ロジックの一元管理、開発生産性の向上といったところでしょうか。
ハブの種類はいろいろあって、データのハブがEAI、機能のハブがBPMS、帳票のハブもあってという感じです。

さて次に開発技術のレイヤーです。ここでは「作る技術」と「つなぐ技術」があります。つなぐ技術は前述のEAIやBPMSを使いこなす技術となります。作る技術は、どういう言語で、どういうフレームワークを使うのかとなりますが、ただひとつに統一するのではなく、対象アプリケーションの種類によって変えるほうがよいと考えました。

ざっくり言えば、基幹系にはJAVAベースの自社開発フレームワークとして、情報系については.netベースにしました。あと悩ましかったのは、製造会社だったので、工場のシステムどうするかであった。

基本はリアルタイムデータベースを中心にした仕組みにした。基本機能は、DataLinkといって、リアルタイムのデータやヒストリー値や期間計算値などを高速読み出しできることとProcessBookといってビジュアルな作図・表示機能でリアルタイムトレンドがわかることである。

この仕組みは、プラントの監視には強力なツールで役に立った。いま、こうした仕組みをビジネスプロセスにも適用できないかを考えている。

さて、次は運用管理の構造化です。運用管理で構造化というのもおかしいかもしれませんが、体系の整理という意味でも大切なことだと思います。

そうした体系では大きく2つになります。ひとつは、ITIL準拠の統合的な運用管理体系を確立することです。もうひとつはセキュリティ体系です。

統合運用管理は、ITILに従ってやるのがいちばん分かりやすいのですが、なんでも全部適用することは現実的ではないと思います。成熟度の高い企業ならいざしらず、普通の会社では、サービスサポートではCMDB（Configuration Management DB）の構築、サービスデリバリーでは、SLA（Service Level Agreement）の確立をやっておけば最低限それでいいと考えました。

CMDBというのは、システム構成データベースのことで、簡単に言えばIT資産管理台帳である。ハード固有情報や、所有・移動情報、保守記録などの静的情報と、稼動OS、メモリー、HD容量、IPアドレス、使用アプリケーションなどの動的インベントリー情報を収集する。

これには、市販のIT資産管理ツールを買ってきましたが、固有のAP識別子が取得できないとかいう問題があったりして、かなりカスタマイズして使った。だが、これでやっとITリソース状況がつかめるようになり、不要ライセンスの削減などの効果を上げました。

セキュリティについても、重要なのは小手先の対策ではなく、ちゃんとセキュリティポリシーを作成し、リスクアセスメントをし、それに基づく技術的対策というかたちでまとめる必要があります。

そして、データ・アプリケーション・OS・ネットワークのそれぞれに対して、予防・検知・回復という観点から構造的にアクセス制御、認証や冗長化といったような具体策を講じることが大事です。

さらに運用ということだと、アウトソーシングかインソーシングかという問題があります。どういう運用の機能を外出しなのか自分たちでやるのかです。

結局、ホストコンピュータの運用はベンダーのデータセンターにアウトソーシングした。このとき、機種もアップグレードしたにもかかわらず、相当なコストダウンを図ることができた。従って、情報化戦略立案は親会社にもたせ、それとホスト運用以外の機能を分社した情報子会社がもつようにしたのです。

さて、最後は情報インフラの構造化ということになります。ここでも大きく２つに分けられます。すなわち、ネットワークとサーバー／クライアント／ストレージです。

ネットワークでは、基幹系と情報系という分類があります。ここで採用したのは、基幹系はIP-VPNで情報系はインターネット-VPNです。ミッションクリティカルなものについては安定性のあるネットワークにして、グレードを落としたところを情報系にしています。

次に、幹線と支線という分類もあります。幹線はトラフィック量が多いのでそれなりの容量のものを用意する必要があり、広域LAN、メトロイーサを充てました。支線はIP-VPNかＢフレッツです。その他、常時とバックアップ、データと音声という切り分けも必要になります。

次は、サーバー／クライアント／ストレージということになりますが、ここは当時の考え方のポイントは集約化ということでした。集約も器の集約と設置場所の集約の二つがあります。これは要員の効率化による運用コスト削減が目的です。

これが当時はけっこう悩ましいところであって、徐々に集約化していきましたが、ここの領域はクラウド化や仮想化技術の登場、そして、圧倒的なハードコストの低下があり大きく様相が変わってきているところではないでしょうか。ですので、ここでは多くを語ることはやめにします。