君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
メンターを初めて経験する人に、最初に読むものとしてオススメしている書籍たち - $shibayu36->blog;
社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。 エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャー エンジニアリング組
2023年にエンジニアな私がマネジメントに目覚めてから読んでよかった3冊 - Lean Baseball
タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
エンジニアに独学を期待するのはもう時代遅れだと思う。 - ヨーロッパで働くIT土方社長のブログ
www.ntt.com これを見てちょっと最近の流れと違うなぁとしみじみ思ったので全力で反論してみる。。 僕自身は８１年代生まれ、小学校6年生のときにPC98シリーズのN88Basicで独学でBasicから入って、中高とDirectX使ってゲーム作ったりして、大学のときにバイトで実務のプログラムを初めて〜、と何故かまぁ小さいながらも経営者として傍らまだ炎上した案件とかに入って消火活動に勤しんでたりしてる。まぁ後半はどうでもいいけど、この世代では日本海外とわず独学で勉強するのは至って普通だと思う。クロアチアだと勿論PC98じゃなくてAmigaとかドイツ製のPCが主流のよう。 で、一方で最近の新入社員たちを見てると最初からスクールに通って、大学で授業を真面目にうけて、インターンでメンターに面倒を見てもらって、バイトも常にメンターがいつつ実務に関わってって流れが普通。プログラミングは常に勉強とし
言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター
いろいろやってみた知見が溜まったのでまとめ。 開発 時間給で労働を売る古き良きスタイルの副業。副業として機能開発とかバグ修正とかやったりする。 自分はUIがいい感じだったからという理由でOffersを使って副業を探した。 offers.jp 注意点として、日中まともに会社員やっている人だと、稼働時間が自ずと平日夜か土日だけになってしまう。これが厳しいところとして、副業先のチームの開発プロセスには載ることが基本できないため、非同期作業みたいな形になる＆開発スピードが求められるコアな機能開発みたいなアイテムには入りづらくなる。 あと純粋にモチベーション的に平日夜とか仕事したくないときもある。でも副業でアサインされてると仕事しないといけない。場合によってはチームの開発作業の進捗妨害をすることにもなったりする。 独立して作業可能なアイテムを貰えるプロジェクトか、例外的に日中もコミュニケーションでき
この度、3年半に渡って勤めたメルカリを2022年5月に退職し、この夏からロンドンのMetaにSenior Machine Learning Engineerとして転職することが決まりました！わいわい✌('ω')。その過程で、東京およびロンドンのBig Tech合計5社を数ヶ月かけて対策をし面接に臨んだので、そこで得たノウハウをここで共有できたらと思います。面接を受ける際にNDA（Non Disclosure Agreement）にサインするので具体的な面接の詳細には触れられませんが、伝えられる範囲でできる限り記述しています。 また、Metaから最終的に提示されたオファー条件を最後に記載してあります。なにぶん日本においては給与の話は燃えやすいということもあり、その部分だけ某日本の有名エンジニアに倣って有料にしてあるのですが、ご興味のある方は是非ご購入いただければと思います（1コイン分の金額で
はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。 この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。 これからエンジニアリングでどのような勉強をすればよいかを考え
はじめに 私は、さくらインターネットというクラウドサーバの会社の社長をしていて、よく経営者の方からのメンタリングのリクエストをいただくことがあります。 その中で多くの割合を占めるのが、ITエンジニア(以降、エンジニア)のマネジメントと、エンジニア組織の構築をどのようにすればいいのかというテーマです。 確かに、どんなビジネスをするにしても、単にSaaSやノーコードツールを活用するだけでは足りなくて、自分たちでシステム開発しないといけないケースが増えてきているのは、間違いないなと思います。 外注をしてシステム構築をするケースももちろん多いですが、基幹システムのような使いにくくても自社の社員が我慢すればいいものと違って、自社のお客様向けのシステムだと使いやすくないとお客様が離脱してしまいますし、常にアップデートをし続けて、最良のUI/UXを作ることが業績に直結します。 要は、今のデジタルシステム
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl
企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン
多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
2019/5/26 はてブで話題になっていたので慌ててアップデート、Docker実践ガイド 第2版が発売されていたので追記&修正しました。 はじめに 本投稿はRecruit Engineers その2 Advent Calendar 2018の5日目の投稿です。 そもそものきっかけ Rancher もくもく勉強＆相談会 #02にて、現代的なインフラエンジニアとして どのようなことを勉強したらよいかという相談を受けたので、書籍ベースで改めて考えてみました。 ”どんな本でしたか”くらいしかまとめてないです。そのまとめも私の完全な主観である点はご注意ください。 筆者は何者？ Web系の会社でインフラエンジニアをやっています。 パブリッククラウドやコンテナ系の技術をベースに先進アーキテクチャの装着みたいな役割で 新規サービスを中心にインフラアーキテクトみたいなお仕事をやっています。 具体的には、ア
エンジニアとして30代までにやってて良かった・やれば良かった事を自分のキャリアから振り返ってみた. - Lean Baseball
最初に言っておきます. このエントリーは「いい本を読んだついでに自分のキャリアを振り返ってオススメを残す」という長文ブログです. 適当に読み流してもいいですし, 心の琴線に触れる事があれば最後までお付き合い頂けると幸いです. さて, 4月の末と言えば, GWが近づいてくると共に色々考えることがあります. 例えば社会人23年目の私は今年, GWの予定（決まっていない場合に限る） 「こどもの日」にしてあげられること キャリアの振り返りと数年先のキャリアプラン検討 この3つについて真剣に考えています. 今年でいうとGW予定（1.）は90%程度計画済み, こどもの日（2.）は甥っ子に渡すお小遣いを検討...までは決まってるのですが, 最後の（3.）はというと, GW明けって転職とか将来キャリアを考える機会になりがちじゃん?そういえば自分のキャリア(ry ...という感じで, GWは（本人が意識する
みなさんこんにちは。@ryuzeeです。 言いたいことはタイトルに書いたとおりなのですが、2022年8月26日に、新刊『エンジニアリングマネージャーのしごと チームが必要とするマネージャーになる方法』が発売になります。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法著者／訳者：James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙出版社：オライリージャパン発売日：2022-08-26単行本（ソフトカバー）：376ページISBN-13：9784873119946ASIN：4873119944 原著はDr. James Stanier氏の『Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Need
SNSだけを見ていると、私たちの会社はいつも平穏でマイペースに仕事をしてるように見えるかもしれない。しかし、所詮は私たちも普通の会社。世の多くの会社が経験する浮き沈みや苦労と無縁ではない。 昨年は創業以来初ともいえる「営業危機」を経験した。幸いにして半年で問題の大半は解消し、数多くの学びを得た。 その一部始終を言語化することで、経験を再利用可能なノウハウとして定着させたい。同時に記事として公開することで、同じ課題で悩む企業や組織の手助けになればと思う。 自負と怠慢 ウェブ制作会社でありながら、マーケティング系のイベントに多数登壇し、マーケティング系のメディアから多数取材が来る。そんなウェブ制作会社は私たちだけだと思っている。マーケティングに強いと市場に認められ、実際にそうだという自負があった。 制作者が社員の大多数を占めるウェブ制作会社にとって、制作をしているだけで自然と仕事が舞い込んでく
プログラミング学習の挫折を防ぐには？
May 9, 2022 プログラミングの学習は時間と労力のかかる学習で、途中で学習を挫折してしまう事も珍しくありません。学習が思ったように進まないと、自分はプログラミングに向いていないのではといった迷いが出ることも少なくないでしょう。 このような問題についての研究は長年続けられており、2015年にラトビア大学のJuris Borzovs氏、Lalia Niedrite氏、Darja Solodovnikova氏らが「コンピュータプログラミング適性検査による中退学生の削減」という論文を発表しました。この論文では心理テスト、高校数学の補修講座、出願前のプログラミング体験、メンタープログラムなどによるドロップアウト削減施策が講じられました。 今回はこの論文の中から特に目に付いた点を紹介します。 半数近くの学生がコンピュータサイエンスを初年度に中退 MBTI診断テストとプログラミング学習の関連 E
新人が1on1に来ない - Qiita
新人が1on1に来ない。その原因を考察する。 ここで出てくる新人の情報は以下である。 年齢: 30代前半 エンジニア歴: 5年 入社して半年 1on1を行うに至った経緯: 1年前、私と同じ時期に入社した同期Aが退職した。 詳細はよく分からないが、どうやらチームの先輩の1人と相性が悪いとの事だった。 尚、Aが退職したのは上記の理由だが、退職したいからこれを名目上の理由にしているのであって、原因は他にある可能性はあるが、この際それは考慮しない。 会社の人員構成: ほとんどがエンジニア歴10 ~ 20年のベテラン。平均年齢は30代後半。 Aは30代前半。 周囲の反応: Aが退職を告げた時、周囲はうろたえた。事前に相談は無かったし、特に問題はないように思われていた。 何より30過ぎた社会人は、問題があれば自分から話して来るという思い込みが、既存社員にあったもしれない。 年齢は関係あるか: ないと考
いいね！Hokudai - #122 新型コロナ対策、研究と政策現場での6ヶ月～西浦博教授ロングインタビュー～
#122 新型コロナ対策、研究と政策現場での6ヶ月～西浦博教授ロングインタビュー～ 2020年07月31日 新型コロナウイルスによる感染症COVID-19は今現在も終息することなく、日本だけでもこれまでに約26,000名で感染が確認されています。本学の西浦博さん（医学研究院 教授）は中国で感染症が発生した直後の1月上旬から研究を開始し、厚生労働省のクラスター対策班の一員としても対応にあたりました。 次々と発生する危機的な状況のなかでデータをかき集め、COVID-19の特徴を徐々に明らかにしていく。そしてそれは直ちに国や自治体の政策へ反映されていく。このような科学と政策のあわいにある感染症の数理疫学は、じっくりと取り組む科学研究、純粋で確実な成果を論文で発表する科学研究というイメージからは遠いかもしれません。しかし、応用重視のオペレーション研究と言われるような分野もまた研究の実際の姿です。
開発者の生産性を測るためのフレームワーク`SPACE`について
LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が著者に入っているThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Researchで提唱されているSPACEについて 以下記事も Four Keysだけじゃない開発者生産性フレームワーク 開発生産性の可視化フレームワークであるSPACEを活用するために、どのようなメトリクスをどう取得するかについて考えてみる 要約 SPACEは開発者の生産性を計測するためのフレームワーク 推奨されている測定指標のカテゴリ(本文ではディメンションと定義)の頭文字 satisfaction and well being performance activity communication and collaborati
※追記: 「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 前回の記事「エンジニアの"有害な振る舞い"への対処法」では多くの反応を頂きました。 はてなブックマークのコメントやTwitterを見ると、多種多様な反応がある中で、有害な振る舞いが多くの方によって実際に観測されていること、そしてそれによって実際に心理的ダメージを受けていたり困っているというコメントがいくつもあることが印象的でした。 ただ、その一方でこれだけ有害な振る舞いに対する反発があると、自分の有害な振る舞いによってチ
先週、電通さんのスタートアップのアクセラレーションと、W venturesさんの投資先メンタリングをやりました。その両方で話したことの補足。 GAFAの作法に無駄に逆らってはいけないよ。GAFA級の複数企業が同じ施策・設計をしていたら、よほどのファクトがない限りは従うのがオススメ。 GAFAってのは、Google, Apple, Facebook, Amazonのことですね。 ここ数年、スタートアップ支援のお手伝いをすることが増えてます。去年は単発の相談も含めると50社ちかくで、サービス設計やグロースのメンタリングをしました。 で、ちょいちょい思うんですが… みんなオリジナリティのあるサービス設計をしすぎ！しかも、必要ないところで！ みなさん、すごい真剣にサービスを作ってるのはわかります。でも、頑張らなくてよいところで、頑張りすぎてる。決済ボタンの位置とか、リンクの色とか、ログインフローと
白潟総合研究所株式会社代表で『中小ベンチャー企業を壊す！ 人事評価制度 17の大間違い』著者の白潟敏朗氏と、『起業の科学』著者の田所雅之氏による対談の模様をお届けします。テーマは「人事評価の『ワナ』『落とし穴』」。中小ベンチャー企業の経営者に向けて、人事評価に対する悩みを解決するために最も大切なポイントについて語られました。最終回の本記事では、人事評価制度の構築・改良の成功のための６つのポイントが語られました。 固定賞与や給与に関する評価シートは、従業員が増えてから 白潟敏朗氏（以下、白潟）：少しまとめさせていただきます。（人事評価シートについて）じゃあ私どもとしてどうしたらいいのかなというのを、一覧表示してみました。まずは業績連動賞与、いわゆるインセンティブに関しては、従業員の人数関係なく、ある意味計算式でやれる世界ができれば、評価が一番楽なのかなというふうに考えます。 社員が20人にな
2023年2月〜3月頃に、私が執筆した書籍『エンジニアのためのマネジメント入門』が発売になります🎉 本稿では、発売に先立って「書籍について」と「執筆のきっかけ」、そして、書籍の「目次」と「各章の内容」を紹介します。 書名: エンジニアのためのマネジメント入門 著者: 佐藤大典 出版社: 技術評論社 発売日: 2023年2月〜3月頃（追記: 2023年3月9日発売になりました） 書籍『エンジニアのためのマネジメント入門』について 本書は、タイトルのとおりエンジニアリングマネージャーの入門書です。 本書のポイントは、エンジニアリングマネージャーの実務よりも、基礎となる知識の体系化を図ったことです。 この一冊で、エンジニアリングマネージャーの基礎的・基本的な知識と技能を学べます。 ハウツーではなくマネジメントの原典を基にした本なので、エンジニアリングマネージャーの入門者だけではなく、経験者の方
Googleで営業をしていた私が、なぜ退職して世界一の美大 Royal College of Artに行ったのか。｜Takayuki Sakai
Googleで営業をしていた私が、なぜ退職して世界一の美大 Royal College of Artに行ったのか。 はじめにはじめまして。さかいたかゆきです(@tokeikun)。このnoteは社会人学生 Advent Calendar 2019 の10日目のnoteです。 ちょっと前に4年と7ヶ月勤めたGoogleを退職し、海外の大学院に入学しました。大学院に行くというと「MBAに行くの？」と聞かれるのですが、自分が入学したのはイギリスのRoyal College of Art(RCA)という美大です。 Googleでのキャリアを振り返りつつ、なぜ退職を決断し、美大に進学するのか、自分の思考整理も兼ねてここに記したいと思います。 また、デザイナーでもエンジニアバックグラウンドでもなく、帰国子女でも留学経験者でもない、私立文系出身者が海外美術系大学院に入る過程として参考になるものがあれば幸
技術ブロガー必読！と言える「Technical Blogging, Second Edition」を読んだ - kakakakakku blog
技術ブロガー必読！と言える「Technical Blogging, Second Edition - Amplify Your Influence」を読んだ．タイトルにある通り「技術ブログ」にフォーカスした本となる．本書は2012年に出版された歴史のある本で，最新版となる Second Edition が6月末に出版された．なお，Second Edition は今年1月から β として公開されていて，β 1.0 → β 5.0 と進化しながら出版されている． 技術ブロガーとして，今まで10年以上育ててきた暗黙知をうまく整理する機会になった．本書の内容は非常に共感できるし，僕自身新しく気付けたこともあった．何よりも「技術ブログ」に対する様々なアプローチを完璧に言語化されている点が素晴らしく，正直言って「本書って僕が書いたの？」と頭が混乱するほどにシンクロを感じる場面もあった．シンクロ具合を表
【📩 仕事の相談はこちら 📩】 お仕事の相談のある方は、下記のフォームよりお気軽にご相談ください。 https://forms.gle/G5g1SJ7BBZw7oXYA7 もしもメールでの問い合わせの方がよろしければ、下記のメールアドレスへご連絡ください。 info*galirage.com（*を@に変えてご送付ください） 🎁 「生成AIの社内ガイドライン」PDFを『公式LINE』で配布中 🎁 「LINEで相談したい方」や「お問い合わせを検討中の方」は、公式LINEでご連絡いただけますと幸いです。 （期間限定で配信中なため、ご興味ある方は、今のうちに受け取りいただけたらと思います^^） https://lin.ee/3zRuqKe おまけ①：生成AIエンジニア塾 より専門的な「生成AIエンジニア人材」を目指しませんか？ そんな方々に向けて、「生成AIエンジニア塾」というプログラムを
私たち株式会社ゆめみでは、2020年から新卒者向けiOS研修カリキュラムを作成し運用してきました。 この研修をOSSで公開いたします！ 研修の内容 この研修には1〜14の課題が用意されており、 順番にクリアしながら天気予報アプリを開発していきます。 研修期間は個人のレベルによって異なりますが目安としては1ヶ月ほどと定めています。 研修に必要なもの インターネット環境 課題を参照するためにインターネット環境が必要です 開発環境 (Mac, Xcode) 実際にiOSアプリを開発していくので、Xcodeなどの環境は一通り必要になります 1名以上のメンター 課題を進行していくうえで、レビュー・フィードバックやフォローを行うメンターが不可欠です 複数名でローテーションし負荷分散するのも良いと思います Gitのホスティングサービス 実務に近い形でプルリクエストベースで進行することを想定しています G
Tom Long氏は、よいコードを書くため「4つのゴール」と「6つのコード品質の柱」を掲げ、「よいコード」と「悪いコード」を比較することで、「なぜ、このコードはよい／悪いのか」を具体的な事例とともに、1つ1つ解説しています。さらに、「よいコード」が正しく動き、「悪いコード」を発見するための「ユニットテスト」についても2章に渡って解説しています。 本書は、11章で構成されており、大きく3つの部に分かれています。最初の第1部では、コードに対するソフトウェアエンジニアとして考えを形作るための理論的な上位の概念について紹介しています。第2部では、いくつかのテーマに分けて、特定の考え方やテクニックを扱います。最後の第3 部では、効果的でメンテナンスできるユニットテストを作るための原則と実践について解説しています。 なお、監訳を務めた山本大祐氏は、次のようなコメントを寄せています。 コードが動くことに
まえがき アクセシビリティーの観点からWebサイトを診断し、AIプラットフォームを利用して得た情報をもとにベストプラクティスを提案してくれるオープンソースのWebサービス「Visible」を開発しました。 WebサイトURL: https://visi.dev GitHubリポジトリ（Starください！）: https://github.com/visible/visible GoogleのLighthouseなど、Webサイトの診断を行ってくれるサービスは以前からありましたが、診断だけではなく改善点の提案も行う新しいサービスになっています。また、アクセシビリティーに関する理解を深めてもらえるように工夫をした設計にしていたり、コマンドライン版ではスタンドアロンで実行可能なようになっています。 2020年度の「独創的アイデアと卓越した技術を持つ小中高生クリエータ支援プログラム」未踏ジュニアに
技術ブロガーを育てる！ブログメンタリングで何を教えているのか - kakakakakku blog
週末に開催された「DevLOVE X」に参加し，2日目に発表をしてきた！今回の発表タイトルは「技術ブロガーを育てる！ブログメンタリングで何を教えているのか」で，今まで約1年半続けている「ブログメンタリング」の事例紹介をテーマにした．さらに関連する話題として，「アウトプットの再定義」や「ブログを書く理由（モチベーション）」や「メンタリングの技術」も話した．発表資料をフォローアップする． devlove.wixsite.com 発表資料 speakerdeck.com Public URL-ize アウトプットの重要性はもう聞き飽きるほど聞いていると思うし，今回の DevLOVE X でも何度も話題に上がっていたけど，僕の発表では，改めてアウトプットを再定義し，うまく言語化したいと考えていた．結果として「Public URL-ize」という言葉にした．意図としては，発表資料にも記載した通り，「
【はじめに】 本記事は 「機械学習をどう学んだか by 日経 xTECH ビジネスAI② Advent Calendar 2019」 の19日目になります。 おじさんSEの私がどうやって機械学習を勉強したかを記します。 きっかけは当時抱えていた分類課題において、「機械学習が使えるんじゃね?」というところから始まりました。 闇雲にやっていたので正直記憶は曖昧です。 経歴 プログラム歴は30年近くあります。 小学生の時に覚えたMS BASICから始まり、Z80アセンブラ、MC68000アセンブラ、FORTRAN、C(UNIX)、C++(Mac)、VB、Java(Android)、VB.NET、C#と触ってきました。 いろいろな言語に触れてきましたが、どれも極めるほどガッツリやっていたわけではありません。 機械学習に関しては20年以上前、いわゆる第二次AIブームの終わり頃に卒論のテーマでニューラ
Dropbox で4年働いて学んだこと10のこと
Dropbox に4年間働き、2019年6月に退職した。2015年4月に入社し、4年2ヶ月勤務したことになる。 4年勤務するというのはサンフランシスコ、シリコンバレーのIT企業では非常に長く、退社する前、私は全社員の中で上位10%の古巣の社員になっていた。 それぐらい人の入れ替わりがあり、優秀な人たちが出入りするのがサンフランシスコ、シリコンバレーの成長しているIT企業の特徴の1つだろう。 Dropbox で働いた4年間は最高にエキサイティングで学びが多かった。特に僕は上場前で日本オフィスの立ち上げ当初に入社したからだろう。僕が入社した当時は社員数はグローバルで1200人だったが、今では2000人を超える社員数になった。さらに僕の部署は入社時は6人だったが、最後には80人ぐらいに成長し、会社の売上の９割を担う部署になっていた。 そんな急成長し続けるDropboxに4年間在籍して学んだことが
「いい感じに成長する」エンジニアのキャリアと学び方 - 2023年オススメPython本を添えて - Lean Baseball
このブログおよび, 登壇・アウトプットはゴリッゴリのエンジニア, 本職はコンサル企業のマネージャーとしてクラウドエンジニアリングのコンサルをやっている者です*1. この記事は, 当ブログの名物である, Pythonのオススメ書籍（と関連する技術書）の紹介エントリーです！ ※去年の記事はこちら. 本年のエントリーでは「今最もいい感じなPython本」の紹介に加えて, キャリアごとに読むべき技術書（と学び方）の選び方 この年末に読んで欲しい技術書（Python本とそれ以外） 「エンジニアのキャリア形成的に期待値の考え方大事だよ」という話 この三本立てでご紹介できればと思います. というわけで, 本年のラインナップは以下の通りです. 要約すると キャリアレベルを考える オススメ技術書籍2023 ジュニア🔰 メンバー マネジメント ボード 結び - キャリアごとの期待値 【番外編】私の推し書籍2
チームトポロジーを読んだ感想
はじめに 最近、チームってどんな構成にするのがいいんだろうか？と考えたことがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか？ チーム間のコミュニケーション（インタラクション）をどう設計するか？ 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか？ チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、１つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
Agile Japanは、日本中にアジャイルの価値を浸透させ、日本の変革を促進することを目指しています。あらゆる業界や職種の方が集まり、実践者も初学者もともに建設的な意見交換ができる場です。「Agile Japan 2022」に登壇したのは、株式会社セブン銀行・スクラムマスターの小林公洋氏。LeSSにおける1on1の取り組みの工夫と結果について発表しました。 セブン銀行・スクラムマスターの小林公洋氏 小林公洋氏：それでは「LeSSではじめる1on1」を始めたいと思います。 まず簡単に、自己紹介をさせてもらえればと思います。セブン銀行の小林と申します。主な経歴としてはシステム開発をずっとやってきています。約3年ほど前にセブン銀行に転職をしています。セブン銀行は4、5年ぐらい前から内製開発に取り組んでいるのですが、内製開発を行っているグループが「プロダクト開発グループ」というところになっており
CTOA Advent Calendar 1日目のバトンを受け取りましたので、1日目となる今回は、CTOに求められる役割の変化について、自分のこれまでの振り返りを兼ねて記事を書いてみようと思います。ちなみに今週はマガジンの連載をこちらの記事に代えさせていただければと。 普段はこちらのマガジンでソフトウェアと経営についてつらつらと書いています。ご興味ある方、年末の時間のあるときにでもご一読いただければ幸いです。 はじめにこの10年、エンジニアとしてのキャリアをスタートして今に至るまで、一桁人のスタートアップから1000人近い規模の開発組織を抱えた大企業まで様々な規模の組織のCTOを経験してきました。おおよその流れとしては、学生時代に小さなスタートアップを3社、その後Gunosyにて一桁人から60人前後の開発組織、現在はDMMのグループにて合計1000人弱の開発組織にてCTOをしています。 C
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
無能な同僚と働くということ。 - WETな備忘録
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
私が 1on1 でしていること - Mobile Factory Tech Blog
ITエンジニアの副業あれこれ - Runner in the High
メルカリを退職してロンドンのMetaに転職します 〜 外資Big Tech転職活動体験記｜松岡玲音｜note
エンジニアの技術土台となる知識を得るための本の紹介 - Qiita
なぜエンジニア組織をうまくマネジメントできないと悩む経営者が多いのか？ - Qiita
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ
今のチームに来てから最も生産性が上がった考え方｜牛尾 剛
部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
インフラエンジニアとしてなんとなく役立っていそうな書籍をリストアップする - Qiita
新刊『エンジニアリングマネージャーのしごと』発売のお知らせ
営業の崩壊と再生～営業の問題を解決する14の処方箋 | knowledge / baigie
エンジニアや上司が"有害な振る舞い"を改善するコツ - Qiita
無駄にGAFAの逆をいくな…というお話｜深津 貴之 (fladdict)
評価制度が機能するのは、前提に「腹八分目の年収」があるから 人事評価制度の構築・改良を成功させる6つのポイント
書籍『エンジニアのためのマネジメント入門』を執筆しました - STEAM PLACE
最強のツール「LangSmith」が登場した話【Python / LangChain】
ゆめみのiOSエンジニア研修を公開します！ - Qiita
1月28日、新刊『Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考』発刊！
機械学習APIでWebサイトの改善点を提案するサービスを作った話 - Qiita
脳みそが固くなったおじさんSEが機械学習を勉強してみた - Qiita
「目標を共有するチーム」より強いのは「悩みを共有するチーム」 スクラムマスターが実践して気づいた、1on1“7つのコツ”
組織規模とCTOの求められる役割の変化に関する雑記｜Matsumoto Yuki