概要
前回のコラム「システム運用設計」というテーマに引き続き、今回からは「運用設計を考える」というテーマで再度、連載をいたします。今回は、皆さんからのご意見やご質問なども受けながら、トヨタ生産方式の考え方も織り込んで、運用設計について考えていきます。
皆様こんにちは。伊藤です。
２０１２年８月から１年間、私は本サイトで 「システム運用設計で必要なこと」 というテーマでお話してまいりました。その際の主要なテーマは、「障害対応は、システム運用の本来の業務ではない」ということでした。今回は、システム運用を、通常の「ものづくり」の業務と比べることで、そのあたりのご理解を深めていただきたいと思います。
さて「運用設計を考える」第４回目は、システムのカットオーバーについて考えてみます。
ユーザーテストという言葉
私は製造業に勤めております。製造するモノは常に変化しています。私の勤務先は自動車製造業ですので、モデルチェンジが行われます。
モデルチェンジといいましても変化の規模は様々で、部分的な改善から全面的に再設計したり、新たなモデルを生み出すこともございます。このように規模は異なりますが、一般のお客様に販売する前に必ず行うことがございます。それを以下でご説明いたします。
お客様にお届けする自動車を生産することを、弊社では”号口（ごうぐち）生産”と申しております。通常、モデルチェンジの際は、それまでと同じ製造ラインを流用いたします。 そして、新しい車は、号口生産する前に、実際の作業員が、実際の設備を使い、実際の作業要領に従って製造されます。その目的は、新しい車が、企画した各種の仕様や機能を満たしているかを評価することはもちろん、当初計画した製造工数や品質性能を満足しているかを評価いたします。
自動車には車検制度があることはご承知だと思いますが、お客様に販売する前にも車検をパスしていなければなりませんし、その前に型式認定というプロセスを経ないと公道を走る自動車を販売することができません。新しい車がこれらの条件をパスすることは当然必要なことですが、継続的に生産し、出荷するためには、実際の生産ラインで常に車検をパスできる生産工程が構築されていなければならないのです。
また、会社の立場からすると、当初計画した製造工数や品質を確保できない場合、そのまま号口生産に移行してしまったら、計画台数が出荷できなかったり、原価割れを起こしてしまい、経営への大きな影響を与えてしまいますので、この評価タイミングで製造工数や製造品質を確認することは、経営上も非常に大きな意味があります。
したがって、このプロセスは、順を追って何度も繰り返し、範囲も徐々に拡大しながら慎重に進められます。当然、各段階での完成度の目標も定め、最終目標に向かって展開されます。なお、弊社ではこのプロセスを”号口試作”と称しています。
さて、ひるがえって情報システムの場合を考えてみましょう。
カットオーバー前の最終段階で、”ユーザーテスト”を行うのが一般的ですが、この内容は、充分なものでしょうか。実は弊社でもシステム開発では”ユーザーテスト”という言葉を使っているのですが、モノづくりの場合の”号口試作”と比べてみた場合、かなり簡単に済ませているのが実態です。
前回のコラムで、「最近のシステムは、オンライン処理と連携したバッチ処理が行われ、情報発生源でのデータ入力や、利用部署での情報アウトプットが行われているのがほとんどでしょう。・・（中略）・・ビジネスの中で”システムがどのように使われるか”が運用である と考える必要があるわけです。」と申し上げました。
従って、システムのカットオーバーを行う前に、実際の環境でシステムを動かしてみて、利用者や運用者の作業はどうなのか、訓練や教育はできているのか。予期しない作業が発生していないか。さらにこれは一番重要なポイントですが、そのシステムを利用する業務プロセスが当初意図したように改善され、機能しているのか。ということこそを確認する必要があるのです。これは、もはや”ユーザーテスト”という言葉の範疇を超えている内容です。
“ユーザーテスト”という言葉には、新システムの利用者自身が出来上がったシステムを使ってみて、自分の意図したように入出力が出来ていることを確認するイメージがつきまといます。しかし、カットオーバー前の最終確認としてはそれでは不十分で、モノづくりの現場での”号口試作”に相当する言葉が、システム開発においても必要であるとともに、そのための体制や時間も確保することが、新システムを成功されるために重要なことだと考えます。
読者の皆様からの質問にお答えします
事務局に、皆様からのご質問やご提案などを頂いております。まことにありがとうございます。
頂いたご質問の中で、今回は、「見える化ボード」の実物をご紹介したいと思います。「見える化ボード」は、「運用設計を考える」第1回でご紹介していますが、その部分を再掲させていただきます。（※）
———————————————–
私はシステム障害を減らすために「見える化」を行いましたが、残念ながら究極の「見える化」はできませんでした。「システム障害は異常な状態で、異常対応業務は運用者の本来の業務ではない」という状況を、その場で誰にでも判るようにしたかったのですが、良い知恵が出てきませんでした。
そこで、次善の策として、障害発生時に、情報システム部員全員に発生を伝えることと、見える化ボード（横軸に日付、縦軸にシステム名を並べて大きな表にし、障害が起きたシステムと日付の交点にマークをつけ、障害対応状況｛暫定対策、復旧、要因解析、再発防止対策完了｝毎にマークの色を変える）を使用して「見える化」を行いました。（「運用設計を考える」第1回より）
———————————————–
見える化ボードはひと月分が一枚になっています。前述したように、赤い丸いシールが、障害の起きたシステムと日付を表しています。あと、その障害についての対応状況が進むにつれて、黄、緑、青のシールを重ねていきます。ここで、あえてシールを同じ日に重ねて貼っているのは理由があります。対策が終了した日付の位置にシールを貼ることも考えましたが、それでは、このボードを一見したとき、どの障害の対応が進んでいるのかどうかがわかり難くなるためです。例えば今日が１５日だとすれば、一週間前の８日の障害が赤のシールのままなら、対策が進んでいないことが一目瞭然です。これを、情報システム部の開発、運用の責任者と部長が毎朝確認してまいりました。
この「一目瞭然」ということが「見える化」の重要な点なのです。
さらに、この「見える化ボード」を作成して思わぬ収穫がありました。写真１の上のほうにあるシステムですが、ほぼ毎週、週末前後に障害が起きています。ばらばらの障害報告書では、なかなか気がつかないのですが、統計とかグラフ化とかしなくても、「見える化ボード」によってこのような障害の発生パターンや、障害が起きやすいシステムが、まさに「一目瞭然」に「見える」のです。
このようにして、新たな気づきも得られ、隠れた問題を見つけることにもつながりました。
以上 「見える化ボード」についてご紹介させていただきました。
次回予告
次回は、 運用設計を考える 第５回 「情報システムを取り巻く脅威とその対応」の予定です。
「標的型攻撃」などの新たな脅威から、内部者による情報漏洩という従来からある脅威まで、情報システムを取り巻く脅威は増える一方です。実運用を行う前に、どのようなことを考えておくべきでしょうか。読者のみなさんが懸念されていることがありましたら、事務局に御連絡いただければ御一緒に検討してまいりたいと思います。また、これまでのコラムの内容についての疑問、ご意見につきましても引き続き承りたいと存じます。
連載一覧
筆者紹介
伊藤 裕 (いとう ゆたか)
トヨタ車体株式会社 情報システム部 ITマネジメント室 参事補
自動車製造業でのシステム管理、運用部門の管理者をはじめ、IT予算管理、J-SOX、セキュリティ対策対応など、企業の情報システムにおける様々な経験をもつ。
コメント
投稿にはログインしてください