2025年のアウトプットふりかえり - t-wadaのブログ
2025年はソフトウェアの作り方が大きく変わった年として記憶されるだろう。自分にも特に印象に残る一年だった。仕事で2025年のアウトプットをまとめる機会があったので、記録として残しておくため、せっかくなので久しぶりにブログエントリを書くことにした。年内に仕上げたかったが、いろいろあって年始になってしまった。ブログを書くブランクが長いとこうなる。 なお、当たり前ではあるが、このブログエントリは 100% 私が書いており、記述にも構成にも AI は関与していない。 1月 年末年始は義実家で過ごして考え事をすることが多い。そして、2024年末の考え事はやや暗いムードだったように思う。当時はコーディングエージェントがメキメキと力を伸ばし、人間がプログラミングする領域が削り取られ始めていた。人間がコードを書くことはもうなくなるのだろうか、俺はコーディングが大好きなんだけどな……とモヤモヤしながら過ご
AI時代に今からITエンジニアを目指す若者にオススメする10冊の本 2026年版 - じゃあ、おうちで学べる
はじめに AIは、あなたが聞いたことにしか答えない。 聞かなかったことは、永遠に教えてくれない。あなたが何を知らないのか、AIは知らない。 2026年だ。AIに聞けば何でも教えてくれる。コードを書いてもらい、設計を相談し、ドキュメントを要約させる。便利だ。では、なぜ本を読むのか。300ページもある本を、最初から最後まで読む必要があるのか。 本は違う。本は、聞いていないことを語りかけてくる。知らなかった世界を見せてくる。持っていなかった問いを、手渡してくる。「そんなこと、考えたこともなかった」。そういう瞬間が、本にはある。AIとの対話では、たぶん起きない。 AIは効率的だ。知りたいことに、最短距離でたどり着ける。でも、最短距離で歩いていると、道の脇にあるものが見えない。著者が失敗した話、遠回りした話、「今思えば間違いだった」という告白。そういう「寄り道」が、不思議と頭に残る。正解は忘れる。で
株式会社スタディストでのDevin導入事例
ツール導入前の課題社内ではCursorやGitHub CopilotなどのAIコーディングツールの導入が進んでいたものの、Devinのような自律型AIコーディングツールに関する知見は不足していました。 また、こうしたツールは実際のプロダクトコードで検証しなければ、正しい判断が難しいものです。 さらに、利用料金が高額で個人検証が容易ではないこともあり、プロダクト開発でAIを活用することでどのようなパフォーマンス向上が得られるのかを、組織として慎重に見極める必要がありました。 どのような状態を目指していたかDevinを実際の開発環境で試し、その実用性や限界を正確に把握したいという目的がありました。 実際の開発業務に近い立場のメンバーが評価を行うことで、AIの出力や振る舞いをよりリアルに検証し、優秀なメンバーのアウトプットを増幅できる可能性を探ろうと考えました。 また、AIツール活用によるパフォ
テストが設計を駆動するなら、評価は何を駆動する？ 〜テスト駆動開発と評価駆動開発、「先に定義する」ことの力〜
テスト駆動開発（TDD）を実践したことがある人なら、テストが設計を駆動するという感覚がわかるかもしれません。 t-wada氏の言葉を借りれば、「テストを先に書き、それに対応するコードを書いていくと、使う側の期待に沿ってコードを書くことになります」——結果として使いやすい設計が生まれる。 AIプロダクト開発ではどうでしょう。 LLMの出力は非決定論的で、従来のテストだけでは乗り切れません。 「この入力なら、この出力」というアサーションができない世界です。 そこで登場するのが評価（Eval）、そして評価を開発サイクルの中心に置く考え方、Eval-Driven Development（評価駆動開発 / EDD） です。 テストが設計を駆動するように、評価がAIの品質を駆動する——最近改めてそう感じています。 （EDD自体、TDDにインスパイアされているので当たり前といえば当たり前なのですが） こ
内部昇進マネジャーと外部からやってきたマネジャーの違い（パート１） ‣ ミドルマネジャーの部屋
外部招聘マネジャーは、プロパー社員の部下から向けられる「お手並み拝見」という視線を感じながら、苦労や気遣いが内部昇進マネジャーより多いのではないだろうか。 そんな問いに対して自ら探求してみたいと思い、大学院に通うことを決めたのが約１０年前です。 私の通っていた大学院は「研究者を養成すること」に熱心であったこともあり、研究のお作法に関しては、かなり丁寧に教えてもらった気がします。（だいぶ忘れかけていますけど・・・） 習ったばかりの拙い統計スキルで分析を用い、何とか修士論文を提出しました。しかし、提出後に振り返りますと、「もっとこうすれば良かった」と思うことが多々ありました。 そこで今回、当時収集したRawデータをもとに、生成AI（Geminiさん）を使い、分析し直したり、新たな分析をしてみました。 データが古いこともあり、今回の分析結果を堂々と語るつもりはありませんが、それでも外部招聘マネジ
仕様駆動開発で作った Spec ファイルってどうするの ? ~ 仕様とコードの乖離問題を考えてみる ~
デベロッパーのためのクラウド活用方法 仕様駆動開発で作った Spec ファイルってどうするの ? ~ 仕様とコードの乖離問題を考えてみる ~ 2026-01-05 | Author : 宇賀神みずき (しょぼちむ) こんにちは！アプリケーション開発コンサルタントのしょぼちむです。 2025 年 11 月 に Kiro が一般公開され、Kiro の得意分野である仕様駆動開発も徐々に注目を集めてきています。仕様駆動開発では、明確な仕様を起点に設計・実装を進めていくことで、AI を活用した開発を効率化できます。 しかし、「仕様を定義したファイル (Spec ファイル) は一時的なもので、正式なドキュメントは別途作成・管理する」という方も多いのではないでしょうか。 その結果、次のような「よくある困りごと」が発生します。 バグ修正時に「なぜこの設計にしたのか」が分からず、影響範囲の特定に時間がかかる
Creating space
A single word of advice, given to all startups, and to CEOs of large companies, and they in turn to their teams: “Focus!” But what does that mean, precisely? And anyway isn’t quantity sometimes in fact better than quality? Don’t we need to test a bunch of stuff instead of trying to make one thing work? Only when we stop doing most things, do we have the time and energy to fully, deeply execute the
セキュリティ学習用の脆弱なWebアプリケーションを作ってみた【React + Node.js + Docker】 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Webアプリケーションのセキュリティを学ぶために、意図的に100以上の脆弱性を埋め込んだ学習用アプリケーションを作成しました。この記事では、その開発過程と学んだことを共有します。 IBM Bobを活用した開発 このプロジェクトは、IBM Bobの対話型AIアシスタントを使って、すべての実装を行いました。 IBM Bobで実現できたこと： ✅ フルスタック開発: React 18フロントエンド + Node.js/Expressバックエンドの完全実装 ✅ Docker環境構築: 5つのコンテナ（frontend, backend
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
