14:11Tweet皆様こんにちは。いうテーマでお話してまいりました。その際の主要なテーマは、「障害対応は、システム運用の本来の業務ではない」ということでした。今回のシリーズではその「ものづくり」の着眼点を、システム運用などの改善に適用した事例をご紹介してまいりました。今回はシリーズ最終回となりますので、皆様からいただいたご質問やご意見へのお答えをさせていただきます。仕事の工程やマニュアルの改訂や浸透はどうしているか次のようなご質問をいただきました。ご質問1.すごい頻度で工程やマニュアルを改訂しているみたいに見えるが毎回ちゃんと浸透するのか。変えることに対する抵抗などはないのか。ご質問2.工程を変えるのに、どれくらいの時間がかかりますか。承認者ルートなどは確立されているのでしょうか。変えたいと思っても、事の仔細を説明して上長を通し部門全体に通し・・・とやる必要があり、そっちの方が時間がかかる気がして踏み切れません。面倒なことをしてくれるなという同僚の目も怖いし・・。皆様は「カイゼン」という言葉をお聞きになったことがあるかと思います。ご承知のように、トヨタ生産方式の重要なキーワードの一つです。この「カイゼン」は、従来ものづくりの現場で行われてきた作業の見直し活動から始まった言葉で、作業効率の向上や安全性の確保などに関して、現場の作業者が中心となって小集団活動の中で知恵を出し合い問題解決をはかっていくことです。その際に重要なことは二つあります。一つ目は、小集団活動で行うということ。二つ目は、「カイゼン」した作業のやり方は、必ず作業標準を改訂し、標準作業化するということです。その工程の作業のやり方は、その工程を受け持つ最小単位の組織の長が責任を持つようにしていますので、改訂もその組織長の責任の下で行われます。これまでのコラムで申し上げてきたことは、システム運用や開発のやり方を見直し、品質や業務効率を向上させる取り組みであり、基本的には、この「カイゼン」と同じです。ご質問者が懸念されるように、誰かが仕事のやり方を変えて、関係するメンバーへ展開する場合は、周知・徹底は大変重要になりますし、従わないメンバーが出てきてしまうおそれもあります。そのようなことを避けること意味もあって、実際の業務を行うメンバーが集まって知恵を出し合って「カイゼン」を行うことが重要になってきます。メンバーの意見は集約され、周知・徹底もその段階で行われているわけです。マニュアルを改訂するだけではなく、可能な限り作業のプロセスをテンプレート化し、最新のテンプレートを使うことで、だれでも常に最新のやり方ができるなどの工夫を行っています。承認、標準やマニュアルの改訂に際しての承認プロセスに時間がかかる問題に関しては、一つのグループ内で完結する内容は、そのグループの長が責任を持つなどのやり方で、できる限り小回りが利くようにしています。建前としては以上となりますが、実際はやはり一人ひとり意見が違ったり、新しいやり方を行わない人も出てくることもあります。クリエイティブな業務では違うのかもしれませんが、情報システムの世界、特にシステム運用においては、作業者それぞれが自分のやり方で仕事をするのではなく、皆が同じやり方で仕事をしなければ継続的なシステム運用が成り立たない、という前提に立って、周知・徹底は地道に根気よくやっています。「カイゼン」の頻度につきましては、やはり障害発生が引き金になるケースが多いのでそれなりの回数はありますが、障害の再発防止や未然防止を図るための根本対策のためには必要なこととして取り組むよう意識づけすることがポイントだと考えています。コラムでも書きましたが、障害対応をすることが「仕事」ではなく、障害を減らすことが「仕事」である。●どうすればルールは守れるか次のようなご質問もいただきました。ご質問3.ルールや決め事について、新人などが、なぜそういうルールがあるのかを考えず、大切さに気づかずミスをしてしまうが何か防止策はとっていますか。ご質問4.障害が起きるたびに改善のためのチェック項目が追加されて必要な工数が増え、逆にルールを守らなくなって同じような障害が起こり、改善につながらない。実は、私の職場でも同じようなことが起きています。ルールを守るために、チェックシートなどを作ったりしていますが、一定頻度でのミスは起きてしまいます。人手によるチェックや、ルール順守にはやはり限度があると考えています。そこで、なぜチェックが必要な作業になっているのか、人手に頼らなければならないのか、という観点で問題をとらえなおすことを提案いたします。第3回のコラムの中で書きましたが、これらはやりにくい作業として考え、どうしたら人手でチェックしなくても済むようにできるかという観点から、情報システムの運用面の仕様から見直す取り組みを行っています。半角英数字のみしか受け付けられない仕組みにも関わらず、データ入力画面で全角入力ができてしまう。A処理と、B処理では処理の順序が決まっているのに、逆の順序もしくは前処理がなくても動作してしまうプログラムなどがあると、人手に頼らざるを得なくなります。加わり、より一層複雑になっているのが実態でしょう。JOB管理システムも進化していますが、管理システムの設定が複雑になれば、人間のミスも増加しますので、現状のシステム構成の棚卸しを行い、特に運用者や利用者の判断や操作に頼っている部分に焦点をあてると問題点も抽出しやくなります。これらの事柄を"運用のやりにくさ"として洗い出し、どのような仕様にすれば人手に頼らなくてもよくなるのかをシステム開発部門と運用部門や利用部門とが一緒になって検討し、改善することが、ポイントだと思います。おわりに今回のシリーズでは、「ものづくり」の視点から情報システムを考えてまいりました。これは、私がシステム障害の低減活動を行ってきた際、「ものづくり」の視点を手掛かりにしたことがきっかけになっています。ムダ」などの言葉を使って従業員一人ひとりが自分たちの行っている業務の問題に気づき、改善に取り組んでいます。私は、このような、歴史もあり、規模も大きな「ものづくり」の現場での改善への着眼や進め方の経験は、システム開発、運用の場面でも活かせるのではないかと考えました。実際にシステム運用の改善活動で試行錯誤する中でその考えが充分通用することがわかりました。そこで、その内容を皆様にご紹介させていただいた次第です。今回のシリーズを通じ、少しでも皆様の気づきにつながり、仕事に役立つことがあれば幸いです。一年間、拙い文章にお付き合いいただき、心から感謝申し上げます。ありがとうございました。運用研究レポート運用設計を考える先回のコラム「システム運用設計」というテーマに引き続き、今回からは「運用設計を考える」というテーマで再度、連載をいたします。今回は、皆さんからのご意見やご質問なども受けながら、トヨタ生産方式の考え方も織り込んで、運用設計について考えていきます。システム管理、運用部門の管理者をはじめ、IT予算管理、J-SOX、セキュリティ対策対応など、企業の情報システムにおける様々な経験をもつ。毎年恒例となった「システム管理者の会」の年に一度の大イベントとなる「システム管理者感謝の日イベント」の模様をお届けします。今年のテーマは、「集まれ若いチカラ!システム管理者のための夏期講習!!」です。