アカウント名:
パスワード:
悪意の有無は兎も角として、日本の場合(アメリカでもそうなのかは知りませんが)、運用ノウハウやバグの回避方法なんかが特定メンバーの頭の中だけにあって、レイオフしてみたらシステムが動かなくなった、ということは発生しそうな気がするなぁ。
ちゃんとドキュメント作ればいいんだけど、システムの設計書は基本設計書とDB設計書ぐらいしかない、運用手順書もない状態で、その上、工数的にドキュメント整備なんかしてる時間はないからそんな状態が延々と続いている、ってところは意外とあるんじゃないだろうか。
そんな感じで回されてるシステムだと、これから炎上するところが結構出てきてもおかしくないんじゃないかな、特にレイオフしたり値下げ目当てで安いエンジニアにすげ替えたりすると。
#そんなシステムの運用保守やってるのでAC#止まったら社会的に見ても結構ヤバいところなんだがなぁ・・・#つーか、発注先の企業が「詳細設計?そんなの金かかるからやらなくてもいいよ。」って、それでいいんかよ、とは思うが。
逆に自分しか使えないようにしておけば、会社にとって必要な人間になれるので、解雇される危険性が減るかも。解雇されたらされたで十分な嫌がらせになるだろうし。
いざ、蓋を開けてみれば、何とも無かったですな
それは定年延長や定年後再雇用などで、彼らが現場を離れていないからです。まだ根本的解決はしていません。
私の関係する仕事でいうと、深い経験と高度な技術がいる分野では結構響いています。(打つ手無しといった部分もあったりします。トホホ…。)
その一方で、わかりやすい作業や単純な業務では数年程度教育すれば、なんとか小間使い程度には使えたりして重宝しています。
人件費が安くなった分だけ効率化してるのでしょうが、目先の利益を追い求めている結果は何時か必ず回ってくるような気がしています。
それができる経営者 or 人事管理者なら、そんな冗長性のない運用の仕方をしない。
よって、解雇される が FA
悲しいけど、これに心から同意。今の日本だと、他人に分かり難いコードを作りドキュメントも用意しないことを推奨する、強力なインセンティブが存在しているんですね。
日本流プロジェクトマネジメントの当然の結果です。
ちょっと前に盛んに言われた問題ですよ。「属人化」で検索するといろいろ出てきます。
(COBOLなどから)新しい開発環境に移行するメリットとしてよく言及された問題なんですが、結局「人の問題」をコンピュータで解決することはできず、いつのまにか影が薄くなったような気がします。# 問題自体は変わらず存在していますが# 取り上げる人が少なくなったというか
>「属人化」で検索するといろいろ出てきます。それは全然関係ない話だと思う。
技術というのは属人的なもので、それを誰にでも使えるようにレベルを下げようというのは最初から無理な話だった。#こういうのは技術を知らない管理職が飛びつくんだよね。#PMBOKとかCMMIだとかITSSとか。
ここで言ってるのはそれとは別の話で、より分かり易いコード、より優れたコードを書くことは可能であるけれど、それを使わないように推奨する強いインセンティブが存在するというお話。
>> でも、普段とは違う形式で他人に分かり難いコードを書けば、数ヶ月もすれば自分でも理解できなくなるので、
ということは,そこでコード変換するための独自プログラムを用意して…いや,むしろ開発を独自の「オレ言語」でプログラミングしておけば良いのか!
これが次々とプログラミング言語が誕生し続ける理由である.(嘘)
ネタだよね?
一応始まりは英国留学中にSimulaユーザだったStroustrap氏が米国に行ってCにクラスを導入して"クラス付きのC"を作った所から始まってます。いろいろあって(特にCの上位互換的性質を維持しようとして)最終的には言語仕様が膨らんだとはいえ、決して難読化を目指したわけでは…。
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html [rim.or.jp]これを真に受けちゃったんでしょう;-)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
悪意の有無は兎も角として (スコア:4, 興味深い)
悪意の有無は兎も角として、日本の場合(アメリカでもそうなのかは知りませんが)、運用ノウハウやバグの回避方法なんかが特定メンバーの頭の中だけにあって、レイオフしてみたらシステムが動かなくなった、ということは発生しそうな気がするなぁ。
ちゃんとドキュメント作ればいいんだけど、システムの設計書は基本設計書とDB設計書ぐらいしかない、運用手順書もない状態で、その上、工数的にドキュメント整備なんかしてる時間はないからそんな状態が延々と続いている、ってところは意外とあるんじゃないだろうか。
そんな感じで回されてるシステムだと、これから炎上するところが結構出てきてもおかしくないんじゃないかな、特にレイオフしたり値下げ目当てで安いエンジニアにすげ替えたりすると。
#そんなシステムの運用保守やってるのでAC
#止まったら社会的に見ても結構ヤバいところなんだがなぁ・・・
#つーか、発注先の企業が「詳細設計?そんなの金かかるからやらなくてもいいよ。」って、それでいいんかよ、とは思うが。
Re:悪意の有無は兎も角として (スコア:3, 参考になる)
逆に自分しか使えないようにしておけば、
会社にとって必要な人間になれるので、解雇される危険性が減るかも。
解雇されたらされたで十分な嫌がらせになるだろうし。
Re:悪意の有無は兎も角として (スコア:2, すばらしい洞察)
実際に必須な人間であっても、会社が理解してくれるかは不明
あと、必要不可欠と思っているのは本人だけというパターンも
数年前、団塊世代の大量退職が会社の危機を招く
なんて、論調が流行っていましたが(主に定年間際の人の間でね)
いざ、蓋を開けてみれば、何とも無かったですな
また、退職を迎えた人の技術移転が出来ていないので、大変な事になる、
なんて言って、オヤジたちの重要性を強調してましたが
職務の一部である、教育や技術移転を、これまで怠ってきたって事でしょ
仕事さぼっておいて、今更、自分たちは貴重な人材だなんて主張されても、、、、
壮大な自作自演だったのでは?と勘ぐってしまいますよ
てな訳で、立場が違えば、見方も変わるので、
安心できませんよ
Re:悪意の有無は兎も角として (スコア:1, すばらしい洞察)
それは定年延長や定年後再雇用などで、彼らが現場を離れていないからです。
まだ根本的解決はしていません。
Re:悪意の有無は兎も角として (スコア:1, 興味深い)
私の関係する仕事でいうと、深い経験と高度な技術がいる分野では結構響いています。
(打つ手無しといった部分もあったりします。トホホ…。)
その一方で、わかりやすい作業や単純な業務では数年程度教育すれば、なんとか小間
使い程度には使えたりして重宝しています。
人件費が安くなった分だけ効率化してるのでしょうが、目先の利益を追い求めている
結果は何時か必ず回ってくるような気がしています。
Re:悪意の有無は兎も角として (スコア:1, すばらしい洞察)
そりゃ「教育」をきちんと評価してこなかった
経営者側の責任でしょう。
なんで報酬も出ないことを自分の生産時間を
削ってまでやらなきゃなんないんだよ(w
Re:悪意の有無は兎も角として (スコア:1)
それができる経営者 or 人事管理者なら、そんな冗長性のない運用の仕方をしない。
よって、解雇される が FA
犬が犬であるように、猫でありたい
Re:悪意の有無は兎も角として (スコア:1)
悲しいけど、これに心から同意。
今の日本だと、他人に分かり難いコードを作りドキュメントも用意しない
ことを推奨する、強力なインセンティブが存在しているんですね。
日本流プロジェクトマネジメントの当然の結果です。
時代かなぁ (スコア:1, 興味深い)
ちょっと前に盛んに言われた問題ですよ。
「属人化」で検索するといろいろ出てきます。
(COBOLなどから)新しい開発環境に移行するメリットとして
よく言及された問題なんですが、
結局「人の問題」をコンピュータで解決することはできず、
いつのまにか影が薄くなったような気がします。
# 問題自体は変わらず存在していますが
# 取り上げる人が少なくなったというか
Re: (スコア:0)
>「属人化」で検索するといろいろ出てきます。
それは全然関係ない話だと思う。
技術というのは属人的なもので、それを誰にでも使えるように
レベルを下げようというのは最初から無理な話だった。
#こういうのは技術を知らない管理職が飛びつくんだよね。
#PMBOKとかCMMIだとかITSSとか。
ここで言ってるのはそれとは別の話で、より分かり易い
コード、より優れたコードを書くことは可能であるけれど、
それを使わないように推奨する強いインセンティブが
存在するというお話。
Re: (スコア:0)
結局は自爆するだけな訳で。
最初からそういう変なコードしか書けないなら仕方ないでしょうけど、それはそれで複数人でプロジェクトを
組むときに同僚に嫌われる結果を招いて自分の評価が下がっていくだけな気も。
Re:悪意の有無は兎も角として (スコア:1)
>> でも、普段とは違う形式で他人に分かり難いコードを書けば、数ヶ月もすれば自分でも理解できなくなるので、
ということは,そこでコード変換するための独自プログラムを用意して…いや,むしろ開発を独自の「オレ言語」でプログラミングしておけば良いのか!
これが次々とプログラミング言語が誕生し続ける理由である.(嘘)
Re: (スコア:0)
> むしろ開発を独自の「オレ言語」でプログラミングしておけば良いのか!
> これが次々とプログラミング言語が誕生し続ける理由である.(嘘)
オレ言語ではありませんが、C++が誕生した理由って正にそんな感じじゃありませんでしたっけ?
(判読の難しさじゃなくて、コーディングの難しさをもって作業単価を維持するとかそんな感じだけど)
Re:悪意の有無は兎も角として (スコア:1)
ネタだよね?
一応始まりは英国留学中にSimulaユーザだったStroustrap氏が米国に行ってCにクラスを導入して"クラス付きのC"を作った所から始まってます。
いろいろあって(特にCの上位互換的性質を維持しようとして)最終的には言語仕様が膨らんだとはいえ、決して難読化を目指したわけでは…。
Re:悪意の有無は兎も角として (スコア:1)
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html [rim.or.jp]
これを真に受けちゃったんでしょう;-)