アカウント名:
パスワード:
＞約3000社の取引先ごとに個別に条件の異なる納品書や請求書データを作成・受領するもの
プログラムでやるより、ＰＣに入力できる熟練の社員を10人育てたほうがいいんじゃないか？
> 開発はRed HatのJBoss BRMSが使われたとのこと。日本の業務システムをパッケージで構築しようとして失敗というのを何度見たことか。カスタマイズで業務に合わせるんじゃなくて、業務をパッケージに合わせないとだめなんだろ。成功率ってどれくらいなんだろ。
カスタマイズで業務に合わせるんじゃなくて、業務をパッケージに合わせないとだめなんだろ。
欧米ではホイホイ転職するのが当たり前だから、転職してきた人を即戦力にするためにパッケージ構築が流行ってるんだよね。SAPなりSalesforceなりなら、そこまで使い方が変わらないから、転職組でも使い方を覚えるリードタイムが短い。
日本は終身雇用前提で作った企業制度で、企業ごとの制度やシステムがバラバラな上、業務をパッケージにあわせるという思想がない。（経営者や現場にそういう発想がないから、何をやっても駄目って話）
まあ、だからRPAみたいな中途半端なソリューションが無駄に売れるんだけどね。そのRPAですら吸収しきれないバラバラのシステムはいい加減、会社ごと滅びたほうが日本のためだよ。労働人口がこれからどんどん減るのに、そんなもんにコスト割くのは社会的な害悪だ。
というより、特にホワイトカラー系は『自己流』や『オレ流』で、仕事を進めるのが好きなんだよ。これが酷くなると、成果よりも仕事の進め方にプライド持つようになる。
事務作業は職人技ではなく『引き継ぎ可能』な仕事であるはず。にもかかわらず、標準化や定型化、ルールの共有が出来ていない。というより、ルールを飛び越えた処理をするオレ、かっけぇ、みたいに考えるクルクルパーもいる。
結果、全容を把握することが難しくなり、その辺が、業務ソフト開発において、要件定義が出来ない原因にもなり、ホワイトカラーの生産性を下げル原因の一つになっている。
……ように、外野からは見える。
そもそもホワイトカラーは「脱時間給」なんで、自己流だろうが、少ない時間・ローコストで処理できることが正義なんすよ。
＞事務作業は職人技ではなく『引き継ぎ可能』な仕事であるはず。これはホワイトカラーじゃなく、「スーツを着た単純肉体労働」なのではと。本当のホワイトカラーは、もっとクリエイティブなことをやってるよ。
その手の事務作業をホワイトカラーと呼ぶのやめようぜ。「マックジョブ」でいい。
最後の砦社内SEがいるエクセルシャドーITは砦の奥でなんかやってる感じかね
知ってるか？社内SEは３つに分けられる
会社の奴隷になって病んでいく奴トカゲの尻尾としてストックされてる奴ベンダーやSIerの飼い犬になる奴
この３つだ
一人情シスなんですが3役こなせますかね？
あぁ、それが俗に言う「フルスタックエンジニア」だな。精進しなされ。
＃違う
自分が２番めに見えた
#年齢と経験で転職できず
トカゲの尻尾かもという自覚がありながら、まだ転職しないですんでいるのはラッキーなのではないでしょうか。
stucked?
パッケージ入れてもアドオンゴリゴリでパッケージの体をなしてないところは多いけど、それでも入れてるだけマシ
未だに基幹がホストですみたいなところは、変える意思すらなかったか、失敗しまくってるってことだから、確実に地雷案件だと思う
欧米のように業務内容が契約で決まっているのであれば、業務をパッケージに合わせることは容易だろうが、日本はそもそも業務内容が明確ではないから、パッケージを入れようとすれば、まず従来の業務内容を明確化しなければならない。個人的なノウハウや、組織的な慣習といった、不明確な業務内容を全て洗い出して明確化するという作業はべらぼうな手間、暇、金がかかる。それをするよりは、現行の業務に合わせてシステムを組んだほうが速いし安くつく。
それをするよりは、現行の業務に合わせてシステムを組んだほうが速いし安くつく。
そう思って帳票3000種オーバーやろうとした結果が今回の炎上でしょ？
まず従来の業務内容を明確化しなければならない。個人的なノウハウや、組織的な慣習といった、不明確な業務内容を全て洗い出して明確化するという作業
それができなきゃ、結局「現行の業務にあわせたシステムを作る」こともままならないよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
人がやったほうがよさそうな気がする (スコア:0)
＞約3000社の取引先ごとに個別に条件の異なる納品書や請求書データを作成・受領するもの
プログラムでやるより、ＰＣに入力できる熟練の社員を10人育てたほうがいいんじゃないか？
Re: (スコア:0)
> 開発はRed HatのJBoss BRMSが使われたとのこと。
日本の業務システムをパッケージで構築しようとして失敗というのを何度見たことか。
カスタマイズで業務に合わせるんじゃなくて、業務をパッケージに合わせないとだめなんだろ。
成功率ってどれくらいなんだろ。
Re:人がやったほうがよさそうな気がする (スコア:3, すばらしい洞察)
カスタマイズで業務に合わせるんじゃなくて、業務をパッケージに合わせないとだめなんだろ。
欧米ではホイホイ転職するのが当たり前だから、転職してきた人を即戦力にするためにパッケージ構築が流行ってるんだよね。
SAPなりSalesforceなりなら、そこまで使い方が変わらないから、転職組でも使い方を覚えるリードタイムが短い。
日本は終身雇用前提で作った企業制度で、企業ごとの制度やシステムがバラバラな上、業務をパッケージにあわせるという思想がない。
（経営者や現場にそういう発想がないから、何をやっても駄目って話）
まあ、だからRPAみたいな中途半端なソリューションが無駄に売れるんだけどね。
そのRPAですら吸収しきれないバラバラのシステムはいい加減、会社ごと滅びたほうが日本のためだよ。労働人口がこれからどんどん減るのに、そんなもんにコスト割くのは社会的な害悪だ。
Re:人がやったほうがよさそうな気がする (スコア:4, すばらしい洞察)
というより、特にホワイトカラー系は『自己流』や『オレ流』で、
仕事を進めるのが好きなんだよ。
これが酷くなると、成果よりも仕事の進め方にプライド持つようになる。
事務作業は職人技ではなく『引き継ぎ可能』な仕事であるはず。
にもかかわらず、標準化や定型化、ルールの共有が出来ていない。
というより、ルールを飛び越えた処理をするオレ、かっけぇ、
みたいに考えるクルクルパーもいる。
結果、全容を把握することが難しくなり、
その辺が、業務ソフト開発において、要件定義が出来ない原因にもなり、
ホワイトカラーの生産性を下げル原因の一つになっている。
……ように、外野からは見える。
Re: (スコア:0)
そもそもホワイトカラーは「脱時間給」なんで、自己流だろうが、少ない時間・ローコストで処理できることが正義なんすよ。
＞事務作業は職人技ではなく『引き継ぎ可能』な仕事であるはず。
これはホワイトカラーじゃなく、「スーツを着た単純肉体労働」なのではと。
本当のホワイトカラーは、もっとクリエイティブなことをやってるよ。
Re: (スコア:0)
その手の事務作業をホワイトカラーと呼ぶのやめようぜ。「マックジョブ」でいい。
Re: (スコア:0)
最後の砦社内SEがいる
エクセルシャドーITは砦の奥でなんかやってる感じかね
Re: (スコア:0)
知ってるか？
社内SEは３つに分けられる
会社の奴隷になって病んでいく奴
トカゲの尻尾としてストックされてる奴
ベンダーやSIerの飼い犬になる奴
この３つだ
Re:人がやったほうがよさそうな気がする (スコア:1)
一人情シスなんですが3役こなせますかね？
Re:人がやったほうがよさそうな気がする (スコア:1)
あぁ、それが俗に言う「フルスタックエンジニア」だな。
精進しなされ。
＃違う
Re: (スコア:0)
自分が２番めに見えた
#年齢と経験で転職できず
Re: (スコア:0)
トカゲの尻尾かもという自覚がありながら、まだ転職しないですんでいるのはラッキーなのではないでしょうか。
Re: (スコア:0)
stucked?
Re: (スコア:0)
パッケージ入れてもアドオンゴリゴリでパッケージの体をなしてないところは多いけど、それでも入れてるだけマシ
未だに基幹がホストですみたいなところは、変える意思すらなかったか、失敗しまくってるってことだから、確実に地雷案件だと思う
Re: (スコア:0)
欧米のように業務内容が契約で決まっているのであれば、業務をパッケージに合わせることは容易だろうが、日本はそもそも業務内容が明確ではないから、パッケージを入れようとすれば、まず従来の業務内容を明確化しなければならない。
個人的なノウハウや、組織的な慣習といった、不明確な業務内容を全て洗い出して明確化するという作業はべらぼうな手間、暇、金がかかる。
それをするよりは、現行の業務に合わせてシステムを組んだほうが速いし安くつく。
Re:人がやったほうがよさそうな気がする (スコア:2)
それをするよりは、現行の業務に合わせてシステムを組んだほうが速いし安くつく。
そう思って帳票3000種オーバーやろうとした結果が今回の炎上でしょ？
まず従来の業務内容を明確化しなければならない。
個人的なノウハウや、組織的な慣習といった、不明確な業務内容を全て洗い出して明確化するという作業
それができなきゃ、結局「現行の業務にあわせたシステムを作る」こともままならないよね。