「日本の製造業が長年,世界一の競争力を維持できたのには理由がある。生産現場レベルに歩留まりやリードタイムといった数値的な指標を導入し,それをうまく活用してきたからだ」。取材相手のシステム・コンサルタントは,突然こんなことを言い出した。正直言って記者は,「突然,何を言い出すのか?!」と思った。

 だが,話の続きを聞くうちに,コンサルタント氏の真意がわかった。その主張は,「情報システム部門も業務の改善度を測る数値的な指標を導入すべき」「なんらかの指標がないと,どこにコスト面と品質面でムダがあるかどうかを見極められない」というものだった。

 確かに情報システム部門は,製造業に学ぶべきところがたくさんある。

あいまいな取り組みが不満を生む

 日本の製造業は強かった。いや,今でも強い。システムの取材で,しばしば生産拠点(工場)を訪問する記者は,そのことを肌で感じている。

 工場にいる担当者たちは,QC(品質管理)活動に真剣に取り組んでいる。生産に工数をそれこそ秒単位で計測し,ムダをそぎ落とす。原価を常に意識して,日夜改善に向けて知恵を絞っている。不良品の発生率は,それこそシックスシグマ(100万回当たり3.4回。関連記事)を目指す。その気迫は,門外漢の記者にも伝わってくる。

 一方,企業の情報システム部門はどうだろうか。製造現場における取り組みを前に,「自分たちも品質向上やコスト削減に全力を挙げてきた」と胸を張って言えるだろうか。

 もちろんほとんどのシステム部門は,システム障害の防止(品質向上)や構築/運用コストの削減に取り組んでいる。その熱意は高く評価する。だが,申し訳ないが,「現在のシステム部門の取り組みは場当たり的」との印象を記者は抱いている。一連の取り組みは,部門全体としての明確な数値目標なしに,個別のシステム単位(より正確に言うと,個別システムを利用する部門の声の大きさ)で実施されることが多いからだ。

 これでは経営は納得しない。経営が求めているのは,それぞれのシステムのダウン率や運用コストではない。「システム全体として,どの程度のレベルのサービスを利用部門に提供しているか」や「そのためにはどのぐらいのコストがかかっており,今後どの程度削減できるか」を説明しないと,経営者は満足しない。

 最近,取材したあるネット証券会社の幹部は「企業の経営陣は間接部門であるシステム部門に対しても直接部門と同様に具体的な結果を出すよう求めているのではないか。業務に支障をきたさないよう,システムを開発・運用するだけでは納得しないだろう」と指摘していた。

 さらに現状のやり方では,利用部門の満足度もなかなか向上しないだろう。個別のシステムの信頼性(品質)を高めていけば,瞬間的に利用部門の満足度は上がる。だが,そのためのコストは最終的に利用部門が負担する。ただでさえ経費削減の厳しい折り,利用部門の財布の紐は堅い。ただ単に「システム障害を減らしましたので,来年度のIT経費負担は2割増しでお願いします」と持っていっても,一蹴されるだけだ。

SLAでコストや品質を改善

 製造現場と情報システム部門の取り組みの違いはどこにあるのだろうか。記者は,数値目標を使って,品質とコストの最適解を見つける努力を組織的にしてきたかどうかだと考える。

 そうした意味で,強いシステム部門を作るには,自らの取り組みを客観的に把握できる指標を導入し,品質向上やコスト削減に生かす努力が欠かせない。システム・サービスの品質改善やコスト・ダウンの成果を目に見える形で経営や利用部門に示し,自らの存在をアピールしていかないと,経営はシステム業務のアウトソーシングという“麻薬”に手を出しかねない。

 最近,情報システム部門の間で「SLA(サービス・レベル・アグリーメント)」に関心が集まっているのは,システム部門の危機感の表れだろう。SLAとは,システム・サービスの提供者と利用者の間で合意したシステム・サービスの内容,範囲,品質に関する取り決めのこと。システムの運用時間,システム障害が発生したときの目標復旧時間,利用者の満足度などをSLAの合意項目に含めることもある。

 これまでSLAはアウトソーシング・サービスの利用時に,ユーザー企業とベンダー(アウトソーシング事業者)の間で結ぶことが多かった。しかし,最近は身内,すなわちシステム部門と利用部門の間や,システム子会社とグループの事業会社の間でSLAを結ぶケースも増えてきている。

 身内でSLAを結んだシステム部門やシステム子会社の狙いははっきりしている。SLAを導入・運用する過程で,既存の情報システムの足りないところやムダを明らかにすることだ。

 例えば,利用部門の担当者は「とにかく止めずに動かしてほしい」との要望をシステム部門によく寄せる。システム部門からしてみると,「就業時間の間は止めない」を求めているのか,「24時間連続稼働させる」のを求めているのか,はっきりしないことがある。こうした悩みもSLAをまとめていくうちに解決する。最初は「とにかく止めないで」と繰り返していた利用部門の担当者も,必要なコストを明示しながら話を詰めていくうちに,考えがまとまる。システム部門は,利用部門の真意をくみ取って,IT投資にメリハリを付けることができる。

 いったん利用部門とSLAを取り決めたあともSLAは効果を発揮する。SLAで決めた「障害発生時の復旧時間の目標値」などの指標を,システム部門(やシステム子会社)自体の業務目標にすればよい。明確な目標があれば,システム・サービスの品質は確実に上がる。担当者の士気も向上するはずだ。これは製造現場におけるQCにほかならない。

 SLAをシステム部門内のQCのきっかけに,システム部門は改善運動に取り組んでほしい。障害発生時の復旧手順を整備したり,原因究明のノウハウを担当者間で共有するなど,やるべきことはたくさんあるはずだ。

(西村 崇=日経コンピュータ)