はじめに「AIは速度をフロントローディングし、失敗をバックローディングする」 Opsera社が25万人のエンジニアを分析した2026年版ベンチマークレポートに記されたこの一文は、AI時代のソフトウェア開発組織が直面している本質的な矛盾を的確に言い当てている（出典: Opsera AI Coding Impact Benchmark Report 2026）。93%の開発者がAIツールを使い、コーディング速度は30〜58%向上した。しかしその代償として、PR レビュー時間は441%増大し、本番インシデント数は242.7%増加し、開発者一人あたりのバグ数は54%増加した（出典: Faros AI Engineering Impact Report 2026）。 AIは組織を速くした。しかし、強くはしていない。 3つの独立した大規模調査が同じ結論を示すStanfordが10万人のエンジニアを対象

はじめに 本記事は、Lilia Abdulina（JetBrains の QA責任者）による研究（Vitaly Sharovatovが協力）である「QA in the Age of AI-Accelerated Development」の翻訳記事です*1*2。 本記事は許諾を得た上で翻訳しています*3。 なお、本記事は現在もGitHub上でディスカッションが続けられています。記事を読んで気になった方や疑問を持った方はぜひディスカッションに参加してください！ 本記事の主な見どころ AIによって「理解の負債」だけでなく、「意図の負債」も増えている AI以前では副産物として獲得できていた「ビジネスドメインの知識」を蓄積できなくなっている 「評価」よりも「予防」に重きを置いている「積極的な品質保証活動を行う企業」と、そうではない「反応的な品質管理を行う企業」が存在する コストはO(n + εn2)

はじめに このたび、ソフトウェアテストとは、そもそもいったいなんなのかということを考え直す機会があったので、その時に読み直した書籍や資料についての備忘録を記録します。 ISTQBとJSTQB ISTQB は International Software Testing Qualifications Board の略で、ソフトウェアテスト分野の国際的な資格制度を運営する組織です。 現在のソフトウェアテストについて、どのような概念であるかについてを調べるには、ISTQBが提供している用語集や試験のシラパスを確認することで概要をつかめます。 ISTQBの用語集 Certified Tester Foundation Level (CTFL) v4.0の情報 ISTQBはさらに高度な試験や専門に特化した試験もあるので、必要に応じて参照してください。 また、JSTQB（Japan Software

【はじめに】｢こんにちは世界｣ 先日、お笑い芸人であり弁護士でもある「こたけ正義感」さんの弁論、特に生活保護受給について語る動画を見ました。 その後、まるで運命の悪戯のようなタイミングで、友人からLINEが届きました。 「障害者年金の受給が断られた。もう死にたい」と。 そこで私は、動画で得た知識を元に、友人に生活保護の申請を勧めました。 その結果、私が目の当たりにしたのは、本当にギャグかコントかと思うくらい、ステレオタイプな役所の「水際作戦」でした。 そして、素人の私が「こたけ正義感」の真似事をしただけで、面白いぐらいにあっさりと役所を撃退してしまった。 その顛末をここに記します。 この文章は、同じように生活保護の申請に悩む人、あるいは水際作戦によって人権を奪われかけている人たちの救いになってほしい。 そして、この件について多くの人に議論してほしいと願って書いています。 私自身は法律につい

What's in a price? How to price your products and services

はじめに：3ヶ月目の今、あえて途中経過を書く理由 スタメンのQAエンジニア、にーくらです。スタメン初のQAエンジニアとして入社して3ヶ月。まだ成果が出てきているフェーズではありませんが、ここで立ち上げ期の思考や試行錯誤を後で振り返るためにも残しておきたいと思います。ですので、本記事は成功事例ではなく、現在試行錯誤しながら行なっていることの話になります。 現在スタメンでは東京オフィスで積極採用中で、個人の努力だけでは回らない局面が見え始めていました。プロダクトや開発、意思決定のスピードが上がる一方で、属人化や判断基準のばらつきが課題となりつつありました。そこで必要とされたのが「QA」という役割です。 QAの役割と品質への考え方 ソフトウェア開発において、QA（品質保証）は単に検証活動を行うだけの役割ではありません。しばしばQAは「テストをする人たち」と誤解されがちですが、本質的な役割はもっと

