第117講 システム開発とプロジェクトマネジメント｜情報Ⅱで「作る側」に回ると何が変わるか

情報Ⅰの「動くプログラムを書く」と、情報Ⅱの「システムを作る」は、別の仕事です。1人で書き切れる規模を超えた瞬間、主題は分けること・つなぐこと・確かめることに変わります。この講では、国の一次資料だけを使ってその境目を示し、小さな貸出システムで要件定義から単体テストまでの1周を実際に回してみせます。

こんにちは、数強塾グループ代表の藤原進之介です。本記事は参考書『藤原進之介の最強120講義』第117講のWeb版で、第6部「情報Ⅱへの橋」の1本です。共通テスト重要度はC——情報Ⅱは共通テストの出題範囲外だからです。ただし、この講の内容は第54講（トレース）や第53講（関数）で身につけたことが「工程」として名前を持つ場所であり、情報Ⅰの理解を一段深くします。

1. この講の問い

「動くプログラムが書ける」ことと「システムが作れる」ことは、どこで別の仕事になるのか。

2. 結論

1人で書き切れる規模を超えた瞬間、仕事の中身が「書くこと」から分けること・つなぐこと・確かめることに変わります。だから情報Ⅱは、工程（要件定義→設計→実装→テスト→運用）とテストの種類とプロジェクトの管理を正面から扱います。そして最初に壊れるのは中身ではなくつなぎ目です。

3. なぜそうなるのか

3-1. 「別の仕事だ」と国が自分で表にしている

文部科学省の「情報Ⅱ解説動画」第4章［1］のスライド（2024年3月公開）に、次の3行の表があります。私が資料を全部あたった中で、情報Ⅰと情報Ⅱの違いをここまで端的に書いたものは他にありません。

同じスライドは学習の目的を「将来情報システムを発注、あるいは利用する上で役に立つ視点を身につけよう」「課題解決する上で、適切なプロジェクトマネジメントを行える力を身につけよう」と書きます。プログラマ養成講座ではありません。発注する側・使う側の目線を作る科目として設計されています。

3-2. 情報Ⅰの一次資料には「確かめる方法」がほとんど書かれていない

語の出現回数を数えると、境目が数字で出ます。3つの資料をテキスト化し、空白と改行を全部除去してから機械計数しました（2026年8月3日実施）。学習指導要領解説 情報編は第1部＝共通教科（情報Ⅰ・情報Ⅱ）と第2部＝専門教科情報科を分けて数えています。

大事なのは合計ではなく用法の内訳です。数える前に、ヒットした箇所を1件ずつ目で見て確認しました。

• 情報Ⅰ教員研修用教材の「テスト」5件は、1件もソフトウェアの検査ではありません。A/Bテストが1件、体力・運動能力調査の「新体力テスト」「テスト項目の年次推移」が4件です。
• 解説 第1部の7件のうちソフトウェアの検査を指す5件は、すべて情報Ⅱ(4)の記述です。残り2件はスポーツテストのデータと、機械学習の「テストデータ」でした。
• 情報Ⅰ教材の「デバッグ」4件は、3件が中学校 技術・家庭科の学習指導要領の引用（「安全・適切なプログラムの制作、動作の確認及びデバッグ等ができること」）で、残り1件は「プログラムの制作やデバッグが容易か」という言語選択の視点。高校の情報Ⅰの本文で、デバッグのやり方を説明した箇所はありません。

第54講で確かめたとおり「トレース」も情報Ⅰの一次資料に0件でした。つまり情報Ⅰには「プログラムを検査する方法」という項目が、語のレベルでも内容のレベルでも存在しません。書けるようになるところまでが情報Ⅰで、確かめる方法は情報Ⅱに置かれている——これがこの講の出発点です。

3-3. なぜインタフェースが最重要なのか

情報Ⅱ教員研修用教材 第4章 学習24 の原文です。

中身が正しくても、つなぎ目で壊れる。だから学習22 のモジュール分割の手順は6段階あって、その❺が「インタフェースの定義」です。カプセル化の説明も「データを読み書きするための関数」＝「モジュールのインタフェースに相当する」となっています。第53講で「引数の順番を間違える」引っかけを扱いましたが、あれは情報Ⅱではバグの類型名になります。

ここで語数の罠が1つあります。「インタフェース」は 解説第1部2／解説第2部10／情報Ⅰ教材13／情報Ⅱ教材44 ですが、意味が2種類あります。

• 情報Ⅰ教材の13件は、モジュール間の接続という意味が0件です。第2章のユーザインタフェースが9件、第4章のネットワークインタフェース層が3件、情報デザインの対象の列挙が1件。
• 情報Ⅱ教材の44件も、第2章の31件はユーザインタフェース（手続き型・目的型・自動型の分類）。モジュール間の意味で使われるのは第4章の9件だけです。

