【LPICレベル1】ユーザーの玄関口を決定する！「ログインシェルと/etc/passwd」｜情報処理問題1000本ノック

Linuxシステムにユーザーがログインした際、最初に自動起動してコマンド入力を待ち受けるシェルを「ログインシェル」と呼びます。このログインシェルがどこで定義されているかをしっかりと整理しましょう。

1. 問題：ログインシェルの設定ファイル

【 問題 】 各ユーザーがログインした直後に起動する「ログインシェル」の情報が保存されている、Linuxの重要な設定ファイルはどれでしょうか？

ア、/etc/shells  
イ、/etc/profile  
ウ、/etc/passwd  
エ、/etc/login.defs

2. 正解：ログインシェルの参照先に関する正解

正解： ウ、/etc/passwd

3. 解説：ユーザー情報の基本中の基本

`/etc/passwd` ファイルは、システム上の全ユーザーのアカウント情報が1行ずつ記録されている、テキスト形式の非常に重要な設定ファイルです。

【図解：/etc/passwd の構造】

ファイルの中身は 「 : 」（コロン） で区切られた7つのフィールドで構成されています。

（例） lpi-user:x:1001:1001::/home/lpi-user:/bin/bash

1. ユーザー名（lpi-user）
2. パスワード（x：現在は/etc/shadowに暗号化されて保管されるため通常は「x」）
3. ユーザーID（UID）（1001）
4. グループID（GID）（1001）
5. コメント欄（GECOS）（空欄も可）
6. ホームディレクトリ（/home/lpi-user）
7. ログインシェル ★今回の正解（/bin/bash）

[ 補足：他の選択肢の役割 ]
★ /etc/shells：システムで利用可能な「有効なシェル」の一覧が書かれたファイルです。
★ /etc/profile：ログイン時に全ユーザーに共通して適用される環境変数などのシステム全体の設定ファイルです。

1. 理解のコツ: ログインシェルは、`/etc/passwd` の一番最後（7番目）の項目に絶対パスで書かれています。ここを `/bin/bash` から `/bin/zsh` に書き換えたり、`chsh` コマンドを使うことで、ログイン時のシェルを変更することができます。
2. 試験対策 of 視点: LPICでは、`/etc/passwd` の各フィールドの意味（何番目が何の情報か）を順番通りに答えさせる問題が多発します。特に「6番目＝ホームディレクトリ」「7番目＝ログインシェル」の組み合わせは、セットで確実に暗記しておきましょう。

---

4. まとめ

ログインシェルは、ユーザーがLinuxと対話するための最初の窓口です。そして、その設定は `/etc/passwd` の最後に刻まれています。もしユーザーにログインさせたくない（サービス専用アカウントなど）場合は、ログインシェルを `/bin/false` や `/sbin/nologin` に設定するという実務テクニックも合わせて覚えておくとバッチリです！

【開発管理】本番環境でしか見えないリスクを暴く！「シフトライトテスト」｜情報処理問題1000本ノック

テストを左（上流）に前倒しする「シフトレフト」の対義語。リリース「後」の本番環境というリアルな舞台で品質を磨き上げる最新のテストマネジメント、シフトライトを攻略しましょう。

1. 【 問題 】：モダン開発における品質管理のアプローチ

【 問題 】 近年のソフトウェア開発および運用管理において、システムを本番環境にリリースした「後」に、実際のユーザー利用環境やリアルなトラフィック（通信量）を用いてシステムの品質、パフォーマンス、安定性を継続的に検証するテスト管理のアプローチはどれでしょうか？

① シフトレフトテスト (Shift-Left Testing)
② シフトライトテスト (Shift-Right Testing)
③ リグレッションテスト (Regression Testing)
④ スモークテスト (Smoke Testing)

2. 正解：

正解： ② シフトライトテスト（Shift-Right Testing / 本番環境テスト）

3. 解説：ステージング環境の「限界」を超える

従来のウォーターフォール開発や、先述の「Wモデル」では、テスト工程をなるべく左（上流・開発初期）に寄せる「シフトレフト」が正義とされてきました。しかし、クラウドやマイクロサービスが複雑に絡み合う現代のシステムでは、「本番と全く同じ環境」をテスト用に用意することがコスト的・技術的に不可能になってきています。そこで生まれたのが「シフトライト（テスト工程を右側の本番運用へ拡張する）」という発想です。

