- PR -

技術者は会社の利益を考えて作業していますか?

投票結果総投票数:44
考えている 39 88.64%
これから考える 0 0.00%
考えていない 4 9.09%
営業が考えるべきだ 1 2.27%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-01-05 08:20
引用:

加納正和さんの書き込み (2007-01-05 01:01) より:
「ふつーの」技術者は、仮想上のプロジェクト売上と原価は把握して
いるので、自分は「利益」も考えていると思い込むものです。



なかなか示唆深いですね。
自分がやっているのは開発の請負なので安直に人件費と
いくらかの間接費用で利益を考察していましたが…
「利益」を考えていると思い込んでいるだけなんだろうか?

大手メーカーみたいに販売まで絡んでいると「利益」を考えることが
相応に難しいことは分かるのですけども。


引用:

DSさんの書き込み (2007-01-04 18:02) より:
ご丁寧に返信ありがとうございます。
メンバーの誰にでも分かるように分かりやすく説明するのも骨が折れるのは分かります。
この辺は、営業も技術も隔たりはありませんね。


回答が面倒な問いかけをして、感想がそれだけですか。ふーん。

解説が面倒なのは私は別にいまさら気にとめてはいませんが、
一生懸命説明した結果、なんだ、俺の解説、別にいらないんじゃん、
と思ったときが一番嫌ですね。
総じて「大変ですよね」なんて、そんな中身の無い回答されてもなぁ。
技術者への嫌がらせとして「答えて見やがれ!」で設問したと
思われても仕方ないですよ。

人と人との間を取り持つのが大変なんだって力説している割には
人の気持ちは考慮していないんですね。
それとも開発の人間にの気持ちはどうでもいいのかな?
あぁ、だから「営業のつらさもわかってください」なのか。

# という書き込みに必死になって反論するのを期待してこの文体
さとぴぃ
会議室デビュー日: 2003/06/01
投稿数: 5
お住まい・勤務地: 沖縄・那覇市
投稿日時: 2007-01-05 10:39
ツリですか?

経営学だけで、営業が務まるとも思えません。
経済学の事も考えてこそですけど・・・

機会費用の事も考慮してやってます?

費用対効果の事ばかり話ししていますが・・・
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2007-01-05 22:13
激しくわけわかんねぇ。。。
引用:

技術力をアピールするタイプの技術者が多いなか、
自分の行っている作業がどれだけ貢献しているのか把握している技術者は少ないように思えます。


 仕事してるってことは、会社の利益のために貢献しているはずなんだけど?

ますますわからん。。。
引用:

【技術者向けに追記】
6.COBOLとJavaを使ったときの費用対効果は出せますか?
7.オブジェクト指向を使う理由を数字にすることはできますか?
8.デザインパターンを使う理由を数字にすることはできますか?
9.最新ツールを導入する理由を数字にすることはできますか?
10.リファクタリングする理由を数字にすることはできますか?
11.ファクトリメソッドに置き換える理由を数字にすることはできますか?
12.シングルトンに置き換える理由を数字にすることはできますか?


6→イタリア語と英語を使ったときの費用対効果は出せますか?
 イタリア人にはイタリア語を使うし、イギリス人には英語を使う。そんなこと、当たり前でしょ?
 もちろん、イタリア人の多くは、英語も理解するだろうけど。

8→デザインパターンが何か、わかってて聞いてる?使うのに、理由なんかいる?
 あるいは。近所のお店にお使いに行くのに、走っていくか、自転車で行くか。そんな違いだよ。
 あることをするのに、定型的なパターンが用意されている。そのパターンを用いれば、より速く、より正確に、より安全に、実装することが出来る。
 それとも、デザインパターンを用いるようにリファクタリングすることについて、疑問視している?

7,10→「今」に重きを置くか、「この先」に重きを置くか。それによって変わってくる。
 オブジェクト指向で行えば、オブジェクト分析をするぶん、設計に時間がかかる。そのかわり、実装やメンテナンスが格段に楽になる。
 使わなければ、すぐに実装にかかれる分、早くできるような気がする。でも、途中の仕様変更やテストでのバグ、複数人での開発時にどこでなんのためにバグが発生したのかわかりにくくなる。
 同じように、わかりにくいコードのまま放っておくか、わかりやすいコードに書き換えておくか。リファクタリングすることを、納期が遅れる理由にしているなら、論外だけど。

11→8と10の組合せね。

12→8,10に一部かかるとしても、愚問の骨頂。
 シングルトンって、何かわかってる?ひとつのインスタンスしかないことを保証するんだよ?ひとつしかないことを保証したい場面で、使わないでどうするの?
 それとも、パターンを使わずに何とかして実装しているのを、リファクタリングすることについて、疑問を持っているのかな?

9→なにを、どうアピールするのか。それが問題。
 最新の UI は、アピールする点として有効。しかし、古い開発環境だと、最新の UI に、すぐにアクセスしづらい。その辺を探し回って実装するか、そのまま実装できるか。あるいは、古い UI のままで行くか。


 技術者向けに追記したものって、「これ、どういう技術ですか」ってのを、先に確認しておいてください。


 私が前にいた会社(と言うより、部門だな)は、直接経費と、外部へ提示する単価を、従業員一人一人が把握させられていました。逆ザヤになっていたからです。ですから、いくらで仕事していて、本当はどこまでで仕上げなければ利益が出ないか、知っていました。
 しかし。それとは別に、営業は利益をかっさらっていました。こちらが出した「見積もり」に自分ところの利益を上乗せして提示する。あるいは、顧客の「予算」から自分ところの利益を引いた分を予算として開発に提示していました。
 請け負い主体なのに、2ヶ月だけ派遣をやったことがあって、その時にもちゃっかり、利益を取っていましたよ(笑)。お客さんが、帳尻あわせに苦労して、泣いてましたね。開発部から出たときの、2倍近い金額になっていましたから。

 そんな営業と付き合っていたので、(以下略
_________________

スキルアップ/キャリアアップ(JOB@IT)