同じ語が「人と機械のさかいめ」から「部品と部品のさかいめ」へ意味を変えます。件数だけ数えると4倍に見誤る典型例なので、参考書の「情報Ⅱではインタフェースが44回出る」といった書き方には注意してください。

3-4. なぜテストに種類があるのか

理由は2段あります。

第1段：単体で正しいことと、組み合わせて正しいことは別。そのために、まだできていない下位モジュールの代わりにスタブ、上位モジュールの代わりにテストドライバという偽物を置いて、先に試します。教材は上位から結合する方法をトップダウンテスト（スタブが要る／「インタフェースエラーなど重大な欠陥を早期に検出できる」がテストドライバは不要）、下位からをボトムアップテスト（テストドライバが要る／「分担しての並行作業が容易」だが「重要な欠陥が後になって検出される」）と呼び、両者を同時に進めるのがサンドイッチテスト、小規模なら全部一度につなぐビッグバンテストもあると書きます。どちらの偽物を作るかがトレードオフになるのがおもしろいところです。

第2段：動くことと、使えることも別。学習25 は総合テストを機能テストと非機能テストに分けます。非機能テストは「プログラムの機能ではなく処理速度や反応速度など、ユーザーが操作する際に不満がないレベルのものであるか」を見るテストです。第73講（通信速度）と第62講（待ち行列）で計算した数字が、ここで検査項目として合流します。

⚠️ 計数の注意をもう1つ。教材の「機能テスト」22件のうち6件は「非機能テスト」の部分一致です。機能テストの実数は16件。短い語を含む長い語がある場合、素朴な検索は必ず多く出ます。

3-5. なぜ見積りが要るのか

第73講で見たとおり、教材は2層クライアントサーバから3層への移行理由を「通信負荷」と明記しています。検索結果が全部ネットワークを流れるから構成を変えた——数字がシステムの構造を決めた実例です。

解説動画のスライド［2］はもっと生々しい。グループチャットに欲しい機能を「メッセージを書き込む／メッセージを読み込む／ToDoリスト／リマインダー機能」と4つ挙げたあとで、こう書きます。

そして「今回の目的からスケジュール管理の重要性は低いので、メッセージ機能に特化することにした」と、ToDoリストとリマインダーを切り捨てます。第2章 学習8 の要件定義（連絡アプリからフォトアルバムを削る）とまったく同じ形です。要件定義とは、機能を並べる作業ではなく、削る決断のこと。ここが受験生に一番伝わりにくいところだと思います。

3-6. 工程の名前は、一次資料の中だけで3系統ある

これは私が調べていて驚いた点です。同じ国の資料の中で、工程の呼び方が揃っていません。

しかも同じ第4章の中に「要件定義」21件と「要求定義」9件が混在します（教材全体では30件と10件）。学習21 は要件定義を業務要件定義（利用者がシステムを使う目的と得られる利益を明確にする）と機能要件定義（目的を達成するために利用者がシステムを使って行う仕事を明確にする）に分けてきちんと定義しているのに、要求定義のほうは一度も定義されないままＶ字モデルの図と学習25 の本文で使われます。ちなみに解説では逆で、要求定義4件・要求分析10件はすべて専門教科側にあります。

この図の読み方はひとつです。左で決めたことを、同じ高さの右で検査する。裏を返せば左で決めていないことは、右で検査できません。要件定義が曖昧なシステムは、テストの合否も決められない。教材が学習22 の指導上の留意点に「要求定義がしっかりなされていないと、モジュールの分割も困難であることを認識させる」と書いているのは、そういう意味です。

だから工程名は暗記する対象ではありません。「何を決める工程か」で覚えます。幸い解説 情報Ⅱ(4)ア(イ)は、6工程それぞれに定義文を置いてくれています。

さらに解説は「なお、要件定義については、その前に、日常生活の中にある課題をどのような情報技術を使って解決するかを構想し企画することが重要であることも理解するようにする」と釘を刺します。要件定義の前に企画がある。何を作るかを決める前に、なぜ作るかを決めろということです。

3-7. プロジェクト・マネジメントの定義も、解説にそのまま書いてある

教材はその道具として2つを挙げます。WBS（Work Breakdown Structure＝作業を分解して構造化する手法。作り方は「ゴールを決定する→ゴールに到達するために必要な作業を列挙する→さらに細分化する」）と、ガントチャート（作業工程を分割し、担当者を振り、時間軸で可視化したもの。先行作業との関係を確認しながら進捗を見る）。教材は「まずは簡易なものを表計算ソフトウェアなどで作り、概念を理解するとよいだろう」と書いています。

4. 手で確かめる——小さな1周を実際に回す

