2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004年12月の記事
全8件 (8件中 1-8件目)
1
-
■バグを減らす
【システム運用カイゼン】（2004.12.22）**********************************************************************■先ずは日記**********************************************************************師走って、ホント忙しいですね。先週からトラブル（システムではないんですけどね）もあって、日記を更新する余裕を失ってます。**********************************************************************■バグを減らす**********************************************************************アプリケーションでバグが発生した時に、開発側に 「こうあるべきだったんだ！」 「何故こんな間違いが発見出来ないんだ！？」なんていうような、文句を言う人がいます。しかし、文句を言っただけで、バグは減りませんよね。文句を言ってバグが減るんだったら、そんな楽な話しはありません。開発者たちだって、バグを作りこみたくはないはずです。そんために、色んな努力をしているんはず。運用側としては、あるべき論を叫ぶだけでなく、ノウハウあるいは情報を体系化し、開発側へフィードバックしてあげてはどうでしょう。そうすれば同じようなミスを、別の人が犯すことも減り、「何故過去の経験が、組織で生かせないんだ！」なんて、別の文句も言わなくて済むのではないでしょうか。どうすれば、バグを減らすことが出来るのか？それは、開発側だけのテーマではなく、運用側のテーマでもあります。自分達には何が出来るのか！？一方的に文句を言うのではなく、開発側と一緒になって考えたいものです。★システム運用カイゼンのポイント★あるべき論を語っても、バグは減りません。運用として何か貢献出来ることはないのか、開発者達と一緒に考えましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月22日
コメント(1)
-
■仕事の仕組みを作り上げる
【システム運用カイゼン】（2004.12.15）**********************************************************************■先ずは日記**********************************************************************急遽年明けから、別の仕事を担当することになりました。**********************************************************************■仕事の仕組みを作り上げる**********************************************************************先日の続きです。組織として責任をもって、仕事を行う仕組みが出来ていないために、担当者がうっかりしていると、作業が滞留し人に迷惑をかけることになってしまう。こんな状況を改善するためには、組織として責任ある仕事を行う仕組みを作ることが必要だ・・・、という話をしました。しかし、実際やろうとすると、今までやっていなかった仕事が増えることになります。今でも大変なのに、これ以上仕事を増やせないという風に考えられたかもしれません。本当に無理なのでしょうか。ここで実際の、私の経験をお話ししましょう。正直言って、仕組みを作り上げる段階で、一時的な負荷は高まりました。それは事実です。ただ今思い返せば、苦しいと感じていたのは、その仕事のやり方に慣れていなかったために感じていた、ストレスだったのです。さて、何をやったかと言いますと・・・、 (1).まず、全ての作業記録を、システムに残すことから始めました。 (2).仕掛かり作業を出来る限り、監視しました。 (3).また、毎朝残作業を組織内全員で棚卸をしました。今では、それが普通であり、慣れてしまえば無駄がなくなった分、負担は確実に軽減されました。無駄がなくなったと言いましたが、具体的には次のようなことです。（全てが完全、とは言えないまでも、以前に比べての効果です）●作業滞留の解消担当者個人の中で持ってしまっていた作業を、全て可視化したため、進捗度合いが芳しくない作業を、フォロー出来るようになり、後から大騒ぎして火消しに追われることがなくなった。●作業量の平準化担当者個々の持っている作業が分かるため、負担の高い人にそれ以上の負担をかけないように調整することで、人によるボトルネックが解消された。●作業実績の分析による効率化過去の作業を実績を洗出し、特定の担当でしか対応出来なかった作業を手順化し、組織内でその手順をシェアすることで、特定担当者の負担が軽減され、人によるボトルネックが解消された。その他にも効果は沢山ありますが、この辺にしておきましょう。ポイントは、人に依存した作業の標準化に始まり、作業量を平準化するという一般的な効率化の流れです。取り立てて、特筆するような目立った対策は行っていません。「仕事の仕組みを作り上げた」だけなのです。もう一度言います。「仕事の仕組みを作り上げた」だけなのです。如何ですか。理論上は理解出来ると思います。後は実践あるのみです。★システム運用カイゼンのポイント★「仕事の仕組みを作り上げる」ことで、無駄がなくなる。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月15日
コメント(0)
-
■組織として責任ある仕事を行うための仕組み
【システム運用カイゼン】（2004.12.13）**********************************************************************■先ずは日記**********************************************************************昨日、下の子供の七五三の写真が仕上がってきました。写真の出来栄えに自分自身も満足そうで、写真を覗き込みながらニコニコしていました。小さくても、しっかり女の子なんですね。お洒落した自分の姿が、嬉しくてしかたないようでした。**********************************************************************■組織として責任ある仕事を行うための仕組み**********************************************************************皆さんの職場では、日々の作業が滞留することなく、必要に応じて処理あるいは対応されていますか？例えば、次のようなことはないでしょうか。システムトラブルが発生したことを、ある担当者が連絡を受け、当日中の対応を申告元の部署と約束していた。しかし他の緊急作業が発生し、そちらの対応を優先していたところ、トラブル対応を忘れてしまった。翌日になり、申告元の責任者から対応がされてないため、業務に多大な影響が出ているとのクレームが入った。多分その担当者は、トラブルの対応をしなければならないと思っていたはずです。しかし、他の作業が立て込んで、うっかり忘れてしまったのでしょう。実際このようなことを、以前何度か経験したことがあります。私自身が忘れてしまったときもありました。さて、そんな状況はどのように改善していくことが出来るでしょうか。ここでまず着目しなければならないのが、作業自体が組織としての仕事でなく担当者任せになってしまっていることです。組織として責任をもって、仕事を行う仕組みが出来ていないために、担当者がうっかりしていると、作業が滞留し人に迷惑をかけることになってしまうのです。従ってこの状況を改善するためには、組織として仕事を行う仕組みを作ることが必要なのです。それでは、その仕組みとはどんなものでしょう。それは作業という情報を共有する基盤と、その作業と人のマネジメントです。言葉にすると簡単ですね。しかし、実際やろうとすると、今までやっていなかった仕事が増えることになります。「そんなこと無理だよ！」そんな声が聞こえてきそうです。・・・果たして、本当にそうなのでしょうか？この続きは、また明日考えてみたいと思います。★システム運用カイゼンのポイント★組織として責任ある仕事を行うための仕組みを作ろう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月13日
コメント(0)
-
■利用者のメリット
【システム運用カイゼン】（2004.12.10）**********************************************************************■先ずは日記**********************************************************************忘年会だらけで、お財布がピンチ！！かみさん頼む、ヘルプ！**********************************************************************■利用者のメリット**********************************************************************機能に続いて、今日もＩＴＩＬ（IT Infrastructure Library）から話しをしましょう。再びＩＴサービスマネジメントの利点、 ●既存サービスに関するより良い情報 （出来れば、変更が最も利点をもたらすところはどこかという情報）情報システムは、使われてナンボのものです。だからと言って、使えばメリットがあるというほど、安易なものでもないということは、世間的にも認知されてきているのではないでしょうか。やはり使いこなしてこそ、そのメリットを最大限、享受出来るものです。しかし、使いこなすって言われても、システム利用者はどんな風な使い方をすれば良いかなんて、分かるものではありません。システム運用担当者は、システムの利用のされ方を、システムの観点だけでなく、業務の観点でモニタリングし、最大の効果をもたらす利用のされ方を見出し、その情報をフィードバックすることが求められます。ある利用者はとてもメリットを感じているのに、別の利用者の場合メリットを余り感じない。また別の利用者にとっては煩わしい以外の何ものでもない。そんなことでは、システム効果は半減してしまいます。利用者がメリットを十分に享受出来るようにしていくこと（例えば運用指導など）も、システム運用大切な仕事です。結果として、システム導入効果は高めるられることになります。★システム運用カイゼンのポイント★利用者がメリットを享受出来るように情報を提供することで、システム効果は高まります。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月10日
コメント(0)
-
■システムパフォーマスンの把握
【システム運用カイゼン】（2004.12.09）**********************************************************************■先ずは日記**********************************************************************何だかバタバタとしていて、時間だけが過ぎていってるようです。 師走のため？ 単に要領が悪いだけ？**********************************************************************■システムパフォーマスンの把握**********************************************************************今日もＩＴＩＬ（IT Infrastructure Library）から話しをしましょう。ＩＴＩＬでＩＴサービスマネジメントの利点のひとつとして、 ●既存のＩＴ能力のより明確な把握があげられています。日々情報システムを運用しておけば、システムのパフォーマンスがどれ程のものか、感じ取れると思います。しかしそれが、具体的な数値として把握出来ているでしょうか？例えば、トランザクション量に対するＣＰＵ使用率あるいは、メモリ使用率、トラフィック量・・・など等。ビジネス環境が変われば、トランザクション量が変わり、システムに求められるパフォーマンスが変わります。適当な感覚で、「そろそろメモリを増やすか！」だとか「ディスク容量を増やそうか！」、「サーバを新しいのにしよう！」なんてことでは、不必要なシステム投資をしてしまうことになりかねません。担当するシステムの、様々なパフォーマンスを的確に把握し、無駄のない拡張をしたいものです。★システム運用カイゼンのポイント★担当するシステムのパフォーマンスを把握し、適切にシステムを拡張しよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月09日
コメント(2)
-
■ＳＬＡを守っても満足されない
【システム運用カイゼン】（2004.12.08）**********************************************************************■先ずは日記**********************************************************************今日は打合せ三昧で、実作業時間を作れず仕舞い。指示が出来ずに、作業が滞留しているものも発生。明日も朝から、お客様先での打合せ。お昼から、一気にスパートかけていこう。**********************************************************************■ＳＬＡを守っても満足されない**********************************************************************昨日の続き。ＳＬＡの範囲内で対応したにも関わらず、サービスデスク（ヘルプデスク）の対応が遅いとクレームが入った時に、どのような対策を考えますか？対応レスポンス時間：平均３０分以内 を、平均２５分以内に見直します？確かにそれも一つの案ですね。しかし、平均の対応時間が５分短くなったところで、利用者やお客様の体感的待ち時間が大きく改善され、クレームは発生しなくなるのでしょうか。人の感覚は非常に曖昧です。状況によっても大きく差が出ます。ある人は３０分待たされても、「仕方ないですね」と納得してくれるかもしれませんが、別の人だと５分でも「何分待たせてるんだ！」と怒鳴ってくるかもしれません。人は何の情報もなく、ただ待たされるという状況に、非常にストレスを感じてしまいます。従ってこのような場合、相手に状況をしっかり伝えることです。状況とは、例えば次のようなことです。 「確認に時間がかかりそうなため、３０分お待ちください」 「５分待っていただければ回答が出来ます」 「障害のため申し訳ありませんが、復旧する明日までお待ち下さい」このように状況を伝えることで、相手は自分自身の行動を選択することが出来るようになります。それだけでストレスは大きく解消され、対応時間がクレームとなるケースは、随分減ることになるでしょう。如何でしょうか。ＳＬＡという定規は、あくまでもひとつの指標値です。それを守ったからといって、利用者やお客様が満足しているとは限りませんよね。自分が逆の立場だったら、分かる思います。「ルールは守った。だから文句を言うあなたがおかしい。」そんな感覚では、いつまでもサービスと呼べるものにはなりません。ＳＬＡはひとつの指標だということを忘れず、利用者やお客様の立場に立った対応を目指しましょう。★システム運用カイゼンのポイント★ＳＬＡはひとつの指標でしかない。守ったからといって、利用者やお客様は満足しているとは限らない。利用者やお客様の立場に立った対応を目指しましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月08日
コメント(1)
-
■ＳＬＡと満足度
【システム運用カイゼン】（2004.12.06）**********************************************************************■先ずは日記**********************************************************************昨日の朝方の風は本当に凄かった。ニュースでも報道されてましたので、ご存知の方もいらっしゃると思いますが、近所のマンション解体現場の足場が崩れて、電柱をなぎ倒していました。いや～ぁ、驚きました。**********************************************************************■ＳＬＡと満足度**********************************************************************今日はＳＬＡに関する話題を取り上げたいと思います。ＳＬＡ（Service Level Agreement）はご存知の通り、サービス品質レベルを保証する制度のことです。最近システム運用に関するサービスレベルを、規定していく動きが盛んになっているように思います。さてそのＳＬＡですが、主観的に内容を規定しても、システムサービスを受ける利用部門やお客様側からしたら、実際のサービス内容が規定された範囲内であったとしても、満足出来ない場合があります。例をあげながら説明したいと思います。サービスデスク（ヘルプデスク）における、インシデントに対する仕様判断の対応レスポンス時間を、平均３０分以内に設定していたとします。このように、平均対応時間を設定していることは問題ないと思います。（何を基準に３０分なのかという議論は別にして・・・）利用部門がお客様を目の前にして、システムが思うように使えないために、運用部門へＱＡを投げてきたとします。当然お客様を目の前にしているのですから、緊急での対応を要求するはずです。しかしそのＱＡ内容が、即答出来そうにないもので、調査・確認が必要となったのですが、何とか２５分程度で回答しました。ＳＬＡ上は問題ありません。しかし、利用者もお客様もひたすら２５分間待たされました。あなたが、利用者あるいはお客様だったとしたら、どのように感じるでしょうか？ボーっと２５分間待たされました。その対応に満足が出来るとは思えませんね。こんなことから、対応が遅いとのクレームが入ったりする訳です。さて、こんなクレームを耳にした時に、あなたならどのような対策を考えるのでしょうか？その続きは、また明日にしたいと思います。★システム運用カイゼンのポイント★ＳＬＡの規定範囲だからといって、満足が得られるとは限らない。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月06日
コメント(0)
-
■セキュリティ・インシデント
【システム運用カイゼン】（2004.12.01）**********************************************************************■先ずは日記**********************************************************************今日は会議続きでした。会議を梯子していると、自分の宿題を見直すタイミングを失いってしまいそうで好きじゃありません。**********************************************************************■セキュリティ・インシデント**********************************************************************今日はセキュリティ・インシデントについて話をしたいと思います。実は私がお世話になっている作業現場で、セキュリティ・インシデントが発生しました。インシデントの内容は、入館・入室用セキュリティカードの紛失です。紛失の経緯を説明しておきましょう。紛失してしまったその人は、仕事を終え食事（飲酒含む）を取り、電車で帰宅していました。セキュリティカードは落とさないよう、しっかり仕事鞄の中に仕舞ってましたが、その鞄は網棚にのせていました。電車の中で眠り込み、丁度自分の降りる駅で目がさめ、慌てて下車したところ、鞄を置き忘れてしまったのです。直ぐに気付いたその人は、駅に届け出て乗車していた電車の中を調べてもらいましたが、鞄は出てこなかったそうです。その後深夜になっていましたが、上司に連絡を入れ、その直後に上司より管理責任者やその他関係者へも連絡が回されました。翌朝直ちに紛失したセキュリティカードの無効化の手続きが行われ、紛失後の入館実績がないことの確認も行われました。幸い不正入館の実績もなく、カードは無効化されましたので、リスクは回避されました。さて、この教訓から何を学ぶことが出来るでしょうか。例えば・・・、無くして困るようなものを、自分の体から離さないということです。誰だってお酒の入った時や、睡眠不足の時に、電車に揺られたら眠ってしまうことはあると思います。眠り込んでしまわずとも、目を離した隙にってこともありえます。札束の入った鞄を、無造作に網棚に置く人はいないですよね。セキュリティ侵害による損失のことを思えば、札束にも相当するはずですが、（多分そんなことまで考える人は少ないと思いますが・・・）如何でしょうか！？もうひとつあげてみましょう・・・、それはこの最悪の事態の中で、光にあたる部分です。それは紛失した後、直ぐに上司へ連絡をしていることです。上司の人も直ぐに必要な関係者へ連絡を行っています。これは、セキュリティ・インシデント発生時のお手本のようですね。認識の甘い人だったら、翌日になってから上司に報告することでしょう。もしかしたら、数日は黙っていたかもしれません。日頃からの教育の賜物ですね。何かあった時には、常にそうありたいものです。さぁ、如何でしょうか。この他にも学ぶことは沢山あると思います。事故を起こさないようにするには、どうすれば良いのか。もしそれでも起こってしまった時には、どうすれば良いのか。皆さんの組織では、こんな場合のことを想定されていますか？自分達の組織における姿を考えてみましょう。★システム運用カイゼンのポイント★セキュリティ・インシデントに対する、予防策や発生時の対応策を、具体的に考えてみましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年12月01日
コメント(0)
全8件 (8件中 1-8件目)
1
