4月25日に起きたJR福知山線の脱線事故は，犠牲者が100人を超える惨事となった。直接の事故の原因はスピードの出しすぎだった。だが，その背景にはJR西日本の過密スケジュールがあるとも，列車自動停止装置（ATS）の配備の問題があるとも，「日勤教育」と呼ばれるミスをした職員へ運転士に対する過酷な再教育が関係しているとも言われている。
特に記者が気になったのは，日勤教育である。ミスをした人間に対して罰則とも思える厳しい措置を施すのはJR西日本だけではない。対象も社内だけでなく社外の取引先であることもあろう。こう考えたのには理由がある。
厳しさだけでは信頼は生まれない
記者は今年3月に記者の眼で「未熟な業界だから動かないコンピュータが増えるのか」という記事を執筆した。その中で，トラブルを引き起こしたIT業界のベンダー担当者に対する発注者の厳しい対応の実態を記した。こうした対応に，日勤教育に近い考えを感じるからである。その内容を再録する。
あるベンダーの担当者は，稼働させたシステムに不具合が多発したため，ユーザーと事後の交渉を進めるための会合を持った。席に座ろうとしたその担当者は，怒り心頭に発したユーザーから「座るところが違うだろう」と言われ，床に正座したままで交渉を進めた。別のベンダーの方はずっと座れなかった経験について語ってくれた。ある製造業のユーザーで，稼働していた受発注システムが突然障害を起こし，何日間か取引先との受発注ができない状況になった。このベンダーの方はこの間，不眠不休に近い形で問題の処理に当たったが，トラブルは収束しなかった。トラブル発生から数日後，ユーザーの担当者と対応策を練る打ち合わせを開くことになったが，「問題が解決するまでは座るな」と言われ，もうろうとした頭で立ったまま打ち合わせをこなしたのだそうだ。
厳しい対応である。こうした厳しさが，当事者に二度と失敗を生まないようにしようとう緊張感を起こさせるのは事実だろう。だが，ただただ厳しい対応が最善の結果をもたらすかどうかが疑問なのである。
厳しさだけが強調されるようになれば，とにかく失敗だけを避けようと考えて，積極的にチャレンジしようという意欲を失わせかねない。なかには，できるだけ失敗を隠そうと考える人間も出てくるかもしれない。隠し続けることでミスは減らない。むしろ，より大きな問題の引き金となることもあり得る。
IT業界に絞ってもう少し話を進めたい。こうした厳しい対応は，発注者と受注者のコミュニケーションや信頼関係を悪化させる恐れがある。特に情報システムの開発や運用は，発注者がただ依頼して，それにベンダーがこたえるというものではない。開発の過程でも運用に入ってからも，両者の間でコミュニケーションを取りながら問題を解決する必要がある。
定量化の手間こそが関係改善をもたらす
では，発注者とベンダーのコミュニケーションや信頼関係を維持・改善させながら，失敗を減らしシステムの開発や運用の質を改善させるためためには，どうすればいいのか。ただただ厳しい対応には限界があるだろうが，何の厳しさもない状況で品質の改善が見込めないのも確かだ。発注者とベンダーが良好な関係を築いており，システムの開発や運用に問題がないなら言うことはないが，現実にはこうしたケースはそう多いわけではない。
この点で記者が今，注目しているのがSLA（サービスレベル・アグリーメント）である。SLAは，ユーザーとベンダーとの間で，サービスの内容を定量的に保証する取り決めを結んで，より品質の高いサービスを実現する手法の一つである（解説記事）。ご存じの方も多いだろう。
守るべきサービスの水準を定量的に管理することで，何がミスで何がミスでないのかがはっきりする。守るべき基準が決まれば，そのために何からやっていけばよいかを考えることができる。これがSLA導入のメリットである。
一方で，SLAを導入する場合には，どんな項目についてサービスの内容を定量的に測定するのかを決めなければならない。SLAの対象となった項目については，必ず測定する必要もある。そのため，SLAの導入には費用も手間もかかる。無理をして導入する必要はないのではないか，という意見があるのも確かだ。
だが，SLAの対象項目の設定や測定いった作業こそが，発注者とベンダーの信頼関係の醸成に有効なのだ。何を測定の対象にすべきなのか，それはなぜ対象にすべきなのか，どういった方法で測定するのがよいのか。当然ながら，こういったことについては発注者やベンダーの一方だけで決めることはできない。両者の間で議論を積み重ねて合意に至るわけだ。この議論が，信頼関係をもたらすのである。
まず入れることからSLAが始まる
実は記者のSLAについての知識は，大半が電子情報技術産業協会（JEITA）の策定した「民間向けITシステムのSLAガイドライン」によるものだ(関連記事)。昨日(5月19日)，JEITAはこのガイドラインの第二版を公開した。弊社でこの第二版を出版することになり，記者が編集を担当することになったため，全文を読む必要があったからである。必要があってガイドラインを読み始めたわけだが，気づかされることが多かった。
SLAを導入しても，ベンダーに対する厳しい対応がなくなるのか，という意見もあるだろう。SLAを導入する際には，品質を保証した項目を守ることができなかったときに，それに対するペナルティを課すことはSLAでは珍しくない。
この点について，JEITAのガイドラインでは，厳しすぎるペナルティの導入には慎重であるべきだとしている。あまりに厳しいペナルティは，ベンダーの自発的な改善への意欲を減退させることに加え，サービスの提供コストそのものを引き上げる可能性があるというのがその理由である。あるいはペナルティだけでなく，ある一定以上の品質水準を実現した場合のインセンティブを導入する可能性についても触れている。冒頭に書いた発注者とベンダーの信頼関係の構築を連想させるものである。
たまたま最近，独力でSLAを導入した取材先の方と話す機会があった。この方は，JEITAのガイドラインのことは知らなかったのだが，SLA項目の洗い出し，ペナルティの扱い方，対象とするSLAの項目選びの方針まで，ガイドラインに書いてあるものに近かった。日本人のガイドライン好きを気にする向きもあるが，こうした実例を見ると，ガイドラインの有用性を感じる。
また，このガイドラインでは，導入当初から多くの項目をSLAの対象にすることは控える方がよいとしている。まずはできることから始めて，内容を広げていこうという考え方である。これは単にSLAの導入に敷居の高さを感じる企業に配慮したのではない。SLAを固定的なものと考えるのではなく，絶え間ない検証と見直しによって内容を改善させていくという，SLM（サービスレベル・マネジメント）の考え方に沿ったものだ。
SLAを数年前から導入している取材先からは，こんな話を聞いたことがある。「別に自社のSLAがどんなものであるかを知られても問題はない。SLAを改善させてきたプロセスはだれにもまねができない」と話していた。SLAの内容や実施方法は企業機密や独自のノウハウになるから公開は難しいのではないか，という記者の質問に対する答えだった。SLMの重要性を改めて意識した瞬間だった。
細かい取り決めなしに結果だけを求める方法には限界がある。特にその内容が複雑化する一方で，さらに高い品質を求められるようになってきたシステムの世界では，なおさらである。今こそ「日勤教育」型の考えを脱却し，見える化と絶え間ない改善に裏打ちされたSLA導入を考えるべきではないだろうか。
（中村 建助＝日経コンピュータ）
