【開発管理】矢印の罠に引っかかるな！「プレジデンス・ダイアグラム法」｜情報処理問題1000本ノック

プロジェクトのスケジュールを組む際、作業の順番（前後関係）を網の目のように表すネットワーク図。記述の「主語」を冷静に見極める必要がある罠問題を攻略しましょう。

1. 【 問題 】：スケジュール管理のネットワーク図

【 問題 】 プロジェクト管理におけるスケジュール管理技法（タイムマネジメント）のうち、作業の依存関係を表す「ネットワークダイアグラム」に分類され、個々の『作業（タスク）』をノード（結合点となる四角などの箱）で表現し、その作業間の『順序（前後関係）』をアロー（矢印）で表現するものはどれでしょうか？

（ア）プレジデンス・ダイアグラム法
（イ）アロー・ダイアグラム法
（ウ）クリティカル・ダイアグラム法
（エ）作業イベント法

2. 正解：

正解： （ア）プレジデンス・ダイアグラム法（PDM）

3. 解説：「アロー」という言葉の罠を解き明かす

この問題の最大のポイントは、「何がノードで、何がアローか」という組み合わせの定義です。試験では（ア）と（イ）の明確な違いが超高頻度で狙われます。

【絶対に混同してはならない2つの図法の違い】

■ （ア）プレジデンス・ダイアグラム法（PDM：AON方式）
・構造：作業（アクティビティ）そのものを「ノード（四角などの箱）」の中に書きます。そして、作業を繋ぐ「矢印（アロー）」は、単に『順番』を表すためだけに使います。 ← ココが問題の正解！

■ （イ）アロー・ダイアグラム法（PERT：AOA方式）
・構造：作業（アクティビティ）そのものを「アロー（矢印）」の上に書きます。そして、「ノード（丸印）」は作業の『開始イベント・終了イベント（結合点）』を表します。

[ 選択肢のひっかけポイント ]
★ （ウ）クリティカル・ダイアグラム法：そのような名前の図法はありません。これらの図から導き出される、遅れが絶対に許されない最長の経路のことは「クリティカルパス」と呼びます。
★ （エ）作業イベント法：こちらも存在しない架空の用語です。

1. 理解のコツ: 目の前にある「タスクカード（四角い付箋）」を想像してください。「①要件定義」と書いた付箋と、「②設計」と書いた付箋を壁に貼り、それを線（矢印）で結びますよね。この、作業自体が「四角い箱（ノード）」になっている、私たちが普段一番よく見かける馴染み深い書き方がプレジデンス・ダイアグラム法（PDM）です。
2. 試験対策の視点: 問題文をパッと見たときに「アローで表現する」という単語だけを目が拾ってしまうと、反射的に（イ）を選んで失点してしまいます。「作業をノードで」と書かれているか、それとも「作業をアローで」と書かれているか、主語を1文字ずつ丁寧に読むことが午前試験の罠を回避する鉄則です。

---

4. まとめ

「作業を箱（ノード）で表し、その前後関係を矢印で繋ぐ、現代のプロジェクト管理ツールの標準的なネットワーク図法」。これがプレジデンス・ダイアグラム法です。この図法を用いることで、作業の並列実行や「前が完全に終わっていなくても次の作業を少しフライングして始めてよい（リード・ラグ）」といった複雑なスケジュール調整を視覚的に行えるようになります。

【開発管理】本番環境でしか見えないリスクを暴く！「シフトライトテスト」｜情報処理問題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行も書かずに最短ルートで顧客が本当に欲しいシステムを届けるための強力なプラクティスです。

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

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

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

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

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

2. 正解：

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

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

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

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

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

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

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

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

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

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

---

4. まとめ

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

【開発技術】修正による「飛び火バグ」を防ぐ！「リグレッションテスト」｜情報処理問題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. まとめ

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

【開発技術】バグを減らす設計思想！「関数型プログラミング」｜情報処理問題1000本ノック

