エンジニアを頑張ったで評価する会社は衰退する | rake enjoy
この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。（最近のゲームなどは除く）またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を
目標がないならまずは地味なエンジニアを目指してみるのもいいかも？という話 - seri::diary
ワカモノは悩んでいるらしい 自分は今年で旧エヴァのミサトさんと同い年という感じで若くないせいか、たまに自分より年下の知り合いに会うと、仕事の悩み相談みたいな展開になることが多い。 会社もバックグラウンドも年齢もそれぞれ違う彼らの悩みは多種多様であるように聞こえていたのだが、最近ある共通点に気づいた。「このままじゃいけない」と無意識に思い込んでいる点である。 今以上にスキルをつけなければいけない、成長しなければいけない、ユニークな仕事をしなければならない、など人によって異なるのだが、なぜか「～なければいけない」の思いを持っていた。 そしてもう一つ共通しているのが、その「～なければいけない」の目的が見えないという点である。何となく焦っているのは分かるのだが、その焦って行動した結果によって自分が何を得たいのか。これまで色んな悩み人と会ったが、共通してそれが見えてこなかった。それとなく中長期的な計
「できません」と言わないソフトウェア技術者の話。
私の知人に、ほとんど「できません」と言わないソフトウェア技術者がいる。営業であれば、「出来ません」と言わない方は普通にいるのだが、ソフトウェア技術者では珍しい。 「GoogleAnalyticsのように、グラフィカルに表示できないですか？」 ⇒「なんとかしましょう」 「1週間以内に実装できないですか？」 ⇒「わかりました」 「応答のスピードを上げられますか？」 ⇒「やってみます」 彼は周りからたいへん頼りにされているのだが、かと言って安請け合いするわけでもない。仕様に問題があれば必ずディスカッションを求め、必ず納期は守る。 私は彼が「やったことはないですが、多分できるでしょう」と言い、そのとおりになったことを何度も見た。 最近すぐに「できません」という社員が増えているとの悩みを経営者の方々からお聞きする。無茶な要求をする 上司や顧客がいるのも事実だろうが、考えもしないで「できません」という
Joel on Software - 射撃しつつ前進
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ
ドワンゴの準エンジニア手当という制度が面白い - 続・はてなポイント３万を使い切るまで死なない日記
ドワンゴにはエンジニア手当というものがあって、プログラマーの給与水準が全体的に高くなっている。要するに優遇されている。 しかし、プログラミングの知識はエンジニアだけでなく企画者、あるいはデザイナーにとっても重要である。したがって、エンジニアから他の職種へのコンバートも積極的に進めるという方針がドワンゴにはあるのだが、このときにエンジニア手当というのが問題になる。要するにエンジニアをやめて他の職種にいくと給料が下がるのだ。 そのため元エンジニア手当みたいなものを作ろうとかいうような話もあったのだが、それはそれで不公平ではないかという議論もあり、結果として準エンジニア手当というものを創設し、一定の技術スキルがあることが試験で認められれば、元エンジニアだろうが、元からの企画者やデザイナーだろうが、給料が上がるという仕組みを導入することにしたのだ。 これがいまドワンゴ社内で盛り上がっているらしい、
エンジニアから非エンジニアに歩み寄る方が捗る - Konifar's WIP
非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシーンがあります。 佐藤「宜しくお願いしま
「アメリカのプログラマの給料が高い」は本当か？ - NomoLog
こんな記事を見つけました。 アメリカのプログラマーの言語別年収wwwwwwwww で、上の記事で引用されている表がこちら 1$=100円とすると、大体1000万円から800万円のレンジですね。 で、こちらが日本のプログラマの言語別年収 プログラミング言語別!求人給与額ランキング 大体400万円から300万円のレンジですね。夢も希望もありません。 訂正 プログラミング言語別!求人給与額ランキング に表記してある給与は下限金額であるというご指摘を受けました。 つまり、Pythonプログラマを雇う会社は平均して最低380万円程度払っているということです。私がソースをきちんと読んでいませんでした。大変申し訳ありませんでした。 プログラミング言語別給与のソースは他に発見できませんでしたが、”プログラマ”として一括りにしたソースはいくつかありました。 プログラマーの平均年収 プログラマーの給料・年収
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
「コードは書かない」と宣言する、えふしんが描くエンジニアの理想のキャリアパス | HRナビ by リクルート
かつてないほど手軽にネットショップ運営を始められる「BASE」。今年の5月には3億円の資金調達に成功し、今、最も勢いのあるECのスタートアップだ。同社に約2年間にわたって技術顧問として関わってきた「えふしん」こと藤川真一氏が、このほどCTOとしてジョインした。 エンジニアとして名高い藤川氏だが、BASEでは「コードを書かない」と公言している。代表の鶴岡氏の掲げるビジョンを具現化し、サービスを成長させるために、マネジメント業務に徹することを決めたという。藤川氏が考える、エンジニアにとっての理想の組織、そしてキャリアパスについて、詳しく話を聞いた。 なぜ藤川氏は「コードを書かない」のか？ ――BASEでは「コードを書かない」と宣言されていますが、それはなぜですか？ 藤川：一言で言うと、コードを書いている余裕がないからということに尽きるのですが、BASEにはすでにある程度の規模のチームがあるので
開発トレンドは「スマホの外」へ。それでもプログラマーのやることは1つ【連載:中島聡】 - エンジニアtype | 転職type
UIEvolution Founder 中島 聡 Windows95／98、Internet Explorer 3.0／4.0のチーフアーキテクトを務めたエンジニア。NTTに就職した後、マイクロソフト日本法人（現・日本マイクロソフト）に移り、1989年、米マイクロソフトへ。2000年に退社後、UIEを設立。経営者兼開発者として『CloudReaders』や『neu.Notes+』、教育アプリ『neu.Tutor』といったiOSアプリを開発する。シアトル在住。個人ブログはコチラ 今回は、エンジニアtypeが展開している特集「New Order～融合の先を拓く者たち」に関連して、編集部から「ソフトとハード、ネットとリアルが融合する時代の歩き方」をテーマにしてほしいというリクエストがあったので、私見をまとめてみました。 この連載でも何度か取り上げたように、一昨年末くらいから、わたしはウエアラブル
プログラミングは必要ない？ 気鋭の経済学者が説く「未来のキャリアに求められるスキル」 | ライフハッカー・ジャパン
99U：いわゆる「月並の」キャリアアドバイスに意味が無いのは、世の中はものすごいスピードで変化しているからです。善意に満ちた識者によるアドバイスは、何十年も前の経験に基づいたものです。 経済学者のタイラー・コーエンは、最新著書『Average Is Over』（訳：標準は終わりだ）で、私たちは仕事に対する考え方を見直すべきで、急激なテクノロジーの変化が起きつつある中、キャリアについて再考すべきであると説きました。 産業化が進んだ国々でアウトソーシングや仕事の自動化が促進され、労働力が過剰になり、雇用が減っています。アマゾンの無人飛行機が利用される世界において、郵便配達人は必要とされるでしょうか？ Googleの無人自動車が大衆市場に進出したら、誰がタクシーを必要とするでしょうか？ とはいえ、クリエイターが直面する問題はもっと漠然としています。ロボットに仕事を取って代わられることよりも、グロ
ベンチャーで働くエンジニアに必要な「勇気」 | Nekoya press
「恐怖」を知ること 35歳が目前に迫りつつある中、ぼちぼちスピリチュアルなことも書いていこうかと思う今日この頃です。 これまで十数年、小さな会社やフリーランス、大企業（はすぐ辞めたけど）を渡り歩いてきて改めてベンチャーの面白さを実感しています。 様々な要素がありますが、その最たる物は「エンジニアが会社の命運を握っている」という紛れもない事実です。自社でプロダクトを開発しているベンチャーにおいて、どんなに立派な経営理念やビジネスモデルも動かないシステムの前ではクソの役にも立ちません。 そして、それはそのままエンジニアの過ちが会社を危機に陥れるリスクを意味します。言ってしまえば「ワンクリックデプロイ」が「ワンクリック倒産」へと直結するかもしれないのです。省力化そのものは目指すべきですが、自分の行為が内包するリスクは忘れてはならないのです。 「何か」が起きてしまった時に上長の責任だ、確認ミスだと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゲームプログラミングの本とは思えないほど後書きが秀逸だった。 ｜ザコ助さんのTwitterで話題の画像