アカウント名:
パスワード:
確かにドキュメントは大事ですね。分かっている人が、分かっている人向けに書いたドキュメントとか見るとうんざりすることも多いです。分かっている人しか見ないなら別にいいんですけど・・・。
せっかくわかるようにとマニュアル書いても『[F5]キーを押下と書いてあるからFキーと5キーを同時に押下したがだめだった』とか『[Enter]と書いてあるので"Enter"と入力したけど反応がない』とか『サーバラックの鍵がない』『(スクリーンセーバー効いてて)モニタの電源を入れても何も表示されない』
…という苦情まで開発メンバーまで回ってきたらうんざりすることも多いです。ま、メンテ要員がメンテする段になってこういう状態が発覚する組織そのものがヤバイ気もするけどw
こういうの見てて思うんだけど、海外でもそんな素人要員がメンテするようなところってあるんですかね?日本は(ド素人メンテ要員が生き残る)ガラパゴスのひとつになってるんじゃないかという気がするんだけど。
ありますよ。むしろ仕事を細分化する事で、スキルの低い人を安く雇えるので、積極的だと思います。特に監視業務は、そうですね。監視はあくまでも監視。異常を発見したら報告するのだけが仕事です。何かあった時のために問題分析要員とか別途います。たいていはそれで十分。センターから離れたところに派遣する要員は部品を交換する技能があれば十分で、その他の細々は遠隔でやります。まぁ、それだけの技能を持った人間をすら、揃えるのに苦労する訳なんですけど。
グッドウィルでもできるようにする必要があるのか #odstudy
odstudy#02に参加した人が補足しますよ。
odstudy#02のグループディスカッションでは、誰が読むためのドキュメントを作るべきなのか。という議論がありました。
1.仲間内で情報共有するためのドキュメント 2.技術力があまりない人に知識を共有させるためのドキュメント
という二通りの側面から議論がありました。
外出し(アウトソース)する場合は、あまり技術力のない人が読むドキュメントも必要だな。ということで、アウトソースで有名なところといえば「グッドウィル」システム運用を外出しする時、グッドウィルから派遣された素人さんでも判るような資料が必要だね。ということで、その名が出たのです。
ふむ、分かっている人が、分かっている人向けに書いたドキュメントは非常に分かり易いけどね。分かってない人が、分かってない人向けに書いたドキュメントは意味不明。
対象物に関して良く分かっていて、分からない人がどのぐらい分からないかも分かっている人が丁寧に書いたドキュメント → くどいけどほとんどの人に分かりやすい
対象物に関してよく分かっている人が、よく分かっている人向けに書いたドキュメント → よく分かっている人には最適。よく分かっていない人には理解できない。
対象物に関してよく分かっていない人が書いたドキュメント → ゴミ。場合によっては変な誤解を誘発するんで無いよりも悪い結果をもたらす。
2番目はよく分かってる人(勉強してる人)には「最適」なんだから、よく分かってない人(勉強してない人)がそれに文句を言うのはお門違い。勉強しないで1番目を要求する人に限って本人が書くのは3番だったりする。
だが待って欲しい。
それはもしかすると
「分かっていない人は触るな」
という警告を含んでいるのではないだろうか。
その通り。
故に、ドキュメントの対象読者を指定します。で、何かと試験を実施し、合格者は対象読者の仲間入り、などという運用をします。あぁ、これを全てのケースに適用できればどんなに楽か。私の環境では、部分適用までですが、まぁ、それなりにいい感じです。
分かっている人になる努力はしたくないということですね。
なるほどそういう考えもあるけど、緊急時に常に全てがわかっている人だけがいるわけじゃないからね~。難しいところです。
特にルールの無い雑な会社で、ドキュメント作って!と丸投げされて悩みつつ書いてたことがありますが、どこに基準を置くかは難しいです。
「ほんとーに何も分からない人」を想定すると、それこそ操作方法やコマンドを一言一句書かないといけないんでしょうが、そうするとOSやらブラウザやらをバージョンアップしただけで理解できなくなってしまいかねません。 ちゃんと改版されるなら別にいいんですが、そういう会社では基本放置されがちなので、メンテは期待できません。
分かってる人に読ませる前提なら、例えばFTPサーバーの情報はこれですんで、FTPで接続してください、と
作業を任せる対象の想定は本当に難しいですね。
以前、
・A、Bの2台のサーバの両方で・X、Yの2つの処理を実行する
と書いた手順書を渡したら、AでXのみを、BでYのみを実行されてトラブった経験があります。実行担当者(UNIXサーバでroot権限での管理経験(年単位)がある)に確認したところ、「AとB」「XとY」と目に入ったので1対1の作業だと勘違いした、とのことで、最終的には
・AでXとYを実行する・BでXとYを実行する
と書かなかった私が悪い、という結論に落ち着きました。
それ以降、どんな簡単なドキュメントでも、それを扱う可能性のある全員との読み合わせを必ず行い、こちらの意図を説明するようにしています。えらく大変ですけど、トラブるよりはマシと考えています。
# 実体験なのでさすがにACで
URIとID、パスワードがあれば、トレーニングを受けたあるべき知識のある人なら接続できるんじゃないの?
知識のないエンドユーザー相手ならわかるけど・・・。それとも、コの業界って、トレーニングもなしに保守の現場に放り込まれるの??
同意。SFTPやあれやこれ細かい設定が必要な環境ならまだしも、FTPを普通に使うだけで、いちいち細かいことまで教えられないと駄目ってどうかと思う。
例えば、ありがちな文字化けとかのトラブルだって、このサーバーの文字コードはEUC-JPです、とだけ伝えれば本来十分なはずでしょ? いちいちマニュアルに、FFFTPの使い方から、文字化けしないようにここはこのコンボボックスからEUC-JPを選んでください、程度まで書かなきゃいけないの? プロバイダーが会員に説明するようなマニュアルならともかく、データセンターやらでシステムの保守管理に使うようなマニュアルの話なのに?
そんなレベルの素人を送り込むな、教育してからにしろ、新たに雇うならそんな奴雇うなと声を大にして言いたい。 コストかけたくない?そんな会社、大きなトラブルでも起こして倒産しちまえ!
それを通り一片の教育しかしてないオペレータに要求する?まさに正気を疑うとしか。
そもそも、そんな人を配置することこそが、まさに正気を疑う行為だとしか言えませんね。 ど素人を集めてなんとか出来るほど保守は甘くないですよ。
逆だと思いますねあまり具体的なことを書きすぎるとあとで面倒なことが起きます指定ツールが公開止めたりしたら困るでしょうできるだけ抽象的に汎用性があったほうが良いですよぎちぎちに書いたドキュメントなどはちょっと手順が変更になっただけで使い物にならなくなるというのが良くあります
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
複雑化 (スコア:2)
確かにドキュメントは大事ですね。
分かっている人が、分かっている人向けに書いたドキュメントとか見るとうんざりすることも多いです。
分かっている人しか見ないなら別にいいんですけど・・・。
Re:複雑化 (スコア:2)
せっかくわかるようにとマニュアル書いても
『[F5]キーを押下と書いてあるからFキーと5キーを同時に押下したがだめだった』とか
『[Enter]と書いてあるので"Enter"と入力したけど反応がない』とか
『サーバラックの鍵がない』
『(スクリーンセーバー効いてて)モニタの電源を入れても何も表示されない』
…という苦情まで開発メンバーまで回ってきたらうんざりすることも多いです。
ま、メンテ要員がメンテする段になってこういう状態が発覚する組織そのものがヤバイ気もするけどw
Re: (スコア:0)
こういうの見てて思うんだけど、海外でもそんな素人要員がメンテするようなところってあるんですかね?
日本は(ド素人メンテ要員が生き残る)ガラパゴスのひとつになってるんじゃないかという気がするんだけど。
Re: (スコア:0)
ありますよ。
むしろ仕事を細分化する事で、スキルの低い人を安く雇えるので、積極的だと思います。
特に監視業務は、そうですね。
監視はあくまでも監視。異常を発見したら報告するのだけが仕事です。
何かあった時のために問題分析要員とか別途います。たいていはそれで十分。
センターから離れたところに派遣する要員は部品を交換する技能があれば十分で、その他の細々は遠隔でやります。
まぁ、それだけの技能を持った人間をすら、揃えるのに苦労する訳なんですけど。
Re:複雑化 (スコア:1)
Re: (スコア:0)
グッドウィルでもできるようにする必要があるのか #odstudy
Re: (スコア:0)
odstudy#02に参加した人が補足しますよ。
odstudy#02のグループディスカッションでは、
誰が読むためのドキュメントを作るべきなのか。という議論がありました。
1.仲間内で情報共有するためのドキュメント
2.技術力があまりない人に知識を共有させるためのドキュメント
という二通りの側面から議論がありました。
外出し(アウトソース)する場合は、あまり技術力のない人が読むドキュメントも必要だな。
ということで、アウトソースで有名なところといえば「グッドウィル」
システム運用を外出しする時、グッドウィルから派遣された素人さんでも判るような資料が必要だね。
ということで、その名が出たのです。
Re:複雑化 (スコア:1)
ふむ、分かっている人が、分かっている人向けに書いたドキュメントは非常に分かり易いけどね。
分かってない人が、分かってない人向けに書いたドキュメントは意味不明。
Re: (スコア:0)
対象物に関して良く分かっていて、分からない人がどのぐらい分からないかも分かっている人が丁寧に書いたドキュメント → くどいけどほとんどの人に分かりやすい
対象物に関してよく分かっている人が、よく分かっている人向けに書いたドキュメント → よく分かっている人には最適。よく分かっていない人には理解できない。
対象物に関してよく分かっていない人が書いたドキュメント → ゴミ。場合によっては変な誤解を誘発するんで無いよりも悪い結果をもたらす。
Re: (スコア:0)
2番目はよく分かってる人(勉強してる人)には「最適」なんだから、
よく分かってない人(勉強してない人)がそれに文句を言うのはお門違い。
勉強しないで1番目を要求する人に限って本人が書くのは3番だったりする。
Re:複雑化 (スコア:1)
だが待って欲しい。
それはもしかすると
「分かっていない人は触るな」
という警告を含んでいるのではないだろうか。
Re: (スコア:0)
その通り。
故に、ドキュメントの対象読者を指定します。で、何かと試験を実施し、合格者は対象読者の仲間入り、などという運用をします。
あぁ、これを全てのケースに適用できればどんなに楽か。
私の環境では、部分適用までですが、まぁ、それなりにいい感じです。
Re: (スコア:0)
分かっている人になる努力はしたくないということですね。
Re:複雑化 (スコア:2)
なるほど
そういう考えもあるけど、緊急時に常に全てがわかっている人だけがいるわけじゃないからね~。
難しいところです。
分からない人向けドキュメントは難しい (スコア:0)
特にルールの無い雑な会社で、ドキュメント作って!と丸投げされて悩みつつ書いてたことがありますが、どこに基準を置くかは難しいです。
「ほんとーに何も分からない人」を想定すると、それこそ操作方法やコマンドを一言一句書かないといけないんでしょうが、そうするとOSやらブラウザやらをバージョンアップしただけで理解できなくなってしまいかねません。
ちゃんと改版されるなら別にいいんですが、そういう会社では基本放置されがちなので、メンテは期待できません。
分かってる人に読ませる前提なら、例えばFTPサーバーの情報はこれですんで、FTPで接続してください、と
Re:分からない人向けドキュメントは難しい (スコア:1)
作業を任せる対象の想定は本当に難しいですね。
以前、
・A、Bの2台のサーバの両方で
・X、Yの2つの処理を実行する
と書いた手順書を渡したら、AでXのみを、BでYのみを実行されてトラブった経験があります。
実行担当者(UNIXサーバでroot権限での管理経験(年単位)がある)に確認したところ、
「AとB」「XとY」と目に入ったので1対1の作業だと勘違いした、とのことで、最終的には
・AでXとYを実行する
・BでXとYを実行する
と書かなかった私が悪い、という結論に落ち着きました。
それ以降、どんな簡単なドキュメントでも、それを扱う可能性のある全員との読み合わせを
必ず行い、こちらの意図を説明するようにしています。えらく大変ですけど、トラブるよりは
マシと考えています。
# 実体験なのでさすがにACで
Re: (スコア:0)
> 読む側としても、自分の使い慣れたFTPクライアントなりでやれば良くて、面倒がありません。
最悪です。
世の中にあるすべてのFTPクライアントがRFCの機能をすべて網羅していてバグがなければそれでいいのかもしれませんが、んなわけないので、あなたのドキュメントはあなたの仮定した(そして操作者は知らない)FTPクライアントを前提とした使えないドキュメントにしかなりません。
きちんと動作検証したFTPクライアントについて逐一操作を記述するか、最悪Windows標準のFTP.exeコマンドに投入するコマンドをベタ書きするかしてください。
Re: (スコア:0)
URIとID、パスワードがあれば、トレーニングを受けたあるべき知識のある人なら接続できるんじゃないの?
知識のないエンドユーザー相手ならわかるけど・・・。
それとも、コの業界って、トレーニングもなしに保守の現場に放り込まれるの??
Re: (スコア:0)
同意。SFTPやあれやこれ細かい設定が必要な環境ならまだしも、FTPを普通に使うだけで、いちいち細かいことまで教えられないと駄目ってどうかと思う。
例えば、ありがちな文字化けとかのトラブルだって、このサーバーの文字コードはEUC-JPです、とだけ伝えれば本来十分なはずでしょ?
いちいちマニュアルに、FFFTPの使い方から、文字化けしないようにここはこのコンボボックスからEUC-JPを選んでください、程度まで書かなきゃいけないの?
プロバイダーが会員に説明するようなマニュアルならともかく、データセンターやらでシステムの保守管理に使うようなマニュアルの話なのに?
そんなレベルの素人を送り込むな、教育してからにしろ、新たに雇うならそんな奴雇うなと声を大にして言いたい。
コストかけたくない?そんな会社、大きなトラブルでも起こして倒産しちまえ!
Re: (スコア:0)
マジありえません。というかFTPなんて前世紀に捨ててくるべきウンコです。ftp.exeでさえロクにRFCに従ってないバグ満載アプリなんですが、時間の限られたメンテ時にいちいちMSDN引いて障害の切り分けさせるんですか?それを通り一片の教育しかしてないオペレータに要求する?まさに正気を疑うとしか。
Re: (スコア:0)
それを通り一片の教育しかしてないオペレータに要求する?まさに正気を疑うとしか。
そもそも、そんな人を配置することこそが、まさに正気を疑う行為だとしか言えませんね。
ど素人を集めてなんとか出来るほど保守は甘くないですよ。
Re: (スコア:0)
逆だと思いますね
あまり具体的なことを書きすぎるとあとで面倒なことが起きます
指定ツールが公開止めたりしたら困るでしょう
できるだけ抽象的に汎用性があったほうが良いですよ
ぎちぎちに書いたドキュメントなどはちょっと手順が変更になっただけで使い物にならなくなるというのが良くあります