成果物の管理・解析とコード設計
構成管理とリポジトリの役割、リバースエンジニアリングと似た用語の違い、Java の3つの実行形態を区別できるようになる。チェックディジットと、コードの桁数・枯渇年度の計算を自力で解けるようになる。
リバースエンジニアリングは免除試験を含めて30回以上出ている頻出の用語問題です。チェックディジットとコード桁数は、手順を覚えれば確実に取れる計算問題です。どれも「古いシステムの仕様が分からない」「ID が足りなくなる」といった、実務でよく起きる事故を防ぐための知識です。
このレッスンで稽古する（用語チェック・過去問）構成管理：どの成果物の、どの版が、どれと対応しているか
結論：構成管理は、成果物の「版（バージョン）」とその対応関係、そして変更の手続を管理することです。 管理の対象になるプログラム・仕様書・設計書などを 構成品目 と呼びます。進捗・品質・体制の管理とは別物です。
実務の例でいうと、「要件定義書 v1.2・API 仕様 v3.0・実装 v3.0.1 がそれぞれ対応している」という対応表と、「決まった手続を通さないと書き換えられない」というルールのセットです。これが崩れると「どこを直せばよいか分からない」「直したはずの修正が反映されていない」が起きます。
| 起きた問題・管理項目 | 担当する管理 | 構成管理に起因する？ |
|---|---|---|
| 改版手続を守らずに修正し、正しく動いていたプログラムが壊れた | 構成管理（変更の手続） | する |
| 仕様書・設計書・プログラムの版が対応付いておらず、修正箇所を特定できない | 構成管理（版数管理） | する |
| 派生元の修正が、派生プログラムに反映されない | 構成管理（派生の管理） | する |
| システムテストで単体テストレベルのバグが多発する | 品質管理（テスト） | しない |
| 開発作業の進捗状況 | 進捗管理 | しない |
| 成果物のレビュー結果 | 品質管理 | しない |
| プロジェクト組織の編成 | 体制（要員）管理 | しない |
試験での問われ方
- 「構成管理の対象は？」→ プログラムのバージョン。進捗・レビュー結果・組織編成がひっかけの選択肢です。
- 「構成管理に起因しない問題は？」→ 版・手続・派生の話が出てこない選択肢（バグの多発など品質の話）を選びます。
リポジトリ：成果物を一か所にまとめる書庫
結論：リポジトリは、各工程の成果物を一元管理する場所です。 一か所にまとめることで開発や保守の作業効率が上がり、用語の統一 もしやすくなります。
たとえると、部署ごとにバラバラだった資料をまとめた共有の書庫です。試験では「不良の管理（品質分析）」「作業手順の定義」「予定と実績の管理（進捗）」が、ひっかけの選択肢として並びます。正解のキーワードは 「成果物の一元管理」 です。
リバースエンジニアリング：物から設計図を書き起こす
結論：リバースエンジニアリングは、既存のソフトウェア（ソースコード・オブジェクトコード・稼働中のDB定義など）を解析して、仕様や設計を明らかにする手法です。 通常の開発は「設計図 → 物（コード）」の向きで進みます。その逆の「物 → 設計図」の向きなので「リバース」と呼びます。
たとえると、完成した料理を味見して材料と手順を割り出し、レシピを書き起こす作業です。稼働中のデータベースの定義から E-R 図（データの関係を表す図）付きの設計書を作るのも、リバースエンジニアリングにあたります。
flowchart LR
A["設計情報（仕様書・E-R図）"] -->|"フォワードエンジニアリング"| B["ソースコード・稼働中のDB"]
B -->|"リバースエンジニアリング"| A
| 用語 | 何をするか | 見分けるキーワード |
|---|---|---|
| リバースエンジニアリング | 既存のソフトを解析し、仕様・設計を明らかにする | 物 → 設計図。「解析して」「取り出す」「設計書を生成」 |
| フォワードエンジニアリング | 設計情報からソースコードを（自動）生成する | 設計図 → 物。「設計情報から」「自動生成」 |
| リエンジニアリング | 既存のソフトを分析・理解したうえで、全体を新しく作り直す | 「作り直す」（リバース＋フォワード） |
| リファクタリング | 外部から見た振る舞いを変えずに、内部構造を改善する | 「振る舞いを変えずに」 |
| リストラクチャリング | プログラムの構造を整理し直す（再構造化） | 「再構造化」。仕様の取り出しはしない |
| コンカレントエンジニアリング | 設計・製造などの工程を並行して進め、期間を縮める | 「並行」 |
| ソーシャルエンジニアリング | 人の油断や心理の隙を突いて、パスワードなどを盗み出す | セキュリティの攻撃手口。開発手法ではない |
試験での問われ方
- 「説明はどれか」型：4つの選択肢が、フォワード（自動生成）・リファクタリング（振る舞いを変えない）・リバース（解析して明らかにする）・リエンジニアリング（作り直す）にそれぞれ対応しています。
- 「この手法はどれか」型：「〜エンジニアリング」「リ〜」で始まる似た名前が並びます。向き（物 → 設計図） と 「解析・取り出す」 で判断します。
Java の3つの実行形態：どこで動くかで見分ける
結論：Java のプログラムは、動く場所で3つに分かれます。アプリケーションは単体で、アプレットはブラウザで、サーブレットは Web サーバで動きます。 試験では「何が必要か」「どこで動くか」を問われます。
| 名前 | どこで動くか | 必要なもの・特徴 |
|---|---|---|
| Java アプリケーション | PC などで単体で動く | Java VM だけ あればよい（ブラウザも Web サーバも不要） |
| Java アプレット | クライアント側の Web ブラウザ | サーバからダウンロード してブラウザ上で実行する |
| Java サーブレット | Web（アプリケーション）サーバ上 | クライアントの 要求に応じて サーバ側で実行する |
| JavaScript | （過去問の文脈では）クライアント側のブラウザ | 名前は似ているが Java とは別の言語 |
| VBScript | （過去問の文脈では）クライアント側のブラウザ | 主にブラウザで動くスクリプト言語 |
| JavaBeans | — | Java のプログラムを 部品として扱うための規約 |
| Java VM | — | バイトコード（中間コード） を実行する仕組み |
範囲に注意：「Web 環境の動的処理で、Web サーバ上だけで動くもの」の正解がサーブレットになるのは、その問題の選択肢（JavaScript・アプレット・サーブレット・VBScript）の中では という意味です。JavaScript も Node.js を使えばサーバ側で動きます。一般論として「サーバ側で動く技術はサーブレットだけ」というわけではありません。
試験での問われ方：サーブレットの説明問題では、アプレット（ダウンロードして実行）・JavaBeans（部品の規約）・Java VM（中間コードを実行）の説明がひっかけの選択肢として並びます。
チェックディジット：入力ミスを見つける最後の1桁
結論：チェックディジット（検査数字）は、コードの入力ミスを見つけるために末尾に付ける1桁です。 各桁に重みを掛けて合計し、基数で割った余りから求めます。読み取る側も同じ計算をして、末尾の数字と一致しなければ入力ミスだと分かります。
手順の型は次の3つだけです。
- 桁ごとに掛けて足す（データ × 重み付け定数）
- 基数で割った余り を求める（mod(x, y) は「x を y で割った余り」）
- 問題文の指示どおりに仕上げる（例：基数 − 余り の1の位）
試験での問われ方：手順3の仕上げを飛ばした値（余りそのもの）が、必ず選択肢に混ざっています。チェックディジットから未知の桁を逆算させる問題も出ます。どちらも下の例題で手順を確認してください。
コード桁数と枯渇年度：組合せは掛け算で数える
結論：コードで表せる数は「1桁あたりの種類数」を桁数の分だけ掛け算した値です。 英大文字なら1桁あたり26通り、数字なら10通りです。将来の件数と比べて、足りるかどうか、いつ足りなくなるかを判断します。
| 形式 | 表せる数 |
|---|---|
| 英大文字2桁 | 26 × 26 ＝ 676 |
| 英大文字3桁 | 26³ ＝ 17,576 |
| 英大文字2桁＋数字3桁（XXNNN） | 26 × 26 × 10 × 10 × 10 ＝ 676,000 |
試験での問われ方：「毎年2割増える」は、×1.2 を年数の分だけ 掛け続けます（20% × 3年 ＝ 60% 増、という足し算ではありません）。枯渇年度は「年度末の累積」が総数を超える年度を答えます。
チェックディジットを付加する（データ7394・重み1234・基数11）
ア 73940
イ 73941
ウ 73944
エ 73947
解き方と答えを見る
- 手順1 桁ごとに掛けて足す：7×1 ＋ 3×2 ＋ 9×3 ＋ 4×4 ＝ 7 ＋ 6 ＋ 27 ＋ 16 ＝ 56
- 手順2 基数で割った余り：56 ÷ 11 ＝ 5 余り 1 → 余りは 1
- 手順3 基数から余りを引く：11 − 1 ＝ 10
- 手順4 その1の位を取る：10 の1の位は 0 → チェックディジットは 0
- 手順5 データの末尾に付ける：7394 ＋ 0 → 73940
答え：ア（73940）。余りの 1 をそのまま付けるとイ（73941）を選んでしまう。
チェックディジットから未知の桁を逆算する（C＝4、N2＝7、N3＝6、N4＝2）
ア 0
イ 2
ウ 4
エ 6
解き方と答えを見る
- 式：C ＝ mod(N1×1 ＋ N2×2 ＋ N3×3 ＋ N4×4, 10)
- 分かっている桁を代入：N2×2 ＝ 7×2 ＝ 14、N3×3 ＝ 6×3 ＝ 18、N4×4 ＝ 2×4 ＝ 8
- 合計：N1 ＋ 14 ＋ 18 ＋ 8 ＝ N1 ＋ 40
- 40 は 10 で割り切れるので、mod(N1 ＋ 40, 10) ＝ N1 を 10 で割った余り
- これが C ＝ 4 になるので、0〜9 の数字の中では N1 ＝ 4
- 確かめ：4 ＋ 40 ＝ 44 → 44 ÷ 10 の余りは 4 ＝ C
答え：ウ（4）
3年後まで足りる顧客コードの桁数（英大文字26種類）
ア 3
イ 4
ウ 5
エ 6
解き方と答えを見る
- 1年後：8,000 × 1.2 ＝ 9,600 人
- 2年後：9,600 × 1.2 ＝ 11,520 人
- 3年後：11,520 × 1.2 ＝ 13,824 人（＝ 8,000 × 1.2³）
- 2桁で表せる数：26² ＝ 676 → 足りない
- 3桁で表せる数：26³ ＝ 17,576 → 17,576 ≧ 13,824 なので足りる
答え：ア（3桁）
ID（XXNNN）を発行し尽くす年度を予測する
| 年度 | 2006 | 2007 | 2008 | 2009 |
|---|---|---|---|---|
| 発行済ID数（累積） | 317,000 | 383,000 | 447,000 | 512,000 |
ア 2010年度
イ 2011年度
ウ 2012年度
エ 2013年度
解き方と答えを見る
- ID の総数：英大文字2桁 × 数字3桁 ＝ 26 × 26 × 10 × 10 × 10 ＝ 676 × 1,000 ＝ 676,000
- 毎年の増加数：2007年度 383,000 − 317,000 ＝ 66,000、2008年度 447,000 − 383,000 ＝ 64,000、2009年度 512,000 − 447,000 ＝ 65,000 → 1年あたり約 65,000
- 2010年度末：512,000 ＋ 65,000 ＝ 577,000（総数 676,000 未満）
- 2011年度末：577,000 ＋ 65,000 ＝ 642,000（まだ未満）
- 2012年度末：642,000 ＋ 65,000 ＝ 707,000（676,000 を超える）→ 2012年度の途中で尽きる
答え：ウ（2012年度）
要点（試験直前に読む）
- 構成管理の対象は「成果物の版（プログラムのバージョン）」。進捗・レビュー結果・組織編成は対象外。
- バグの多発は品質管理（テスト）の問題で、構成管理に起因しない。
- リポジトリ＝各工程の成果物を一元管理する場所。作業効率と用語の統一に役立つ。
- リバースエンジニアリング＝既存の物を解析して仕様・設計を取り出す（物 → 設計図）。フォワードは設計 → コードの自動生成、リファクタリングは振る舞いを変えない内部改善、リエンジニアリングは作り直し。
- Java：アプリケーション＝VM だけで動く、アプレット＝ダウンロードしてブラウザで動く、サーブレット＝Web サーバ上で要求に応じて動く。
- チェックディジットは「掛けて足す → 基数で割った余り → 指示どおり仕上げる」。コードの総数は種類数の掛け算、増加率は年数の分だけ掛け続ける。
ひっかけ
- チェックディジットの問題では、最後の仕上げ（基数 − 余り の1の位など）を飛ばした「余りそのもの」が選択肢にある。手順の番号を1つずつ消し込んで計算する。
- 「〜エンジニアリング」「リ〜」の似た名前が並ぶ。「解析・取り出す・設計書を生成」ならリバース、「自動生成」ならフォワード、「振る舞いを変えずに」ならリファクタリング、「作り直す」ならリエンジニアリング。
- 「Web サーバ上だけで動くのは？」→ その問題の選択肢の中ではサーブレット（JavaScript・VBScript・アプレットはクライアント側で動く）。「ダウンロードして実行」はアプレット、「VM だけで動く」はアプリケーション。
- 「構成管理に起因しない問題」では、版・改版手続・派生の話が出てこない選択肢（テストでのバグの多発など）を選ぶ。
- 増加率の問題で「2割 × 3年 ＝ 6割増」と足し算にしない。×1.2 を3回掛ける。コードの総数も 26 × 2 のような足し算ではなく、26 × 26 のように掛け算する。
用語（20）
成果物の版とその対応関係、変更の手続を管理して、どれが最新で、どれとどれが対応しているかを常に分かるようにすること。
⚠ 進捗管理・品質管理と混同しやすい。対象が「成果物の版」なら構成管理、作業の進み具合やバグ・レビュー結果なら別の管理。
構成管理の対象になる個々の成果物（プログラム・仕様書・設計書など）。
成果物の版（バージョン）を記録し、仕様書・設計書・プログラムの版の対応を取れるようにすること。
成果物を修正して新しい版にするときに通す、決められた承認と記録の手順。
各工程の成果物を一元管理する場所で、作業効率を上げ、用語の統一にも役立つ。
⚠ 不良管理・手順定義・進捗管理のツールと混同しやすい。キーワードは「成果物の一元管理」。
既存のソフトウェアやDB定義を解析して、仕様や設計の情報を取り出す手法。
⚠ フォワードエンジニアリングは逆向き（設計情報 → コード）。リエンジニアリングは解析したうえで作り直すところまで含む。
設計情報からソースコードなどを生成する、通常の向きの開発手法。
⚠ リバースエンジニアリングと向きが逆。「設計情報から自動生成」ならフォワード。
既存のソフトウェアを分析・理解したうえで、全体を新しく作り直すこと。
⚠ リバースは解析だけ、リエンジニアリングは作り直しまで行う。
外部から見た振る舞いを変えずに、プログラムの内部構造を改善すること。
⚠ リバースエンジニアリングと混同しやすい。「振る舞いを変えずに」が出てきたらリファクタリング。
プログラムの構造を整理し直すこと（再構造化）。
⚠ 仕様や設計を取り出す手法ではないので、リバースエンジニアリングとは違う。
設計・製造などの工程を並行して進めて、開発期間を短くする手法。
⚠ 名前が似ているだけで、解析とは関係ない。キーワードは「並行」。
人の油断や心理の隙を突いて、パスワードなどの情報を盗み出す攻撃手口。
⚠ 開発手法ではなくセキュリティの用語。
Java のバイトコード（中間コード）を実行する仕組みで、これがあれば Java アプリケーションが動く。
⚠ サーブレットの説明問題で「インタプリタ」「バイトコードを実行」とあれば Java VM の説明。
Java VM さえあれば、Web ブラウザも Web サーバも使わずに単体で動く Java プログラム。
⚠ アプレット（ブラウザが必要）、サーブレット（Web サーバが必要）との違いは「VM だけで動く」こと。
サーバからダウンロードして、クライアント側の Web ブラウザ上で実行される Java プログラム。
⚠ サーブレットと名前が似ている。「ダウンロードしてクライアントで実行」ならアプレット。
クライアントの要求に応じて、Web（アプリケーション）サーバ上で実行される Java プログラム。
⚠ アプレット（ダウンロードしてブラウザで実行）と混同しやすい。過去問の選択肢（JavaScript・アプレット・サーブレット・VBScript）の中で「Web サーバ上だけで動く」のはサーブレット。ただし一般論としてサーバ側の技術がサーブレットだけというわけではない。
Java のプログラムをアプリケーションの部品として扱うための規約。
⚠ サーブレットの説明問題で「部品として取り扱う規約」とあれば JavaBeans。
コードの入力ミスを見つけるために、各桁から計算して末尾に付ける1桁の数字。
チェックディジットの計算で、データの各桁に掛ける決められた数。
チェックディジットの計算で、合計を割るときに使う数（例：11、10）。
⚠ 基数で割った「余り」と「基数 − 余り」を取り違えないこと。問題文の手順に従う。
このレッスンの過去問
- 構成管理が必要となる状況の判断平成28年度 春期 基本情報技術者試験 午前 問50
- リポジトリの目的(成果物の一元管理)基本情報技術者試験 科目A免除 修了試験 20250608 実施分 問34
- リバースエンジニアリングの定義平成29年度 秋期 基本情報技術者試験 午前 問50
- Javaプログラムの実行形態(アプリケーション・アプレット・サーブレット)平成28年度 秋期 基本情報技術者試験 午前 問8
- チェックディジットの計算平成29年度 秋期 基本情報技術者試験 午前 問24
- コード桁数と組合せ総数による枯渇年度予測平成29年度 春期 基本情報技術者試験 午前 問23