※本記事は、ホスト系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 は、ウエハ製造工程における電気特性ばらつきを定量的に...

はじめに銀行の勘定系システムや保険の基幹業務など、社会インフラを支える多くの重要システムはいまもCOBOLで稼働しています。これらのシステムでは、わずかな計算差異や判定誤りも許されません。そのため、既存環境から新しい実行環境への移行は、単なる「言語の移し替え」ではなく、動作結果の完全一致が求められる高度な作業となります。しかし移行対応の中で、次のような問題に直面しました。文法上は正しいコンパイルエラーも発生しないそれでも実行結果が一致しない論理を変更していないにもかかわらず、環境の違いによって処理結果が変化するケースが存在したのです。この問題はCOBOL...

はじめにQAエンジニアとして不具合に向き合う際、私たちが最も警戒すべき言葉があります。それは 「手元の環境では再現しませんでした」 という回答です。一見、単純な操作ミスや特定の端末依存に見えるバグでも、実は 「特定のログイン状態」や「複雑な権限設定」が組み合わさった時にだけ牙をむくエッジケースが多々あります。まれに発生するバグであっても、そのサービスや機能を利用するユーザーが存在する限り「サービスに欠陥があるな...」と捉えられてしまっては残念ですよね。今回は、チャットツール（SaaS）を例に、「再現不可」のバグの深掘り方やQAの介在価値を考察しました。 事象：メッセージ...

はじめにこんにちは。株式会社ガラパゴスでQAエンジニアをしているfukaです。社内のメンバーと話していると、「品質についての課題」や「品質向上」というワードがよく出てきます。普段の業務で品質保証活動は行っているはずだけど「品質」という言葉が出てくると、「自分は品質に対して何かやれているっけ・・・」といつも不安になります。「品質」という言葉が意味する範囲は広いため、今回、品質を図る色々な指標を用いつつ、私なりに考えてみました。 品質の定義品質とは何でしょうか？この記事では認識を揃えるために、テスト関連記事でよく見かける以下の定義を用いてみます。「品質とは、誰かにとっ...

Vibe駆動開発はクソである。 Vibeで詰みかけた国内でもほぼ前例のない高難度R&Dをやっていた。調べても答えが落ちていない。数式と向き合いながら精度を詰めていくしかない類のやつだ。自分としても専門外の分野だったので、最初はAIに頼ってみた。それっぽいプロンプトを投げ、AIにコードを書かせて、理解した気になりながら、Vibe的なお祈り駆動開発を進める。結果？失敗である。つまるところ、Vibeで詰みかけた。そこから 「Vibe」を全て捨てた。真正面から数式と論文へと向き合い、基礎勉強主体に回帰した。その瞬間からグラフの精度は階段状に伸び始め、最終的には業界最高...

はじめに前回の記事では「品質とは何か」「品質は後工程で作るものではなく、工程の中で作り込むもの」という考え方を整理しました。今回はその続編として、製造工程（コーディング〜単体試験）で品質を作り込む方法を扱います。私はこれまで主に業務アプリケーション開発に携わってきました。その中で痛感したのは、製造工程は「設計どおりに作る工程」ではなく「設計の曖昧さや欠陥を顕在化させ、品質を決定づける工程」だということです。本記事では、一般論としての品質作り込みの考え方と、私自身が現場で実践・失敗してきた具体策を組み合わせて整理します。 製造工程における「品質」とは何か...

はじめにこのAdvent Calendarも、いよいよ最終日となりました。これまで、この20年間に私が書いてきたWeb記事を振り返ってきましたが、最後にそこで感じたことを「変化」「責任」「挑戦」「感謝」の4つのキーワードでまとめたいと思います。やや自分語りの部分もありますが、最終回としてお付き合いいただければ幸いです。 変化この20年で、本当にさまざまな変化がありました。 扱うテーマの変化＝技術の変化テストや品質を軸としながら、新しいテーマが次々と加わってきました。序盤（2006～2012年）テスト自動化（1日目、5日目、8日目、9日目）、メトリクス（2日目）、...

はじめにこのAdvent Calendarでは、過去に私が書いたテストや品質に関する記事の紹介をします。本日紹介する記事はこちらです。掲載日：2015年12月掲載メディア：slideshare 生成AIによる要約「わかりやすい日本語を書こう（完全版）」 は、読み手に誤解なく伝わる日本語を書くための実践的なガイドです。主なポイントは以下の通りです。主語・述語を明確にする、修飾語を遠ざけない、1文を短くするなど、文構造を整える基本技法を紹介。あいまい語（「適宜」「ちゃんと」「なるべく」など）や、抽象的で理解しにくい表現を避けることの重要性を説明。「誰に」「何を」...