古いバージョンのブラウザーを使用しています。MSN を最適にご利用いただくために、サポートされているバージョンをご使用ください。

なぜ、日本の企業は「標準化」ができないのか?

ITmedia エンタープライズ のロゴ ITmedia エンタープライズ 2017/01/11

 前回の記事では、サーバOSのパッチ適用の場面を例に、パッケージソフトウェアの導入時の問題点を、局所最適と全体最適の観点で解説しました。今回は、その中でも問題になりやすい“標準化”にまつわる問題を取り上げます。

 率直に言ってしまえば、日本のIT運用の現場において、標準化は“驚くほど”進んでいません。その理由がどこにあるのか、前回と同じく、サーバOSパッチ適用効率化のプロジェクトを例に考えてみたいと思います。

 パッケージソフトウェアの導入に際し、ベンダーの懸命な説得で、導入企業側の担当者も作業の一部分ではなく、プロセス全体を自動化する方向に考えが変わり始め、経営層がバックアップする体制も整いつつある状況でのお話です。

●失敗事例8:「要望に細やかに応える、職人的な文化」

パッケージソフトウェア購入企業の担当A: このソフトウェアは、パッチがリリースされてからパッチ適用までの一連の手作業を自動化できるんですよね。手順もある程度カスタマイズ可能と聞いています。弊社ではWindows OS上で稼働するシステムが100以上あり、手順はシステムごとに開発者が用意したもので、各システムに最適化されています。それを全て自動化するとなると膨大な作業が必要になりそうですが……。

ソフトウェアベンダーB: おっしゃる通りです。全ての手順をそのまま自動化すれば膨大な作業量になるうえ、維持管理にかかる労力もはかりしれません。そのため、代表的な手順を確立して標準とし、各システムに適用していくことを推奨しています。そうすれば、カスタマイズも最小にでき、かつ大きな効果が得られます。

担当A: それは、今あるシステムごとの手順を変えるということですか? それは厳しいですね……。社長からの指示で開発部門も協力する体制はできましたが、われわれは安定運用が第一です。手順を統一すれば、今までのサービスレベルを保てないケースも出てくるでしょう。開発側からも文句が出るに決まっています。そもそも我が社は、個別の要望にきめ細やかに応える、職人的な文化を大事にしているのです。会社もそれは否定できませんよ。製品が柔軟にカスタマイズできるのなら、それで対応できそうじゃないですか。

ベンダーB: (個別最適の話に戻っているな……)分かりました。ここは一つ、本来の目的とその達成を阻害する要因について整理していきませんか?

 このまま担当Aの言う通り、システムごとにカスタマイズを行っていては、このプロジェクトが失敗することは間違いなさそうです。仮にパッケージソフトを導入しても、費用に見合う効果は得られないでしょう。

●なぜ「標準化」が必要なのか?

 システムの数だけパッチ適用プロセスのパターンをカスタマイズ(作成)すれば、プロジェクト工数や想定外の作業が増えて、スケジュールが遅延しやすくなりますし、何より、膨大なカスタマイズで生まれる成果物の維持管理が大変です。管理対象が増えれば、品質維持も難しくなります。

・関連記事→なぜ、パッケージソフトの「カスタマイズ」で失敗してしまうのか?

 こうした個別カスタマイズの考え方の対極にあるのが「標準化(standardization)」です。標準化とは、今まで同じ目的のためにバラバラに存在していたものを統一化すること。私たちの文明の発展は、標準化なしには考えられません。皆さんがなにげなく使っているcm、kgといった単位、日常的に使っている(もはや、使っていると意識しないレベルの)インターネットも標準化の産物です。

 想像してみてください。隣の人が、知らない重さの単位でモノの重さを伝えてきたらどうしますか。恐らく、その重さの単位の説明から聞く羽目になるでしょう。重さを共有したいだけなのに、それ以前の会話から始める必要があるのです。本来の何倍もの時間を費やすことになるでしょう。

 先ほど例に挙げたパッチの適用にも同じことが言えます。システム開発者は、ただシステムのサーバOSにパッチを当ててほしいだけなのに、会社(またはサービス)として標準的な方法が確立されていないために、そのやり方から考える必要が出てくるのです。それも多くの企業がWindowsやLinuxといった、デファクト・スタンダードなOSを使っているにもかかわらず。

 これは企業活動として大変な“ロス”だと思います。外資系のパッケージソフトウェアは特に、そういった標準化の概念が根底にあると考えた方がいいでしょう(マニュアルには、特にそのような解説はありません)。そうと知らずに使ってしまうと、本来の効果が得られないばかりか、かえって非効率な結果を招くことになります。それで「このソフトウェア、使えないね」といわれてしまっては、ソフトウェアがかわいそうです。

 しかし、日本企業のIT運用で「標準化」がなされている現場はほとんどないと言っても過言ではありません。

●標準化が浸透しない国、ニッポン

 これまで連載の中で挙げてきた、さまざまな要因がその背景にありますが、今回の会話にも出てくる、「個別の要望にきめ細やかに応える、職人的な文化」という考え方も阻害要因の1つだと考えています。

 「標準化してしまうと、他社と同じような内容になってしまい、差別化のポイントが失われる」という意見をよく聞きますが、この考え方も間違っています。そもそも、ハードウェアもOSも、そしてデータベースやミドルウェアも、世の中でデファクトとなっている企業の製品を採用しているケースがほとんどですから、運用の部分で差別化を図るのは本来至難の業です。

 できたとしても、その運用ができない企業に代わって運用を行うというサービスくらいでしょう。しかし、実際にそのようなサービスを提供している企業は、他社との厳しい価格競争にさらされており、かつ近年では高度に標準化、自動化されたパブリッククラウドサービスにシェアを奪われています。

 どの企業も使っているハードウェア、OS、データベース、ミドルウェアの最適な運用(ベストプラクティス)は、大してバリエーションがあるわけではありません。差別化を図るならば、その上のレイヤーで稼働するアプリケーションに注力したほうが効果が出やすいはず。それ以下のレイヤーはベストプラクティスで標準化し、かつ自動化するのが投資対効果の面でも望ましいです。

 世の中で実績のあるデファクトな製品と、ベストプラクティスで標準化・自動化された「基礎」があって初めて、職人的な差別化を行えるわけで、それがないのは、芸術や武道でいうところの“形無し”と同じです。「形があって初めて、型破りなことができる」というのは、エンタープライズITの世界でも共通していると思います。

 では、どのように標準化を進めればよいのでしょうか。ここ最近の業界標準としては「IT4IT」などがありますが、まずは、本記事で挙げた考え方やマインドを持って自社のシステムを見直すのがスタートだと考えます。その一歩が進められるか、進められないかの差は意外と大きく、仮に進められたとしたら大きな一歩になるでしょう。その後、実践方法のリファレンスとして、業界標準を参照するのがよいです。機会があれば、連載の中でもIT4ITを扱いたいと思います。

 以上、今回までパッケージソフトウェアを導入するフェーズでの失敗例をご紹介しました。次回からは、導入から運用に移行するときの失敗例を取り上げていきます。お楽しみに。

ITmedia エンタープライズの関連記事

image beaconimage beaconimage beacon