2025-08-14 かっぱNight vol.1 「はじめての転職講座」
はじめての転職講座/The Guide of First Career Change
2025-08-14 かっぱNight vol.1 「はじめての転職講座」
ソフトウェアエンジニアから AI エンジニアへスキルチェンジ - As a Futurist...
AI 始めました！というと、ミーハーな感じがありますが、15年ほどやってきたソフトウェアエンジニアとしてのキャリアは終わりにして、 2カ月程前から AI エンジニアになりました。ここ5年程は、過去の経験の切り売りしかしていない感じがずっとあったのですが、 全く新しいことを始めて1から勉強し直しているところでとても楽しいです。 Fifteen Years of Dev, Deleted — Hello AI 目次 AI エンジニアって何？ 今までのAI/機械学習と違うところ 自律的なエージェントの構成要素 自律的なエージェントが人間を拡張した先 未来への不安 ブラックボックスを超えて 自然言語が主役になる時代のソフトウェア開発 やりたいこと AI エンジニアって何？ 雑に言えば、この表現が言いえて妙だと思います: 「LLM インテグレーション屋さん」 LLM インテグレーション屋さんになるこ
ソフトウェアエンジニアが抱えやすい21の苦労 - mtx2s’s blog
ソフトウェア開発の現場でも、日々、苦労が絶えない。知らず知らずのうちに、エンジニアを消耗させる問題が潜んでいる。 苦労は、日常の風景に溶け込みやすい。それが当たり前の状態であり、疑問すら抱かれない。「そういうものだ」と思い込む。いや、苦労することに、そもそも違和感を持てないのだ。 日常化した苦労は、改善されることがない。違和感がないからこそ、問題として扱われない。そして、原因に目が向けられることもなく、風景に溶け込んだまま、空気のようにあり続ける。 つまり、苦労を軽減するには、日常風景の中から問題を見つけ出す必要がある。そのための第一歩が、「気づく」ことだ。問題というのは、気づかなければ解決のしようがない。学校の試験のように、誰かに出題されるものではないのだから。 本記事では、「気づく」ための視点を言語化し、手がかりとして整理している。 ソフトウェアエンジニアリング業務でありがちな苦労を、
強みを2つ以上持つ - Konifar's ZATSU
強みを2つ以上持つことを意識しておくほうがいいと思っていて、雑に書きなぐっておきたい。 1つの領域で圧倒的な強みを作るのは大変。「チョットデキル」、「完全に理解した」を何度繰り返しても、やればやるほど上が見えてくる。 2つ以上の強みを持つというのもそれはそれで大変なのだけれど、パレートの法則に照らせば80点くらいまでは高めやすい。ある程度自分の強みを作ったらそれをより極めていくのもよいが、他の領域も30%くらいやってみるというのがいいかもしれない。 プロダクトマネジメントが強みだとすると、他領域をやっている中で "プロダクトマネジメント的" な発想を転用できることが多いことに気づくと思う。営業が強みだとすると、相手の求めることを突き詰めて考えるといったエッセンスが採用など人事領域にも活かせるかもしれない。 デザイナーがモバイルアプリやWebフロントエンドの実装をやってみるのもとてもいいと思
日本におけるDevRelとは何なのか、現状と課題と今後 - 941::blog
数日前に𝕏上で「日本のDevRelって何なんだ？」という議論が巻き起こり、エンジニアや今DevRelを名乗っている人たち周辺で大きな話題となりました。わたしもかつてDevRelという名前のチームで働き、その活動に意義があると思っているので話題を整理してみたいと思います。今や様々な役割を内包する名称としてIT・WEB業界で一定の認知度を得ているDevRelとは何をする人なんでしょうか。 ここに書いたものはあくまでも個人的な視点と意見ですが、関連する皆さんは一緒に考えてみてもらえると嬉しいです。𝕏でもブログでもPodcastでもYouTubeでもなんでもいいので、是非ご意見ご感想をお寄せください。 この記事を人力で三行でまとめると アメリカ式のDevRelが日本で改変されて使われるようになったよ なんでこうなっちゃったか考えてみるよ 本来的なものだけを残して、ほかは名前を変えるのもいいんじ
エンジニアと顧客理解 - Cybozu Inside Out | サイボウズエンジニアのブログ
この記事は、CYBOZU SUMMER BLOG FES '24 (kintone Stage) DAY 8 の記事です。 kintone 新機能開発チームでエンジニアをしているぶっちーです。 私のチームでは、有志のメンバーで集まって顧客、ユーザーとの接点の情報がたくさん詰まった「コンタクト履歴」を読んで、顧客の理解を深める活動を行いました。 コンタクト履歴とは、営業やカスタマーサクセスなどのメンバーと顧客のやり取りが記録されているデータベースです。 数ヶ月このコンタクト履歴を読むことを続けた結果、理解が進んだ感覚はあるものの、まだまだ改善の余地があるのではないかと感じました。そこで一度立ち止まって、なぜエンジニアが顧客理解をすると良いのかについて改めて考えてみました。 なぜエンジニアが顧客理解に取り組む必要があるのか 私がなぜ顧客理解に取り組むのか？それは「良いプロダクトを創る」ためです
開発者イベントやコミュニティ参加についての期待や効果 - 株式会社ヘンリー エンジニアブログ
VP of Engineeringの id:Songmu です。冒頭に、大事なお知らせですが、今週土曜日(6/22)に開催される、Kotlin Fest 2024にヘンリーはスポンサーをしています。スポンサーブースも出展しますので、是非お立ち寄りください。私もいます。 また、Henryの開発者の一人でもあり「Kotlin サーバーサイドプラグラミング実践開発」の著者でもある、 @n_takehata が、2024年版 Kotlin サーバーサイドプログラミング実践開発というタイトルで登壇します。是非こちらも聞きに来てください。 ヘンリーも社員数が増えてきたこともあり、このスポンサーを機に、イベントやコミュニティ参加に関する制度づくりを始めました。また、それらに参加する社員も増えて欲しいと思っています。そのために、改めて、社員がイベントやコミュニティに参加する意義を考え直して整理した内容が本
複数の企業でデータエンジニアとして求められたスキル - yasuhisa's blog
最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力
データアナリストからアナリティクスエンジニアへ：スキルギャップと克服 - 現実モデリング
はじめに 前にも書いたが、「アナリティクスエンジニア」を採用するのは難しい。そもそもアナリティクスエンジニアの知名度が低いし、スキルを持っている人が採用市場に少ない。 しかしニーズはある。以下のようなケースでは、アナリティクスエンジニアはかなりほしい人材だ。 会社全体でデータ分析に対するニーズが高い場合 例えば、競争環境の激しいマーケットを相手にしている状況など この場合、データに対する需要をアナリスト単体では満たすことができなくなるため、ダッシュボードを利用して分析環境をスケールさせるのが常套手段になる この段階でテーブル設計・パイプライン設計が行われるため、アナリティクスエンジニアの出番となる 定常的なデータ分析が求められている場合 日時でKPIを見る場合など、分析がパターン化できそうな場合 アドホックにやるのが面倒になってきたタイミングでテーブル設計・パイプライン設計が行われるため、
2023年にエンジニアな私がマネジメントに目覚めてから読んでよかった3冊 - Lean Baseball
タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ
40代よわよわエンジニアの転職は打ちのめされてからが本番だった
久しぶりに転職をした。 理由は「上司がクソ・年収も上がらない」という至極単純なもの。 自分は人手不足と言われているエンジニア業界でも、人が居ないと嘆かれている言語のエンジニアである。 正直に言って、今までは求人に乗っかればそれなりに内定を取れたので、そんな感じでいくだろうとタカをくくっていた。 ところが、今回の転職はめちゃくちゃ難航した。 受けたカジュアル面談は20社近く。 約半数の選考に進み、スキルチェックで落とされたのが3社、面接で落ちたのが2社、内定獲得したが辞退したところが3社。 打率3割は高いと思うかもしれないが、経験者なら誰でもOKのSESなので自慢にならないんだ。すまんな。 最終的には良さげなところを見つけ転職は幕を閉じたが、かけた期間はおよそ6ヶ月。 それをぼちぼち忙しい業務の合間と土日に行っていたので、もう身も心もすっかり摩耗した。 ようやく落ち着いて新しい環境にも慣れた
【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
どうして自分を過小評価するのかと言われた話
忘年会の時に、「おじさん(私のこと)って自分のことをできないエンジニアであるふりをするけど、どうして？」って言われたのだが、いざどうして自分がそういうふりをするのかを言語化しようとしたら難しかったので、時間をかけて言語化してみた。 ぶっちゃけ自分はできないエンジニアではないと思っている まず「できる」「できない」の定義だが、ここではしない。 いろんな人と比較されて「できない」側の人間として扱われてきた自分にとってその定義は考えたくない。 「できない」の定義は人を傷つけると思うのでしたくない。 なのであくまで読者の感覚的な尺度で解釈して欲しい。 自分はいわゆる別業種からの転向組で、エンジニアとして働き始めたのは 2018 年なので今年で 5 年目エンジニアだ。別業種からの転向ということでコンピュータサイエンスを大学で学んだ者・小学生の頃からバリバリやってきた者・新卒でエンジニアになって研修や
Pull Requestの質を向上させるために行った戦略/戦術の話 - JMDC TECH BLOG
株式会社JMDCでモバイルアプリエンジニアをやっている @mrtry です。入社した当初、モバイルアプリチームのエンジニアは私一人だったのですが、現在では4人になりました。最近はPull Requestのレビュー数も爆増しており、とても疲弊しがちです(嬉しい悲鳴)。たいへんポイントを減らすために、最近Pull Requestまわりの運用を整えたので、今日はその話をしたいと思います。 Pull Requestのレビューがたいへん 現在、モバイルアプリチームでは、3つのプロダクトの開発をしています。各プロダクトに1名ずつassignされており、リードエンジニアとして私が一通りレビューをしている状況です。そんなこともあり「Pull Requestのレビューがたいへん」というのが最近の悩みでした。 Pull Requestのレビューをするとき、私は以下のような観点でレビューしています。 機能仕様レ
伸ばすのが難しい能力
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
中年IT人材おじさんの平穏 - megamouthの葬列
IT人材が不足してるんだって。零細Web制作会社で言えば、退職者が残したubuntu12サーバーに眠るRails5アプリをすぐにDDDでマイクロサービスに再構成して、jQuery満載のコードを全て読み下したうえで、フロントエンドをReactかなんかのSPAに全部書き換えて、E2Eを含めた自動回帰テストを整備して、ついでにCIも整備して、k8sにデプロイできるようにして、ドキュメントは小まめに残し、職場の心理的安全性を落とさず、飲み会にはかかさず参加、役員との関係も良好で、定期的な勉強会も開いてくれて、それでも残ったプライベートの時間を最新の技術動向やセキュリティ情報の収集に全量突っ込んでくれる、そんなごく当たり前のエンジニアが不足している。ついでに言うと、人類の原罪を一身に贖ってくれるスキルの持ち主も不足しているらしい。多分、我々はもっと求人サイトに金を払うべきなんだろうね。 同業者から、
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
【登大遊】天才エンジニアの安寧を求めない生き方「日本で“大義”を持って働く選択は有利」 - エンジニアtype | 転職type
エンジニアがいい仕事人生を歩むために、「心と体のコンディション」と「仕事のパフォーマンス」にはどんな相関関係があるのだろう？ 高いパフォーマンスを発揮するエンジニアの経験談から「心・技術・体」のベストバランスを学ぶ！ 2020年、NTT東日本と独立行政法人情報処理推進機構（以下、IPA）が提供した、無償かつユーザー登録不要で利用できるシンクライアント型VPN『シン・テレワークシステム』が話題を呼んだ。 このシステムをわずか2週間で完成させたことで称賛を集めたのが、自ら経営するソフトイーサの代表取締役、筑波大学産学連携准教授、IPA技術研究室長、NTT東日本特殊局員と、4足のわらじを履くプログラマー・登大遊さんだ。 優れたアウトプットを出し続ける登さんだが、「パフォーマンスと自身のコンディションは、基本的に常に一定」なのだという。登さんはなぜ、ブレずに高いパフォーマンスを出し続けることができ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
作業配信をしているエンジニア一覧
WEB+DB PRESSと私
