<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>System Clinic &#187; 救急室(4)－問合せ</title>
	<atom:link href="http://clinic.acc-s.com/?cat=24&#038;feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://clinic.acc-s.com</link>
	<description>　－　悩めるシステム運用に関するサイト　－</description>
	<lastBuildDate>Sun, 13 Dec 2015 06:05:15 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.4</generator>
		<item>
		<title>救急室(4)－ログ問い合わせ</title>
		<link>http://clinic.acc-s.com/?p=464</link>
		<comments>http://clinic.acc-s.com/?p=464#comments</comments>
		<pubDate>Mon, 06 Feb 2012 13:15:00 +0000</pubDate>
		<dc:creator>所長</dc:creator>
				<category><![CDATA[救急室(4)－問合せ]]></category>

		<guid isPermaLink="false">http://clinic.acc-s.com/?p=464</guid>
		<description><![CDATA[プログラム構造の中で、多くの人が携わりコミュニケーションミスにより、不具合が発生しやすい事を述べました。 では、システムからログを取得し、サポートベンダーに問い合わせをする時に何が必要かについて触れます。 サポート担当者とのギャップ サポート担当者は全てを知っているという誤り サポート担当者は理解していなくても、管理できているという誤り サポートベンダーは何もわかっていないという誤り 開発現場の人が担当している場合、どのような状況下で開発が行われているかを知っていて、また、開発では顧客と折衝する立場であれば、さらに顧客の気持ちも理解できる事から、解決にいたらなかったとしても、イライラさせる事はありません。 ただ、開発現場の人がサポート窓口に立つことは少なく、保守専任の人が担当する事が多いです。この場合、残念ながら、決められた手順で淡々とこなすしかありません。顧客担当は目の前で、事象を見ておりこれは、あそこがおかしいのではないかといった当たりが、ついたりするのですが、保守専任の場合は、いくら目の前の事象を話しても、理解してもらう事が難しいです。 保守業務がルーチンワークになっている場合は顕著に表れ、サポート担当者は発生している分野から専任技術者（または、メーカー）への橋渡しに特化します。専任技術者は、複数の顧客システムを問い扱いますので、目に見える事象を説明されても、わかりません。ログを取得し、そのログを解析する事を業務としています。 そして、このサポート担当者と専任技術者にも、コミュニケーションミスが存在します。プログラムの中身も、保守業務の中身も人がやっている以上、かわらないのです。私が、顧客側の運用担当者の時、イライラする事はありません。スペシャルな事(*1)を除き、淡々とこなすのが最良と思っています。話は戻って、サポート担当者は顧客からプレッシャーを与えられ、専任技術者は障害になれています。このギャップが、管理という側面を壊します。お互いの業務にプロフェッショナルを求めるからです。顧客に叱られてなんぼだろ、とか、専任なんだからさっさと原因みつけろというのは最悪ですが、溝ができやすい環境です。特に専任技術者はあらゆる可能性を考えたり、前述のログを見過ごしてしまう危険性がある為、緊急対応であっても、急げない理由があります。 そんな中で、サポート担当が理解している事は、この専任技術者だったら大丈夫。このメーカーへの問い合わせだったら大丈夫。逆に、あの専任技術者や、メーカーはだめだ。そういう事は、よく理解しています。私がサポート担当の時、まだ、顧客に叱られる前から本当に申し訳ないという態度で接していました。電話の対応で顧客が察する事も多々ありました。システムを構築する時に「選定」という工程があります。どの機器、OS、ミドル、開発ベンダーを使って構築するかを選ぶ工程です。古いものを使えば、実績があるのですが、この選択はあまりなくて、新しいものを使うのが主流です。新しいものには、選定ミスというリスクが伴います。暗い話になりましたが、保守サポートはやり方によっては、最良の方法があります。これは、いずれこのサイトでご紹介します。 そして一番肝心なのは、サポート担当のいう事を鵜呑みにしては、いけないという事です。なんどもコミュニケーションミスを言ってきましたので、当たり前の事です。どのログから判断したのか、そのログの意味はなにか。なぜ、問題のログなのか、似たようなログが他のタイミングででているが、何が違うのか。説明には一過性を求めますが、プログラムの構造も、人もこんな状況なので、途中で変わってしまう事があります。矛盾している回答は受けいれがたいのですが、あまりにもきれいにまとまっている説明は、どうも信用ができません。サポート担当は、障害から早く逃れたい為に綺麗にまとめようとする節がありますが、まとめるのは、サポート担当ではなく、顧客であるべきだと思います。サポート担当は顧客がまとめられるまで、仮定や可能性、個々の事象やログに対し説明すべきです。 以前、先輩にコンピュータが不具合になる事はない。そのように作った人が不具合を生んでいる。と言われた事があります。言いすぎかもしれませんが、矛盾のない人はいないでしょう。だから、障害説明での矛盾は、許しています。問題はその矛盾が、どれほどのものか、そこの矛盾を回避する事での他への影響はどれほどか。発生頻度、障害レベルも含め総合的に判断する必要があります。 ——————————————————————————– (*1)スペシャルな事は、取締や社長からクレームを入れるというものです。一担当者がキレても、あまり変わりません。 &#160;]]></description>
			<content:encoded><![CDATA[<p>プログラム構造の中で、多くの人が携わりコミュニケーションミスにより、不具合が発生しやすい事を述べました。</p>
<p>では、システムからログを取得し、サポートベンダーに問い合わせをする時に何が必要かについて触れます。</p>
<p>サポート担当者とのギャップ</p>
<ol>
<li>サポート担当者は全てを知っているという誤り</li>
<li>サポート担当者は理解していなくても、管理できているという誤り</li>
<li>サポートベンダーは何もわかっていないという誤り</li>
</ol>
<p>開発現場の人が担当している場合、どのような状況下で開発が行われているかを知っていて、また、開発では顧客と折衝する立場であれば、さらに顧客の気持ちも理解できる事から、解決にいたらなかったとしても、イライラさせる事はありません。</p>
<p>ただ、開発現場の人がサポート窓口に立つことは少なく、保守専任の人が担当する事が多いです。この場合、残念ながら、決められた手順で淡々とこなすしかありません。顧客担当は目の前で、事象を見ておりこれは、あそこがおかしいのではないかといった当たりが、ついたりするのですが、保守専任の場合は、いくら目の前の事象を話しても、理解してもらう事が難しいです。</p>
<p>保守業務がルーチンワークになっている場合は顕著に表れ、サポート担当者は発生している分野から専任技術者（または、メーカー）への橋渡しに特化します。専任技術者は、複数の顧客システムを問い扱いますので、目に見える事象を説明されても、わかりません。ログを取得し、そのログを解析する事を業務としています。</p>
<p>そして、このサポート担当者と専任技術者にも、コミュニケーションミスが存在します。プログラムの中身も、保守業務の中身も人がやっている以上、かわらないのです。私が、顧客側の運用担当者の時、イライラする事はありません。スペシャルな事(*1)を除き、淡々とこなすのが最良と思っています。話は戻って、サポート担当者は顧客からプレッシャーを与えられ、専任技術者は障害になれています。このギャップが、管理という側面を壊します。お互いの業務にプロフェッショナルを求めるからです。顧客に叱られてなんぼだろ、とか、専任なんだからさっさと原因みつけろというのは最悪ですが、溝ができやすい環境です。特に専任技術者はあらゆる可能性を考えたり、前述のログを見過ごしてしまう危険性がある為、緊急対応であっても、急げない理由があります。</p>
<p>そんな中で、サポート担当が理解している事は、この専任技術者だったら大丈夫。このメーカーへの問い合わせだったら大丈夫。逆に、あの専任技術者や、メーカーはだめだ。そういう事は、よく理解しています。私がサポート担当の時、まだ、顧客に叱られる前から本当に申し訳ないという態度で接していました。電話の対応で顧客が察する事も多々ありました。システムを構築する時に「選定」という工程があります。どの機器、OS、ミドル、開発ベンダーを使って構築するかを選ぶ工程です。古いものを使えば、実績があるのですが、この選択はあまりなくて、新しいものを使うのが主流です。新しいものには、選定ミスというリスクが伴います。暗い話になりましたが、保守サポートはやり方によっては、最良の方法があります。これは、いずれこのサイトでご紹介します。</p>
<p>そして一番肝心なのは、サポート担当のいう事を鵜呑みにしては、いけないという事です。なんどもコミュニケーションミスを言ってきましたので、当たり前の事です。どのログから判断したのか、そのログの意味はなにか。なぜ、問題のログなのか、似たようなログが他のタイミングででているが、何が違うのか。説明には一過性を求めますが、プログラムの構造も、人もこんな状況なので、途中で変わってしまう事があります。矛盾している回答は受けいれがたいのですが、あまりにもきれいにまとまっている説明は、どうも信用ができません。サポート担当は、障害から早く逃れたい為に綺麗にまとめようとする節がありますが、まとめるのは、サポート担当ではなく、顧客であるべきだと思います。サポート担当は顧客がまとめられるまで、仮定や可能性、個々の事象やログに対し説明すべきです。</p>
<p>以前、先輩にコンピュータが不具合になる事はない。そのように作った人が不具合を生んでいる。と言われた事があります。言いすぎかもしれませんが、矛盾のない人はいないでしょう。だから、障害説明での矛盾は、許しています。問題はその矛盾が、どれほどのものか、そこの矛盾を回避する事での他への影響はどれほどか。発生頻度、障害レベルも含め総合的に判断する必要があります。</p>
<p>——————————————————————————–</p>
<p>(*1)スペシャルな事は、取締や社長からクレームを入れるというものです。一担当者がキレても、あまり変わりません。</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://clinic.acc-s.com/?feed=rss2&#038;p=464</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
