全107件 (107件中 1-50件目)
-
■バグを減らす
【システム運用カイゼン】（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)
-
■スキルアップ
【システム運用カイゼン】（2004.11.30）**********************************************************************■先ずは日記**********************************************************************明日から師走だぁ！！今日はまだ師走じゃないのに、予想外の飛び込み作業のために忙しい・・・。**********************************************************************■スキルアップ**********************************************************************システムの運用に携わっていると、担当するシステム自体が頻繁に変更されることはないためでしょうか、技術スキルの向上に努めない人を目にします。何も新しい技術を追い求めるだとか、新しい言語を覚えたりするだけが、技術力向上ではありませんよね。携わっているシステムを構成するものは、多岐に渡っていると思います。ネットワーク、ストレージ、サーバ、ＯＳ、データベース、フレームワーク、アプリケーション、・・・数を上げれば限りがありませんね。それぞれに関する知識を養おうと思うと、果てしない努力をしても終わりを迎えることはないはずです。では、何故スキルが必要になるのでしょうか？ひとつの例をあげてみましょう。システム運用担当者は、システムが常に最善であることを、日々の運用を通して模索し続けるミッションを持っています。その時にシステムに関するスキルがないと、何が最善なのか見出すことが出来ません。安易な思い込みで、良かったものを悪い方向へ導くことさえあります。今動いているものを、お守りするだけが運用の仕事ではありません。スキルを高め、システムのより最善な姿を模索し続けましょう。★システム運用カイゼンのポイント★システム運用を担当していても、技術スキルの向上が必要です。スキルを高め、システムのより最善な姿を模索し続けましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月30日
コメント(0)
-
■「手順書（プロシージャ）」
【システム運用カイゼン】（2004.11.29）**********************************************************************■先ずは日記**********************************************************************先週は新サービスの開始やらなんやらで、バタバタしてしまい更新が少なくなってしまいました。バタバタと言っても、時間の余裕がなくなっていた訳ではなく、気持ちの余裕を失っていただけだと思います。何にせよ毎日継続出来る人は、ホント凄いですよね。尊敬してしまいます。**********************************************************************■「手順書（プロシージャ）」**********************************************************************またまた日経ＢＰ社さんのサイトの記事を取り上げます。その記事は次の通り。今週のSecurity Check [2004/11/29]セキュリティ・ポリシーのポイント「手順書（プロシージャ）」を解説するhttp://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20041126/153136/記事の表題の通り、情報セキュリティ・ポリシーに関する内容で、現場作業でセキュリティに関わる、具体的行動を示す「手順書（プロシージャ）」について解説されています。事例をあげながら説明してありますので、とても理解しやすいと思います。興味のある方は、是非ご一読いただいきたいと思います。私自身の現場経験からみても、「手順書（プロシージャ）」の重要性は強く感じます。記事の中にも書いてありますが、情報セキュリティ・ポリシーは （1）「基本方針（ポリシー）」 （2）「管理策（スタンダード）」 （3）「手順書（プロシージャ）」と呼ばれる３階層（簡易化され２階層の場合もありますね）で策定されます。これがもし「基本方針（ポリシー）」だけだったりすると、人によって解釈の違いが起こり、ルールがあってないような事態を招きかねません。通常の仕事や作業が、誰がやっても安全になるようにすることが重要です。車の運転を例にあげれば、分かりやすいと思います。「車の運転には十分に安全を確保しなければならない。」と言われて、ある人は自分のドライビングテクニックだと、このようなカーブなら通常時速１００Ｋｍでも大丈夫と思うかもしれません。しかし違う人からすれば、時速５０Ｋｍじゃないと大丈夫と思えないかもしれません。ここの解釈には、スピードにして倍の開きがあります。この解釈の違いを、なくすために必要なのが、道路ごとに設置された標識です。最高速度５０Ｋｍや、一時停止や、具体的な行動を示していますよね。セキュリティ・ポリシーにおける、道路標識にあたるのが「手順書（プロシージャ）」であると考えてもらうと分かりやすいと思います。そういう意味でも「手順書（プロシージャ）」はとても重要なものです。ただ、だからと言って硬い文章で書く必要はありません。誰が読んでも理解出来て、かつ行動出来るものであることが重要です。（道路標識だって絵になってますからね。）形に拘るより、具体的行動がしっかり理解出来る内容でありたいものです。場合によっては、図や絵も必要でしょう。分かりにくい、長々とした文章を読ませるより、図や絵にすることで理解が深まるのであれば、そうするべきですよね。更に言えば、全ての「手順書（プロシージャ）」が完成することを、待つ必要もありません。重要なことから始めていけば良い事です。しかもその内容が不十分であっても構いません。必要に応じて、見直していけば良いのです。何もしないまま、指を咥えていることの方が問題です。「手順書（プロシージャ）」の重要性を認識し、形よりも実のある内容の「手順書（プロシージャ）」で運用しましょう。★システム運用カイゼンのポイント★セキュリティ・ポリシーにおいて「手順書（プロシージャ）」は重要です。具体的行動を、分かりやすく示しましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月29日
コメント(0)
-
■新サービスの開始日でした。
【システム運用カイゼン】（2004.11.25）**********************************************************************■先ずは日記**********************************************************************昨日の夜、部下と面談（実際は飲み）に行ってきました。新卒で会社に入った後、そのままお客様先へたった一人で派遣に出て、４年が経とうとしているメンバだ。非常に、人当たりが柔らかい、おとなしい性格の人物です。悪く言えば控えめで、言いたいことも我慢してしまうような感じでした。しかし、久しぶりにゆっくり話しをしたところ、派遣先の現場では、ハッキリした言葉で意思を伝えているとのことで、良い意味で期待を裏切られ、とても嬉しく思いました。**********************************************************************■新サービスの開始日でした。**********************************************************************今日はお客様先システムの、新サービスの開始日でした。今回は予想以上にトラブルが多かったように思います。複数のチーム体制でのぞみましたが、私がいたチームでは作業のコントロールを担当した人に負担が集中し、ボトルネックになってしまうことが幾度となく発生しました。そのような状況を招いてしまった原因は・・・、そもそもトラブル発生件数が多く、担当者の処理能力を超えてしまっていたことは否めません。ある意味仕方ないと思いたいところですが、それを理由にしてしまったら、今後の改善策がなくなってしまいます。仕方ないではなく、今回の体制や仕組みでは、発生したトラブル件数を処理するだけの、作業能力が無かったのです。そこで、体制や仕組みとい観点で、問題点を洗い出してみました。作業のコントロールを担当した人には、フォローする担当が付いていました。フォロー担当には、更にそのフォロー担当を設定していました。（実は私がこれをやったのですが・・・）つまり担当チームの体制は、次のようになっていました。 ●作業コントロール担当者 ｜｜ ｜＋－●フォロー担当者 ｜ ｜ ｜ ＋－●フォローのフォロー担当者（私） ｜ ●実作業担当者作業が集中するであろう作業コントロール担当に、二重のフォローを設定していたにも関わらず、作業のボトルネックを発生させてしまいました。ここで最大の問題だったのは、フォロー担当者（フォローのフォロー担当者）が、どんな振る舞いによって、作業コントロール担当者を支援するのか具体的に整理出来ていなかったのです。一緒になって、バタバタしていただけで、作業の流れをスムーズにするには、至りませんでした。それぞれの分担を整理しておくべきでした。明日も同じ体制で、運用を行って行く予定です。同じ轍を踏まないようにしたいと思います。★システム運用カイゼンのポイント★チーム内の担当者個々の振舞いを、具体的に定義しておこう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月25日
コメント(0)
-
■システム運用担当から、開発担当へもの申す！（その２）
【システム運用カイゼン】（2004.11.22）**********************************************************************■先ずは日記**********************************************************************本日は朝から快晴です。週明けからこんな天気で、気持ち良いですね。今日の夜は、社内マネージャ会議の予定。ポジティブで行きましょう！**********************************************************************■システム運用担当から、開発担当へもの申す！（その２）**********************************************************************先日も書きましたが、「開発部門へもの申す」で今日もいきたいと思います。今日のテーマは、「トラブル発生時の、トランザクションの復旧方法は確立出来てる？」アプリケーションが分散化することに伴って、トランザクションは複雑化していると先日も話しました。それに伴い、トラブルによってトランザクションが中断した場合の、復旧方法も複雑化していると言えます。トラブルは必ず発生するものです。そしてトラブルが発生すれば、必ず復旧を行わないといけませんよね。そのことを考慮しないで、アプリケーションを実装してしまうと、トランザクションが中断しても、復旧出来ないことになってしまいます。それが担当のシステム内で発生した場合であれば、まだ何とか対処のしようもあると思いますが、対外システムとの連携で発生した場合、取り返しが付かないですよね。開発担当の皆さん方、復旧出来ないシステム設計にならないように、注意して下さい。運用担当の皆さん方、もし新しいトランザクション方式で開発されようとしている場合、トラブル時の復旧のことを十分に考慮にいれレビューを行い、復旧が出来ない方式での、運用を開始させないようにしましょう。★システム運用カイゼンのポイント★システム運用担当から、開発担当へもの申す！「トラブル発生時の、トランザクションの復旧手順は確立出来てる？」━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月22日
コメント(0)
-
■変更管理ミス
【システム運用カイゼン】（2004.11.19）**********************************************************************■先ずは日記**********************************************************************先程一緒に仕事をしてきていた人が、プロジェクト撤退の挨拶に来てくれました。一ヶ月ほど休職し、心と体を休めるとのことでした。以前から軽鬱で病院に通っていたのは聞いてましたが、つらかったんですね。あッ！、仕舞った。「頑張って！」って言ってしまった。欝病の人にその言葉は禁句でした。そう言えば、最初笑顔があったのに、途中からなくなったもんなぁ。悪いことしてしまった。ホント、申し訳ない。（ここで言っても本人には、伝わりませんが・・・）ゆっくり休んで、心も体もリフレッシュして欲しいと、心から願うばかりです。**********************************************************************■変更管理ミス**********************************************************************私がＩＴ系の情報を入手する際、良く利用させてもらってます「＠ＩＴ］に、今日掲載された記事で、「変更管理、その正体と対策」というものを目にしました。記事掲載のアドレスは、次の通り。http://www.atmarkit.co.jp/farc/rensai/config03/config03.html変更管理に関する手法については、記事を参照してもらうとして、ここでは私が経験した変更管理ミスに伴う、トラブルの事例を紹介することで、変更管理の重要性を認識していただきたいと思います。ある運用中のアプリケーションプログラムに、バグが発見されました。そのプログラムソースは、数ヵ月後にリリースされる新サービスに伴い、変更が発生していたため、 ●正本ソース ⇒払出し⇒ ●新サービス用ソースという具合に、２元管理された状態になっていました。本来であれば、現行システムで稼動中のコードは、当然「●正本ソース」になっているので、当然「●正本ソース」に対し修正を行う必要がありました。（正確に言えば、「●正本ソース」を「●障害修正用ソース」に払出し、そこ へ修正を行うです。）しかし誤って「●新サービス用ソース」に対し修正を行い、本番環境へリリースを行いました。----------------------------------------------------------------------【現行システムバグに対するプログラム修正】 ●正本ソース ： ○ ●新サービス用ソース ： ×（新サービス用のロジックを組込み済みの為）----------------------------------------------------------------------当然ですが、まだ動作してはいけないロジックが組み込まれた状態で、本番環境にリリースしたため、異常な動作をすることとなった訳です。試験で発見されるべきものかもしれませんが、試験パターンの不足から発見されないまま、リリースに至りました。正直言って、とても単純なミスです。こんな単純なパターンは珍しいと思いますが、複数のプロジェクト（案件）に伴い、多次元管理状態になったソースでバグが発見された場合、バグに対する修正結果を、多次元管理された全てのソースに反映させる必要があります。全ての反映行為を、漏れなく確実に実施するには、やはりそれなりの仕組みが必要です。これは、開発時にも言えることだと思いますが、運用としては本番稼動における障害は一つでも発生させたくないはずです。変更管理にはしっかり気を配り、ミスを発生させない仕組みをつくりましょう。★システム運用カイゼンのポイント★変更管理ミスによる障害を、発生させない仕組みをつくりましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月19日
コメント(0)
-
■システム運用担当から、開発担当へもの申す！
【システム運用カイゼン】（2004.11.18）**********************************************************************■先ずは日記**********************************************************************免許更新やら、遅くなったのですが子供の七五三の写真を撮りに行ったりして昨日はお休みしてました。様々なイベントのタイミングで、改めて子供の成長を実感します。これからも健やかに成長して欲しいと願う、父なのでした。**********************************************************************■「運用担当から、開発担当へもの申す！」**********************************************************************今日は運用部門向けの話しとは、少し趣を変えて、 「運用担当から、開発担当へもの申す！」と題して、書きたいと思います。何故思ったかと言いますと、開発されたシステム自体の品質レベルが低ければ、運用の苦労は増えるばかりですよね。そこで、開発者側へ伝えるべきことがあると考えたのです。さて、何についてもの申すかと言いますと、トランザクションについてです。私が担当させていただいているシステムは、業務アプリケーションのメンテナンス頻度が非常に高く、それに伴いバグの発生頻度も高い状況です。当然開発側の人たちは、品質向上に最善の努力をしており、その苦労が並大抵でないことは痛いほど分かります。さて、そんな中でバグ（障害）発生の原因が、トランザクション設計ミスによるものを目にすることがあります。トランザクションは、情報システムの基本的な機能ですよね。そのトランザクション設計にミスがあっては、泣くに泣けません。情報システムは、常に成長し、システム同士は複雑に絡み合い、相互に連携するようになってきており、トランザクションの仕様自体が、難しくなっていることは否めません。しかし、トランザクション設計ミスの原因を更に追求すると、トランザクションパターンの考慮漏れという場合が多いのです。そう、以外と単純なものなのです。アプリケーション開発者との会話で良く耳にするのが、 「そのパターンの考慮を忘れていました。」時間との勝負を続けながら、頑張っていることは知っていても、何かしっくりこない理由です。気持ちは判るんですが、開発品質向上に努めている結果としてそれ？って感じなのです。（開発者の言い分も沢山あるでしょうが・・・）トランザクションパターンって、使いまわし出来るものだと思っています。私自身が開発をした時も、一度作ったものを育て（改版）ながら、活用してました。それを、開発者同士でシェアしたりもしてましたし。バグを殆ど発生させない開発担当者は、やはり過去の資産を十分活用しています。それが自分が作ったものであれ、他の人が作ったものであれ関係ありません。その違いは大きいですよね。システムの分散化による、トランザクションの複雑化は、今後更に広がっていくことと思います。そんな状況で開発担当者の方達は、担当するシステムのフレームワークにおけるトランザクション仕様をしっかり理解することは当然ですが、連携するシステムとのトランザクションの一貫性をも、十分に理解しなければいけません。より難しいものに、神経を集中することが求められるようになると思います。だからこそ、単純なものに神経を取られるようなことは避けたいですよね。開発担当の皆様方、「トランザクションパターンの使いまわし」ちょっと考えてみて下さい。★システム運用カイゼンのポイント★運用の苦労を減らすためには、開発されたシステム自体の品質レベルが上がらないと、どうしようもありません「開発担当へもの申す！」あなたの現場でもやってみて下さい。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月18日
コメント(0)
-
■組織としての責任ある仕事
【システム運用カイゼン】（2004.11.16）**********************************************************************■先ずは日記**********************************************************************昨日は毎月参加させていただいてます、クイズプロデューサー）弘中 勝さん主催の「五反田ＱＱ」に行ってきました。先日は、メルマガコンサルタント）平野友朗さんをゲストスピーカーに迎えての講義と、ブレイントレーニングでした。今回も素晴らしいインスピレーションをいただいてきました。懇親会も、相変わらず楽しかった！顔見知りの方も増え、楽しさ倍増って感じです。これからも、続けて参加させていただきたいと思います。**********************************************************************■組織としての責任ある仕事**********************************************************************昨日の日記でも書きましたが、先週の土曜日に予定していた担当者が、バイクに乗っていて交通事故に合い、予定していた作業の実施について、大騒ぎすることになってしまいました。そもそも作業自体に担当者の責任も伴いますが、それ以上に組織としての仕事なのですから、組織としての責任です。昨日の日記ではリスク回避という観点で書きましたが、もっと大切な観点としては、組織としての責任ある仕事だということです。リスク回避策というのは、組織の仕事としての責任の一環でしかないですよね。今回のことで最大の問題だったのは、組織として、 ●準備の進捗を把握出来ていなかった。 ●作業の内容を把握出来ていなかった。 ●作業の手順を把握出来ていなかった。つまり、マネジメントされていない状態で、仕事が進められていたということです。そんな状態になっている仕事って、世の中に結構多いですよね。「担当のｘｘが休んでおりまして・・・」なんて言葉を、よく耳にします。もし自分がお客様の立場で、そんなこと言われたら、どう思いますか？絶対に納得いかないと思います。自分がされたら腹が立つようなことを、自分自身の仕事に対してやってしまってるなんて、ちょっと恥ずかしい話しですよね。作業一つひとつに、マネジメントの目を入れていくのは、正直言ってそれなりの努力と根性が必要になると思います。しかし、やってるところは、ちゃんとやってるんです。そんなことは、到底無理なことだと諦める前に、出来るようにするにはどうしたら良いのかを考えてみることが必要です。諦めた時点で、何も進みませんから。一度に全部が無理であれば、重要なものから順に進めていけば良いんです。今時点は出来ていないからと言って、将来に渡って出来ないままということではないはずです。慌てなきゃ良いことです。作業一つひとつを、組織として責任ある仕事にする。つまりそれはマネジメントが、ちゃんと機能した仕事にするということです。★システム運用カイゼンのポイント★作業一つひとつを、組織として責任ある仕事にするため、重要なものから順にマネジメトの目が届くようにしていきましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月16日
コメント(6)
-
■個人任せに伴うリスク
【システム運用カイゼン】（2004.11.15）**********************************************************************■先ずは日記**********************************************************************昨日、下の子供の七五三のお宮参りに行ってきました。お姉ちゃんが七五三の時に着たおさがりの服を着せたんですが、後姿だけだとそっくりなんですよ。姉妹ってすごいですね。親ながらビックリです。綺麗な服を着て、とても嬉しそうにしてました。**********************************************************************■個人任せに伴うリスク**********************************************************************先週の土曜日に休日出勤していたのですが、その日に作業を予定していた担当が、バイクに乗っていて交通事故に合ってしまい、大騒ぎになりました。幸い命に別状はなく、胸骨骨折（あばら骨を折ったってことですね）程度で済み、大事に至らず安堵したのですが、問題は予定していた作業の方でした。当日２０時から開始予定の作業だったのですが、準備が終わっておらず、かつ本人しかその内容が分からないという状態。同じグループの他の担当の人に、急遽出勤してもらい、対応が取れないものかと確認をしてもらったですが、結局情報の不備などがあり、延期せざるを得ないとの判断になりました。全ての作業に対し、このような場合を想定して、担当者を最低二人設定しておく、なんてことは実際難しいことだと思います。しかし、リクスに応じて対策を講じておくことは出来ると思います。今回ようなケース、休日の夜間作業等の場合に限っては、もしもの場合を想定し、緊急時の交代要員を決めておくとかいうことが考えられますね。個人任せになってしまっている作業を、組織の仕事にしていくためには、そういう観点で、リスク回避策を講じてが大切です。★システム運用カイゼンのポイント★個人任せの作業にはリスクが伴います。組織としての仕事にするため、作業の内容によって、リスク回避策を講じましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月15日
コメント(0)
-
■システム運用の仕事を、お金に換算してみよう
【システム運用カイゼン】（2004.11.12）**********************************************************************■先ずは日記**********************************************************************朝から雨が続いています。日曜日に下の子供の七五三のお宮参りに、行こうと思っているのですが、また雨のようです。明日は晴れのようですが、お仕事の予定。ちょっと残念。**********************************************************************■システム運用の仕事を、お金に換算してみよう**********************************************************************システム運用の仕事って、事業部門側から見た場合、何をやっているのか分かりにくいものだと思います。 「毎日忙しそうにしてるけど、別に売上を上げるわけでもないのに、 一体何がそんなに大変なの、 所詮、機械のお守りしてるだけじゃないの？」大抵の場合、こんな風に思われているんじゃないでしょうか。頑張っているのに、悲しい話しですよね。でもそのままにしていて、良いのでしょうか！？ほっといたら、人は減らされ、予算は削られ、大変な状況は更に悪化することになりますよね。そうならないようにするには、必要な仕事をであることを、自ら証明していかなければなりません。でも、どのようにして理解を得れば良いのでしょうか？何も考えずに見てしまえば、単なるコストセンターにしか見えません。しかし、そんなことはないはずですよね。販売・営業や、製造、顧客サービス等の事業部門は、予算を得て利益を上げていくのに対して、システム運用を含むＩＴ部門は、予算を得てＩＴサービスを提供しています。そのサービスを継続して提供することの価値を、誰の目にもみて理解出来る、つまりお金に換算して見せていくことです。ひとつのヒントとしては、もしそのシステムサービスが存在していなかったとしたら、どれ位のコストに跳ね返るのか？だからそのシステムサービスの価格は幾らになるとの見方です。簡単にコスト換算することは難しいと思いますが、仕事である以上、何らかのかたちでお金に換算しないと仕方ないですよね。システム運用の仕事を、お金に換算してみましょう。★システム運用カイゼンのポイント★システム運用の仕事の価値を、お金に換算してみましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月12日
コメント(0)
-
■仲良しが群れているだけでは、組織は活性化しない。
【システム運用カイゼン】（2004.11.11）**********************************************************************■先ずは日記**********************************************************************昨日、今日と殆ど打合せもなく、黙々と自分のことに取り組んでいます。大半の時間は、机の前に紙を広げ、自分は椅子にもたれながらリラックスモードで、ボーっと考えてはメモしたり、お絵描きしたり・・・。きっと人からは、仕事しないでサボってるように見えたことでしょう。実際、眠かった時間も多かったのですが。人からどう見えていようが、私の場合、思い付きを形にしていくためには、そんな思考の時間が必要なのです。作業に追われていた時期には、閃きがホント少なかったし、それ自体の内容がプアな場合が多かったんですよね。そう考えると、こんな幸せな時間を取れる状況に感謝です。**********************************************************************■仲良しが群れているだけでは、組織は活性化しない。**********************************************************************組織のメンバー同士が仲が良いことは、とても素晴らしいことですよね。時には小さな組織の中に、派閥みたいなものを作って、とても冷めた人間関係に陥っているようなところもあるようですが・・・。しかし、仲が良いだけで、お互いを高め合うことの出来ない、横並び主義に陥った組織も見かけます。正に、仲良しが群れている状態。そんな状態になった組織だと、新しいことに取り組もうとしても、自ら手を挙げ協力するような人は誰もいません。しかも担当に選ばれた人を、周りの人が哀れむといったことさえ起こります。そんな風になったら、由々しき事態です。元々やる気のなかった人に対し、周りの人間がマイナスの意識を助長しているのです。何と恐ろしいことでしょう。スタートから挫折しているようなものです。実はこれ、私のいる現場で、私自身が経験したことなのです。やる気がないにも程がある。互いの足を引っ張り合うようなマネだけは、して欲しくないですね。仲良しが群れているだけでは、組織は活性化しません。互いを高め合える関係を築きたいですね。★システム運用カイゼンのポイント★組織が、仲良しが群れた状態は危険信号です。何か手を打たなければ、組織は成長出来ません。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月11日
コメント(0)
-
■システムオーナー／利用者の、声を聞くための"仕組み"や"場"
【システム運用カイゼン】（2004.11.10）**********************************************************************■先ずは日記**********************************************************************昨日上の子供が、学校の漢字テストで、クラス最高得点だったらしいのです。確かに頑張ってましたよ。テスト前日に妻作ってもらった問題をやって、当日の朝は頑張って早起きをして（とは言っても起こしてあげましたけど・・・）、前日やった問題の間違いを、一所懸命に復習していました。先生がテストの結果を返されるとき、「今回のテストの最高得点は・・・・」思いがけず自分の名前を呼ばれ、とても嬉しかったそうです。本当に良かったね。その話しを聞いて、お父さんも凄く嬉しかったよ。**********************************************************************■システムオーナー／利用者の、声を聞くための"仕組み"や"場"**********************************************************************昨日は「事業サポートの信頼性向上」という話題の中で、時には経営層、マネジメント層の声を聞きましょうという話しをしました。これは、システムオーナー側の要望・要求をヒアリングすることですね。当然ですがシステムは、利用者（時にそれがお客様である訳ですが）がいて始めて意味をなします。（感の良い方は、もうお判りですね。）従って、利用者の声を聞くことも忘れてはいけません。システム利用者の要望・要求をヒアリングしながら、システムの問題を洗出しましょう。オーナーにせよ、利用者にせよ、その声を聞くための仕組みだったり、コミュニケーションの場（リアルもバーチャンルも含む）を持つことは、とても大切なことです。そういうものがないと、●不便なものがいつまでもそのままに放置され、気付かないまま無駄を垂流し てしまうかもしれない。●使いにくいからと言う理由で、知らないうちにお客様が離れていってるかも しれない。●致命的な問題の発見が遅れ、気付かないうちに傷口を広げてしまっているか もしれない。・・・・・など等、大きな損失に繋がることがあります。また、次のような意味もあります。運用部門の業績評価は、システムサービスのレベルによって評価される必要があります。そのため、オーナーあるいは利用者の、システムサービスに対する満足度を吸い上げるための仕組みは、必須と考えなければなりません。それが自分たち自身のためにつながります。あなたの担当するシステムには、システムオーナー／利用者の、声を聞くための仕組み、あるいはコミュニケーションの場はありますか？★システム運用カイゼンのポイント★オーナーのため、利用者のため、そして自分たち自身のために、システムオーナー／利用者の、声を聞くための仕組み、あるいはコミュニケーションの場を持つようにしましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月10日
コメント(2)
-
■事業サポートの信頼性向上
【システム運用カイゼン】（2004.11.09）**********************************************************************■先ずは日記**********************************************************************昨日は、ある大手ソフトベンダーの部長様を訪問しました。ビジネスで何かお役に立つようなことがないのか、お話しをさせてもらうための訪問でしたが、今回は活路を見出すには至りませんでした。その時のちょっと恥ずかしいことですが、大切な気付きの話しを書きます。話しの流れから、私がつい口にした 「タイミングがあれば、チャンスをいただいて・・・・・」という言葉に対し、その部長様は 「そのチャンスは、うちにはリスクなんだよねぇ。ハハハッ。」との軽いジャブ。つまり、 ●【（自分）チャンス】＝【（相手）リスク】という式になっていたのです。どうして ●【（自分）チャンス】＝【（相手）チャンス】となっていなかったのでしょうか？私は気付かないまま、自分の立ち位置を「仕事を下さい！」というところに、移してしまっていました。始めのうちは、上手くタイミングがあって、両者の意向が合えば・・・と思っていたのですが、いつのまにか仕事が欲しいとの欲が前に出てしまい、相手の信用を落とす結果に繋がっていたんです。その部長様から見たら「自分ところのおこぼれを貰いに来た人」ですね。それじゃ、信用して契約なんかする気は起きません。逆の立場になれば、自分だってそうですから。【（自分）チャンス】＝【（相手）チャンス】になる会話を心がけましょう。**********************************************************************■事業サポートの信頼性向上**********************************************************************日頃から、企業情報システムを運用することは、企業活動つまり事業の基盤を運用することだと、この日記に書き続けています。そして、その運用のサイクルをマネジメントすることが、ＩＴサービスマネジメント（の一部分）にあたります。何度も登場しているＩＴＩＬですが、ＩＴＩＬはＩＴサービスマネジメントにおけるベストプラクティスをまとめたものです。そのＩＴＩＬでＩＴサービスマネジメントの利点のひとつとして、 ●サービス品質の向上。すなわち、事業サポートの信頼性の向上があげられています。つまりＩＴサービスマネジメントは、システムだけの観点だけでなく、事業の観点で、マネジメントすることが求められます。そんなことを言うと、「難しすぎて、運用としてシステム面倒を見切れないなぁ！」という気持ちになってしまうかもしれません。でも慌てることはありません。当然、自分のスキル（ＩＴもビジネスも）を高めることも必要ですが、まずはまわりにいるスキルの高い方に協力を求めてみて下さい。特に事業（ビジネス）に関する分野については、必要であれば経営層、マネジメント層の声をしっかり聞くようにして下さい。（開発時だけが、ＩＴに関するヒアリングのタイミングではありません。）事業サポートとして、システム運用部門に何を求めるのか？その要求に対し、サポートサービスとして、どのように応えていくのか？具体的なアクションを、見出すことが出来るはずです。また、時には両者の専門家の意見を取り入ることも必要でしょう。（その時には、なんちゃってコンサルタントや、なんちゃってＩＴコーディネーターには注意して下さいね）社内で調達出来ない場合、時間をお金で買うことは重要ですから。このようにしながら、事業サポートの信頼性の向上を図りましょう。★システム運用カイゼンのポイント★システム運用は事業サポートをしています。マネジメントによって、事業サポートの信頼性向上を図りましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月09日
コメント(0)
-
■インフラが多様化している
【システム運用カイゼン】（2004.11.08）**********************************************************************■先ずは日記**********************************************************************昨日（日曜日）ですが、初めてフリーマーケットを経験しました。もちろん出店の方ですよ。以前より妻が申し込んでいたのですが、申込数が多くキャンセル待ちになっていました。それが一週間前に、空きが出てとの連絡が入り、急遽慌てて準備をしました。実際は殆ど妻が考え、私は言われるまま手伝っただけに過ぎませんが・・・。実は私、フリマは遠目に眺めたことがある程度で、買い物さえしたことありませんでした。だから、全てが初めての経験。妻も同じでした。でも変な気負いもないので、結構楽しくお客さんと話しをしたりして、小さな商売を満喫することが出来ました。始めの頃は恥ずかしがっていた子供たちですが、終わり頃は大きな声で呼び込みをしてくれたりして、家族皆で一日中、楽しく過ごすことが出来ました。成果は、売上２４千円程度。良かったのか、悪かったのかさえ分かりませんが、変なレジャーよりも、ずっと面白かったですね。子供たちも、色んな人に褒められて、とても良い経験になったみたいです。**********************************************************************■インフラが多様化している**********************************************************************システム運用の大切な仕事として、インフラの維持がありますが、インフラっていったい何でしょう？「サーバ」と「ネットワーク」に集約されていたのは、一昔前のこと。では、今はどうなっているのでしょうか？誤解を恐れずに言わせていただくなら、 ・ストレージシステム ・各種セキュリティツール ・各種ミドルウェア群 ・データベース（ＤＢＭＳ） ・ＥＡＩツール ・フレームワークそのもの ・・・・・解釈を広げるなら、 ・アプリケーション何故このように考えるかと言えば、ＩＴそのものがビジネス基盤と呼ばざるを得ない状況になっているからです。運用側の立場で言えば、インフラが多様化していることになります。情報システムの物理的機能配置は、更に分散化傾向に向かうことでしょう。そしてそれは、統合化という名の基に、相互に複雑に絡み合っていくことになります。それに伴い、システム毎の運用も密に連携する必要があるでしょうし、必要に応じて統合化する必要も出てきます。今後多様化したインフラを維持していくためには、以前のようなサーバやネットワークをターゲットにしたルーチンワーク中心では、対応出来なくなってきています。まずは、その実態をしっかり認識することです。その上で、これから何が必要なのかを考えてみましょう。★システム運用カイゼンのポイント★インフラが多様化しています。その実態を認識し、その上で何が必要なのか考えよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月08日
コメント(2)
-
■どうやって“手抜き”をしようか？
【システム運用カイゼン】（2004.11.05）**********************************************************************■先ずは日記**********************************************************************ここ数日、暖かいですね。外を歩いていても、とても気持ちが良いのです。昨日の夜は、あるＩＴ系の書籍を探して本屋をはしごしてました。全部で５件。暫く前に発行されものだったために、結局見つかりませんでした。「そんな本なんて、ネットで買えば良いじゃん！」って言われそうですが、急いで必要だったもんで、足で解決しようとしましたが、残念な結果に終わりました。仕方なかったので、今日の昼休みに別の本で妥協となりました。**********************************************************************■どうやって“手抜き”をしようか？**********************************************************************いつも情報源に利用させていただいている、日経ＢＰ社さんのＷｅｂサイトのひとつ「ＩＴ Ｐｒｏ」で、また面白い記事が紹介されていました。掲載されたのは11/2です。さて内容はといいますと、「徹底的に手間を省力化する“手抜き”ポリシー作成術」http://itpro.nikkeibp.co.jp/members/NBY/Security/20041022/151588/今回は特集の第１回目ということで、これから７回に渡って掲載されるみたいです。さて、今回の記事で私の目を引いたのは、タイトルにあった“手抜き”という言葉です。通常仕事の上で“手抜き”なんていうと、あまり良い意味には使われませんが、実はその発想がとても大切なんですよ。カイゼンの発想の原点は“手抜き”そのものなのです。如何に“手抜き”をして、楽をするかという発想なくして、カイゼンのポイントは見えてきません。もし、生真面目に仕事を考えている方は、ちょっと発想を変えてみた方が良いと思いますよ。言われた通りに全てを行っていては、何の進歩も得られませんから。どうやったら、仕事が楽になるかを必死に考えてみましょう。私はこの“手抜き”という言葉が、大好きなのです。（カイゼンというテーマで日記を書いているくらいですから。）必要なことに力を使って、必要ではないことには“手抜き”をするのです。手を抜けることに無駄な力を使って、大切なことに手が回らないってことでは、バカバカしいですよね。★システム運用カイゼンのポイント★どうやったら、“手抜き”をして楽が出来るか？必死に考えてみましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月05日
コメント(0)
-
■イライラさせないための情報を提供する。
【システム運用カイゼン】（2004.11.04）**********************************************************************■先ずは日記**********************************************************************昨日は娘のピアノの発表会でした。頑張っている姿に、我が子ながら惚れ惚れしてしまいました。良い緊張感楽しめたみたいで、終わった後の笑顔はとても清々しいものでした。「よく頑張ったね！ お父さんは演奏する姿を見ながら、涙が出そうになっちゃいました。 在り来たりな言葉だけど、輝いている君の姿に感動しました。 これからも、いっぱい頑張って、いっぱい楽しんで下さい。 何も手伝ってあげられないけど、誰よりも応援しています。」**********************************************************************■イライラさせないための情報を提供する。**********************************************************************「お客様がイライラしないで済むように考える」という先日の話題の続きです。システムメンテナンスに伴って、システムサービスを利用出来ない利用者や、お客様は、イライラしたり、ストレスを感じたりしているはずだ、ということが先日のお話しでした。それでは、どうやってそのイライラやストレスを軽減させるのか、ということが今日の話しです。人間って、当たり前のことが、当たり前の状態でなくなった時に、大きなストレスを感じてしまいます。例えば、駅でもないのに突然電車が停車した場合などがそうです。 「急いでいるのに、何が起こったんだ？」 「いつになったら動き出すの？」きっとこんなことを考えたり、感じたりしていると思います。大抵このような時には、車内放送で「前の駅に先行の電車が停車しております。 先行の電車の発車まで、暫くお待ち下さい」なんていうことを聞いて、 「仕方ないなぁ。」とは思いながらも、一先ず安心出来ると思います。これがもし、何の情報提供もされず、ただ待たされたりしたらどうでしょう。人と会う約束をしていたら、 遅れるとの連絡をする必要があるのか？ それともすぐにでも動き出すので、連絡の必要はないのか？どうすれば良いのか判断が出来ませんよね、動き出すまでに待たされたのが、１、２分程度であったとしても、滅茶苦茶イライラすると思います。さて、システムメンテナンスの話しに戻りましょう。システムメンテナンスに伴い、システムサービスを利用出来ないことを、この電車の停止に置き換えてみたら分かると思います。動くはずのものが、動かない。いつ動き出すのか分からないでは、利用者はイライラするしかないですよね。ですから、私たちシステム運用をする側は、 ●利用者やお客様に、必要な情報を提供することが大切。ということが、分かると思います。例えば、 ・何故システムを利用出来ないのか？ ・いつシステムは使えるようになるのか？ ・緊急時はどうすれば良いのか？ あるいは、連絡をすれば良いのか？ ・・・・・など等システムを利用出来ない事実は、どうすることも出来ません。だからこそその事実を、利用者やお客様に納得していただくしかないですよね。自分が逆の立場だったら、どう感じるのか？ どうして欲しいのか？そこを考えることで、どうすれば良いのかが見えてくると思います。情報システムは、水道を捻れば出てくる水と同じように、当たり前のものになった今、その感覚に応えるサービスレベルが必要になってきています。あなたの関係する情報システムは、そのようなサービスレベルをクリア出来ていますか？もしそうでないというのであれば、どうしますか？★システム運用カイゼンのポイント★システムメンテナンスに伴って、システムが利用出来ないことは仕方ありません。利用者やお客様が、イライラしないで済むように、必要な情報を提供することが大切です。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月04日
コメント(0)
-
■お客様がイライラしないで済むように考える
【システム運用カイゼン】（2004.11.02）**********************************************************************■先ずは日記**********************************************************************今日は午前中に、コーチプラスの佐野さんにお会いし、今度始められるサービスの "BoardCore" を体験させていただきました。佐野さんも楽天で日記されてます。アドレスは次の通り。http://plaza.rakuten.co.jp/coachplus/コーチプラスのＨＰは、 http://www.coachplus.jp/日刊でメルマガも発行されています。もっとコミュニケーションをとろうよ！ (マガジンID：0000108492)http://www.coachplus.jp/html/melma.htmlさて、BoardCoreの感想ですが、非常に良かったですよ。（ちなみに、佐野さんに頼まれて書いているのではありませんので）ホワイトボードを使いながら、私自身が曖昧にしていた人生の選択を、明確に導き出してもらいました。私は実際のところその選択に対し、ある程度の答えは持っていました。しかし、自分の中にあった引っかかりをや悶々としたものを、文字というかたちで整理していただいたき、正に腑に落ちたという感覚を得ました。自分ひとりで考えている時には、選択に対するリスクばかりが気にかかってしまい、選択の結果で得られるであろうメリットに対して、気持ちが集中出来ていませんでした。それが、BoardCore によってメリットの要素を引き出してもらった結果、自分の中にあった夢を、ハッキリしたイメージにすることが出来たのです。更に言えば、夢へのストーリーが整理出来たおかげで、モチベーションも上がったというおまけ付き。多分、佐野さん自身が持っているオーラが、私の気持ちを高めてくれたのだと思います。本当にありがとう御座いました。導き出していただいたことを実現するために、頑張りたいと思います。どうぞ、これからも宜しくお願いしますね。**********************************************************************■お客様がイライラしないで済むように考える**********************************************************************システムのメンテナンスに伴って、一時的にシステムを利用出来なくなることは避けることが出来ませんよね。例えばアプリケーションのバグのために、緊急でアプリケーション資産の入れ替えをしなければならない、そんなことはシステムを運用していれば、必ずと言って良いほど発生します。その時に忘れて欲しくないことがあります。それは、いったい何でしょう？・・・・・それは、システムサービスを受けたい、つまりシステムを使いたいと思っている人が、そのサービスを受けられないということです。「そんなこと当たり前だろう！」そう思った方、素晴らしい。あなたは、しっかりと利用者あるいはお客様のことが分かっていますね。さて、システムサービスを受けられなかった人は、その時どんな気持ちでいるでしょうか？多分、イライラしたり、ストレスを感じたりしているはずですよね。自分が逆の立場だったりしたこと考えれば分かります。決して良い気持ちではないはずです。つまりそれは、サービスレベルを落としてしまったため、満足度が低下したことを意味しています。しかし、始めに言った通り、システムのメンテナンスは避けられません。ですから利用者やお客様が少しでも、イライラしないで済むとか、ストレスを感じないで済むように考えることが必要ですね。それでは、具体的にどのようなことをすれば良いのでしょうか？・・・・・その辺の話しは、また次回にしたいと思います。★システム運用カイゼンのポイント★システムメンテナンスは避けることが出来ない。だから、利用者やお客様がイライラしないですむことを考えよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月02日
コメント(2)
-
■「７割近くの組織が変革を実行できない」らしい
【システム運用カイゼン】（2004.11.01）**********************************************************************■先ずは日記**********************************************************************１１月になりましたね。今日は某国内メーカさんから、私がお世話になっている現場のお客様へ、ＫＭ（ナレッジマネージメント）システムの提案説明が行われ、それに同席致しました。個人的にＫＭについては勉強しており、色んなソリューション事例や、製品を調べていましたが、予想していたより、良い製品でかつ、ノウハウも実績も持っていらっしゃてました。正直、結構いけてます。もし、ＫＭシステム導入を検討されてるところがあれば、一度お話しを聞かれた方が良いかもしれませんよ。興味がある方は、営業さん紹介しますよ。因みに、私が手数料貰ったりするものではありません。損得なしで、私が勝手に言ってることですので、ご心配なく。**********************************************************************■「７割近くの組織が変革を実行できない」らしい**********************************************************************数日前の日経ＢＰ社のＷｅｂサイトで、面白い記事を見ました。まずは、記事の紹介です。BP's Eye経営の情識・「何も変わらない組織」が全体の3割強、組織DNA調査速報http://nikkeibp.jp/wcs/leaf/CID/onair/jp/rep01/340010この記事の中で、> パッシブ－アグレッシブ型、フィット・アンド・スタート型、管理過剰型は> いずれも、変革を実行できない健全とは言えない組織である。これら三つの> タイプに所属する回答者が7割近くいたことになる。とありました。ｘｘ型個々の話しは、記事の内容を読んでもらうとして・・・、私は「７割近くの組織が変革を実行できない」ということに、ショックを受けてしまいました。ショックと言いながら、確かにその数字を証明するようなことは、普段の仕事の中から感じています。何度も経験していることですが、まわりの組織を巻き込み、仕事の流れを変えようとした時、打合せの席では良いことを言って、やる気を見せてくれます。しかし実際の行動となると、 「内部の調整が必要だから・・・」なんてことで、いつまで経っても始まらないところが多いんです。皆さんも、きっとそう感じているのではありませんか！？他人のことはとやかく言いたくはありませんが、変な期待だけさせて、裏切るようなことはしないで欲しいですね。お願いだから、邪魔だけはしないで・・・！って感じですね。何か愚痴になってしまいました。★システム運用カイゼンのポイント★「７割近くの組織が変革を実行できない」らしい。別組織を巻き込む時は、心してかかる必要がありそうです。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年11月01日
コメント(0)
-
■システム運用に「組織」は重要な意味を持つ
【システム運用カイゼン】（2004.10.30）**********************************************************************■先ずは日記**********************************************************************今日は朝から雨でした。新潟の被災地の方たちには、つらい雨ですよね。早期復興をお祈りいたします。**********************************************************************■システム運用に「組織」は重要な意味を持つ**********************************************************************ＡＤ坂本さんの日記から・・・「組織の重要性」、http://tb.plaza.rakuten.co.jp/advsaka/diary/200410300000/ システムを運用していく上で、ＡＤ坂本さんも言われていますが、組織がしっかりしていないといけません。情報システムが、企業活動を行っていく上で、その存在が当たり前のようになり、決して切り離すことが出来ない存在となった今、システム運用は企業活動の重要な部分を担っている「組織」ということになります。 ・システムを安定的に稼動させ、 ・またシステムそのものを評価し、 ・将来に向けたあるべきシステムを検討していく。また、 ・システムに関係する、全ての組織との関係を明確にし、 ・システムダウンなどの、もしもの時に対する準備しておく。それを実現するために、 ●必要な機能や管理内容を整理し、 ●その作業に応じた体制を整え、 ●マネジメントの仕組みを作ることが必要となります。単なるコンピュータ好きの集まりでは、システムを運用してはいけません。繰り返しになりますが、企業活動の重要な部分を担う「組織」です。しっかりした「組織」を目指し、作っていきましょう。★システム運用カイゼンのポイント★システム運用に「組織」は重要な意味を持つ。しっかりした「組織」を目指し、作っていきましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月30日
コメント(2)
-
■仕事の目標がないという部下
【システム運用カイゼン】（2004.10.29）**********************************************************************■先ずは日記**********************************************************************昨日お客様へ上半期の活動報告を終え、今日はちょっと息抜きモードで一日を過ごさせていただきました。来週から、新しい月も始まります。気分一新、頑張りましょう。**********************************************************************■仕事の目標がないという部下**********************************************************************★今日は運用カイゼンとは関係ない話しです。先日社内メンバの面談を行ったのですが、仕事の目標がないと言うのです。開発の仕事をしているメンバだったので、流行の技術なり、実務に役立つようなものがないのかと聞いてみても、やはりこれといって "ない" とのこと。１ヶ月程前に、社内異動で私の部署に配属になり、やっとゆっくり話しをしたところ、そんな感じでした。正直言って、ショック。私は心の中で、 「何が楽しくて、毎日会社に来てるの？」 「うそでも、何か目標を言うだろう！」 「前の部署で、いったいどんな風にしてたの？」そんなことを呟きながらも、何か話してもらおうとしましたが、結局反応を得ることは出来ませんでした。目標もないまま、日々を流しているなんて、人生勿体ない。作業現場で同じ年代（二十代前半）の人たちに話しを聞いたら、反応こそ違えど目標を持たずに仕事をいる人が、意外と多いことに驚かされました。今時点で何かに取り組んでいなくても、「こんな技術を身に付けたいなぁ！」というような気持ち位は持っていて欲しい。それが正直な感想です。全ての人がそうだとは言いませんが、自分の人生の主導権を、自ら手放してはいけません。仕事以前の問題です。もっと自分自身の成長を、自ら作り出して行く気持ちを持って欲しいものです。★システム運用カイゼンのポイント★今日はお休みでした。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月29日
コメント(0)
-
■当たり前のことを、当たり前のように実行し続ける。
【システム運用カイゼン】（2004.10.28）**********************************************************************■先ずは日記**********************************************************************昨日の奇跡的な救出劇には、子を持つ親として心の痛みを感じずにはいれませんでした。まだ２歳にしかならない子供が、真っ暗で狭い中にたった一人でいたなんて、どんなに寂しく、心細い思いをしたのでしょう。まだママにべったりだったはずです。うちの下の子供は３歳ですが、ちょっと親の居場所が分からなくなるだけで、大泣きするくらいです。それが当たり前なんです。それなのに・・・。考えただけで、涙が浮かんできます。きっとこれから、色々大変だと思います。ただ、今は「頑張ってね！」と、ここで言うことくらいしか思いつきません。**********************************************************************■当たり前のことを、当たり前のように実行し続ける。**********************************************************************読まれている方も多いと思いますが、先日（10/26）の、鮒谷さんのメルマガ【平成・進化論。】（http://www.mag2.com/m/0000114948.htm）のテーマは、 「原理原則はシンプルでも、習慣にするのが難しい」でした。日々の仕事の中で、嫌と言うほど思い知らされています。良いと思って始めても三日坊主になったり、面倒臭いがために始めることさえしなかったり・・・。それを習慣化し継続するとなると、予想以上の忍耐が必要となります。「当たり前のことを、当たり前のように実行し続ける」って、意外と難しいですよね。基本動作を怠らなければ、事故は発生しなかったとか、未然に防ぐことが出来たなんて、世間で飽きるほど耳にします。例えば、日々の監視を怠っていなければ・・・なんてことありませんか？気付かないうちにいつのまにかデータ量が増加し、リソースを圧迫したことで、システムダウンしてしまったなんてことでは、システム運用担当者として恥ずかしいでしょ。小さな積み重ねこそが、最大のパワーを作り上げます。目的や目標をハッキリ持ち、それを目指しシンプルな原理原則を継続していきたいですね。★システム運用カイゼンのポイント★小さな積み重ねこそが、最大のパワーを作り上げる。当たり前のことを、当たり前のように実行し続けよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月28日
コメント(0)
-
■環境変化に応じた改善を施す
【システム運用カイゼン】（2004.10.27）**********************************************************************■先ずは日記**********************************************************************先ずは、新潟中越地方地震により、被災された皆様にお見舞い申し上げます。さて、久しぶりに日記復活です。丁度最初の地震が発生した時に、私は羽田空港にいまして、早めの夕食を取っていました。私の乗るはずだった飛行機は折り返し運転の着陸直前だったみたいで、地震後の点検待ちの間に、成田空港へまわされましたが、結局再度羽田空港に戻され、２時間半遅れでの出発となりました。脱線した真っ暗の新幹線に、閉じ込められたことを思えば楽なものです。（子供たちは相当退屈してましたが・・・）私が仲良くさせていただいている方は、たまたま親戚の慶弔ごとで、新潟へ行かれたらしいのですが、新幹線脱線事故のため、戻ってこれなくなったということでした。どうにか航空機の臨時便が取れ、一日遅れで東京へ戻られたみたいです。**********************************************************************■環境変化に応じた改善を施す**********************************************************************ビジネス書で、次のような言葉を良く目にします。 「過去の成功体験を捨てる」システム運用においても、当然考慮しておく必要のある言葉です。システムは「生き物」と良く呼ばれますが、様々な環境の変化により、 ・システム自身が拡張されたり、 ・場合によっては縮小されたり、 ・当然データ量は増加し、 ・必要性が上がれば、利用頻度が増加します。その為に過去の管理体系では、運用上のリスクを低減出来なかったり、回避出来なかったりします。過去においては通用していたものが、今となっては全く通用しない。セキュリティリスクなどは、その代表だと思います。ＩＴ業界はご存知の通り、変化の激しい分野に属しています。システム運用には、常に今やっていることに疑問を投げかけ、環境に変化に応じた、改善を施していくことが必要です。★システム運用カイゼンのポイント★過去のやり方にこだわっていないか？環境の変化に応じた、改善を施していこう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月27日
コメント(0)
-
■サービスを提供しているお客様のことを思い浮かべる
【システム運用カイゼン】（2004.10.22）**********************************************************************■先ずは日記**********************************************************************朝１０時頃、レインボーブリッジの下を、煙を吐いた船が２艘通っていったがあれは何だんったんだ？煙って、蒸気なんかじゃないですよ！明らかに煙です。どう見ても、火災だろう！って感じの煙でした。でも火は見えなかったし・・・。さて、明日から九州の実家へ帰ります。実家にはネット接続出来る環境がないため、４日程お休みします。**********************************************************************■サービスを提供しているお客様のことを思い浮かべる**********************************************************************システム運用部門で、「お客様は誰？」という視点を、持っているだろうか？端末操作など、日々が機械相手の作業中心になっている人も多いでしょう。システムを安定稼動させることだけに、気持ちがいってしまい、お客様の顔が見えなくなっていては問題です。お客様と言っても、場合によってはそれが社内の人ということもあるでしょう。しかし、運用サービスを提供している側からみれば、社内であってもそれは、大切なお客様なのです。常に、お客様の顔を思い浮かべながら、「何を必要としているのだろう？」と自分自身に問い掛けることが必要です。時には、お客様に直接問い掛けてみましょう。「何か不満はない？ 不足しているものはない？」きっと運用サービスに関する、気付きが得られるはずです。★システム運用カイゼンのポイント★システム運用は、機械相手の仕事ではない。運用サービスを提供しているお客様のことを、常に思い浮かべよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月22日
コメント(2)
-
■面倒くさがらず、情報の 整理・整頓 をする
【システム運用カイゼン】（2004.10.21）**********************************************************************■先ずは日記**********************************************************************今回の台風は、今年最大の被害を出したらしいですね。天災は本当に怖いですよね。自然の前では、人間は無力そのもの。日頃忘れがちですが、あらためて考えさせられました。**********************************************************************■面倒くさがらず、情報の 整理・整頓 をする**********************************************************************こんな経験をしたことはないでしょうか？ 「こんな障害、以前にもあったよなぁ！ 何処かに、記録が残っていないかなぁ？」私は何度も経験しました。その度に、サーバや自分の端末の中を探し回ったり、人に聞いて回ったり。見つかれば良いのですが、散々探した挙句、結局見つからなかった場合、多くの時間を無駄にしてしまいます。そんなことにならないためにも、再利用される可能性のある情報は、しっかりしたルールを決め、保存あるいは保管しておくことです。必要であれば、ファイリングシステムや、検索ソフトなどを利用して、必要な情報へのアクセスをしやすくしましょう。世間で言われる通り、様々な情報が氾濫しています。分かっていることですが、特に仕事に必要な情報の 整理・整頓 が必要です。時間を無駄にしないためにも、面倒くさがらずに取り組みましょう。★システム運用カイゼンのポイント★面倒くさがらず、情報の 整理・整頓 をしよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月21日
コメント(0)
-
■改善でも変革でも、目標の具体的イメージが必要
【システム運用カイゼン】（2004.10.20）**********************************************************************■先ずは日記**********************************************************************昨夜は、クイズプロデューサー）弘中さんの開催される『五反田ＱＱ』に参加してきました。いつもの軽快なトークで、楽しみながら勉強をさせていただきました。懇親会では、久しぶりにお会いした方、新しくお会いした方を交え、頬の筋肉が痛くなるほど、笑わせていただきました。間違いなく、一番うるさい集団だったはずです。ご一緒させていただいた皆様、ありがとう御座いました。昨日は私の誕生日だったんですが、色んな方々からお祝いのお言葉やメールをいただきました。本当にありがとう御座いました。**********************************************************************■改善でも変革でも、目標の具体的イメージが必要**********************************************************************組織で高い目標を持っていますか？それも具体的にイメージ出来ていますか？始めから諦めて、夢を描くことを止めてしまっては、絶対に実現しません。こんな仕事が出来るチームへと成長しよう。あんなスキルを持ったエンジニアになろう。夢があるからこそ、そこに近づくことが出来ます。今を変えるということは、変えた先のことを具体的にイメージすることから全ては始まるはずです。改善だって同じ。変革だって同じ具体的夢を持ちましょう。★システム運用カイゼンのポイント★改善でも変革でも、目標に対する具体的イメージを持とう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月20日
コメント(0)
-
■問題意識が薄れて、無駄なことでも続けてしまう。
【システム運用カイゼン】（2004.10.18）**********************************************************************■先ずは日記**********************************************************************季節の変わり目のためでしょうか、風邪を引いてしまったようです。昨日は一日中、鼻水が止まらずつらかった。今日は幾分か楽にはなりましたが、まぶたが腫れぼったく、鼻水も止まっていません。いっぱい仕事があるのに・・・。頑張りましょう！！**********************************************************************■問題意識が薄れて、無駄なことでも続けてしまう。**********************************************************************システム運用の仕事は、ルーチン作業が多く、惰性で流している作業が多くないでしょうか？惰性でも実施出来るような手順になっていることは、非常に安定した作業ということで、見方によっては良いことかもしれません。しかし本当にそれで良いのでしょうか？担当者に、 「何でその作業を行っているのか？」と問い掛けると、 「前からやっていましたから」なんて回答が戻ってきたりするものは、ちょっと問題です。質問を変えて、 「何故、その作業に人が介在する必要があるのか？」との問い掛けに対しても、これまた 「前からやっていましたから」なんてことだと、更に問題です。 "問題を問題と感じない" 状態の現れ、 "問題意識が欠如している" 証拠です。常日頃から自分達の行っている作業について、 ●その目的や手順が妥当なのか？ ●そもそも、本当に必要なのか？と、問いかけ続けることが大切です。★システム運用カイゼンのポイント★気付かないまま、無駄な作業を行っていることがないだろうか？常に問題意識を持ち、作業の妥当性・必要を問いかけよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月18日
コメント(0)
-
■業務影響に応じた復旧を目指す
【システム運用カイゼン】（2004.10.15）**********************************************************************■先ずは日記**********************************************************************朝からトラブルで、予定していた仕事が何も出来ずに、一日が終わってしまいました。やっと今（ただ今 ＡＭ３：３０）一日ぶりのご飯を食べてきました。トラブルだけは、どうしようもないですね。食事のことも忘れてしまうのですから。**********************************************************************■業務影響に応じた復旧を目指す**********************************************************************先程書いた通り、運用にトラブルは付きものです。トラブルは大小様々なことが起こります。トラブルが発生した時に、その影響の大小を冷静の判断し、適切な振る舞いが取れるようにすることが大切です。何か起こったからといって、運用が慌ててしまっては、ビジネスフロー全体が統制を失い、混乱を起こしてしまいます。慌てることなく、業務上の影響を中心に考え、その影響に応じたアクションをとることが求められます。全体の流れを滞らせない、復旧を目指しましょう。★システム運用カイゼンのポイント★トラブルが発生した場合、業務影響に応じた復旧を行おう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月15日
コメント(0)
-
■空想論議で時間を無駄にしてしまう
【システム運用カイゼン】（2004.10.14）**********************************************************************■先ずは日記**********************************************************************何だかバタバタしてます。仕事が細切れになってしまって、集中力を欠いた状況。何とかするぞ。**********************************************************************■空想論議で時間を無駄にしてしまう**********************************************************************「仕事のやり方をちょっと変えてみよう！」と思った時に、まずは関係者を集めて会議をしたりしてませんか？多分それはとても回り道をしていることになります。だって、何人もの人が集まって、予測の世界で「ああでもない、こうでもない・・・」と言ったところで、何の解決も出来ませんよね。考えるより、まず試して見ることです。それから会議をしても、何の問題もないですよね。試した分、空想の世界での会話が減って、全て具体的に会話が出来るようになります。★システム運用カイゼンのポイント★空想論で時間を無駄にするより、まずは試してみましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月14日
コメント(0)
-
■将来を妥協の産物にしたくない
【システム運用カイゼン】（2004.10.12）**********************************************************************■先ずは日記**********************************************************************「スーパーマン」の主演俳優のクリストファー・リーブさんが、亡くなられたそうですね。特に「スーパーマン」に対する思い入れはありませんが、落馬事故以降の活躍されている姿は、鮮烈なイメージで受け止めていました。私などからは想像も付かないほどの努力があったことは、言うまでもないことでしょう。きっととても小さかったであろう一歩を、果てしない夢を信じ、確実に進んで来られたからこそ、テレビの世界まで復帰されたはずです。夢はかないませんでしたが、多くのことを学ばせていただきました。ただ、ご冥福を祈るばかりです。**********************************************************************■将来を妥協の産物にしたくない**********************************************************************今の状況は、過去の自分の行動の結果ですよね。つまり将来は、今の自分の行動の結果。今は、時間が無くて出来ていないことがあるかもしれません。でもいつかは、何とかしなくてはいけないんですよね。システムのキャパシティ管理を例に考えてみましょう。キャパシティ管理は、今すぐにでもしなければ、システムが止まってしまう訳ではありません。しかし出来れば必要な管理項目を洗い出し、定期的に監視を行うようにして、リソースが枯渇して運用に影響を出さないように、準備しておきたいものです。現時点では、管理項目が洗い出せていないために、中途半端な監視しか出来ないということもあるでしょう。ただ、将来のことを思えば、近い将来何らかの対処を必要とするのは確実です。今のままで、良いわけはありません。もし「時間がないから」だとか、「何とかなるでしょう」と見て見ぬふりをしていたとすれば、将来「あの時に・・・」と後悔をすることにしかなりません。指を咥えたままでは、システムダウンが待っています。出来ない理由を考えるよりは、出来るようにするためのことを考えることです。時間を何とか調整するとか、人を調整するとか、思い切って予算をとるために提案をするとか、考えてみれば、出来ることは沢山あるはずです。将来を妥協の産物にしたくはないですよね。今はだめでも、将来は何とかするために、今出来ることを考えましょう。★システム運用カイゼンのポイント★今出来てないのは仕方ない。でも将来に渡ってそのままで良い訳ないですよね。今出来ることを考えましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月12日
コメント(0)
-
■テクニックやノウハウを活かすための "思考錯誤"
【システム運用カイゼン】（2004.10.11）**********************************************************************■先ずは日記**********************************************************************今日は体育の日です。ここ数年運動不足が続いており、体力の低下を強く感じる今日この頃・・・。昨夜の「あるある大辞典」であったエクササイズを調子に乗ってやってたら、今日は腰が痛い。ついでに言えば体が重い。きっと明日になって筋肉痛が襲ってくるに違いない。妻のお尻のたるみを笑ってられない私でした。**********************************************************************■テクニックやノウハウを活かすための "思考錯誤" ********************************************************************** "テクニック" や "ノウハウ" と言われるものに頼ろうとしても、思うように結果が出せない場合ってありますよね。私もその類の本は、結構読んだりしてますので、試しにやってみたりしたことが何度もあります。機械相手のプログラミングテクニック等は、本に書いてあることを真似るだけで、大きな効果を得ることが出来ましたし、比較的使いまわしもし易かったりして、そのような本を見つけると飛びついていました。しかしこれが、人間を相手にするようなものになると、●そもそもやろうとすることの意図を理解してもらえなかった。●真似ることで一時的な効果が出たが、継続しなかったので逆効果となった。●たまには理解者を得ることが出来て、思いのほか上手くいった。・・・など等、様々な結果を生み出しています。結局のところ、表面的なことを真似ても、思うような結果には繋がらないものが多いのです。安易にテクニックやノウハウに頼ってしまい、真似ることに神経が集中して、本来の目的から意識が遠のいてしまっているのではないでしょうか？相手が人間である場合、感情によって左右される微妙なラインがありますよね。そこを見誤ってしまえば、どんな素晴らしいテクニックやノウハウであろうと、何の意味もなしません。理解者や協力者を募ったり、一度やってだめならやり方を少し変えてみたり、時には政治力を利用したりすることが必要です。テクニックやノウハウは、成功事例です。どんどん活用したいですね。しかし、表面上を真似ただけでは効果を生み出せません。テクニックやノウハウを活かすための、 "思考錯誤" が必要です。★システム運用カイゼンのポイント★テクニックやノウハウを真似ることにだけ集中してはいけない。目標を常に意識し、テクニックやノウハウを活かすための思考錯誤を重ねよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月11日
コメント(0)
-
■対外的なことばかりに一所懸命でいると、中に不平・不満が溜まってしまう。
【システム運用カイゼン】（2004.10.08）**********************************************************************■先ずは日記**********************************************************************また台風が来てますね。困ったものです。九州の義妹の家は、度重なる台風で家の一部が壊れ、修理を見積もったところ、２５０万円だったらしい。車も、色んなところに傷や凹みが出来て、そちらも修理中だそうです。殆どは保険で対応出来るらしいのですが、大変だすよね。保険会社はもっと大変ですね。**********************************************************************■対外的なことばかりに一所懸命でいると、中に不平・不満が溜まってしまう。**********************************************************************ここ１、２年は、様々な経緯もあったのですが、お客様に対し仕事の内容を、可視化することに努めてきました。その甲斐もあって、信頼関係は深まり、更に今後に向けた協力体制も、確実に強化されています。対外的には、非常に効果を上げてきているのですが・・・、短期間に、仕事のやり方、ルール、組織ミッションまでも見直し、手を入れてきたために、現場サイドでは大きな動揺を生んでいます。不平、不満も多く、随分愚痴を耳にすることが多い状況です。お客様を取り巻く、急速なビジネス環境の変化が、私たちに対しても疾風怒涛のごとく押し寄せ、変化を余儀なくされたのです。急速な変化が、組織に無理を強いているのは当然でした。これまでお客様との信頼関係強化を中心にして、時には強引なくらいに施策を推進してきました。そのしわ寄せが、現場サイドに集中していたのは知りながらです。しかし、モチベーションも限界かもしれません。つい先日ですが、ここ数年、いや特にこの半年で、見直してきた担務やルールでお客様との合意も取れ、更には１年以上もの間、日の目を見なかった提案も急に動き出し、対外的な改善について、ある程度目処がたちました。これからは、メンバの不平、不満にしっかり耳を貸して、内部の環境改善に力を入れていくつもりです。来週、上期の総括報告をお客様にする予定になっています。その席で下期は内部環境の改善を中心に行い、組織強化を中心に推進する旨の話しをしようと思っています。大変だけど、みんな一緒に頑張ろう！★システム運用カイゼンのポイント★外にばかり目を向けていると、内部は付いていけなくなる。しっかり中に目を向けることをしよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月08日
コメント(0)
-
■上に相談すると、当たり前のことを教えてくれる。
【システム運用カイゼン】（2004.10.07）**********************************************************************■先ずは日記**********************************************************************昨日の夜は同じプロジェクトで、開発部門側の現場リーダをされているＡさんのお誘いで、Ａさんと同じ会社のＹさんと、３人で飲みに行きました。Ａさん、Ｙさん昨夜は、ありがとうございました。**********************************************************************■上に相談すると、当たり前のことを教えてくれる。**********************************************************************今日は日記のところで書いたＡさんが、昨日飲んでいるときに話されたことを紹介したいと思います。私も、Ａさんも、Ｙさんも、中間管理職です。お互いそれぞれの立場で、日々現場の仕事や管理の仕事に、多くの悩みを抱えながら励んでいる状況です。飲みながら、互いに悩みを打ち明け合け、相談し合った訳ですが、その時Ａさんが言ったことばは、「上（上司など）に相談すると、当たり前のことを教えてくれるんだよ。 でも、今生きた情報は現場からしか、教えてもらえないんだよね！」上の方たちは、これまでの経験から様々なことを教えていただけます。それはとても有難いことで、Ａさんもとても大切にされています。しかし「今作業の現場で何が起きていて、現場の個々の人たちがどんな思いをし、どれくらい悩んでいるのか？」ということは、机上論では計り知れないことの方が多く、事実は現場にしか存在しません。そこにいるのは、それぞれの心を持った、生きた人なのです。手厚いケアを必要とする人もいるでしょう。厳しく突き放す必要のある人もいるでしょう。決して答えはひとつじゃありません。思考錯誤の結果は、上の人が教えてくれたものかもしれませんね。しかし、経験をしたことで、その答えの本当の意味を知ることになるのです。★システム運用カイゼンのポイント★「上（上司など）に相談すると、当たり前のことを教えてくれるんだよ。 でも、今生きた情報は現場からしか、教えてもらえないんだよね！」━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月07日
コメント(0)
-
■お客様のセキュリティへの不安に対し、どのように応えていくのか。
【システム運用カイゼン】（2004.10.06）**********************************************************************■先ずは日記**********************************************************************昨日は緊急のトラブルで徹夜でした。徹夜じゃないな、朝方は寝たので、職場へのお泊りですね。昨夜の２３時頃、帰宅しようとエレベーターに乗ったところ、携帯電話が鳴りました。障害対応のヘルプの連絡です。お泊り決定の瞬間でした。昨夜のうちに暫定的な対処・復旧は完了しましたが、障害影響による罹災情報の完全復旧には、まだ至っていません。作業自体は私の手から離れましたが、担当の人は今日も頑張ってます。**********************************************************************■お客様のセキュリティへの不安に対し、どのように応えていくのか。**********************************************************************情報漏洩事件は、とどまる所を知りませんね。昨日もエヌ・ティ・ティ・ドコモ九州からの情報漏洩が報道されていました。お詫びのＨＰアドレスhttp://www.docomokyusyu.co.jp/info/customer/20041005_owabi.html元派遣社員による行為のようです。これまでの起こった事件もその殆どが、内部の人間によるものです。悲しいことですが、性善説ではセキュリティを守れない世の中になってしまっているようです。今日は、お客様の情報資産を扱う、アウトソーサーや運用を請負うベンダー、あるいは派遣社員としての考えです。先日も書きましたが、内部による犯行では、どれだけコストをかけ対策を施しても、完全堅牢な環境にはなりません。お互いを疑い合いながら、仕事をしなければならない環境にはしたくありませんよね。（考えが甘いと言われそうですが・・・）行き着くところ「お客様との信頼関係をどのように考え、どう行動するのか。」のように思います。私が席を置く現場は、生の顧客情報を扱うことが非常に多い部署です。そのために "非常にリスクの高い部署" との見方をされています。私たちは、お客様のその不安に対し、 ●自ら全ての作業の記録を残していく。 （インシデント情報と顧客情報アクセスなどの全ての記録） ●その記録は全てオープンにしていく。 （全ての記録は、フルオープンでお客様に公開する） ●現状の課題、リスクも全てオープンにしていく。 （管理・対策が出来ていない部分も、事実を全てお客様に伝える、問題を 可視化する） ●自らセキュリティ強化に向け積極的に取り組む。 （可視化された問題を、お客様とともに優先度をつけ、対策を推進する）完璧とは言えませんが、これらのことに積極的に取り組み、信頼関係を築こうと勤めています。この取り組みにどれ程の効果があるのか、現時点で計測出来ませんが、担当者個々への意識付けや、お客様からの信頼という効果は出ているようです。とても小さな取り組みですが、作業を行う上で手間もかかっています。性善説を証明することに、コストをかけていると言っても過言ではありません。脆弱な部分が多く、不安はつきることがありません。当然ですが、将来に向け様々な施策を検討・推進しており、うっかりミスを含め、事故を未然に防ぐような、仕組みや環境を構築しようとしています。しかし、それはまだ先の話しです。すぐにでも出来ることは、今の仕事が少しくらい面倒になったとしても、お客様との信頼関係を大切にし、まずはスタートしたかったのです。面倒になったことは、日々改善していけば良いのですから。★システム運用カイゼンのポイント★セキュリティリスクは益々高まっています。お客様の信頼を裏切らないため、今出来ることは何があるのだろう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月06日
コメント(0)
-
■下手な文章は仕事の効率を悪くしてしまう
【システム運用カイゼン】（2004.10.05）**********************************************************************■先ずは日記**********************************************************************今朝の雨は激しかった。そんな言っている今も、かなり降ってる。お昼になった今でも、靴の中が冷たい。今日は一日中雨。また帰りに濡れないといけない訳ね。**********************************************************************■下手な文章は仕事の効率を悪くしてしまう**********************************************************************システムにはドキュメントやマニュアルは必須のもの。運用の現場では、仕様書、作業手順書や障害（トラブル）報告などがありますよね。人のことを言えるほど、自分が出来る訳ではないのですが、文章を書くことが苦手な人が多くて困ります。例えば、 「この手順書読んだけど、 これじゃ良く判らなくって、作業出来ないんだよね！」 「障害報告読んだけど、 原因の意味、判らないんだけど！ ついでに言えば、根本原因は何だったの？」現場でこんな風景を目にしたことありませんか？ものによっては、ダラダラと文章が羅列してあって、「あ～、ちょっと読みたくないなぁ。」と、拒絶反応を起こしてしまいそうなものもあります。私のいる作業場でも、その点に苦労しています。作業手順書を作るように指示しても、いつまで経っても「もの」が仕上がらなかったり・・・。インシデント管理記録に残された、対応履歴や原因の文章が日本語になっていなかったり・・・。若かりし頃の自分だって、同じだったことを思い出します。そんな思い出話に浸っていても、仕事上は困りますね。私たちが試みたものを、ひとつ紹介しましょう。ありきたりかもしれませんが、障害報告について、雛形を作成しました。報告に必要とされる情報を最低限、網羅したものを準備し、サンプルも付けました。そうしたところ、全体的なレベルが上がり、短期間で大きな改善効果を見ることができました。何と言っても、書き直しの発生が極端に減りました。日本語レベルの問題は別として、情報の網羅性が安定したため、手戻りが少なく、承認者も何度も同じ報告に目を通す必要が無くなりました。報告を受ける人達も、常に同じレベルのものが出てくるので、理解しやすいとの感想を得られました。単純な対策ですが、意外と効果は高かったのです。是非お試し下さい。ただ、文章能力は高めたいですよね。『ベンチャーテクノロジーさん』の日記で、"書く技術"を高めるための書籍を紹介されています。http://tb.plaza.rakuten.co.jp/ventech/diary/200410030000/ （トラックバックしてます）ご参照あれ！ベンチャーテクノロジーさん曰く、> 「考える技術・書く技術」は、この本を読んでいないコンサルは、> モグリと言われるほどの超有名本。・・・私も随分前ですが「考える技術・書く技術」読みました。（読んでて良かった・・・）★システム運用カイゼンのポイント★システムの現場で、ドキュメントやマニュアルは必須のもの。雛形を準備して、全体のレベルの底上げをしよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月05日
コメント(2)
-
■形式だけのルールのために、現場の意識が低下してしまう
【システム運用カイゼン】（2004.10.04）**********************************************************************■先ずは日記**********************************************************************昨日から雨が降り続いています。今週はずっと雨らしい。昨日のお昼は、下の子供とふたりっきりで家の中。公園で拾ってきてたどんぐりで、爪楊枝を手と足にして、人形を作りました。夕方帰ってきてたお姉ちゃんは、羨ましそうにしてました。（今度はお姉ちゃんの分も作ってあげるね）**********************************************************************■形式だけのルールのために、現場の意識が低下してしまう**********************************************************************セキュリティの為だということで、無駄なルールが運用されていることはありませんか？私の作業現場では、組織変更にともない、運用ルールの見直しを行っています。そこで私は、実態が伴わない形式上のルールの押し付けに、徹底的に反対しています。何故ならば、形式的なことだけにこだわって、中途半端なルールを押し付けるほど、現場の担当者たちは、セキュリティに対する意識を落としてしまうからです。「セキュリティより、形式やルールを重んじているんだ！」そのように思われても仕方ないですよね。当然お金をかければ、色んなことが出来ます。でもそれが形式的なものになってしまえば、誰も重要性を認識してくれません。行き着くところ、セキュリティ性はマインドに依存する部分が、相当あります。形式だけにとらわれたものでは、事故は防げません。意識を低下させる分、逆効果を生んでしまいます。守られないルールなら無い方がまし。現状に対し、無駄のない対策を施し、常に見直しをしていきたいですね。★システム運用カイゼンのポイント★セキュリティ対策が、形式的なもになっていないか？形式だけのルールでは、現場のマインドは低下します。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月04日
コメント(0)
-
■重大なトラブルが、担当者の手元で眠っていることはないか
【システム運用カイゼン】（2004.10.01）**********************************************************************■先ずは日記**********************************************************************今日は慌しく一日が過ぎていきました。今は絶頂に眠い。**********************************************************************■重大なトラブルが、担当者の手元で眠っていることはないか**********************************************************************業務影響の大きい、重大なシステムトラブルが、担当者の手元で眠っていたりしたことってありませんか？そんな風になってしまう理由は、 担当者自信には、発生事象に対し危機意識を感じなかった、 そのため、緊急のアクションが必要と判断しなかった、 結果として、トラブル発生からとんでもない時間が経過してしまった。といったことだと思います。実は昨日、重大なトラブルと判断される内容のインシデントが発生していたのですが、今日の夕方になって、担当者から仕様の確認をされて、その時にはじめて、拙いということに気付きました。一応昨日のうちに、エスカレーションは行われていましたが、組織的な情報のキャッチアップと、アクションが伴っていませんでした。結局再現性がなく、現在も継続調査中となっています。現場では毎朝、インシデントの棚卸の場を設けているのですが、たまたま今日の打ち合わせの場に、リーダクラスのメンバが全員不在で、担当者同士で形式的な打ち合わせを行っただけであった。正直言って、物凄い危機感を感じてしまいました。●危機感その１ある程度、人に依存する部分は仕方ないとの思いもありますが、事象から重要度・緊急度のレベルを判断する基準が、徹底出来ていなかった。●危機感その２毎朝繰り返し行っている打ち合わせが、担当者たちには形式的なものになっていた。最近組織変更に伴う、エスカレーションルールの変更が、まだ整理出来ていなかったという理由もありましたが、それ以前の問題の方が大きいですね。来週早々に、 ●事象毎の重要度・緊急度判定レベルの見直し。 ●見直した結果の周知徹底。 ●エスカレーションルールの見直し。そして何より、 ●個々の担当者との意見交換で、エスカレーションに対する意識の確認を実施しようと思います。いや、しなければなりません。来週も忙しい一週間になりそうです。★システム運用カイゼンのポイント★事象ごとに適切なエスカレーションは出来ているだろうか？重大トラブルを見過ごさないための、仕組みは出来ているだろうか？出来ていなければ、早速準備に取り掛かろう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年10月01日
コメント(2)
-
■今の安定は、将来の不安定に繋がっている
【システム運用カイゼン】（2004.09.30）**********************************************************************■先ずは日記**********************************************************************９月も今日で終わりですね。ついこの前、８月も終わって、これで夏も終わりだなぁ、なんてこと考えてたような気がします。**********************************************************************■今の安定は、将来の不安定に繋がっている**********************************************************************「新しい技術への挑戦というリスクを取らない方がリスクは大きい。 この世界では、何もしないことが一番大きなリスクになる。」ORACLE の ラリー・エリソン氏のことばです。運用側の観点で言えば、新しいものばかりに固執されては、安定稼動の実現は困難ですよね。しかし違う角度から見た場合、現状維持に固執することは、変化に対応出来ないことになります。変化を恐れて何もしなければ、今この瞬間は安定していることが出来ますが、その安定が未来永劫保証される訳ではありません。逆に時間の流れとともに環境は変化し、不安定な時が必ず訪れます。現状に甘んじることなく、新しいことに挑戦していくには、恐怖が伴います。しかし自らリスクを取り、新しいことに挑戦していくことでしか、変化に対応していく術はありません。出来れば、新しいことに挑戦する時の、あの「何とも言えない緊張感」を楽しめるようになると良いのですが・・・。★システム運用カイゼンのポイント★今の安定は、将来の不安定を意味します。新しいことに挑戦することでしか、それを解決することはできない。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年09月30日
コメント(2)
-
■口数よりも行動
【システム運用カイゼン】（2004.09.29）**********************************************************************■先ずは日記**********************************************************************また台風が来てますね。九州には既に直撃しているようです。このまま日本列島を横断し、関東の方にも来そうですね。その台風の影響で雨が降っていますが、これから打合せで外に出ないといけません。結構雨脚が強いなぁ！こんな天気の日は辛いですね。**********************************************************************■口数よりも行動**********************************************************************現在、作業現場ではインシデント管理用のシステムを導入しようとしています。実はこのシステムがとても厄介で、作業の最適化を十分に検討されないまま、机上論で設計されたものなのです。毎日混乱の声を耳にする状況です。さっきも使用説明が行われたのですが、皆の顔に不満の気持ちが見え隠れしていました。説明が終わった後には複数の集団が出来て、そこで不安や不満を語り合っていました。そのシステムは、私とかでは調整の効かないレベルで話しが決まり、構築されたもののため、今更ケチを付けたところで何の意味も無いのです。俗に言う「上を向いて唾を吐く」って状態ですね。運用開始を目の前にして、ホント今更の状況になっていてもなお、関係者たちは調整に終われている状況です。今私たちが出来ることは、最大限活用出来るように協力することしかなのです。何もせずして、文句を言うのは簡単です。しかし、現場には評論家は必要ないのです。必要とされるのは、何とかして今の問題を解決し、最大限の結果を引き出す力のある人。やるだけのことはやって、結果使えないと言う判断をするのは構わないと思います。でも何もしないで、文句を語っている人は、机上論でシステムを作った連中と何ら変わりません。現場では、「口数」よりも「行動」と「結果」が必要です。★システム運用カイゼンのポイント★何かを変えるには、当然問題が伴います。何とかしてその問題を解決し、結果を引き出す力が必要とされます。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年09月29日
コメント(0)
-
■責任の曖昧な仕事
【システム運用カイゼン】（2004.09.28）**********************************************************************■先ずは日記**********************************************************************先週の後半から、めざましテレビの占いランキングで低迷したまま。下位ランキングをうろついてます。実際、風邪ひいて体調崩したり、頼んだ仕事が終わってなかったり・・・。これもひとつの試練でしょう。**********************************************************************■責任の曖昧な仕事**********************************************************************自分たちが所属する組織で、責任を持つ仕事の範囲の捉え方って、人によって違う場合がありますよね。「その仕事はあっちでやるべきだ！」とか「何でそんなことをうちでやってるんだ！」なんて話は良くあることます。今の現場では、常に仕事の見直しを行っているため、そんな話を耳にする機会が非常に多いのです。（勝手に他人の責任にしてるみたいで、私は嫌いです）昨日もリーダで打合せをやっていたところ、個々の認識違いが微妙にあることが判り、自分たちだけでは解決せず、関係部署と調整をする方向となりました。その微妙な線にある仕事は、面倒なものが多く、そのために自分たちから好んで、やりたがることはありません。しかしそこに問題があります。曖昧にしたままにしておいたがために、何かが起こってしまった時に、責任の擦りあいをする羽目になってしまいます。擦りあいならまだ良いでしょうが、お客様に迷惑をかけてしまうことになったら大変です。信用問題に関わりますよね。やりたい、やりたくないは別にして、責任は "はっきり" させましょう。★システム運用カイゼンのポイント★責任の所在が曖昧な仕事を放置するのは止めよう。何か起こってからでは遅い。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年09月28日
コメント(2)
-
■結果にこだわる
【システム運用カイゼン】（2004.09.27）**********************************************************************■先ずは日記**********************************************************************体調崩したり、忙しかったり・・・など等で、日記がお休みになってました。新しい週が始まりました。さぁ、頑張りましょう！！**********************************************************************■結果にこだわる**********************************************************************何をやるにせよ、結果を出すためには、それなりの辛抱が必要ですよね。時には世の中に溢れたハウツーものを真似たら、直ぐに結果が出てしまう場合もあるかもしれませんが、得られた結果を継続させるためには、やはり継続という辛抱が必要です。判っているけど、現実としては辛いものです。（辛いことを抱くのが、辛抱ですからね）今日は自分自身の反省を込めて、この日記を書きます。私は作業現場で改善活動を中心に行っており、小さな取り組みはそれなりに、結果をだすことが出来ています。しかし、少々大きな費用が必要な取り組みや、組織間を跨った大幅なルールの変更などは、１年以上経過しているにも関わらず、話しが進展しないものもあります。そのような状態になっているのには、当然理由があって、自分の想いだけではどうにもならないものです。だから、焦ってどうなるものでもないのですが、他力本願でことの成り行きを、ただ見守っていても当然結果は出ません。そうであるにも関わらず、私は・・・。最近関係する人たちから、 「あの話しはどうなってます？」と良く聞かれていました。それに対し私は、いい加減に面倒くささを感じており、 「私は待ち状態です」と話していました。実際何もせずに、待っていたのです。期待する人や、自分の仕事の流れが変わるために心配する人や、多くの人たちの思いが交錯しています。（それだけインパクトがあるということでしょう）私は面倒くさくなって、その期待や心配を無視していたのです。現状では確かに、私だけで何か結果を出せる訳ではありませんが、私が出来ることはあるはずです。それは、人の尻を叩くことかもしれませんし、政治力を活用するために、調整に走り回ることかもしれません。欲しいのは結果であり、大切なのはその結果にこだわり、出来る限りのことをやり尽くすことです。まだやれることは沢山あり、協力をお願い出来る人たちも沢山います。今は産みの苦しみを味わっているのです。きっと誰かに、この状況を乗り越えられるか試されているのです。諦めれば楽なのでしょうが、それは私の精神的な開放でしかなく、現場の仕事は何も楽にはなりません。時間とともに、更に面倒な問題へと波及していきます。最悪トラブルを誘発してしまうかもしれません。ここでもう一度、プライドに油を注いで、燃え上がらせる必要があります。結果にこだわり、今出来ることをやり尽くす。それだけです。★システム運用カイゼンのポイント★結果をだすのに、他力本願に陥っていないか？自分が出来ることは沢山あるはずです。結果にこだわりましょう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年09月27日
コメント(0)
-
■ゼネラリストでは何故いけない
【システム運用カイゼン】（2004.09.24）**********************************************************************■先ずは日記**********************************************************************先日飲みに行った次の日に、体調悪いなぁ～！ 頭痛いなぁ～！なんて思っていたら、風邪ひいてたみたいです。その日の夜には熱が出て、昨日は一日大人しくしてました。そして今朝になっても、熱はなかったのですが、鼻は詰っているし、少々寒気はするし・・・。そんな日に限って、仕事は忙しいし。最近仕事を楽してたもんだから、罰があたったのかもしれません。**********************************************************************■ゼネラリストでは何故いけない********************************************************************** "スペシャリストの時代" と言われて久しいですね。「いったい自分自身は・・・?」今朝通勤途中に歩きながら、何気なくそんなことを考えていました。最近の私は、技術的な面について、特に何かを集中的に勉強したりはしていません。日々の仕事への活用、またマネジメントの仕組み作りをするため、ＩＴＩＬについては、よく調べたりはしますが・・・。興味を持っているものと言えば沢山あります。まずＩＴ関連では・・・、例えば、ＩＴをより効率的に、また効果的に商売に活用したいとのポリシーを持っていますので、ＥＡ（Enterprise Architecture）や、ＳＯＡ（Service Oriented Architecture) 等には興味があり、セミナーに参加したり、ネットで調べたりしています。他には、運用とは切っても切れない関係にある、セキュリティ関係についてもやはりセミナーに参加したり、ネットで調べたりしています。一般ビジネス関連では・・・、最近では、マーケティング関係の書籍購入率が一番高いですね。目の前の本棚の中を覗き込んでも、圧倒的にマーケ関連の本が多く並んでますその他には、製造業特に、トヨタ社関連の書籍が多いですね。後はマネジメント関連。その他にも沢山って感じです。そんな状況から見た場合、私はスペシャリストではなく、ゼネラリストの方向に自分を進めています。それには、しっかりした理由があり、その道を自分で選択しました。数年前までは、私はデータベース関連の技術を中心に、アプリケーション実装設計、特にトランザクション設計を最大の売りとした技術者でした。全くもってスペシャリストの部類に入ります。しかしその後自分が "マネージャ" として仕事をしていく中で、また作業現場で作業改善を推進していく中で、スペシャリストではその仕事が成り立たなくなったのです。その他にも理由があります。自分の人生を主導的に動かしていくのに、「スペシャリスト」というある意味他人から使われてナンボの人生では、自分が納得出来ないと考えたからです。自分の人生、また自分の所属する組織やプロジェクトを主導的にマネジメントしようと考えたら、必然的にスペシャリストという選択肢ではなく、ゼネラリストという選択肢となった訳です。しかしゼネラリストと言えば「何でも屋」的なイメージがあります。「何でも屋です」＝「何も出来ません」にならないよう、私は自ら考え、行動するゼネラリストでありたいと考えています。中途半端を止め、自分が選択した道を信じ、徹底的に追及することが重要だと思うのです。組織やプロジェクトをまとめていくには、スペシャリストだけでは困難です。最悪、統制が取れず烏合の衆となる場合もあります。マネジメントの仕組みを作り、組織全体をコーディネートしていくには、ゼネラリストの能力が不可欠です。世の中が「スペシャリストの時代」騒いでいるからと言って、全員がそれじゃ社会は成り立ちませんよね。（その言葉は、稼ぎ手を欲しがる企業が、自分達が使う人を増やす為に言って るのだと、私は思っています）スペシャリストとゼネラリストの両方がいて初めて、組織やプロジェクトは、機能します。★システム運用カイゼンのポイント★組織やプロジェクトをまとめていくには、ゼネラリストの存在は不可欠。スペシャリストだけではなく、ゼネラリストも組織は必要とする。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年09月24日
コメント(2)
-
■作業記録を残すことの重要性
【システム運用カイゼン】（2004.09.22）**********************************************************************■先ずは日記**********************************************************************今日は、朝からレビューや打合せが立て続けにあります。昨夜は飲みに行ったのに、家に帰ってまで飲んでしまいました。更には夜中に暑くて目を覚ましたりしたことも重なり、体がとてもだるいのです。ちょっと頭も痛いし、二日酔いですね。そんな体に鞭打って、気合で頑張らねば・・・。**********************************************************************■作業記録を残すことの重要性**********************************************************************システム運用には作業記録って大切ですよね。私は仕事の現場では、インシデント管理を中心に行っているのですが、やはりそこでも、作業記録は重要な意味を持っています。発生しているインシデント情報は全て共有し、適切な対応が出来ているか点検することに利用していますし、同事象については、別担当者でも対応が出来るように、対応記録を再利用したりしています。そうするために、発生したインシデント全ての発生記録および、その対応状況を共通のデータベース上に、リアルタイムで残すようにしています。以前は、担当する業務や、作業チーム毎にデータを持って、それぞれバラバラに管理をしていました。実際のところそれは、管理と呼べないレベルのものでした。そのため、担当者の判断で対応を後回しにしてしまったインシデントが、実は運用に重大なインパクトがある内容だったにも関わらず、誰も気付かないまま、時間だけが経過し、お客様に迷惑をかけてしまったりしたこともありました。また、運用をしている中で、たった今何が発生していて、いったい誰がそれを対応しているのか全てを知るには、担当者の間を聞いて回るしかなかったのです。情報共有が出来ていないという、良くある状況ですね。そんな状況から脱するために、私たちはまずは簡易的なＷｅｂアプリを構築し、情報を共有するための基盤を整備しました。実はそこからが大変でした、 ●完全な記録を残す習慣の無い組織に、仕事のやり方の順番を変え、 記録を残すようにした。 ●その記録を点検するサイクルを作った。 ●統計情報を分析するようにした。 ●何度もシステムの機能改善・機能追加を行った。このようなことを、ずっと繰り返してきました。現在でも改善は進行中で、管理の仕組みを更に強化する方向で計画中です。おかげで対応の漏れや、担当者不明のインシデントは、ほぼ無くなりました。また、クレームに繋がる対応の遅れについては、ここ最近私の記憶している中では発生しません。そのようになったのは、記録を残すことによって、さまざまなマネジメントが機能するようになったからだと思います。仕事の記録を残すことは、正直言って面倒臭いことです。慣れが必要な作業だと思います。しかし記録があるからこそ、マネジメントは機能する訳ですし、改善の要素もそこから見えてきます。もし仕事の記録を残していなければ、必要なものから確実に残すようにしましょう。残しているのであれば、ガンガン活用しましょう。★システム運用カイゼンのポイント★仕事の記録があってこそ、マネジメントは機能する。始めは面倒臭くても、記録を残すことに慣れよう。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年09月22日
コメント(0)
-
■人はミスは犯すもの
【システム運用カイゼン】（2004.09.21）**********************************************************************■先ずは日記**********************************************************************今日は、正に残暑。夕方から、あるシステム会社の社長様にお会いして、システム運用に関して、お話しをさせていただく予定です。楽しい話しになることを期待してます。**********************************************************************■人はミスは犯すもの**********************************************************************先日ある作業においてミスが発生し、お客様にご迷惑をおかけしてしまいました。ミスが発生した作業は、手順も確立し定型化されていました。投入するコマンドやＳＱＬは雛形が準備されており、作業を実施する場合は、その雛型をコピーし、可変となる情報部分のみを修正するだけになっていたのです。しかしミスは発生してしまったのです。そのミスの内容とは単純なもので、俗に言うケアレスミスでした。コピーした雛型に対し、必要な修正をしないまま作業を行っていたのです。普通に考えれば、あり得ないレベルのミスです。私もその話しを聞いた時に思わず、「馬鹿じゃないの！？」って言ってしまいました。しかし、人が犯してしまうミスには、こんなレベルのものが非常に多いのです。人間が行うことに完璧が無い以上、仕方ないことだと思います。だからこそ、ミスは発生するという前提で、手順を作ったり、確認を行ったり、あるいは検査・検証することが、重要になります。しかもミスが混入した工程から、次の工程に進む前に発見されれば、後工程を行う分のロスを防ぐことが出来ます。極力そうありたいですね。そうするためには、「やるべきことをやったか？」という確認だけでなく、作業にミスが混入していないかを、適切に評価出来る「検査・検証」が、工程毎に必要になります。一度に全ての作業をそのような形にすることは、絶対に不可能ですから、計画的に見直していきましょう。★システム運用カイゼンのポイント★人のやる作業に完璧は存在しない。ミスが見落されないようにするためには、検査・検証が重要です。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【システム運用カイゼン】Copyright (c) 2004 Tatsuro Fukuda. All rights reserved.━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2004年09月21日
コメント(0)
全107件 (107件中 1-50件目)
-
-
- 気になるニュース＆話題(Infoseekニ…
- 隠しきれないオトナの色気 32歳の元…
- (2025-11-24 04:00:05)
-
-
-
- つぶやき
- 大豆とひじきチーズサンド、クラムチ…
- (2025-11-24 00:00:14)
-