【シフトライトテストの具体的な手法例】

ただ本番環境でぶっつけ本番のテストをするわけではなく、ユーザーに影響が出ないよう高度な管理手法とセットで行われます。

・カナリアリリース：新バージョンを本番環境にデプロイする際、まずは全体の「5%のユーザー」にだけ先行公開して様子（エラー率や負荷）をテストし、問題がなければ全体に広げる。
・A/Bテスト：本番環境でユーザーを2つのグループに分け、異なるUIや機能を同時に提供してどちらがスムーズに動作・利用されるかを検証する。
・カオスエンジニアリング：本番環境のシステムにわざと疑似的な障害（サーバーを1台強制停止するなど）を発生させ、システムが自動復旧するか、耐障害性があるかをテストする。

[ 選択肢のひっかけポイント ]
★ ①：シフトレフトは、要件定義や設計といった「リリースより遥か前（左側）」の段階で不備を見つけるアプローチなので真逆です。
★ ④：プログラムがビルドできた直後に、主要な機能がとりあえず起動するかを確かめる「ごく初期の簡易テスト」です。

1. 理解のコツ: 「新車の開発」に例えてみましょう。テストコース（実験室・ステージング環境）でどれだけ安全確認（シフトレフト）を重ねても、実際に「大雨の一般公道（本番環境）」を走らせてみないと、本当のワイパーの弾き具合やタイヤの静音性は分かりません。一般公道に出た「後」も、ドライブレコーダーやセンサーのデータを集めて車の挙動を検証し続ける、これがシフトライトテストです。
2. 試験対策の視点: 「本番環境へのリリース後」「実際のユーザー環境での検証」「カナリアリリースやカオスエンジニアリング」というキーワードが出たらシフトライトテストが一択です。DevOps（開発と運用の融合）やSRE（サイト信頼性エンジニアリング）の文脈で、近年非常に注目されているマネジメント用語です。

---

4. まとめ

「リリース後の本番環境という究極のリアル舞台で、継続的にシステムの安全性を検証する管理アプローチ」。これがシフトライトテストです。事前の「シフトレフト」で防げるバグは徹底的に防ぎ、事前検証が不可能なリスクは「シフトライト」で監視・制御する、という両輪のマネジメントが現代のクオリティ管理の最適解とされています。

【開発管理】ユーザーの「欲しい」をテストで定義！「ATDD（受け入れテスト駆動開発）」｜情報処理問題1000本ノック

アジャイル開発において、チーム全員が「同じゴール」を向くための管理手法。要望の定義と同時にテストの合格条件を決めてしまう、ATDDを攻略しましょう。

1. 【 問題 】：アジャイル開発のマネジメントプラクティス

【 問題 】 アジャイル開発において、顧客、ビジネスアナリスト、開発者、テスターが協力し、ユーザーストーリー（機能要求）の作成と同時に、その機能の完了条件となる「受け入れテスト」を明確に定義して開発を進める手法はどれでしょうか？

① TDD (Test-Driven Development)
② BDD (Behavior-Driven Development)
③ ATDD (Acceptance Test-Driven Development)
④ FDD (Feature-Driven Development)

2. 正解：

正解： ③ ATDD（Acceptance Test-Driven Development / 受け入れテスト駆動開発）

3. 解説：「できた！」の基準を最初に握る

ATDDは、開発をスタートする前に「何を作れば顧客が満足して受け入れてくれるか」というゴール（受け入れテスト）を全員で合意し、それを道標にして開発を“駆動（リード）”していく管理手法です。

【ATDDの4つのステップ（3アミーゴの協力）】

ATDDでは、ビジネス・開発・テストの3つの視点（3アミーゴ）で話し合います。

1. 議論 (Discuss)：顧客が「こんな機能（ユーザーストーリー）が欲しい」と提案する。
2. 抽出 (Distill)：全員で話し合い、「じゃあ、〇〇の条件でボタンを押したら、××の画面になる。これで合格（受け入れ）ですね？」と、具体的なテスト例を同時に定義する。 ← ココが問題の正解！
3. 実装 (Develop)：そのテストをパスすることだけを目指して、開発者がコードを書く。
4. デモ (Demo)：作った機能でテストを走らせ、顧客に確認してもらう。

