優秀な技術者を追い出してしまう方法 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
エンジニア採用における大前提作りについて
※人材サービス業の方のご参加はお断りしております。--------------------------------------Engineer Recruitingとは------... powered by Peatix : More… 参加者は 株式会社モンスター・ラボの村上氏 株式会社アカツキの大日方氏 株式会社MOLTS の寺倉そめひこ氏 株式会社ユーザーベースの大川氏 という面々。もちろんエンジニア採用のHowToがメインテーマだったわけですが、むしろ大枠というか抽象概念みたいなところに非常に重要性を感じました。そこで、下記にポイントをまとめてみたいと思います。 曰く、別にエンジニア採用だから特別に◯◯をするということはなく、まるっと採用に必要な大前提は同じだよね、ということ。 普段支援をさせていただいている出資先の悩みの中でも大きく上がってくるのが採用の課題。普遍的な大前提とし
知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)
週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを
33歳でアーリーリタイヤしたエンジニアが「技術力以外」の大切さを説く理由～『SOFT SKILLS』著者に聞く - エンジニアtype | 転職type
2016.07.28 働き方 プログラミングに関してズバ抜けた能力を持つエンジニアが、とあるシステムを作ったとしよう。コードは可読性が高く、最新のフレームワークを使いこなしてもいる。 にもかかわらず、ユーザーには不評で、ほとんど使われずに放置されているというケースを見たことがあるエンジニアは案外少なくないのではないだろうか。 一方、この世界では、技術力の面で平均かそれ以下のエンジニアたちが作ったシステムがユーザーから好評を得たというケースもままある。この2つのケースで、違いを生んでいるのは何なのか？ 実は開発担当者がユーザーの下に足しげく通ってサポートしていたり、ユーザーの声をつぶさに拾い上げながら機能開発をしていたなどと、「技術力以外」のところに理由があったりするものだ。 個人のキャリアでも、似たようなことがよく起こる。「技術的に優秀」であることと、「技術者として優秀」であることはイコー
第34回 エンジニアの世代交代 | gihyo.jp
一攫千金のチャンス 私は持ち込み原稿がきっかけで、高校生のときからアスキー出版でソフトウェアエンジニアとしてアルバイトをすることになった。当時はまだPCの黎明期で、NECからようやくPC-8001という8ビットPCが発売されたばかりだった。ソフトウェアの開発環境も整っておらず、すべて機械語でプログラムを書かねばならなかった。そのため、ソフトウェアを開発できるエンジニアの数がものすごく少なく、高校生の私でもあっという間に大人と肩を並べて仕事ができるようになってしまったのである。 そんな私に一攫千金のチャンスがやってきた。NECがPC-8001向けにCP/MというOSを移植していたのだが、フロッピーディスクへのアクセスがあまりにも遅く、アスキー出版に相談に来たのである。 私は、その手の高速化の話が当時から大好きだし得意だったので、当然のように私と相棒の増川くん（同じく高校生）がやることになった
第35回 自社サービス開発から受託開発に転身したエンジニアが語る「幸せな受託開発」とは
岡山で全国の仕事を請け負う「気さくなプログラマー」 岡山に暮らしながら、東京の顧客とSkypeを使ってミーティングをし、受託開発を行うプログラマーがいる。名刺の肩書は「気さくなプログラマー」。 「Rubyのまつもとさんをはじめ、できる人はみんな気さくじゃないですか。だから私も自分のキャッチフレーズとして使っています」と笑いながら話すのは、ソニックガーデンのエンジニア、野上誠司さんだ。 SI企業で5年間受託開発に携わり、その後自社サービスを作る企業に転職、そして現在は「納品のない受託開発」を掲げるユニークな企業、ソニックガーデンのエンジニアとして働く。受託開発から自社サービスへ移りたいと考えるエンジニアは多いが、再度受託開発に戻ったのはなぜなのだろうか。 【転職者プロフィール】 野上誠司さん（32歳） 株式会社ソニックガーデン 気さくなプログラマー（2013年10月入社） 【転職前】 岡山の
「技術的負債」の返済ルールを作る 株式会社ドワンゴ 清水俊博 氏 | ギークアカデミー | dodaエンジニア IT
中堅SIerを経て2009年にドワンゴに中途入社。複数のシステムの開発に携わった後、エンジニアの生産性を高めることをミッションとする部署の立ちあげに参加する。趣味はプログラミングとネトゲ。 ドワンゴ清水俊博氏にドワンゴのエンジニア文化について聞いた。2012年4月の第1回「ニコニコ超会議」の後、ドワンゴのエンジニアが大量退職するという危機的な時期があった。エンジニア文化を立て直す社内組織に参加した経緯を聞く。 ──転職のきっかけはコミュニティ活動とのことですが、当時参加していたコミュニティjava-jaの雰囲気をお聞かせください。 java-jaでは、スキルがある人たち、技術力がある人たちに囲まれていました。ヨシオリ（java-jaを立ち上げた庄司嘉織氏、清水氏の元同僚）も当時はSI業界にいて、互いに話をして共感しあい、友人になりました。 java-jaは、ヨシオリが「勉強会」という呼び名
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kamranahmedse/developer-roadmap: Interactive roadmaps, guides and other educational content to help developers grow in their careers.
金髪の神エンジニア・kamipo 伝説のもうひとつの真実 －トレジャーデータ 上薗竜太氏 - Forkwell Press
Engineer salary in United States
Living as engineer
続けられた理由は「仕事が楽しくなかったから」──カーネルハッカー・小崎資広（3） | サイボウズ式