アカウント名:
パスワード:
ヒューマンファクターなんてガン無視で、自分がやれと言われたら発狂するような一貫性のない手間ばかり多い操作でも「マニュアルに書いておけばいい」って風潮は何なんだろうね。
日本独特とも言われる「SIer」って奴がクソなだけな気がするんだけど。
「マニュアル」という単語に脊髄反射ですか?
この場合、「何をやればいい」ではなく「こういう場合こうなる」っていう事前情報としてのマニュアル記載に誤りがあったってことでしょ
それにより行われるはずだった事前準備がなくなれば、実際問題が起きた時の初動が遅くなるまた、自動切替が行われない場合がある旨正しく書いてあった場合、その記述を見て「自動切替になるように設定変更して」と依頼することもできる
で、今度はパターン漏れがないように全パターン網羅して記述して、マニュアルが1万ページ超えるような状態になったとしても
「マニュアルに書いてありますよね」
って言うんですよね。
委託先がそんな資料作ってくれるなら喜んでもらいますよ。そうとうリスクが減らせます。
そんなもので喜ぶのは客を見てない人の発想。
市場で受け入れられているのはドキュメントもまともに作らない、作ってても現状優先とか免責事項を入れてメンテしない、サポートすらコミュニティに丸投げって米系巨大ITという現実。
いいものさえ作れば余計なものは不要。
あー、プロ対プロの話をしてるかと思った。素人向けね。富士通や東証がこの場合のプロかどうかは知らないけど。
品質管理を考えた場合、文書やエビデンスがないと話にならないんだよ。たとえば今回もマニュアルがあったから、マニュアルが間違っていましたと言えて、マニュアルをなおしますとか言う話になるわけ。
さらにいうとそんなマニュアルが出てきた原因とその改善策は? とかなって手順書とか教育を改善しますとかなると、既存の手順書や教育の内容とその既存のものを使用して今回のマニュアルを作ったというエビデンスを出せとかなるわけね。そもそも手順書や教育を使ってなかったらそれを改善しても改善策にならないわけだから。
いいものであっても0 FITとかにはならないんだからさ。今回は品質問題であって、性能(いいもの)かどうかは関係ないんだよ。
プロ対プロの取引でも運用は素人がやるってのが大規模システム開発の前提条件だけど。ヒューマンエラー起こす「仕様」作って「マニュアルに書いてあるじゃん」って言い訳は通用せんぞ。
そもそも今回のは(設定項目の動作説明という最小限の)マニュアルが間違ってたケースの話ってわかってるか?それに、最終運用者が素人でも、その素人が直接プロ対プロ用のマニュアル読むのはおかしい。最終運用者に運用を引き継ぐ前にその運用現場の条件における素人向けのマニュアルをプロが作るべき。であればその段階でプロが問題を指摘すれば良い。素人がプロ向けマニュアルの記載を読み落とすリスクなんてものが発生してる時点で、フローに問題あり。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
マニュアルに書けばいいという風潮 (スコア:0)
ヒューマンファクターなんてガン無視で、自分がやれと言われたら発狂するような
一貫性のない手間ばかり多い操作でも「マニュアルに書いておけばいい」って
風潮は何なんだろうね。
日本独特とも言われる「SIer」って奴がクソなだけな気がするんだけど。
Re: (スコア:0)
「マニュアル」という単語に脊髄反射ですか?
この場合、「何をやればいい」ではなく「こういう場合こうなる」っていう事前情報としてのマニュアル記載に誤りがあったってことでしょ
それにより行われるはずだった事前準備がなくなれば、実際問題が起きた時の初動が遅くなる
また、自動切替が行われない場合がある旨正しく書いてあった場合、その記述を見て「自動切替になるように設定変更して」と依頼することもできる
Re: (スコア:0)
で、今度はパターン漏れがないように全パターン網羅して記述して、
マニュアルが1万ページ超えるような状態になったとしても
「マニュアルに書いてありますよね」
って言うんですよね。
Re: (スコア:0)
委託先がそんな資料作ってくれるなら喜んでもらいますよ。
そうとうリスクが減らせます。
Re: (スコア:0)
そんなもので喜ぶのは客を見てない人の発想。
市場で受け入れられているのはドキュメントもまともに作らない、
作ってても現状優先とか免責事項を入れてメンテしない、
サポートすらコミュニティに丸投げって米系巨大ITという現実。
いいものさえ作れば余計なものは不要。
Re: (スコア:0)
あー、プロ対プロの話をしてるかと思った。素人向けね。
富士通や東証がこの場合のプロかどうかは知らないけど。
品質管理を考えた場合、文書やエビデンスがないと話にならないんだよ。
たとえば今回もマニュアルがあったから、マニュアルが間違っていましたと
言えて、マニュアルをなおしますとか言う話になるわけ。
さらにいうとそんなマニュアルが出てきた原因とその改善策は? とかなって
手順書とか教育を改善しますとかなると、既存の手順書や教育の内容と
その既存のものを使用して今回のマニュアルを作ったというエビデンスを
出せとかなるわけね。そもそも手順書や教育を使ってなかったらそれを
改善しても改善策にならないわけだから。
いいものであっても0 FITとかにはならないんだからさ。
今回は品質問題であって、性能(いいもの)かどうかは関係ないんだよ。
Re:マニュアルに書けばいいという風潮 (スコア:0)
プロ対プロの取引でも運用は素人がやるってのが大規模システム開発の前提条件だけど。
ヒューマンエラー起こす「仕様」作って「マニュアルに書いてあるじゃん」って言い訳は通用せんぞ。
Re: (スコア:0)
そもそも今回のは(設定項目の動作説明という最小限の)マニュアルが間違ってたケースの話ってわかってるか?
それに、最終運用者が素人でも、その素人が直接プロ対プロ用のマニュアル読むのはおかしい。
最終運用者に運用を引き継ぐ前にその運用現場の条件における素人向けのマニュアルをプロが作るべき。
であればその段階でプロが問題を指摘すれば良い。
素人がプロ向けマニュアルの記載を読み落とすリスクなんてものが発生してる時点で、フローに問題あり。