[ 選択肢のひっかけポイント（似た3文字単語に注意） ]
★ ①：TDDは、開発者がプログラムの最小単位（関数など）に対して、コードを書く前に単体テストを書く「実装テクニック（開発技術）」です。顧客視点の受け入れテストを対象とするATDDとは規模や目的が異なります。
★ ②：BDDは、TDDやATDDをさらに「システムの振る舞い（ユーザーの行動）」に焦点を当て、「Given（前提）-When（もし）-Then（ならば）」という自然言語に近い文章で記述する手法です。

1. 理解のコツ: 「友達への誕生日プレゼント」に例えてみましょう。「何かいい感じの服が欲しい（ユーザーストーリー）」と言われて勝手に選ぶと、好みが合わずに失敗するリスクがあります。そうではなく、最初に「青色で、サイズはMで、普段着として洗えるパーカー（受け入れテスト）」と、合格ラインを具体的に約束してからお店に買いに行く。これがATDDです。絶対にハズレ（手戻り）が起きません。
2. 試験対策の視点: 「ユーザーストーリーの作成と同時」「受け入れテスト（または受け入れ基準）を定義」「顧客やテスターと協力」という管理・コミュニケーション重視の記述があればATDDです。先述の「Wモデル」や「シフトレフト」の思想を、アジャイル開発のチーム運営に落とし込んだ手法として出題されます。

---

4. まとめ

「要求定義（ユーザーストーリー）と受け入れテストをセットで作り、開発のブレをなくす管理手法」。これがATDDです。ビジネス側と開発側の『言った・言わない』の不毛な衝突を完全に防ぎ、無駄なコードを1行も書かずに最短ルートで顧客が本当に欲しいシステムを届けるための強力なプラクティスです。

【開発技術】設計とテストを同時に走らせる！「Wモデル」｜情報処理問題1000本ノック

「テストは開発が終わってからやるもの」という常識を覆し、超早期からバグを潰しにいく。Vモデルを進化させた現代的なプロセス「Wモデル」を攻略しましょう。

1. 【 問題 】：開発とテストの並行プロセスモデル

【 問題 】 ソフトウェア開発における「Wモデル」の特徴に関する記述として、最も適切なものはどれでしょうか？

① 開発工程の成果物が完成した後に、初めて対応するテスト工程の準備を開始するモデルである。
② 開発工程（要件定義・設計など）とテスト工程（テスト設計・テストケース作成など）を同時並行で進め、上流工程の段階から仕様の矛盾や不備（バグ）を早期に発見・修正していくモデルである。
③ ソフトウェアの機能を細切れに分割し、1週間から数週間という短い周期（スプリント）の開発を何度も繰り返すモデルである。
④ プログラムのコードを書く前に、まずテストコードを先に作成してから実装を始める開発手法である。

2. 正解：

正解： ② 開発工程とテスト工程を同時並行で進め、上流工程の段階から仕様の矛盾や不備を早期に発見・修正していくモデルである。

3. 解説：コードを書く前に、設計書を「テスト」する

従来のVモデルでは、左側の「設計」が終わってから、右側の「テスト」に進んでいました。しかし、これだと「要件定義や基本設計の段階で埋め込まれた勘違い（バグ）」が、開発の最後（システムテストなど）になるまで見つからないという大問題がありました。これを解決するのがWモデルです。

【Wモデルの同時並行の仕組み】

Wモデルでは、2つのV（開発のV、テストのV）を最初から同時に走らせます。

・システムエンジニアが「要件定義（開発のV）」をしている横で、テストエンジニアは「システムテストの計画・設計（テストのV）」を始めます。
・テストエンジニアが「この仕様だと、こういうパターンでテストできませんよ？」と突っ込むことで、コードを1行も書く前の「設計書の段階」でバグ（矛盾や考慮漏れ）を見つけて直すことができます。
→ これをテストの世界では「シフトレフト（テストの左前倒し）」と呼び、Wモデルはその代表例です。

[ 選択肢のひっかけポイント ]
★ ①：これは従来の「Vモデル」の説明です。
★ ③：これはアジャイル開発（スクラムなど）の説明です。
★ ④：これは「TDD（テスト駆動開発）」という、実装テクニックの説明です（Wモデルはプロジェクト全体のプロセスを指します）。

