概要
前回のコラム「システム運用設計」というテーマに引き続き、今回からは「運用設計を考える」というテーマで再度、連載をいたします。今回は、皆さんからのご意見やご質問なども受けながら、トヨタ生産方式の考え方も織り込んで、運用設計について考えていきます。
皆様こんにちは。再び本コラムを担当させていただきます伊藤でございます。
先回、「システム運用設計」というテーマでコラムを連載させていただきましたが、今回から「運用設計を考える」というテーマで再度お話させていただきます。今回は、皆さんからのご意見やご質問などもお受けしながら、一緒になって「運用設計」を考えていければいいな。と考えていますので、拙文をお読みになって、ご意見やご質問を持たれた皆様は、システム管理者の会の方にご連絡をお願い申し上げます。
さて、まずは、「見える化」について考えてみましょう。
そもそも「見える化」ってなんでしょう
皆さんは「見える化」という言葉をどう捉えていらっしゃいますか。最近は、「見える化」とか「可視化」という言葉をよく聞くようになってきました。一般的に考えれば、目に見えない、もしくは見えにくい事象を、信号や、ディスプレイなどを使って目視できるようにすることとして使われていると思います。
ところで、私の学生時代の専門は、機械工学でした。機械の動きは人の目に見えることが一般的です。大きな飛行機が空を飛び、ビルほどの大きさのショベルカーが、鉱山で仕事をしています。とても分かりやすい世界ですね。一方、友人で電子工学を専攻していたものがいますが、こちらの世界では、トランジスタや、ICチップ(現在でしたら、CPUのチップ一枚の中に、とんでもない数のトランジスタや電子素子が組み込まれていますけど)を扱っていて、それをじっと見ていても電子の振舞いが目に見えるわけでもありません。蒸気機関車のピストンロッドと動輪の動きの躍動感にわくわくしていた私にとって、彼らは一体、何が面白いのだろうか。と思っていました。
昔話はこれくらいにして、「見える化」に戻りますが、このように電子の動きとか、非常に微細な現象とか、金融だとか、その他の諸々の事象をわかりやすくするために、「見える化」、「可視化」が工夫されてきています。
では、「見える化」「可視化」の目的はなんでしょうか。事象をわかりやすくして、その後何をするのでしょうか。
実は、「見える化」はしたものの、そのあと何をするのかが、はっきりしていないことも多いように感じます。従って「見える化」の前に何かを付け加えるとよいでしょう。私にとっての「見える化」は、実は「異常の見える化」でした。先回の私のコラムを読まれた皆さんには繰り返しになってしまいますが、私は、システム障害をどうしたら減らすことができるか。という課題に対し、「システム障害の見える化」に取り組んできました。
以上のように、「見える化」は目的ではなく、何かを行うための手段なのです。
「異常の見える化」
目的が決まったら、どのように見えるとよいのでしょうか。よく使われるのは、棒グラフや折れ線グラフなどのグラフでしょうか。でも、それだけが「見える化」ではありません。
ここで、皆さんにある光景を想像していただきたいと思います。そこには二つの生産工程があります。仮に、一方をA工程、他方をB工程としましょう。どちらも同じものを同じペースで生産しています。A工程では、自分の持ち分の作業が終わってしまったら、その人は持ち時間中でも椅子に座って休憩することになっています。また、持ち時間中に作業が終わらないときは、ボタンを押して工程を止めるようになっています。一方、B工程では、自分の持ち分の作業が終わってしまったら、他の遅れている人を手伝うことになっています。遅れている人を助けて、極力工程が計画通り動くようにするのです。
さて、工程の問題点を見つけ、改善しようとしたとき、どちらの工程の方が、課題(作業負荷のアンバランスや設備の不備など)が分かりやすいでしょうか。ちょっと考えてみてください。
答えはA工程です。「仕事時間中にも関わらず休憩」していたり、「ラインが止まっている」ということは、「何かおかしい」、「普段とは違っている」ということが「誰が見ても」分かります。これが究極の「見える化」です。ポイントは、誰が見てもいうところです。専門的な知識を持ち合わせていなくても、極端に言えば通りすがりの人でも、普通じゃないことが判るしくみです。そうすると、専門家でなくても、その状態を改善する動機が生まれるわけです。しかも、「見える化」のためのシステムもグラフ化も不要です。
このようにして「見える化」することで、A工程は課題を見つける動機づけが行われ、工程改善が進みます。一方、B工程は、はじめのうちは計画通り生産できるかもしれませんが、それ以上の進歩につながりにくいのです。
システム運用における「見える化」
それでは、システム運用の現場での「見える化」について考えてみましょう。
私はシステム障害を減らすために「見える化」を行いましたが、残念ながら究極の「見える化」はできませんでした。「システム障害は異常な状態で、異常対応業務は運用者の本来の業務ではない」という状況を、その場で誰にでも判るようにしたかったのですが、良い知恵が出てきませんでした。
そこで、次善の策として、障害発生時に、情報システム部員全員に発生を伝えることと、見える化ボード(横軸に日付、縦軸にシステム名を並べて大きな表にし、障害が起きたシステムと日付の交点にマークをつけ、障害対応状況{暫定対策、復旧、要因解析、再発防止対策完了}毎にマークの色を変える)を使用して「見える化」を行いました。
ただし、システム運用を行っている場所と情報システム部の事務所が離れていたたこともあり、見える化ボードは事務所の方に置きました。これによって、開発者にも障害情報が共有できたことは良かったと考えています。
運用設計における「見える化」の提案
運用設計とは何を指しているのでしょうか。以下に以前本サイトに掲載された記事を引用させていただきます。
「システムは一旦稼動し始めると、計画停止や異常が発生した場合を除き、次のシステム更新があるまでは動き続けます。その間、稼動させるシステムを長期間安定稼動させる、あるいは維持管理させるために、多くの事項を想定・考慮してシステムの開発/保守を行う必要があります。
また、システムは平日・休日・日中・夜間・時間帯・携わる関係者など、周りの状態により日々変化しながらまるで生き物のように動きます。曖昧な状態でそのようなシステムを稼動させると、必ず混乱やトラブルを招き、それを回避するために運用作業としてカバーすることも少なくはないようです。
運用設計とは、そういった想定される事態、状況、変化をシステム構築段階で要件として吸収し、未然に混乱やトラブル、曖昧さを防ぎ、そのシステムが思ったように動いてくれるような環境や仕組み、作業などについて明確化させることをいいます。(運用規約、運用設計書第4回 運用設計とは ITシステム運用コンサルタント 沢田典夫氏 2005年12月07日掲載 より)」
それでは、運用設計で「見える化」をどう考えればよいのでしょうか。この場合の目的は、「システムが思ったように動いていない状態」を「見える化」させることだと考えます。これについて私は、二つの視点を提案いたします。
一つ目は、運用設計どおり、システム運用が行われているかどうかを「見える化」することです。逆の見方をすれば、運用設計で想定された業務と、そうでない業務を区別し、そうでない業務を行っていることを誰でもわかるようにすることです。運用設計で想定された業務を行うエリアと、そうでないエリアを分けて、想定外業務エリアで誰かが仕事をしていることで想定外業務を「見える化」できます。ただし、運用設計の段階で、そこまで考慮した業務設計が出来ていないと難しいかもしれません。
もう一つの視点は、運用設計されたシステム運用業務事態をさらに改善するための「見える化」です。これは、運用設計は必ずしも100点満点で行われているとは限らないし、また環境や与件が変われば、適切な運用の方法も変わっていく。と考え、対象のシステムが、より効率的に運用されるように、課題を明確化するための「見える化」です。
いずれにせよ、システム仕様を固める段階で、出来るだけ誰が見ても分かる「見える化」のための「しくみ」を考え、織り込んでおくことで、運用時点での業務の「見える化」、ひいては運用業務の課題の明確化、改善につなげていくことができることでしょう。
私の取り組んだものは、後者の範疇の一部である、システム障害の「見える化」でした。この範疇には、ほかにも標準的な時間内に業務が終わっているか、誰でも同じレベルで業務が行われているか、等の確認項目があります。これらについて、どうしたら「見える化」でき、課題発見、業務改善に結び付けることができるか、皆さんからもご意見をお聞かせ頂ければ幸いです。「見える化」ノウハウを共有して、効率的な運用設計、システム運用を目指したいと思います。
次回予告
次回は「障害対応は、システム運用の本業か」についてお話をしたいと思います。
連載一覧
筆者紹介
伊藤 裕 (いとう ゆたか)
トヨタ車体株式会社 情報システム部 ITマネジメント室 参事補
自動車製造業でのシステム管理、運用部門の管理者をはじめ、IT予算管理、J-SOX、セキュリティ対策対応など、企業の情報システムにおける様々な経験をもつ。
コメント
投稿にはログインしてください