意識低めの成長 - Mitsuyuki.Shiiba
とても雑記 個人の成長は必須かなぁ？ よーはつのツイートを見て、古川さんのスライドを見て、「グループや会社は成長して欲しいなぁって思うけど、個人の成長はどうなんだろう？僕は『今、自分が持ってるチカラで会社の成長を支える』ぐらいがいいなぁ」みたいなことをぼやーっと考えた ここ数年、こういう組織の支援もやっているけど、ほんとに難しい… 開発組織の持続可能性について https://t.co/8HpulzqngQ pic.twitter.com/Jx9LFuH0p2— yoh nakamura (@yohhatu) July 12, 2022 意識低い 最近の自分は「成長しなきゃ！」「そして自分の成長で会社の成長を支えなきゃ！」みたいなのはあんまりなくて、意識は低い方かなぁと思う。「それはそれ、これはこれ」な気持ち 単純に、新しいことを学ぶのは楽しいし、昨日できなかったことが今日できるようになる
中年IT人材おじさんの平穏 - megamouthの葬列
IT人材が不足してるんだって。零細Web制作会社で言えば、退職者が残したubuntu12サーバーに眠るRails5アプリをすぐにDDDでマイクロサービスに再構成して、jQuery満載のコードを全て読み下したうえで、フロントエンドをReactかなんかのSPAに全部書き換えて、E2Eを含めた自動回帰テストを整備して、ついでにCIも整備して、k8sにデプロイできるようにして、ドキュメントは小まめに残し、職場の心理的安全性を落とさず、飲み会にはかかさず参加、役員との関係も良好で、定期的な勉強会も開いてくれて、それでも残ったプライベートの時間を最新の技術動向やセキュリティ情報の収集に全量突っ込んでくれる、そんなごく当たり前のエンジニアが不足している。ついでに言うと、人類の原罪を一身に贖ってくれるスキルの持ち主も不足しているらしい。多分、我々はもっと求人サイトに金を払うべきなんだろうね。 同業者から、
Staff EngineerとSenior Engineerの違いを知る「Staff Engineer」 - stanaka's blog
今年読んだ本は今年のうちにレビューしてしまおう、の第二弾「Staff Engineer」です。 Staff Engineer すこし前にTwitter界隈でIndividual Contributor(以下、IC)の話が話題になってましたが、そのICとしてのキャリアの先にある、日本ではあまり馴染みのないStaff Engineerについての本です。ちなみに本の内容は全て https://staffeng.com/ でも読むことができますので、紙が不要な人はこちらからどうぞ。 Staff Engineerは、会社ごとに、またおそらく部署ごとでも様々なバラエティのある役割の定義があり、この本は著者での経験に基づく記述と、各社のいろいろなStaff Engineerの人たちからのインタビューから構成されています。 著者の経験によると、Staff Engineerの典型例として、一つ、もしくは複数
事業内容によって必要なエンジニア組織は異なる - Melting Pot of Thoughts
CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど
ソフトウェアエンジニアと技術力 / developer-lifework
Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - htt…
エンジニアの目標設定って難しいよね、という話とOKRでなんとかできるのではという話｜dora_e_m
「目標設定、ニガテなんですよね」組織に属するメンバーを育成し、評価する。そのための材料として「目標設定」を活用している組織は多い。MBOか、それに類する形を採用しているところが多いのではないか。（観測範囲での判断なので今は違うかもしれない） そして、「目標設定」を行う組織は多いというのに、「私、目標設定得意なんですよ」というエンジニアの存在は寡聞にして存じ上げない。なぜなのだろう。 エンジニアの目標設定は難しい？組織のレベルでは、「売上○○円」「ユーザー数○○人」「平均DAU○○」といった目標が設定されることが多い。財務に直結するものだ。翻って、エンジニアたちは組織にどう貢献するのか。エンジニアリングだ。直接売上がどうこうではなく、「どうすればビジネスに貢献するか」から立脚された仮説に基づいて行動をしていくことになる。 こうすれば画面遷移数が減って使いやすくなる、その事により利用率が向上す
「共同創業者（エンジニア）を探している」という相談に対しての僕の回答｜suthio
「共同創業者になってくれるエンジニアを探している」と起業家（準備中含）から相談されてだいたい同じことを回答してる気がするので僕の考えを書きます。 想定読者・起業を考えていて自分自身はエンジニアではない ・試したい仮説はあって、検証するためにはプロダクトを開発する必要がある ・現在、コミットしてもらえるエンジニアもいない ・どういうエンジニアを探せばいいかわからない 結論 結論から書きます。 検証するためのプロダクトをあなた自身で書いていきましょう。 創業者が優秀なエンジニアになれという話ではなくて、 一人目のエンジニアを採用するためには自分自身でプロダクトを作るのが一番の近道という話です。 ソフトウェア開発について一定の理解を得ることができる ソフトウェアの開発を行う時にどういうことを考えて、結果どういうものを作っていくかのフローを一度経験しておくことにより、 エンジニアを採用した後に自分
「零細企業経営にはほとんどの意見が参考にならなかった話」を書けと言われたので - terurouメモ
書けと言われたので、雑に。人に意見されたことはあまりないつもりだったんだけど、思い出してみたら、結構あったような気がしてきた。 零細企業経営にはほとんどの意見が参考にならなかった話 https://t.co/sUpRX51RJq ポエム書いた。— V (@voluntas) 2020年11月22日 これは是非 @terurou にも書いていただきたい。— V (@voluntas) 2020年11月22日 人の意見は参考になるか？ 基本的に利害関係のない人間の話は「参考にならん」でいいと思う。逆に利害関係のある人間の話は重要で、それは社員だとか、顧客だとか、株主だとかになってくる（うちは株の100%が自分が持ってるので、株主って自分ですねになるのだけど）。 世間には「勝ちに不思議の勝ちあり、負けに不思議の負けなし」という良い言葉がある通りで、 成功体験をもとにしてくる意見はまず参考にならん
エンジニアの職人芸を継承すべし | 外道父の匠
『職人芸』。それは、その人にしかできない、または他より圧倒的な品質・精度・速度で仕事を遂行する技術力、というものが確かにあります。 そのような崇高な技術は、どこから来て、どこへ行くのか。そんな圧倒的ポエム回。 職人芸とは 言い方はなんでも良いのですが、組織には上級的なエンジニアが一定割合いて、おそらくその人にしかできない仕事や、手慣れていて効率的に済ませられる仕事を任せられていることでしょう。 そういうエンジニアはたいてい『職人芸』と呼べそうな技術を修得しています。例えば、高精度な設計・高難度な機能実装・的確なコードレビュー・精密な試験・堅牢な運用などなど。 システム提供を大雑把に工程で分類すると、企画・設計・構築・試験・運用 といったところでしょうか。ちょっと外すと研究などもアリですね。それぞれの工程において、集中的に従事して得る職人芸もあれば、多岐にわたる経験によって生まれる職人芸もあ
設計の知恵を、リアルな価値に変えるために 〜 問題の所在 | タイム・コンサルタントの日誌から
エンジニアだったら誰もが、「自分の出した知恵で、評価されたい」と思うだろう。優れたアイデアを出せば、それが高く評価される。逆に、つまらぬ設計しかできない者は、たいして評価されない。世の中は、そういう風であってほしい、と感じている人は多いはずだ。 評価という言葉には、いろいろな意味がある。同僚や周囲からリスペクトされるのも、評価だ。新しい重要な仕事のリーダー格に取り立てられたり、昇進するのも、評価だ。もちろん、給料やボーナスに反映されるのも、評価だ。ともあれ、優れた知恵を出したら、尊敬され、リーダー役に抜擢され、ちゃんと経済的にも報われるべきだ。つまり、良い設計の知恵は、リアルな価値に、ちゃんと具現化されてほしい。 だが、そうあってほしいと感じる人が多いのだとしたら、それは逆に、世の中はそうなっていない、という事の証拠であろう。自分の身の回りを見る限り、あんまりそうなっていないな、なんとも世
失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
Habits of High-Functioning Teams
I often struggle to explain what it means to be part of a high-functioning software team. Sure, there are mountains of literature, and an entire genre of LinkedIn thought leadership that professes all kinds of guidelines and heuristics about what makes teams work, but in my experience, it’s hard to internalize these ideas and follow someone else’s model if you’ve never seen what good looks like. I
Webエンジニアおかあさんそのほか｜やきとりい
IT業界で働く女性が、母親をしつつ仕事も続けるビジョンを持ちにくいよねー実例が少ないからねーという話を聞きました。このnoteは、その1サンプルの提供のために書いています。 他の人に必ず当てはまる話ではないけれど、たしかに今なんとかかんとか回している子持ちWebエンジニア（フルタイム）のわたしの話です。 すごく優れているわけじゃないし、人並外れて努力しているわけでもない。そんな真面目でもない。 ただ毎日、できる範囲でなんとかしています。 2018年現在のステータス - Webエンジニアとして8年目くらい - こども（ぱんださん・仮名）は1歳8ヶ月 - パートナー（ささださん）もエンジニア、時間の融通が効くお勤め - 会社は株式会社万葉。SES契約での業務が主ですが常駐するスタイルではなく、働きやすさと技術を大事にするホワイト企業 目次- 今の働き方のスタイル（日々のタイムスケジュール／イレ
すべてのエンジニアが持つべきプロダクト思考とは - STEAM PLACE
メリークリスマスイヴ！エンジニアリングマネージャーの さとうだいすけ @dskst9 です！ この記事は Engineering Manager Advent Calendar 2019 24日目の記事です。 みなさんはプロダクト作りを楽しんでますか？ 私達エンジニアの存在意義であるプロダクト開発において、プロダクトマネジメントは切っても切れない存在です。 本稿では、エンジニアが持つべきプロダクト思考とは何かを探求します。 エンジニアにとってプロダクトとは プロダクトの価値がゼロになると プロダクトにおける技術的負債の返済 プロダクトの機能と価値と負債 プロダクトの価値を高める、あるいは負債を返済する ストーリーを知る ファクトを集める 機能の価値を見極める ネゴシエートする 成長するプロダクトを描く おわり エンジニアにとってプロダクトとは 私達は機能を作っているのではなく、プロダクトを
エンジニアを増やしていけば、うまくいくと思っていた––メルカリCTO名村卓氏が語る、開発組織の今とこれから
2019年9月24日、株式会社メルカリにて、エンジニア向けイベント「Mercari Bold Challenge ~CTOとエンジニアが赤裸々に語る 変化と挑戦~」が開催されました。社員数は1,800人を超え、40ヵ国以上の国から多様な人材が集まり急成長を続けるメルカリ。一方で、急成長に伴って新たな課題も生まれています。そこで今回は「Bold Challenge（大胆な挑戦）」というテーマで、メルカリのエンジニア組織の変化と挑戦について、そのリアルを語ります。プレゼンテーション「メルカリのエンジニア組織の今とこれから」に登場したのは、執行役員CTOの名村卓氏。講演資料はこちら CTO名村氏が語るメルカリのエンジニア組織の今 名村卓氏：こんにちは。CTOの名村です。僕からは、メルカリのエンジニア組織の話をさせていただきます。「今とこれから」ということで、これまでのことと、今抱えている課題と、
なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか｜川嶋一矢@メルペイPM
はじめにメルカリUK版の立ち上げを終え2018年3月に帰国しました@tsumujikazeです。今は東京でメルペイのProduct Managerをしています。 イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。 PMF →リーンプロダクトのプロセス →モダンなプロダクトチーム（組織論）という流れになっています。 はじめに 本編 ・何のためにプロダクトを作るのか ・プロダクトマーケットフィット ・PMFピラミッド ・要件定義フェーズのリーン化 ・モダンなプロダクトチームでのリーン開発とは おまけ ・Problem Space vs. Solution Space ・Problem Solution Fitとは ・エンジニア組織とPM組織の特性について ・バリュープロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織の持続可能性について
よくないエンジニアリングカルチャー
日本で働くソフトウェアエンジニアの給与：東京で働く外国人エンジニアによる究極のガイド
Googleのソフトウェアエンジニアリング文化
