D-Plus Tokyo #1 https://d-plus.connpass.com/event/315744/

先達エンジニアに学ぶ 思考の現在地 Online Conference https://findy.connpass.com/event/313119/

先達エンジニアに学ぶ 思考の現在地 Online Conference の発表資料です https://findy-code.io/events/v7KebEabaBDzh?fr=event_20240416

技育祭2024春のスライドです。 価値のあるプロダクトをつくるエンジニアになるための話と、自分がどういうキャリアでそうなっていったかを話します。

システムの開発や内製化支援を手掛けるゆめみは3月14日、スタートアップ・ベンチャー企業向けの開発支援サービスを始めた。事業成長に応じたエンジニア人材の採用が間に合っていない企業などの利用を見込むという。 プランは同社のエンジニアに向けてプロダクトの相談ができる「壁打ちプラン」（月額30万円）、少人数のメンバーで実際に開発を支援する「ミニマム開発プラン」（同100万円）、チームで開発支援に当たる「サービスグロースプラン」（同300万円）の3つ。ミニマム開発プラン以上では、同社のデザイナーやITエンジニア、プロジェクトマネジャーが状況に応じて参加し、短時間での開発を支援するという。

エンジニアに限らず、BlogやTwitter、OSS、登壇など、対外発信力がキャリアにおける強力な付加価値になることは知られるようになりました。 英語力がそうであるように、発信力は必ずしも必須スキルではありません。英語ができなくても活躍しているエンジニアはいくらでもいます。同時に英語がそうであるように発信力が有力な付加価値をもたらすスキルであることは事実です。 私自身、発信力が強みになっている分バイアスがあるので、あまりそのスキルの価値を過大評価して他人に押し付けるようなことはしたくありません。それに、エンジニアだったら発信力などではなく、純粋な技術力で評価されたいよな、という青臭い気持ちもまだどこかにあります。 ですから、全員が発信すべきだとは考えません。ただ、対外発信に興味を持っている人は後押しはしたいし、そういう人が増えてほしいとは強く思っています。なぜならば、それが単純に楽しいから

会社がリファクタリングに賛同してくれないたったひとつの理由一定の工数をかけてリファクタリングをやったほうがいいことは（少なくとも筆者の観測範囲では）エンジニアリングのバックグラウンドがない人でもだいたい理解しています。 上司の無理解をあげつらっても仕方ありません。 リファクタリングの実施を渋る真の原因が工期や予算の問題であることはあまりないとおもいます。タイミングの問題である可能性はありますが。 必要であればコストをかけることにも同意してくれます。 「技術的負債は過去のビジネス上の選択によって生じたまさに負債なので、計画的に返済しましょう」っていえば、多くの経営者は理解を示してしてくれるでしょう。 本当に無理解ゆえにリファクタリングをしないのであれば技術的には死んでいる組織なので、エンジニアとして幸せになりたい場合は逃げ出したほうが賢明です。 というわけで、本稿ではそういう組織においてもな

はいどうもー。クドウマサヤ(@masaya_dev)です。先日、東京からはるばる広島まで行ってきました。そう、YAPCという技術カンファレンスのために。 気づけば開催からもう2週間が経ち、東京へ帰ってきてからいろんな人にYAPCの思い出を語りました。語っていない日の方が少ない。思わず人に話したくなってしまう、それくらい心に残るイベントでした。 というわけで遅ればせながら思い出を綴っていこうと思います。ブログを書くまでがYAPC。 結論「良いLTは結論から」なんてエンジニア界隈ではよく言われますが、この記事でも先に結論を。 本当に参加できてよかった。 プログラミングが好きで、エンジニアリングが好きでWebエンジニアとして働いてきて十数年。 あの杜甫々(とほほ)さんをはじめ、dankogaiさん(@dankogai)、t_wadaさん(@t_wada)、naoyaさん(@naoya_ito)、

どうもお疲れ様です。MESIです。 これは私が駆け出しの新卒1年目の頃でしょうか。 ある社内のつよつよエンジニアからこう言われました。 「MESIよ。流行りのフレームワークの使い方を覚えるのではなく、土台を理解しなさい」 彼はそう言い残すと1冊の本を残し会社を去っていきました。 これ。 託された本を読んでみたものの当時の私には難しすぎました。 理解ができないのですが、何が理解できないのかがわからない。そんな状態でした。 毎日この本とにらめっこをしましたが、時間だけが過ぎていきました。 大学でコンピュータサイエンスを全く学んでいない状態で入社した当時の私には難しすぎたのです。 私は諦めずにOS関連の低レイヤーの本を読み出しました。そして以下のループにハマりました 本の内容が理解できない ↓ 本を理解するために別の本を読む ↓ 理解できないのでまた別の本を読む いきなり難しい本にチャレンジをし

