ここから本文です

なぜ、日本のIT部門は業務の「見える化」ができないのか?

11/1(水) 10:20配信

ITmedia エンタープライズ

 DevOpsを始める第一歩としてKPIを定めるべきだ――。前回の記事で、私はそんな風にお話ししました。それは、DevOpsというのは、各企業が自社に適したKPIを策定し、可視化することで効果を高めていく改善プロセスであるためです。

バリューストリームマップの簡易図

 それでは、ITの運用や開発に携わる社員の「KPI」とは、一体何でしょうか。

 例えば、アプリケーション開発者であれば、バグや機能追加のチケット回収率、インフラ運用者であればサービスの稼働率などが最初に思い当たるところかと思います。ところが、普段から多くの業務をこなしている現場担当者でも、あらためて自身の“役割”を問われると、的確に答えられない人が少なくありません。

 もちろん、どの役割であったとしても、最終的には企業の利益につながるべきなのですが、日頃からそれを意識をしなければ、個人の成果や企業の投資対効果につながらず、ひいては業績の頭打ちを招く可能性もあります。

 DevOpsも同様です。最終的なビジネス価値に対して、自身の役割と一緒に働いているメンバーの役割が相互補完関係にあるのが理想ですが、価値の見える化ができていないために、目先の仕事に追われてしまい、本来のKPIを見失っていることは、案外多いのではないでしょうか。

●“見える化”の課題を打破する「バリューストリームマッピング」

 この“見える化”の課題を打破するための施策として、DevOpsでは、トヨタ生産方式で利用されていた「バリューストリームマッピング(VSM:Value Stream Mapping)」を利用することがあります。これは、企業の生産工程において顧客への付加価値を生み出している活動と、そうではない活動を顕在化し、価値を生まない業務に潜むムダを排除することで、リードタイム短縮やプロセスタイムそのものの削減を目指す活動です。

 バリューストリームマップはもともと、物流の生産ラインなど、目に見えるものを対象としていましたが、最近では、ITサービスのような“目には見えない活動”にも応用されています。日本でも、アプリケーション開発サイクルが短いWeb系企業などを中心に、利用され始めているのはご存じでしょうか。

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

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

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

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

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

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

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

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

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

 もともと機能別組織というのは、業務における急激な変化が少なく、市場や顧客への迅速な対応よりも、組織内部の効率化や生産性を高めることが、成功要因となる企業に適した組織体制です。そのため、バリューストリーム上の各プロセスが部署単位に分かれていると、担当者1人が管理できる範囲を越えてしまい、指摘しづらいプロセスが出てきてしまいます。

 また、社内だけでなく長年慣れ親しんだパートナーに、プロセスをまるまる外注していると、作業がブラックボックス化しているにもかかわらず、変更しにくいという価値観が生まれやすいのも事実です。変える意志はゼロではないけれど、どこか“他人ごと”になってしまう――。そんな担当者、あなたのまわりにはいませんか?

 その一方で、バリューストリームをうまく開発サイクルに取り組めている組織は、「運用をプラットフォーム化した事業部別組織」を展開し始めています。

 事業部別組織とは、その名の通り、独立してビジネスを行う「事業部」ごとに人員を分けた組織を指し、業務プロセスの最初から最後までを、単独の事業部に一貫して担当させることで、意思決定権限を事業部ごとに委譲し、迅速なサービスを展開できるようになります。

 一方で運用に関してはプラットフォームを一元化し、事業部内に運用プラットフォーム部隊との調整役を立て、ガバナンスを効かせるのが望ましいでしょう。その結果、部署単位での調整コストが減り、短期的な意思決定から、中長期の計画立案までのサイクルを事業部内で迅速に回すことができるようになるのです。

 各個人のKPIやバリューストリームの改善というのは、単に自動化やプロセスの見直しだけにとどまりません。組織内部におけるコミュニケーションを変える必要もあります。

 あなたの会社では、部署間で見えないカベができていないでしょうか? 無意識のうちにカベを作ってしまっていませんか? DevOpsに取り組む第一歩としても、部署間のコミュニケーションが円滑になるよう個人で努力することは大切ですし、強制的な組織構造の改革を検討することも、エンタープライズ系の企業には、今まさに求められているといえるでしょう。

●著者紹介:北山晋吾

 楽天株式会社にて国際ECサービスのインフラ部門に入社。主にオープンソースを利用したインフラ基盤やプライベートクラウドの設計、構築、運用を担当。

 その後、日本ヒューレット・パッカードにて、金融系システムのプロジェクトリードを経験。仕事に従事しながらグロービス経営大学院でMBAを取得し、現在はテクニカルアーキテクトとしてDevOpsやクラウド、Deep Learning分野をはじめとした、オープンソースソリューションの提案、コンサルティングおよび構築デリバリーを担当している。

 また、これまでの業務経験を生かし、教育トレーニングの講師やオープンソース勉強会のリード、アーキテクト育成活動など幅広く活躍している。