題材は部活動の共用備品の貸出にします（教材の図書館システムとは別題材の自作です）。要件定義→設計→実装→テストを、実際に1周してみましょう。

JOGEN = 3  # 1人が同時に借りられる上限（機能要件）
def kari_kano(buin_id, hinmei, zaiko_su, hoyu_su):
    """貸出できるかを判定する。zaiko_su と hoyu_su は下位モジュールの関数＝インタフェース"""
    if zaiko_su(hinmei) <= 0:
        return (False, "ZAIKO_NASHI")
    if hoyu_su(buin_id) > JOGEN:        # ← ここが今回の書き間違い
        return (False, "JOGEN_CHOKA")
    return (True, "OK")

下位モジュールはまだ影も形もありません。そこでスタブを置きます。決め打ちの値を返すだけの偽物です。

# スタブ（ダミーの下位モジュール）。決め打ちの値を返すだけ。
def stub_zaiko(n):
    return lambda hinmei: n
def stub_hoyu(n):
    return lambda buin_id: n

そして❸で設計したテストケースを、そのまま表の形でコードに書き写します。

# 同値分割と境界値分析で作ったテストケース
CASES = [
    (0, 0, False, "ZAIKO_NASHI", "在庫の境界（無効側）"),
    (1, 0, True,  "OK",          "在庫の境界（有効側）"),
    (5, 0, True,  "OK",          "所持0＝同値クラスの代表"),
    (5, 2, True,  "OK",          "所持の境界（有効側）"),
    (5, 3, False, "JOGEN_CHOKA", "所持の境界（無効側）"),
    (5, 4, False, "JOGEN_CHOKA", "上限超過の代表"),
]
ng = 0
for z, h, kahi_e, riyu_e, nerai in CASES:
    kahi, riyu = kari_kano("B001", "バスケットボール",
                           stub_zaiko(z), stub_hoyu(h))
    ok = (kahi == kahi_e and riyu == riyu_e)
    if not ok:
        ng += 1
    print("在庫%d 所持%d -> (%s, %-12s) 期待(%s, %-12s) %s  # %s"
          % (z, h, kahi, riyu, kahi_e, riyu_e, "OK" if ok else "NG", nerai))
print("不合格 %d 件 / 全 %d 件" % (ng, len(CASES)))

実行結果です（私の手元で実際に走らせた出力をそのまま貼っています）。

在庫0 所持0 -> (False, ZAIKO_NASHI ) 期待(False, ZAIKO_NASHI ) OK  # 在庫の境界（無効側）
在庫1 所持0 -> (True, OK          ) 期待(True, OK          ) OK  # 在庫の境界（有効側）
在庫5 所持0 -> (True, OK          ) 期待(True, OK          ) OK  # 所持0＝同値クラスの代表
在庫5 所持2 -> (True, OK          ) 期待(True, OK          ) OK  # 所持の境界（有効側）
在庫5 所持3 -> (True, OK          ) 期待(False, JOGEN_CHOKA ) NG  # 所持の境界（無効側）
在庫5 所持4 -> (False, JOGEN_CHOKA ) 期待(False, JOGEN_CHOKA ) OK  # 上限超過の代表
不合格 1 件 / 全 6 件

6件中5件は通り、落ちたのは「所持3点」の1件だけです。適当に0点と4点だけ試していたら、このバグは見つかりません。> を >= に直すと6件すべて OK になります（こちらも実行して確認済み）。

延滞  -1 日 -> 停止  0 日
延滞   0 日 -> 停止  0 日
延滞   1 日 -> 停止  1 日
延滞   2 日 -> 停止  2 日
延滞   6 日 -> 停止  6 日
延滞   7 日 -> 停止  7 日
延滞   8 日 -> 停止 14 日
延滞   9 日 -> 停止 14 日
延滞  30 日 -> 停止 14 日

7日と8日の間で 7 → 14 と飛びます。この段差を仕様として意図しているのか、それとも書き間違いなのか。表を作ると、そこが議論の対象になります。これが「テストを設計する」ということです。

5. 共通テストではこう出る（重要度 C）

この講は共通テストに接続しません。情報Ⅱは出題範囲外です。ここで扱った語（単体テスト・結合テスト・スタブ・WBS・Ｖ字モデル）を覚える必要はありません。

ただし入口だけは情報Ⅰ側に開いています。令和8年度本試験 第3問について、大学入試センターの問題評価・分析委員会報告書は、プログラムの作成・評価・改善を通じて思考力を問うたと述べ、正答率を「条件設定の理解を問う問題は8割以上、プログラム中の空欄を埋める問題は4〜8割、プログラムの改善を扱った問題は4割程度、プログラムの動きを問う問題は約2割」と公表しています。「改善」を問われた瞬間に正答率が4割まで落ちる。改善するには、まず「どこが悪いか」を切り分けられなければなりません。それは単体テストと結合テストの発想そのもので、この講で扱った工程の入口が、すでに情報Ⅰの第3問に置かれているということです。

