AI時代になぜ人が学ぶのか - そーだいなるらくがき帳
来週、学生たちに向けて『AI時代に学ぶ意味』というテーマで講演を行う予定で、その要点をここにまとめておく。 AI時代に学ぶ意味 概ね、理由は以下のとおり。 良い質問をするために知識が必要 AIの出力を評価する 抽象的なアドバイスを活用する これらを実行するためには、一定の知識とスキルが必要である。 スキルを身につけるためには基礎知識があるうえで経験が必要であり、そのサイクルがまさに学びなのである。 そのため、AIが普及したとしても、人が学ぶことの重要性は変わらない。 その前提を踏まえたうえで、各ポイントについて説明する。 良い質問をするために知識が必要 AIに質問する際には、質問の意味を理解している必要がある。 そして質問するにはまず、自分の無知の状態を認識しなければならない。 無知には5段階のレベルがあって、自分がどの状態にあるのか理解する必要がある。 これをFive Orders of
SmartHRのQAエンジニア歴4年で見えてきた「QAエンジニアの役割」 - SmartHR Tech Blog
こんにちは、SmartHRのwattunです。 私は2022年1月にQAエンジニアとして入社し、2024年4月からはQAエンジニアとプロダクトオーナーを兼務してきました。そして2026年1月から、プロダクトマネジメント本部で新しいチャレンジをすることになりました。 入社時点では、「QAエンジニアの役割は品質を守ることだ」と考えていました。しかし、この4年間で、「QAエンジニアの責務」についての見え方は大きく変わりました。品質を守るという役割を超えて、「組織がどう判断し、どう進むか」を支える役割としてQAエンジニアを捉えるようになったのです。 この記事では、これまでの経験を通じてたどり着いた「QAエンジニアの責務」について整理してみます。 次のステージに進む自分自身の棚卸しであると同時に、「QAという仕事にも、いろいろな関わり方がある」と思ってもらえるきっかけになればうれしいです。 この記事
父の介護が始まったと思ったら終わった。 - 小学校笑いぐさ日記
結論から書くと以下の通りです。 ・親の様子がおかしいと思ったら、早めに地域包括支援センターに相談しよう。 ・市の福祉課、高齢課などにも相談しよう。必要なら警察にも躊躇無く相談しよう。 ・「一人で抱え込んではいけない」とわかっている人も、いざその立場になると相談を後回しにしがちなので気をつけよう。（徐々におかしくなるので相談のタイミングを逸する。ゆでガエル理論） ・親の様子はなるべく頻繁に確認しよう。 あらすじ。 2025年12月上旬 この頃から父の易怒性が高まり、同居する母に怒鳴り散らしたり、近隣の家とトラブルを起こしたりする。警察を呼ばれる、自分から警察に苦情を言いに行くなどする。 12月20日（土） 母からSOSのLINEが来て状況を知る。地域包括支援センターへの相談を勧める。 12月22日（月） 母、地域包括支援センターに相談に行く。その間、私が有給休暇を取って父と出かけ、時間を稼ぐ
Claude Code Customization Guide: Rules vs Skills vs Subagents vs MCPs
JANUARY 5, 2026Claude Code Customization: When to Use Rules, Skills, Subagents, and MCPs Claude Code has four internal configuration layers: CLAUDE.md (master config), Rules (domain knowledge), Skills (workflows), and Subagents (autonomous tasks). Plus MCPs as external bridges to tools like GitHub, databases, and Slack. Internal layers shape how Claude thinks; MCPs extend what Claude can reach. Cl
テストが設計を駆動するなら、評価は何を駆動する？ 〜テスト駆動開発と評価駆動開発、「先に定義する」ことの力〜
テスト駆動開発（TDD）を実践したことがある人なら、テストが設計を駆動するという感覚がわかるかもしれません。 t-wada氏の言葉を借りれば、「テストを先に書き、それに対応するコードを書いていくと、使う側の期待に沿ってコードを書くことになります」——結果として使いやすい設計が生まれる。 AIプロダクト開発ではどうでしょう。 LLMの出力は非決定論的で、従来のテストだけでは乗り切れません。 「この入力なら、この出力」というアサーションができない世界です。 そこで登場するのが評価（Eval）、そして評価を開発サイクルの中心に置く考え方、Eval-Driven Development（評価駆動開発 / EDD） です。 テストが設計を駆動するように、評価がAIの品質を駆動する——最近改めてそう感じています。 （EDD自体、TDDにインスパイアされているので当たり前といえば当たり前なのですが） こ
MCPでやる必要のない業務をSkillsに置き換えてトークンと時間の消費を爆減してみた
こんにちは。ダイの大冒険エンジョイ勢のbun913と申します。私はSDET(Software Development Engineer in Test)として、QAチームにいる何でも屋さんとして、私より優秀なみなさんが本質的なことに時間を使えるように日夜改善を考えています。 私は弊QAチームでのMCP活用として以下のような記事を書いておりました。 今回は最近話題の Agent Skills とあらかじめ作っておいたCLIツールを組み合わせて、QAチームが本質的ではない作業にかける時間とトークン消費量を大幅に削減する試みを紹介します。 内容自体はQAチームの取り組みですが、考え方やツールの使い方は他のことに流用できるのではないかと考えています。 先に背景とやったことをざっくり説明 背景: 前回までの取り組み 弊チームでは自動テストに力をいれつつも、手動テストの威力も大事にしています。実際探索
Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？
GoogleでGoogle CloudやGeminiに携わるソフトウェアエンジニアのアディ・オスマニ氏が、Googleで約14年間働く中で得た「21の教訓」を自身のブログで公開しました。オスマニ氏は当初「良いコードを書くことが仕事」だと思っていたものの、長く働くほど「活躍するエンジニアは必ずしも最高のプログラマーではない」「コードの周りにある人間関係・社内政治・認識合わせ・曖昧さを乗りこなせる人が伸びる」と実感したとのことです。 AddyOsmani.com - 21 Lessons From 14 Years at Google https://addyosmani.com/blog/21-lessons/ ◆1：ユーザーの問題に執着する 新しい技術に執着して使い道を探し始めるのは自然なことですが、価値を生む人は逆向きに考えるとのこと。「サポートチケットを読む・ユーザーに話を聞く・ユーザ
生成AI時代のチーム設計 ― 役割と協働の再構築
Tidy First? ―個人で実践する経験主義的ソフトウェア設計著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ出版社：オライリー・ジャパン発売日：2024-12-25単行本（ソフトカバー）：164ページISBN-13：9784814400911ASIN：4814400918 脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin出版社：オライリー・ジャパン発売日：2024-06-18単行本（ソフトカバー）：312ページISBN-13：9784814400799ASIN：4814400799
【資料公開】デイリースクラム Deep Dive
みなさんこんにちは。@ryuzeeです。 2026年1月7日〜9日まで開催のRegional Scrum Gathering Tokyo 2026で「デイリースクラム Deep Dive」というテーマで登壇しましたので、資料を公開します。 「スプリントレトロスペクティブ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Diveスプリントプランニング Deep Diveスプリントレビュー Deep Diveベロシティ Deep Diveスプリントレトロスペクティブ Deep Diveセッション資料は以下になります。 以下簡単なまとめです。 デイリースクラムを朝会と呼ばない。余計なコンテキストが増えてしまい本来の目的が阻害されるデイリースクラムの目的は、スプリント
【自己紹介】はじめまして、株式会社GENZです（バグと仲良く…はしません）｜GENZ
たぶん、あなたも一度は見たことあるはずです。 リリース当日に落ちるボタン なぜかログインできない月曜の朝 “昨日まで動いてた”のに動かない神秘 そしてこう思う。 「これ、テストしてないの…？」 ……してます。してるんです。 でも、“してる”だけだと足りない瞬間がある。 僕らGENZは、そこを仕事にしています。 ソフトウェアテストの専門会社です。 バグを見つけるだけじゃなく、事故らない仕組みまで一緒に作ります。 物語：深夜23:48、Slackに流れた一言から始まる「本番で、注文が通らない」 この一文って、胃にきます。 胃に。きます。（大事なので2回） 原因は“仕様通り”でした。 でも、仕様が現実を置き去りにしてた。 例外入力のときだけ、DBの制約に引っかかる その結果、注文処理が途中で止まる 画面は“完了”っぽい顔をしてる（最悪） この手の事故って、バグの前に「設計のスキマ」があるんです。
育てるほど楽になる AI 開発体制を作っている話 | BLOG - DeNA Engineering
こんにちは。ソリューション本部 エンタープライズ事業部 スポーツプラットフォーム部の永田です。普段の業務ではスポーツ領域の新規サービス開発に従事しています。 本記事では、複雑なドメインを持つ新規サービス開発のプロジェクトにおいて、「AI を活用して開発生産性を向上させる」 ために構築した仕組みと、その具体的な例を紹介します。 背景と課題 プロジェクトの特性 本プロジェクトには、以下のような特性があります。 新規サービス開発: ゼロからの立ち上げであり、設計判断が多い タイトなスケジュール: ビジネス要件上、できるだけ早く開発を進める必要がある 複雑なドメイン・コード: 特有の概念や複雑な構造が多く、全体像の把握が難しい。新規メンバーが多いチーム構成も相まって、ドメイン知識の蓄積が十分でない こうした背景から、AI をうまく活用してスピードと品質を両立して開発を効率化したいと考えていました。
2026元日、Playwright MCPに触れて気づいた、LLM時代のブラウザ自動化の新しいパラダイム
はじめに 年末年始でPlaywright MCPを触り直しています。きっかけは、MCPがLinux Foundation傘下のAgentic AI Foundationに移管されたというニュースでした。GitHub Starsは23,000を超え、2024年11月のMCP発表からわずか1年。最初は「また新しいツールか」程度に思っていたのですが、触っているうちに、これまで経験してきたブラウザ自動化とは何か違うと感じ始めました。 その違和感を年末年始で整理してみた結果、自分なりに言語化できたのが「Webページの表現方法」の変化という視点です。 PlaywrightとPlaywright MCPは別物である 最初に混乱したポイントを共有します。 PlaywrightとPlaywright MCPは、関連はあるものの根本的に異なるものです。自分は「PlaywrightのMCP対応版」くらいに思って
試行錯誤と不調が続いた2025年｜つとむ QAエンジニア
2025年を思い返すと、「前に進んだ」というより、 立ち止まって考えている時間の方が長かった気がします。 何かを決めて走り出すというより、いったん立ち止まっては考え直す、 そんな試行錯誤が続いた1年でした。 仕事編とプライベート編で2025年を振り返りました。 仕事編QAチームメンバーのベクトル、価値観のすり合わせ2025年は、チームメンバーが増え、ついに「個人」ではなく「チーム」として動き始めた一年でした。 チームとして成果を出すために、 QAエンジニアとしてどんな行動を大事にするのかを言葉にし、 行動指針として整理するところから取り組みました。 その過程で、QAエンジニアとQAエンジニアリーダーの間にある 考え方や期待値のズレを、一つずつすり合わせていったのを覚えています。 また、各QAエンジニアが「今、何に注力すべきか」を判断しやすくするために、RICEという考え方を参考にしながら、
現職でQA組織のEMとしての1年ちょっとが過ぎたので少しふりかえる｜tarappo
いつの頃からかノートに1週間の仕事のことについてふりかえるようにしています。 現職に入社するときに用意したノートが、1年少しすぎたところで終わりました。 この一冊を使っている期間の間に、組織も変化させていきながら、EMである私の役職はManager（Acting）からDirectorへと変わりました。 1年も終わる節目もありますし、ふりかえりもかねてQA組織について、この一冊を通して考えたことを書きます。 もっと詳細なことは別の機会にブログ記事にしたり、どこかしらで話せればと思います。 QA組織についての情報の少なさエンジニアリング組織に関する資料や本は多くありますが、それらの多くはPdEやSWEといった職種がメインの話になっています。 QAという文脈に触れている本も中にはありますが、そこまで情報はのっていません。 それもそのはずで、それらの本の著者の職種はPdEやSWE出自であるのでどう
エンジニアのコミュニケーションで気をつけているのは「正しさ」より「前に進むか」
うぐいすソリューションズ Advent Calendar 2025の 24 日目担当の zen です。ラストバッター頑張ります。 エンジニアのコミュニケーションで気をつけているのは「正しさ」より「前に進むか」 エンジニアとして働いていると、「何が正しいか」は割とすぐ分かるのに、それをどう伝えるかで悩む場面が多いなと感じます。 僕自身、コミュニケーションが得意だと思ったことはあまりありません。それでも振り返ってみると、(自分を変に攻撃してくる人がいない場合に限りますが)プロジェクトが大きく揉めたり、人間関係が壊れたりすることは少なかった気がします。 なぜだろう、と考えてみた結果、どうやら僕はずっと 「正しいことを言う」より 「チームが前に進むかどうか」 を優先してきたように思えます。 この記事では、そんな僕が普段あまり意識せずにやっている、エンジニアとしてのコミュニケーションの考え方をまとめ
Autify上のE2EテストをPlaywrightに移行しました | PR TIMES 開発者ブログ
またそれぞれのシナリオの実行に平均で30分近くかかっていたため、失敗したテストの調査に時間がかかってしまうといった課題も抱えていました。 そこでFlakyなテストを減らし、エンジニアのメンテナンスコストを削減することを目的に、E2Eテストの整理と再構築の取り組みを始めました。 テストシナリオの精査 まず始めに、増えすぎてしまったテストシナリオの見直しを行いました。 Autify上には約150個のシナリオがありましたが、細かな要素の表示など重要度の低いテストが混ざっているものが多くありました。 そこで、E2Eテストを実施してきた最大の目的である「リリース時に既存の重要機能が正常に動作することを担保する」に改めて立ち返り、重要な機能の確認に絞った53個のシナリオを新しく作成しました。 重要な機能の線引きでは、以下の基準を一つの判断基準としました。 ユーザー情報の公開・非公開や、ユーザー権限によ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - vercel-labs/agent-browser: Browser automation CLI for AI agents
GitHub - VibiumDev/vibium: Browser automation for AI agents and humans
霞が関から学ぶ、仕事のコミュニケーション────官僚は複雑なステークホルダーをどう調整しているのか？
『アーマード・コア6』の“ルビコン空手”達人に世界が注目。150～200時間もかけた「アイスワームノーダメ撃破」の裏側を訊いたら、「精神が削られた」らしい - AUTOMATON