1. 理解のコツ: 「映画の撮影」に例えてみましょう。台本（設計書）が完成して、撮影（コーディング）が終わってから、最後に編集（テスト）で「あれ？このシーン、前後の繋がりがおかしいぞ！」と気づいたら、俳優を呼び戻して大がかりな再撮影（手戻り）になります。そうではなく、台本を作っている段階から編集者（テスト担当）も一緒に読み合わせをして、その場で矛盾を直していく。これがWモデルです。
2. 試験対策の視点: 「開発とテストを同時並行（並行して進める）」「上流工程からテスト活動を行う」「手戻りの削減」といったフレーズがあればWモデルが正解です。Vモデルとの違いを明確に突いてくるため、2つの違い（終わってからやるV、同時にやるW）を意識して覚えておきましょう。

---

4. まとめ

「設計とテスト設計をパラレル（同時並行）で走らせ、超早期にバグを刈り取るモデル」。これがWモデルです。バグは下流で見つけるほど修正コストが何倍にも膨らむため、上流で潰せるWモデルは、品質管理・コスト削減において極めて強力なアプローチです。

【開発管理】設計とテストは表裏一体！「Vモデル」｜情報処理問題1000本ノック

ソフトウェア開発の流れを「Vの字」で表現するVモデル。各開発工程の成果物が、どのテスト工程の基準（インプット）になるのか、その美しい対応関係を攻略しましょう。

1. 【 問題 】：ソフトウェア開発プロセスモデル

【 問題 】 ソフトウェア開発における「Vモデル」に関する記述として、最も適切なものはどれでしょうか？

① 開発工程の初期段階でプロトタイプ（試作品）を作成し、ユーザーの評価を得ながら仕様を確定していくモデルである。
② 開発工程とテスト工程を対比させて並べたものであり、各開発工程の成果物（アウトプット）が、それぞれ対応するテスト工程の検証基準（インプット）となることを示したモデルである。
③ システムをいくつかの機能単位に分割し、優先度の高い機能から順に設計、開発、テスト、リリースを繰り返していくモデルである。
④ 設計書のレビュー（静的テスト）を重視し、コードを書く前の段階で仕様の矛盾をすべて洗い出すことを目的としたモデルである。

2. 正解：

正解： ② 開発工程とテスト工程を対比させて並べたものであり、各開発工程の成果物が、それぞれ対応するテスト工程の検証基準となることを示したモデルである。

3. 解説：左で作り、右で試す

Vモデルは、ウォーターフォール開発における「開発工程」と「テスト工程」の1対1の対応関係を分かりやすく視覚化したものです。Vの字の左側を下に向かって進むのが開発、右側を上に向かって進むのがテストになります。

【Vモデルの美しい対応マップ】

左側の開発で作った「設計書（アウトプット）」は、右側のテストを行う際の「テスト仕様書（インプット）」に化けます。

・要件定義（ユーザーの要望）
↔ システムテスト／受入れテスト（本当に要望通り動くか？）

・基本設計／外部設計（画面や全体の仕組み）
↔ 統合テスト／結合テスト（部品を繋げて仕様通り動くか？）

・詳細設計／内部設計（プログラムの細かいロジック）
↔ 単体テスト（関数やクラス単体で正しく動くか？）

[ 選択肢のひっかけポイント ]
★ ①：これは「プロトタイピングモデル」の説明です。
★ ③：これは「イテレーティブ（反復）開発」や「アジャイル開発」に近い説明です。

1. 理解のコツ: 「取扱説明書」をイメージしてください。基本設計の段階で「この電化製品のリモコンのボタンを押すと、画面が切り替わります（取扱説明書の内容）」と決めたら、後で行う結合テストでは、その取扱説明書を読みながら「よし、ボタンを押して本当に画面が切り替わるな」とテストをします。左側で作った仕様書がないと、右側のテストができないという強い結びつきを示すのがVモデルです。
2. 試験対策の視点: 「開発工程とテスト工程の対応」「成果物がテストのインプット（基準）になる」という記述があればVモデルで間違いありません。午前問題では概念を問われ、午後問題では「基本設計書の不備は、どのテスト工程で発覚するか？（答え：結合テスト）」といった、具体的な対応関係を突っ込んでくる問題が頻出します。

---

4. まとめ