西谷圭介 国内SIerで金融系基幹システムの開発等に従事した後、クラウドサービスの開発ならびに新規事業立ち上げを経て2014年にアマゾンウェブサービスジャパン株式会社（現アマゾンウェブサービスジャパン合同会社）へ。国内企業のクラウドシステム設計支援を実施しつつ、日本におけるサーバーレス市場の創出と普及に尽力。プロトタイプ開発を行う部門の立ち上げに従事した後、2021年6月より現職。CTOとしてプロダクトを国内外に提供すべくすべてのレイヤで開発に従事している。フロントエンドが好きでインフラもそこそこわかるバックエンドエンジニア。 X（@Keisuke69）・ブログ 第1回「西谷圭介が振り返る、育休なしで乗り切った娘2人の誕生と仕事の両立」では、子どもができる前後の生活の変化や仕事への影響などについてお話しました。子どもが生まれたことで時間の使い方や過ごし方を変える必要があり、その中で「エンジ

この記事はNuco Advent Calendar 2023の18日目の記事です。 はじめに 本記事ではGithubレポジトリTop28を紹介します！ Githubレポジトリは日々の業務や学習に役立てることが可能です。必要な機能や学習教材は、無料で利用出来る高機能なものがあるのなら積極的に利用して役立てるべきです。 以下の内容に分けて合計28個のGithubレポジトリを紹介します！ 開発用Githubレポジトリ 学習用Githubレポジトリ QOL高めのエンジニアとして日常を過ごしたい方は参考にしてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。

はじめに 私は、さくらインターネットというクラウドサーバの会社の社長をしていて、よく経営者の方からのメンタリングのリクエストをいただくことがあります。 その中で多くの割合を占めるのが、ITエンジニア(以降、エンジニア)のマネジメントと、エンジニア組織の構築をどのようにすればいいのかというテーマです。 確かに、どんなビジネスをするにしても、単にSaaSやノーコードツールを活用するだけでは足りなくて、自分たちでシステム開発しないといけないケースが増えてきているのは、間違いないなと思います。 外注をしてシステム構築をするケースももちろん多いですが、基幹システムのような使いにくくても自社の社員が我慢すればいいものと違って、自社のお客様向けのシステムだと使いやすくないとお客様が離脱してしまいますし、常にアップデートをし続けて、最良のUI/UXを作ることが業績に直結します。 要は、今のデジタルシステム

Developers CAREER Boost 2023 登壇資料

技育祭2023秋 DAY1 HALL C 14:30 - 15:15 「エンジニアを目指す君たちはどう生きるか　～ソフトウェアアーキテクトのすゝめ～」 の登壇資料です。 https://talent.supporterz.jp/geeksai/2023autumn/information/#1021-1430-HallC

はじめに 現在ITエンジニア歴16年目でこれまでなんどかチームリーダー(プロジェクトリーダー)を経験してきましたが、数年前は上手くいっていたけど、ここ1年位のチームではなかなかうまく行かないことが多く、メンバーからのクレームが上長経由で伝えられてくることがあります。 クレームを伝えてくるメンバーの多くが経験が浅いエンジニア(若手、未経験中途入社)であり、まだITエンジニアとしての業務や商流が分かってない部分もあるゆえのエゴのようなクレームもあるのですが、中にはリーダーとして気をつけるべきだなと思ったことがあったので、まとめておきたいと思います。 なお、経験が浅いエンジニアと主語大きめに書きましたが、数年前にリーダーをした際にQAから転身したてのITエンジニアや、20台中盤くらいの方もいましたが特にクレームはなかったので「メンバーによる可能性はある」ということは書き添えておきます。 また、上

インフラエンジニアの肩書きをSREに変えるタイプの組織変更は近いところから遠いところまでいろんなところで見かけてるんだけど、改めてそれって名前変えただけじゃないよね？って問いかけは個人が組織に、組織が個人にそれぞれ相互でした方がいいと思う。 インフラエンジニアって言葉もまあ定義が死ぬほど広くてどこからどこまで指すのってのは組織によって違うね大変だねって話ではあるんだけど、SRE(Site Reliability Engineering)やPE(Platform Engineering)はインフラと必ずしも対応関係にあるわけではないんだよな。 Platformってのは言ってしまえば会社のエンジニア組織の中で自分達に最適化された基盤を作る人たちの集合体とそのプロダクトそのものを指していて、Platform Engineering組織の中には当然フロントエンドエンジニアやデザイナー、プロダクトオ

TOPインタビューエンジニア不足は「業界全体」の問題。LayerX松本CTOに聞く「自走できるエンジニア不足」から脱する方法 日本CTO協会 理事　株式会社LayerX 代表取締役CTO 松本 勇気 東京大学在学時に株式会社Gunosy入社、CTOとして技術組織全体を統括。またLayerXの前身となるブロックチェーン研究開発チームを立ち上げる。2018年より合同会社DMM.com CTOに就任し技術組織改革を推進。大規模Webサービスの構築をはじめ、機械学習、Blockchain、マネジメント、人事、経営管理、事業改善、行政支援等を歴任。2019年日本CTO協会理事に就任。2021年3月よりLayerX 代表取締役CTO就任。開発や組織づくり、及びFintechとPrivacy Techの2事業の推進を担当。2023年、LayerX LLM Labsを立ち上げ所長に就任 多くの企業がエンジ

2023年度リクルート エンジニアコース新人研修の講義資料です

組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ

会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない