第２回まででIT技術の品質管理の全体像について説明してきました。第３回からはシステム運用の業務範囲の中で品質をどう扱えばいいのかについて説明します。

目次

■昨今のシステムトレンドとインフラ基盤運用の関係について■

■システム運用に求められる品質は何か■

■運用品質を認めてもらうためには何が必要か■

■運用品質の価値の見える化が大切■

■昨今のシステムトレンドとインフラ基盤運用の関係について■

ITシステムは大雑把に言うと、イノベーション系と効率化系に分けられます。前者はまだ世の中に実現していないIT技術により新しい価値観を作り出します。後者は既に何らかの方法で世の中に存在する業務をシステム化し、より価値が高まるように業務に合わせて付加価値を追加したりシステムのベースコストを下げる仕組みです。顧客から見える部分のITシステムがイノベーション系であったとしても、システム基盤部分の構築、運用、保守は効率化系に分類できます。ここからは効率化系のシステム基盤の運用についての品質管理についてお話しします。

■システム運用に求められる品質は何か■

システム開発でのシステムに対する品質管理は当たり前のように実施していると思いますが、製品や商品は顧客が使って初めて価値が出てくるにも拘わらず、開発と運用では往々にして担当が変わるため、一貫した品質目標を定めるのが難しいとも言われます。
さらに、システム運用ではインフラ部分の開発を運用で行う場合があり、何が開発で何が運用かの境界が不明確になり、管理対象の焦点を合わせることが難しくなる場合もあります。
これを防ぐために非機能要件で運用についての品質管理の要点を記述しますが、運用と保守業務に精通していないと実際に具体的な運用作業をシミュレートし効果予測するまでの分析を行うことは難しく、導入後に多くの乖離が見られます。
しかしながら、利用者の立場からシステムにお願いすることは、
· システムが予定通りに動くこと
· どう使えばいいかマニュアルがあること（あるいは教育があること）
· どうしても困ったときに問い合わせる窓口があること
に集約されます。
ここに設計書やテスト仕様書、稼働報告書は関係してきません。これらはシステム管理者にとっては有用ですが、利用者にとっては特段の価値がないからです。
システム運用業務を簡単に定義すると、実際にシステムの価値を生み出す場で、開発した製品を「当初計画で見込まれた価値を得られるように動かし続けること」が仕事です。
「動かし続けること」というのは実際には大変で、特に複雑系（ハードウェア、ネットワーク、OS、ミドルウェア、アプリケーション等の相互作用で動作が変動するもの）は現象と原因の結び付けが困難を極める場合もあり、システム開発とは違う独自の技術が必要とされます。
例えば家庭のパソコンでは簡単に行うOSのバージョンアップですら、ミドルウェアやアプリケーションが動作するかの確認や、関連のあるシステム間でのバージョン差異の混在で影響が出ないか等の検証が必要となります。
このため、工程品質それぞれの目標と実現手段を明確にし、特に開発チームと運用チームの共通認識になる使用品質においては、双方の限界、境界を見える形にし、リリース前に運用チームが柔軟に運用設計する余地を残す必要があります。
ここでは理屈として簡単に書いてしまっていますが、現実には開発完了後に運用を別会社に発注し直接の移管ができないことや、開発の保証期間内に無理やりサポートや後追いの運用設計を行うなど、多くの混乱が見受けられます。
システムを開発せずミドルウェアやアプリケーションにパッケージを使うことも多く、この場合は開発側からの情報提供がマニュアルとヘルプデスクになっていることがあります。パッケージ開発メーカーがアナウンスしている環境に合わせてインフラを構成する以外の手段はほぼ無いのですが、特にOSやミドルウェアのパッチとアンチウィルスとの相性については泣きたくなるほど悩まされます。これらは複雑なOS割り込み処理を使いメモリーやI/O機器にアクセスしますので、CPUアーキテクチュアの高度化に伴い、影響調査の複雑化が進んでいます。
日々、システムを取り巻く環境が大きく変化していても、利用者から見れば、「いつも通り普通に使えること」がニーズであり、第２回で述べた魅力的品質では「当たり前品質」を中心に求められ、アトリビュートマトリクスでは基本的要素が強く求められる割には否定的特性だけは基本的要素、差別化的要素、決定的要素が強く出てきます。
運用の経験がある方は思い当たることがあるのではないかと思います。
システム運用がこのように重要で簡単ではない業務であるにも関わらず、高評価を得ることが難しいため、あまり楽しそうな仕事には聞こえなくなってきてしまいますが、それでも運用を行っていて、「仕事の品質が良い」と褒められ評価が上がることもあります。だから評価される仕事の仕方は存在するということです。
せっかく頑張って仕事をするのであれば、「どうしたら認められるか」ということにも気を配り、成果を認めてもらう仕事の進め方を行いたいものです。

