はじめに一般的に、QAエンジニアは、外部品質の改善に関わることが多い反面、内部品質の改善に関わることはあまりありません。しかし、外部品質の改善のみで、ソフトウェアの全体的な品質を担保していくのはとても難しいです。今回は、内部品質と外部品質について説明した後、内部品質と外部品質の関係性を説明し、QAエンジニアが内部品質の改善にアプローチできる方法をいくつか紹介していきます。 内部品質とは何か内部品質とは、ソフトウェア内部の作り込みの品質について指していて、ソースコードや仕様書の品質のほか、保守性や柔軟性、移植性、テストのしやすさなどが含まれています。この品質は、利用時の品...

はじめに「AI コーディングで品質が落ちている」という調査結果が、この夏話題になりました。New Relic が 2026 年 7 月 30 日に発表した「The 2026 State of AI Coding Report」(米国の中堅・大企業の IT リーダー 200 人対象) は、AI がコードの過半を書くようになった現場で、本番障害が増えているという数字を並べています。この記事は、その調査への反論でも、AI コーディング擁護でもありません。私たち自身が AI を使ってソフトウェアを開発し、商用製品としてリリースしている当事者として、では、何を管理すればよいのかを実務の視点...

はじめにAIにコードをたくさん書かせると、何をしているかを表すWhatコメントをたくさん書く。Whatコメントはコードの修正時にコメントのメンテナンスが発生するので保守性がよくない。ちなみにWhatコメントはこういうの// 商品の価格をorderItemのpriceにセットするconst orderItem = { productId: product.id, price: product.price, quantity,};一方Whyコメントはこういうの// 商品マスタの価格は後から改定されるため、注文時点の価格をorderItemへ複製して保持するco...

Claude Codeの出現以降、ターミナルに複数のAIエージェントを別ペインで表示し、並列でコーディングさせて生産性を極限まで高める、という話が一種の流行を見せています。しかし、たとえば和田卓人さんは「コーディングってボトルネックだったでしょうか。であれば、IDEの進化でコーディングは大分速くなったとき、プロジェクトはより速く終るようになったのでしょうか。おそらくまったく変っていない。なぜならコーディングは、プロジェクト全体の一部にすぎず、そこはすでにある程度人数をかけるという方法でもう十分に速くなっていた。しかし、プロジェクト全体の期間は短縮できていない。つまりボトルネックはそこで...

はじめにここ数か月かけて、弊社の開発体制は「人間が書き、AIが手伝う」から「AIが自走し、人間が方針判断とレビューを担う」へと段階的に移行してきました。マルチセッション運営・リリース手順・QA・本番監視までをAIが一気通貫で回す、いわゆるAIネイティブ開発の基盤が最近ようやく整ってきました（基盤の全体像は「AIネイティブ開発の基盤ができるまで」にまとめています）。基盤が整ったこれからは、サービス向上そのものを加速させていくフェーズです。その入り口として本記事では、人間中心だった時代と比べて、AIネイティブ化でQCD（品質・コスト・納期）がどう変化したのかを、直近2週間の実測データ...

!この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の153週目の記事です！3年間連続達成まで残り6週となりました！こんにちは、ログラスの飯田(@ysk_118)です。ここ数年、AIによってコードを書く速度はずいぶん上がりました。一方で、「品質向上に対してどのようにアプローチしていくのか」という問いも、多くの現場で同時に立ち上がっているように思います。AIによる開発現場の進化の渦中において、エンジニアリングマネージャーはどう変化すべきなのか？品質にとどまらずさまざまな観点でアップデートが求められていると感じていますが、まずは直近で取り...

はじめにこの記事は Dress Code Advent Calendar 2026/07 の 17日目の記事です。こんにちは。DRESS CODE 株式会社でプロダクトエンジニアをしている西銘です。DRESS CODE の開発では、PdM が機能チケットを作成し、そこに記載された仕様をもとに開発者が実装するフローが一般的です（チケットの粒度は、画面デザインまで書かれたものから機能名だけなど様々です）。進め方は各開発者に委ねられますが、私が実装前に品質を上げるために取り組んでいる「QA との事前打ち合わせ」 を紹介します。開発の進め方の一つとして参考になれば幸いです。 ...

