いまさら聞けない「クラウドの基礎」〜クラウドファースト時代の常識・非常識〜：クラウド時代のアジャイルシステムインテグレーション（1）（2/3 ページ）

[松井暢之，TIS株式会社]

従来型のシステムインテグレーション、4つの無駄

　このクラウドならではの価値を提供するためには、システムインテグレーションの定石も大きく変革しなければなりません。従来の「システムごとに最適化され手作業を前提としたシステムインテグレーション」から、「クラウドを前提としたアジャイルなシステムインテグレーション」への転換です。

　システムごとに最適化され、手作業を前提とした従来のシステムインテグレーションには、ビジネスの価値へ貢献しないさまざまな無駄があります。それらの無駄をいくつか挙げてみましょう。

1.同じようなアーキテクチャやプラットフォーム、インフラ運用を設計・実装・テストする無駄

　システムを構築する際には、システムのアーキテクチャやプラットフォーム、バックアップや監視などのインフラ運用を設計・実装・テストしなければなりません。手作業でこのような作業を行わなければならないため、似たような設計・実装・テストを毎回繰り返す必要があります。

　ある程度大きな企業であれば、アーキテクチャやプラットフォーム、インフラ運用の設計や実装のパーツを企業内で共有することで、この無駄の排除に取り組んでいることでしょう。しかしそれらのパーツを適切にシステムに組み込むためには、パーツを解釈して理解し、適切に組み込まれたことをテストして確認する必要があるため、この無駄が完全にゼロになることはありません。

2.手作業で運用することによる無駄

　システムごとにアーキテクチャやプラットフォーム、インフラ運用を手作業で実装する場合、実装する担当者の能力次第で運用を機械化・自動化できる個所が異なってきます。システム構築時に時間や要員が足りなくなってくると、得てして「ここは後で手順書をまとめることで対処しよう」というように運用にツケを回しがちで、そのしわ寄せが運用コストの増大を招きます。

　また手作業による運用では、ミスを回避するのも一苦労です。ミスを起こさないようにするためには運用コストの増大には目をつぶり、ダブルチェック体制を取らざるを得ないでしょう。

3.同じシステムを更新し続けることによる無駄

　従来のシステムは簡単にコピー＆ペーストできるようなものではないため、アプリケーションのリリースやミドルウェアのバージョンアップ、障害対応など、システムを更新する際にはそのシステムに手を加え続ける必要があります。

　そのため、影響が大きいシステム更新を行う場合、別途、維持管理されている「ミドルウェアやアプリケーションが本番システムとほぼ同等」のステージングシステムにおいて、そのシステム更新が及ぼす影響の事前検証を行った後に、全く同じ作業を本番システムで行う必要があります。これはかなり面倒な作業のため、一回のシステム更新に要する時間は長くなり、必然的にシステムを更新する頻度も低下せざるを得ません。

　また、更新したシステムに万一不備があった場合、迅速に「前のシステム」へ戻す必要があります。しかしシステムに手を加えてしまっているため、前のシステムに戻すことは容易ではありません。これもまたシステム更新の準備を難しくし、システム更新時間の長大化やシステム更新頻度の低下に拍車を掛けます。

4.システムがブラックボックス化することによる無駄

　システムの更新を手作業で行っている場合、設計書への反映が漏れてしまう可能性があります。絶対に漏れがないように、複数の目によるレビューと承認フローをルール化し適切に運営できていれば別ですが、そうでない場合は結局、実際のシステムを調査しなければ現状を正しく把握できないということになります。

　このようにブラックボックス化したシステムは、システム更新に対する準備に手間がかかるだけでなく、そのシステムの運用が属人化する原因にもなります。