「上流の設計と、下流のテストを1対1でペアリングした開発モデル」。これがVモデルです。このモデルを意識することで、設計書を書いている段階から「この仕様はどうやってテストしようか？」と考える視点が生まれ、結果として手戻りの少ない高品質な開発ができるようになります。

【データベース】2回目も絶対に同じ値！「Repeatable Read」｜情報処理問題1000本ノック

Read Committedからさらに防御力を高め、「データの書き換わり」まで完全にロックするレベルです。何が防げて、何が防げないのかの境界線を見極めましょう。

1. 【 問題 】：トランザクション分離レベルの識別

【 問題 】 データベースのトランザクション分離レベルのうち、「ダーティリード」だけでなく、同一トランザクション内で同じデータを繰り返し読み込んだときに値が変わってしまう「ノンリピータブルリード（非反復読み取り）」の発生まで完全に防止されるものはどれでしょうか？
ただし、他のトランザクションが新しい行を挿入することによって、2回目の検索時に1回目にはなかったデータが出現する「ファントムリード」の発生は許容されるものとします。

① Read Uncommitted
② Read Committed
③ Repeatable Read
④ Serializable

2. 正解：

正解： ③ Repeatable Read（反復可能読み取り）

3. 解説：「自分が触った本には、鍵をかける」世界

Repeatable Read（リピータブル・リード）は、その名の通り「同じ読み取り（Read）が反復（Repeat）できる」ことを保証するレベルです。

【どうやってノンリピータブルリードを防いでいる？】

・このレベルでは、自分が1回データを読み込むと、データベースはそのデータに対して「トランザクションが終わるまで、他人は変更しちゃダメ」という強力なロック（共有ロック）を維持します。
・そのため、他人が途中で値を書き換えてコミットしようとしても、自分の処理が終わるまで待たされることになります。
・結果として、自分が2回目に同じ場所を読んだとき、1回目と1の位まで完全に同じ値であることが保証されます。

【しかし、なぜ「ファントムリード」は防げない？】

・Repeatable Readがロックするのは、あくまで「自分が既に読み込んだ既存の行」だけです。
・まだ存在していない、空いているスペース（隙間）まではロックしていません。
・そのため、他人がその隙間に「新しい行をポロッと追加してコミットする」ことは禁止できません。その結果、2回目の範囲検索（例：歳が20歳以上の人を全件取得）をしたときに、1回目にはいなかったメンバーが幻（ファントム）のように現れてしまうのです。

1. 理解のコツ: 図書館の席に例えてみましょう。「自分が一度手に取って机に置いた本（既存のデータ）」は、席を立つまで誰にも触らせないようガッチリ抱え込んでいます（ノンリピータブル防止）。しかし、「隣の空いている席に、誰かが新しい本を新しくポンと置いていく（ファントムリード）」ことまでは防げない、というイメージです。
2. 試験対策の視点: 問題文に「リピータブルリード（非反復読み取り）は防止される」かつ「ファントムリードは許容される（発生する）」とあれば、100%この Repeatable Read が正解になります。英語名そのままで問題文に出ることが多いので、言葉の意味さえ掴めば一瞬で解けるサービス問題です。

---

4. まとめ

既存データの書き換えを絶対に許さない、非常に堅牢な分離レベルがRepeatable Readです。
※ちなみに、MySQL（InnoDB）という有名なデータベースでは、このRepeatable Readをさらに独自の技術で強化し、ファントムリードまで裏でこっそり防いでくれる仕組み（MVCC）が搭載されており、これがデフォルト設定になっています（実務知識として知っておくとカッコいい豆知識です！）。

【データベース】実務のデファクトスタンダード！「Read Committed」｜情報処理問題1000本ノック

データの安全性とシステムの処理速度。その2つが最も実用的なバランスで妥協（トレードオフ）した、実務で最頻出の分離レベル「Read Committed」を攻略しましょう。

1. 【 問題 】：トランザクション分離レベルの識別

【 問題 】 ANSI/ISOで定義されている4段階のトランザクション分離レベルのうち、他のトランザクションがコミット（確定）していない未確定の変更データの読み取り（ダーティリード）は防止されるが、自身の処理中に他のトランザクションがデータを更新・追加することによって発生する「ノンリピータブルリード」および「ファントムリード」の発生は許容されるものはどれでしょうか？