はじめに普段、自分のミッションはなにかと聞かれたら、迷わず「品質を守り、上げていくこと」だと答える。機能を増やすことでも、早くリリースすることでも、それ自体が目的だとは思っていない。届けるものの品質を守り、少しずつでも上げていく。それが自分の役割だと、なんとなくずっと思ってきた。そもそもこの「品質を守る」に行き着いたのは、「ユーザーに安心・安全に、スピーディーに価値を届けるために、自分には何ができるか？」を突き詰めた結果だった。もちろん、ユーザーに真の価値を届けるだけなら、他にもやれることはいくらでもある。実際にユーザーの声を聞くとか、徹底的にユーザー目線で考えるとか。そのなか...

暑いですね！AIに対する熱気と共にLLMを組み込んだ機能を開発することがどんどん増えてきた昨今です。 生成AIアプリの開発において、モデル選定は重要だが、もっと大事なものがあるLLMを組み込んだ生成AIアプリの開発において、どのモデルを使うかは重要ですよね。私はモデル選定に1ヶ月かけたこともあります。しかし、振り返って考えてみると、もっと重要なことがあります。それが評価です！ モデル選定よりも、要件定義の段階で評価項目を決めろ文書を検索して答えるRAGチャットボットを作ったとき、GPTとClaudeとGeminiを並べて比較スプレッドシートを作り、ベンチマークの記事を読み漁...

品質ってなに？〜ソフトウェア開発で本当に大事な「品質」とは〜ソフトウェア開発に携わっていると、毎日「品質」という言葉を耳にします。「品質を上げろ」「品質が悪い」「品質保証（QA）」…でも、「品質」って結局何だろう？ と改めて問われると、意外と答えに詰まる人が多いのではないでしょうか。この記事では、ソフトウェア開発における「品質」の本質を、初心者〜中堅エンジニア向けに整理します。国際規格も参考にしつつ、実務で使える視点をお届けします。 1. 「品質」の3つの顔ソフトウェアの品質は、大きく3つのレイヤーで考えるとわかりやすいです。プロダクト品質（成果物そのものの品質）...

出発点は「手を抜きたい」だった最初の動機は、まったく高尚じゃない。手を抜きたかった。AIにできる限りやらせたい。自分はできるだけ動きたくない。でも、出てくるものの品質は落としたくない。この3つを同時に満たしたい、というだけだった。そこから、ほしい開発プロセスの形はすぐ決まった。SPECとユースケースくらいまでは、自分が面倒を見る。何を作るかは、さすがに自分で書く。でも、その先——実装、テスト、レビュー、仕様と実装の突き合わせ——は、全部AIにやってほしい。要するに「上流だけ握って、下流は丸投げ」。怠け者の理想形だ。じゃあ、その開発プロセスを作るか。そう思って手を動かし始めた...

COBOL現新移行検証シリーズ まとめ本シリーズは、ホスト系COBOL処理系からオープン系COBOL処理系への移行に携わる実務者を対象に、差異の構造と実機検証の設計思想を体系的に整理したものです。コンパイルエラーの有無ではなく、「動作が一致しているか」という観点から移行品質を捉え直すことを目的としました。 各回一覧 第1回【COBOL現新移行検証①】マニュアルに書いていない非互換とどう向き合うかhttps://zenn.dev/nttdata_tech/articles/f0610fa39d5bb8 第2回【COBOL現新移行検証②】実機検証の設計思想と検...

カバレッジ 100% なのに、本当に安心していい？AIを使ってコード生成して、テストカバレッジを上げたとしてもそのテストコードがほんとに正しいといえますか？。極端な話、こんなテストでもカバレッジは 100% になります。def test_calc(): calc(10, 5) # 戻り値をアサートしていないcalc は実行されたのでカバレッジ上は緑。でも何も検証していないので、calc がどんなバグを持っていても気づけません。カバレッジは「テストの量」は測れても「テストの質」は測れないわけです。ここで効いてくるのが**ミューテーションテスト（mutation tes...

