なぜ、日本のIT部門は業務の「見える化」ができないのか？：夢物語で終わらせない「DevOps」（2）（2/3 ページ）

[北山晋吾（日本ヒューレット・パッカード），ITmedia]

　VSMを用いる最大の理由は、各作業にある工数のムダを排除し、開発サイクルのリードタイムを短縮するだけでなく、品質も担保できる点にあります。そのため、品質低下による手戻りでリードタイムを悪化させることを考慮し、各プロセス間での正確率（％C/A：Percent complete and accurate）を測定することが求められているのです。

• リードタイムの短縮：顧客の要求に対応できるまでの時間（＝リードタイム）を短くするためには、プロセスの改善を行う
• プロセスタイムの短縮：要求の対応時間（＝プロセスタイム）を短くするためには、自動化や対応方法の見直しを行う
• 品質の向上：各ステップ間の修正やバグの発生率を下げるためには、自動テストや標準化の徹底を行う

　このように、IT現場におけるVSMは、バリューストリーム（ビジネス上のアイデアを顧客価値として届けるまでのプロセス）に潜む課題を見える化し、改善ポイントを洗い出すことができるオペレーション戦略として、再び注目を集めています。

　しかし、Web系では採用する企業が多い一方で、エンタープライズ系の企業では、このVSMを利用した業務プロセスのボトルネック抽出や、改善を行うIT部門が少ないのも事実です。彼らがこういった投資対効果を測る活動まで、手を伸ばせないのはなぜなのでしょうか。

組織の壁によって、運用部隊は「見える化」が難しい!?

　以前、私は顧客のインフラ運用担当者に次のようなことを言われました。

　「VSMのようなワークにはとても興味があるけれど、アプリケーションのことはよく分からないし、既に外注しているプロセスも多いから、目先の課題対応に日々追われています。それに、現状では分単位でサービスを作るような要件もないので、後回しにしている状況なんですよ」

　この話がよい例ですが、既にVSMを知っている人でさえ、手を付けられない原因の1つに、現状のIT運用における組織体制が、バリューストリームの各プロセスに大きく依存しているという問題があります。

　こうした企業の運用部隊は、ネットワーク管理者、仮想マシン／サーバ管理者、データベース管理者といった、個別の機能をユニット化した「機能（職能）別組織」になっていることがほとんどです。機能別組織は業務範囲が細分化され、従業員が個々の業務分野における習熟度を高めやすいというメリットがある半面、階層化が進みやすいといったデメリットもあります。