命令を順番に実行する「手続き型」とは異なり、計算を「関数の組み合わせ」として捉える。モダンな開発で必須知識となった関数型プログラミングの核心を攻略しましょう。

1. 【 問題 】：プログラミングパラダイムの特性

【 問題 】 関数型プログラミングの特徴に関する記述のうち、最も適切なものはどれでしょうか？

① 変数の値を頻繁に書き換えることで、処理の効率を高めメモリの使用量を抑える。
② 同じ引数を与えても、実行するタイミングやシステムの内部状態によって異なる結果を返す。
③ 関数を「第一級オブジェクト」として扱い、他の関数に引数として渡したり、戻り値として受け取ったりできる。
④ グローバル変数を多用し、どこからでも自由にデータを変更できるようにしてプログラムの柔軟性を担保する。

2. 正解：

正解： ③ 関数を「第一級オブジェクト」として扱い、他の関数に引数として渡したり、戻り値として受け取ったりできる。

3. 解説：状態を変えない「安全」な計算

関数型プログラミングは、「状態の変化」をできるだけ排除し、数学的な関数（入力に対して常に出力が一意に決まるもの）を組み合わせてプログラムを構築する手法です。

【関数型プログラミングの3大キーワード】

■ 純粋関数（Pure Function）
・同じ引数（入力）を渡せば、「いつでも必ず同じ結果（出力）」が返ってくる関数。外部の変数を勝手に書き換えたりしないため、予測しやすくテストが超簡単になります。

■ 不変性（Immutability）
・一度作ったデータは「後から書き換えない」というルール。値を変更したいときは、元のデータを変えるのではなく、新しいデータを作り直します。

■ 第一級オブジェクト（First-Class Object）としての関数
・関数を「数値」や「文字列」と全く同じように扱えます。つまり、関数の中に別の関数を引数として放り込んだり（高階関数）、関数を戻り値として出力したりできます。

[ 選択肢のひっかけポイント ]
★ ①・④：値をどんどん書き換えるのは手続き型やオブジェクト指向の特徴であり、関数型では嫌われます（バグの原因になるため）。
★ ②：タイミングで結果が変わるものは「純粋関数」ではないため、関数型の特徴に反します。

1. 理解のコツ: 数学の $f(x) = x + 2$ を思い出してください。 $x$ に $3$ を入れたら、昨日計算しても、10年後に計算しても、絶対に答えは $5$ ですよね。途中で勝手に数式が書き換わることもありません。この「いつでも、どこで実行しても、絶対に計算結果がブレない安心感」を目指すのが関数型プログラミングです。
2. 試験対策の視点: 「純粋関数」「副作用がない（外部に影響を与えない）」「不変性（イミュータビリティ）」「第一級オブジェクト（ファーストクラス）」という言葉が出たら関数型プログラミングが正解です。近年は、JavaやJavaScript、Pythonなど、あらゆる主要言語に関数型の機能（ラムダ式など）が取り入れられているため、開発技術分野のトレンド問題として頻出です。

---

4. まとめ

「関数をデータと同じように扱い、状態変化（副作用）のないコードを目指す思想」。これが関数型プログラミングです。マルチコアCPUによる並行・並列処理（マルチスレッド）を行う際にも、データが勝手に書き換わらない関数型の特性は圧倒的な強みを発揮します。

【開発技術】エラーはいつ見つける？「静的型付け」と「動的型付け」｜情報処理問題1000本ノック

プログラミング言語が変数の「データ型（数値や文字列など）」をいつ、どのようにチェックするのか。開発の安全性とスピードを左右する2つの型付け手法を攻略しましょう。

1. 【 問題 】：プログラミング言語の特性

【 問題 】 プログラミング言語のデータ型の扱いに関する記述のうち、適切なものはどれでしょうか？