品質とは何か（品質の定義） 品質とは品質とは、「そのものが本来持っている特性が、求められる条件をどれだけ満たしているか」という度合いのこと「良い品質」「悪い品質」のように形容詞をつけて使うこともある「本来備わっている」とは、後から付け加えたものではなく、そのものが存在する限りずっと持っている性質のこと 品質要素と要求品質品質要素：品質を細かく分解した、個々の性質や性能のこと（例：タオルなら「吸水性」「肌触り」「耐久性」など）要求品質：お客様が製品に対して求めている品質のこと。はっきり口に出して求めていること（顕在的）だけでなく、「言わなくてもわかるだ...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の最終回です。 1. シリーズの振り返り本シリーズでは、移行時に発生し得る差異を以下の観点で整理してきました。暗黙初期値データ例外（0C7）ファイル定義中間演算精度移送元と移送先の属性ソート順いずれも共通しているのは、コンパイルは通る文法も正しいしかし動作が変わるという点です。 2. 差異の構造（3層モデル）移行時の差異は、偶発的に発生するものではありません。検証結果を整理すると、次の3層構造に分類できます。層差異の種類具体例本質...

はじめに先に、この記事が何の話かを言っておく。これは「AIを使うと生産性が上がる」という話ではない。AIコーディングエージェントを毎日使っていたら、自分の得意分野だけが異常な速度で深堀りされることに気づいた。そしてその結果、私は知らないうちに「品質偏向防止系」を組み上げていた——という、自己分析と品質工学が混ざった手記である。この記事は、前回書いたAIの性能が行き着いたら、次に必要なのは「品質偏向防止」であるの裏側にあたる。前回は「AIを確率論的変換器として開発プロセスに組み込むなら、品質の保存量を『最大化』から『偏向防止』へ移すべきだ」という構造論を、外から見た設計図として書...

はじめにAIの性能が行き着いたら、次に必要なのは確率論的な「偏向防止」ではないか。なぜなら、AI を開発プロセスの構造材として組み込んだ瞬間に、ソフトウェア工学が暗黙に前提にしてきた「品質最大化」という目標そのものが、定義不能になるからである。これは「AIで品質が下がる」とか「ベストプラクティスを守ろう」という話ではない。もっと根本的に、確率論的なものを構造材として採用する開発プロセスでは、要求すべき品質の定義そのものを組み替える必要がある、という話である。本記事はその構造的根拠を、できるだけ具体的に書く。 この記事の射程について本論に入る前に、議論の前提を明示しておき...

はじめに大企業ほどAI活用を投資案件として扱い、ROIや評価指標で管理したがる傾向は強いです。実際にIBMの2025年調査では、最高経営責任者の65%がAIの用途をROI基準で選び、68%が革新のROIを測る明確な指標があると答えています。しかし同じ調査で、期待どおりのROIを達成できたAI施策は25%にとどまり、全社展開まで到達したものは16%しかありませんでした。この数字だけでは「ROI管理が原因で失敗した」と断定はできません。AI施策そのものが難しいだけだという解釈も十分成り立ちます。ただし少なくとも、ROI指標を大量に持てばAIの価値が掴めるという世界観は、この調査結果に...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第8回です。 1. なぜソート順を検証したのかソート順の違いは、目に見えやすい差異です。しかし問題は、並び順が変わること＝業務ロジックが変わることにあります。特に、キー順処理最小値／最大値取得先頭レコード判定重複判定などに直接影響します。 2. 差異の根本原因 2.1 文字コードの違い項目ホスト環境オープン環境英大文字連続配置連続配置英小文字大文字より後大文字より後数字英字より前英字より前記号環境依...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第7回です。 1. なぜ移送属性を独立観点としたのかCOBOLにおける MOVE 文は、単なる代入ではありません。内部では、型変換桁調整符号処理表現形式変換が発生します。そのため、文法は同じでも結果が変わる可能性があります。 2. 検証設計 検証軸送出し側の型受取り側の型桁数差符号有無表現形式（DISPLAY / COMP / COMP-3） 3. 基本検証コード IDENTIFICATION DIVISION. ...