アカウント名:
パスワード:
「いつも俺たち(プログラマー/エンジニア)は悪くない。悪いのは営業かマネージャーか顧客だ」
プログラマ/エンジニアが悪いことが原因でプロジェクトが失敗するのって、そもそもからして難しい気がするんだけど。
自分の10数年の経験でも、業務システムで技術的問題で失敗したケースはほぼありませんでした。問題は常に上流工程にあります。実際に難しい仕事だと思いますが。
ただ、逆に言うとプログラマレベルの人達はいくらでも交換可能ということです。どの会社に回してもそれほど酷い事にはなりませんからね。
客がそれに気がつかないように嘘を付かれているだけでは?それを成功と言うならそうでしょう。
製造をもう少し大事にして頂きたい。自分の自宅を大学生のバイトの大工に任せますか?
もしかしてわかっていないのかもしれないけど,「いくらでも交換可能」と「その辺の素人」は別の話だよ.
家を建てるのにはもちろん職人さんを集めるけど,その職人さんは「現代の名工」である必要はない.必要なレベルのスキルを持った職人さんを必要な人数だけ集めるのは別に難しくないし,その中にダメな人がいて交代させようと思っても,それも難しくないってこと.
製造を大事にしすぎたから、いまの日本の惨状があるのです。
いやいや山ほどありますよ。
システムがリプレースされたら、数万レコードから1レコードを引っ張ってくるだけの1秒以下の処理が、20秒以上かかる様になったとか、マスターが時々すっとぶとか、ソースを見たら1クラスにメソッドが100個とか。もちろん、営業やコンサルが酷い事も多かった。
ユーザ企業の情シスの目から見れば、一番悪いのは、そんな営業やコンサルの口車に乗せられて契約した挙句、使えないシステムを使わされる現場や、アラートを出し続けていた自社の情シスの話より、営業やコンサルの話ばかり聞いて問題を先送りにし続ける、上の人達だと思いますけどすね。
技術者的な観点で言えばそんなの「技術的な問題ではない」んですよ。開発コストに予算が合わなかったとかスキルの無い所に開発させたとか言う「営業的な問題」です。
技術的な問題で大混乱したことありましたよ。
顧客DBをSIerさんが新式に移し替える時、電話番号をコンバートしたら頭の0が全部欠けてて検索しても使い物にならなかった。聞いたら「データを一度Excelに落として新しい方に流しました」との事。電話番号が数値扱いになったら、そりゃ頭の0なくなりますわな。
単純に、Excelの初歩の初歩の技術的仕様(デフォルトが数値扱いのセルで、明示的に文字扱いにしておくべき)をSEがうっかり忘れてたのか、疲れて眠かったのか何なのか分かりませんけどね。
# テストデータでコンバートしてみなかったのかな。# ちなみに2000万のプロジェクトで、あまりに困ったから余所様に出したら桁が一個減った。
何が何でも技術者のせいにはしたくないという気持ちだけは伝わってきました。
技術がわからず適当に仕事を取ってきている(ようにみえる?)営業が悪いのか、経営が分からず自分の給料がどこから出ているのかも理解できない(ようにみえる?)技術が悪いのか。
でもさ、今やらなきゃならないのは自分以外の誰かのせいにして薄っぺらいプライドのために死ぬのを待つんじゃなくて、プライドを投げ捨ててでも営業と技術が連携して会社を存続させる(=給料をもらえる)ことを必死で考えるべきなんじゃないの?
自分たちの技量で技術要件が満たせる案件だけをできれば幸せなのかもしれないけど、そんな選り好みできるほど今業界は活況なわけじゃないから多少難しくても取ってくるしかない。そうしなきゃ会社が倒れちゃうからさ。
そうやって、具体的な対応策を出さずに精神論を振りかざして、責任の所在を曖昧にする人が最も悪いんだろうなあ。
それは技術が原因となった「トラブル」でしかなくね?
愛知の図書館。あれ、同じシステムを他のところでも流用してたんでしょう?そして発注側は満足してたわけだ。なので、営業的には大成功ですよね。なんの手もかかってないのだもの。
製品はゴミクズ以下だったわけだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
あなたがたはこういいたいのですね (スコア:0)
「いつも俺たち(プログラマー/エンジニア)は悪くない。悪いのは営業かマネージャーか顧客だ」
Re:あなたがたはこういいたいのですね (スコア:0)
プログラマ/エンジニアが悪いことが原因でプロジェクトが失敗するのって、そもそもからして難しい気がするんだけど。
Re: (スコア:0)
自分の10数年の経験でも、業務システムで技術的問題で失敗したケースはほぼありませんでした。
問題は常に上流工程にあります。実際に難しい仕事だと思いますが。
ただ、逆に言うとプログラマレベルの人達はいくらでも交換可能ということです。
どの会社に回してもそれほど酷い事にはなりませんからね。
Re: (スコア:0)
客がそれに気がつかないように嘘を付かれているだけでは?
それを成功と言うならそうでしょう。
製造をもう少し大事にして頂きたい。
自分の自宅を大学生のバイトの大工に任せますか?
Re: (スコア:0)
製造をもう少し大事にして頂きたい。
自分の自宅を大学生のバイトの大工に任せますか?
もしかしてわかっていないのかもしれないけど,「いくらでも交換可能」と「その辺の素人」は別の話だよ.
家を建てるのにはもちろん職人さんを集めるけど,その職人さんは「現代の名工」である必要はない.
必要なレベルのスキルを持った職人さんを必要な人数だけ集めるのは別に難しくないし,その中にダメな人がいて交代させようと思っても,それも難しくないってこと.
Re: (スコア:0)
製造を大事にしすぎたから、いまの日本の惨状があるのです。
Re: (スコア:0)
いやいや山ほどありますよ。
システムがリプレースされたら、数万レコードから1レコードを引っ張ってくるだけの1秒以下の処理が、20秒以上かかる様になったとか、マスターが時々すっとぶとか、ソースを見たら1クラスにメソッドが100個とか。
もちろん、営業やコンサルが酷い事も多かった。
ユーザ企業の情シスの目から見れば、一番悪いのは、そんな営業やコンサルの口車に乗せられて契約した挙句、使えないシステムを使わされる現場や、アラートを出し続けていた自社の情シスの話より、営業やコンサルの話ばかり聞いて問題を先送りにし続ける、上の人達だと思いますけどすね。
Re: (スコア:0)
技術者的な観点で言えばそんなの「技術的な問題ではない」んですよ。
開発コストに予算が合わなかったとかスキルの無い所に開発させたとか言う「営業的な問題」です。
Re:あなたがたはこういいたいのですね (スコア:1)
技術的な問題で大混乱したことありましたよ。
顧客DBをSIerさんが新式に移し替える時、電話番号をコンバートしたら頭の0が全部欠け
てて検索しても使い物にならなかった。
聞いたら「データを一度Excelに落として新しい方に流しました」との事。
電話番号が数値扱いになったら、そりゃ頭の0なくなりますわな。
単純に、Excelの初歩の初歩の技術的仕様(デフォルトが数値扱いのセルで、明示的に文字
扱いにしておくべき)をSEがうっかり忘れてたのか、疲れて眠かったのか何なのか分かりません
けどね。
# テストデータでコンバートしてみなかったのかな。
# ちなみに2000万のプロジェクトで、あまりに困ったから余所様に出したら桁が一個減った。
はじける加齢の香り!orz
Re: (スコア:0)
何が何でも技術者のせいにはしたくないという気持ちだけは伝わってきました。
Re: (スコア:0)
技術がわからず適当に仕事を取ってきている(ようにみえる?)営業が悪いのか、
経営が分からず自分の給料がどこから出ているのかも理解できない(ようにみえる?)技術が悪いのか。
でもさ、今やらなきゃならないのは自分以外の誰かのせいにして薄っぺらいプライドのために死ぬのを待つんじゃなくて、
プライドを投げ捨ててでも営業と技術が連携して会社を存続させる(=給料をもらえる)ことを必死で考えるべきなんじゃないの?
自分たちの技量で技術要件が満たせる案件だけをできれば幸せなのかもしれないけど、
そんな選り好みできるほど今業界は活況なわけじゃないから多少難しくても取ってくるしかない。
そうしなきゃ会社が倒れちゃうからさ。
Re: (スコア:0)
そうやって、具体的な対応策を出さずに精神論を振りかざして、責任の所在を曖昧にする人が最も悪いんだろうなあ。
Re: (スコア:0)
それは技術が原因となった「トラブル」でしかなくね?
Re: (スコア:0)
愛知の図書館。
あれ、同じシステムを他のところでも流用してたんでしょう?
そして発注側は満足してたわけだ。なので、営業的には大成功ですよね。
なんの手もかかってないのだもの。
製品はゴミクズ以下だったわけだけど。