カバレッジ 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. ...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第6回です。 1. なぜ中間演算精度を検証したのか演算結果が一致していても、内部の計算過程が異なれば将来的な誤差が発生する可能性があります。特に金額系では、桁あふれ丸め符号処理内部表現が業務結果に直結します。 2. 検証設計 確認観点COMPUTEADD / SUBTRACTROUNDED有無桁あふれCOMP / DISPLAY差符号桁 3. 検証コード例 IDENTIFICATION DIVISION. PR...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第5回です。 1. なぜファイル定義を独立観点としたのかCOBOLにおけるFD句は、単なる構造宣言ではありません。RECORDING MODEBLOCK CONTAINSレコード長固定長／可変長ラベルレコードこれらは、実行環境と密接に結びついています。言語仕様は同じでも、I/Oの前提が変われば動作が変わります。 2. 検証観点以下の観点で確認しました。OPEN時の挙動READ時のレコード解釈レコード長の扱いEOF検知のタイミング固定長／可変長の差...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第4回です。 1. なぜデータ例外を独立観点としたのかデータ例外は単なる異常系ではありません。移行時に問題となるのは、例外が発生するかどうかどの命令で発生するか発生後の処理が継続するか停止するか戻りコードやメッセージの違いです。つまり、例外の“存在”ではなく、“構造”が問題になります。 2. 検証設計 2.1 検証軸 ステートメント軸MOVEADDSUBTRACTCOMPUTEDIVIDEIF（比較）DISPLAY データパタ...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第3回です。 1. 問題の所在暗黙初期値は、仕様上「未定義」とされる領域です。しかし移行時に問題となるのは、未定義であること実装が環境ごとに異なることその差が業務結果に影響することです。つまり、「未定義」は“差が出ない”ことを意味しないという点が本質です。 2. メモリ表現レベルでの差異 2.1 文字項目（PIC X）未初期化状態のメモリダンプ比較（例）：環境16進表現現行40 40 40 40次期00 00 00 00...

!リンクの紹介は目視で確認。文章ドラフトおよび調査において生成AIを利用しています。 TL;DRQA自体は不要にならないただし、「人間が手で大量のテストケースを書くこと」を中心にした旧来QAはもう苦しい生成AIで実装、観点出し、テスト生成、補助的な確認が高速化した結果、後工程で待つQAはボトルネックになりやすいこれからのQAは、シフトレフトして仕様の穴を前で潰し、AIに量産させ、人間が疑い、選び、文脈で判断する仕事に寄る特に人間に残る価値は、ブラックボックスでの違和感検知、探索的な観点や状態遷移崩し、権限や運用をまたいだリスク発見にあるジュニアQAやテスターも悲観し...

AI駆動開発は確かに速い(ことも多い)。しかし、「このコード本当に大丈夫？」の問いに答えられるだろうか？不具合が出てAIに指示させてもデバッグが終わらないことはないだろうか？仕方なくAIのコードをチマチマ手で直していないだろうか？...ハイ、自分は去年までそうしてました (笑)同じ罠にハマる人が減ることを願って、AIDD(AI駆動開発)の根幹をなすSDD(仕様駆動開発)とA-SDLC(AI自律開発)の解説記事を書いてみます。用語AIDD : AI-Driven Development（AI駆動開発）。AIが開発タスクを主導し、人間が監督・評価する開発スタイルSDD :...

🎯 1. 本稿の目的本稿では、BOMに付与された情報を部品 → サブAssy → 製品へと集約・評価する Roll-up管理 の考え方を整理します。設計変更時に必要となる影響範囲の把握判断根拠の明確化を、BOM運用の観点から説明します。内容は、以下の教材ページで整理しているBOM属性管理・評価モデルを基に構成しています。📘 参考教材https://samizo-aitl.github.io/EduMecha/08_production_process/06_bom_generation/ 🧾 2. なぜ属性管理が必要か設計段階では見えにくいもの...

はじめに現代の知能労働は、一見すると道具が賢くなってラクになったように見えます。ところが体感としては、むしろ脳が焼ける感じが増えています。これは仕事の中身が「手を動かす」から「頭で選ぶ」へ寄ったことが大きいです。とくにAIが成果物を高速に量産できる環境では、作業者の価値は実装より判断に寄ります。判断は筋トレみたいに長時間連続で回すと精度が落ちます。だから休憩はサボりではなく品質を守る工程になります。また、コミュニケーションが常時接続になり、割り込みが増えました。割り込みは一回ごとに思考の再構築を要求し、地味にコストが高いです。ここに休憩を挟まないと、集中が摩耗していきます。本...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第2回です。前回は、マニュアルに書かれていない非互換が存在することを整理しました。▶ 第1回はこちらCOBOL現新移行で「マニュアルに書いていない非互換」とどう向き合ったか はじめに第1回では、仕様ベースの非互換抽出だけでは不十分であり、実行結果ベースの検証が必要であることを述べました。では、実機検証はどのように設計すればよいのでしょうか。重要なのは、「何をどの順番で疑うか」を整理することでした。単発のテストではなく、差異が潜む“構造”を整理することが必要でした。 ...

🧭 はじめに不良解析（FA: Failure Analysis）は、単に「壊れた理由を調べる作業」ではありません。FA の目的は明確です。観測された不良が、工程起因か設計起因かを特定し、是正対象を確定すること本記事では、FA が果たす役割なぜ OBIRCH が主流の解析手法であるのかなぜ解析を途中で止めてはならないのかを、量産品質ループの最終工程という観点から整理します。 🔬 FAの定義と役割FA は、ETESTウエハテスト（WAT）信頼性試験などで検出された 不良結果 を入力とし、その 物理的原因を断定する工程です。FA の最終目...

🧭 はじめにETEST が製造工程の状態を監視する評価工程であるのに対し、ウエハテスト（WAT: Wafer Acceptance Test） は製品チップそのものを対象とした 選別工程 です。WAT の目的は明確です。規定仕様を満たさないチップを後工程へ投入しないこと本記事では、WAT が判断している内容「最後の防衛線」と位置づけられる理由温度試験および D値が果たす役割を、量産工程における実務的観点から整理します。 🔍 WATの定義と評価対象WAT は 製品テスト工程 であり、測定対象はスクライブ構造ではなく 製品チップ です。主な評価項目...

🧭 はじめに半導体製造においては、工程条件が設計どおりに維持されているかを、製品不良が顕在化する前に把握する必要があります。その目的で実施されるのがETEST（Engineering Test） です。ETEST は製品テストではなく、また、良否選別を行う工程でもありません。本記事では、ETEST が測定している物理量製品チップではなく TEG を用いる理由ETEST データが設計・モデルに与える影響を、工程モニタリング工程としての位置づけから整理します。 🧪 ETESTの定義と役割ETEST は、ウエハ製造工程における電気特性ばらつきを定量的に...