① 静的型付け言語では、プログラムの実行時に変数の型が決定されるため、実行速度が高速になる。
② 動的型付け言語では、コンパイル時に厳密な型チェックが行われるため、データ型の不一致によるエラーを実行前に検知できる。
③ 静的型付け言語では、ソースコードの記述段階やコンパイル時に変数の型が決定されるため、型に関するバグを実行前に発見しやすい。
④ 動的型付け言語では、変数の型をあらかじめ宣言する必要があるため、大規模開発におけるコードの可読性が高まる。

2. 正解：

正解： ③ 静的型付け言語では、ソースコードの記述段階やコンパイル時に変数の型が決定されるため、型に関するバグを実行前に発見しやすい。

3. 解説：型をチェックする「タイミング」の違い

「型付け（Typing）」とは、変数に入れるデータの種類（整数、文字列、配列など）のルールのことです。このルールを「実行前」に決めるか、「実行しながら」決めるかが決定的な違いです。

【2つのアプローチの特徴比較】

■ 静的型付け（Static Typing）
・いつ決まる？：プログラムを実行する前（コード記述時やコンパイル時）。
・メリット：間違った型を代入しようとすると、実行前にエラー（コンパイルエラー）が出るため安全。大規模開発向き。
・代表例：Java, C++, TypeScript, Go, Rustなど。

■ 動的型付け（Dynamic Typing）
・いつ決まる？：プログラムを実行している最中（値が代入された瞬間）。
・メリット：型をいちいち宣言しなくてよいため、コードが短く済み、素早く開発できる。試作向き。
・代表例：Python, JavaScript, Ruby, PHPなど。

[ 選択肢のひっかけポイント ]
★ ①：実行時に型を決めるのは「動的型付け」です。
★ ②：コンパイル時にチェックするのは「静的型付け」です。
★ ④：事前に型を宣言する必要があるのは「静的型付け」です。

1. 理解のコツ: 荷物を送る「段ボール箱」をイメージしてください。あらかじめ「これは割れ物用」「これは本用」と箱にラベルを貼って指定するのが静的型付けです（違うものを入れると怒られます）。一方、中身を詰めてガムテープを貼った瞬間に「あ、これは本箱ね」と決まるのが動的型付けです。
2. 試験対策の視点: 「コンパイル時に型が決定する＝静的」「実行時に型が決定する＝動的」という対応関係を確実に覚えましょう。近年はJavaScript（動的）に型を導入したTypeScript（静的）が主流になるなど、トレンドとしても非常によく狙われるテーマです。

---

4. まとめ

「エラーを実行前に潰せる安全な静的型付け」と、「素早く柔軟にコードが書ける動的型付け」。これがプログラミング言語の2大特性です。それぞれのメリット・デメリットを正しく理解することが、堅牢なソフトウェア設計への第一歩です。

【ソフトウェア開発技術】変化を味方につける！「アジャイルプロセス」｜情報処理問題1000本ノック

あらかじめ完璧な計画を立てるのではなく、小さな単位で開発を繰り返しながら完成度を高めていくアジャイル開発。その根底にある「アジャイル宣言」の考え方を攻略しましょう。

1. 問題：アジャイルプロセスの特色

【 問題 】 アジャイルプロセスの特色として、適切でないものはどれでしょうか？

ア、数週間程度の短いサイクルで開発を繰り返し、短期開発を目指す。
イ、開発チームと利用者が密接に協力し、利用者が積極的にプロジェクトに参加する。
ウ、形式的な仕様書や、数学的に厳密さが保証された膨大なドキュメントの作成を最重視する。
エ、開発の途中であっても、ビジネス環境やユーザーニーズによる要求の変化を柔軟に受け入れる。

2. 正解：開発プロセスに関する正解

正解： ウ、数学的に厳密さが保証されたドキュメントを重視する

3. 解説：「動くソフト」と「対話」を重んじる

アジャイル開発では、包括的なドキュメント（書類）よりも、実際に動作するソフトウエアを早く提供することを優先します。

【図解：アジャイルソフトウエア開発宣言のポイント】

