アカウント名:
パスワード:
ヒューマンファクターなんてガン無視で、自分がやれと言われたら発狂するような一貫性のない手間ばかり多い操作でも「マニュアルに書いておけばいい」って風潮は何なんだろうね。
日本独特とも言われる「SIer」って奴がクソなだけな気がするんだけど。
そもそもこの設定項目、富士通関係なく、NetApp なんだけど。
今まで通りのやり方でやる→失敗は作業者のせい新しいやり方に変更する→失敗は変更したやつのせいどっちを選ぶかは自明じゃん?
なんかトラブったら営業がへーこらすれば済む程度のシステムなんざそれでいいんだよそれになまじ自動化なんかして人手がかからなくなったら、売り上げさがっちゃうじゃんこれが極めて合理的な判断なんだよ
>それになまじ自動化なんかして人手がかからなくなったら、売り上げさがっちゃうじゃん
大手SIがこういうことやるから、海の物とも山の物ともつかぬ中小クラウド業者が奪おうとするわけじゃん?で、コストしか見てない経営層が騙されて既存契約切って「移行」するわけじゃん?で、言うことは大手の受け売りなので立派でもまともな人材が揃えられていない「中小」ばかりなので、導入後に炎上するわけじゃん?
合理的か?誰が幸せになってるのさ?
合理的にやれば幸せになるはずだ、ってのは全く合理的な考えじゃないな
「マニュアル」という単語に脊髄反射ですか?
この場合、「何をやればいい」ではなく「こういう場合こうなる」っていう事前情報としてのマニュアル記載に誤りがあったってことでしょ
それにより行われるはずだった事前準備がなくなれば、実際問題が起きた時の初動が遅くなるまた、自動切替が行われない場合がある旨正しく書いてあった場合、その記述を見て「自動切替になるように設定変更して」と依頼することもできる
で、今度はパターン漏れがないように全パターン網羅して記述して、マニュアルが1万ページ超えるような状態になったとしても
「マニュアルに書いてありますよね」
って言うんですよね。
委託先がそんな資料作ってくれるなら喜んでもらいますよ。そうとうリスクが減らせます。
そんなもので喜ぶのは客を見てない人の発想。
市場で受け入れられているのはドキュメントもまともに作らない、作ってても現状優先とか免責事項を入れてメンテしない、サポートすらコミュニティに丸投げって米系巨大ITという現実。
いいものさえ作れば余計なものは不要。
あー、プロ対プロの話をしてるかと思った。素人向けね。富士通や東証がこの場合のプロかどうかは知らないけど。
品質管理を考えた場合、文書やエビデンスがないと話にならないんだよ。たとえば今回もマニュアルがあったから、マニュアルが間違っていましたと言えて、マニュアルをなおしますとか言う話になるわけ。
さらにいうとそんなマニュアルが出てきた原因とその改善策は? とかなって手順書とか教育を改善しますとかなると、既存の手順書や教育の内容とその既存のものを使用して今回のマニュアルを作ったというエビデンスを出せとかなるわけね。そもそも手順書や教育を使ってなかったらそれを改善しても改善策にならないわけだから。
いいものであっても0 FITとかにはならないんだからさ。今回は品質問題であって、性能(いいもの)かどうかは関係ないんだよ。
プロ対プロの取引でも運用は素人がやるってのが大規模システム開発の前提条件だけど。ヒューマンエラー起こす「仕様」作って「マニュアルに書いてあるじゃん」って言い訳は通用せんぞ。
失敗する奴はプロじゃないみたいな
そもそも今回のは(設定項目の動作説明という最小限の)マニュアルが間違ってたケースの話ってわかってるか?それに、最終運用者が素人でも、その素人が直接プロ対プロ用のマニュアル読むのはおかしい。最終運用者に運用を引き継ぐ前にその運用現場の条件における素人向けのマニュアルをプロが作るべき。であればその段階でプロが問題を指摘すれば良い。素人がプロ向けマニュアルの記載を読み落とすリスクなんてものが発生してる時点で、フローに問題あり。
お前仕事で「マニュアルはページ数が多いからちゃんと読んでません」って言ってるの?
逆に聞くが、SIが出してくる膨大なマニュアルを読んで理解してる奴なんているの?レビュー記録表が誤字脱字の指摘ばかりで技術的なツッコミ皆無って現場も多いんだが。
> マニュアルを読んで理解してる奴なんているの?僕はマニュアル読んで理解するってことしてません、的なことを言われましても……
私は自分の設計する機能と制限事項は絶対読むね大抵ろくでもねぇ注意事項が書いてあるもの
逆にあれかな、問題起こったときに「マニュアルに書いてあんじゃん」って突っ込み入れると何も言えずに黙り決め込むクソベンダーの中の人でもやってるの?
残念ながら読まないやつが圧倒的多数なんですよ、客もベンダも誰も読まない。だから誤字脱字のオンパレードってそういうこと。
そもそも読ませるつもりもないしな。間違い探しみたいなコピペ増殖ドキュメントを二束三文で買ってきた偽装請負に作らせてるとか常識で考えておかしい体制がまかり通ってるし。
マニュアルをちゃんと読めばわかるのかもしれないけど体系的網羅的に書かれているので(マニュアルに書いとけば免責?みたいなのも含めて)、自分のやりたいことが実はコマンド1発だったとしてもマニュアルだと広範囲に読まないと見つけられないみたいなことは多々あって、そんなに時間をかけられないからQiitaみたいなのがあったりして。。。というのが現実だと思う。
> マニュアルが1万ページ超えるような状態になったとしても> 「マニュアルに書いてありますよね」
CPUのエラッタ情報なんかはそういう状況なんじゃないっけ。NASのマニュアルは1万ページないと思うけど、機器の重要度はユーザーによってCPU以上はいえるだろう。
パターン漏れじゃなくて設定項目単独での仕様の説明が大嘘だったんだが。
現行ページ数のドキュメントでも更新漏れ起こすような所が、複合での挙動を無意味に列挙するドキュメントなんて作った日にはより更新漏れが増えるんじゃねぇかな……
マニュアル対応を批判するような文脈はお呼びじゃないよ。
うん、今回のマニュアルって手順書よりもどちらかというと取説だよね。記事をしっかり読めば分かるのに、元コメの人って取説読まずに失敗するタイプだったりしないかしらん。
まあ受け入れテストをどこまでやるかとかそういう話ですかね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
マニュアルに書けばいいという風潮 (スコア:0)
ヒューマンファクターなんてガン無視で、自分がやれと言われたら発狂するような
一貫性のない手間ばかり多い操作でも「マニュアルに書いておけばいい」って
風潮は何なんだろうね。
日本独特とも言われる「SIer」って奴がクソなだけな気がするんだけど。
Re:マニュアルに書けばいいという風潮 (スコア:1)
そもそもこの設定項目、富士通関係なく、NetApp なんだけど。
Re: (スコア:0)
今まで通りのやり方でやる→失敗は作業者のせい
新しいやり方に変更する→失敗は変更したやつのせい
どっちを選ぶかは自明じゃん?
なんかトラブったら営業がへーこらすれば済む程度のシステムなんざそれでいいんだよ
それになまじ自動化なんかして人手がかからなくなったら、売り上げさがっちゃうじゃん
これが極めて合理的な判断なんだよ
Re: (スコア:0)
>それになまじ自動化なんかして人手がかからなくなったら、売り上げさがっちゃうじゃん
大手SIがこういうことやるから、海の物とも山の物ともつかぬ中小クラウド業者が奪おうとするわけじゃん?
で、コストしか見てない経営層が騙されて既存契約切って「移行」するわけじゃん?
で、言うことは大手の受け売りなので立派でもまともな人材が揃えられていない「中小」ばかりなので、導入後に炎上するわけじゃん?
合理的か?誰が幸せになってるのさ?
Re: (スコア:0)
合理的にやれば幸せになるはずだ、ってのは
全く合理的な考えじゃないな
Re: (スコア:0)
「マニュアル」という単語に脊髄反射ですか?
この場合、「何をやればいい」ではなく「こういう場合こうなる」っていう事前情報としてのマニュアル記載に誤りがあったってことでしょ
それにより行われるはずだった事前準備がなくなれば、実際問題が起きた時の初動が遅くなる
また、自動切替が行われない場合がある旨正しく書いてあった場合、その記述を見て「自動切替になるように設定変更して」と依頼することもできる
Re: (スコア:0)
で、今度はパターン漏れがないように全パターン網羅して記述して、
マニュアルが1万ページ超えるような状態になったとしても
「マニュアルに書いてありますよね」
って言うんですよね。
Re: (スコア:0)
委託先がそんな資料作ってくれるなら喜んでもらいますよ。
そうとうリスクが減らせます。
Re: (スコア:0)
そんなもので喜ぶのは客を見てない人の発想。
市場で受け入れられているのはドキュメントもまともに作らない、
作ってても現状優先とか免責事項を入れてメンテしない、
サポートすらコミュニティに丸投げって米系巨大ITという現実。
いいものさえ作れば余計なものは不要。
Re: (スコア:0)
あー、プロ対プロの話をしてるかと思った。素人向けね。
富士通や東証がこの場合のプロかどうかは知らないけど。
品質管理を考えた場合、文書やエビデンスがないと話にならないんだよ。
たとえば今回もマニュアルがあったから、マニュアルが間違っていましたと
言えて、マニュアルをなおしますとか言う話になるわけ。
さらにいうとそんなマニュアルが出てきた原因とその改善策は? とかなって
手順書とか教育を改善しますとかなると、既存の手順書や教育の内容と
その既存のものを使用して今回のマニュアルを作ったというエビデンスを
出せとかなるわけね。そもそも手順書や教育を使ってなかったらそれを
改善しても改善策にならないわけだから。
いいものであっても0 FITとかにはならないんだからさ。
今回は品質問題であって、性能(いいもの)かどうかは関係ないんだよ。
Re: (スコア:0)
プロ対プロの取引でも運用は素人がやるってのが大規模システム開発の前提条件だけど。
ヒューマンエラー起こす「仕様」作って「マニュアルに書いてあるじゃん」って言い訳は通用せんぞ。
Re: (スコア:0)
失敗する奴はプロじゃない
みたいな
Re: (スコア:0)
そもそも今回のは(設定項目の動作説明という最小限の)マニュアルが間違ってたケースの話ってわかってるか?
それに、最終運用者が素人でも、その素人が直接プロ対プロ用のマニュアル読むのはおかしい。
最終運用者に運用を引き継ぐ前にその運用現場の条件における素人向けのマニュアルをプロが作るべき。
であればその段階でプロが問題を指摘すれば良い。
素人がプロ向けマニュアルの記載を読み落とすリスクなんてものが発生してる時点で、フローに問題あり。
Re: (スコア:0)
お前仕事で「マニュアルはページ数が多いからちゃんと読んでません」って言ってるの?
Re: (スコア:0)
逆に聞くが、SIが出してくる膨大なマニュアルを読んで理解してる奴なんているの?
レビュー記録表が誤字脱字の指摘ばかりで技術的なツッコミ皆無って現場も多いんだが。
Re: (スコア:0)
> マニュアルを読んで理解してる奴なんているの?
僕はマニュアル読んで理解するってことしてません、的なことを言われましても……
私は自分の設計する機能と制限事項は絶対読むね
大抵ろくでもねぇ注意事項が書いてあるもの
逆にあれかな、問題起こったときに「マニュアルに書いてあんじゃん」って突っ込み入れると何も言えずに黙り決め込むクソベンダーの中の人でもやってるの?
Re: (スコア:0)
残念ながら読まないやつが圧倒的多数なんですよ、客もベンダも誰も読まない。
だから誤字脱字のオンパレードってそういうこと。
Re: (スコア:0)
そもそも読ませるつもりもないしな。
間違い探しみたいなコピペ増殖ドキュメントを
二束三文で買ってきた偽装請負に作らせてるとか
常識で考えておかしい体制がまかり通ってるし。
Re: (スコア:0)
マニュアルをちゃんと読めばわかるのかもしれないけど
体系的網羅的に書かれているので(マニュアルに書いとけば免責?みたいなのも含めて)、
自分のやりたいことが実はコマンド1発だったとしてもマニュアルだと広範囲に読まないと見つけられない
みたいなことは多々あって、そんなに時間をかけられないからQiitaみたいなのがあったりして。。。
というのが現実だと思う。
Re: (スコア:0)
> マニュアルが1万ページ超えるような状態になったとしても
> 「マニュアルに書いてありますよね」
CPUのエラッタ情報なんかはそういう状況なんじゃないっけ。
NASのマニュアルは1万ページないと思うけど、機器の重要度はユーザーによってCPU以上はいえるだろう。
Re: (スコア:0)
パターン漏れじゃなくて設定項目単独での仕様の説明が大嘘だったんだが。
現行ページ数のドキュメントでも更新漏れ起こすような所が、
複合での挙動を無意味に列挙するドキュメントなんて作った日には
より更新漏れが増えるんじゃねぇかな……
マニュアル対応を批判するような文脈はお呼びじゃないよ。
Re: (スコア:0)
うん、今回のマニュアルって手順書よりもどちらかというと取説だよね。
記事をしっかり読めば分かるのに、元コメの人って取説読まずに失敗するタイプだったりしないかしらん。
Re: (スコア:0)
まあ受け入れテストをどこまでやるかとかそういう話ですかね