エンジニアをやめました - よく寝てよく寝る
Xの名前やプロフィールを変えたので気づいた方もいるかもしれませんが、 1ヶ月前くらいにエンジニアからジョブチェンジし、技術広報のお仕事をしています。 転職はしてません。 転職してから何してたの なんでエンジニアやめたの 感謝したいこと これからについて 転職してから何してたの 技術広報を始めるきっかけがあるまで、何やってたかを書いてます。 たいした伏線にはならないので興味のない方は読み飛ばしていただいて構いません。 ペパボからグロービスにバックエンドエンジニアとして入社するとまず、グロービス学び放題というビジネススキルを動画で学習できるサブスクサービスの事業部で、新規ユーザーを獲得するための開発施策を実施するチーム(当時)に配属されました。 このチームの守備範囲はサービスのLPにあるメールアドレス登録フォームからサブスクのプランを選択して決済操作を完了させるまでです。 チームメンバー全員が
サービス開発の施策に納得できない時にエンジニアができるアクション - $shibayu36->blog;
サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが
やりたいこと・学びたいことがたくさんある焦り・急がば回れ - たにしきんぐダム
散文 何だか最近ソフトウェア開発者として焦りを感じている 知りたいことや学びたいことがたくさんある。WasmやRISC-V・コンパイラ最適化やLLVMについてだってもっと深く知識を身に着けたい。 とはいえ時間の全てを勉強に投げ出すわけにはいかない。仕事はあるし生活もある、優先度をつけてやっていかないといけない。しかし深い知識を身につけるには時間がかかる。 本やドキュメントをこつこつと時間をかけて読み続けるしかないのだが、早くそれを分かりたいという気持ちが先行して、ついショートカットしようとしていきなりそれらのプロダクトのコードを読もうとしてみたり、ちょろっと表面を触って分かった気になろうとしてしまう。そしていきなり事前知識が少ない状態でそれらのプロジェクトのコードを読もうとすると当然たくさんの未知の情報に圧倒されて惨めな気分を味わうことになる。(戒め) ちゃんと本やドキュメントを一から読ん
バイアスを逆手に取る
Profile id: Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 株式会社ヘンリー VP of Engineering おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU 好きな言語は、PerlとGoと中国語 3 Times ISUCON Winner Using Perl 入門監視 付録C 執筆 「みんなのGo言語」共著者 Profile id: Songmu (ソンムー) What I ♥ Blog / Twitter OSS Agile Full Cycle Development Road Bike, Cycling
35年と3ヶ月間働いて、とうとう定年になりました。 区切りとして、定年エントリーを書きました。お楽しみください。 - Vengineerの妄想
はじめに 今日、勤務先の制度上、定年を迎えました。大昔は、誕生日をもって定年でしたが、最近は定年を迎える月の末日ということのようです。 早いもので、35年と3か月(423か月)、雇われる身として、働いてきました。ちなみに、国民年金の満額は、480か月ですので、満額は貰えません。 今月末に定年エントリーを各予定です。 若い頃の働き方が定年までできるのはほぼ無理です。 家族が増えたり、家の購入、子供教育、親の介護などいろいろな事が起こります。 起こる前提にしておかないと、辛いだけです それから勤務先からの要求も変わっていきます。 という内容を残したいと思います。— Vengineerの妄想 (@Vengineer) 2024年6月9日 定年を意識したのは、パンデミックの2年目です。おこちゃまが大学進学のためにお家から出て行ってからです。 最初に定年について書いたのが下記のブログです。 veng
開発者イベントやコミュニティ参加についての期待や効果 - 株式会社ヘンリー エンジニアブログ
VP of Engineeringの id:Songmu です。冒頭に、大事なお知らせですが、今週土曜日(6/22)に開催される、Kotlin Fest 2024にヘンリーはスポンサーをしています。スポンサーブースも出展しますので、是非お立ち寄りください。私もいます。 また、Henryの開発者の一人でもあり「Kotlin サーバーサイドプラグラミング実践開発」の著者でもある、 @n_takehata が、2024年版 Kotlin サーバーサイドプログラミング実践開発というタイトルで登壇します。是非こちらも聞きに来てください。 ヘンリーも社員数が増えてきたこともあり、このスポンサーを機に、イベントやコミュニティ参加に関する制度づくりを始めました。また、それらに参加する社員も増えて欲しいと思っています。そのために、改めて、社員がイベントやコミュニティに参加する意義を考え直して整理した内容が本
mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論
mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論 2024年6月18日 mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日本語化やプラグイン、Go言語などでOSS（オープンソースソフトウェア）の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023年 GitHub Stars。著書に『みんなのGo言語』（2016年、2019年に改訂2版、技術評論社、共著）、『Go 言語プログラミングエッセンス』（2023年、技術評論社、単著）がある。関西在住。 X:@mattn_jp GitHub 前回はアウトプットとは何か、何のためアウトプットするのか、についてお話しました。筆者はこれまで、アウトプットのやり方で悩んでいる方々に、どう
2023 の振り返り
2024 年に書いてる時点で全然収まってないけど 2023 を振り返る。せっかくブログもオーバーホールしたので…。10 年ぶりとかなのでここしばらくの内容も含んでる。 仕事 引き続き同じ会社にいて 11 年目くらい。ここ 5 年くらいは Platform Engineering、Security、Corporate Engineering (情シスとか IT ともいう) のエリアに跨った仕事をして、各々のエリアへ貢献したり、はたまた全社に影響する成果を出したり。UK を本拠とするグローバル事業の組織、日本の組織ともに見ていて、今の仕事は 4 割くらい英語。 今年は波乱の 1 年だった。2 度にわたる退職勧奨やレイオフ、創業者が社長に戻る、オフィスを横浜から東京に戻すことが決まる、去年(全てが起こる前に)交代した CTO もいなくなることになる…など。 この影響で退職を決断したメンバーも多か
エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つです
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
「一番の下手くそ」かもしれないけれど、未経験の業務に飛び込んでみる | はてなで働く kmuto にアンケート [#25] - Hatena Developer Blog
はてなで働くエンジニアにアンケートシリーズ第25回は、MackerelチームのCRE、id:kmutoに話を聞きました。 「一番の下手くそでいよう」という本の一節から異なる環境へ CREチームの「Engineer」成分が強化されてきている カスタマーサクセスとしてお客さまとの商談に臨み、技術的な挑戦をする 「学び、考え、育つ」ことが常に期待される環境 「一番の下手くそでいよう」という本の一節から異なる環境へ ── Q1. はてなidとその由来を教えてください はてなidは kmuto です。 大学の研究室配属時のUNIX（SunOS）アカウント発行ルールが「名1文字＋姓」だったため、「Kenshi Muto」→「kmuto」となりました。以来、どこでもこの文字列を使っています。 はてなidとして取得したのは比較的最近のことなので、他の人が使っていなかったのは幸運でした。呼ばれるときには、k
![「一番の下手くそ」かもしれないけれど、未経験の業務に飛び込んでみる | はてなで働く kmuto にアンケート [#25] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/db5a60c92486218c910483a792ad02e4772df003/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20230501%2F20230501125320.jpg)
現役エンジニア兼採用担当から見たエンジニア採用アンチパターン / Engineer Recruitment Anti-Patterns
LAPRAS忘年会 2023でのLT発表資料です。
Webアプリケーションエンジニアとして1on1してもらう際に考えていること - stefafafan の fa は3つです
同僚が1on1の際に他の人がどういう話をしているのか気にされていたので、便乗してブログに書きます。 ということで人が1on1の時間に何を考えてどう使っているのか気になっている1on1で何を話すか考えてる - tomato3713’s blog 前提 株式会社はてなは新卒から所属しており、今年で9年目 現在チームでテックリードをしている。Webアプリケーションエンジニアとしてコードも日々書いている とはいえ自分もメンティーは持っていなくて、1on1してもらう側の1人 最近1on1に向けて考えていること 前提に書いてある通り、自分はこの会社では古参で普段の仕事の仕方だったり同僚とのやりとりやカルチャーについての大きな悩みや不安はないです。その代わり、テックリードや30歳になったエンジニアとしての悩みや考えはあります。ということで以下のようなことを考えています。 テックリード どのような振る舞い
仕事における感情の変化に1on1で向き合った話 - taxin's notes
勤労感謝の日なので (?) 仕事の話をします。 記事のタイトルにある通り、仕事と感情の変化についてSREのテックリード (TL) と1on1で会話する機会がありました。 最近は、エンジニアとして「気分良く」仕事ができるかということを考えています。もちろん仕事の締切を守るとか求められるアウトプットを出すように最大限勤めるとかは前提とした上でです。 仕事におけるモチベーションや行動力につながるのはもちろんですが、自分の傾向として「気分が良い」方が視野が広くなり興味関心や思考をチ－ム外・社外の物事まで向けやすくなるというのがあります。 私の所属するチ－ムでは2週間スプリントでスクラムを行っているのですが、あるスプリントで「気分良く」仕事ができていない状態になっていました。 タスクが想定より時間がかかってしまった タスク完了までに設けているチェックポイントに達するまでの時間もかかっていた 自分でコ
テックリードとして技術的施策をチームに提案する際に意識すべきポイント - stefafafan の fa は3つです
私はいま会社でテックリードをしていますが、いちエンジニアとして技術的改善をチームに提案するスキルに関してまだ課題感を持っています。その際同じくチームに所属しているエンジニアリングマネージャー（EM）の方にヘルプしていただき、実際に提案資料をペアライティングした中で湧いたイメージがあるのでブログとしてまとめて自分の考えを整理してみようと思います。 効果的なストーリーテリングのための既存のフレームワーク 技術的な提案をするには効果的なストーリーテリングをするスキルが必要だと考えています。私はストーリーテリングに関して詳しくありませんが、仕事を通じて以下の二つのフレームワークを知りましたので軽く紹介します。世の中には他にもいろいろあると思いますが、基本的な考え方は近いのかなと想像しています。 空・雨・傘 STARフレームワーク 空・雨・傘 EMの方と会話する中で「空・雨・傘」というフレーズを何度
Scalaわいわい勉強会 参加した - ふんわり放牧
scala-tokyo.connpass.com 株式会社はてな 東京オフィスで開催されたScalaわいわい勉強会に参加した。 発表内容の感想ではなく、参加して漠然と思ったことについて書く。個人の日記です。 Scala、10年前に本当に少しだけ触った程度で何も覚えていない（github.comに辛うじてコードが残っている）のだけれど、 この1年はJVM言語で仕事をしているのもあり、勉強会の運営をしている id:Windymelt にも紹介いただいたのもあって、ふらっと参加してきた。 Scalaのコミュニティというか関数型プログラミング言語のコミュニティ、ふらっと参加するには恐れ多い印象があったのだけれども*1、 これくらいのノリであれば全然次回も参加したいな〜となるくらいの感じであったな。 参加前に これだけ読めばOK！Scalaの環境構築2023 - Lambdaカクテル を読んでて、手
趣味プログラミングのたのしみ - Hatena Developer Blog
こんにちは。CTOのid:motemenです。みなさん趣味プログラム書いてますか？ このエントリは Backyard Hatena #4 のフォローアップ記事です。エピソードの最後のほうで、「motemenが作って公開しているツール、どんなことを考えて作ってる？」という話になりました。そのときは時間の関係もあってあまりちゃんと話せなかったな、という感覚があったので、ここであらためて考えてみようと思います。 治具のようにつくる ウェブ上で読める自分が好きな記事のひとつに、Go Is a Shop-built Jig（抄訳）というものがあります。一言でいうと、「Goは現実的な問題を解くための治具である」ということをいっています。治具とは何かを達成することを補助する小さな目的のために作られた道具、という感じかな。fujiwaraさんの隙間家具のたとえからも近いニュアンスを感じます。 自分がツール
LegalOn Technologies のエンジニアグレード評価基準を公開します - LegalOn Technologies Engineering Blog
こんにちは。LegalOn TechnologiesでCTOを務めている深川といいます。 もし私がどういう人なのか気になる方がいましたら、私のことは以下の弊社オープン社内報でも記載していますので、よかったらこちらの記事をご覧いただければと思います。 https://now.legalontech.jp/n/n36b23e19f7b0 エンジニア組織の運営は人数が増えていくにつれて加速度的に難易度があがります。その中でも、エンジニアリングマネージャーにとって常に頭を悩ませるものが人事評価制度です。特に、評価基準については、公正かつ納得感があり、それでいて属人化しない評価基準を作り上げるのは至難の業です。 弊社も例に漏れずエンジニアのグレード評価基準に課題を感じていたため、2022年10月にエンジニアグレード評価基準の刷新を行いました。そこから約10か月が経過し、徐々に刷新の効果や課題が見えて
キャリアハックの奇行 - Software Transactional Memo
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
2023年にエンジニアな私がマネジメントに目覚めてから読んでよかった3冊 - Lean Baseball
タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
男女5名のコミュニティリーダーが語る、エンジニア×ネイルアートの魅力──キラキラエンジニアへの道は輝く指先から！
