AI のお陰で、今エンジニアの人はめちゃくちゃおいしい時代かもしれない。｜牛尾 剛
X見てると、今日ソフトウェアエンジニアが近い将来オワコンになるか否かが明確にわかると思うな。自分的にはならんと思うけど、なったらそれは素晴らしい事で凄いイノベーションだよな。そうなったらブルースマンでもやるかw — 牛尾剛『世界一流エンジニアの思考法』(文藝春秋)🎸Tsuyoshi Ushio (@sandayuu) August 7, 2025 本心で言ったのだが、予想通りそうはならなかった。今回の AI ブームが過去と圧倒的に違う部分は、わけわかっていない人が言っているのではなく、ガチのエンジニアでも、「あー、わしもうリプレースされて、エンジニアいらんようになるかもしれん」と本気で思ったところだと思う。まぁ、実際そうかもしれないが、問題はどれぐらいでそうなるか？がまだ全然わからないということである。 「オワコン」と思われているかもしれないが、もしかすると今ソフトウェアエンジニアをやっ
「生成AIを使いこんでいる人」だけが知っていること
最近は生成AIも一通り新発表ラッシュが終わり、ChatGPTが登場した直後の「熱狂」は一通り収まってきたように感じる。 おそらく現在は 「ちょっと触ってみて、すごいと思ったけど、あまり実用性を感じられなくて、今はたまに使うくらい」 という人が多いのではないかと思う。 いわゆる「失望の谷」に入った状態だ。 なぜ生成AIは「失望の谷」に入ったのか。 その原因は明らかで、生成AIを使って、自分が狙っているクオリティの成果品を出すのが難しいし、プロンプトを考えるのが面倒からだ。 例えば、こんな状況を想像してほしい。 朝出勤してきて、最初に 「昨日一緒に飲みに行った、お客さんの部長さんに「お礼」のメールを書きたい」 とする。 多くの方が想像する通り、お礼のメールは結構書くのが面倒だ。 そこで、「生成AIを使ってみよう」と、次のようなプロンプトをChatGPTに打ち込むとどうなるか。 昨日一緒に飲みに
「普通エンジニア」はみんなシアトルに来たらええのにと思う話｜牛尾 剛
アメリカで、ソフトウェアのエンジニアをするというのは、ごく一部のものすごく優秀なエリートが達成できる境地…みたいに思っていないだろうか？そんなことは無いですよ。アホにゃんにゃんで、日本ではプログラマとして通用しなかった自分でもやれています。５年たった今でも自分的には最高に居心地が良くて楽しい！だから、なぜ私がタイトルのように思うかを解説したいと思う。 シアトルでエンジニアをやる楽しさ 本記事はもちろんマイクロソフトはなんの関係もなくて、自分の意見であるが、私はマイクロソフトの Azure Functions の開発者をやっている。自分の性格をあげると、エヴァンジェリストとかやってたので陽キャと思われる人もいるかもしれないが、私は趣味がギターとプログラミングの陰キャで、人と一緒にいるより一人の時間がないと死ぬタイプの人間だ。（ちなみに、陽キャの人は楽しめないという話ではありません） アメリカ
エンジニアの未来と生成AIについて質問させて頂きたいです。情報系の学部に所属している者なのですが、自分が何時間もかけてやった課題をChatGPTに投げるとほんの数秒でサンプルコードが提示されます。自分の課題のレベルが低く、上のレベルでは自力でプログラミングをすることが必要なのは理解しているのですが、何時間もかけたものが一瞬にして解決される様にAI発展の喜びより冷酷さを感じてしまいます。エンジニアとして働きたい者としてどのようにこの事実と向き合うべきでしょうか？ | mond
エンジニアの未来と生成AIについて質問させて頂きたいです。情報系の学部に所属している者なのですが、自分が何時間もかけてやった課題をChatGPTに投げるとほんの数秒でサンプルコードが提示されます。自分の課題のレベルが低く、上のレベルでは自力でプログラミングをすることが必要なのは理解しているのですが、何時間もかけたものが一瞬にして解決される様にAI発展の喜びより冷酷さを感じてしまいます。エンジニアとして働きたい者としてどのようにこの事実と向き合うべきでしょうか？ ソフトウェアエンジニアの仕事について誤解があるようです。 確かに書けと言われた題材を動くまで持っていく力は大切ですが、それよりもっと大切なのは動いている物を思い通りにする力です。ソフトウェアエンジニアの仕事の9割以上は既に書かれているコードに対して何らかの変更を加える事であって、どこをどう書き換えるべきかという疑問に対して生成AIが
ドキュメントとしての詳細設計書と、プロセスとしての詳細設計 - 勘と経験と読経
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から
『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を読んだ - Magnolia Tech
ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 作者:Vlad KhononovオライリージャパンAmazon 訳者の増田亨様より献本いただきました ありがとうございます さっそく読んでみました システムは、なぜ必要とされるか？という「why」が有り、次に何を作るべきか？という「what」が有り、それを受けての「how」が有る。 （たまに突然「what」だけが有ったり、なぜか「how」の議論だけが先行する事例も聞くけど、それは順番が間違っているだけなので、その問題はここでは触れない） この「why」と「what」と「how」が上手く繋がった状態を作り上げていくために、過去にさまざまな開発方法論が考案され、語られてきた。 「ドメイン駆動設計」は、開発方法論として「名前がついて、生き残ってきた手法」の一つであり、昨今複数の解説書が発行されている唯一の手法と言え
開発生産性カンファレンス2024に参加しました - Timee Product Team Blog
タイミー QA Enabling Teamのyajiriです。 去る6月28日〜29日の2日間、ファインディ様主催の「開発生産性カンファレンス2024」に参加してきました。 （タイミーには世界中で開催されるすべての技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、今回もこれを利用して新潟からはるばる参加してきました。） productpr.timee.co.jp タイミーでは弊社VPoE(VP of ええやん Engineering)の赤澤の登壇でもご紹介した通り、チームトポロジーを組織に適用し、プロダクト組織の強化と改善にチャレンジしています。 speakerdeck.com この登壇でも紹介されておりますが、私自身もイネイブリングチームの一員として、プロダクト組織全体のQA（品質保証）ケイパビリティの向上や、障害予防プロセスの改善に取り組んでいます。 開
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広…
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
オープンソースプロジェクトを有料化して月収100万円の事業家に転身したソフトウェア開発者
インターネットを形作っているさまざまな技術は、オープンソースプロジェクトに携わる多くの人々の支援と献身によって支えられています。電子メールクライアント「EmailEngine」を作ったソフトウェア開発者のアンドリス・ラインマン氏が、オープンソースプロジェクトの作者から有料APIの開発者に転身するまでの経緯とその結果をブログでつづりました。 How I turned my open-source project into a business https://docs.emailengine.app/how-i-turned-my-open-source-project-into/ エストニアの技術者であるラインマン氏が、最初にオープンソースプロジェクトを立ち上げたのは、記事作成時点からさかのぼること約15年前の2010年のことです。 Node.jsアプリケーション用のメール送信モジュールで
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
チームトポロジーを読んだ感想
はじめに 最近、チームってどんな構成にするのがいいんだろうか？と考えることがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか？ チーム間のコミュニケーション（インタラクション）をどう設計するか？ 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか？ チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、１つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
カジュアル面談 逆質問テンプレ - yuiseki
御社の事業の立ち上げの経緯や意思決定や試行錯誤のプロセスについて、もしご存知でしたら、なるべく詳しく教えてください
『ソフトウェアアーキテクチャの基礎』島田浩二氏が語る、エンジニアが最初に知っておくべきアーキテクチャリテラシー
ソフトウェアアーキテクチャはシステムの成功に不可欠な要素であり、ソフトウェア開発者にはこの分野における効果的なスキルが求められる。しかし、その学習資料はまだ十分ではないのが現実である。株式会社えにしテックの代表取締役 島田浩二氏は、ソフトウェアアーキテクチャに関する書籍を多数翻訳している。Developers Summit 2023 Summerに登壇した島田氏は、数々の書籍から学んだソフトウェアアーキテクチャの重要なエッセンスを紹介した。 ソフトウェアアーキテクチャとは？ 3つの定義を紹介 島田氏は2009年に株式会社えにしテックを設立。2011年からは一般社団法人日本Rubyの会の理事を務めている。島田氏が翻訳に携わった書籍には、『進化的アーキテクチャ』『ソフトウェアアーキテクチャハードパーツ』、『ソフトウェアアーキテクチャの基礎』『Design It!』（いずれもオライリージャパン）
エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つです
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
転職してソフトウェアエンジニアをやっている - ogijun's blog
ひさしぶりにblog記事書きます 本エントリはカケハシ Advent Calendar 2023 Part 2の 15日目の記事に入れてもらってます。カケハシ Advent Calendar Part 1 もあり、様々な職種の方が記事を書いているので、ぜひご覧ください。といってもそもそもこのblogでは初出であるカケハシってなんだ？という話からしなければなりません。このAdventが書くきっかけになったのですが、そのあたりの近況報告も兼ねて最近こんなことをやっているというアップデート記事です。 転職していました 実際に新しい所属になったのは今年の10月1日からで、もう2ヶ月半くらい経っているのですが、本当にあっという間でした。Twitterではいろいろ投稿していたので見ていた方はご存知かも知れません。現在は株式会社カケハシというところで、ソフトウェアエンジニアとして新しい事業ドメインを起ち
生成AI入門：議事録を答えるチャットAI（RAGアプリ）を作ってみよう【プログラミング不要】
連載目次 現在、企業への生成系AI*1の導入が急速に拡大しています。2023年10月23日に日本マイクロソフトが記者向けに発表した内容によれば、日本国内でAzure OpenAI Service（Microsoftが提供するクラウドAIサービス）を活用している企業は560社以上、全世界では1万1000社を突破しています。このような状況から、「うちの会社も生成系AIを導入すべきか？」「生成系AIが何の役に立つのか？」と気になっている方は少なくないでしょう。 筆者は、生成系AIが多くの業務効率化に不可欠なテクノロジーであり、大半の企業が導入すべきだと考えています。例えばこの記事自体も、段落ごとに「分かりやすいか？」とChatGPT（チャットAI）に質問しながら推敲（すいこう）を重ねました。また、GitHubというサイトが公開したアンケート調査結果によれば、米国のソフトウェア開発者の92％が既に
40歳を過ぎてもソフトウェアエンジニアを続けてるって話 - Mitsuyuki.Shiiba
昨日、ゆのんさん（ https://twitter.com/yunon_phys ）が社内の勉強会で「エンジニアリングマネージャとは？」って話をしてくれて、面白いなぁって思いながら聞いてた。 今日は @yunon_phys が社内勉強会で、エンジニアリングマネージャについてお話をしてくれてとてもよかった。こんな話が社内で聞けるのって福利厚生だなぁと思いながら聞いてた。— SHIIBA Mitsuyuki (@bufferings) October 13, 2023 その中で「エンジニアリングマネージャが見ることのできる範囲はめちゃ広いから、すべてを完璧にしようとするんじゃなくて、その場に応じてスキマを埋めるような動きができるといい。組織の成長とともにその動きも変わっていく」ってことを言っていて、これって自分のソフトウェアエンジニアとしての動きにも似たところがあるなぁと思ったので雑にメモ。
DDDでの要件定義〜実装までの流れについて解説します
本記事では、ソフトウェア開発手法の一つであるDDD（domain-driven design）を使って要件定義〜実装を行う際のプロセスやポイントについてまとめていきます。 （書籍「ドメイン駆動設計モデリング/実装ガイド」の内容を大いに参考にさせていただいていますが、独自の内容・考察も記載しているつもりです。） DDD とは？ DDD（domain-driven design）は日本語に訳すとドメイン駆動設計で、ソフトウェア開発手法の一つです。 ドメイン駆動という言葉から、ドメインというものが重要そうだということは伝わってくると思いますが、そもそもドメインという言葉が抽象的でわかりにくいですよね。 ドメインは直訳すると「領域」ですが、DDD で指している「領域」とは「ソフトウェアで問題解決しようとする対象領域」です。 そして、① ドメインについての理解を深めてモデルを作成し（DDD では、後
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアを目指す君たちはどう生きるか ～ソフトウェアアーキテクトのすゝめ～