■ 重視するもの（左側） vs 軽視はしないが優先順位が低いもの（右側）
1. プロセスやツール よりも 個人との対話
2. 包括的なドキュメント よりも 動くソフトウエア ★(ウ)のポイント
3. 契約交渉 よりも 顧客との協調
4. 計画の遵守 よりも 変化への対応

■ 数学的な厳密さについて
・選択肢(ウ)にある「数学的に厳密なドキュメント」は、主に「形式手法（フォーマルメソッド）」などで重視されるものであり、スピードと変化への対応を重視するアジャイルの思想とは対極にあります。

[ 関連用語：イテレーション（反復） ]
★ アジャイルでは「計画→設計→実装→テスト」という一連のサイクルを1〜4週間程度の短い期間で行います。この繰り返しの単位を「イテレーション」（スクラムではスプリント）と呼びます。

1. 理解のコツ: 「旅行ガイドブック（ドキュメント）を完璧に読み込む」ことよりも、「とりあえず現地へ行って、天気や気分に合わせて行き先を決める（動くソフトと変化への対応）」のがアジャイルのスタイルです。
2. 試験対策の視点: 「ドキュメントよりもプログラミングを優先」「計画変更を歓迎する」「ユーザーとのコミュニケーション」といったキーワードが正解（適切な特色）としてよく登場します。逆に、厳格な文書化や事前の詳細すぎる計画はアジャイルには馴染まないため、誤答の選択肢として使われます。

---

4. まとめ

「ドキュメントよりも、動くソフトウェアと変化への柔軟性を重視する」。これがアジャイルプロセスです。ビジネスのスピードが加速する現代において、ユーザーと共に価値を作り上げていくための現代的な開発手法です。

【ソフトウェア開発技術】論理の美しさと正しさの基本！「適正プログラム」｜情報処理問題1000本ノック

複雑なプログラムも、基本となるパーツが「入り口が一つ、出口が一つ」という規律を守っていれば、解析や修正が格段に楽になります。この基本的な定義を攻略しましょう。

1. 問題：プログラムの構造的定義

【 問題 】 プログラムの処理単位において、以下の2つの条件を満たすものを何と呼ぶでしょうか？
① 入口が一つで、出口も一つである。
② 入口から入って、必ず出口に到達する（無限ループがない）。

ア、構造化プログラム   イ、適正プログラム   ウ、保守性プログラム   エ、アルゴリズムド・プログラム

2. 正解：プログラム設計に関する正解

正解： イ、適正プログラム（Proper Program）

3. 解説：なぜ「出口一つ」が重要なのか

プログラミングにおいて、あちこちからジャンプして入ってきたり、途中で勝手に終了したりするコードは「スパゲッティコード」の原因となります。

【図解：適正プログラムの2条件】

■ 条件1：1入口・1出口（Single Entry, Single Exit）
・どこから始まってどこで終わるかが明確であること。
・これにより、処理を一つの「ブラックボックス（部品）」として扱いやすくなります。

■ 条件2：停止性（Terminating）
・途中でデッドロックを起こしたり、永遠に終わらないループに陥ったりせず、必ず出口にたどり着くこと。

[ 構造化プログラミングとの関係 ]
★ 構造化プログラミング（ダイクストラが提唱）は、この「適正プログラム」を、「順次・選択・反復」という3つの基本構造だけで組み合わせる手法のことです。適正プログラムはその最小単位の理想形と言えます。

1. 理解のコツ: 迷路をイメージしてください。「入り口が1つ、出口が1つ、そして必ずゴールに辿り着けるルートがある」。そんな健全な迷路（プログラム）が「適正」な状態です。
2. 試験対策の視点: 紛らわしい選択肢として「構造化プログラム」がありますが、問題文が「1つの入口と1つの出口を持つ～」という定義そのものを問うている場合は、「適正プログラム」が最も適切な用語になります。

---

4. まとめ

「1つの入口と1つの出口を持ち、必ず終了する」。これが適正プログラムです。この規律を守ることが、バグが少なく、他人が読んでも理解しやすい「良いコード」への第一歩となります。