① Read Uncommitted (未コミット読み取り)
② Read Committed (コミット済み読み取り)
③ Repeatable Read (反復可能読み取り)
④ Serializable (直列化可能)

2. 正解：

正解： ② Read Committed（コミット済み読み取り）

3. 解説：「確定した事実」だけを信じる世界

Read Committedは、名前の通り「コミット（確定）されたデータだけを読み取る」というルールです。これにより、存在しない幻のデータを読んでしまう最悪の事態（ダーティリード）は100%防げます。

【なぜ他の2つの現象は起きてしまうのか？】

■ ノンリピータブルリードが起きる理由
・自分が1回目の読み込みをした後、他のトランザクションがデータを変更してコミットを完了したとします。
・Read Committedのルールは「コミットされたら読んでも良い」なので、自分が2回目の読み込みをすると、他人が確定させた最新の値（書き換わった後の値）が見えてしまいます。これが「同じ処理の中で、2回同じ場所を読んだのに値が変わってしまう（ノンリピータブルリード）」の原因です。

■ ファントムリードが起きる理由
・同様に、自分が検索した後に他人が新しいデータを挿入してコミットを完了すると、2回目の検索では、1回目には存在しなかったはずの「新しい行（ファントム）」が出現してしまいます。

[ 4段階のレベルと不整合の対応関係 ]
1. Read Uncommitted ＝ 【全て発生】（最速・最危険）
2. Read Committed ＝ 【ダーティ防止、残り2つは発生】（実務の標準） ← ココ！
3. Repeatable Read ＝ 【ダーティ・ノンリピ防止、ファントムのみ発生】
4. Serializable ＝ 【全て防止】（最堅牢・最遅）

1. 理解のコツ: 「オフィシャルの記者発表」をイメージしてください。まだ噂段階の未確定情報には一切耳を貸さず、公式発表（コミット）された情報だけを記事にするため、デマ（ダーティリード）を掴むリスクはありません。しかし、公式発表が朝と夕方で更新されれば、手元のニュース内容が変わる（ノンリピータブルリード）のは受け入れる、というスタンスです。
2. 試験対策の視点: 「ダーティリードは防ぐ（許容されない）」「ノンリピータブルリードとファントムリードは発生する（許容される）」という組み合わせが来たらRead Committedが一択です。多くのデータベースシステムでデフォルト（初期設定）に採用されているため、問題文での登場回数が圧倒的に多い最重要レベルです。

---

4. まとめ

「嘘のデータは読まないが、他人が確定させた最新の変化はそのまま受け入れる分離レベル」。これがRead Committedです。データの一貫性をある程度保ちつつ、データベースに余計なロック（待ち時間）をかけないため、大規模なアクセスを捌く現代のシステムにおいて最もバランスの良い設定とされています。

【データベース】最速だけど最も危険！ダーティリードを許す「Read Uncommitted」｜情報処理問題1000本ノック

データの正確性と、同時処理のスピードはトレードオフの関係にあります。今回は、4段階ある「トランザクション分離レベル」の中で最も制約が緩いレベルを攻略しましょう。

1. 【 問題 】：トランザクション分離レベル

【 問題 】 ANSI/ISOで定義されている4段階のトランザクション分離レベル（アイソレーションレベル）のうち、他のトランザクションがコミット（確定）していない未確定の変更データを読み取る現象（ダーティリード）の発生を許容するものはどれでしょうか？

① Read Uncommitted (未コミット読み取り)
② Read Committed (コミット済み読み取り)
③ Repeatable Read (反復可能読み取り)
④ Serializable (直列化可能)

2. 正解：

正解： ① Read Uncommitted（未コミット読み取り）

3. 解説：ロックをかけずにフライング読み込み

トランザクション分離レベルは、複数の処理が同時に動くときの「お互いの独立性の高さ」を表します。レベルが低いほど処理スピード（スルーブット）は上がりますが、不整合が起きやすくなります。

【4つの分離レベルと発生する現象のまとめ】

下に行くほどレベルが高く（厳格に）なり、有害な現象をブロックできます。

1. Read Uncommitted（←ココが正解！）
・特徴：他人が書き換えている最中のデータを「お構いなし」に読めます。
・発生する不整合：ダーティリード、ノンリピータブルリード、ファントムリード