■運用品質を認めてもらうためには何が必要か■

周りから見て運用チームが目立ちにくいのは、上記のように「当たり前品質」の範囲の業務を遂行しており、否定的特性が取り上げられやすい仕事の見え方が要因の一つです。
目に見える具体的なoutputサービスがないため、目標設定が難しいと感じる方も多く見受けられます。
考えるポイントは、運用側から利用者にとっての価値として提案することで、

が重要となります。
この時に重要なのは、目標は利用者に理解される言葉で表現しなくてはいけない点です。
そしてこれを実現するために運用で何を行ったのか利用者から見える形で表現（報告）することが重要です。
つまり第２回までに述べた、「満足度を保証するために、どのような評価軸を定義し、それを測る方法と遂行する手段をどう定めて運用業務を行い、その結果がどうであったか」を提示できる仕事の進め方が重要です。
同時にゴンペルツ曲線の成長カーブの範囲で、投資対効果が高い活動を実施していることを示すこともポイントです。

運用の現場では、「△△月◇◇システムのバージョンアップ完了」というような情報が並ぶガントチャートを目にすることは多いと思います。これだけを見て日々の仕事を行っていると、どうしてもやらされ感しか湧かないと思います。ではちゃんと理解しようと各計画書の中身を見ると、実施概要に「◇◇システムの累積バグ対応、及びWindowsXX対応のため、バージョンアップを行う」とあり、別のサーバーマシンへのインストールや移行前テスト期間、データ移行や補償範囲の定義、ロールバック手順、アナウンスタイミング、など、多岐にわたる作業内容が並びます。運用とはこんなにも面倒なものか！という実態は周りからあまり見えません。しかしこれを利用者に見えるようにしても、「手間かかります」ということしか現れてきませんし、利用者にとってはどうでもいいことです。要は利用者がシステムを使えればいいのです。
そう思われても運用チームはこの業務が必要と考え実現しなくてはいけないことは明白です。実施計画をきちんと立てて、最終的に完了させないといけません。
ここまでですら、すでに両者で目標が少し違っているように見受けられてきました。
秒進分歩のIT環境とそれを利用している事業の動きの中では、当初計画通りでは本来の目的が達成できなくなるケースもあります。システムを計画する際には理由と理屈があって然るべきですが、それはあくまでシステムを利用する事業への影響で表さないといけないはずです。
この例ではバージョンアップが利用者にどのような影響を与えるか、あるいは与えなくて済むかが根本要因になるはずです。必ずしもメリットだけではなく、デメリットも飲んでもらわないといけないこともあるでしょう。そうした場合に利用者目線で計画を説明しないと理解されません。
現実には運用の内情を知っている人から深く追及されることはあまり無いかもしれませんが、このことが問題なのです。経営はプロフィットとコストの対比で勘定します。コストセンターでなければプロフィットセンターでなければいけませんが、その場合は利益を明示しければなれません。中間は無いと考えておくべきです。

そうなのでしょうか？決してそうではないはずです。
運用品質を利用者のメリットに結びつけていないと、このような言われ方をされ、悲しい思いをします。（なんだか給料も少ないような気もしてきます）

■運用品質の価値の見える化が大切■

プロジェクト管理にて各作業工程の締め切り日に対する進捗を時間や日数で表すお馴染みの工数管理の他に、作業工程が生み出す損得勘定で進捗を表すEarned Value Managementという手法があります。後者は一言でいえば、プロジェクトの全てをお金に換算して管理すれば一つの見方で統一した管理が行えるというものです。
この手法と同様に、運用の業務を全て品質という評価軸で統一すれば品質管理を行うことでのメリットを表現し易くなり、管理が楽になるという考え方があります。
品質管理はバグやトラブルを数える行為ではありません。業務を評価する手法でもあります。
特にシステム運用においては、満足度や精度という表現が微妙な要素が多いので、きちんと分析して定量的な品質管理として仕事を見ていく必要があると考えます。
システム運用での品質管理というのは、効果が見えにくい運用業務において業務価値、つまり利益を見える形にする手法なのです。それにより運用担当者も正しい評価を受けられることになります。

第３回では、システム運用における品質の考え方について説明しました。特に品質を定量的に評価することがプロジェクト管理に繋がるというアプローチはあまり知られていなかったと思います。第４回は運用品質を定量的に測定するツールについて説明します。