わりと複数の企業のお悩みが、「そもそも生成AIでやるべきでない問い」にチャレンジして疲弊してる。ので説明メモ。 大企業が生成AIを導入してうまくいかないケースの多くは、ツールの性能不足というより、業務設計がズレている印象があります。 もう少し正確に言うと、「AIが苦手な問い」をそのまま投げている。で、当然苦戦しています。 ポイントは大きく2つあります。 完璧性を要求する仕事を、やってはいけない ステップが長く連鎖する仕事も、やらせないほうがいい 順番に解説すると… そもそも完璧性を要求する仕事を、やってはいけない生成AIは確率分布で、未来を予測したり、答えを予測するマシーンです。つまり、「確率的に間違えが発生する」ことは仕様の一部です。 なので、以下のような「そもそも100%の正しさを前提とする業務は苦手」です。 正解が一意で厳密：数式の厳密計算、機械語や厳密仕様のコード生成（1文字違いで

はじめに 現代のソフトウェア開発において、スピードと品質を両立させるための鍵は、皮肉なことに「完璧でないことを受け入れること」にあるのではないかと考えています。より正確に言えば、「失敗することを前提とし、その許容の程度を柔軟に組織やプロセスの設計にあらかじめ組み込んでおくこと」 です。 なぜ「失敗を許容する設計」こそが、結果として品質への近道となるのか。今回はその理由についてお話していきます。 「作る脳」と「直す脳」を切り離す 人間は、新しいものを生み出す「発想・創造」のようなアクセルと、論理的な不整合をチェックする「批判・検証」のようなブレーキを同時に行うようにはできていません。これらを無理に並行させようとすると、認知的負荷が上がり、脳のエネルギーを消耗します。 その結果生まれるのは、品質が低く、創造性も欠いた凡庸な成果物になってしまうかもしれません。 この構造的なジレンマを考慮した設計

あけましておめでとうございます。10X社・代表の矢本です。 この記事は10X 新春ブログリレー 2026の1月6日分の記事です。 近年の私にとってのテーマであった、「複利を経営に組み込む」というテーマについて書いてみます。 複利という発明「複利 (コンパウンド)」は、人類最大の発明だと言われます。 投資の世界では当たり前のように語られるこの概念ですが、事業経営において、複利を構造として実装することは非常に難しいものです。 一昨年頃、コンパウンド・スタートアップという言葉が流行しましたが、どれほどの人が真の意味で複利と向き合い、その実装に成功したのでしょうか。 かくいう私も、わかっているようで、わかっていませんでした。 しかし2025年は、複利の存在を少し理解できたかな、と思います。 過去より積み上げてきた構造が、少しずつ成果として眼前に現れるようになったからです。 この図は2021年4月を

筆者はDevelopers Summit（デブサミ）のコンテンツ委員を2021年から2026年まで6年連続で務め、約400件のセッション公募（プロポーザル）に投票コメントを行ってきました。 投票の際にどのような観点を意識してきたのか、自分用のメモをまとめておこうと思います。 カンファレンス登壇に挑戦する方やイベント運営に関わる方のヒントになれば幸いです。 はじめに 注意事項・免責 挑戦する人が一番えらい！ 「登壇者」側の立場で書いた記事はコチラ 投票にあたって気にしていたこと ①聞き手が明日からアクションできるか ②キーメッセージが定まっているか ③どんな課題を、どう解決したか ④どんな成果を出せたか ⑤位置付けを俯瞰できているか ⑥具体的な事業や技術に言及しているか ⑦手を動かしているか／手を動かせるか ⑧汎用的な学びに言い換えられるか ⑨このタイミングでその話を聴きたいか ⑩この登壇者

BASE株式会社執行役員の柳川です。金融事業の事業責任者をしています。 私はエンジニア→PdM→事業責任者というキャリアを歩んできました。 現在は事業戦略、プロダクト戦略、組織戦略全ての責任を持ちながら、事業責任者を務めさせていただいています。 さて今回はお便りが来たので回答します。若干センシティブですがメンバーシップ加入者からの質問に答えないわけにはいかない。 当然の如くポジショントークの入った話になること、ご容赦ください。 前提この記事では難易度が高い事を言ってます。誰かを刺す意図はないです。 @gimupop PMフィッシュボウルのスレッド後追いしてて、もうちょい詳しく教えて欲しいです！ 僕自身のキャリアが下記のような感じなので、良かったら聞きたいですー！！！ 公務員（2年）→IT会社（3年9ヶ月→1年8ヶ月→イマココ） 石の上にも3年した方がいい！？#pmconf2025 #pmc