2. Read Committed
・特徴：他人がコミットした（確定した）データだけを読みます。
・発生する不整合：ダーティリードを防ぐ（ブロックする）。残り2つは発生。

3. Repeatable Read
・特徴：自分の処理中に、他人がデータを書き換えても自分には見えません。
・発生する不整合：ファントムリード（行が追加される現象）のみ発生。

4. Serializable
・特徴：すべての処理を順番に1つずつ実行するのと同様の状態にします。
・発生する不整合：すべての有害な現象を完璧に防ぎます（最も安全）。

[ 選択肢のひっかけポイント ]
★ ②：Read Committed（コミット済み読み取り）は、名前の通り「コミットされたデータしか読まない」レベルなので、ダーティリードは発生しません。

1. 理解のコツ: 「書類の承認プロセス」をイメージしてください。まだ上司のハンコ（コミット）が押されていない、作成中の下書き書類を勝手にデスクから持ち出して使い始めてしまうレベルがRead Uncommitted（未コミット読み取り）です。書類が後から破棄（ロールバック）されるリスクがありますが、完成を待たずにすぐ動けるのでスピードだけは最速です。
2. 試験対策の視点: 「ダーティリードを許容する」「最も分離レベルが低い」という条件が来たら「Read Uncommitted」が一択です。試験では、この4つの分離レベルと、3大有害現象（ダーティ／ノンリピータブル／ファントム）が「どこまで防げるか」の対応表を丸暗記しておくことが、データベース分野の得点王への近道です。

---

4. まとめ

「他の処理が確定していないデータでも、お構いなしに読み取ってしまう最も低い分離レベル」。これがRead Uncommittedです。お金の計算など、1円の狂いも許されないシステムでは絶対に選んではいけない設定ですが、多少の誤差が許される統計データの集計など、速度を限界まで追い求めたいケースで限定的に使われます。

【開発技術】修正による「飛び火バグ」を防ぐ！「リグレッションテスト」｜情報処理問題1000本ノック

バグを1つ直したら、別の場所が動かなくなった――開発現場で誰もが経験するこの恐怖。システムの「先祖返り」やバグの拡散を防ぐための必須テスト、リグレッションテストを攻略しましょう。

1. 【 問題 】：ソフトウェアテストの手法

【 問題 】 ソフトウェアの変更やバグ修正、機能追加を行った際に、その修正がシステム内の他の正常だった部分に予期せぬ悪影響（新たなバグの混入など）を及ぼしていないかを確認するために、以前実施したテストを再度行うものはどれでしょうか？

① リグレッションテスト（回帰テスト）
② 統合テスト（結合テスト）
③ 受入れテスト（承認テスト）
④ ストレステスト（負荷テスト）

2. 正解：

正解： ① リグレッションテスト（回帰テスト / 退行テスト）

3. 解説：既存の安心をもう一度確かめる

リグレッション（Regression）とは「後退、退行」という意味です。プログラムを書き換えたことで、システムの品質が「以前より悪くなっていないこと」を保証するために行うテストです。

【リグレッションテストの極意と自動化】

■ 目的：サイドエフェクト（副作用）の検知
・バグ修正そのものが正しく直っているかを確認するのは「デバッグ（修正確認テスト）」です。
・リグレッションテストは、その修正によって「関係ないはずのA機能やB機能が、巻き添えを食らって壊れていないか」を調べるために、過去に合格したテストケースを丸ごとやり直します。

■ 開発現場での運用：自動化の主役
・コードを書き換えるたびに毎回大量の過去のテストを行う必要があるため、人間が手動でやると膨大な時間がかかります。そのため、現代の開発（CI/CD：継続的インテグレーションなど）では、ツールを使って夜間に自動でリグレッションテストを回す仕組みが定着しています。

[ 選択肢のひっかけポイント ]
★ ②：複数のモジュール（部品）を組み合わせて、インターフェースのデータの受け渡しを確認するテストです。
★ ③：開発の最終段階で、発注元（ユーザー）が要望通りのシステムになっているかを確認するテストです。
★ ④：大量のデータやアクセスを同時に発生させ、システムが限界まで耐えられるかを試すテストです。

