「個別に学んで来たスキルが総合的な形で発揮され、自信を深めたプロジェクト」が、2008年から2011年まで取り組んだ公共インフラ企業の基盤構築業務のアドバイザリープロジェクトだった。 　同社は、分社化によりシステム開発の人員や技術が分散され、場所も、システムも、人員リソースも実質的にゼロからつくり直さなければならなかった。

具体的には、データセンターの構築と運用時の監視システムの2つについて、顧客と一体になって必要な仕様を詰め、それを顧客に代わって構築ベンダーに提示して受託者を決め、開発を管理するというものだった。 「まずお客さまが望まれる立地でデータセンターにできる物件を探し、そのビルの耐震強度や地盤を評価しました。またサーバーを設置した際のフロアの荷重の分散状況なども評価します。ここまでは不動産会社と建築会社の業務を行っているようなものですね」

データセンターの設置場所を決めるのと並行して各所に分散していたシステムを統合するための「統合システム基盤」の要件定義や開発が進められた。 「それまで分散していたシステムは、さまざまなベンダーの独自の開発思想や規格で構築されていました。それを統一したものにするために各ベンダーに対してどのような考え方や、やり方で進めるべきかの標準化作業を行います。具体的にはマニュアルをつくって提示します」

この際に、重要なポイントがある。顧客側の担当者、JSOL、構築ベンダーなどさまざまな人が絡むために、システム開発の技量にはばらつきがある。これを放置すると開発が予定より遅れたり、完成品質にばらつきが出てしまったりする。 「能力、技量の標準マニュアルとでも言えばよいでしょうか、プロジェクトで求められる技量についての規定書も作成しました。こうしなければ統合システム基盤という"箱"は用意できても、仏をつくって魂入れずのような状態になってしまうのです」

システム完成後には、運用要員管理についても詳細な仕組みをつくる。伯井に言わせると、「データセンターという基幹業務にもかかわらず、運用要員管理は最も歪みが出やすい部分」だからだ。それをまた伯井は、「ベンダー・ロックインの嵐、無法地帯化を防ぐ」とも表現する。 分散していた各種の仕事が、統合基盤に集約される。それぞれの仕事を担ってきたスタッフやベンダーには、ある作業や事象の呼び方一つにも違いがあり、トラブル時の対応方法も異なっている。それを統合後も放置しておくと無法地帯と化し、顧客が自分のシステムなのに実態を把握できず結果的にベンダーに丸投げしてしまう「ベンダー・ロックインの嵐」にさらされてしまうのだ。

「用語の再定義などから始まり、運用フロー、作業フロー、評価手法などを相次いで確立していきました。運用サービスレベルの考え方などについても同様です。こうしたことでお客さまは、システムの運用と管理について自分たちでグリップできるようになり、結果的に企業としてのITシステムについての知見を蓄積できるようになるのです。こうしたインフラ一括運用支援は、JSOLがどのメーカーとも関わりのない独立系のシステムサプライヤーだからこそ可能な支援だと思います」

（2016年03月現在）