チームのテスト力を総合的に鍛えてシフトレフトを推進する/Shifting Left with Software Testing Improvements

はじめに 技術系カンファレンスでは、一般公募（プロポーザルの募集）を行い、運営が審査して採択をする形式があります。 プロポーザルを見たり、運営側として採択を決めたりするときに、「これってテーマは良さそうなんだけど、伝えたい内容が少し見えてこないから採択できないかな…」と思うものが多数あります。 そこで、私がプロポーザルを作成する際に気をつけていることや運営側として気にしていることを言語化してみたいと思います。あくまでも私の主観ですので、その点はご了承ください。 なお、私がどんな立場なのか（プロポーザルの応募者やカンファレンスの運営実績など）については、本記事末尾の注釈で紹介しています。（応募者実績*1、運営者実績*2） ちなみに、私がコンテンツ委員を担当しているDevelopers Summit 2026では、現在プロポーザルを募集しています（Developers Summit 2026の

「品質管理が僕たちの責務です」 って、最近エンジニアリング界のライザップ的元テスト専門会社のQAエンジニアが、昔、言ってたなぁ……、と。 思い上がるなっ！ 君たち如きに背負えるものでは、すでにない。 とあえて言おう。 それほどまでに、最近のサービスは、でかく複雑になりすぎた。 いや、マジで、無理なんよ、もう。 例えば、キッチキチにエレベータを作り込んだとして、後から点検してくれ、と言われたら、まぁ、普通は困るよな。 モーター室がモーターが入るギリギリの広さだとしたら、箱の外に出る手段がなったら。 どうやって点検するんだよ。 外から目視か？ 実際には、設計時に点検方法を決定して、それができる余地を確保してから、施工するものだろう。 今時のEV車なんて、テスト用の仕組みがきっちりと、製品に組み込まれている。 品質管理の仕組みって、そもそもそういうもんだろ？ DDDで設計してます。 マイクロサー

おおたとしまさ @toshimasaota 何年も前にレギュラー出演していたNHKラジオ番組｢マイあさ！｣から出演依頼。懐かしい。事前に1時間程度の打ち合わせも必要とのことで、念のため出演料を尋ねると、事前にはお伝えしないとの回答。 2025-08-12 13:27:54 おおたとしまさ @toshimasaota 報酬を事前に明らかにしないまま出演の可否判断を迫ることは、立場の弱い出演者や制作者に不当な負担を強いるものと考え、悪慣行の改善を求める意志を伝えて出演を辞退しました。似たような依頼があったら「それおかしいよ」ってみんなで声を上げましょう。じゃないと変わらないから。 2025-08-12 13:28:07 おおたとしまさ @toshimasaota 目の前のおかしなことに「おかしい」と異議申し立てをできないひとがジャーナリストをしていてはいけないと思うので、今回は抗議の意味で出演

ユニットテスト 基礎講座 Jun. 7, 2025 @JJUG CCC 2025 Spring Takeshi Yonekubo

前回記事で書いたように、お届けチームの扱うシステム領域ではさまざまな非同期処理が行われています。 product.10x.co.jp この記事では 非同期処理の採用するモチベーション 非同期処理の実現方法 を書いています。 非同期処理の採用するモチベーション 「領域間をまたぐ」 「同期処理をミニマルにしたい」 実現するためのoverview publish side subscriber side メッセージによる非同期処理を本番導入するまでに 1. gRPCのリクエストハンドラ内でプログラム上、同期的にイベントハンドラを実行する 2. gRPCのリクエストハンドラ内でプログラム上、非同期でイベントハンドラを実行する 3. gRPCのリクエストハンドラ内ではイベントの永続化だけし、別プロセスでイベントハンドラを実行する サンキューEventarc 次回に続く 非同期処理の採用するモチベーシ

チームのテスト力を総合的に鍛えてシフトレフトを推進する/Shifting Left with Software Testing Improvements