1. 理解のコツ: 「お家のリフォーム」をイメージしてください。2階の水回りを新しく修理してもらった（バグ修正）あと、その工事のせいで「1階の電気がつかなくなっていないか」「壁にヒビが入っていないか」を確認するために、家中のスイッチをもう一度入れて回る。これがリグレッションテストです。
2. 試験対策の視点: 「プログラムの変更・修正」「他の部分に悪影響がないか確認」「以前のテストを再度実施」というキーワードが並んだらリグレッションテストが一択です。カタカナで「リグレッションテスト」、漢字で「回帰テスト」または「退行テスト」と、試験によって表記が揺れるので、すべて同じ意味だと覚えておきましょう。

---

4. まとめ

「システムの修正・追加によって、正常だった他の機能が壊れていないかを確かめる再テスト」。これがリグレッションテストです。アジャイル開発や継続的な機能改善（アップデート）を行う現代のソフトウェア開発において、システムの品質を一定に保つための生命線と言えるテスト手法です。

【開発技術】成果物の完成度を高める！レビュー手法の定番「ウォークスルー」｜情報処理問題1000本ノック

ソフトウェア開発において、バグや設計の不備を早期に見つける「レビュー」。進め方や役割の違いによって名前が変わる、代表的な4つの手法を攻略しましょう。

1. 【 問題 】：システム開発のレビュー手法

【 問題 】 ソフトウェア開発におけるレビュー手法のうち、成果物の作成者自身がモデレータ（司会進行役）や説明者を兼ね、他のメンバーに成果物の内容を説明しながら、問題点や欠陥を早期に発見・指摘してもらうものはどれでしょうか？

① ウォークスルー
② インスペクション
③ パスアラウンド
④ ピアレビュー

2. 正解：

正解： ① ウォークスルー（Walk-through）

3. 解説：誰が主導するかで名前が変わる

レビュー手法を分類する際の最大のポイントは、「誰が司会（モデレータ）をするか」と「どれくらい厳格に行うか」です。

【試験に出る！レビュー4大手法の決定的な違い】

■ ウォークスルー（Walk-through）
・特徴：「作成者自身」が司会進行と説明を行います。参加者に事前に成果物を読み込んでもらう必要はなく、その場で説明しながらコメントをもらう、比較的カジュアルな手法です。 ← ココが問題の正解！

■ インスペクション（Inspection）
・特徴：最も「厳格」なレビューです。作成者ではない「第三者（モデレータ）」が司会を務めます。事前に参加者が成果物を読み込んでチェックリストを元に検証し、役割分担（記録係など）を明確にして実施します。結果は必ず文書化して品質を測定します。

■ パスアラウンド（Pass-around）
・特徴：成果物をメールやレビューツール（GitHubなど）で関係者に「回覧」し、非同期にコメントをもらう手法です。集まる必要すらありません。

■ ピアレビュー（Peer Review）
・特徴：管理者を含めず、開発者同士（Peer：仲間・同僚）で行うレビューの総称です（ウォークスルーやインスペクションも、仲間内で行うものはこれに含まれます）。

[ 選択肢のひっかけポイント ]
★ ②：インスペクションは「作成者以外の第三者」が司会を務める、最もカチッとした手法なので不適切です。
★ ④：ピアレビューは「同僚同士で行うレビュー」という広い意味の言葉であるため、今回の「作成者自身が説明して〜」という具体的な手順を指す言葉としては「ウォークスルー」が最も適切です。

1. 理解のコツ: 自分の作った「旅行のしおり」を友達に説明する場面をイメージしてください。あなたがしおりを開いて「1日目はまずここに行って〜、次ここね」と指差しながら（ウォークスルーしながら）説明し、友達から「あ、ここの移動時間足りなくない？」と突っ込んでもらう。このスタイルがウォークスルーです。
2. 試験対策の視点: 「作成者自身が説明」「モデレータを兼ねる」というフレーズがあれば一発でウォークスルーです。逆に、問題文に「第三者がモデレータ」「チェックリストを使用」「最も厳格」とあればインスペクションが正解になります。この2つの対比はレビュー問題の超・大本命です。

---

4. まとめ

「作成者が主導して、内容を説明しながら欠陥を探すレビュー」。これがウォークスルーです。プログラミングのバグは、後から（テスト工程で）見つけるほど修正コストが跳ね上がるため、この段階で早期に潰しておくことがプロジェクトの成功に直結します。