アカウント名:
パスワード:
技術的に失敗することが明らかなんだけど、上司や顧客にそれを言っても理解しない（主に知識が足りないので理解できない）ような時に、警告はしたよっていう証拠を残しておくこと。また、そのままプロジェクトが邁進した結果、結合テストやシステムテストあたりで問題点が発覚した時に、責任を回避したり、最悪、炎上した案件から逃げ出すための方法を用意しておくこと。これに尽きると思う、個人的には。なんかもう慣れてきたけどね。
サイジングとかやってるとたまに起きる。「それじゃ性能足りねーよ」って言ってるのに予算ありきでシステム組んで、いざ本番で負荷かかりすぎてマトモに動かないとか。本来、同時に使うことなんか想定されてない複数のミドルなんかを１つのサーバにインストールした挙げ句、「それぞれの動作環境は足りてるのになんで書いてある処理性能が出ないんだ」って言い出したり。
>主に知識が足りないので理解できない
まぁ、こんな言い方するヤツは、たいてい自己満足な説明しかできていないんですけどね。相手の理解力に言及する前に、自分の説明力不足の可能性を考えて改善してみたら？「知識が足りないので理解できない」人に、自分の提案を受け入れてもらう方法を、もっと考えてみたら？
そうすると、もっと良いエンジニアになるよ！
つい最近の事案だとだな。
「応用情報技術者を持ってます」というチームリーダーが、「ハードの予算足りないからDBサーバーをシングルクラスタにしちゃおうぜ」って言う。（別に資格持ってるのはフカシじゃないっぽい。だから余計困るんだが。）そして「耐障害性下がりますよ？」って言うと「なんで？」って言う。「冗長化」の理由を理解してねーんだ。「なんとなく冗長化するのがお約束みたいだから冗長化で設計してたけど、今までの固定観念を取り払った斬新な設計によりコストダウンを達成した俺かっけー」ぐらいにしか思ってないんだぜ？＃ちなみに某大手SIerの社員な、そいつ
そんなヤツにどんな説明しろっていうんだよ……。説明力不足とかそういうレベルじゃねーぞ？
客は兎も角、技術者として動いてる管理職なら「最低限知らなきゃいけないこと」ってのはあるだろ。その「最低限知らなきゃいけないこと」を知らないヤツってのは、それを理解する能力が無いから知らないだけなんだよ。ついでに言えば、自分が無知であるという自覚がないし、指摘されても無知であることを理解しないし、だから学ぼう、相手の言うことを理解しよう、という意志もない。
笑い話にしか見えない人も居るだろうが、現実問題、そういう「上司」ってヤツも居るんだ、多くはないだろうけどね。ついでに言うと、そういう無茶を強行した部分のカバーを現場の下の方が死ぬ気で何とかしたり、営業が死ぬ気で客を納得させて丸く収めるから、結果としては「コストダウンに成功したチームリーダー」って記録だけが残る。それが現実だ。
「良いエンジニアになる」キャリアパス考えたら、こんな馬鹿な上司がつくような案件にかかわらずに済む道を模索する方が先だと理解はしてる。＃でもまぁ、しがらみとか色々あってそれができんのよ
立派なエンジニアじゃない。要求されていない冗長化を、さも必要そうに進めてくるエンジニアにくらべればね。いまどきのハードで耐障害性云々だから冗長化しましょうってことを行ってくるやつは信用できないね。
本当に耐障害性が必要なら、そのチームリーダーを論理的に説得できるはず。できないのなら、そのプロジェクトは、耐障害性は二の次との判断がされているのだから、だまって従え。
本当に耐障害性が必要なら、そのチームリーダーを論理的に説得できるはず。
耐障害性の必要性の有無以前に、「ハード２台並べてれば、片方が死んでももう片方が生き残るから耐障害性が上がるよね」って理屈すら理解してない馬鹿に理論的な説明とか通用するの？
いまどきのハードで耐障害性云々だから冗長化しましょうってことを行ってくるやつは信用できないね。
金融系のシステム屋では普通に出る話だけどなぁ。「奴らはCOBOLerであってエンジニアでは
>耐障害性の必要性の有無以前に、「ハード２台並べてれば、片方が死んでももう片方が生き残るから耐障害性が上がるよね」って理屈すら理解してない馬鹿に理論的な説明とか通用するの？
その程度の理解で理論的に説明している気になっている時点でだめだね。いまどきその手の説明で納得してもらえるくらいなら苦労しませんよ。
＞金融系のシステム屋では普通に出る話だけどなぁ。＞「奴らはCOBOLerであってエンジニアではない、だから信用できない」とか言われたら地味に反論に困るけれども。
金融系ならシステム屋じゃなくて、ハード屋が安心設計してくれるインフラをつかえばいい。
> 必要のない耐障害性をごり押ししてくる奴に限って耐障害性の要不要を決定するのは、システム開発者じゃない。お客だ。「耐障害性を削ると１ヶ月システム停止が発生するけど、それで問題ありません」と書いてあるペーパーをお客から貰うんだね。お客からのオーダー無しに耐障害性を削るのは莫迦のやることだ。
> ハードが心配なら、監視をきちんとして、予防交換をした方が、下手な2重化とかするより、よほど安定運用ができるってことを知っていた方がいいぞ。これらはどれも耐障害性確保の要素であって、対立する要因ではないわな。多重化して監視しないも、多重化しないで監視するのも、共に莫迦のやること。故障に予兆が無いもんもあるんだけど、どうやって故障の予兆を監視でとらえる事が出来るんだ？大体、多重化に難癖をつけるお客や開発側のマネジメントが、それ以上に金が掛かるPMや監視をやるとも思えないけどね。
> シンプルイズベストな対応を考えてくれって言ってるの。
まず、こういう馬鹿を排除、だな。
ハードの故障ごときで止まるシステムを作る方が馬鹿だ。
とか言っちゃう奴に正論たれても無駄だと思うよ。
＃冗長化してるから待機系があるのでハード故障しても止まらない、ってならともかく＃冗長化なしでハードが壊れてもシステムが止まらないなら、そのハードは本来不要だっただけ＃そんなもん作ってる奴が「止まるシステム作る方が馬鹿だ」とか笑い話だな
別ACだけどｗ
いや、まさに説明力が無い事を自分で言っているような。。もしくは理解力か？
ちなみにサーバーの多重化で対故障性は上がるけど、当然コストは上がる。多重化をやめればコストは下がるが対故障性も下がる。
でも顧客の予算は決まっているし、自社の利益率も普通決まっている。なので、予算の兼ね合いから、高価な単一のサーバーで行くか、安いサーバー複数台で行くかを決めるのが普通だと思うよ。＜ メンテや交換部品で金を請求できるなら後者だし、そうじゃなければ前者
予算も時間も有り余っているなら、高価なサーバーで多重化なんでしょうけどね。＜ そんな顧客は最近見ていないｗ
客は兎も角、技術者として動いてる管理職なら「最低限知らなきゃいけないこと」ってのはあるだろ。
そういうのは大抵は知っていても知らないようにして振る舞っていることが多いです。ようするに経営側・管理側・技術側で目的も違うし評価持ちがうので、知識としては同じでも、理解の仕方と運用が全く異なる。それは、着眼点が違うというか、別のゲームのプレイヤーとしての側面から語るので。異次元の思考に見えるのはある意味必然。
新しい技術によって、冗長化すべき（コストをかけるべき）部分が変わってきてるというなら分かるんだが……
冗長化が分かってなければ、分かってないということを突きつけてやればいいだけだろ。話を理解できないバカであれば、リーダーを下ろすしかあるまい。
# なんだか昔ゴテゴテの冗長化を詰め込んだ筐体を見てたからか# 冗長化を見るとお腹いっぱいになる気持ちなら分かる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
大変、の意味によりますがね (スコア:5, 参考になる)
技術的に失敗することが明らかなんだけど、上司や顧客にそれを言っても理解しない（主に知識が足りないので理解できない）ような時に、警告はしたよっていう証拠を残しておくこと。
また、そのままプロジェクトが邁進した結果、結合テストやシステムテストあたりで問題点が発覚した時に、責任を回避したり、最悪、炎上した案件から逃げ出すための方法を用意しておくこと。
これに尽きると思う、個人的には。
なんかもう慣れてきたけどね。
サイジングとかやってるとたまに起きる。
「それじゃ性能足りねーよ」って言ってるのに予算ありきでシステム組んで、いざ本番で負荷かかりすぎてマトモに動かないとか。
本来、同時に使うことなんか想定されてない複数のミドルなんかを１つのサーバにインストールした挙げ句、「それぞれの動作環境は足りてるのになんで書いてある処理性能が出ないんだ」って言い出したり。
Re: (スコア:0, フレームのもと)
>主に知識が足りないので理解できない
まぁ、こんな言い方するヤツは、たいてい自己満足な説明しかできていないんですけどね。
相手の理解力に言及する前に、自分の説明力不足の可能性を考えて改善してみたら？
「知識が足りないので理解できない」人に、自分の提案を受け入れてもらう方法を、もっと考えてみたら？
そうすると、もっと良いエンジニアになるよ！
Re:大変、の意味によりますがね (スコア:1)
つい最近の事案だとだな。
「応用情報技術者を持ってます」というチームリーダーが、「ハードの予算足りないからDBサーバーをシングルクラスタにしちゃおうぜ」って言う。（別に資格持ってるのはフカシじゃないっぽい。だから余計困るんだが。）
そして「耐障害性下がりますよ？」って言うと「なんで？」って言う。「冗長化」の理由を理解してねーんだ。
「なんとなく冗長化するのがお約束みたいだから冗長化で設計してたけど、今までの固定観念を取り払った斬新な設計によりコストダウンを達成した俺かっけー」ぐらいにしか思ってないんだぜ？
＃ちなみに某大手SIerの社員な、そいつ
そんなヤツにどんな説明しろっていうんだよ……。説明力不足とかそういうレベルじゃねーぞ？
客は兎も角、技術者として動いてる管理職なら「最低限知らなきゃいけないこと」ってのはあるだろ。
その「最低限知らなきゃいけないこと」を知らないヤツってのは、それを理解する能力が無いから知らないだけなんだよ。ついでに言えば、自分が無知であるという自覚がないし、指摘されても無知であることを理解しないし、だから学ぼう、相手の言うことを理解しよう、という意志もない。
笑い話にしか見えない人も居るだろうが、現実問題、そういう「上司」ってヤツも居るんだ、多くはないだろうけどね。
ついでに言うと、そういう無茶を強行した部分のカバーを現場の下の方が死ぬ気で何とかしたり、営業が死ぬ気で客を納得させて丸く収めるから、結果としては「コストダウンに成功したチームリーダー」って記録だけが残る。
それが現実だ。
「良いエンジニアになる」キャリアパス考えたら、こんな馬鹿な上司がつくような案件にかかわらずに済む道を模索する方が先だと理解はしてる。
＃でもまぁ、しがらみとか色々あってそれができんのよ
Re: (スコア:0)
立派なエンジニアじゃない。
要求されていない冗長化を、さも必要そうに進めてくるエンジニアにくらべればね。
いまどきのハードで耐障害性云々だから冗長化しましょうってことを行ってくるやつは信用できないね。
本当に耐障害性が必要なら、そのチームリーダーを論理的に説得できるはず。
できないのなら、そのプロジェクトは、耐障害性は二の次との判断がされているのだから、だまって従え。
Re: (スコア:0)
まあほとんどのプロジェクトでは耐障害性のプライオリティなんて下の下だよね。障害が発生するその日までは。
Re: (スコア:0)
耐障害性の必要性の有無以前に、「ハード２台並べてれば、片方が死んでももう片方が生き残るから耐障害性が上がるよね」って理屈すら理解してない馬鹿に理論的な説明とか通用するの？
金融系のシステム屋では普通に出る話だけどなぁ。
「奴らはCOBOLerであってエンジニアでは
Re: (スコア:0)
>耐障害性の必要性の有無以前に、「ハード２台並べてれば、片方が死んでももう片方が生き残るから耐障害性が上がるよね」って理屈すら理解してない馬鹿に理論的な説明とか通用するの？
その程度の理解で理論的に説明している気になっている時点でだめだね。
いまどきその手の説明で納得してもらえるくらいなら苦労しませんよ。
＞金融系のシステム屋では普通に出る話だけどなぁ。
＞「奴らはCOBOLerであってエンジニアではない、だから信用できない」とか言われたら地味に反論に困るけれども。
金融系ならシステム屋じゃなくて、ハード屋が安心設計してくれるインフラをつかえばいい。
Re: (スコア:0)
> 必要のない耐障害性をごり押ししてくる奴に限って
耐障害性の要不要を決定するのは、システム開発者じゃない。お客だ。「耐障害性を削ると１ヶ月システム停止が発生するけど、それで問題ありません」と書いてあるペーパーをお客から貰うんだね。お客からのオーダー無しに耐障害性を削るのは莫迦のやることだ。
> ハードが心配なら、監視をきちんとして、予防交換をした方が、下手な2重化とかするより、よほど安定運用ができるってことを知っていた方がいいぞ。
これらはどれも耐障害性確保の要素であって、対立する要因ではないわな。多重化して監視しないも、多重化しないで監視するのも、共に莫迦のやること。故障に予兆が無いもんもあるんだけど、どうやって故障の予兆を監視でとらえる事が出来るんだ？大体、多重化に難癖をつけるお客や開発側のマネジメントが、それ以上に金が掛かるPMや監視をやるとも思えないけどね。
Re: (スコア:0)
> シンプルイズベストな対応を考えてくれって言ってるの。
まず、こういう馬鹿を排除、だな。
Re: (スコア:0)
とか言っちゃう奴に正論たれても無駄だと思うよ。
＃冗長化してるから待機系があるのでハード故障しても止まらない、ってならともかく
＃冗長化なしでハードが壊れてもシステムが止まらないなら、そのハードは本来不要だっただけ
＃そんなもん作ってる奴が「止まるシステム作る方が馬鹿だ」とか笑い話だな
Re: (スコア:0)
別ACだけどｗ
いや、まさに説明力が無い事を自分で言っているような。。
もしくは理解力か？
ちなみにサーバーの多重化で対故障性は上がるけど、当然コストは上がる。
多重化をやめればコストは下がるが対故障性も下がる。
でも顧客の予算は決まっているし、自社の利益率も普通決まっている。
なので、予算の兼ね合いから、高価な単一のサーバーで行くか、
安いサーバー複数台で行くかを決めるのが普通だと思うよ。
＜ メンテや交換部品で金を請求できるなら後者だし、そうじゃなければ前者
予算も時間も有り余っているなら、高価なサーバーで
多重化なんでしょうけどね。＜ そんな顧客は最近見ていないｗ
Re: (スコア:0)
そういうのは大抵は知っていても知らないようにして振る舞っていることが多いです。
ようするに経営側・管理側・技術側で目的も違うし評価持ちがうので、
知識としては同じでも、理解の仕方と運用が全く異なる。
それは、着眼点が違うというか、別のゲームのプレイヤーとしての側面から語るので。
異次元の思考に見えるのはある意味必然。
Re: (スコア:0)
新しい技術によって、冗長化すべき（コストをかけるべき）部分が
変わってきてるというなら分かるんだが……
冗長化が分かってなければ、分かってないということを突きつけてやればいいだけだろ。
話を理解できないバカであれば、リーダーを下ろすしかあるまい。
# なんだか昔ゴテゴテの冗長化を詰め込んだ筐体を見てたからか
# 冗長化を見るとお腹いっぱいになる気持ちなら分かる