6. 情報Ⅱではこうなる

本講自体が情報Ⅱ(4)「情報システムとプログラミング」の話です。教員研修用教材 第4章は学習19〜25 の7単元で構成されています。

学習25 は開発の進め方も3つ並べます。ウォーターフォール型（「時間をかけて仕様を設計し、その仕様の通りに実装してテストする」方式で、教材は「仕様を決めたら変更が難しい銀行等のシステムなどの開発に従来から広く使われてきた」と書く）、プロトタイプ型（「大まかに動く試作品を短期間で作り、その動作を確認しながら仕様を修正する」）、スパイラル型（機能を限定したシステムの作成と評価を繰り返す）。作り方が1つではないことを、高校段階で示している点は押さえておきたいところです。

そして教材はテスト駆動開発（TDD）まで進みます。「従来の開発順序」＝内部設計書→単体プログラム→テスト設計→テスト実施（成功）に対し、「テスト駆動開発での開発順序」＝仕様の確定→テストを設計→テストの実施（失敗）→単体プログラムを作成→テストの実施（成功）。Python の標準ライブラリ unittest を使った例まで載っています。

その先——高校の外へどうつながるか

IPA（情報処理推進機構）のITパスポート試験シラバス Ver.6.5 を当たると、この講の語がどこに配置されているかが分かります。WBS・アローダイアグラム・ガントチャートは「プロジェクトマネジメント」の用語例、ウォーターフォールモデル・スパイラルモデル・プロトタイピングモデルは「主なソフトウェア開発モデル」、そしてテスト駆動開発は「アジャイル」の用語例です（教材は学習25 でTDDを扱いますが、アジャイルという語は使いません）。Ｖ字モデルはITパスポートのシラバスに0件で、この点は情報Ⅱ教材のほうが先に出しています。

供給側の事実——情報Ⅱの教科書は3点しかない

文部科学省「高等学校用教科書目録（令和8年度使用）」によると、情報Ⅱの教科書は3点だけです。東京書籍（情Ⅱ701）・実教出版（情Ⅱ702）・日本文教出版（情Ⅱ703）で、いずれも定価1,211円・令和4年検定。情報Ⅰが17点あるのに対して3点です。学校で開講されないことも多いのが現状ですが、国の教員研修用教材（全7分冊）と解説動画は無料で公開されています。独学の材料は手に入ります。

まとめ

• 情報Ⅰは1人で書く、情報Ⅱは複数人で作る。国自身がその表を作っている
• 情報Ⅰの一次資料にはソフトウェアのテストの記述が実質0件。トレースもデバッグの方法もない
• 壊れるのは中身ではなくつなぎ目。だからインタフェースを先に決める
• テストは単体→結合→総合、さらに機能／非機能。動くことと使えることは別
• 要件定義は削る決断。工程名は3系統あるので、名前ではなく何を決める工程かで覚える
• 境界値でしか出ないバグがある。試す場所を設計するのがテスト設計

第6部のほかの講もあわせて読むと、情報Ⅱの全体像がつかめます。まずは第109講「情報Ⅱとは何か」から。全120講の一覧はこちらのハブページにまとめてあります。

出典（すべて2026年8月3日に取得）

• 文部科学省「高等学校学習指導要領（平成30年告示）解説 情報編」平成30年7月 https://www.mext.go.jp/content/1407073_11_1_2.pdf
• 文部科学省「高等学校情報科『情報Ⅱ』教員研修用教材（本編）」令和2年3月発行。第4章 情報システムとプログラミング https://www.mext.go.jp/content/20200609-mxt_jogai01-000007843_005.pdf
• 文部科学省「高等学校情報科『情報Ⅰ』教員研修用教材」（第1〜4章） https://www.mext.go.jp/a_menu/shotou/zyouhou/detail/mext_00017.html
• 文部科学省「情報Ⅱ解説動画」［1］〜［4］情報システムとプログラミング スライド（2024年3月公開） https://www.mext.go.jp/a_menu/shotou/zyouhou/detail/mext_02652.html
• 文部科学省「高等学校用教科書目録（令和8年度使用）」令和7年4月 https://www.mext.go.jp/content/20250415-mxt_kyokasyo02-000041714_3r.pdf
• 大学入試センター「令和8年度大学入学共通テスト 問題評価・分析委員会報告書」『情報Ⅰ』問題作成部会の見解 https://www.dnc.ac.jp/albums/abm.php?d=2151&f=abm00017684.pdf
• 情報処理推進機構（IPA）「ITパスポート試験 シラバス Ver.6.5」 https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kn1-att/syllabus_ip_ver6_5.pdf