Geekなぺーじ : エンジニアが見落としがちなこと
過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
仙石浩明の日記: 技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき
先週参加した社外の飲み会 (私は飲めないので専らウーロン茶でしたが) で、 Linux ディストリビューションの開発や、 カーネル技術を売りにしたコンサルティングで有名な某社の カーネル技術者とお会いしました。 彼はいま伸び盛りの若手カーネル・ハッカーなのですが、 オープン・ソース・ソフトウェア (以下 OSS と略記) ビジネスについて熱く語ったり、 ディストリビューションをサポートし続ける使命感に燃えていたのが、 わたし的にはちょっと気になりまして、 ひとこと言いたくなってしまいました(お節介ですね ^^;)。 ディストリビューションのサポート体制 (カーネルのバグにも的確に即応できる体制) を維持し続けることによって、 多くの企業で Linux を安心して使ってもらうことができて、 それが OSS の発展につながるし、 それこそが自分の使命だと彼は考えているようでした。 それはそれで
developer0000.jp
Buy this domain. developer0000.jp 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
業務知識は都市伝説ではない - novtan別館
極端な話、「これが問題になると俺の出世に響くんだよね」をソリューションするのも業務知識です。極端だけど。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 SIerが必要としているのは業務知識だという都市伝説 - yvsu pron. yas まあ言わんとすることがなんとなくわかるのは僕が金融の人だからかもしれない。でも社内で流通をやっている人も、違う倉庫に配送されちゃったりして苦労してますよｗ 今のシステムって大きくなったり統合されたりしたせいで、作っている人にインプットやアウトプットが見えにくくなっている。だから、作る局面ではもはや業務知識は要らないかもしれないけれども、そういう人たちが10年後20年後に全く業務がどうなっているかわからないシステムを息も絶え絶えな感じで保守している姿が目に浮かびます
上司に認めてもらえないエンジニアは“社内”を捨てOSSで行こう
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 比嘉康雄氏といえば、Javaのための「依存性の注入（Dependency Injection：DI）」と「アスペクト指向プログラミング（Aspect Oriented Programming：AOP）」をサポートした、フレームワーク「Seasar2」のチーフコミッターであり、日本のオープンソースソフトウェア（OSS）の世界でも有名人と言えるだろう。そうした比嘉氏がOSSに出会ったのは、「社内での評価に対する不満」がきっかけだという。 電通国際情報サービス（ISID）に勤務している比嘉氏は先頃開催された情報処理推進機構（IPA）のイベント「IPAフォーラム2007」の中で、「開発を夢のある仕事にするには」と題する講演を行った。同氏は、20
営業職と事務職と技術職が一体となったのがSIerのデキる人 - novtan別館
そんな状況改善しなきゃ！ 営業のスキルとマネジメントのスキルと事務管理のスキルと技術はまったく別の平行した要素であり、いっぱいできるに越したことないけど、みんなにそれを要求するのは間違っている。 そもそもの話として、世の中一般的に、会社ってのはどうやって回っているんだろうか。いわゆる「出来ない人」「万年係長」というのは本当にお荷物なんだろうか。まあ、お荷物なんだろうけれども、じゃあそういう人が排除される社会を目指しているかというとそうでもない。 IT業界ってプログラミングや設計の技術がない人を使えない呼ばわりするけれども、そういう人が上手く生きる仕事を用意できてないってことかもしれないよ。何しろ現場の人間はみんな技術者だから、それ以外の視点でものを見れないのだ。巨大なSIerならともかく、圧倒的に多い中小SIerでは間接部門のコストは俺達が払ってるんだ的な意識であることは多いし、実際に間接
微妙だなぁ - がるの健忘録
元ネタは 僕らは技術力よりも第一印象で能力を判断されている／Ｔｅｃｈ総研 http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001333 ぶっちゃけたところ。…微妙だなぁと。 初手。 今回は、エンジニアとそれ以外の職に就く200人にアンケート調査を行い、「出会ってからどの程度の接触期間で相手の仕事能力を判断していますか」という質問をぶつけてみた。 この中に「技術者と接触している非技術者(「派遣会社系の営業さん」とか)」が何割くらい含まれているのかなぁと。 また、エンジニアとそれ以外の人を分けて傾向を見ると、チェック項目にはかなり開きが見られ、エンジニアの場合はやはり「話の内容」で能力を判断する人が一番多く、逆にエンジニア以外は「目線」「髪形・服装」「話し方」という見た目での判断基準が上位に。 というのも正直こわい。というの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
