inouetakuya.info 2023 著作権. 不許複製 プライバシーポリシー
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか? 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい
世間の流れに沿って、一度、退職エントリを書いてみたかったんですけど、まだちょっと退職しそうにないんで、倒置法で我慢してみました。 本人には「退職エントリ書くね!」と去り際に伝えてありますが、センシティブなカテゴリですから、企業・個人事情に基づくものというよりは、身近な人間が退職したという出来事に対する感想的なものとなります。 ザッと振り返って 前に書いた、「新卒インフラエンジニアを育成した話」で地獄を見せようと試みて、いまいち業火で焼き尽くせず耐え切ったアノ弟子です。二年が経過し、中小規模のサービスを専任で4~5個担当するまで至っていたので、当人の努力と成果は十分であったのかと思います。 他にも、AWS関連や、インフラのアーキテクチャなどは、私と共に進めたり、時には率先して案を出したりもしてくれていたので、中盤からは弟子というよりは普通に共同作業者という立ち位置でした。例えば「現代ITイン
弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について本人同意済み。弊社特有の部分は一部省いています。) ああ、なんという長い旅だったろう。この会社で5年間もセキュリティを担当していたよ(諸々の失敗は許してくれ) 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、
「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。 第一期 サービスリリース前 自分でサービスをガリガリ作っている というかサービスを作ることしかしていない 1日16時間くらい仕事をしても、プログラミングしかしていないので疲れない 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識 フルスタックエンジニアというある種の全能感を満喫する 第二期 サービスリリース後 運用(ユーザーサポートなども含む)が入ってくるのでサービス開発のスピードが落ちる エンジニアを採用(業務委託含む)する 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる でもまだまだ自分が圧倒的にメイン開発者 コードレビューやマージ、リリースは自分が全てやる システムの全体からディテール
「職場の小さなことをなんでも自動化していた“本当にターミナルに住んでいるようなヤツ”と評されるエンジニアの話が、ロシアの掲示板から英訳され、話題になっている」と、サイボウズ・ラボの秋元裕樹氏がブログで日本語で紹介し、日本でも話題になっています。 そのエンジニアは訳あって転職しましたが、「文字通りターミナルに住んでいるようで、90秒以上時間が掛かるものはスクリプトで自動化してしまう人」だったそうです。その「遺産」が残っていました。 smack-my-bixxx-up.sh(夜9時以降に活動していたら、「遅くなる」などの理由を定義した文字列からランダムに選び、SMSで奧さんへ送る) kumar-xxxhole.rb(顧客からのメールをスキャンし、不具合対処依頼メールが来たら客の運用サーバを直近のバックアップに巻き戻す。そして「大丈夫だ。次は気を付けてくれ」と返事する) hangover.sh(
"首都「圏」から島根「県」へエンジニア・ワークシフト2015" での講演資料です
当記事は、こちらへ移動しました。 引き続きQiita:Teamをよろしくお願いいたします。
2015年8月21日の勉強会「スタートアップにおける技術チームの作り方」で発表した際の資料です。Read less
どうも、吉田真吾(@yoshidashingo)です。このたびcloudpackのエバンジェリストを卒業することになりましたのでご報告です。 本日8/14(金)が最終出社日で、今月いっぱい有給消化するスケジュールです。 微力ながらAWSおよびそれを使った構築・運用サービスであるcloudpackの普及にエバンジェリストとして2年8ヶ月間、携わらせていただき、とても濃密な時間が過ごせてアイレットのみんなには感謝の念でいっぱいです。 なんで辞めるの? 今回卒業することにした主な理由は2つです。 クラウド=ITのモダン化の1つの流れ(足回りのモダン化)ととらえ、それを活用するチーム作りや開発フローのモダン化についてもバリューを出して行きたいと思った。 いわゆるエバンジェリストというロールよりは、もっともっと自身のエンジニアとしての経験値を積んで、そこからストーリーが伝えられる人になりたいと思った
本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う(詳しくは検索してきて!) sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった
こんにちは、テコラス株式会社技術研究所の伊勢です。この度、テコラス::データホテルテックブログが開設されたようでして、「最初のエントリは最年長技術者が書くべきじゃねーか?」というデジコアディレクター松本氏からの脅迫に近いお達しにより、一発目のエントリを書くことになりました。とはいえ、最近あまり仕事もしておりませんし、旬な技術や実装ネタも無いため、どーしよーっかなー?と考えていましたら、技術評論社Software Design誌編集長の(心やさしい)池本さんから、過去に寄稿した記事を転載してもイイヨ!というありがたいお言葉を頂きましたので、それを元に書きたいと思います。 本エントリは昨年12月4日に技術評論社から発売されたSoftware Design別冊シリーズ「インフラエンジニア教本」に寄稿させて頂いた「インフラエンジニア鬼十訓」を転載したものです。この鬼十訓は私の経験知見だけではなく、
2015-03-07 某R社を5日でクビになった話 Hello,World!個人開発でぬくぬくやってきたエンジニアの僕が、縁あってエンジニアインターンし、5日目にしてクビになるという出来事があり、学びが多かったので綴りたいと思います。 ◼︎某社との出会い 焼き肉をおごるという企画で、スカウトが来て、オシャレでキレイな焼き肉屋さんでランチをしました。そこで、スゴイエンジニアさんに「このサービスのこの部分をこうしたほうがよくて、ここまで作ったので開発してもいいですか?みたいにすれば自分のやりたい開発ができるんだよ」と言われ、自分のエンジニアのイメージがガラッと変わって魅了されて、興味を持つようになりました。そのスゴイエンジニアさんは、今も憧れているスゴイ方です。カッコイイなと思っています。 ◼︎某社の技術責任者との出会い 会社訪問を予定していた日に、スゴイエンジニアさんにスゴイエンジニアさんの
グループを作れば、無料で誰でもイベントページが作成できます。情報発信や交流のためのイベントをTECH PLAY で公開してみませんか?
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く